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

Sebastian Goerke goerke at lat-lon.de
Mon Dec 9 03:10:16 EST 2013


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

Am 07.12.2013 19:07, schrieb Andrea Aime:
> On Sat, Dec 7, 2013 at 7:04 PM, Andrea Aime 
> <andrea.aime at geo-solutions.it
> <mailto:andrea.aime at geo-solutions.it>> wrote:
> 
> On Sat, Dec 7, 2013 at 6:23 PM, Andrea Aime 
> <andrea.aime at geo-solutions.it
> <mailto:andrea.aime at geo-solutions.it>> wrote:
> 
> Hi, I was looking into a fix that is causing a failure and I'm not 
> really following the reasoning behind the change:
> 
> https://portal.opengeospatial.org/services/srv_public_issues.php?call=viewIssue&issue_id=898
>
>  Basically, it seems the reporter claims that if the SRS for the 
> bbox in a request is not specified, then the default SRS should be
> used. No argument there, yet, both Deegree and GeoServer
> capabilities responses state:
> 
> 
> <DefaultSRS>urn:ogc:def:crs:EPSG:6.11.2:4326</DefaultSRS> 
> <DefaultSRS>urn:ogc:def:crs:EPSG::4326</DefaultSRS>
> 
> Which are lat/lon oriented. Yet, the reporter states the order of
> the axis in the GET request should be lon/lat oriented because
> that's the order of urn:ogc:def:crs:OGC:1.3:CRS84" And that's where
> I've completely lost the discussion... where in the world is that
> CRS used in the capabilities documents? The default srs is
> explicitly declared and it's not CRS84.
> 
> 
> By the way, I did a search in the WFS 1.1 standard, the CRS84 SRS
> is not mentioned anywhere. So I don't see how it can be the
> "default" one?
> 
> 
> Also, found the following in the Filter 1.1 specification, which
> seems pretty clear to me:
> 
> *if the literal geometry SRS is unspecified, then the literal
> geometry SRS shall be* *interpreted to be equivalent to the
> <DefaultSRS> value of the queried feature type.*
> 
> So, both Deegree and GeoServer declare a DefaultSRS in lat/lon
> order, it follows that the BBOX parameter in the GEtFeature request
> should be interpreted in lat/lon order too, in absence of an
> explicit srs stating otherwise, no?
> 
> 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
> 
> -------------------------------------------------------
> 
> 
> _______________________________________________ CITE-Forum mailing
> list CITE-Forum at lists.opengeospatial.org 
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum
> 

- -- 
l a t / l o n  GmbH
Aennchenstrasse 19               53177 Bonn, Germany
phone ++49 +228 18496-0          fax ++49 +228 18496-29
http://www.lat-lon.de            http://www.deegree.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKleugACgkQq1hDh4aJykLfMwCdE0gmbAbPkt8F1hKrS56dfLYD
4OsAn2kCgV/J1Xb15k9XW9tpugj0YZms
=nvJw
-----END PGP SIGNATURE-----


More information about the CITE-Forum mailing list