5

While exploring various WMTS services, I've observed that sometimes x, y pair displayed in TopLeftCorner tag of TileMatrix tags defined in TileMatrixSet have succession changed to y, x.

There are at least two samples of AFAIK wrong succession. See for example:

http://mapy.geoportal.gov.pl/wss/service/WMTS/guest/wmts/TOPO?REQUEST=GetCapabilities&SERVICE=WMTS

(for EPSG:2180 TileMatrixSet and EPSG:4326 TileMatrixSet), and

http://ext-webbgis.lansstyrelsen.se/sverigeslanskarta/proxy/proxy.ashx?http://maps.lantmateriet.se/topowebb/v1/wmts?request=GetCapabilities&version=1.0.0&service=wmts

(for 3006 TileMatrixSet and WGS84 TileMatrixSet).

In the latter example, succession used in definition of TopLeftCorner:

<TopLeftCorner>8500000.000000 -1200000.000000</TopLeftCorner>

is in contradiction with definition of BoundingBox a few lines above:

<ows:BoundingBox crs="urn:ogc:def:crs:EPSG:6.3:3006">
    <LowerCorner>-1200000.000000 4305696.000000</LowerCorner>
    <UpperCorner>2994304.000000 8500000.000000</UpperCorner>
</ows:BoundingBox>

despite the fact that LowerCorner, UpperCorner and TopLeftCorner should use the same ows:PositionType definition from schemas-opengis-net-ows-1.1.0-owsCommon.xsd:

Position instances hold the coordinates of a position in a coordinate reference system (CRS) referenced by the related "crs" attribute or elsewhere.

I wonder how to copy with such discrepancies when processing WMTS GetCapabilities response automatically. Is this problem addressed in some way in existing software packages?

6

It seems that all WMTS service that were suspicious in my question, were right; I was wrong.

World of CRS definitions is not so simple.

Actual axis order to be used while constructing TopLeftCorner, results from CRS definition.

It has been explained e.g. at http://www.geotoolkit.org/modules/referencing/faq.html#axisOrder.

For CRS like EPSG:3857, EPSG:32633, axis order is "natural", i.e. horizontal one first, then vertical one.

For CRS like geodetic EPSG:4326, and projected EPSG:2180, EPSG:3006, axis order is "reversed", i.e. vertical one first, then horizontal one.

Despite this fact, coordinates in BoundingBox and WGS84BoundingBox are always listed in "natural" succession.

Actual order of axes can be detected by examining appropriate part of WKT representation of given CRS containing AXIS tags, e.g.:

  • EPSG:3857: AXIS["X",EAST],AXIS["Y",NORTH]
  • EPSG:32633: AXIS["Easting",EAST],AXIS["Northing",NORTH]

EAST first, then NORTH - no swapping required

  • EPSG:2180: AXIS["x",NORTH],AXIS["y",EAST]
  • EPSG:3006: AXIS["x",NORTH],AXIS["y",EAST]

NORTH first, then EAST - swapping is required

For geodetic CRS, swapping from lat, lon order to lon (horizontal), lat (vertical) is always required.

Or maybe there are other geodetic CRS that use lon, lat order? There are no AXIS tags in WKT for EPSG:4326.

Other links in this matter:

Axis Order Policy Guidance

Posts containing 'axis order' - GIS Stack Exchange

  • "coordinates in BoundingBox and WGS84BoundingBox are always listed in natural succession" is not entirely correct. In WMTS 1.0.0 axes order of BoundingBox is specified "Minimum bounding rectangle surrounding the layer, in the supported CRS", axes order unspecified (or CRS-specified) – mloskot May 19 '17 at 15:29
  • Moreover, BoundingBox a type is specified in OWS which states "Any number of axes may be used, from 1D to 4D or more. The number of axes included, and the order of these axes, shall be as specified by the referenced CRS." – mloskot May 19 '17 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.