[Qgis-developer] How should the dissolve tool in Processing work?

[Bernhard Ströbl]

Hi Victor,

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.

Bernhard

>
> Let me know if you have more ideas
>
> 2015-10-19 17:38 GMT+02:00 Matthias Kuhn <matthias at opengis.ch>:
>> Hi
>>
>> 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
>>> a
>>>
>>> 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"
>> tools)
>> - 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
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>

-- 
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stroebl at jena.de
Internet: www.kij.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.
http://www.eset.com