3

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

I have three layers (two shapefiles, one OpenLayers layer [Bing Maps]) that I am trying to line up located in peninsular Malaysia.

Shapefile_1 is a sub-district border (WGS84; EPSG:4326) Shapefile_2 is river system within the sub-district (GDM2000 Peninsula RSO; EPSG:3375) OpenLayers (set as the ProjectLayer CRS; WGS84 Pseudo Mercator; EPSG:3857)

When importing the layers in QGIS, Shapefile_1 is close to the borders of the sub-district shown in the OpenLayers layer -- but clearly not matched.

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

When the same layers, with the (apparently) same CRS information are displayed in ArcGIS, they line up correctly.

Any insights would be greatly appreciated.

Improve this question
8
  • 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, 2013 at 13:23
  • 2
    Can you insert the content of the .prj files here?
    – AndreJ
    Mar 18, 2013 at 13:40
  • Naresh, yes, on the fly CRS transformation was enabled.
    – Daniel
    Mar 18, 2013 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.
    – AndreJ
    Mar 19, 2013 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, 2013 at 15:08

3 Answers 3

Reset to default
3

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

Improve this answer
2
  • 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, 2013 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.
    – AndreJ
    Mar 20, 2013 at 5:14
2

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

Improve this answer
2
  • 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.
    – AndreJ
    Mar 20, 2013 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.
    – AndreJ
    Mar 20, 2013 at 8:21
0

From trials, the following proj4 seems working. "+proj=omerc +lat_0=0 +lonc=105.236274066667 +alpha=323.0257964666666 +gamma=-36.86989764584402 +k_0=0.99984 +x_0=804671 +y_0=0 +ellps=GRS80 +units=m +no_defs"

If you happen to try it, may i know if it works?

Improve this answer
1
  • It worked "sort of". My final solution was to have a friend who uses ARCgis rewrite the files in a more qgis friendly format
    – Daniel
    Nov 16, 2013 at 3:04

Your Answer

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

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