# Axis Order Policy Guidance

**OGC Project Document 08-038r5**

**TITLE: Axis Order Policy and Recommendations**

**AUTHORS:**

**Name: Carl Reed, Editor**

**Email:**

__creed <at> opengeospatial.org__

**DATE: 2008-09-15**

**CATEGORY: OGC Policy statement**

Issues and misunderstandings about how to specify coordinate axis order causes confusion and lack of interoperability. The classic case is of an OGC® GML payload that specifies a SRSName__[1]__ of EPSG__[2]__ 4326 (axis order latitude, longitude) but then encodes the geometry in the reverse order longitude, latitude. So, the problem is not simply an issue of **X, Y, Z** or **N, E, S, W**, but how we interpret them and use them in software, geodesy and navigation - it varies and has led to confusion among many people__[3]__.** **

In all cases, honesty is the key. In other words, any documentation, encoding, payload, or service interface MUST state how the coordinate axis order is actually encoded in the coordinate strings. (CRS = Coordinate Reference System and CS = Coordinate System)

· **Case 1: CRS explicitly stated in the interface or payload**: Coordinates are expressed using the axis order as defined in the CRS (Example is a GML payload where the axis order of the SRSName and the encoding of the geometry are consistent). The CRS SHALL be defined either by value, by reference, or by use of a URN as defined in the "ogc" URN namespace, as now specified in Clause 7 of OGC 05-023r1/OWS Common, unless a URL is used to reference a CRS in a registry__[4]__.

· **Case 2: CRS is not explicitly stated in the interface or payload**: In this case, the documentation SHALL explicitly state the CRS that is always used and your application/service/payload shall use the axis order as stated in the standard practice documentation. (Examples are CAP and KML), This is a corollary to Case 1.

· **Case 3: A Derived CRS or a local CS transformation is stated in the payload or interface **For this case, follow the OGC Abstract Specification Topic 2 guidance for defining a derived CRS and applying local transformations. Such a CS transformation could be as simple as changing the axis order.

Additional background and information is now provided.

The above guidance is 100% consistent – but expands – the axis order policy statement agreed to by the OCG members at the 2006 Bonn Meetings.

1. Going forward, for new standards, coordinate values shall be listed in the axis order as specified by the referenced coordinate reference system (CRS).

- Going forward, when a Standards Working Group (SWG) is working on edits to an existing adopted standard, coordinate values shall be listed in the axis order specified by the referenced coordinate reference system (CRS).
- Going forward, for updated and new OGC standards, CRSs should be referenced using URNs in the "ogc" URN namespace, as now specified in Clause 7 of OGC 05-023r1/OWS Common, unless a URL is used to reference a CRS.
- Existing adopted standards will remain as is unless change requests are submitted and accepted, that seek consistency in CRS usage - such as for WMS.

Based on the Bonn policy and the contents of this manifesto, there are several OGC standards that need additional work to remove all ambiguities related to axis order.

Axis Order – The order of the axes as specified in the Coordinate System. The order of the coordinates in a coordinate tuple in a content payload, API, service interface, and so forth corresponds to that order. For example, Northing, Easting or Easting, Northing.

Coordinate – One of a sequence of *N *numbers designating the position of a point in *N*-dimensional space. (OGC Abstract Specification Topic Volume 2 and ISO 19111)

Coordinate System - Set of (mathematical) rules for specifying how coordinates are to be assigned to points. (OGC Abstract Specification Topic Volume 2 and ISO 19111).

NOTE: This defines the coordinate axes and the order in which they are to be used.

CRS – Coordinate Reference System - Coordinate System that is related to the real world by a datum. (OGC Topic AS Volume 2 and ISO 19111)

EPSG – The work of the European Petroleum Survey Group has been incorporated into the OGP Surveying and Positioning Committee. However, the geodetic parameter database is still referred to as the __EPSG Geodetic Parameter Dataset__ or EPSG for short.

Geodetic CRS - CRS in which position is specified by geodetic latitude, geodetic longitude and (in the three-dimensional case) ellipsoidal height when associated with an ellipsoidal Coordinate System or by Geocentric X, Geocentric Y and Geocentric Z when associated with a 3D Cartesian Coordinate System (OGC Topic AS Volume 2 and ISO 19111)

Geometric primitive - A single, connected, homogeneous element of space. Geometric primitives are non-decomposed **objects **that present information about geometric configuration.

Geometry Coordinates__[5]__ – Coordinates defining a geometric primitive, such as the coordinates defining a point, linestring, or polygon.

From ISO 19111 (which can be downloaded from the OGC website):

“Some coordinate reference systems are defined by applying a coordinate conversion to another coordinate reference system. Such a coordinate reference system is called a Derived CRS and the coordinate reference system from which it was derived is called the Base CRS. The best-known example of a Derived CRS is a Projected CRS, which is always derived from a base Geographic CRS by applying the coordinate conversion known as a map projection.”

In order to allows a payload or interface to specify a CRS, such as 4326 but also specify a derived CRS in which a local transform to switch the axis order is provided, the OGP has updated the EPSG database to include a number of new conversions and coordinate systems that can be applied to create a derived CRS.

Axes swapping conversions:

- one 2D coordinate conversion that swaps the axes; This conversion is equally applicable to coordinate tuples in a Projected CRS

- one 3D coordinate conversion that swaps the first two axes (in the horizontal plane); the height axis is assumed to be the 3rd one and stays there. This conversion is equally applicable to coordinate tuples in a Geographic 3D CRS and in a Compound CRS.

New Coordinate Systems

- ellipsoidal 2D CS, Longitude, Latitude in degrees, supplier to define representation format

- ellipsoidal 2D CS, Longitude, Latitude in grads

- ellipsoidal 2D CS, Longitude, Latitude in radians

- ellipsoidal 3D CS, Longitude, Latitude in degrees, supplier to define representation format, ellipsoidal height in metres

- ellipsoidal 3D CS, Longitude, Latitude in grads, ellipsoidal height in metres

- ellipsoidal 3D CS, Longitude, Latitude in radians, ellipsoidal height in metres

For good measure the following have also added:

- ellipsoidal 2D CS, Latitude, Longitude in radians

- ellipsoidal 3D CS, Latitude, Longitude in radians, ellipsoidal height in metres

The EPSG dataset will not actually contain any CRSs that make use of those building blocks. It is up to the application or service to use this information to perform the necessary transformations.

1) As per the Bonn motion, the OGC needs to make sure that what is decided (pursuant to this manifesto) is communicated broadly.

2) Further, there is a need to discuss for all OGC standards that use CRS the implications of this manifesto.

3) Related, all of the above is about the ability for software/applications to provide for the possibility that coordinate order may need to be transformed between one software environment and another depending on the CRS and/or formatting definition. This is already common when moving coordinates from geometry storage / processing subsystems to graphics subsystems. It needs to be common practice for supporting coordinate data exchange formats and interfaces as well.** **

In summary, the core issue is how to deal with axis ordering of geographic coordinates – latitude and longitude. There is a significant GIS community of practice that has for decades always used a right handed coordinate system for storing, processing, and displaying geographic coordinates as longitude-latitude. There is also a large and significant community that has adhered to the geodetic best practice that axis order for geographics is represented as latitude-longitude.

Axis orientation: The left-handed orientation is shown on the left, and the right-handed on the right. (http://en.wikipedia.org/wiki/Right-hand_rule).

Therefore, in order to move forward and enable a migration path, the OGC Membership recommends that we provide strong guidance on the use axis order that goes beyond Bonn (Option 1) and allows any of the alternatives given in the OPTIONS above. This guidance should include an “honesty” clause so that use of alternative, valid options does not interfere with interoperability. Such an honestly clause requires that OGC standards such as WFS allow for the ability to specify both a CRS and other information that defines how axis order is represented in the geometry.

__[1]__ SRSName = Spatial Reference System Name

__[2]__ EPSG – Database of coordinate reference systems maintained by the OGP. http://www.epsg.org/

__[3]__ Blog posting by Dean C. Mikkelsen

__[4]__ There are two well defined and publicly accessible CRS registries: __http://www.epsg-registry.org__ and __http://spatialreference.org/__

__[5]__ Not in 19107. Defined for use in this document.

- Login to post comments

## Comments

## The current draft of the

The current draft of the GeoJSON in IETF: http://tools.ietf.org/html/draft-butler-geojson-00 we could have a problem because they are saying:

"2.1.1 [...] position [...] or array of positions [...] will be longitude and latitude, or easting and northing, precisely in that order and using decimal numbers."

and to

"3 [...] The presence of a CRS object SHALL NOT change the ordering of coordinates specified in section 2.1.1."

If GeoJSON is going to be used mixed in other OGC standards, in my opinion (and from discussions in OWS-10) this could create a contradition with this policy document. A solution could be to ammend this policy to include GeoJSON as an exception. The situation could be even worst if we end up mixing JSON encodings generated in OGC (or by others) that are no explicitly recognized as GeoJSON and using different axis ordering.

## Effects on previous

Effects on previous versions

Good document. This will clarify the issue.

I suggest that new revision of this document includes a table that describes which versions of WxS and other standards are interpreting EPSG:4326 in the wrong order and which versions have this issue corrected. As a developed this information is vital to interoperate with old serves and clients in an harmonized the behaviour. Unfortunately new developed clients and servers has to deal with old versions and new versions simultaneously.

Even more useful will be where exactly the developed has to act.

For instance:

- WMS 1.0, 1.1.0, 1.1.1 have examples in the wrong order so we have to assume that implementations has to behave switching order. WMS 1.3 corrects the order issues.

LatLonBoundingBox, BoundingBox, resx and resy in the capabilities document and in GetMap and GetFeatureInfo BBOX parameter are afected.

- WFS and GML are also afected. Examples on GML 3.1.1 seem to be in wrong order so this and all previous version implementation has to be supposed in the wrong order. GML 3.2.0 corrects the situation. Examples on WFS seems to order the lat-long in WGS84BoundingBox elements in the wrong order. Next version 1.2 will correct this.

- etc

Joan Masó

UAB-CREAF-MiraMon