-
-
Notifications
You must be signed in to change notification settings - Fork 99
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 sometimes called axis-awareness.
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)
This means that deegree treates "EPSG:4326" as an XY coordinate system and "urn:ogc:def:crs:epsg::4326" as YX.
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">
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 versions, deegree 3.x keeps to the internal CRS DB. Modern EPSG identifier variants are treated axis-aware, while "EPSG:xxxx" will be treated as XY.