Tag Info

Hot answers tagged

3

In QGIS, the projection string for EPSG:3399 is: +proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=5500000 +y_0=0 +ellps=bessel +units=m +no_defs This projection string has no datum shift +towgs84, which I would expect for every transformation from the German DHDN/bessel to the WGS ellipsoid. See this page in German for more information on official transformation ...


1

After posting the question I was able to track down a specific article at Geosoft that answers this. Yes, the "Local Datum Transform" is used to convert to WGS84. https://my.geosoft.com/supportcentre?showOverlay=yes&login=ok#kb/kA230000000VFkoCAG See Local Datums


1

You make a mistake with the pyproj parameters from pyproj import Proj, transform inProj = Proj("+init=EPSG:3857")) outProj = Proj("+init=EPSG:4326") x1,y1 = (-20037507.0672, 20037509.6184) x2,y2 = (-1467048.29156, 8625918.8737) # with the x,y coordinates of pointx print transform(inProj,outProj,x1,y1) (-179.99998854118687, 85.08398750388278) # with the ...


1

Andrew, I think you're thinking wrong and it may get you into trouble. You need to stop thinking in terms of your dataset and start thinking in terms of GDAL and GIS. Your dataset data is in some projection, in this case State Plane. That means you use state plane (ft here) coordinates to access the data. The transform (GetGeoTransform) converts between ...


1

Source of problem found. It turns out the GEOTIFF_CSV environmental variable was not set. In c#, the following code: OSGeo.GDAL.Gdal.SetConfigOption("GEOTIFF_CSV", Path.GetDirectoryName(Application.ExecutablePath) + @"\gdal-data"); makes a very big difference. Now the geoTransform contains the actual lat/long.



Only top voted, non community-wiki answers of a minimum length are eligible