Bug report #3632

incorrect reprojection on windows (7), fine on linux

Added by Mathieu Pellerin - nIRV over 13 years ago. Updated over 13 years ago.

Status:Closed
Priority:Low
Assignee:nobody -
Category:Projection Support
Affected QGIS version: Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied: Resolution:invalid
Crashes QGIS or corrupts data: Copied to github as #:13691

Description

There's an on the fly reprojection issue going on with QGIS on windows platform (working fine under linux, untested on mac).

On the windows version of QGIS, a WGS84 datum layer and its Indian 1960 48N datum equivalent fails to project on top of each other, ending up in a +450 meter (!) difference in location. (see screenshot attached)

I've been noticing this for quite some time but didn't find a good way to explain the issue until now.

Steps to reveal issue:
1. Create a new program, set the CRS to UTM Indian 1960 48N and activate on the fly reprojection.
1. Load the raster @ http://licadho-cambodia.org/qgis/ASTGTM_N11E103.zip (it's a simple aster gdem geotiff) into the project
1. Using the gdal's wrap tool, transform the astgm_n11e103_dem.tiff's WGS84 datum to Indian 1960 48N datum
1. Load the generated raster
1. Apply the this colormap (http://licadho-cambodia.org/qgis/bugramp.txt) to both rasters to make it easier to observe the issue

Et voila.

Loading the two rasters into the linux version of QGIS will render just fine.

ontheflyreprojection-wsg84-vs-indian1960_48n.jpg (43.7 KB) Mathieu Pellerin - nIRV, 2011-03-17 12:30 AM

reprojection-issue-vector.jpg (36.5 KB) Mathieu Pellerin - nIRV, 2011-03-19 08:53 PM

reprojection-issue-vector-1point.jpg (21.3 KB) Mathieu Pellerin - nIRV, 2011-03-19 09:20 PM

History

#1 Updated by Mathieu Pellerin - nIRV over 13 years ago

Jef, thanks for the format edit.

If you're running on windows, can you go through the steps to reproduce issue to provide momentum to this critical reprojection flaw?

#2 Updated by Mathieu Pellerin - nIRV over 13 years ago

The problem isn't limited to raster, issue also affecting vectors.

Steps to reveal issue using vectors:

1. Create a new program, set the CRS to UTM Indian 1960 48N and activate on the fly reprojection. 
 1. Load the kml vector @ http://licadho-cambodia.org/qgis/chub.kml into the project 
 1. Using the gdal's ogr2ogr tool, transform the chub.kml (WGS84 datum) to a shapefile (Indian 1960 48N datum) by executing a command like this: ogr2ogr -f "ESRI Shapefile" -overwrite "ogr2ogr-indian196048n.shp" "c:/location/of/your/kml/chub.kml" -T_SRS EPSG:3148 
 1. Load the generated shapefile into your project

Notice the location/projection difference (again +450 meter difference).

#3 Updated by Mathieu Pellerin - nIRV over 13 years ago

BTW, I'm using the ogr2ogr tool above and not qgis' own 'save as...' layer feature as the latter is apparently affected by the same issue described in this ticket and result in improper datum data.

This issue can be reproduced on latest qgis trunk (0697d5ba (SVN r15541)).

I'm sure developers are all extremely busy cooking new features and fixing other bugs. Nevertheless, I feel this ticket should be addressed ASAP, and would appreciate some sort of feedback :)

#4 Updated by Mathieu Pellerin - nIRV over 13 years ago

Re steps using vectors, the chub.kml is a polygon. To further simplify things, I've uploaded a one point kml file (http://licadho-cambodia.org/qgis/1point.kml), feel free to use this instead, should make it much easier to trace the process with only one point to reproject.

#5 Updated by Mathieu Pellerin - nIRV over 13 years ago

  • Resolution set to invalid
  • Status changed from Open to Closed

Marking this bug as invalid. The problem isn't platform specific. QGIS needs to update its SRS definitions.

This new ticket (http://trac.osgeo.org/qgis/ticket/3645) was created.

Also available in: Atom PDF