[Qgis-developer] Attribute Editor: Dual View

[Matthias Kuhn]

On 01/10/2013 02:07 PM, Bernhard Ströbl wrote:
> Matthias,
>
> I try to do it with your words...
>
> Am 10.01.2013 13:18, schrieb Matthias Kuhn:
>> Bernhard,
>>
>> On 01/10/2013 07:39 AM, Bernhard Ströbl wrote:
>>> Hi Matthias,
>>>
>>> comments below.
>> same here
>>>
>>> Am 09.01.2013 16:41, schrieb Matthias Kuhn:
>>>> Hi Bernhard
>>>>
>>>> On 01/09/2013 03:07 PM, Bernhard Ströbl wrote:
>>>>> Hi Matthias (and others),
>>>>>
>>>>> I read your paper and I like the idea of the dual view because
>>>>> currently it is not possible to open the attribute editor from the
>>>>> table. On the other hand I am not convinced of the filter/selection
>>>>> proposal. IMHO one of the strengths when using GIS data is the unity
>>>>> of geometry and attribute data. Currently selecting a feature in the
>>>>> map also selects its attributes in the corresponding table and vice
>>>>> versa.
>>>>> examples:
>>>>> 1) Select in map and investigate attributes: If a filter was applied
>>>>> the data might not be visible in the table without clicking 
>>>>> "selection
>>>>> to filter".
>>>>> 2) filter logical in table and investigate these features in the map:
>>>>> You would need an additional "filter to selection" button to handle
>>>>> this.
>>>>> 3) field calculator: will it update the selected or the filtered
>>>>> datasets?
>>>>> I think the whole concept will confuse average users. I would favour
>>>>> to keep the well established solution of features being selected no
>>>>> matter where (table or map) the selection was performed.
>>>>
>>>> I think the reasoning for the change in the selection/filter paradigm
>>>> was rather poor in the document itself. There are other reasons which
>>>> are in favor of a change of filter/selection as well.
>>>>
>>>> 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 and some others which do not meet this criterion, but some
>>>> other criteria. At the moment, you can do this by sorting and 
>>>> scrolling
>>>> and maybe some other tricks, but it's not that easy. With the
>>>> independent filters, this would be a task of changing the filter and
>>>> Ctrl-Clicking the required features out of each subset.
>>>
>>> I see the point in this, but the case you describe could be solved
>>> differently (that is at least theroretically :-). If the selection
>>> tool would not always create a new selection (as is now) but enable
>>> the user to either "add to selection" or "select within current
>>> selection" or even "remove from selection" this would IMHO be more
>>> straightforward for users.
>>>
>> I'm sorry, I'm not able to follow this description exactly. Could you
>> please describe in detail how you imagine the process.
>> If possible, please also outline the scenario, where the user wants to
>> check/update individually the attributes for all cities with more than
>> 100'000 inhabitants in the attribute view.
>
> "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.

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".

Regards,
Matthias