RFC 20: OGRSpatialReference Axis Support

Author: Frank Warmerdam
Contact: warmerdam@…
Status: Development

Summary

The OGRSpatialReference and OGRCoordinateTransformation classes assume that all coordinate systems use x=easting, y=northing (or in geographic terms x=longitude, y=latitude). In practice some coordinate systems use alternate axis orientations (such as the Krovak projection), and some standards (GML, WMS 1.3, WCS 1.1) require honouring the EPSG declaration that all it's geographic coordinates refer to x as latitude and y as longitude.

This RFC attempts to extend the OGRSpatialReference, and OGRCoordinateTransformation classes to support alternate axis orientations, and to update selected drivers (GML, WMS, WCS, GMLJP2) to properly support axis ordering.

WKT Axis Representation

The OGC WKT SRS format (per OGC 01-???) already indicates a way of defining coordinate system axes as shown in this example:

GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AXIS["Lat",NORTH],
    AXIS["Long",EAST],
    AUTHORITY["EPSG","4326"]]

There is one AXIS definition per axis with order relating to position within a tuple. The first argument is the user name for the axis and exact values are not specified. The second argument is a direction and may be one of NORTH, SOUTH, EAST or WEST.

Dilemma

The core challenge of this RFC is adding support for axes orders, including honouring EPSG desired axis order for geographic coordinate systems where appropriate without breaking existing files and code that make extensive use of EPSG coordinate systems but override axis orientations and assume they should be treated as long, lat regardless of what EPSG says.

In particular, we come up with appropriate policies and mechanisms to decide when a file in a geographic coordinate system like EPSG:4326 is to be treated as lat/long and when it should be long/lat. Because of the extensive existing practice it behooves us to err on the side of past practice, and require "opting in" to honouring EPSG axis ordering.

OGRSpatialReference

New methods:

    const char *GetAxis( const char *pszTargetKey, int iAxis, 
                         int *pnOrientation );

    OGRErr      SetAxes( const char *pszTargetKey, 
                         const char *pszXAxisName, int nXAxisOrientation,
                         const char *pszYAxisName, int nYAxisOrientation );

Defines the X and Y axes for a given target key (PROJCS or GEOGCS).

    int         EPSGTreatsAsLatLong();

Note that OGRSpatialReference::StripNodes( "AXIS" ); can be used to strip axis definitions where they are not desired.

Changed Methods:

• Modify importFromURN() to set AXIS values properly for EPSG and OGC geographic coordinate systems. So urn:...:EPSG: will be assumed to really honour EPSG conventions.
• Modify SetWellKnownGeogCS() to *not* set AXIS values, and strip AXIS values out of any other hardcoded WKT definitions.
• importFromEPSG() will continue to *not* set AXIS values for GEOGCS coordinate systems.
• importFromEPSG() *will* now set axis values for projected coordinate systems (at least in cases like Krovak where it is a non-default axis orientation).

OGRCoordinateTransformation

If AXIS values are set on source and/or destination coordinate system, the OGRCoordinateTransformation code will take care of converting into normal easting/northing before calling PROJ.4.

Questions

1. Should we try and address the Z axis too?
2. Are there values other than EAST, WEST, NORTH and SOUTH in the specification?
3. Should we use an enumeration for EAST, WEST, NORTH and SOUTH instead of #define's.