[QGIS-Developer] Processing 3.0: Possible change to the Convex Hull algorithm

[G. Allegri]

If you read above, the idea is to set fields *other then the ones selected
for grouping* null. So it wouldn't pick the first one, which is meaningless.

Having aggregate functions to be applied to single non-grouping fields
could be a great plus, keeping the option to leave the field set to null.

What kind of aggregate functions do we have for categorical/textual values?

giovanni

Il 30 giu 2017 08:36, "Neumann, Andreas" <a.neumann at carto.net> ha scritto:

> Hi,
>
> I also think that the logical solution would be to aggregate the
> attributes when grouping and allow the user to specify which aggregate
> function to use for each attribute.
>
> Just randomly using the attributes of the first feature doesn't really
> makes sense to me. In 99% of the
>
> Now that we have aggregate functionality in QGIS - are there technical
> reasons for not using these aggregate functions?
>
> Just a hint, because about 1 year ago we paid Nyall for these aggregate
> functions and of course we are interested that these are used more and more
> in QGIS ;-)
>
> BTW: FME from safe software has an aggregate widget/functionality
> available whenever something is grouped. QGIS should do the same. I don't
> see why not.
>
> Andreas
>
> On 2017-06-30 07:47, Matthias Kuhn wrote:
>
> On 6/29/17 10:21 AM, G. Allegri wrote:
>
>
> 1. Allowing multiple field selection for grouping
> 2. Keeping attributes of first feature when grouping
>
>
> I will accept this criteria, obviously, if it's the preferred solution for
> the mosts.
> I just want to report that many users (partecipants to courses or
> customers) say they find having the "first feature value" misleading.
> I agree with them. I would set the field values only for the grouping
> fields, having the same value within the group, and set null for the other
> fields.
>
> The problem raises during a long workflow. At some point you obtain a
> dataset with unconsisten field values, and it's not always obvious to know
> when and.which field value was set miningless.
>
>
> In the long run the most flexible solution will be to allow specifying the
> aggregate function applied to each field individually ("first/any", "mean",
> "mode", "max"...).
>
> No worries if it's not implemented right now, but please keep the code
> modular enough to introduce this easily later down the road. Without
> manually editing each algorithm that supports grouping.
>
> A possible approach to this would be a parameter
> "ParamterFieldAggregation" that offers a standard gui to configure the
> aggregation behavior (fieldA: min; fieldB: mean; fieldC: any; fieldD:
> mean(expression("numBirds2017 - numBirds2000")) ).
>
> Matthias
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170630/e40ec1cc/attachment.html>