Bug report #13398
Georeferencer produce images in wrong crs in 2.10 and master
Status: | Open | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | C++ plugins/Georeferencer | ||
Affected QGIS version: | 3.7(master) | Regression?: | No |
Operating System: | windows | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 21450 |
Description
in QGIS 2.6.1, georeferencing results (tif-images) are correct produced in the choosen crs.
In 2.10 and master, georeferencing in EPSG 25832 results in a tif georeferenced in crs EPSG 3044.
You have also now two steps to bring QGIS to start georeferencing work. First click on the icon starting the referencing work, results in a popup mask asking for the transformation type, although p.e. "helemert" ist preconfigured. Give all information into the mask, press OK button and nothing happens. Then you have to click the button for starting referencing work again to do the output process. (in 2.6.1, referecing work starts by click on OK in the first mask)
Projects with data in 2.6.1 and 2.11 are attached as zip-archiv
Related issues
History
#1 Updated by Jukka Rahkonen about 9 years ago
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.
- ETRS89 / TM32
<3044> +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <> - 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,ORDER1],
AXIS["easting (E)",east,ORDER2],
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.
#2 Updated by Gerhard Spieles about 9 years ago
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
#3 Updated by Giovanni Manghi almost 9 years ago
- Target version deleted (
Version 2.12)
#4 Updated by Giovanni Manghi over 7 years ago
- Affected QGIS version changed from 2.10.1 to 2.18.4
- Priority changed from High to Normal
#5 Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#6 Updated by Tobias Wendorff about 7 years ago
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
#7 Updated by Tobias Wendorff about 7 years ago
Returned info: it's not a Proj4 problem...
#8 Updated by Tobias Wendorff almost 7 years ago
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.
#9 Updated by Giovanni Manghi almost 7 years ago
- Description updated (diff)
- Status changed from Open to Feedback
Tobias Wendorff wrote:
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.
aren't this and #17138 the same (the source of the issue seems the same)?
#10 Updated by Gerhard Spieles almost 7 years ago
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).
#11 Updated by Jürgen Fischer almost 7 years ago
- Duplicated by Bug report #17440: EPSG 25832 tiffs added
#12 Updated by Gerhard Spieles over 6 years ago
Issue is still present in 3.1.0-3 (see Mail Paolo Cavallini, QGIS tickets)
#13 Updated by Giovanni Manghi over 6 years ago
- Affected QGIS version changed from 2.18.4 to 3.1(master)
#14 Updated by Jürgen Fischer over 5 years ago
- Resolution set to no timely feedback
- Status changed from Feedback to Closed
Bulk closing 82 tickets in feedback state for more than 90 days affecting an old version. Feel free to reopen if it still applies to a current version and you have more information that clarify the issue.
#15 Updated by Gerhard Spieles over 5 years ago
- Resolution deleted (
no timely feedback) - Status changed from Closed to Reopened
- Affected QGIS version changed from 3.1(master) to 3.7(master)
Issue is not solved and present in master.
#16 Updated by Giovanni Manghi over 5 years ago
- Status changed from Reopened to Open