[Qgis-developer] Ideas/proposal for Attribute Table

Matthias Kuhn matthias.kuhn at gmx.ch
Tue Jan 7 02:56:00 PST 2014

How about adding this feature (aggregate functions like max/min/avg 
etc.) to QgsExpression instead? Then it could not only be used in the 


On Tue 07 Jan 2014 11:50:24 AM CET, Bernhard Ströbl wrote:
> Hm,
> if you look at JasperReports it is Java. Can you implement this
> internally into QGIS? Looking at reports in general some kind of
> programming will always be needed to generate an individual report
> because the data structure is individual, too, so I think it will
> always be something for specialists.
> An idea to start with would be to create a new element in Composer
> that makes simple calculations like sum or average on a field: Choose
> layer - choose field - choose what to do. Evaluation time will be the
> same as for the map (either permanetly or on request but at least
> before printing).
> Bernhard
> Am 07.01.2014 11:16, schrieb Paolo Cavallini:
>> Hash: SHA1
>> Il 06/01/2014 10:40, Bernhard Ströbl ha scritto:
>>> the need to create some kind of reports is often uttered. IMHO a
>>> dedicated reporting
>>> tool can always handle this better than anything implemented in QGIS
>>> or any other GIS
>>> (because it is not a main GIS feature). I successfully coupled a Python
>>> implementation of JasperReports [1] with QGIS. JasperReports not
>>> only allows
>>> sum/average and the like but also subreports (for ?:n relations)
>>> charts and much
>>> more. AFAIK (but have not tried myself) LibreOffice output is
>>> possible, too. This
>>> solution needs some Python programming to create an XML document
>>> from your data and
>>> send the data and the report template to the server.
>> Hi all.
>> I agree this is an important issue. I heard there was some plan to
>> implement this:
>> anyone knows the current status, and the prospects for the future?
>> Obviously, we have always the same duality: implementing outside QGIS
>> is easier and
>> more powerful, reusing existing tools, whereas an internal
>> implementation is far
>> smoother from an user point of view.
>> Historically, in most analogous cases we ended up implementing an
>> internal solution
>> (sometimes using common libs), and I suspect sooner or later we'll
>> have to do the
>> same for reporting also.
>> All the best.
>> - --
>> Paolo Cavallini - www.faunalia.eu
>> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
>> Version: GnuPG v1.4.15 (GNU/Linux)
>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>> AnMAlRyAp4wxoChEMxz8T4L/KaQnsSI=
>> =d9ww
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> __________ Information from ESET Mail Security, version of virus
> signature database 9258 (20140107) __________
> The message was checked by ESET Mail Security.
> http://www.eset.com
> _______________________________________________
> 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