[Proj] RSO, +gamma and Hotine Oblique Mercator Variant A

Thu Apr 28 01:03:58 PDT 2011

Hello Hilmy!

> my apologies for bringing up this Malayan Monster again.

The Malayan Monster has at least three heads, and sometimes
they grow back after they have been chopped off. ;-) 

1) To get variant A of Hotine Oblique Mercator, the 
   proj.4 omerc definition must include the +no_uoff flag. 
   This flag is missing from the epsg file in proj 4.7.0
   and the trunk, but I think it was present in proj 4.6.1.
   This should explain the large offset along the initial
   line that you observed. I have now opened a ticket on 
   this: http://trac.osgeo.org/proj/ticket/104

2) The +gamma parameter was added to proj.4 fairly 
   recently, in March 2010, so I don't think it is 
   supported in proj 4.7.0, only in the trunk.  
   But I don't know what version of proj.4 is 
   used by Quantum GIS and Postgis.  
       I think the difference between supported 
   and unsupported +gamma could be hard to see on
   the small-scale maps you attached, but it may 
   be visible if you zoom in on the area where 
   you also have cadastral data in Cassini-Soldner. 

   You wrote:
   > In QGis, versions 1.6 and up in OSGeo4W, the 
   > default proj.4 string for EPSG:3168 and EPSG:3375 
   > is without the +gamma parameter, so the projection
   > is not correct.

   Not necessarily. With older versions of proj.4, 
   you can implement the Malaysian instances of Hotine 
   Oblique Mercator by adding the +rot_conv flag. This 
   flag does not take a numerical value as +gamma does, 
   it just says:
       "The +gamma differs from +alpha, and +gamma 
        cannot be specified, but I know that this 
        projection is designed for a part of Malaysia."
   (I am not sure what happens if you would specify 
    both +rot_conv and a value for +gamma.)

3) You will need a datum shift as well, in the form
   of +towgs84 parameters.  These are often missing
   in proj's epsg file, for various reasons.  

   - For the new datum, GDM2000, use 

       +towgs84=0,0,0

   This datum shift is missing from EPSG for some reason 
   (and therefore missing in proj's epsg file), but it 
   follows from the Anchor Definition of the datum,
   which EPSG describes as "ITRF 2000, epoch 2000.0",
   meaning the datum is equivalent to WGS84 except for 
   the tectonic motions since 2000.

   - For the datum Kertau(RSO) for West Malaysia, use 

       +towgs84=-11,851,5

   which can be derived from the EPSG datum shift 
   "Kertau (RSO) to WGS 84 (1)", EPSG:8659. The EPSG
   represents this as a concatenated shift via "Kertau 1968",
   which explains why it is missing in proj's epsg file.
   (Well, in the proj.4 trunk, this shift is used for the
    "Kertau 1968" datum, but not for the "Kertau(RSO)" datum;
    I must say I don't quite understand the reasons for
    distinguishing these two datums.) 
   (In fact, the EPSG Remarks for the concatenated shift
    seem to imply that it cannot be represented as a single
    datum shift, but I think that's just wrong. 
    See also http://trac.osgeo.org/proj/ticket/38 ) 
   But note that the accuracy of this datum shift is said
   to be only about 15 meters.  I suspect Malaysian authorities
   know better datum shifts, but maybe they are classified
   or proprietary.

   - For the datum Timbalai 1948 for East Malaysia, use 

       +towgs84=-533.4,669.2,-52.5,0,0,4.28,9.4

   This is the shift "Timbalai 1948 to WGS 84 (4)", EPSG:1852,
   which is said to have accuracy of 5 meters, at least offshore.
   It also occurs in proj's epsg file in the trunk, but not
   in 4.7.0 I think. 

Hope this helps,

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com

________________________________

From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of Hilmy Hashim
Sent: den 9 april 2011 13:55
To: proj at lists.maptools.org
Subject: [Proj] RSO, +gamma and Hotine Oblique Mercator Variant A

Hi, 

This issue has been discussed many times before, so I'm trying to assess the current situation.

I'm a new user of Quantum GIS and Postgis which I understand uses Proj.4 for projections. I'm working with the RSO projection for Peninsular Malaysia both old and new definitions (EPSG:3168 and EPSG:3375). From my readings on various lists, RSO for Malaysia requires the +gamma parameter and the projection method is now classified by epsg-registry.org <http://epsg-registry.org/>  as EPSG:9812 Hotine Oblique Mercator (Variant A). This means that the final rotation applied is at the natural origin as opposed to the center of projection which is Variant B (EPSG:9815)

In QGis, versions 1.6 and up in OSGeo4W, the default proj.4 string for EPSG:3168 and EPSG:3375 is without the +gamma parameter, so the projection is not correct. Looking at the OSGeo4W\share\proj\epsg file, gamma is indeed defined in there. So I'm confused where QGis srs.db is getting it's information from.

Creating a custom CRS in QGis with +gamma seems to have an effect, so the latest omerc.c does take into account the gamma parameter. However, the projection is still not quite correct. It looks like it is correctly aligned to north, but the x and y translation is off and I surmised that this has to do with the final center of rotation. I did an empirical correction with x_0 = false_easting + Uc sin(gc) and y_0 = false_northing + Uc cos(gc) approximately I think. Attached is a diagram of a comparison I did with different parameters. C is approximately the correct projection with a cadaster layer in EPSG:3384 overlayed at the bottom.

As proj.4 is used by many applications, my question is how and where can I get the projection parameters for RSO Malaysia corrected and how can the omerc projection be made to use variant A. I am advising a state government to standardize on QGis and PostGIS so there will be many users.

Thank you for any help  and my apologies for bringing up this Malayan Monster again.

Hilmy
Hilmy