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 >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> _______________________________________________ >> Qgis-developer mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
