Opened 13 years ago
Closed 13 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 )
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:
- Create a new program, set the CRS to UTM Indian 1960 48N and activate on the fly reprojection.
- Load the raster @ http://licadho-cambodia.org/qgis/ASTGTM_N11E103.zip (it's a simple aster gdem geotiff) into the project
- Using the gdal's wrap tool, transform the astgm_n11e103_dem.tiff's WGS84 datum to Indian 1960 48N datum
- Load the generated raster
- 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.
Attachments (3)
Change History (10)
by , 13 years ago
Attachment: | ontheflyreprojection-wsg84-vs-indian1960_48n.jpg added |
---|
comment:1 by , 13 years ago
Description: | modified (diff) |
---|
comment:2 by , 13 years ago
comment:3 by , 13 years ago
Platform: | Debian → Windows |
---|
comment:4 by , 13 years ago
The problem isn't limited to raster, issue also affecting vectors.
Steps to reveal issue using vectors:
- Create a new program, set the CRS to UTM Indian 1960 48N and activate on the fly reprojection.
- Load the kml vector @ http://licadho-cambodia.org/qgis/chub.kml into the project
- 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
- Load the generated shapefile into your project
Notice the location/projection difference (again +450 meter difference).
by , 13 years ago
Attachment: | reprojection-issue-vector.jpg added |
---|
comment:5 by , 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 (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 , 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.
by , 13 years ago
Attachment: | reprojection-issue-vector-1point.jpg added |
---|
comment:7 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → 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.
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?