Opened 20 months ago

Closed 20 months ago

Last modified 20 months ago

#6080 closed defect (fixed)

Well known GCS definitions of WGS84, WGS72, NAD27 and NAD83 don't match their EPSG defs

Reported by: Even Rouault Owned by: Even Rouault
Priority: normal Milestone: 2.1.0
Component: OGR_SRS Version: unspecified
Severity: normal Keywords:
Cc:

Description (last modified by Even Rouault)

When doing SetWellKnownGeogCS() with WGS84, WGS72, NAD27 and NAD83, the result is not strictly equal to the corresponding ImportFromEPSG()

Differences are :

  • TOWGS84 node for WGS84
  • AUTHORITY 9108 instead of 9122 for degree
  • inverse flattening of NAD27 is 294.978698213898 instead of 294.9786982138982

Change History (4)

comment:1 Changed 20 months ago by Even Rouault

Milestone: 2.1.0
Resolution: fixed
Status: newclosed

trunk r29765 "Align hard-coded WKT of well known GCS definitions of WGS84, WGS72, NAD27 and NAD83 with thee WKT of their EPSG def (#6080)"

comment:2 Changed 20 months ago by Even Rouault

trunk r29766 "Commit file that should have gone with previous commit (#6080)"

comment:3 Changed 20 months ago by Even Rouault

Description: modified (diff)

comment:4 Changed 20 months ago by Even Rouault

The removal of TOWGS84 in WGS84 definition caused a regression on http://debbie.postgis.net:8080/job/GDAL_Regress/2943/ because of a difference in behaviour in proj.4 where the normalization of proj.4 strings didn't expand +datum=wgs84 to a +towgs84=0,0,0 contrary on other test platforms. So it is better in importFromProj4() to no add the dummy TOWGS84 node for +datum=WGS84

trunk r29775 "importFromProj4(): make sure no to include a TOWGS84[0,0,0,0,0,0,0] when the datum is WGS84 (#6080)"

Note: See TracTickets for help on using tickets.