[CITE-Forum] Axis order change breaks standard compatibility in WFS 1.1?
andrea.aime at geo-solutions.it
Sat Dec 7 13:07:08 EST 2013
On Sat, Dec 7, 2013 at 7:04 PM, Andrea Aime <andrea.aime at geo-solutions.it>wrote:
> On Sat, Dec 7, 2013 at 6:23 PM, Andrea Aime <andrea.aime at geo-solutions.it>wrote:
>> I was looking into a fix that is causing a failure and I'm not really
>> following the
>> reasoning behind the change:
>> 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:
>> 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
*interpreted to be equivalent to the <DefaultSRS> value of the queried
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
in absence of an explicit srs stating otherwise, no?
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
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