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

[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

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

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

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