QGIS » QGIS Application

I believe that the same issue affects also many other projection pairs. The reason is that at least older versions of Proj.4 are using the same definitions for both EPSG-codes.

1. ETRS89 / TM32
   <3044> +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
2. ETRS89 / UTM zone 32N
   <25832> +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>

However, there is a difference in the axis order as can be seen from the EPSG database:

http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3044
http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::25832

The WKT output of 3044 from the EPSG database version 8.7.5 is

PROJCRS["ETRS89 / UTM zone 32N (N-E)",
BASEGEODCRS["ETRS89",
DATUM["European Terrestrial Reference System 1989",
ELLIPSOID["GRS 1980",6378137,298.257222101,LENGTHUNIT["metre",1.0]]]],
CONVERSION["UTM zone 32N",
METHOD["Transverse Mercator",ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,ANGLEUNIT["degree",0.01745329252]],
PARAMETER["Longitude of natural origin",9,ANGLEUNIT["degree",0.01745329252]],
PARAMETER["Scale factor at natural origin",0.9996,SCALEUNIT["unity",1.0]],
PARAMETER["False easting",500000,LENGTHUNIT["metre",1.0]],
PARAMETER["False northing",0,LENGTHUNIT["metre",1.0]]],
CS[cartesian,2],
AXIS["northing (N)",north,ORDER¹],
AXIS["easting (E)",east,ORDER²],
LENGTHUNIT["metre",1.0],
ID["EPSG",3044]]

EPSG:25832 differs only by the AXIS.

This may be a QGIS issue because it is now too clever and do not trust in the code that user gives but instead it is going through the projections it knows and selects the first one that matches the WKT (or +proj or whatever).

It is possible that more recent Proj4 versions include the axis order terms and if GDAL is built with that version and QGIS is progammed to check the axis order then the issue may go away by updating Proj4 and GDAL.

There is a note about the N-E version in the EPSG database:

"Remarks: ETRS89-LCC (CRS code 3034) used for conformal mapping at 1:500,000 and smaller scales. ETRS89-LAEA (CRS code 3035) used for statistical applications at all scales. See ETRS89 / UTM zone 32N (CRS code 25832) for CRS with preferred east-north axis order."

Unfortunately INSPIRE rules require the use of the non-preferred north-east axis order.

Hi,

i agree, that it is not good to let QGIS choose the crs, when the user say, in wich crs the image schould be georeferenced.
That results in projects with non consistant crs.

Please change the behaviour

Gerhard

Actually, doesn't ETRS89 need a datum? The definition says "European Terrestrial Reference System 1989" as datum, the proj4 string only gives

+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Should this need anything like +datum=ETRS89?
Forwarded to https://github.com/OSGeo/proj.4/issues/571

Returned info: it's not a Proj4 problem...

Sorry for boosting this in reference to: #17138

In Europe, more and more cadastral offices and corporations are switching from ArcGIS & MapInfo to QGIS. Since the SRSs between EPSG:25828 and EPSG:25837 are the official ones, many users will run into problems.

I am not experienced enough, to determine wether it is the same source.

In #17138 you have a shape dataset with prj file and qgis recognize the crs not correct. I solve this problem in deleting the prj file and load the shape. Then QGIS ask to the crs and you can choose the right (25832).

In #13398, you say QGIS to reference an image in the wished crs (25832), QGIS ignore your choosen crs and produce a georefeneced image in wrong crs (3044).

In result, QGIS seem to produce/recognize in both issues the same wrong crs (25832 --> 3044 --->User10002).

Issue is still present in 3.1.0-3 (see Mail Paolo Cavallini, QGIS tickets)