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

Wed Oct 19 16:25:47 PDT 2016

Hi Jody -

Glad to help!  The page I read was the "basics" page.

However, I just took a quick look at the "order" page. That page also
references urn:x-ogc. The x should be removed. To help, I will review the
"order" page more closely.

Regards

Carl

On Wed, Oct 19, 2016 at 5:09 PM, Jody Garnett <jody.garnett at gmail.com>
wrote:

> Thanks Carl that is a great link. Can I confirm which "GeoServer" axis
> order page you wish corrected?
> - http://docs.geoserver.org/latest/en/user/services/wfs/basics.html
> - http://docs.geotools.org/latest/userguide/library/referencing/order.html
>
> We have a release coming up and I would love to catch any corrections (and
> link to http://www.ogcnetwork.net/axisorder).
>
> --
> Jody Garnett
>
> On 19 October 2016 at 11:21, Carl Reed <carl.n.reed at gmail.com> wrote:
>
>> 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
>>
>> _______________________________________________
>> Standards mailing list
>> Standards at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/standards
>>
>
>

-- 
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/d569fd7f/attachment-0001.html>