The +no_uoff flags, needed for some Oblique Mercators, have disappeared from nad/epsg

[mikrit]

Hello Frank.

In Proj version 4.7 and in the trunk, there are no longer any +no_uoff flags in any omerc definitions in nad/epsg.

I think they were present in Proj version 4.6.1 (see  http://trac.osgeo.org/proj/ticket/37 and 38).

A +no_uoff ("no u-offset") means that the origin is at the so-called natural origin, on the central oblique line of the projection, and near the ordinary equator (on the "aposphere equator", but I've never understood what an aposphere is). This is called Hotine Oblique Mercator Variant A (new terminology, from the EPSG Guidance Note 7.2 published Nov. 2010).

If the +no_uoff is omitted, you get Hotine Oblique Mercator Variant B instead, where the origin is at the projection center.

I noticed that you implemented the +gamma parameter for omerc last year, and this means that you can remove the old +rot_conv flag, but it seems you have thrown out the baby with the bath water: you cannot remove the +no_uoff flag from those omerc instances that are supposed to be variant A.

See also  http://trac.osgeo.org/gdal/ticket/2745

Best regards

[garret]

+rot_conv flag has also disappeared in the trunk version. I upgraded because I needed the +gamma support but it appears support for rot_conv and no_uoff has gone!

Before I upgraded, I was able to produce RSO coordinates using: proj +proj=omerc +ellps=WGS84 +k_0=1.0 +lat_0=45.16666 +no_uoff +rot_conv +alpha=280 +lonc=-65.11666 +towgs84=0,0,0 +no_defs

and Hotine B using: proj +proj=omerc +ellps=WGS84 +k_0=1.0 +lat_0=45.16666 +alpha=280 +lonc=-65.11666

Now, it appears that I can only reproduce Hotine B and not RSO.

Regards,

Garret

[mikrit]

I looked at the revision history; there was a major change in Changeset 1817 (Feb. 2010), named "wholesale upgrade of omerc from Gerald's libproj4". If I understand it right, the +rot_conv flag was removed and replaced by the +gamma parameter. And also, the +no_uoff flag was renamed to +no_off.

I guess Gerald Evenden decided that +no_off was a better name for libproj4. But in Proj.4, it is of course better to keep the old name +no_uoff, for backwards compatibility. The change appears to be an accidental side-effect of the upgrade.

(I am slightly sorry to see the +rot_conv flag disappear, since I personally like it better than the general gamma. But gamma is used in the EPSG database, and I can understand if it would be cumbersome to support both +rot_conv and +gamma.)

Regards,

Mikael

[garret]

Yes, I noted the major change described in  http://trac.osgeo.org/proj/ticket/62

But now I cannot replicate a general RSO projection now; by 'general', I mean a General Hotine B that has not been rectified (==RSO) since that just seems to be the difference. The commands I outlined in previous post worked great to reproduce general RSO. And, yes, I tried +no_off +gamma=280 +alpha=280

I thought gamma was the same as XY_Plane_Rotation or Rectified_Grid_Angle (see  http://trac.osgeo.org/gdal/changeset/18950) so shoudn't necessarily exclude rot_conv, which seems to be a completely different and independent parameter.

I think I will go back to proj.4 version <4.7 but I will have a good read of libproj4 too.

Garret

Replying to mikrit:

I looked at the revision history; there was a major change in Changeset 1817 (Feb. 2010), named "wholesale upgrade of omerc from Gerald's libproj4". If I understand it right, the +rot_conv flag was removed and replaced by the +gamma parameter. And also, the +no_uoff flag was renamed to +no_off. I guess Gerald Evenden decided that +no_off was a better name for libproj4. But in Proj.4, it is of course better to keep the old name +no_uoff, for backwards compatibility. The change appears to be an accidental side-effect of the upgrade. (I am slightly sorry to see the +rot_conv flag disappear, since I personally like it better than the general gamma. But gamma is used in the EPSG database, and I can understand if it would be cumbersome to support both +rot_conv and +gamma.) Regards, Mikael

[garret]

To summarize:

For Hotine Variant B: +proj=omerc ... +lat_0= +alpha= +lonc=

For Hotine Oblique Mercator Azimuth Natural Origin: +proj=omerc ... +lat_0= +alpha= +lonc= +no_off

For RSO: can't do it anymore because +rot_conv is gone

Garret

Replying to garret:

Yes, I noted the major change described in  http://trac.osgeo.org/proj/ticket/62 But now I cannot replicate a general RSO projection now; by 'general', I mean a General Hotine B that has not been rectified (==RSO) since that just seems to be the difference. The commands I outlined in previous post worked great to reproduce general RSO. And, yes, I tried +no_off +gamma=280 +alpha=280 I thought gamma was the same as XY_Plane_Rotation or Rectified_Grid_Angle (see  http://trac.osgeo.org/gdal/changeset/18950) so shoudn't necessarily exclude rot_conv, which seems to be a completely different and independent parameter. I think I will go back to proj.4 version <4.7 but I will have a good read of libproj4 too. Garret Replying to mikrit:

I looked at the revision history; there was a major change in Changeset 1817 (Feb. 2010), named "wholesale upgrade of omerc from Gerald's libproj4". If I understand it right, the +rot_conv flag was removed and replaced by the +gamma parameter. And also, the +no_uoff flag was renamed to +no_off. I guess Gerald Evenden decided that +no_off was a better name for libproj4. But in Proj.4, it is of course better to keep the old name +no_uoff, for backwards compatibility. The change appears to be an accidental side-effect of the upgrade. (I am slightly sorry to see the +rot_conv flag disappear, since I personally like it better than the general gamma. But gamma is used in the EPSG database, and I can understand if it would be cumbersome to support both +rot_conv and +gamma.) Regards, Mikael

[mikrit]

As far as I understand, the +rot_conv flag can be present or absent, and that gives you two ways to specify the rotation: present = the Malaysian way or absent = the non-Malaysian way. So if you can specify an arbitrary +gamma value instead, you can simulate any use of +rot_conv, but you have to know which +gamma value you should use for that particular instance of RSO. (See  http://lists.maptools.org/pipermail/proj/2010-September/005349.html )

Or can you give an example of an RSO projection instance that you cannot implement without +rot_conv?

About the other flag: are you saying that neither +no_uoff nor +no_off has any effect? I can't explain that.

-- Mikael

Replying to garret:

To summarize: For Hotine Variant B: +proj=omerc ... +lat_0= +alpha= +lonc= For Hotine Oblique Mercator Azimuth Natural Origin: +proj=omerc ... +lat_0= +alpha= +lonc= +no_off For RSO: can't do it anymore because +rot_conv is gone Garret Replying to garret:

Yes, I noted the major change described in  http://trac.osgeo.org/proj/ticket/62 But now I cannot replicate a general RSO projection now; by 'general', I mean a General Hotine B that has not been rectified (==RSO) since that just seems to be the difference. The commands I outlined in previous post worked great to reproduce general RSO. And, yes, I tried +no_off +gamma=280 +alpha=280 I thought gamma was the same as XY_Plane_Rotation or Rectified_Grid_Angle (see  http://trac.osgeo.org/gdal/changeset/18950) so shoudn't necessarily exclude rot_conv, which seems to be a completely different and independent parameter. I think I will go back to proj.4 version <4.7 but I will have a good read of libproj4 too. Garret Replying to mikrit:

I looked at the revision history; there was a major change in Changeset 1817 (Feb. 2010), named "wholesale upgrade of omerc from Gerald's libproj4". If I understand it right, the +rot_conv flag was removed and replaced by the +gamma parameter. And also, the +no_uoff flag was renamed to +no_off. I guess Gerald Evenden decided that +no_off was a better name for libproj4. But in Proj.4, it is of course better to keep the old name +no_uoff, for backwards compatibility. The change appears to be an accidental side-effect of the upgrade. (I am slightly sorry to see the +rot_conv flag disappear, since I personally like it better than the general gamma. But gamma is used in the EPSG database, and I can understand if it would be cumbersome to support both +rot_conv and +gamma.) Regards, Mikael

[garret]

+no_off does work instead of +no_uoff, this is clearly reflecting the changes in libproj4.

My point about +rot_conv is that it was useful for creating custom, what I called earlier 'general', RSO projections. I was using it for creating projections with an arbitrary rotation to orientate geographic features north-south) for specific geomorphometry. Ideally, PROJ would support +gamma (=XY_Plane_Rotation) for arbitrary transverse mercator projections for my purpose but this hasn't been implemented yet... perhaps I could add it as feature request...

I have reverted to v. 4.6.1

Garret

[mikrit]

Test example 1:

In proj.4 trunk, based on EPSG 7.9, the entry for EPSG:26931, NAD83 / Alaska zone 1, is

+proj=omerc +lat_0=57 +lonc=-133.6666666666667 +alpha=323.1301023611111 +k=0.9999 +x_0=5000000 +y_0=-5000000 +gamma=323.1301023611111 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

With the input

133d40'W 57N

this definition gives

5000000.000 -5000000.000

In order to get the correct result

818676.734 575097.689

one must add the flag +no_off to the definition (it used to be called +no_uoff), in order to get Hotine variant A instead of B. Sources for the correct result: Melita Kennedy,  http://lists.maptools.org/pipermail/proj/2006-May/002258.html (and the NGS site that Melita mentions).

Test example 2:

The entry for EPSG:3376, GDM2000 / East Malaysia BRSO, is

+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31580995 +k=0.99984 +x_0=0 +y_0=0 +gamma=53.13010236111111 +ellps=GRS80 +units=m +no_defs

With the input

117E 12N

this definition gives

217398.00 886644.47

In order to get the correct result

807919.14 1329535.33

one must add the flag +no_off (or +no_uoff) again. Source for the correct result: The GIGS Test Dataset published by OGP; get it from  http://www.ogp.org.uk/pubs/430-3a.zip , look at the output file GIGS_mapProj_51xx_output_v2-0_2011-06-28.xls, under 5106 HOM-A (which also has more test points).

List of CRS definitions using Hotine variant A, which need to be corrected:

Code	Name
3078	"NAD83 / Michigan Oblique Mercator"
3079	"NAD83(HARN) / Michigan Oblique Mercator"
3167	"Kertau (RSO) / RSO Malaya (ch)"
3168	"Kertau (RSO) / RSO Malaya (m)"
3375	"GDM2000 / Peninsula RSO"
3376	"GDM2000 / East Malaysia BRSO"
3468	"NAD83(NSRS2007) / Alaska zone 1"
3591	"NAD83(NSRS2007) / Michigan Oblique Mercator"
5247	"GDBD2009 / Brunei BRSO"
24571	"Kertau / R.S.O. Malaya (ch)"
26731	"NAD27 / Alaska zone 1"
26931	"NAD83 / Alaska zone 1"

Other Hotine definitions in EPSG use variant B, and are correct in Proj.4 (as far as I know).

[warmerdam]

Ugg, this is complicated, but I can see I had better fix it before 4.8.0 or suffer regressions.

[mikrit]

Okay, the ticket discussion became a bit long, so let's forget +rot_conv and +gamma (which are off-topic) and just summarize the A/B issue:

current EPSG name	old EPSG name	coord op code	+no_uoff
"Hotine Oblique Mercator (variant A)"	"Hotine Oblique Mercator"	9812	yes
"Hotine Oblique Mercator (variant B)"	"Oblique Mercator"	9815	nope

I don't know how you generate the epsg initialization file. If you do it via OGRSpatialReference somehow, you are hindered by this class having the same blind spot for variant A and B (this is ticket  http://trac.osgeo.org/gdal/ticket/2745). However, let's assume that you can figure out the coord. op. code from the CRS code (you could look it up in pcs.csv, perhaps). Then you just need to add something like

if (coord_op_code == 9812) then projstring.append(" +no_uoff");

Easy as pi.

Disclaimer: I am currently recovering from a bad case of flu and my brain is sluggish; I can only hope I haven't made any typo in this comment.

On the other hand, if you can pass the HOM A and HOM B tests from GIGS, all should be well.

Good luck with 4.8.0; we are looking forward to it.

[warmerdam]

I have made adjustments in GDAL to differentiate the two variants ( http://trac.osgeo.org/gdal/ticket/2745 /  http://trac.osgeo.org/gdal/changeset/24091) and regenerated the epsg init file (r2187).

For the purposes of PROJ.4 I think this is now fixed.

I have confirmed that +no_uoff was added specically to the coordinate systems you noted needed work. It would be nice to add a couple epsg based tests to testvarious for the two oblique mercator variants.