Oblique Mercator vs. Hotine Oblique Mercator

[crschmidt]

From ​http://lists.osgeo.org/pipermail/metacrs/2008-December/000185.html:

• EPSG:2056, "CH1903+ / LV95"
• EPSG:2057, "Rassadiran / Nakhl e Taqi"
• EPSG:21780, "Bern 1898 (Bern) / LV03C"
• EPSG:21781, "CH1903 / LV03"
• EPSG:23700, "HD72 / EOV"
• EPSG:29700, "Tananarive (Paris) / Laborde Grid",
• EPSG:29702, "Tananarive (Paris) / Laborde Grid approximation"
• EPSG:29871, "Timbalai 1948 / RSO Borneo (ch)"
• EPSG:29872, "Timbalai 1948 / RSO Borneo (ft)"
• EPSG:29873, "Timbalai 1948 / RSO Borneo (m)"

According to EPSG, all these use the projection method "Oblique Mercator", coord op method 9815. But on SpatialReference.org, these ten CRSs are given the projection method "Hotine_Oblique_Mercator", which is a different method (coord op method 9812). It is true that each instance of "Oblique Mercator" can be reformulated as an instance of "Hotine Oblique Mercator", but this requires that you adjust the False Easting and False Northing, which has not been done. EPSG Guidance Note 7.2 gives the example of "Timbalai 1948 / R.S.O. Borneo (m)", which has

• Easting at projection centre (EC) = 590476.87 metres
• Northing at projection centre (NC) = 442857.65 metres

This can be reformulated as an instance of "Hotine Oblique Mercator", but only if you adjust these parameters to

• False easting (FE) = 0.0 metres
• False northing (FN) = 0.0 metres

Note also that some CRSs in the ESPG database do use "Hotine Oblique Mercator", so it is no solution to just replace "Hotine_Oblique_Mercator" by "Oblique_Mercator" everywhere. The two coord op methods must be distinguished.

[Even Rouault]

Other (possibly) related tickets : #3038 and #3311

[Even Rouault]

Linked to ​http://trac.osgeo.org/proj/ticket/104

Related discussion in ​http://osgeo-org.1803224.n2.nabble.com/RSO-gamma-and-Hotine-Oblique-Mercator-Variant-A-td6256795.html

[warmerdam]

OK, I have added a differentiation (r24091) between the two oblique mercator variants. The one that requires +no_uoff keeps the name "Hotine_Oblique_Mercator" while variant "b" is given the WKT name "Oblique_Mercator".

Updates made to PROJ.4 translation also. Note that there are some special variations for Swiss Oblique Mercator and RSO variant. I have duplicated this logic between the OM and HOM cases for now, not knowing what would be minimal.

Still not addressed issues include:

• Support for Oblique Mercator in the GeoTIFF code (likely needs a new geotiff code for oblique mercator)
• Translation to/from ESRI format. I'm not sure how these are described in ESRI.

This should also likely be addressed for other projections formats (PCI, USGS, etc) though those aren't so critical.

[warmerdam]

We also need to update the GeoTIFF "projection list" pages for hotine oblique mercator and oblique mercator.

[mikrit]

Just want to remind you that these two projection methods have officially changed names (EPSG names, that is). It happened in EPSG Guidance Note 7.2, in the version that was published in November 2010.

"Hotine Oblique Mercator" -> "Hotine Oblique Mercator (variant A)"

"Oblique Mercator" -> "Hotine Oblique Mercator (variant B)"

The new names make it more clear that the projection methods are very closely related. But it is still hard to remember which is which. Actually, I think I would prefer the ESRI names, but I am not quite sure what they are, and I fear that there is no one-to-one correspondence between the ESRI definitions and the EPSG ones (I think Norm Olsen would know more about that).

In any case, I think it may be a bad idea to use the old EPSG names. Except for backwards compatibility, of course. It's worth thinking about, at least.

[warmerdam]

I have reviewed the ESRI PE strings I got from Melita a while ago and I see they use Hotine_Oblique_Mercator_Azimuth_Center for HOM Variant B.

I have changed GDAL/OGR to do the same (r24323, r24324). I still need to update the GeoTIFF driver in some way to distinguish.

[mikrit]

Yes, I think so, and HOM Variant A is known as Hotine_Oblique_Mercator_Azimuth_Natural_Origin in ESRI. But I believe these two ESRI projections don't take the parameter

Angle from Rectified to Skew Grid

(or Rectified Grid Angle = gamma), so it is implicitly equal to the Azimuth.

When the Rectified Grid Angle differs from the Azimuth (which happens in Malaysia only, I think), ESRI seems to use the projection name

Rectified_Skew_Orthomorphic_Natural_Origin

For completeness, I guess there should also be something like Rectified_Skew_Orthomorphic_Azimuth_Center or perhaps just Rectified_Skew_Orthomorphic_Center, but I am not sure if there is any need for that; maybe no such combination occurs in real life. I haven't seen an example yet.

It seems the Rectified Grid Angle parameter is called XY_Plane_Rotation by ESRI.

ESRI also has a Hotine_Oblique_Mercator_Two_Point_Natural_Origin, which is supported by Proj.4, but not by EPSG.

(I am not 100 % sure of all this, and it may be slightly irrelevant to the ticket, but it could affect the morph-to-ESRI mechanism in OGR.)

[warmerdam]

The GeoTIFF code was updated a while ago (r24401). I believe this issue is now resolved in trunk. I'm still kind of chicken about back porting it to 1.9.

[hayamaguchi]

Please Note that

EPSG:3078: NAD83 / Michigan Oblique Mercator EPSG:3079: NAD83(HARN) / Michigan Oblique Mercator EPSG:3591: NAD83(NSRS2007) / Michigan Oblique Mercator

all appear to have the same problems as the Hotine Oblique Mercator problems that were apparently fixed in this ticket. Thank you.

[Jukka Rahkonen]

All the coordinate systems which were originally listed in this ticket seem to use the "Hotine Oblique Mercator (variant B)" method in the EPSG database. Coordinate systems on your Michigan list use "Hotine Oblique Mercator (variant A)" in the EPSG database.

I believe that this means that your problem is not the same and reopening this ticket was not the right thing to do. If you (hayamaguchi) are reading, please verify that the problem still exists with current GDAL version and create a new ticket about it. Write clearly into the new ticket how GDAL behaves now and what is wrong with it. This is what gdalsrsinfo reports now about the Michigan projections:

gdalsrsinfo epsg:3079

PROJ.4 : '+proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 
+k=0.9 996 +x_0=2546731.496 +y_0=-4354009.816 +no_uoff +gamma=337.25556 
+ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '


OGC WKT :
PROJCS["NAD83(HARN) / Michigan Oblique Mercator",
    GEOGCS["NAD83(HARN)",
        DATUM["NAD83_High_Accuracy_Reference_Network",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6152"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4152"]],
    PROJECTION["Hotine_Oblique_Mercator"],
    PARAMETER["latitude_of_center",45.30916666666666],
    PARAMETER["longitude_of_center",-86],
    PARAMETER["azimuth",337.25556],
    PARAMETER["rectified_grid_angle",337.25556],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",2546731.496],
    PARAMETER["false_northing",-4354009.816],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["X",EAST],
    AXIS["Y",NORTH],
    AUTHORITY["EPSG","3079"]]

[Jukka Rahkonen]

No feedback, closing again in belief that reopening was an error.