Bug report #20048
Incorrectly uses epsg:2158 for epsg:25829 prj files
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.
History
#1 Updated by Luigi Pirelli about 6 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 about 6 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 about 6 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 over 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 over 5 years ago
- Resolution set to fixed/implemented
- Status changed from Open to Closed