Opened 7 years ago

Closed 5 years ago

#4910 closed defect (fixed)

ogr2ogr does not know +no_uoff parameter

Reported by: 45136 Owned by: Kyle Shannon
Priority: normal Milestone: 1.11.1
Component: OGR_SF Version: 1.10.0
Severity: normal Keywords:
Cc:

Description (last modified by 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.

Attachments (1)

Mich-wgs84.zip (1.4 KB) - added by 45136 7 years ago.
sample vector grid 1°x1° in WGS84

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by 45136

Attachment: Mich-wgs84.zip added

sample vector grid 1°x1° in WGS84

comment:1 Changed 7 years ago by 45136

Description: modified (diff)

comment:2 Changed 7 years ago by 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.

comment:3 in reply to:  2 Changed 7 years ago by 45136

Milestone: 1.10.0
Version: 1.9.2svn-trunk

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.

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by 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.

comment:7 in reply to:  6 Changed 6 years ago by 45136

Version: svn-trunk1.10.0

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.

comment:8 Changed 6 years ago by 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).

comment:9 Changed 6 years ago by 45136

Milestone: 1.11.0

comment:10 Changed 6 years ago by Kyle Shannon

Owner: changed from warmerdam to Kyle Shannon
Status: newassigned

I'll take a crack at this...

comment:11 Changed 5 years ago by Even Rouault

Milestone: 1.11.01.11.1
Resolution: fixed
Status: assignedclosed

Duplicate of #5511

Note: See TracTickets for help on using tickets.