On mercredi 7 mars 2018 17:45:41 CET Andre Joost wrote: > Am 07.03.18 um 11:50 schrieb Michael Schulz: > > Dear devs, > > > > why is og2ogr using a grid shift file explicitely specified in the > > proj4 string in the s_srs parameter and not when the same proj4 string is > > in the system-wide proj4/epsg file? > > > > This example gives correct projected results: > > > > ogr2ogr -f 'ESRI Shapefile' target.shp -s_srs "+proj=tmerc +lat_0=0 > > +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel > > [email protected],BETA2007.gsb +units=m +wktext" -t_srs "EPSG:25832" > > source.shp > > > > The proj4/epsg contains exactly the same definition for EPSG:31467, but > > when used like this: > > > > ogr2ogr -f 'ESRI Shapefile' target.shp -s_srs "EPSG:31467" -t_srs > > "EPSG:25832" source.shp > > > > the transformation is using the towgs84 parameters defined in > > datum_shifts.csv... > > > > Is this the intended behaviour? > > Yes, this is intended. GDAL has its own CRS definition files, and does > normally not fall back to the proj4 folder definitions. > > C:\OSGeo4W64\share\gdal\datum_shift.csv is the file to look for, > containg a definition for EPSG:4314 DHDN, which will be used for all > DHDN based projected CRS.
Right, if you use "EPSG:XXXXX" as SRS name, GDAL will build the proj4 string from its various csv files in its data directory If you want to use the definition from the proj.4 epsg file, use "+init=epsg:XXXXX" (on Unix, make sure to put 'epsg' in lowercase there, as this is the filename, so case sensitive) Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
