Hello, I just noticed that this issue apparently also surfaces when opening projects from QGIS 2.18 in QGIS 3.0
E.g. a project with the CRS set to 25833 (ETRS89/UTM zone 33N) in 2.18 will open with CRS 3006 (SWEREF99 TM) in the current QGIS 3.0. Kind regards, Daan 2018-01-20 18:05 GMT+01:00 Jürgen E. Fischer <[email protected]>: > 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 > > _______________________________________________ > 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 _______________________________________________ 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
