[Qgis-developer] Identified features vs. Selected features : could we merge those ?

[Andreas Neumann]

Hi,

I am skeptical - mainly for the reasons you list in your rationale
against it. Selection and identification are really two different tasks.
You do not want to loose your selection just because you want to query
the attributes of the feature.

Identification works with all layers, while selection should only work
on the selected layer to get predictable results. Users should be making
selections intentionally rather than by accident because the selection
works on all layers and they are not aware of what they are doing.

The identify tool has been improved several times - we added the
top-down-stop-at-first mode (which most of my users like) and then later
on the new "layer choice mode" with an interactive choice in a drop-down
menu. So we have 4 modes now, with the two described above as the more
powerful ones. I still think there is a use-case for all of the four
modes, but maybe the most recent addition (the "layer choice mode")
should be the default.

Selection is essential in GIS - useful for exporting features, run
analysis only on selected features, field calculator updates, plugins,
processing, etc. The identify mode should not change the selection.

The selection tool was improved over time as well, with shortcuts, free
form selection, circular mode, etc., etc.

I am open to improving the identification tool (e.g. by opening the form
in the mode where one can toggle between table and form easily instead
of just the form) - but please let's keep the selection and
identification tools separated.

Andreas

Am 02.04.2014 22:17, schrieb Olivier Dalang:
> Hi !
> 
> The discussions about this issue http://hub.qgis.org/issues/9907 raised the
> question (at least for me) of merging the concepts of Identified features
> and Selected features.
> 
> I don't know if it's the good moment to discuss this, but since we have a
> few other threads talking about a bit more deep user interaction changes, I
> thought it could be good to think of this also (even if it's not urgent)...
> 
> In short, the idea would be to have both identified features and selected
> features be exactly the same thing.
> The only difference between the select tool and the identify tool would
> then be that the identify tool opens a form window (either the single
> feature form or the attribute table in form mode).
> The identify tool could then also work in "single","rectangle","polygon"
> etc modes.
> 
> 
> Rationale FOR:
> 
> 1. There is already a feature overlap
> 
> When identifying one feature only, the "identify tool" can open the form
> (provided "open feature form if a single feature is identified" is
> checked). But when identifying several features, the way to go is a
> selection, which dynamically refreshes the attribute table, and where the
> features can be edited in the form mode.
> This is also a problem in the scenario of issue #9907 : to open the form of
> overlapping features, you have to use a selection, if you don't want to
> spend too many clicks expanding the "identify window" tree, finding the
> right feature, and clicking on it's "open feature form" button. This also
> has the annoying consequence of being unpredicable : the effect of the tool
> will sometimes be opening the form (when one feature gets identified), and
> sometimes to open that "identifying results" window (when several features
> got identified).
> 
> *2. The attribute table in form mode is actually great*
> 
> The "identify results" window is not very practical: the folded tree
> requires expanding, it does not provide a good overview of what is
> selected, does not take editing widgets into account etc.
> Meanwhile, the form view is great (both the single feature form and the
> multiple features form in the attribute table). It's clear, neat, even
> allows to choose which field to use to list the selection, etc... It's sad
> that it's a bit hidden in the UI, I find it one of the best additions to
> the UI that has been made lately.
> 
> *3. Both functions are very similar in how they work and look*
> 
> Both require you to click on a feature, and have a visual feedback
> consisting of highlighting the feature. It's very confusing for beginners
> as it's uncommon for softwares to implement two different types of
> selections.
> 
> *4. Having the attribute table in form mode for editing is promising for
> the future*
> 
> Because we could implement edition on several feature at once (currently,
> one needs a plugin to set an attribute on different features at once, and
> those plugin do not yet take the field widgets into account).
> 
> 
> 
> Rationale AGAINST (and of course counterarguments) :
> 
> *1. Identification is not the same than selection*
> Users sometimes want to work on a selection, while still being able to
> identify features.
> To allow this usage, either we could offer workaround features by
> implementing store/restore selections and/or have selections in the undo
> stack (grouped), or we could make an exception for the "identify single
> feature", which would not set the selection, but only open the feature form
> (current behavior).
> 
> *2. Identification would stop working across several layers (top-down mode)*
> Since it is difficult to imagine having the attribute table window display
> selections from several layers. Technically, it would be doable in the form
> view, since it does show only one form at a time, but it may be more clear
> simply to remove this possibility.
> However, we could keep the current behaviour when using "identify single
> feature" though. This tool's behviour could keep the same functions that
> currently, adding the feature #9907 and an "open attribute table in form
> mode even if only one feature is selected" option. (to be clarified)
> 
> I guess I missed some uses of the "identify results" window ?
> 
> 
> What do you think ?
> 
> 
> Best regards,
> 
> Olivier
> 
> 
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>