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. I need help figuring out if I've missed something - Or if the program is or isn't working as designed. To duplicate my issue:

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.

Is it me or the program? Has QGIS always done this? In any event, the transparent and unintended datum shift in the map readout could cause some serious confusion.

  • 1
    Do you have the 'on the fly" CRS transformation feature on?
    – sig_renato
    Commented Feb 19, 2016 at 0:36
  • 1
    Change the canvas CRS should be ok, but Change the shapefile CRS using Set Layer CRS will corrupt your data. Use ` Save As ...` instead.
    – AndreJ
    Commented Feb 19, 2016 at 6:46
  • I do have OTFT turned on. In fact I have to enable OTFT to project the map. Then if I disable OTFT I do get the correct DMS readout, because the map CRS reverts back to GCS Camacupa. In other words the map is no longer projected. If I leave OTFT enabled the map is properly projected, but the DMS readout is untintentionally transformed to WGS84. And WGS84 is not referenced by the map or the layer.
    – charliec
    Commented Feb 20, 2016 at 6:55
  • I realize that in QGIS the CRS has to be assigned when the shapefile is created (as it was for the 1st test), or when it is created from another shapefile using a Save As (as it was for the 2nd test). Any other actions can cause problems as you indicate.
    – charliec
    Commented Feb 20, 2016 at 7:11

1 Answer 1


What it sounds like to me is you're trying to set the CRS without creating a new shapefile. Select the layer that you want to change the CRS. Right click and select "Save Vector Layer as..." FORMAT: ESRI Shapefile. SAVE AS: Your new Filename. CRS: your reference datum (Camacupa / UTM zone 33S). Select "Add saved file to map" and select "OK". This will permanently change the CRS so it won't revert back to its original CRS.

  • Thanks - For the 2nd and 3rd tests I created new shapefiles (from scratch or through Save As), and did not attempt to modify their CRSs while performing the map CRS and readout tests. Good advice though. Doing otherwise without making sure that the shapefile coords and the CRS are compatible can be disastrous.
    – charliec
    Commented Feb 20, 2016 at 7:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.