[Qgis-developer] Attribute Editor: Dual View

Bernhard Ströbl bernhard.stroebl at jena.de
Thu Jan 10 07:52:36 PST 2013



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.

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


More information about the Qgis-developer mailing list