RFC20 not completely implemented : some axis ordering still present in WKT

[rouault]

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.

and

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.

[rouault]

Hum, there's maybe an exception to my above observations. In OGRSpatialReference::importFromURN() we call SetWellKnownGeogCS(x) where x = "CRS84" or "CRS83" or "CRS27". In those cases,I guess the 'AXIS[\"Lat\",NORTH],AXIS[\"Long\",EAST]' should be present. So if we remove it from SetWellKnownGeogCS(), we should happen it in importFromURN() ?

[warmerdam]

Even,

I don't follow your point with regard to CRS84, 27 and 83.

I have corrected the SRS_WKT_WGS84 macro in gdal/ogr/ogr_srs_api.h to not include the AXIS declarations as required by RFC20 in trunk (r15869) and 1.6 (r15871).

I have also done corresponding axis checking fixes in the autotest in trunk (r15870) and 1.6 (r15872).

I'll address that 1.5 issues later...

[rouault]

A grep shows that the JDEM, BSB, L1B, HDF4, ENVISAT, SRTMHGT, SAR_CEOS and LAN drivers still advertize AXIS[\"Lat\",NORTH],AXIS[\"Long\",EAST].

[warmerdam]

I have corrected the axis problems in these drivers in trunk (r16018) and 1.6 branch (r16019).

[warmerdam]

Removing non-serious milestone.