-
Notifications
You must be signed in to change notification settings - Fork 2
Axis order handling
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.
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
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/):
- EPSG:4326
- http://www.opengis.net/gml/srs/epsg.xml#4326
- urn:ogc:def:crs:epsg::4326
- urn:x-ogc:def:crs:epsg:6.11.2:4326
- urn:ogc:def:crs:EPSG:7.4:4326
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.
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.
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">For WMS 1.1.1, every deegree 3.x version should behave according to the specification and always treat coordinates as XY-ordered.
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.
- 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
Unclear. Some info needed.
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.