Martin Davis wrote:
That's interesting feedback, Jukka. It sounds like our use case is very different to yours. We are using
WFS to return vector features for the classic Identify map UI function. It is very puzzling for users to
have features returned which obviously don't intersect the bounding box they drew!.
It is absolutely puzzling and we have pretty many questions in Geoserver users archives about why BBOX and Intersects gives different results even the WFS standard says that they mean the same:
"The bounding box parameter, BBOX, is included in this specification for convenience as a shorthand representation of the very common a bounding box filter which would be expressed in much longer form using XML and the filter encoding described in [3]. A BBOX applies to all feature types listed in the request".
However, the loose BBOX is often as useful with WFS than with WMS because it is faster and more friendly to the database backends. No user who adds a WFS layer into OpenLayers application with http://dev.openlayers.org/releases/OpenLayers-2.7/doc/apidocs/files/OpenLayers/Layer/WFS-js.html really needs strictly accurate results and situation is the same when adding WFS layers into uDig project. If it was you who implemented the ingenious dynamic PostGIS layers into OpenJUMP then you should know best the reason to use && instead of ST_Intersects.
I believe that our users usually do not get or recognize any extra features because we play almost totally with points and small polygons and extra features are rare.
Andrea suggested using an Intersects filter as well, but this is much less convenient for us, since we
are querying multiple layers at once, and thus (as I understand it) would have to encode multiple
Filter conditions, one for each layer. (And in addition, have metadata about the geometry
column name on the client).
Very understandable. I do not program anything but I know I would hate to do it in a complicated way if one simple BBOX would be enough.
I'm not sure I follow your last point. Using Loose BBOX, users can only assume that they will get
back all features which intersect the BBOX, and *possibly* some unknown and near-random set
of other features as well. So I can't see that they have any basis for concern if the server only
returns the exact set of intersecting features. And I don't see that this depends on how other
servers operate. I don't see anywhere in the WFS spec where it encourages *more* features
to be returned than strictly necessary. The Loose BBOX is a reasonable heuristic to allow
faster querying for rendering purposes, but when WFS is being used for data retrieval purposes
I think it should return the strict result.
You are right, it was late nigh logic that does not totally hold water in the daylight. I mixed also the real end users and folks who are developing kind of middleware like a general purpose WFS based UI identify tool for programs like OpenLayers or QGIS. Users will await that such a tool gives only strict results. However, if we do not talk about a tailored enterprise application then the developer can't control which WFS servers the users are going to use. And because there are Geoservers with strict and loose BBOXes in the wild the result is inevidently that identify tool that sends simple BBOX queries will show different results from different WFS servers even they were all Geoservers. That will be puzzling too and developers will get feedback from the field. I believe that a good universal identify tool that gives similar and correct results from all possible WFS servers should do a final filtering on the client side by applying the BBOX again into the result set.
We would like to have this option available, but if it's too much of a change to have it enabled
by default we can tolerate enabling it manually.
I do not have strong opinions but I feel that at least for an open WFS server the loose BBOX is a better default value. It is more friendly for WFS server and database and application developers can turn the server to return strict results by themselves if they use Intersects in filters. If it is set into the strict mode then there is no way to turn it into the fast and loose mode but it will be strict always.
-Jukka Rahkonen-
On Mon, Jan 20, 2014 at 2:26 PM, Rahkonen Jukka (Tike) <jukka.rahkonen@anonymised.com.1245...> wrote:
Hi,
For what we have used WFS since 2006 loose BBOX does make more sense. Typically it is used for getting vectors to fill the screen or then our users draw a very approximated box. Loose BBOX brings a bit more vectors but they come faster. I do not think that in any of our applications BBOXes given by the users are so accurate that it would be worth going to a strict and slow BBOX handling. I trust that you have different use cases.
I am not sure if uDig is still making a new BBOX query each time when user is panning or zooming but if it does, then again loose BBOX is preferred. Just the same for QGIS 2.0 when it is used in a non-caching mode. Especially with Oracle which is much less slow with loose BBOX than with the strict one.
Why not just to use Intersects if accurate results are needed and reserve BBOX for the fast ones? If it is up to server admin to change the behaviour, how can the poor users know what they will get back with BBOX? Is it friendly to learn them trust that BBOX with Geoserver is accurate if it sometimes is, sometimes not? If we love our users we would at least check and document how at least deegree 3 and Mapserver 6.4 are handling BBOX vs. Intersects, perhaps also TinyOWS and a few non-open WFS programs.
Regards,
-Jukka Rahkonen-
________________________________________
Lähettäjä: Martin Davis [mtnclimb@anonymised.com]
Lähetetty: 20. tammikuuta 2014 19:33
Vastaanottaja: geoserver-devel@lists.sourceforge.net
Aihe: [Geoserver-devel] Loose BBOX for WMS but not WFS?
Moving this thread to the devel list...
Andrea has proposed some options for implementing this, which he will probably reply with. From a use perspective we have the following comments:
- We have no use case that requires a loose BBOX for WFS
- If Loose BBOX is provided as an option for WFS, it would be good to have "strict BBOX" as the default configuration
- We are using the URL-encoded format of WFS, querying multiple feature types with a single BBOX (from OpenLayers). Andrea pointed out that using an explicit rectangle intersection filter should avoid the Loose BBOX issue, but this is much less convenient than the simpler BBOX query.
- Loose BBOX is fine for WMS if it speeds up rendering. It's good to have this as the default configuration
Martin
On Fri, Jan 17, 2014 at 10:54 PM, Martin Davis <mtnclimb@anonymised.com> wrote:
Is there any way to specifiy a Loose BBOX for WMS (where it provides better performance) but not for WFS (where it causes incorrect results for queries)?
No, there is not, it has been in my wish list for a while: http://jira.codehaus.org/browse/GEOS-1762
It seems nobody cared about it (or had time) back when I've tried to discuss the topic, no answers:
http://osgeo-org.1560.x6.nabble.com/Loose-bbox-for-the-last-time-hopefullly-td4296115.html
Our target environment is Oracle 12c. We absolutely need accurate answers for WFS queries, but would also like to have as fast WMS rendering as possible.
Maybe a solution would be not to use BBOX, but an OGC intersection filter with a polygon that represents the BBOX, this should not be
turned into a fast BBOX (hopefully, at least)
Cheers
Andrea
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel