Opened 7 years ago

Closed 7 years ago

#3904 closed defect (fixed)

SAD69 Spheroid Remapping in morphFrom/ToESRI()

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: OGR_SRS Version: unspecified
Severity: normal Keywords: esri
Cc:

Description

I'm dealing with OGR SRS now and I (and probably every potential SAD69 datum user) became a victim of ESRI PRJ files oddities. Here in Brazil we have been using SAD69 datum with GRS 1967 Modified spheroid. Despite the recent adoption of SIRGAS 2000 as our (brazilian) new SRS there are lots of data available in SAD69 and this data will be here for some time.

So what Armando you my be asking, so let me clarify, I dunno if you are aware that ESRI PRJ file for this DATUM contains the text bellow:

GEOGCS["GCS_South_American_1969",DATUM["D_South_American_1969",SPHEROID["GRS_1967_Truncated",6378160.0,298.25]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]

You should have noticed the bold SPHERIOD name, it's the problem source. I modified, by hand, the text "GRS_1967_Truncated" to "GRS_1967_Modified" and now the postgres driver correctly assign the SRID to 4618 (as it should be) instead of adding new records to spatial_ref_sys table.

Since OGR_SRS make OSRMorphFromESRI function available I would ask if it's possible to add another fix to it changing SPHEROIDS with value "GRS_1967_Truncated" to "GRS_1967_Modified".

Change History (3)

comment:1 Changed 7 years ago by warmerdam

Resolution: fixed
Status: newclosed

I have applied a remapping for this situation going and coming from ESRI format as well as a brief test (r21485).

Currently this is only in trunk. I'm not sure if I want to take it back into 1.8 at this point.

comment:2 Changed 7 years ago by Even Rouault

Resolution: fixed
Status: closedreopened

This causes the following failures in trunk autotest:

  TEST: hfa_pe_read ... PROJCS["World_Cube",GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_84",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Cube"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Option",1.0],UNIT["Meter",1.0]]
fail
    failed to read pe string as expected.
  TEST: hfa_pe_write ... 
PROJCS["World_Cube",GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.017453292519943295]],PROJECTION["Cube"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Option",1.0],UNIT["Meter",1.0]]
PROJCS["World_Cube",GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_84",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.017453292519943295]],PROJECTION["Cube"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Option",1.0],UNIT["Meter",1.0]]
fail
    failed to write pe string as expected.
  TEST: pdf_1 ... PROJCS["WGS_1984_UTM_Zone_20N",GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_84",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-63.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]
fail
    bad WKT

I presume they should be updated to reflect the new behaviour ?

comment:3 Changed 7 years ago by Even Rouault

Resolution: fixed
Status: reopenedclosed

r21656 fixed the hfa errors. And I fixed the pdf one accordingly in r21663

Note: See TracTickets for help on using tickets.