ogr2ogr does not know +no_uoff parameter

[45136]

I want to transform vector data from wgs84 to Michigan Georef. With cs2cs, transformation works ok:

echo epsg 4326-3078 >out.txt
cs2cs +init=epsg:4326 +to +init=epsg:3078 in.txt >>out.txt
echo epsg 4326-projstring with no_uoff>>out.txt
cs2cs +init=epsg:4326 +to +proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +x_0=2546731.496 +y_0=-4354009.816 +no_uoff +gamma=337.25556 +datum=NAD83 +units=m +no_defs in.txt >>out.txt
echo epsg 4326-projstring with no_off>>out.txt
cs2cs +init=epsg:4326 +to +proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +x_0=2546731.496 +y_0=-4354009.816 +no_off +gamma=337.25556 +datum=NAD83 +units=m +no_defs in.txt >>out.txt
echo epsg 4326-projstring without no_uoff >>out.txt
cs2cs +init=epsg:4326 +to +proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +x_0=2546731.496 +y_0=-4354009.816 +gamma=337.25556 +datum=NAD83 +units=m +no_defs in.txt >>out.txt

in.txt contains just

-83 44

The first three operations result to

740335.15	387567.53 0.00

The last one to

2787226.40	-4495042.59 0.00

which is obviously wrong (all data from inside Michigan state should be positive).

Then I created a sample vector grid 1°x1° of the area, and performed the follwing transformations:

ogr2ogr -s_srs epsg:4326 -t_srs "+proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +x_0=2546731.496 +y_0=-4354009.816 +no_uoff +gamma=337.25556 +datum=NAD83 +units=m +no_defs" Mich-proj_no_uoff.shp Mich-wgs84.shp
ogr2ogr -s_srs epsg:4326 -t_srs "+proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +x_0=2546731.496 +y_0=-4354009.816 +no_off +gamma=337.25556 +datum=NAD83 +units=m +no_defs" Mich-proj_no_off.shp Mich-wgs84.shp
ogr2ogr -s_srs epsg:4326 -t_srs "+proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +x_0=2546731.496 +y_0=-4354009.816 +gamma=337.25556 +datum=NAD83 +units=m +no_defs" Mich_proj.shp Mich-wgs84.shp
ogr2ogr -s_srs epsg:4326 -t_srs epsg:3078 Mich_3078.shp Mich-wgs84.shp

All shapefiles have an extend of around the wrong cs2cs value. Which means that the +no_uoff or +no_off parameter is ignored in ogr2ogr. As a consequence, all original Michigan Georef shapefiles are totally misplaced in Quantum Gis dependig on GDAL, while they are well aligned in uDig and Arcgis.

Tested on Windows 7, if that may have an influence.

[45136]

sample vector grid 1°x1° in WGS84

[Even Rouault]

There have been changes in trunk related to #2745 in that area, but with trunk r25245, I still confirm that there's a roundtripping problem.

$ gdalsrsinfo epsg:3078

PROJ.4 : '+proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +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 / Michigan Oblique Mercator",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4269"]],
    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","3078"]]

If you use the above generated proj.4 string:

$ gdalsrsinfo '+proj=omerc +lat_0=45.30916666666666 +lonc=-86 +alpha=337.25556 +k=0.9996 +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 '

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

OGC WKT :
PROJCS["unnamed",
    GEOGCS["GRS 1980(IUGG, 1980)",
        DATUM["unknown",
            SPHEROID["GRS80",6378137,298.257222101],
            TOWGS84[0,0,0,0,0,0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Hotine_Oblique_Mercator_Azimuth_Center"],
    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["Meter",1]]

So the +no_uoff parameter was lost.

End of what I can reasonably do about this without any particular knowledge on HOM vs HOMAC.

[45136]

Replying to rouault:

There have been changes in trunk related to #2745 in that area, but with trunk r25245, I still confirm that there's a roundtripping problem.

Using the latest build from sysinternals, only EPSG:3078 does the transformation correct. The other three (with proj string) are all identical to the old version.

[45136]

The bug also affects Malaysian RSO CRS in QGIS, see this discussions and blogs: ​http://gis.stackexchange.com/questions/54758/crs-in-qgis-and-arc-dont-line-up-malaysia-data

​http://qgismalaysia.blogspot.de/2012/07/did-you-use-right-wgs84.html?showComment=1349167336783#c4368788163579127311

[hilmyh]

I made a test for the +no_off and +no_uoff on a Windows 7 64 bit machine installed with QGIS Master and QGIS 1.8 using Osgeo4W. The GDAL version reported is 1.9.2. The proj4 string I used was GDM2000/Peninsula RSO (EPSG:3375) with +no_off added (also tested with +no_uoff):

+proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.0257964666666 +k=0.99984 +x_0=804671 +y_0=0 +gamma=323.1301023611111 +ellps=GRS80 +no_off +units=m +no_defs

Test points: 1.827764875 deg N, 103.640259872222 deg E (WGS84 EPSG:4326) Expected coordinates: Northing 202,122.062 m, Easting 627,096.132 m (EPSG:3375)

Using QGIS Custom CRS dialog Test section, I get the expected result:

Y = 202,122.0625 m, 627,096.1317 m.

Also same result with cs2cs using the osgeo shell.

Using QGIS on-the-fly transformation and ogr2ogr in the osgeo shell I get:

Y = -240,332.0326, X = 958,936.7057

This is the same if the +no_uoff or +no_off was not applied.

[hilmyh]

Just did a test with GDAL 1.10.0. ogr2ogr is now giving the correct results with both +no_uoff and +no_off. Results from test points in previous post:

Y = 202122.06250741021 m, 627096.13171942497 m.

Great, thanks.

[45136]

unfortunately, my Michigan example shows the same behaviour in GDAL 1.10.0 as the last trunk version: only "EPSG:3078" is handled correctly, the proj strings fail.

[hilmyh]

For the record,

ogr2ogr -s_srs epsg:4326 -t_srs epsg:3375 test_points_prso.shp test_points_wgs84.shp

works correctly in GDAL 1.10.0 on Windows 7 (64 bit install).

[45136]

Just another case, this time with Alaska omerc projection:

​http://gis.stackexchange.com/questions/83664/how-do-i-set-a-crs-when-it-isnt-listed-in-qgis-mac-not-pc

[Kyle Shannon]

I'll take a crack at this...

[Even Rouault]

Duplicate of #5511