[Proj] RSO, +gamma and Hotine Oblique Mercator Variant A
Mikael Rittri
Mikael.Rittri at carmenta.com
Thu Apr 28 03:03:58 EST 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
More information about the Proj
mailing list