QGIS » QGIS Application

Looking through them using the search ("WFS bounding" and "wfs box"), the closest I can find is #8656

But that is about the server side.

Hi,

The MaxFeatures=1 request is perhaps fired for reading a sample of data for verifying the schema but I do not know, just guessing.

It looks like QGIS developers have not tested the client with any WFS layer which holds millions of features. Jonathan and I as WFS server admins consider that WFS clients should not be developed against anything with less than million features per feature type.

The old WFS client in QGIS had a check box for making a one-off BBOX query by using the bounds of map window as BBOX. That was quite a good and intuitive way for reducing the queries.

The new WFS driver has by default the "Cache features" box checked and that means reading the whole feature type. Unchecking the box changes behaviour and set client into live mode. Now the BBOX from the map is used and no features are cached. Every time user is panning or zooming a new GetFeature is sent. This is how uDig has always done it and I somehow guess that the motivation is to make WFS-T simple and reliable because all the features with the neighbouring features are for sure on the map. However, without zoom limit the client is sending oversized getfeatures when zoomed out and that will kill both server and client when the WFS layer is big.

I have a few suggestions and Jonathan will add more, I guess.

1) Have a MaxFeatures setting in a visible place in the dialogue window with default value at about 1000-10000.
2) Get back the "Use map window as BBOX" selection for one-off requuests.
3) The current default to read the whole feature type into local cache should be a special case and users should do something for selecting it.
4) When the live mode (no caching) is activated the client should automatically add MaxFeatures count into requests and there should also be a setting for max scaledenominator as an additional way to prevent crazy requests like "All the parcels for the whole UK". The default could be at around 1:100000.

At the moment the only way to utilize layers with millions of features is to
- Zoom close with a help of some other layer
- Add WFS layer with "Cache features" unchecked
- Don't zoom out before visiting layer style settings and setting enough strict scale limits for visibility. This will prevent crazy requests later.

Hi
jratike80 - wrote:

The MaxFeatures=1 request is perhaps fired for reading a sample of data for verifying the schema but I do not know, just guessing.

DescribeFeatureType does that though.

The new WFS driver has by default the "Cache features" box checked

Ah yes, I'd missed that. It makes a good interim solution to this problem. I don't think QGIS should try and cache the entire dataset in one go though but should do what MapInfo does - store things that have been requested in previous requests so they don't need to be re-requested.

1) Have a MaxFeatures setting in a visible place in the dialogue window with default value at about 1000-10000.

Good idea though probably better placed in a new ticket (feature request).

However I don't think the scale issue is one that can be addressed here. The user can already use "scale dependent visibility" and if they chose not to, that's their choice, same as for any other data source. The server admin if sane, will have put restrictions on what the max features can actually be so the client shouldn't be able to actually "harm" the server with oversized requests.

The problem is that sometimes it may make sense to put MaxFeature count to some relatively high value on the server side. I have it at 100000 on my personal server because it does not support paging and I have also users who need the whole big datasets. But if QGIS used wants to add such layer into a project just for getting a handful of features from a limited area he can set the "scale dependent visibility" only after reading data from WFS and that can be too late because if user was zoomed out he already got 100000 polygons. Lets hope he was not using a mobile net abroad with rate of 10 €/megabyte or more.

Being able to set visibility before loading data could be useful also for database layers and why not for big shapefiles as well.

Hi, I think this is a documentation problem. Please read:

http://www.qgis.nl/2013/04/29/qgis-en-wfs-caching/

When you DISABLE the 'Cache Features' checkbox, QGIS will add a BBOX filter to its requests AND will not cache features anymore. So panning or zooming your map wil result in a new request (with BBOX).

I've had exactly your problem with our national mapping services.

If this solves your problem, please close this issue :-)

(or write some documentation lines for it, and sent it to the documentaton/community team)

I've looked up wfs in docs:

http://www.qgis.org/en/docs/user_manual/working_with_ogc/ogc_client_support.html?highlight=ogc#wfs-and-wfs-t-client

please write a little paragraph about this 'problem'

@Richard - If I'm understanding your comments, you are suggesting I should disable caching? Jukka pointed that one out too, and it does work. The problem then is that there is absolutely no caching between requests.

So take this example:
- I zoom to an area and get back my features.
- I then move the map one single pixel.
What currently happens (if caching is off) is that when I move the map, QGIS asks for the entire map extent again. So 99% of the features will be re-requested and re-sent.
What I think should happen is that QGIS caches the features it already has, and then sends a request to the server for CQL polygon request boxing the area covered by the one pixel. Any features returned are added to the ones already cached from the previous result. Rince and repeat for all panning.

This would have significant benefits:
a) Less bandwidth use
b) Faster
c) Less demand on the server

====
I guess that means this is a feature request now rather than a bug as current behaviour is expected.
- I'd suggest three possible modes:
1) Load entire dataset (what is currently "cache features").
2) Absolutely no caching (current "disabled cache features").
3) Smart caching as described above. I'd suggest this should be the default too.

@Jonathan Moules: when I found out I had exactly that reaction. But then I tried to find a way to do it.

So imagine you just downloaded 10000 features (the max for given server), and you do a one pixel pan. Then indeed QGIS will request all features.

BUT what could it do otherways? Only reason to efficiently request the new features, is by sending id's for the other 10000 features, so the server can decide to not sent those from given bbox. But that also not efficient, and not sure if WFS can do that.

Only reason to do it would be to sent the smallest box possible (like only one pixel row), which is also hard.

I think you can close this one, and do a feature request, but I think technically QGIS takes the right choice.