Even Rouault <even.rouault <at> mines-paris.org> writes: > > Le lundi 02 janvier 2012 16:39:17, Jukka Rahkonen a écrit :
... > > > > So it is WFS 1.1.0 request with the BBOX filter. But is it OK to give BBOX > > as GML2 gml:Box if the service is WFS version 1.1.0? I have been thinking > > it should be using GML3 and gml:Envelope instead. > > I suppose you're right. I didn't recall all the details, so I had a look at > the code, and here's the answer : > .... > So basically it seems that most servers are tolerant and will accept gml:Box. > But some servers that should accept gml:Envelope don't. So the default > behaviour is to use gml:Box, except in cases where we know it won't be > accepted (but the server mentionned in the comment is no longer online, and I > cannot find another one that doesn't accept <gml:Box>) > > It would perhaps be more reasonable to implement the reversed logic from a > theoretical point of view, but unless you can point me to a server that > doesn't like the current logic, I'm quite hesitant to change that How about using plain key-value pair BBOX instead of Filter Encoded BBOX? GDAL is using GET method anyway. With WFS 1.0.0 it would be simple and reliable. The four parameter BBOX would always mean the default srsName of the feature type and it would always follow the Easting-Northing order. Evil thing with WFS 1.1.0 is that KVP BBOX defaults to EPSG:4326. Therefore the BBOX should be given with five parameters to include srsName. Client must check first the GetCapabilities to know the default srsName but GDAL seems to do it anyway. I suppose that GDAL does not try to interpret the the axis order used for the -spat parametes so it would be up to user to give it right. I am not sure how well different WFS servers support the five parameter KVP BBOX with WFS 1.1.0. I know that TinyOWS supports it but it behaves in a wrong way with axis order with some EPSG codes. I do not know the situation with Mapserver, Geoserver and deegree. -Jukka Rahkonen- _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
