Hi Tobias, On Sun, 14. Jan 2018 at 15:09:30 +0100, Tobias Wendorff wrote: > I was able to observe many users over the year, which do not correct > the projection neither for work within QGIS, nor for saving (they are > not aware of the problem) Worse still: when saving, EPSG:3044 is > written to the PRJ file (for shapefiles). Thus, the error manifests > itself permanently. There are also other
I just tried and the EPSG is only written to the qpj, but not to the prj. That's why we write .qpj, because otherwise we may run into the same problem even within QGIS. GDAL doesn't write the full WKT into the prj - it "morphs to ESRI" for compatibility reason. The qpj carries it. If there is no qpj, we rely on GDAL to detect the correct CRS from the prj, which can have issues with some prjs (if there is a qpj too - but we feed it the full WKT from the qpj). GDAL does detect the correct EPSG from prj it wrote itself. Apparently from the different name of the projection, because the rest of the prj is the same. There is no information about the different axis order in the prj (ie. the only actual difference between EPSG:3044 and EPSG:25832). I guess you see the problem with prj from third parties that use different projection names. And hence there may be no clue left in the prj that could help with identifying whether it's EPSG:3044 or EPSG:25832. How do your .prj actually look like? > Possible workaround: > We should check all SRS/CRS, where the parameters overlap. Then we > should order those "duplicates" by the frequency of use (for exaple > official projections first, follwed by historical projections). > Maybe there's only a handful of projections that are affected. Unfortunately not. sqlite> select count(*),count(*)-count(distinct parameters) from tbl_srs; 6759|1633 1633/6759 crs have duplicates. sqlite> select count(*),parameters from tbl_srs group by parameters having count(*)>1 order by count(*) desc limit 10; 138|+proj=geocent +ellps=GRS80 +units=m +no_defs 62|+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs 51|+proj=longlat +ellps=intl +no_defs 36|+proj=longlat +ellps=GRS80 +no_defs 25|+proj=geocent +ellps=WGS84 +units=m +no_defs 17|+proj=longlat +ellps=clrk80 +no_defs 15|+proj=longlat +ellps=bessel +no_defs 14|+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs 13|+proj=longlat +ellps=clrk66 +no_defs 9|+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +vunits=m +no_defs So some even have 138 duplicates. sqlite> select srid,description from tbl_srs where parameters='+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs'; 3044|ETRS89 / ETRS-TM32 25832|ETRS89 / UTM zone 32N 6707|RDN2008 / UTM zone 32N (N-E) 7791|RDN2008 / UTM zone 32N The parameters of EPSG:25832 exists 4 times. https://trac.osgeo.org/gdal/ticket/4345 looks relevant. With GDAL trunk gdalsrsinfo -e on a EPSG:25832/3044 prj with the projection name changed to unknown finds EPSG:25832 and EPSG:3044 with a confidence of each 90%. I guess we better let the user decide with CRS to use, when we don't find an accurate match. Even if there wouldn't be so many duplicates, the frequency of use may be different for different areas of application and any automatism might still fail and appear as a bug. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) Germany IRC: jef on FreeNode
signature.asc
Description: PGP signature
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
