[Qgis-developer] Aggregates within expression engine
Luigi Pirelli
luipir at gmail.com
Fri Mar 18 05:11:29 PDT 2016
+1
Luigi Pirelli
**************************************************************************************************
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************
On 16 March 2016 at 09:15, Hugo Mercier <hugo.mercier at oslandia.com> wrote:
> 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
>>
>
> _______________________________________________
> 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