[OSGeo-Standards] Web Feature Service (WFS) and Axis Order
Carl Reed
carl.n.reed at gmail.com
Thu Oct 20 09:10:20 PDT 2016
Andrea -
Thank you for the well considered response. I appreciate your observations
related to implementation ambiguities, such as in cascading WFS instances
and axis order variations.
Please note that I was not suggesting that GeoServer be changed. I
completely understand that there is a very large community of GeoServer
users/developers. As such making changes to the GeoServer WFS 1.1.0 does
not make sense. I completely agree with you. Just to be clear, the WFS axis
order requirements did not change until version 1.1.1 (WFS Corrigendum). As
1.1.1 was never published, there are no CITE tests or reference
implementations - or implementations for that matter! My intent was to
provide historical context and relevant information related to the
evolution of axis order and the WFS standard.
However, I am a bit confused by the use of urn:x-ogc usage. The official
OGC urn policy and IETF RFC were approved and published in 2008:
https://tools.ietf.org/html/rfc5165 . Further, the official WFS 1.1.0
reference implementations (see below) do not use the x-ogc syntax.
Reference implementations for WFS 1.1.0
lat/lon: urn:ogc:def:crs:EPSG::4326
interactive instruments: urn:ogc:def:crs:EPSG::4326
I suspect - as you suggest - that both the CITE and GeoServer WFS 1.1.0
implementation decisions were impacted by the OGC policy transition related
to the concurrent approval of the official OGC urn policy and by the
IETF/IESG.
I agree that if the WFS 1.1.0 CITE tests are still using the x-ogc syntax
that this is a "leftover". Perhaps Luis Bermudez should be involved in this
discussion?
As to your observation, "Humble suggestion, for the future specifications,
try to avoid changing the syntax whenever possible, and focus on adding
extra functionality instead."
This may seem strange as I facilitated the OGC standards program for many
years but I agree with you :-) I designed and developed software for many
more years than I did standards work so I completely understand your
recommendation. But understand that facilitating the process meant not
dictating to the members - I could suggest but not mandate.
Thanks again for your feedback. Much appreciated.
Regards
Carl
On Wed, Oct 19, 2016 at 9:41 PM, Andrea Aime <andrea.aime at geo-solutions.it>
wrote:
> On Wed, Oct 19, 2016 at 6:21 PM, Carl Reed <carl.n.reed at gmail.com> wrote:
>
>> 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).
>>
>
> This indeed sort of what GeoServer implements in WFS 1.1.0, except that
> all WFS 1.0 SRS syntaxes produce a lon/lat order, so if you expect
> http://www.opengis.net/gml/srs/epsg.xml#4326 to produce lat/lon in WFS
> 1.1 then we have a problem, because the current implementation has been
> like that for 8+ years and there is a lot of applications relying on it to
> force the outputs in lon/lat order despite using WFS 1.1.
> The opposite axis order is the standard, I know, but it never became
> popular among the GeoServer user base, and I'd venture to say, in all OSGeo
> projects in general... GeoServer own WFS cascading support has one
> configuration flag allowing the admin to specify if the cascaded server is
> using lat/lon or lon/lat axis order in its responses, and a separate one to
> specify if the server wants spatial filters to be specified in lat/lon or
> lon/lat order, because we have found at least 3 out of 4 of those
> variations in the wild (yes, servers that do return lat/lon but that
> require lon/lat in filters).
>
> The http://www.opengis.net/gml/srs/epsg.xml#xxxx notation order in WFS
> 1.1.0 is not something we can just "fix" 8 years down the road, the change
> would break too many existing clients (see at the bottom of the mail for a
> funny example), I would favor making that behavior configurable instead.
>
> GeoServer does not have an implementation of WFS 1.1.1, if someone is
> wiling to sponsor it GeoServer could have an implementation the "new" axis
> order rules there.
>
>
>> 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.
>>
>
> Lacking a official WFS 1.1.1 spec to read, I have a question, how does a
> client tell if a server is a WFS 1.1.1 or a WFS 1.1.0 version? This change
> in axis order for the deprecated EPSG:xxxx syntax is likely to increase
> confusion about axis order even further. I agree with Even, it would be
> best to just stay away from the EPSG:xxxx notation... except for the fact
> that there is a very common need to ask data forced in east/north order and
> the current specs are not offering
> a solution to that problem.
>
> While we are on the topic, how about the interaction between axis order
> and output formats? In GeoServer WFS 1.1 if someone asks for a
> zipped-shapefile format a lat/lon ordered one is returned, that common
> software does not actually reads properly (even if the prj states the axis
> order).
> One might say that this is a legacy format, but then there is geopackage,
> which also seems to mandate east/north ordering, see
> https://github.com/opengeospatial/geopackage/issues/54
> So it makes me wonder what the guidance would be here... should we return
> an axis order other than the standard defined one, and user requested one
> on occasion (e.g., when using srsName), depending on the chosen output
> format?
>
>
>>
>> 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.
>>
>
> I echo Jody's feedback, can you pinpoint what should be fixed, considering
> that GeoServer does not implement WFS 1.1.1, but only WFS 1.1.0?
>
>
>> 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.
>>
>
> I managed to dig up this old conversation on the topic, apparently this
> syntax was mandated by the original WFS 1.1 CITE tests (e.g., the only way
> to be officially compliant) and
> then the implementation got modified to follow the "urn:ogc" approach
> instead:
>
> http://osgeo-org.1560.x6.nabble.com/srsName-urn-x-ogc-vs-
> urn-ogc-more-headaches-and-long-term-decisions-td3823432.html
>
> So if the above is correct no server using the official syntax would have
> passed the original WFS 1.1 CITE tests.
>
> It is however to notice that even today OGC own WFS 1.1 CITE tests are
> using that syntax during compliance runs, so a server not recognizing it
> would fail to pass the suite:
>
> https://github.com/opengeospatial/ets-wfs11/blob/master/src/
> main/scripts/ctl/basic/GetFeature/logicalops/wfs-1.1.
> 0-Basic-GetFeature-tc101.1.body.xml
>
> This is probably a leftover, the other tests are using the "urn:ogc"
> syntax. I don't see any test using the new URL based syntax though.
>
> As a side note, even today GeoServer WFS 1.1 defaults to the urn:x-ogc
> syntax when generating GML 3, e.g.:
> http://demo.geo-solutions.it/geoserver/tiger/ows?service=WFS
> &version=1.0.0&request=GetFeature&typeName=tiger:tiger_roads&maxFeatures=1
>
> This is the default, however an admin can go and decide to use the
> "ogc:urn" syntax by changing the GML generation settings, see the available
> SRS styles here (our CITE test configuration does indeed use the "ogc:urn"
> syntax):
> http://docs.geoserver.org/stable/en/user/services/wfs/webadmin.html#gml
>
> It might be argued that in 2016 the default could be set to use the
> "ogc:urn" syntax indeed.... not that there is much feedback against it
> honestly, and changing it is likely going to break some client, many
> applications are actually still "hand built" for a specific purpose and are
> rather fragile in terms of what output they can handle.
>
> About that, funny aside, a few days ago I have been asked why the
> following WFS 2.0 request was not working against GeoServer:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <GetFeature xmlns="http://www.opengis.net/wfs/2.0" xmlns:DigitalGlobe="
> http://www.digitalglobe.com"
> xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:ogc="
> http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/
> 2001/XMLSchema-instance"
> service="WFS" startIndex="0" maxFeatures="50" version="2.0.0"
> xsi:schemaLocation="http://www.opengis.net/wfs/2.0
> http://schemas.opengis.net/wfs/2.0/wfs.xsd">
> <Query typeName="foo:bar">
> <ogc:Filter>
> <ogc:Intersects>
> <gml:Polygon srsDimension="2" srsName="http://www.opengis.
> net/gml/srs/epsg.xml#4326">
> <gml:exterior>
> <gml:LinearRing>
> <gml:posList>-180.0 -90.0 180.0 -90.0 180.0 90.0 -180.0 90.0
> -180.0 -90.0
> </gml:posList>
> </gml:LinearRing>
> </gml:exterior>
> </gml:Polygon>
> <ogc:PropertyName>geometry</ogc:PropertyName>
> </ogc:Intersects>
> </ogc:Filter>
> </Query>
> </GetFeature>
>
> The amount of issues in it is a bit comical (maxFeatures? typeName?
> ogc:Filter? ogc:Propertyname as the second argument?),
> but mind, this is not the work of a grad student, it's the work of a
> professional development team in a large defense and aerospace corporation.
> So when you think axis order is confusing, remember there are other
> sources of confusion coming from the continuous changes in the
> specifications,
> and people having troubles piecing them together. Humble suggestion, for
> the future specifications, try to avoid changing the syntax
> whenever possible, and focus on adding extra functionality instead.
>
> Best Regards
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054 Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> -------------------------------------------------------
>
--
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/20161020/08a18727/attachment-0001.html>
More information about the Standards
mailing list