<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi,</p>
<p>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.</p>
<p>Just randomly using the attributes of the first feature doesn't really makes sense to me. In 99% of the </p>
<p>Now that we have aggregate functionality in QGIS - are there technical reasons for not using these aggregate functions?</p>
<p>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 ;-)</p>
<p>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.</p>
<p>Andreas</p>
<p>On 2017-06-30 07:47, Matthias Kuhn wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<p>On 6/29/17 10:21 AM, G. Allegri wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div dir="auto">
<div class="gmail_extra" dir="auto">
<div class="gmail_quote"><br />
<blockquote class="quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">1. Allowing multiple field selection for grouping<br /> 2. Keeping attributes of first feature when grouping</blockquote>
</div>
</div>
<div dir="auto"> </div>
<div dir="auto">I will accept this criteria, obviously, if it's the preferred solution for the mosts. </div>
<div dir="auto">I just want to report that many users (partecipants to courses or customers) say they find having the "first feature value" misleading. </div>
<div dir="auto">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.</div>
<div dir="auto"> </div>
<div dir="auto">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.</div>
</div>
</blockquote>
<br /> 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"...).<br /><br /> 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.<br /><br /> 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")) ). <br /><br /> Matthias<br /><!-- html ignored --><br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br /> QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br /> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br /> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
</blockquote>
<p> </p>
<div> </div>
</body></html>