Opened 11 years ago
Closed 10 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 )
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)
Change History (12)
by , 11 years ago
Attachment: | Mich-wgs84.zip added |
---|
comment:1 by , 11 years ago
Description: | modified (diff) |
---|
follow-up: 3 comment:2 by , 11 years ago
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 by , 11 years ago
Milestone: | → 1.10.0 |
---|---|
Version: | 1.9.2 → svn-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:4 by , 11 years ago
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
comment:5 by , 11 years ago
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.
follow-up: 7 comment:6 by , 11 years ago
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 by , 11 years ago
Version: | svn-trunk → 1.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 by , 11 years ago
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 by , 10 years ago
Milestone: | → 1.11.0 |
---|
Just another case, this time with Alaska omerc projection:
comment:10 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I'll take a crack at this...
comment:11 by , 10 years ago
Milestone: | 1.11.0 → 1.11.1 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Duplicate of #5511
sample vector grid 1°x1° in WGS84