Opened 15 years ago
Closed 9 years ago
#2713 closed defect (fixed)
RFC20 not completely implemented : some axis ordering still present in WKT
Reported by: | Even Rouault | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | 1.6.0 |
Severity: | blocker | Keywords: | axis rfc20 wgs84 |
Cc: |
Description
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.
Change History (6)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Status: | new → assigned |
---|
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...
comment:3 by , 15 years ago
A grep shows that the JDEM, BSB, L1B, HDF4, ENVISAT, SRTMHGT, SAR_CEOS and LAN drivers still advertize AXIS[\"Lat\",NORTH],AXIS[\"Long\",EAST].
comment:4 by , 15 years ago
comment:6 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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() ?