Bug report #20048

Incorrectly uses epsg:2158 for epsg:25829 prj files

Added by Francisco Puga over 5 years ago. Updated about 5 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Projection Support
Affected QGIS version:3.2 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:27870

Description

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 and spatialreference

But, when loaded into QGIS, EPSG:2158 is incorreclty used. But the .prj that defines EPSG:2158 is different as stated in epsgio and spatialreference

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 (238 KB) Francisco Puga, 2018-10-08 01:55 PM

History

#1 Updated by Luigi Pirelli over 5 years ago

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]]

#2 Updated by Jorge Rocha over 5 years ago

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#4345 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.

#3 Updated by Francisco Puga over 5 years ago

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)

#4 Updated by Francisco Puga about 5 years ago

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

#5 Updated by Giovanni Manghi about 5 years ago

  • Resolution set to fixed/implemented
  • Status changed from Open to Closed

Also available in: Atom PDF