[CITE-Forum] Axis order change breaks standard compatibility in WFS 1.1?
rmartell at galdosinc.com
Wed Dec 11 18:23:23 EST 2013
Unlike the unambiguous statement in WFS 1.1, WFS 2.0 doesn't specify a default CRS for the
BBOX param. So it would seem that interpreting a BBOX parameter without a CRS reference appended
is problematic in WFS 2.0*. It also refers to WSC, cl. 10.2.3 (the text is unchanged from WSC 1.0), which states:
If no CRS URI value is included, the applicable CRS must be either:
a) Specified outside the bounding box, but inside a data structure that includes this bounding box, as specified for a specific OWS use of this bounding box type
b) Fixed and specified in the Implementation Specification for a specific OWS use of the bounding box type.
WFS 1.1 went with option (b) as noted previously. Since there is no KVP parameter to satisfy (a), and (b) is overlooked, it
would seem that in WFS2 a BBOX param lacking a terminal CRS reference is invalid.
* The WFS2 test suite currently doesn't use the BBOX param, but uses FILTER instead so the issue has been
avoided so far.
From: CITE-Forum [mailto:cite-forum-bounces+rmartell=galdosinc.com at lists.opengeospatial.org] On Behalf Of Andrea Aime
Sent: Monday, 09 December, 2013 00:59
To: Sebastian Goerke
Cc: cite-forum at lists.opengeospatial.org
Subject: Re: [CITE-Forum] Axis order change breaks standard compatibility in WFS 1.1?
On Mon, Dec 9, 2013 at 9:10 AM, Sebastian Goerke <goerke at lat-lon.de<mailto:goerke at lat-lon.de>> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
this issue is currently discussed on the WFS SWG. The problem here is:
BBOX != BBOX Filter (following FE 1.1.0). The behaviour for the
defaultSRS is also described within 9.2 of the WFS spec (and only
meant for the xml representation)(What is described here is covered by
the value of the KVP parameter FILTER).
Section 14.3.3 of the spec describes the following (Describung the KVP
If the crsuri is not specified then the 2-D coordinates shall be
specified using decimal degrees and WGS84 as described in .
15 is OWS Common. There it is mentioned, that the axis order for WGS
84 is long/lat.
I see, found it. That's quite troublesome, as the WFS 1.1 spec and tests
have been around for so much time, and the tests forced implementors to
the current implementation too.
Imho the chance to change this test without causing major pain
in the "real world" is long gone.
I totally agree your arguments regarding interoperability and that the
testsuite worked the way it was for years (meaning that ALL certified
products handle it the way we both expect it to work.).
Both reference implementations are failing the test now. But I
understand the argument from the standards view, that WGS 84 with
long/lat order shall be used.
We need a strategy here. The plan is, to discuss the general issue at
today's CITE dev meeting:
My suggestion... if a change really need to be made, fix this for later standards?
For example, how about WFS 2.0? I'm sure GeoServer behaves in the
same way as WFS 1.1 when hit with a BBOX in WFS 2.0
At the very least, the CITE tests for WFS 2.0 are fresh out no?
That said, have an inconsistent behavior between the BBOX in KVP and the
BBOX in XML is going to cause much paint down the road, at least the way
they are implemented now, they are consistent.
If I could have bee paid for the many times I had to explain about the various
axis order issues introduced by WFS 1.1 and WMS 1.3 (with all the people I
met so far expecting a easting/northing orientation, and claiming the software
was buggy because we use lat/lon instead) I could have bought a nice car by now.
This is going to make things worse, not only the axis order is inconsistent with
the rest of the standard, but the data is being queried in a SRS that is not its native one...
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
Ing. Andrea Aime
Via Poggio alle Viti 1187
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CITE-Forum