[Qgis-developer] Attribute Editor: Dual View

[Bernhard Ströbl]

Matthias

I will be glad to take part in the discussion.

regards

Bernhard

Am 12.01.2013 11:18, schrieb 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer