[OSGeo-Standards] Web Feature Service (WFS) and Axis Order

[Carl Reed]

Dear OSGeo community -

I have subscribed to the GeoServer list but have not yet been approved so I
am posting to this list.

As you may know years ago I facilitates a lengthy and at time lively OGC
discussion on Axis Order and CRS. The result of these discussions was OGC
member approval of the OGC Axis Order policy and guidance (
http://www.ogcnetwork.net/axisorder).

Given this background, Esri recently approached me about some ambiguities
and confusions regarding the history and evolution of how axis order was
expressed in a Web Feature Service implementation instance. After review of
various OGC WFS documents and discussions with the Editor (Peter Vretanos)
I compiled the following information. I will be sharing the same
information with the OGC Architecture Board and staff. Apparently, the CRS
axis order issue never really "dies"!!

I bring this information to your attention so that perhaps the GeoServer
community can update their WFS Axis Order web page content to be consistent
with the following. Any questions in that regard, please let me know. Onto
the discussion.

Part of the confusion is probably due to changing OGC policies over the
last 15 years. Examples are the 2008 Axis Order Guidance policy (08-138r5)
and later the http uri policy (in TC Policy Directives). Anyway, in 2013
the WFS 1.1.1 corrigendum corrected the axis order issue to be consistent
with the Axis Order policy as well as other OGC standards.

Short synopsis: Before WFS 1.1.1 the only sure thing was that the axis
order was LON/LAT when the notation "EPSG:4326" was used to define the CRS
and otherwise was undefined.  For WFS 1.1.1 and later, the OGC Axis Order
policy was in force which meant and still means that the axis order is
defined by the CRS being referenced, such as lat/lon for EPSG 4326.

The longer answers is:

How any WFS instance interprets axis order depends on the version of the
WFS standard implemented and the notation being used to specify the CRS.

Based on the WMS 1.0 model, WFS 1.0.0 used the notation EPSG:XXXX for
specifying CRSs.  The implication was (although it was never explicitly
stated) that the WFS would do what WMS did and what the WMS did was to say
that for EPSG:4326 the axis order was LON/LAT.  This was actually also
consistent with GML 2.1.1. For example:

<gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opengis.net_gml_srs_epsg.xml-234326&d=DQMFaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=LCXhcrMdvdcRNz8NUgOEV1cYOakNFpC9sSTsSszC0Kc&m=HY5mDJJy4-L8dvfBgWuyrG9fxDiNEyFRZNZCetAE2kY&s=cz2ENba-ejcGrGosCxt7VCq5sYUHu7GlMCLq3G1jO2M&e=>
">
         <gml:coordinates>-180.0,-90.0 180.0,90.0</gml:coordinates>
</gml:Box>

The WMS 1.0 standard did not say anything about any other EPSG code and so
other CRS behavior was undefined.  As a result, most WFS 1.0.0
implementations stuck with LON/LAT regardless of the EPSG code being used.

WFS 1.1.0 specified several notations for defining the CRS: EPSG:XXXX,
http://www.opengis.net/gml/src/epsg.xml#XXXX
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opengis.net_gml_src_epsg.xml-23XXXX&d=DQMFaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=LCXhcrMdvdcRNz8NUgOEV1cYOakNFpC9sSTsSszC0Kc&m=HY5mDJJy4-L8dvfBgWuyrG9fxDiNEyFRZNZCetAE2kY&s=vcSZ-tEvudUXHYfE6HX2WUCkg5qjM9X5ULCLBSADUkw&e=>,
urn:EPSG:geographicCRS:XXXX.  The EPSG:XXXX notation was maintained for
backward compatibility with WFS 1.1. As such, a WFS implementation instance
would behave as it did in WFS 1.0.0 (i.e. LON/LAT for EPSG:4326, undefined
otherwise).  The other two notations were meant to follow the then being
developed OGC Axis Order policy which eventually provided clear policy
guidance on how to express and document axis order. The recommended option
is to use the axis order as defined in the EPSG CRS definition.  However,
at the time WFS 1.1 was being processed the Axis Order policy and notation
were still in flux. Ultimately the URL and URN notations specified in the
WFS 1.1 standard were invalid.  This problem was, however, addressed in the
WFS 1.1.1 corrigendum. Unfortunately, for some reason that corrigendum was
never published thereby increasing the WFS axis order confusion. This
oversight is being addressed by OGC staff.

Which brings us to WFS 1.1.1 and 2.0.X.  In these versions, the same Axis
Order policy is specified: Do what the EPSG CRS definition says. Also, at
the same time the srsName expression changed to the http uri notation (i.e.
http://www.opengis.net/dev/crs/epsg/0/xxxx
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opengis.net_dev_crs_epsg_0_xxxx&d=DQMFaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=LCXhcrMdvdcRNz8NUgOEV1cYOakNFpC9sSTsSszC0Kc&m=HY5mDJJy4-L8dvfBgWuyrG9fxDiNEyFRZNZCetAE2kY&s=otM5bDnCQOb9DY-U_pSooY0tHUmXzTpcwfIOXZvwxyk&e=>).
This is because in 2010 the OGC policy changed regarding how to identify
resources. The OGC moved from urn's to using URLs as identifiers. Even so,
the initial version of WFS 2.0 used the URN notation
(urn:ogc:def:crs:EPSG:<ver>:XXXX). This changed in WFS 2.0.2 (corrigendum).
All of the urn references were changed to URLs with notes on what the older
"urn" strings were.
Which brings us to the GeoServer documentation. That documentation is not
quite right and should be corrected to reflect reality and what is actually
in the various versions of the WFS standards. Further, the GeoServer
documentation mentions the use of "urn:x-". I am not sure where that is
coming from as none of the WFS standards from WFS 1.0 and later use that
notation.

Regards

Carl
-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

"When the power of love overcomes the love of power the world will know
peace." Jimi Hendrix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20161019/9f180f36/attachment.html>