(regression) QGIS 1.7.* misdetects EPSG::25884 datasets as EPSG::2100

[qgib]

Author Name: marisn - (marisn -)
Original Redmine Issue: 5066
Affected QGIS version: master
Redmine category:projection_support

---

When adding a vector dataset (shapefile) with correct PRJ file listing it's CRS as ETRS89/TM Baltic93 (EPSG::25884), it gets set as a layer CRS a Greek grid (EPSG::2100). Reprojecting such data results in ~300m shift for all features. If user digitizes data without realizing that QGIS has misdeteced it's CRS, it results in storing of wrong data!

Workaround: when adding every vector dataset, user has to check if QGIS has detected CRS correctly and in the case of detection like Greek grid, to set correct CRS manually.

Tested versions: QGIS 1.7.2 and 1.7.4 on MS-Windows.
Current git master on Linux just detects same shapefile (created with QGIS) to have "generated" CRS and thus is reprojected correctly.

Attaching a sample shapefile and a project file where the wrong detected CRS is visible.

---

• Baltic_93tm.zip (marisn -)
• estonia_generalized.zip (marisn -)

---

Related issue(s): #14764 (relates), #15172 (relates)
Redmine related issue(s): 4977, 5598

---

[qgib]

Author Name: marisn - (marisn -)

---

#14833 could be a related issue.

---

• operating_system was changed from to Windows
• fixed_version_id was configured as 35
• version was changed from master to 1.7.4

[qgib]

Author Name: marisn - (marisn -)

---

Just checked that 1.6.0 is not affected. Due this issue, we are keeping our GIS labs on 1.6.0 release, as EPSG:25884 is the most used coordinate system in our university.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

tagging this as a regression

---

• priority_id was changed from High to 6
• subject was changed from QGIS 1.7.* on Windows misdetects EPSG::25884 datasets as EPSG::2100 to (regression) QGIS 1.7.* on Windows misdetects EPSG::25884 datasets as EPSG::2100

[qgib]

Author Name: marisn - (marisn -)

---

Just tested 1.7.4 on Linux and found out that it suffers from the same issue.

---

• subject was changed from (regression) QGIS 1.7.* on Windows misdetects EPSG::25884 datasets as EPSG::2100 to (regression) QGIS 1.7.* misdetects EPSG::25884 datasets as EPSG::2100
• operating_system was changed from Windows to

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

marisn - wrote:

Just tested 1.7.4 on Linux and found out that it suffers from the same issue.

The problem also does relate to a change in GDAL were most of the +datum= parameters were dropped and +towgs84= parameters were inserted. QGIS now ignores +datum=, if there's no match found.

EPSG:25884 and EPSG:2100 are only different by +towgs84 parameter:

$ gdalsrsinfo -o proj4 Baltic_93TM_QGIS_test.prj 
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +units=m +no_defs '
$ gdalsrsinfo -o proj4 epsg:25884
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '
$ gdalsrsinfo -o proj4 epsg:2100
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=-199.87,74.79,246.62,0,0,0,0 +units=m +no_defs '

WKT of the shape:

PROJCS["ETRS89_TM_Baltic93",
    GEOGCS["GCS_ETRS89",
        DATUM["ETRS_1989",
            SPHEROID["GRS_1980",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",24],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

I don't know when (and why) +datum was removed from gdal output of proj.4 strings, but the problem here is that .prj files do not have +towgs84 parameters.

In gdal 1.9 this can be fixed with the config option GDAL_FIX_ESRI_WKT=TOWGS84
see "OGRSpatialReference::morphFromESRI()":http://www.gdal.org/ogr/classOGRSpatialReference.html#ad556dfdc04d9ec5f1714fc6b5e0eb6a6 and "GDAL !#14282":http://trac.osgeo.org/gdal/ticket/4345

$ GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo -o proj4 Baltic_93TM_QGIS_test.prj
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '

Perhaps this config option could be added to the GGis environment? How does master deal with this problem?

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

Fixed in changeset "2f135c1d630f0f96422547c31a05c38d41997470".

---

• status_id was changed from Open to Closed

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• fixed_version_id was changed from 35 to Version 1.8.0

[qgib]

Author Name: marisn - (marisn -)

---

Unfortunately issue is back in master.

1.9.0-Master
QGIS code revision 078f5b8

Running GDAL 1.8.1

---

• status_id was changed from Closed to Reopened
• version was changed from 1.7.4 to master
• fixed_version_id was changed from Version 1.8.0 to Version 2.0.0

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

marisn - wrote:

Unfortunately issue is back in master.

1.9.0-Master
QGIS code revision 078f5b8

Running GDAL 1.8.1

This should be fixed with GDAL 1.9 (see the commit)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• status_id was changed from Reopened to Feedback

[qgib]

Author Name: marisn - (marisn -)

---

It's still an issue for some datasets.
Attached dataset was created by exporting from GRASS GIS. Data are in EPSG:25884, still QGIS autodetects it as EPSG:2100

gdalsrsinfo estonia_generalized.prj 

PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +units=m +no_defs '

OGC WKT :
PROJCS["Transverse_Mercator",
    GEOGCS["GCS_grs80",
        DATUM["unknown",
            SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",24],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

---

• 4836 was configured as estonia_generalized.zip

---

• estonia_generalized.zip (marisn -) - Map of Estonia in EPSG:25884

[qgib]

Author Name: marisn - (marisn -)

---

Forgot to add version information:

QGIS versija 1.9.0-Master
QGIS code revision ad437bf
Compiled against GDAL/OGR 1.9.1
Running against GDAL/OGR 1.9.1

Also fix only for OGR >1.9.x is unacceptable, as due to QGIS + OGR layer encoding issues, it's not possible to read/write shapefiles with GDAL/OGR 1.9.x (yes, shapefile encoding still doesn't work at all when QGIS runs with GDAL/OGR 1.9.1!) and thus GDAL/OGR 1.8.x is the only option for many QGIS users.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

marisn - wrote:

Forgot to add version information:

QGIS versija 1.9.0-Master
QGIS code revision ad437bf
Compiled against GDAL/OGR 1.9.1
Running against GDAL/OGR 1.9.1

Also fix only for OGR >1.9.x is unacceptable, as due to QGIS + OGR layer encoding issues, it's not possible to read/write shapefiles with GDAL/OGR 1.9.x (yes, shapefile encoding still doesn't work at all when QGIS runs with GDAL/OGR 1.9.1!) and thus GDAL/OGR 1.8.x is the only option for many QGIS users.

not sure, but aren't both gdal issues?

[qgib]

Author Name: marisn - (marisn -)

---

Giovanni Manghi wrote:

not sure, but aren't both gdal issues?

Well. No. They both are QGIS issues triggered by changes in GDAL/OGR/Proj. GDAL/OGR doesn't mandate EPSG code to operate on datasets. I don't know if it's QGIS doing the wrong guess or GDAL/OGR, still end result is clear - QGIS uses wrong CRS, OGR tools use right one. As long as QGIS was using just datasets .prj file contents, it was fine.

Here's example how to check it:

ogr2ogr -s_srs epsg:2100 -t_srs epsg:4326 est_gre.shp estonia_generalized.shp
ogr2ogr -s_srs epsg:25884 -t_srs epsg:4326 est_bal.shp estonia_generalized.shp
ogr2ogr -t_srs epsg:4326 est_raw.shp estonia_generalized.shp

Compare output. est_bal equals est_raw, est_gre is shifted by ~200m. Conclusion - ogr2ogr uses right CRS for provided file.

As goes for encoding issues - I'm fed up with them. It's still not possible to specify correct encoding in layer preferences or when adding vector dataset AND get data in specified encoding. Pointing out that there are also issues on QGIS side is threated like blasphemy. Still most likely I will reopen bugs when GDAL/OGR 1.9.2 will come out and issue will still exist.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Pointing out that there are also issues on QGIS side is threated like blasphemy.

I'm sorry but you are plain wrong. If you check you will see I'm the top bug reporter (or the second one, anyway I'm the top one in the last 3 years) -> I have no interest in not reporting a QGIS bug, on the other hand I'm very interested in hunting any possible bug.

Here the point is to keep the tracker as clean as possible, avoiding to have open tickets that are not right/necessary and eventually redirecting the issue upstream to other projects trackers.

Still most likely I will reopen bugs when GDAL/OGR 1.9.2 will come out and issue will still exist.

I have no reason to not believe you, anyway we will see as soon as qgis will be compiled against gdal 1.9.2

In any case if the latest gdal version available has the issue described here fixed, I don't understand why this should be left open. But anyway I will leave the last word to someone else.

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

marisn - wrote:

As long as QGIS was using just datasets .prj file contents, it was fine.

That's part of the problem. QGIS doesn't use the .prj directly and AFAIK never did. It only uses it to find a match in the srs.db and actually use the projection defined there.

And finding that match became more complex after the GDAL change, because the datum parameter was dropped from GDAL and replaced with the towgs84 parameter. And therefore QGIS would fail to recognize those as there wasn't an exact match anymore and in turn produce a user CRS. So people started to complain about user CRSs instead of EPSG CRSs. So the detection was relaxed a bit by ignoring the @+datum@ parameter, if there's no match otherwise.

Unfortunately there are some CRSs that are only different by the datum parameter - the above two being one of those pairs. And QGIS did pick the first hit even if there are more than one.

42a9d01 changes that. So now, QGIS produces a user crs for @estonia_generalized.shp@ now. BTW @Baltic_93TM_QGIS_test.shp@ still worked for me. Still a compromise and hopefully not one that breaks other things.

As goes for encoding issues - I'm fed up with them.

Welcome to the club.

It's still not possible to specify correct encoding in layer preferences or when adding vector dataset AND get data in specified encoding. Pointing out that there are also issues on QGIS side is threated like blasphemy.

"threated" should have been "treated", shouldn't it? No one is threatening anyone, right?

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• status_id was changed from Feedback to Closed
• resolution was changed from to fixed