Tell me more ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.
up vote 2 down vote favorite

I am using QGIS 1.9.0 on Linux Mint; and I am new to (Q)GIS

I have three layers (2xshapefiles, 1xopenlayer[Bing Maps]) that I am trying to line up located in peninsular Malaysia.

Shapefile_1 is a subdistrict border (WGS84; EPSG:4326) Shapefile_2 is river system within the subdistrict (GDM2000 Peninsula RSO; EPSG:3375) Openlayer (set as the ProjectLayer CRC; WGS84 Pseudo Mercator; EPSG:3857)

When importing the layers in QGIS, Shapefile_1 is close to the borders of the subdistrict shown in the Openlayer -- but clearly not matched.

Shapefile_2 is incorrectly located hundreds of kilometers north east off the coast.

Whe the same layers, with the (apparently) same CRC information are displayed in ARCGIS, they line up correctly.

Any insights would be greatly appreciated.

share|improve this question
1  
Did you enable on the fly transformation in QGIS? Its a small button (globe looking) in bottom right corner of QGIS (CRS status if you mouse over). The top option is 'enable on the fly' CRS transformation. Enable it and check again. – Naresh Mar 18 at 13:23
2  
Can you insert the content of the .prj files here? – Andre Joost Mar 18 at 13:40
Naresh, yes, on the fly CRS transformation was enabled. – Daniel Mar 18 at 21:29
1  
The prj for shapefile_2 is also in WGS84; that won't help. Was the original shapefile without prj-file? It would help if you could put the whole shapefile_2 zipped in the dropbox. – Andre Joost Mar 19 at 12:21
1  
The original shapefile was without a prj-file. Here is the .shp file and the .shx for shapefile_2 – Daniel Mar 19 at 15:08
show 3 more comments

2 Answers

up vote 2 down vote

I'm afraid you are lost with your Malaysian data with QGIS and any other software depending on GDAL and proj. Here is some reading:

http://osgeo-org.1560.n6.nabble.com/RSO-gamma-and-Hotine-Oblique-Mercator-Variant-A-td3841370.html

http://trac.osgeo.org/proj/ticket/104

http://trac.osgeo.org/gdal/ticket/4910

The difficult thing is the omerc projection, which does not use a simple meridian as origin, but a line with an angle to its prime meridian. There are two different versions on how to rotate the data to the line, and rotate back in the end to have north up. Both are defined in proj by a +no_uoff parameter. Unfortunately, this has been lost somewhere between proj, GDAL, ogr2ogr and QGIS (see the last ticket).

EDIT

Still something is working, but NOT inside QGIS:

I installed the latest dev version of GDAL from gisinternals, and reprojected the shapefile with the following :

ogr2ogr -s_srs epsg:3375 -t_srs epsg:4245 Malay-Kertau.shp rivers.shp

I first tried with WGS84, but got the offset you mentioned. EPSG:4245 is an older datum used in Malaysia. This is what i got, against Google Physical background:

enter image description here

share|improve this answer
Thank you very much for your insight and work! This is not good news for me, but at least I better understand the issue. Do you know why ARCGIS handles the original shapefiles seamlessly? – Daniel Mar 19 at 23:58
Simple answer: ARCGIS does not use GDAL ;-( And they have more man-power and money to solve any problem. I guess there are not enough people in the QGIS world that get stuck with your rather exotic CRS problem. – Andre Joost Mar 20 at 5:14
up vote 1 down vote

I corresponded with Hilmy Hashim about the question I raised. He was the author of one of the links Andre Joost cited. Hilmy had written about the issue and the answer here.

His reverse engineered, custom CRC was:

+proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.013286728 +gamma=323.07483685 +k=0.99984 +x_0=472830.426 +y_0=442454.099 +ellps=GRS80 +units=m +no_defs

The results are better than when I started, but still off. The river from one of my shapefiles is in red, and offset from the google layer.

enter image description here

share|improve this answer
I would suggest to try the latest GDAL builds which might have solved the problem. Perhaps you and Hilmy might find a developer who can locate the error inside the QGIS toolchain. For smaller shifts, try to play with +towgs84 parametres. – Andre Joost Mar 20 at 5:17
A highly accurate solution would be to create a nadgrid file for Malaysia from known coordinates as proposed here: lists.maptools.org/pipermail/proj/2013-January/006531.html. But that is a lot of work, and should be done by the local community together. – Andre Joost Mar 20 at 8:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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