Quantum GIS

TS: Marco, Welcome to this the fifth QGIS interview! Can you start by giving us a brief introduction of yourself?

I live in Zürich (Switzerland) close to the lake. I'm 29 years old, married and I have a three year old daughter. I'm working as a software engineer for Autoform, a company which produces software for sheet metal forming.

TS: How and when did you get involved with QGIS? What prompted your involvement in QGIS over other GIS apps such as GRASS?

I noticed QGIS the first time in April 2003 because of an entry at freegis.org. At this time I was a PhD student in the GIS division at the University of Zürich. In fact I already dreamed of a Qt based open source GIS for quite some time. Then I discovered QGIS, compiled it, sent the first patches and since then, I'm an enthusiastic QGIS programmer.

TS: Looking back over the time you have been involved with QGIS, what are the major advances that have been made? How does the application compare now to what it was like when you started using it?

When I started with QGIS, it was a simple vector data viewer. It was possible to load OGR data formats and PostgreSQL layers, display tables, zoom in and out. One of the major advances was the addition of raster layer support. GIS viewing is much more fun with a background map. And (invisible for users), the invention of the data provider abstraction for vector layers was very important. And there is plenty of additional functionality available now:

• store/save projects

• change the order of map layers,

• select vector features,

• classify vector features according to attribute values,

• edit vector features

• also an overview window

To make it short: qgis was a simple vector data viewer then and is a real desktop GIS now.

TS: Your area of interest in QGIS lies mainly in implementation of vector drawing capability. Could you explain briefly how the vector implementation model works? What are the good and bad aspects of the way that vectors have been implemented in QGIS?

QgsVectorLayer is the class which represents a QGIS vector layer. It has an association to a QgsRenderer, which manages how the features of the vector layers are displayed (classification, fill color, fill pattern) and also an association to a QgsDataProvider. The data provider is an interface which hides the details of data sources from the data layer. So QgsVectorLayer does not have to care if a data provider is a shapefile, a database, a GPS file or a grass file. To display the layer, QgsVectorLayer queries feature after feature from the data provider (QgsDataProvider::getNextFeature()) and passes a QPainter object to its renderer. The renderer sets the color, style, pattern, etc. and after this, the vector layer draws the feature with this QPainter.

So I think two good aspects of the vector implementation are the data provider and the renderer abstraction. It is now straightforward to add new data sources to QGIS and all of them benefit automatically from the capabilities of QgsVectorLayer. The same with the renderers. One problem of course is performance. I made some little tests to see where most of the time is spent in drawing a vector layer. And I found out that it is actually the drawing itself (done by QPainter). My test dataset took 10 seconds for drawing. I commented out the call to QPainter->draw... and all took only 3 seconds. So I hope that with the better usage of hardware acceleration in Qt4, drawing of QGIS layers will be much faster.

GS: Right now QGIS is more a viewer (and soon editor) of GIS data rather than an analytical tool. What true GIS features do you think are important for QGIS to support and how do you envision them being implemented?

Analytical tools could be implemented as plugins. There are several nice tools, which could be implemented this way:

• A plugin for raster map algebra (e.g. produce a raster which is the sum of two rasters, a' la Tomlin)

• A plugin for vector analysis (buffers, intersections, unions)

• A plugin with makes vector - raster analysis (e.g. sum of raster values in a polygon)

• A plugin for raster based terrain modelling and one for triangle based terrain modelling

• There are a lot of possibilities, but, as always, the who seems to be more difficult than the how :-)

GS: Some have commented that the pace of QGIS development is too slow. Do you think this is true and if so, what can be done to improve the pace?

In general I think it is too slow, but it isn't considering the limited resources we have. All QGIS developers write code in their free time. Personally, I work on QGIS half a day a weekend and about one hour per evening during the week (so 9 hours a week). If we would try to enhance the pace in this situation, we would lose in quality and I think quality is much more important than feature richness. Thus, the only solution to enhance development pace would be to have more developers and/or people working on QGIS on a professional basis. Unfortunately I don't have any idea about how people could work on it on a professional basis (so it's not really a solution in fact). If I had, I would already do it.

TS: For those not familiar with Qt, what is the attraction of using the Qt toolkit over other toolkits such as Gtk, Tcl/Tk, WxWindows etc?

I know Qt much better than the other toolkits, so I cannot do a sound comparison. Qt has several strong points: Qt code works under X11 Unix, Mac OSX and Windows. The GUI elements have a nice appearance and, from my experience, the library is very efficient and stable. An important point is also the nice object oriented design and the good documentation.

TS: Which areas are you looking for help in? Are there smallish easily identifiable tasks that you would like to hand out to other developers that they could implement without going through too much of a learning curve?

I see two possible tasks in the areas I'm working:

1. An important thing would be that we have the same editing possibilities for the OGR provider as for the PostgreSQL provider. At the moment, it is not possible to delete features in the OGR provider and also attributes cannot be added/ removed. This task would take place completely inside the OGR library.

2. Another interesting thing would be to have more possibilities for classifications in the renderers, not only 'equal interval', but also 'quantiles'.

Of course also non-programmers can help by testing, sending bugs and features requests.

TS: Is this the first Open Source project you have become involved in? How do you feel about the open source development process? Is it structured enough? Many people are frightened of working on OSS projects because they are afraid of embarrassment or criticism when their work is on public display. Did you experience any of these issues?

Yes, it is my first open source project. For a living, I work for a commercial software company (for a year) so I am able to compare it with the 'commercial way'. In the open source way, other people are looking at your code and I think this improves the quality of the code a lot. I think criticism is good (of course as long as it comes in a constructive and friendly way). Also I think it is more fun to share experiences with other developers. The advantage of the commercial way is that I am able to work 42 hours a week on the software instead of 9.

TS: What are the three websites you most commonly visit

1. of course the QGIS page,

2. the FreeGIS page (www.freegis.org),

3. and a popular German climbing page (www.climbing.de)

GS: Thanks for taking the time to answer our questions.