Bug report #10106

Panning a non-cached WFS layer causes selection to change

Added by Heikki Vesanto about 10 years ago. Updated about 8 years ago.

Category:Web Services clients/WFS
Affected QGIS version:2.2.0 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:18574


When a layer is added in from a WFS server and it is not cached, if a selection is made and then the map is panned the initial selection is not maintained.
Images to demonstrate the issue:
Initial selection:

Selection after the map has panned and the WFS has updated the features in the layer:

I guess QGIS makes a selection based on an arbitrary primary key, so the features selected after the map has panned have the same arbitrary primary key as the features selected before the pan.

Possible solution:
Make it possible to select a primary key for a non-cached WFS layer when adding it in and use this primary key for selections.


#1 Updated by Giovanni Manghi about 10 years ago

  • Priority changed from Normal to Severe/Regression
  • Target version set to Version 2.4

seems a regression to me. Please lower the priority if I'm wrong.

#2 Updated by Jukka Rahkonen about 10 years ago

Confirmed. For example, if I select one feature that has an internal ID value "2" in QGIS and pan to a new location, new set of features is fetched from WFS and again a feature with internal ID=2 is highlighted. However, it is not the same feature.

If WFS server is configured so that it is using permanent WFS fids they could be used as primary keys on QGIS side. This is the intended behaviour with WFS-T. However, some WFS servers which are not configured right or serve read-only WFS do not have permanent fids but they can depend on timestample or something and are always different. This happens for example by default with Geoserver if the database table used as source data does not have primary key. Thus I am not sure how it would be possible to make QGIS to keep the same selection after pan/zoom so that it would be generally reliable. It happens also that selected feature is not at all in the new WFS dataset because it goes outside the BBOX. Should QGIS cache in this case the selected features even generally the cache is disabled?

#3 Updated by Heikki Vesanto about 10 years ago

Most datasets will have a unique primary key. You could allow a user to choose a primary key field to make selections on. I guess there are issues of the user not knowing the data, but it is a solution. I guess the main issue would be if a user selects a field that isn't unique, it would behave strangely, but that is a documentation issue.

I don't know how QGIS stores selections, but this would also allow a feature to come in and out of being visible, if only the selected primary keys are stored.

I would suggest not caching the selected features, because the whole point of non-cached is large datasets that hit WFS server feature limits.

#4 Updated by Jukka Rahkonen about 10 years ago

Fid is what is supposed to be unique and permanent in WFS and for making WFS-T to work it must be unique and permanent. Because QGIS can do WFS-T it must already have code for handling WFS fids. Perhaps that code could be reused for handling selections on WFS layers.

#5 Updated by Jürgen Fischer almost 10 years ago

  • Category set to Web Services clients/WFS

#6 Updated by Martin Dobias almost 10 years ago

  • Priority changed from Severe/Regression to Normal
  • Target version changed from Version 2.4 to Future Release - High Priority

Not a regression - it didn't work in 2.0 either.

QGIS stores selection as a list if feature IDs.

WFS provider stores WFS feature IDs and maps them to internal feature IDs. But, when re-caching, WFS provider does not keep track of which internal IDs were used for which WFS IDs, resulting in the broken selection and also editing functionality.

Not caching just selected features as suggested in note 3 is not an option, the functionality needs to be fixed inside WFS provider.

#7 Updated by Even Rouault about 8 years ago

  • % Done changed from 0 to 100
  • Status changed from Open to Closed
  • Target version changed from Future Release - High Priority to Version 2.16

Fixed in 2.16 per 9040ec1b

Also available in: Atom PDF