[gdal-dev] Problem with Shapefile and CRS 2056/21781

Even Rouault even.rouault at spatialys.com
Sun Apr 24 08:58:43 PDT 2016


Le dimanche 24 avril 2016 17:46:45, Stefan Keller a écrit :
> 2016-04-24 17:34 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
> > Could you post the .prj file ?
> 
> Bien sur: I posted both CRS.
> Hope attachments come through.

OK, that explains it.

The .prj file are somewhere between a old-style ESRI WKT and regular OGC WKT, 
in that they have a AUTHORITY EPSG node, but no TOWGS84 node.
Hence when you do the direct conversion, no datum shift is taken into account. 
When you do the 2-step conversion, in the first step, the GPKG driver has a 
logic to add entries in its gpkg_spatial_ref_sys table based on the source 
SRS. When the source SRS has a EPSG node, the WKT definition is read from the 
GDAL SRS db from the EPSG code (thus ignoring the rest of the WKT), which 
brings back the default TOWGS84. The second ogr2ogr call then applies it when 
reprojecting.

I guess we would want to improve the shapefile importer to get the WKT 
definition from the GDAL EPSG DB when a AUTHORITY EPSG node is found. Could you 
create a ticket about that ?

Even

> 
> :Stefan
> 
> 2016-04-24 17:34 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
> > Le dimanche 24 avril 2016 17:29:36, Stefan Keller a écrit :
> >> Given a Shapefile "swiss_admin_boundaries.shp" in EPSG:2056 (or 21781,
> >> to be downloaded for free at [1]) I have problems transforming it to
> >> any other SRS/CRS.
> > 
> > Could you post the .prj file ?
> > 
> >> When doing this:
> >> > ogr2ogr -f "GPKG" swiss_admin_boundaries1.gpkg
> >> > swiss_admin_boundaries.shp -t_srs EPSG:3857
> >> 
> >> ... swiss_admin_boundaries2.gpkg have a shift of about 150m.
> >> 
> >> But when I convert Shapefile first e.g. to GeoPackage, and transform then:
> >> > ogr2ogr -f "GPKG" tmp.gpkg swiss_admin_boundaries.shp
> >> > ogr2ogr -f "GPKG" swiss_admin_boundaries2.gpkg tmp.gpkg -t_srs
> >> > EPSG:3857 del tmp.gpkg
> >> 
> >> ... swiss_admin_boundaries2.gpkg is correct!
> >> 
> >> What could be the reason?
> >> 
> >> :Stefan
> >> 
> >> [1] https://opendata.swiss/en/dataset/swissboundaries3d-gemeindegrenzen
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list