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 <[email protected]>:
Hi
On 10/19/2015 05:11 PM, Anita Graser wrote:
Hi Victor,
On Mon, Oct 19, 2015 at 1:15 PM, Victor Olaya <[email protected]> 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
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
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: [email protected]
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
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
