Ticket #2713 (assigned defect)
RFC20 not completely implemented : some axis ordering still present in WKT
|Reported by:||rouault||Owned by:||warmerdam|
|Severity:||blocker||Keywords:||axis rfc20 wgs84|
RFC20 says :
SetWellKnownGeogCS() ¶ This method appears to be the only code * Modify SetWellKnownGeogCS() to *not* set AXIS values, and strip AXIS values out of any other hardcoded WKT definitions.
Work will be in trunk for GDAL/OGR 1.6.0 with the following exceptions which will be address in 1.5.x: * Existing use of AXIS specifier will for geographic coordinate systems will be stripped from SetWellKnownGeogCS() and the various drivers with hard coded WKT strings. * Some sort of hack will need to be introduced into the GMLJP2 (and possibly WCS) code to flip EPSG authority lat/long values (details to be worked out).
I've discovered that in GDAL 1.6, SetWellKnownGeogCS("WGS84") still returns the WKT definition with AXIS[\"Lat\",NORTH],AXIS[\"Long\",EAST]. See SRS_WKT_WGS84 in ogr_srs_api.h. However, AXIS have been stripped off from the other hard-coded SRS : WGS72, NAD27 and NAD83. The error seems due to the move of the hard-coded definition of WGS84 WKT to the header. It seems important to me that it is an important of the RFC that should be fixed for 1.6 release, doesn't it ? Although I'm not sure of the severity, I'm putting as a blocker in doubt.
And it appears that the work announced for the 1.5 branch hasn't been done. http://trac.osgeo.org/gdal/browser/branches/1.5/gdal/ogr/ogrspatialreference.cpp still contains the AXIS definition for the all set of hard-coded SRS.