[Qgis-developer] Aggregates within expression engine

Hugo Mercier hugo.mercier at oslandia.com
Wed Mar 16 01:15:11 PDT 2016


Hi,

Just for me to understand: why not considering improving a bit the
virtual layers ?

There is already a support for user defined aggregate functions. Caching
of the computed aggregate is already done by the engine (I guess). And
we could add some functions to restrict the query to the selected
features of a layer or deal with relations ...

And using something like the "query builder" found in db manager (and
inspired by mapinfo), it may ease to deal with the SQL syntax ...

On 16/03/2016 08:30, Neumann, Andreas wrote:
> Hi Paolo,
> 
> Thank you for your feedback. 
> 
> Why do you think SQL aggregate syntax (e.g. as outlined
> at http://www.postgresql.org/docs/9.5/interactive/functions-aggregate.html)
> is a no-go? Can you explain this in detail? QGIS is much closer to a
> database then it is to a spreadsheet - in fact for most serious QGIS
> work you store your data in a SQL database.
> 
> It was my impression that QGIS tries to maintain expression syntax
> compatible with SQL wherever possible. I think it would be a good thing.
> 
> The question is how we can specify grouping. I'd like to see support for
> the following grouping mechanisms:
> 
>  
> 
>   * whole record set
>   * given grouping field or expression
>   * current selection
>   * grouping based on relations (very important to my employer) - also
>     our initial trigger for funding this work
>   * current set of symbology rules or classes (not so important to me,
>     but maybe useful to some)
> 
>  
> 
> Andreas
> 
> On 2016-03-16 08:11, Paolo Cavallini wrote:
> 
>> Hi Nyall,
>>
>> Il 16/03/2016 07:17, Nyall Dawson ha scritto:
>>
>>> I'm also torn regarding the best syntax to use for aggregates within
>>> expressions. I'm unsure if the traditional SQL "group by" clauses
>>> would be a good fit within the existing QGIS expression syntax (eg
>>> "sum("some_field") group by "some_other_field"). To me it doesn't fit
>>> with the existing functional approach that the expressions take. But
>>> on the other hand, trying to implement this as functions would result
>>> in some very clumsy expressions: "aggregate('sum', "some_field",
>>> "some_other_field")" or "sum("some_field", "some_other_field") ". Has
>>> anyone got any other ideas for syntax which would be a good fit?
>>
>> Good news, thanks for sharing.
>> IMHO having a syntax that is easy to use for the average user is a
>> crucial point. I think using SQL is a no go. Why not using the
>> spreadsheet syntax? Not that I find it particularly attractive, but at
>> least everybody is more or less familiar with it.
>> All the best.
> 
>  
> 
>  
> 
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 



More information about the Qgis-developer mailing list