[Qgis-developer] Qgis-developer Digest, Vol 85, Issue 86 QGIS Engine development

Windmüller, H (Hans) Hans.Windmuller at PWN.NL
Wed Nov 28 00:12:33 PST 2012


Forgive my lack of knowledge if this reaction does not cover the renderproblem.

Though I'm not a developer I have been wondering a long time why QGIS is so much slower than other GIS-applications like ArcGIS, DivaGIS and MapWindow.
I've posed the question before and got some workarounds like PostGis.

On the post mentioned below I have posted my test results


Somehow QGIS (on windows?) needs to upload the .dbf file to the client instead of opening it on the remote server.

I have asked several people (both GDAL and QGis) but I have not had any clear confirmation or denial that the above is the case and how and where this action is taken within the software.

Once the .dbf file is loaded rendering is swift as a bird.

Hope someone can tell me whether or not this QGIS behaviour is intended or not and / or if this behaviour can be redesigned to opening the .dbf file on the remote server.

Best regard,

Hans Windmüller
hans.windmuller at pwn.nl

-----Oorspronkelijk bericht-----
Van: qgis-developer-bounces at lists.osgeo.org [mailto:qgis-developer-bounces at lists.osgeo.org] Namens qgis-developer-request at lists.osgeo.org
Verzonden: woensdag 28 november 2012 7:13
Aan: qgis-developer at lists.osgeo.org
Onderwerp: Qgis-developer Digest, Vol 85, Issue 86

Send Qgis-developer mailing list submissions to
	qgis-developer at lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
	qgis-developer-request at lists.osgeo.org

You can reach the person managing the list at
	qgis-developer-owner at lists.osgeo.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Qgis-developer digest..."

Today's Topics:

   1. Re: QGIS Engine development (Martin Dobias)
   2. Re: Html image map plugin error (Richard Duivenvoorde)
   3. Re: Get rid of Shapefiles ! Go SpatiaLite ! (Noli Sicad)
   4. Re: QGis 1.8 Custom Feature Form (Tim Sutton)


Message: 1
Date: Tue, 27 Nov 2012 21:42:07 +0100
From: Martin Dobias <wonder.sk at gmail.com>
To: Mihis <mihis.sakh at gmail.com>
Cc: qgis-dev <qgis-developer at lists.osgeo.org>
Subject: Re: [Qgis-developer] QGIS Engine development
	<CAC2XbFfCyheoL5aQKZaOAehK9dHxLo6rcVmuEMr+eKDbrAck+A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"


let me share some thoughts...

On Wed, Nov 21, 2012 at 3:34 PM, Mihis <mihis.sakh at gmail.com> wrote:

> Marco Hugentobler-4 wrote
> > I don't know if AGG would be faster than the Qt raster paint engine and
> > how much. It would be very interesting to have the comparison AGG <-> Qt
> > raster engine (and maybe libcairo as well).
> >
> > With AGG / cairo, the approach would be to create a new Qt paint engine
> > based on these libs (rather than changing the code in qgis core to be Qt
> > free). If someone knows of an AGG paint engine implementation or likes
> > to create one, that would be very interesting.
> There is point of view (which I consider to be right) that implementation
> of
> traditional
> painting engine (like one in Qt, Cairo, GDI+) with one large Painter class
> on the top of
> AGG is totally inefficient because of the template architecture of this
> library. Maybe much
> more efficient approach will be implementation of light weighted wrapper of
> AGG, which will
> look like a system of classes for optimized rendering of spatial data.

It's hard to discuss AGG vs Qt rendering performance without benchmarks on
real data. As far as I know, Qt has fairly optimized rendering, see:

http://doc.qt.digia.com/qt/qpainter.html - Performance section

> However the absolute majority
> of cases when you need really fast spatial data rendering is when you need
> to display set of
> large vector layers like rivers, lakes, elevation contours, coastline and
> so
> on. Such kind of features
> in cartography are expected to be displayed on the map by identical
> graphics
> symbols (lines of the same width and color, polygons withe same outline and
> the same fill color and so on).
> In such situation the most efficient approach is to minimize the number of
> calls of rasterisation
> algorithm (rasterize all identical graphics symbols at a time). This
> definitely can be easily implemented
> with the help of AGG. And what about Qt? I can mistake but it seems to me
> that such classes
> as QPainter are often hardcoded things (Cairo's painter class is
> hardcoded).
> So does Qt painting engine
> have enough potential for optimized usage to be used for efficient spatial
> data rendering?

Qt has modular painting system, so you could try give it a try and
implement a paint engine based on AGG, but I do not believe that would make
a difference - there are other areas that need more attention.

> However in my opinion (but I may mistake) rendering of spatial data is not
> the main issue
> in the terms of QGIS performance problem. It seems that main problem lies
> in
> usage of GDAL/OGR,
> which tendency to support great number of vector and raster data formats
> may
> have negative influence
> on its performance. Of course, it's possible to give users opportunity to
> switch to another memory usage model (store all data in memory),
> furthermore
> as I know QGIS Engine already has implementation of such technique for
> vector data (QgsMemoryProvider). That will lead to significant improvement
> of performance,
> but in my opinion to make QGIS be competitive with proprietary GIS systems,
> fast spatial data rendering system with efficient memory usage should be
> implemented. So, are there any ideas about implementation of own QGIS
> spatial data formats, or other possible ways to speed up process of reading
> data from files?

Currently I see the greatest bottleneck in access to data. First of all, we
do not have in-memory caching, so the data are fetched from data source
everytime we render a map. Efficiency of GDAL/OGR could also be improved in
some cases, but it really depends on what data format you are going to use.
Apart from GDAL/OGR, QGIS has native data providers for PostGIS, SpatiaLite
and other sources which is supposed to give us more flexibility, faster
access and better control since there is one layer less.

I have been measuring the performance of vector layer rendering some time
ago and it varies greatly on three levels:
- data source type (shapefile / database layer / ...)
- layer type (geometry type, number of vertices per geometry, number of
attributes, ...)
- renderer type (using attributes? antialiasing? thick lines?)

Of course there are some areas worth improving also in QGIS to lower the
amount of time spent in QGIS libraries while rendering and to make life
easier to the rendering engine (e.g. simplify polygons with lots of
vertices before rendering them).

I apologize in advance for my posts, because they may sound like criticism
> of QGIS. Indeed I haven't used QGIS much. I work in commercial company,
> which is planning to build its own GIS system only for internal work. The
> key problem is that this system must be able to work fast with really large
> raster and vector files. My boss doesn't want the system to be created from
> scratch, he wants me to use some open source GIS platform. That's why I am
> very interested in the real temps of QGIS Engine development, who and how
> many developers really work on these problems? I also have investigated
> situation around more fast gvSIG, but it is Java-based and unlike QGIS
> seems
> not to have API for development of standalone GIS applications.

Building an own GIS system on top of QGIS is something that is perfectly
possible and may result in fruitful cooperation: your company can save
large amount of money that would be spent on initial development and may
focus just to specific areas important for your company.

> Also I would not pay attention for QGIS performance problems if I hadn't
> keep in mind an example of one university experimental GIS development
> project. It resulted in the development by one person of simple GIS
> application with own vector data format and AGG based rendering, without
> some complex systems of data caching or tricky techniques of reading data
> from files, without thread support, built with old Borland ?++ compiler.
> Some time ago I tested it and was really surprised to find that it worked a
> bit slower the multithreaded gvSIG and much faster then QGIS.

We would be very happy to see any patches that would improve the
performance :-)

> I apologize for my post again, I have no aim to criticize QGIS. I believe
> it
> to have great potential in improving of performance. I am only trying to
> investigate the real situation. Are there real detailed
> plans for improvement of QGIS Engine?

I'm currently working on getting some changes in libraries done in
preparation for version 2.0 which hopefully will bring also rendering in
threads (I have worked on that during GSoC 2010, but did not get it
merged). See my reports from GSoC:


Otherwise, there are no detailed plans for improvements of rendering speed
- I encourage you to give QGIS a try, evaluate where the speed is lacking
your needs and tell us your findings - you could even find some sponsors
willing to invest money into some performance improvements (or share the
development costs)!

> And what are the real opportunities of
> QGIS community to implement these plans in program codes?

Of course everyone is welcome to suggest improvements and provide patches,
so there are lots of opportunities. QGIS core team is receptive to patches
from other community members. When starting a greater development that
should be merged to QGIS source code, it is a good idea to let the team
know - we can help with design decisions and it also lowers the probability
that more people work independently on the same thing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20121127/10e0d9a8/attachment-0001.html>


Message: 2
Date: Tue, 27 Nov 2012 22:57:43 +0100
From: Richard Duivenvoorde <rdmailings at duif.net>
To: Paolo Cavallini <cavallini at faunalia.it>
Cc: qgis-developer <qgis-developer at lists.osgeo.org>
Subject: Re: [Qgis-developer] Html image map plugin error
Message-ID: <50B53757.8010608 at duif.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 11/27/2012 02:17 PM, Paolo Cavallini wrote:

> "/home/paolo/.qgis//python/plugins/imagemap_plugin/imagemapplugin.py",
> line 322, in ring2area
>      htm.remove(len(htm)-1,len(htm))
> AttributeError: 'unicode' object has no attribute 'remove'
> Anyone confirms?
> All the best.

Hi Paolo,

Thanks for the report, but I cannot confirm this either.

Can you maybe sent me the data you are using, or more information about 
the type of geometries you are using as the output layer?
Or maybe you have some special characters in filename or attributes or so?
You are not using Python 3 are you?


Richard Duivenvoorde


Message: 3
Date: Wed, 28 Nov 2012 09:52:28 +1100
From: Noli Sicad <nsicad at gmail.com>
To: Stefan Keller <sfkeller at gmail.com>
Cc: qgis-developer at lists.osgeo.org
Subject: Re: [Qgis-developer] Get rid of Shapefiles ! Go SpatiaLite !
	<CADs9uc9SWiGhrLhtWq575hcCk2GvQkbKyv3RfgH3DTLtiQ7fZQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Stefan,

> Your point is very common and I understand this situation.
> But the ArcGIS SW suite doesn't really make interoperability easy and tends
> to maintain a vendor lock-in.
> My proposal is to break this deadlock by programming an free ArcGIS desktop
> extension which reads/writes Spatialite.
> Any volunteers?

It's almost done (i.e. just read, not write Spatialtie).

AmigoCloud's GDAL/OGR Plugin for ArcGIS.

It reads from Spatialtie and other formats at the moment.




Message: 4
Date: Wed, 28 Nov 2012 08:12:36 +0200
From: Tim Sutton <lists at linfiniti.com>
To: Justin Hubbard <justin at pyrotechsoftware.com>
Cc: qgis-developer <qgis-developer at lists.osgeo.org>
Subject: Re: [Qgis-developer] QGis 1.8 Custom Feature Form
	<CALCNqkaVcq23Ui2oPewFKpOznBmJe7GHs0-iECAZOOekaHeN8w at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"


You probably need to manipulate your sys.path to ensure that your form is
visible to python at plugin start, or move your form into the same
directory as your project file.



On Mon, Nov 26, 2012 at 9:02 PM, Justin Hubbard <justin at pyrotechsoftware.com
> wrote:

> I am developing a plugin, which uses a custom feature form with custom
> logic.
> The problem is that when I open the project (Automatic with the load of
> the plugin) and I try to open the feature form I get an import error that
> the module doesn't exist.
> If I click the save project button, and then try to open the feature form
> it works correctly.
> I have tried to trigger this save in the plugin code. The save works
> correctly, but unless I specifically click on the action, I get the same
> error.
> Am I missing something?
> --
> Warm regards
> *Justin Hubbard*
> *--*
> *Justin Hubbard*
> Software Engineer and Support
>   Mobile:
>   +27 (0)79 827 1657
>   Fax:
>   +27 (0)86 540 6016
>   Email:
>   justin at pyrotechsoftware.com <robert at plannermunicipalsoftware.co.za>
>   Web Site:
>   www.pyrotechsoftware.co <http://www.plannermunicipalsoftware.co.za/>m
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20121128/7e778d65/attachment.html>


Qgis-developer mailing list
Qgis-developer at lists.osgeo.org

End of Qgis-developer Digest, Vol 85, Issue 86

More information about the Qgis-developer mailing list