Hello, Le mardi 27 mai 2014 16:06:55, Andreas Neumann a écrit : > 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.
I would not be shocked if QGIS had an "official" local data format, allowing the user to get all features when using it, and other formats for interoperability. I do not think that this would disturb users as : * almost all software do this * QGIS already behaves like this, with read-only data formats for examples It would almost simplify the situation as in "use the official format or accept limitations". And of course having a GeoPackage-compatible format would be a win. This kind of change could trigger a new major version though, to make it clear that this is an important change. Vincent > > 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 _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
