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

[Hilmy Hashim]

Mikael,

Thanks very much for a very clear definition of the problem. Indeed, the
Malayan Monster has many heads! And thank you for submitting the ticket. I
hope Frank can do something about it.

I have seen the  +no_uoff flag mentioned but I didn't see it used in omerc.c
trunk. I started using qgis from 1.6 for my current project but I now prefer
to use 1.7-dev.

In qgis 1.7, the +gamma parameter is absent from the main projections list,
but if I add it in as a custom crs, it does have an effect. see my diagram
B previously. So I assume qgis 1.7 on OSGeo4W uses the latest proj4 build,
whatever that is - the shell say Rel. 4.7.1, 23 September 2009. This is
another head of the monster, qgis srs.db which holds the proj4 strings, is
not synced to the latest gdal espg database, which has the gamma parameter
included.

Again, thanks for responding.

Regards

*Hilmy*


On Thu, Apr 28, 2011 at 4:03 PM, Mikael Rittri
<Mikael.Rittri at carmenta.com>wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20110428/5db5e41e/attachment.html>