[Qgis-developer] Attribute Editor: Dual View

[Bernhard Ströbl]

Am 10.01.2013 17:03, schrieb Matthias Kuhn:
> On 01/10/2013 04:52 PM, Bernhard Ströbl wrote:
>>
>>
>> Am 10.01.2013 16:12, schrieb Matthias Kuhn:
>>
>> -- 8< snip --
>>>>
>>>> "E.g. If you want to manually select features out of different subsets.
>>>> Let's say you have a layer with a lot of features and you're looking
>>>> for
>>>> a couple of cities (but not all of them) which have more than 100'000
>>>> inhabitants"
>>>>
>>>> in extended selection enter: num_inhabitants > 100000
>>>> click: "new selection"
>>>> result (example): 150 datasets selected
>>>>
>>>> "and some others which do not meet this criterion, but some
>>>> other criteria."
>>>>
>>>> in extended selection enter: some_other_field = some_other_ctriteria
>>>> click: "add to selection"
>>>> result (example): 270 datasets selected (150 from before + 120
>>>> matching "some_other_criteria")
>>>>
>>>> after that you can manually remove all datasets that you do not need
>>>> from the selection but I doubt this is a real use case, because how
>>>> would you decide which to keep and which to remove? Obviously because
>>>> some attributes match certain criteria, so here we go: e.g. user wants
>>>> to see only the cities with an airport
>>>>
>>>> in extended selection enter: airport = false
>>>> click: "remove from selection"
>>>> result (example): 205 datasets selected (from the previosuly selected
>>>> 65 do not have an airport and are therefore removed from the selection)
>>>>
>>>> now have a look at the map and see where these cities are, in this
>>>> case manual removal seems imaginable, so lets remove 7 from the
>>>> selection; result: 198 datasets selected (205 - 7) in both table and
>>>> map!
>>>>
>>>> now the user can do anything with this selection (update certain
>>>> fields, export to new dataset, use for a spatial query...)
>>>>
>>>> I am of course totally aware that the 205 datasets can be achieved by
>>>> using only one query like "(num_inhabitants > 100000 OR
>>>> some_other_field = some_other_ctriteria) AND airport = true" but the
>>>> whole thing starts getting interesting when we imagine a spatial query
>>>> in the start e.g. "select all cities within 20 km from the sea" then
>>>> we could got to the attribute table enter "(num_inhabitants <= 100000
>>>> OR some_other_field != some_other_ctriteria) AND airport = false" and
>>>> click "remove from selection" to get a result containing all cities
>>>> with either more than 100000 inhabitants or some_other_ctriteria and
>>>> an airport and within 20 km of the sea
>>>>
>>>> the "show only selected" checkbox should of course work as one would
>>>> expect it to i.e. whenever the selection changes, no matter if this
>>>> change originates from a user's click in the table or map or from
>>>> using one of the selection buttons the dataset shown contains _all_
>>>> currently selected datasets and _only_ them
>>>>
>>>> I cannot imagine any use case that can not be tackled with what I
>>>> propose but I have a feeling that the filter/selection concept would
>>>> really confuse users
>>>>
>>> Ok, I think I got your idea.
>>>
>>> Of course it is possible to generate a useful selection now already by
>>> using an appropriate expression. This works as long as your requirements
>>> are well defined (as in num_inhabitants > 100000 AND airport = true
>>> etc.). Unfortunately that's not always the case as in this OSM data I've
>>> had a look at recently, where the number of stories was supposed to be
>>> in a field but sometimes something like "4-8", ">9" etc. was in there,
>>> requiring special attention.
>>>
>>> And there is the other use-case I mentioned in my last mail (and that's
>>> probably the main reason): The attribute editor view (the one with the
>>> list on the left and the attribute editor on the right) will greatly
>>> benefit from the filter/selection paradigm.
>>> In the example before (number of stories), you can apply a filter, to
>>> only show the buildings not containing a clean number (i.e. requiring
>>> inspection) and manually adjust the numbers to be in a consistent format
>>> you can use. In this case you will need the selection to change (because
>>> you change it, whenever you change the currently edited feature(s)) but
>>> you don't want your filter to change before you finished inspecting all
>>> the suspicious features.
>>
>> bare with me I do not get your point here. Why would I change the
>> selection when I change a feature's value? We do not even have a
>> selection, do we? All we have is a filter. ...ahh wait a bit... the
>> filter is applied once and stays even if data are changed so they do
>> not match the filter anymore - but that is the current behaviour with
>> a selection, isn't it?
>> How if we had a selection and tick "show selected only" and switch to
>> the attribute view where we fix one dataset after another - would that
>> be any different from using the filter?
>> I really do like the dual view idea but do not understand why it is
>> linked to the filter.
>>
> The filter should always represent the current status of the data, even
> when it changes.
> The selection needs to be changed, because it defines which feature is
> currently visible in the attribute editor (right side of the editor
> view). And if you want to edit 5 different features one after the other,
> you change the selection 5 times.

ok, I see, but that would be a different behaviour from what we have now 
when clicking with the "i" or right clicking in the table. Both leave 
the selection unchanged. Imagine selecting some features e.g. in the map 
then pressing "selection to filter" changing to the attribute view, 
investigating some features and when going back to the map/table view 
your selection is gone. Maybe there is another solution to this then 
changing the selection? In that case you would not need the filter 
anymore here :-)

Once you changed a certain feature, it
> may disappear from the filter. The others stay visible. For the example
> above this means: edit the data until all suspicious features
> disappeared and you've got a clean dataset.

so the filter continuously refreshes according to any data changes. This 
would be an appropriate behaviour for a filter, not for a selection, 
though. Still I would prefer basing all table work on the selection. 
Think about using the calculator updating selected features and a filter 
prevents me from seeing my selection. This could damage people's data.

Bernhard

>
> Matthias
>
>>>
>>> I suppose we won't get around this (unless the dual view as a whole is
>>> dumped) but I'm sure there is a possibility that will keep it as easy as
>>> possible for every user.
>>> Maybe a solution could be to detach the selection "advanced search" tool
>>> from the attribute table (keeping it available with a button) as also
>>> requested in http://hub.qgis.org/issues/6799. This tool could then also
>>> implement your ideas such as "add to selection", "remove from selection"
>>> and "intersect with selection".
>>
>> +1 for #6790
>>
>> Bernhard