[Qgis-developer] Attribute Editor: Dual View

[Matthias Kuhn]

On 01/10/2013 05:23 PM, Bernhard Ströbl wrote:
>
>
> 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 :-)

You're correct. It wasn't our idea to implement it this way and thinking 
about it again it's really not a good idea. Sorry for the confusion.
I had this idea because for multi-edit selecting features first and then 
changing attributes would be really handy, but that's not part of the 
current work actually. So although not necessary now, this idea may 
become interesting again later on (I hope to get some experience with 
all these possibilities before then).

For now the idea is to have separate buttons in the feature list to 
choose the feature to edit :)

>
> 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.
>
This can be taken care of with a warning (Like: The current selection 
contains 3 items which are not shown due to filter restrictions).

Maybe there is still the need for a "link filter to selection" option, 
in case there is strong interest in keeping a possibility for the 
current way. I think that should be discussed, once a first 
implementation is available.

Regards