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.neum...@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@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@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer