Bug report #13997
Unintended datum shift to WGS84 in map canvas
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Map Canvas | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Win 7x64 | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | end of life |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 22011 |
Description
I'm a new QGIS user running 2.12 Lyon. I've encountered an issue with map canvas units and an unexpected and transparent datum transformation to WGS84 - To duplicate:
1st test:
- Create a point shapefile with a point at Lon: 12 00 00.000 E Lat: 06 30 00.000S - select CRS GCS Camacupa.
- Add it to a new project, which will take CRS GCS Camacupa by default.
- Change the map canvas units to DMS, which obtains the original Lon/Lat values for the point.
- Change the map CRS to PCS Camacupa / UTM zone 33S, which obtains the correct values for Camacupa / UTM zone 33S: X: 168151.91 mE Y: 9280605.47 mN.
- Now change the map canvas units to Degrees, Minutes, Seconds (needs at least two tries, but does work), which obtains values in WGS84: Lon: 06 30 05.370E Lat: 11 59 49.278S. (Externally verified). The GCS default datum transformation parameters are used.
2nd test:
- Reproject the layer itself to Camacupa / UTM zone 33S, add the layer to a new map, and change the map canvas units to DMS, which again obtains values in WGS84.
3rd test:
- Change the shapefile GCS to WGS84 and add it to a Camacupa / UTM zone 33S map. A datum shift is performed and the resulting Camacupa XYs are correct. Change the units to DMS and the readout reverts to WGS84.
These and other tests of this behavior seem to indicate that if the projected map GCS references a local datum such as Camacupa, the Degree or DMS projected map readout will be transparently transformed to WGS84.
My expectation is that the projected map canvas unit Degree or DMS readout would reflect the project CRS GCS.
If the program is only intended to provide the correct Lon/Lat coordinates when the map is de-projected, then it should not allow a Degree or DMS readout to be selected when the map is projected.
Better yet, it should allow a Degree or DMS readout to be selected for a projected map, and should not perform the shift to WGS84.
History
#1 Updated by Charles Clancy almost 9 years ago
Update:
This transparent and unintended datum shift in the map readout could cause some serious confusion.
#2 Updated by Charles Clancy almost 9 years ago
Clarification:
The layer CRSs were not changed during the map CRS and readout tests. The layer CRSs were assigned when the layers were created from scratch, or selected in a Save As step.
#3 Updated by Nyall Dawson almost 9 years ago
- Status changed from Open to Feedback
Please retest with current master. There's been related changes which may have fixed this
#4 Updated by Charles Clancy almost 9 years ago
OK - Thanks.
I'm not sure what I should download. Should I wait until QGIS 2.13 or 2.14 shows up on https://www.qgis.org/en/site/forusers/download.html - in a week or so? Or should I download something else now, such as OSGeo4W?
#5 Updated by Nyall Dawson almost 9 years ago
See instructions here: https://www.qgis.org/en/site/forusers/alldownloads.html#windows
MUCH better to quickly test with the development version prior to release. If there's a valid bug which can be fixed, we'd rather catch it prior to 2.14 if possible.
#6 Updated by Charles Clancy over 8 years ago
- File QGIS_wgs84_unintended.jpg added
OK - I updated to 2.13.0-Master on 21 Feb 2016 at 13:27 PST. I repeated the 1st test from scratch. The Coordinate Display settings interface is better and applies the option more smoothly. But the unintended shift to WGS84 when the map is projected is still performed when the readout is degrees in any format.
#7 Updated by Giovanni Manghi over 8 years ago
- Status changed from Feedback to Open
- Affected QGIS version changed from 2.12.0 to master
#8 Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#9 Updated by Giovanni Manghi over 5 years ago
- Resolution set to end of life
- Status changed from Open to Closed
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/