[Qgis-developer] have aggregate/window expressions ever been discussed?

Andreas Neumann a.neumann at carto.net
Tue May 27 07:06:55 PDT 2014


Hi all,

I understand your concerns, but on the other hand - how would you treat
all data sources equally well, if QGIS does not implement that stuff
within QGIS for data providers that do not implement this? One could
still write a QGIS expression to SQL compiler for those providers who
support these functions (Matthias Kuhn proposed that).

We will need these aggregate functions in forms for information purposes
and in the print composer for generating reports. Having to write
Postgis-Views would work for database pros. But let's not forget that
not all of our users are database professionals and not all of the users
have their data in Postgis.

Personally, I don't care where these aggregate functions are implemented
and executed, as long as they are easy to use and do not enforce the
usage of a specific data format.

Andreas


Am 27.05.2014 09:21, schrieb Vincent Picavet:
> Hello Andreas,
> 
> Le mardi 27 mai 2014 10:28:13, Andreas Neumann a écrit :
>> Hi,
>>
>> We would definitely need this functionality for our application modules
>> - we need functions like "min", "max", "mean", "sum", "average" to work
>> on 1:n relations.
>>
>> Now that we have relations in QGIS, I think that aggregate functions are
>> a logical next step. Something to seriously consider in 2.6.
> 
> As already stated before, I am worrying about current developments around a 
> lot of features looking like database features :
> * Table joins
> * relations
> * "SQL-like" processing
> * .. including aggregates
> 
> Implementing all these features on top of QGIS seems reinventing the wheel, 
> and database wheels are particularly hard to design and implement well.
> I really think we should re-study the global design of such features to have a 
> clear and clean strategy instead of stacking features on features, lacking 
> coherency.
> 
> As stated by Regis, basing this work on top of SQLite may be the best option, 
> but more study has to be done and a general agreement is needed to go this 
> way.
> 
> Vincent
> 
>>
>> Andreas
>>
>> Am 23.05.2014 17:34, schrieb G. Allegri:
>>> Recently I had to calculate the relative dimension of a polygon relative
>>> to the others of the same class. I know there are a lot of way to do it,
>>> inside and outside QGIS, but I wondered if field calculator (and
>>> expressions in general) couls be extended to accompish this kind of
>>> tasks.
>>>
>>> The approach would be something similar WINDOW functions in Postgresql
>>> [1], where for each record a new value will be calculated on the basis
>>> of other records (filtered or not).
>>>
>>> Has this ever been discussed? Is it something that could fit QGIS
>>> expressions?
>>>
>>> giovanni
>>>
>>> [1] http://www.postgresql.org/docs/9.1/static/tutorial-window.html
>>>
>>>
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer



More information about the Qgis-developer mailing list