WFS does not use the layer bounding box

[ralcazar]

The WFS is not using the layer bounding boxes correctly, as the comparison used to know if the SRS is WGS84 is wrong:

char* pszProj4 = NULL; if (poSRS->exportToProj4(&pszProj4) == OGRERR_NONE) {

if (strcmp(pszProj4, "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ") == 0) {

poLayer->SetExtents(dfMinX, dfMinY, dfMaxX, dfMaxY);

} ...

}

the exported proj4 string does not have the ellps component inside (exportToProj4 returns "+proj=longlat +datum=WGS84 +no_defs" ) (see ticket http://trac.osgeo.org/gdal/ticket/3737)

Tested using XML with URL ​http://geohub.jrc.ec.europa.eu/effis/ows (VIA: ​http://www.paolocorti.net/2011/03/23/a-quick-look-at-the-wfs-gdal-driver/)

It is "easily" solved by changing the comparison to

strcmp(pszProj4, "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ") == 0

strcmp(pszProj4, "+proj=longlat +datum=WGS84 +no_defs ") == 0

but maybe there is a cleaner way to do it.

[Even Rouault]

Reading ​http://trac.osgeo.org/mapserver/ticket/2579 and ​http://lists.opengeospatial.org/pipermail/wfs-dev/2007-October/thread.html, I can see there's a huge possible confusions about the order of coordinates reported in WGS84BoundingBox or LatLongBoundingBox in WFS 1.1. So I'm not very enthusiastic of making changes because there's a high risk that I don't understand the spec correctly and especially that the WFS server guys don't too (or they don't agree between them and/or with me). I've already seen a lot of different behaviours between servers in other areas of the WFS spec when developing the driver...

Currently if the driver doesn't decide to read the extent, it will fallback to computing it from the feature geometry, which should be more exact, althoug slower... (which is currently the case for other projections which are not WGS84)

[ralcazar]

After reading your links, I see there is lot of confusion

However, reading the WFS 1.1.0 standard (​http://portal.opengeospatial.org/files/?artifact_id=8339):

"The <WGS84BoundingBox> element is used to indicate the edges of an enclosing rectangle in decimal degrees of latitude and longitude in WGS84. Its purpose is to..."

seems pretty specific about the content of WGS84BoundingBox.

---

Anyway, for me the comparison strcmp(pszProj4, "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ") == 0 seems to have been broken due to the changed http://trac.osgeo.org/gdal/ticket/3737

It could just be solved by changing the comparison to:

if (strcmp(pszProj4, "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ") == 0

or

strcmp(pszProj4, "+proj=longlat +datum=WGS84 +no_defs ") == 0)

I do not think this change can break anything.

---

The problem with the fallback of computing it from the feature geometry is that makes the driver unusable for sources with many features over slow connections.

[Even Rouault]

r22183 /trunk/gdal/ogr/ogrsf_frmts/wfs/ (WFSServersList.txt ogr_wfs.h ogrwfsdatasource.cpp): WFS: use the layer bounding box for EPSG:4326 layers (restricted to GEOSERVER for now) (#4041)

[Jukka Rahkonen]

I do not quite understand for what reason the bounding box of WFS layer is checked? If it is an alternative for the heavy way of getting extents by reading the whole feature type with GetFeature then it is perhaps OK. However, even in GeoServer it is easy to configure the server to advertise wrong bounding box. And after inserting or deleting features the bounding box is not recalculated automatically so as its best the advertised bounding box is only a hint.

If the aim is to prevent doing some operations if BBOX of the request is outside the advertised bounding box of the feature type I think it usually does not help much and sometimes it does a wrong thing. WFS servers typically send an empty response very fast if the BBOX of query is outside the data area and spatial index of the source data works. Checking the advertised BBOX before transactions could prevent inserting new features with WFS-T if they would make the bbox wider.

[Even Rouault]

Replying to jratike80:

I do not quite understand for what reason the bounding box of WFS layer is checked? If it is an alternative for the heavy way of getting extents by reading the whole feature type with GetFeature then it is perhaps OK.

Yes, the aim is to use if to have OGRLayer::GetExtent() to return a fast response.

However, even in GeoServer it is easy to configure the server to advertise wrong bounding box. And after inserting or deleting features the bounding box is not recalculated automatically so as its best the advertised bounding box is only a hint.

Well, that would be the server fault, but indeed my tests during initial development showed that the reported bounding box was globally not accurate (for the reason you give, or lat/lon inversion, etc...)

For all above reasons, I don't think we should do more than that, so closing the ticket

[Even Rouault]

trunk r28942 "WFS: add a TRUST_CAPABILITIES_BOUNDS open option, that can be set to YES to trust layer bounds declared in GetCapabilities response, for faster GetExtent() runtime (#4041)"

[Even Rouault]

Milestone renamed