Tag Info

New answers tagged

0

I guess your data have lat/long coordinates ("Geographic coordinate systems" in ArcGis), so that coordinates are stored in degrees (e.g. decimal degrees). For this kind of analysis I think the use of a "Projected coordinate systems" is recommended. You can refer to the following image (Wikipedia) to find the UTM zone where your project data belongs: ...


2

The shapefile distributed by GeoDa Center does not have a PRJ file, so normally you would have to define the projection in order to line it up with other spatial data. But it appears that while the shapefile distributed by GeoDa Center does in fact use the UTM 19N zone, for some reason the units are in kilometers, where UTM coordinates are usually expressed ...


0

Try to look to this page: Convert Between Geographic and UTM Coordinates This page convert from UTM to Geographic lat\lon with javascript,You can view source of the page by pressing (CTRL + U) on the browser and press (CTRL + F) to search for the function (UTMtoGeog).


1

i faced somehow the same problem. For me that worked. instead of EPSG:4326 in my project i used EPSG:28993. mapOptions = {projection:"EPSG:900913",displayProjection: new OpenLayers.Projection("EPSG:4326")}; map = new OpenLayers.Map(mapOptions); googleBaseMap = new OpenLayers.Layer.Google("Google Satellite", {'type' : google.maps.MapTypeId.HYBRID}); ...


2

It seems the first dataset (vista_nicosia_links.shp) is using a different projection, most likely UTM (the zone depending on your data's location - for Nicosia, it is most likely UTM Zone 36 North). To match the coordinates properly, you have to correctly determine and define the shapefile's coordinate system (using Define Projection or changing the ...


2

Either the WGS 1984 in the original raster, or in the target UTM doesn't match Esri's definition of WGS 1984. It's probably one of the names. If it's the original raster, try using the Define Projection tool to reset it to Esri's WGS 1984 definition. If it's the output coordinate system, try using Esri's version instead.


0

A shapefile should usually have a .prj file with the projection information. For GDA94, there are different projections available: EPSG:3577 Australian Albers EPSG:3112 Geoscience Australia Lambert EPSG:3308 NSW Lambert EPSG:3107 SA Lambert EPSG:3111 Vicgrid94 EPSG:3113 BCSG02 and GDA94/MGA zone 48 to 58. From those, zone 55 should be the best choice. ...


3

Yes. Double-click the dataframe name in the Table of Contents, or right-click it and choose Properties. On the Coordinate System tab, at the bottom, click the Transformations button. This will bring up the same dialog as when you add the layers. Here you can select the CRS of the layers present in the top box, the CRS you want to specify them to (your ...


0

The GeometryEngine.project() method is the right method, you just need to ensure your output spatial reference is correct. SpatialReference srFrom = SpatialReference.create(3857) // WGS84 SpatialReference srTo = SpatialReference.create(3168) // Kertau_RSO_RSO_Malaya // convert point Point convertedPoint = GeometryEngine.project(point, srFrom, srTo); A ...


0

Since you specified the transformation you used, I looked it up in some reference material Esri provides on selecting a transformation to use - specifically, this pdf which lists available transformations in ArcGIS. It includes an accuracy column. Although there isn't any specific explanation of the numeric value, and mkennedy has noted it is derived from a ...


3

Proposal: Conic Equidistant Projection This preserves distance over all meridians and two parallels of choice (could be optimized for major areas of interest). Notice, most distance distortion is in the southern oceans out of the area of interest. As an alternative, you could divide the world into 5 identical projections centered on each continent. This ...


0

Where is the problem, simply use this: double lat = 8.654; double lon = 38.123; double[] xy = new double[2] { lat, lon }; double[] z = new double[1] { 1234.5 }; Reproject.ReprojectPoints(xy, z, pStart, pEnd, 0, 1); Console.WriteLine(String.Foramt("New Lat/Lon = {0}/{1}", xy[0], xy[1]));


3

You might get a shift if the source CRS of the original shapefile is not given by an EPSG code, but a .prj file. These do not include datum sift parameters, and gdal tries to match the WKT information with its own EPSG database. So I suggest to always add the -s_srs parameter for all ogr2ogr operations.


4

Gi* doesn't care about distance, it cares about weights (which you could set to inverse distance if you want...) so you need to think about how to form weights between raster cells on the whole globe. This is tricky, because at the poles, your cells are a different shape and area to those on the equator, and have a different adjacency relationship with ...


2

I'm currently struggling with similar issues, so feel free to wait for a more authoritative answer. However, I can't recommend an equidistant projection. It sounds great, but keep in mind that the distances are true only along specific lines. Measured along other directions, the distances will not be true. I doubt that you want to use a single projected ...


1

This is apparently not possible with ArcGIS for Desktop, see Esri's article FAQ: Are vertical datum transformations supported in ArcGIS? If you go to the ArcGIS idea page referenced in the article's comments, there is a mention of this being possible in Pro and Runtime, programmatically. To be verified with Esri, I couldn't find any confirmation of this.



Top 50 recent answers are included