Opened 13 years ago
Closed 13 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 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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.