[gdal-dev] Re: Ogr2ogr, WFS 1.1.0, -spat and gml:Box

[Even Rouault]

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

When developing the WFS driver, I have had problems with some servers when I 
was using initialy KVP BBOX, and combined with attribute filtering. Using 
Filter Encoding in my experience enable to use both spatial and attribute 
filtering quite reliably. I'd really really hesitant to change that. I had too 
many problems to found requests that worked well with the various WFS servers 
exisiting, so perhaps in 5 years when all servers will be completely 
compliant, someone might reconsider changing the logic ;-)

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

Well, you are supposing incorrectly ;-) GDAL does actually to interpret the 
axis ordering for *geographic SRS* (unfortunately it does not interpret it for 
projected SRS : http://trac.osgeo.org/gdal/ticket/4329 ) if they are reported 
as urn:ogc:def:crs:EPSG::XXXX by GetCapabilities. It will do the axis order 
swapping when issuing spatial filters, and when reading the GML content, it 
will return in the usual GIS friendly long,lat order (unless the 
GML_INVERT_AXIS_ORDER_IF_LAT_LONG configuration option is set to NO in which 
case it will return in the order found in the GML file).

I'm afraid it is a bit confusing, but just have a look at the difference 
between (look at the subtle difference in the layer SRS too):

ogrinfo -ro "WFS:http://www.tinyows.org/cgi-bin/tinyows?TYPENAME=tows:world" -
al

and

ogrinfo -ro "WFS:http://www.tinyows.org/cgi-bin/tinyows?TYPENAME=tows:world" -
al --config GML_INVERT_AXIS_ORDER_IF_LAT_LONG NO

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

Yes, I also noticed issues with TinyOWS, WFS 1.1.0 and axis order. The 
following request -I think- should return features in Europa, but it returns 
feature in South Africa.

http://www.tinyows.org/cgi-
bin/tinyows?TYPENAME=tows:world&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&FILTER=%3CFilter%20xmlns=%22http://www.opengis.net/ogc%22%20xmlns:tows=%22http://www.tinyows.org/%22%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CBBOX%3E%3CPropertyName%3Etows:the_geom%3C/PropertyName%3E%3Cgml:Box%3E%3Cgml:coordinates%3E30.0000000000000000,-20.0000000000000000%2055.0000000000000000,20.0000000000000000%3C/gml:coordinates%3E%3C/gml:Box%3E%3C/BBOX%3E%3C/Filter%3E

(generated by ogrinfo  -ro "WFS:http://www.tinyows.org/cgi-
bin/tinyows?TYPENAME=tows:world" -al  -spat -20 30 20 55 )

> I do not know the
> situation with Mapserver, Geoserver and deegree.

In my experience : 3 servers and possibly >3 different behaviour depending on 
their different versions ;-)

> 
> 
> -Jukka Rahkonen-
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev