Opened 7 years ago

Closed 3 years ago

Last modified 2 years ago

#4041 closed defect (fixed)

WFS does not use the layer bounding box

Reported by: ralcazar Owned by: Even Rouault
Priority: high Milestone: 2.0.0
Component: OGR_SF Version: 1.8.0
Severity: normal Keywords: wfs wgs84
Cc:

Description

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.

Change History (8)

comment:1 Changed 7 years ago by Even Rouault

Owner: changed from warmerdam to Even Rouault

comment:2 Changed 7 years ago by 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)

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by 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)

comment:5 Changed 3 years ago by 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.

comment:6 in reply to:  5 Changed 3 years ago by Even Rouault

Resolution: fixed
Status: newclosed

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

comment:7 Changed 3 years ago by Even Rouault

Milestone: 2.0

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

comment:8 Changed 2 years ago by Even Rouault

Milestone: 2.02.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.