Incorrectly uses epsg:2158 for epsg:25829 prj files

[qgib]

Author Name: Francisco Puga (@fpuga)
Original Redmine Issue: 20048
Affected QGIS version: 3.2
Redmine category:projection_support

---

One of the official spanish crs is EPSG:25829 (ETRS 89, UTM Zone 29) and many downloadable shapefiles for public administrations are in this crs. I attach a sample shape.

The .prj has the following contents:

PROJCS["ETRS_1989_UTM_Zone_29N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-9.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

That matches the definitions provided in "epsgio":http://epsg.io/25829.esriwkt and "spatialreference":http://spatialreference.org/ref/epsg/25829/

But, when loaded into QGIS, EPSG:2158 is incorreclty used. But the .prj that defines EPSG:2158 is different as stated in "epsgio":http://epsg.io/2158.esriwkt and "spatialreference":http://spatialreference.org/ref/epsg/2158/

BTW, when manually selecting EPSG:25829 y Layer Properties -> Source and exported as shp, the same original .prj is created, but the with .qpj the layer can be correctly loaded in EPSG:25829.

---

• _0013_Costa.zip (Francisco Puga)

[qgib]

Author Name: Luigi Pirelli (@luipir)

---

Datums are exactly the same.

PROJCS["ETRS89 / UTM zone 29N",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4258"]],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-9],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
AUTHORITY["EPSG","25829"],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]

PROJCS["IRENET95 / UTM zone 29N",
GEOGCS["IRENET95",
DATUM["IRENET95",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
->>> difference TOWGS84[0,0,0,0,0,0,0], <<<<- difference
AUTHORITY["EPSG","6173"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4173"]],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-9],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
AUTHORITY["EPSG","2158"],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]

[qgib]

Author Name: Jorge Rocha (@jgrocha)

---

The (ESRI) WKT representation of each of the mentioned SRS are:

EPSG:2158, from http://spatialreference.org/ref/epsg/2158/esriwkt/

PROJCS["IRENET95 / UTM zone 29N",GEOGCS["IRENET95",DATUM["D_IRENET95",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

EPSG:25829, from http://spatialreference.org/ref/epsg/etrs89-utm-zone-29n/esriwkt/

PROJCS["ETRS89 / UTM zone 29N",GEOGCS["ETRS89",DATUM["D_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",-9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

We don't know which software was used to produce the shapefile, but the *.prj string is none of the above, but it is more similar to the second (EPSG:25829).

PROJCS["ETRS_1989_UTM_Zone_29N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-9.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

It could be just a problem with the original *.prj string, but it isn't.

The problem with QGIS does exist. Even if we use the "official" SRS WKT for the EPSG:25829, QGIS still uses the EPSG:2158.

To test, download the shapefile, edit the *.prj and paste the above WKT from http://spatialreference.org/ref/epsg/etrs89-utm-zone-29n/esriwkt/. When opened in QGIS, it detects and uses ESPG:2158.

Tested with QGIS 3.3.0-Master, GDAL 2.2.3.

Using the above "official" WKT strings, gdalsrsinfo -e is able to identify correctly both SRS (using the GDAL#14282 fix). With the _0013_Costa.prj file, gdalsrsinfo -e does not identify the SRS.

To reproduce and fix this problem in QGIS SRS detection, I recommend not to use the original *.prj file, but one with the EPSG:25829 WKT representation.

[qgib]

Author Name: Francisco Puga (@fpuga)

---

Thanks for take to time to check it. I'm not sure which software was used to generate the shapefile, but probably is some automated process from ArcGIS Server. The source of the data is http://mapas.xunta.gal/visores/descargas/ -> Series Cartográficas 10.000 (SHP)

[qgib]

Author Name: Francisco Puga (@fpuga)

---

This issue seems to be solved in QGIS 3.6. So the ticket can be closed. ¿Must I close the ticket myself?

Just to add a bit more info if the problem persists this is the versions and repositories i'm using:

$ sudo apt-cache policy qgis
qgis:
  Instalados: 1:3.6.0+git20190309+e4c85cd+28bionic-ubuntugis
  Candidato:  1:3.6.0+git20190309+e4c85cd+28bionic-ubuntugis
  Tabla de versión:
 *** 1:3.6.0+git20190309+e4c85cd+28bionic-ubuntugis 500
        500 https://qgis.org/ubuntugis-nightly-release bionic/main amd64 Packages
        100 /var/lib/dpkg/status
     3.4.5+dfsg-1~exp2~bionic0 500
        500 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu bionic/main amd64 Packages
     2.18.17+dfsg-1 500
        500 http://es.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

$ sudo apt-cache policy gdal-bin
gdal-bin:
  Instalados: 2.4.0+dfsg-1~bionic0
  Candidato:  2.4.0+dfsg-1~bionic0
  Tabla de versión:
 *** 2.4.0+dfsg-1~bionic0 500
        500 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
     2.2.3+dfsg-2 500
        500 http://es.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

$ sudo apt-cache policy proj-bin
proj-bin:
  Instalados: 5.2.0-1~bionic0
  Candidato:  5.2.0-1~bionic0
  Tabla de versión:
 *** 5.2.0-1~bionic0 500
        500 http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
     4.9.3-2 500
        500 http://es.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• resolution was changed from to fixed/implemented
• status_id was changed from Open to Closed