[CITE-Forum] Axis order change breaks standard compatibility in WFS 1.1?

Andrea Aime andrea.aime at geo-solutions.it
Mon Dec 9 03:58:45 EST 2013


On Mon, Dec 9, 2013 at 9:10 AM, Sebastian Goerke <goerke at lat-lon.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Andrea,
>
> 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
> parameter BBOX):
>
> If the crsuri is not specified then the 2-D coordinates shall be
> specified using decimal degrees and WGS84 as described in [15].
>
> 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:
>
> https://github.com/opengeospatial/teamengine/issues/16


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...

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20131209/d060ef58/attachment.html>


More information about the CITE-Forum mailing list