Opened 12 years ago

Closed 12 years ago

#3632 closed bug (invalid)

incorrect reprojection on windows (7), fine on linux

Reported by: nirvn Owned by: nobody
Priority: critical: causes crash or data corruption Milestone: Version 1.7.0
Component: Projection Support Version: Trunk
Keywords: Cc:
Must Fix for Release: Yes Platform: Windows
Platform Version: Awaiting user input: no

Description (last modified by jef)

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.
  2. Load the raster @ (it's a simple aster gdem geotiff) into the project
  3. Using the gdal's wrap tool, transform the astgm_n11e103_dem.tiff's WGS84 datum to Indian 1960 48N datum
  4. Load the generated raster
  5. Apply the this colormap ( 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.

Attachments (3)

ontheflyreprojection-wsg84-vs-indian1960_48n.jpg (43.7 KB ) - added by nirvn 12 years ago.
reprojection-issue-vector.jpg (36.5 KB ) - added by nirvn 12 years ago.
reprojection-issue-vector-1point.jpg (21.3 KB ) - added by nirvn 12 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by jef, 12 years ago

Description: modified (diff)

comment:2 by nirvn, 12 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?

comment:3 by nIRVn, 12 years ago

Platform: DebianWindows

comment:4 by nirvn, 12 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.
  2. Load the kml vector @ into the project
  3. 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
  4. Load the generated shapefile into your project

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

by nirvn, 12 years ago

comment:5 by nirvn, 12 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 (r15540).

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 :)

comment:6 by nirvn, 12 years ago

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

comment:7 by nirvn, 12 years ago

Resolution: invalid
Status: newclosed

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

This new ticket ( was created.

Note: See TracTickets for help on using tickets.