[Qgis-developer] broken WFS client commit

Richard Duivenvoorde rdmailings at duif.net
Sun Oct 25 09:15:02 PDT 2015

Hi devs,

Looking at this commit:


it looks like there there was a checkbox introduced which forces the WFS
provider to add a bbox to the requests.

but this was already working via the 'cached' option.

Currently for the use-case where you get features from a server which
has maximized number of features to return, this is broken, see also [0]

So my question to devs:
- what was the idea of adding this option
- what was the plan to make it play right with the old implementation
- can we come with plan to make it work again

[0] http://hub.qgis.org/issues/13117

My take:

- the 'caching' option never had a real 'caching'-mechanism, because
(correct me if I'm wrong), we do/can not work with features with id's,
so we cannot really cache the features... so the mechanism used was to
resend a getFeatureRequest including a bbox filter for every pan/zoom

- the 'use current bbox' is practically doing the same, BUT only uses
the initial bbox, so does not resend the 'current' bbox

Scenario's I see

- a wfs server serving out an amount of features which can be retrieved
in one take by QGIS (essentially a data-download)
- a wfs server serving out just too much features to retrieve
(practically for QGIS, or because it is a 'limiting' server)
(Am I missing something?)

Should we maybe 'rename' the 'caching' option to be an option which
makes QGIS resend a feature request every zoom/pan?

Or any other ideas/options?


Richard Duivenvoorde

More information about the Qgis-developer mailing list