Re: [gdal-dev] ogr2ogr using grid shift files
Hi Andre and Even, thanks a lot for this clarification. Especially the last hint from Even solved my issue, although widely using this syntax, I wasn't aware of the subtle difference it makes. Cheers and thanks, Michael 2018-03-07 23:13 GMT+01:00 Even Rouault : > 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=350 +y_0=0 +ellps=bessel > > > > +nadgrids=@BWTA2017.gsb,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:X" 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:X" (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 > -- --- Michael Schulz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr using grid shift files
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=350 +y_0=0 +ellps=bessel > > +nadgrids=@BWTA2017.gsb,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:X" 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:X" (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 gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr using grid shift files
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=350 +y_0=0 +ellps=bessel +nadgrids=@BWTA2017.gsb,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. So try to adjust that file. HTH, Andre Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev