Skip to content

Axis order handling

Jump to bottom
Markus Schneider edited this page Apr 23, 2014 · 8 revisions

Axis-ordering issues have a long history in the OGC world. This page collects the requirements from the OGC specifications, the current implementation status in deegree and thoughts on how to do it better in the future.

What is axis ordering?

Basically, axis ordering refers to the order of the axis values in a coordinate. For example, the geographical coordinate of Bonn can be expressed as:

  • 50.733992,7.099814 (YX-order)
  • 7.099814,50.733992 (XY-order)

This ordering is relevant whenever coordinates are exchanged between different systems or subsystems, e.g.

  • Bounding box (in WMS/WFS capabilities)
  • Bounding box (in WMS/WFS requests)
  • GML geometries (in WFS responses)
  • GML geometries (in WFS requests)
  • PostGIS geometries

CRS identifiers

A CRS identifier consists of an authority and a code. Due to historical reasons, there are several ways to encode them. Here are some examples that all refer to the common CRS with code 4326 from EPSG (http://www.epsg-registry.org/):

NOTE: The CRS authority defines the parameters of the CRS, including axis order. If the axes of a coordinate keep the official ordering of the authorities' definition, this is also called axis-awareness. A lot of GIS software (e.g. PostGIS) is not axis-aware at all and always uses XY ordering, regardless of the definition of the CRS.

Status in deegree

deegree 3.x supports many different CRS and identifier variants. Each available identifier is defined in file crs-definitions.xml (module deegree-core-cs). This file can be adapted in the JAR, and it's also possible to override it in the deegree workspace.

NOTE: The CRS db has a convention to associate axis-awareness with the way an EPSG code is specified:

  • EPSG:4326 (not axis-aware, XY)
  • "urn:ogc:def:crs:epsg::4326" (axis-aware, YX, "modern")

This means that deegree treats "EPSG:4326" as an XY coordinate system and "urn:ogc:def:crs:epsg::4326" as YX. The rational for that is that older (not axis-aware) clients will always use "EPSG:xxxx" to specify a coordinate system, while modern clients that use something like "urn:ogc:def:crs:epsg::4326" will more likely be axis-aware.

WMS 1.1.1

Specification

The specification clearly mandates XY-ordering (in capabilities and requests)

<BoundingBox CRS="EPSG:4326" minx="-180" miny="-90" maxx="180" maxy="90">
<BoundingBox CRS="CRS:84" minx="-180" miny="-90" maxx="180" maxy="90">

Implementation status

For WMS 1.1.1, every deegree 3.x version should behave according to the specification and always treat coordinates as XY-ordered.

WMS 1.3.0

Specification

Specification mandates official axis ordering (in capabilities and requests). A lot of clients don't seem to do it right, though. Some discussion: http://dmorissette.blogspot.de/2012/12/dont-upgrade-to-wms-130-unless-you.html

<BoundingBox CRS="EPSG:4326" minx="-90" miny="-180" maxx="90" maxy="180">
<BoundingBox CRS="CRS:84" minx="-180" miny="-90" maxx="180" maxy="90">

NOTE: Don't get confused by the attribute names. For WMS 1.3.0, minx means: mininum value of the first axis.

Implementation status

  • For WMS 1.3.0, deegree 3.x up to version 3.4-pre10 uses the axis-order from the internal CRS database: "Modern" EPSG identifier variants are treated axis-aware, while "EPSG:xxxx" is treated as XY.
  • Since deegree 3.4-pre11, all identifier variants are treated axis-aware

WFS

Specification

Unclear. Some info needed.

Implementation status

For all WFS protocol versions, deegree 3.x keeps to the axis-order of the internal CRS DB: "Modern" EPSG identifier variants are axis-aware, while "EPSG:xxxx" will be treated as XY.

Clone this wiki locally