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

[Andrea Aime]

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.

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20161020/769db885/attachment-0001.html>