> > 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. >
I totally agree Andreas. Whatever the way it would be implemented, I hope it won't become a blank textarea where to write some "special" SQL. I imagine something integrated into the rest of expressions GUI. > > 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 > -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
