[QGIS-Developer] QGIS3: reminder of an annoying bug

Jürgen E. Fischer jef at norbit.de
Sat Jan 20 09:05:33 PST 2018


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180120/418eb59c/attachment-0001.sig>


More information about the QGIS-Developer mailing list