[Qgis-developer] How should the dissolve tool in Processing work?
bernhard.stroebl at jena.de
Mon Oct 19 23:18:19 PDT 2015
Am 19.10.2015 um 17:46 schrieb Victor Olaya:
> I think the best soultion would be to add an extra parameter with the
> fields to keep and the stats for them, so if it's empty, it behaves as
> it does now
Do you mean drop fields (as is now but in debate) or keep first value
(as it used to be before)?
> The trick here is that there is no support for a parameter such as
> this (which should be entered in a table and probably internally
> represented as a dict or array of tuples). Should be easy to implement
> it using a string, but then a custom UI should be created, otherwise
> it will be cumbersome to type in the parameter value
How would you enter the value? I could imagine a LineEdit where you
input e.g. a comma-separated list of fields to keep and another one
where you input a comma-separated list of the stats to apply? To apply
several stats on one field you would need multiple entries in LineEdit1?
> I will take care of moving the logic from Julie's plugin into
> processing, and then work on the UI. Shouldn't take long, and I think
> this will be a nice improvement
Would be nice to have. On the other hand there is a work-around by first
applying "Statistics by categories" and then "Join attributes table".
Would work on one field only because we lack an algorithm to rename or
drop fields, if I am not misstaken.
> Let me know if you have more ideas
> 2015-10-19 17:38 GMT+02:00 Matthias Kuhn <matthias at opengis.ch>:
>> On 10/19/2015 05:11 PM, Anita Graser wrote:
>> Hi Victor,
>> On Mon, Oct 19, 2015 at 1:15 PM, Victor Olaya <volayaf at gmail.com> wrote:
>>> Hi Anit
>>> nice discussion you bring up
>>> Shouldn't it behave like the ftools dissolve tool currently does?
>> Yes, it used to behave exactly like ftools still does. But the arguments
>> behind the latest changes to the script are that the (ftoos) behavior is not
>> what users expect.
>> The current behavior is not deterministic and therefore in the long run
>> probably not the most desirable behavior. Reading Bernhard's comments in the
>> issue, it's quite hard to improve without considerably extending parameter
>> handling in processing.
>> Best solution IMO:
>> * Keep the current/old behavior for the moment
>> * Add new parameter possibilities (e.g. a table/array of string (attribute
>> name) -> combobox (aggregate function) mappings)
>> * Use the current behavior as default setting for fields where the
>> aggregate funtion is undefined
>> + Full backwards compatibility
>> + Full control (/as soon as it gets done)
>> + One tool for one job (as opposed to "old dissolve" vs. "new dissolve"
>> - The default behavior may not be optimal (Can still be changed for 3.0 if
>> it's considered to be better)
>> -- Matthias
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
Kommunale Immobilien Jena
Am Anger 26
Tel.: 03641 49- 5190
E-Mail: bernhard.stroebl at jena.de
Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe
__________ Information from ESET Mail Security, version of virus signature database 12434 (20151020) __________
The message was checked by ESET Mail Security.
More information about the Qgis-developer