Page 1 of 5 (81 posts)

  • talks about »
  • uncategorized


Last update:
Mon Oct 16 23:05:18 2017

A Django site.

QGIS Planet

Do you want to host a QGIS developer meeting?

Each year the QGIS.ORG community holds two developer meetings. These events are an important part of  our project – they provide an invaluable opportunity for us all to meet face to face and share ideas, discuss issues and plan the future of QGIS.

The host of the developer meeting gets a special bonus for hosting the meeting: One of our releases will be named after the town / village / city etc. where the event was held – like this:

Screen Shot 2017-09-02 at 11.11.31 PM.png

We want to have a better idea of which venues we will be using for future events to help with out planning. So I am putting out a call for venue proposals:

If you would like to host a QGIS developer meeting (estimated 50 people per event) or a QGIS Conference (estimated 100-150 people per event) please contact us!

Please don’t submit proposals unless you have the authority to make such a proposal and are willing to act as the local organiser for the event. To make a proposal, fill out this form and tell us about your great venue!


Adding ESRI’s World Hillshade layer to QGIS

You may have seen my earlier tutorial where I described how to make nice looking hillshaded maps in QGIS using SRTM elevation data. Well, we don’t have to stop with just one hillshade layer on a map, it is possible to overlay multiple hillshades; a procedure that can increase the visual quality and detail. The following image is the hillshade we made before. Once you re-create a hillshade, following the previous tutorial, you can head to the next step (note that brightness and contrast settings may be different due to changes in how QGIS generates and displays hillshades).

We can improve the SRTM hillshade further by adding ESRI’s World Hillshade layer, which uses multi-directional illumination (also called a Swiss Hillshade in tribute to the celebrated Swiss cartographer Eduard Imhof). In addition, World Hillshade has a much higher resolution than SRTM 30m data in some regions of the world, it is 2m for most of the England and Wales, 10m for most of the US, 5m for Spain and 3m for Holland etc. The only drawback is that the style of this layer is somewhat controversial, some love it, some hate it, it looks like it’s illuminated from above, but mixing it with the SRTM hillshade obviates some of it criticised flaws.

To add the World Hillshade layer in QGIS go to the Layer Menu – Add Layer – Add ArcGIS MapServer Layer – click New and add the following URL:

Notice QGIS 2.18 no longer needs a plugin to add ESRI layers, it new has this functionality built in. Also, open the url in a browser such as Firefox, it brings up a webpage that describes the layer. We also see links to other other layers. Yes, they can all be added to QGIS by simply taking the URL of the webpage that describe the layer and connecting to it via the ArcGIS MapServer Layer connector.

Name the layer World Hillshade and click Connect, then click and highlight the layer it connects to. Finally, click the Add button to add the layer to the canvas.

Next, we need to adjust the properties of the World Hillshade layer to properly overlay it above the SRTM hillshade layer. Make sure the World hillshade layer is the topmost layer. In the Layers Panel, right click Layer properties and in the window that opens up, click Style (if not visible). Next, change the Layer Blending mode (under color rendering) to Overlay. Adjust the layer’s brightness to around -20 and leave contrast at 0. If you find the scene is still too dark, brighten the SRTM Hillshade by increasing the layer’s brightness. You may also have to change (lower) the Min value of the Min – Max value boxes. Leave the contrast at 0 for the SRTM hillshade. Also, don’t brighten it too much as it might become washed out, loose detail, especially in bright areas. Play around the controls, settings may vary depending on the SRTM data you download and the version of QGIS you use.

Here’s a comparison in Ireland, a ring like structure of hills with a central peak. No, it’s not a meteorite crater. It’s a different kind of geological marvel, the Slieve Gullion Complex and its ring dyke; the deeply eroded remains of a 410 million year old Caledonian volcano. The SRTM hillshade is on the left and World Hillshade + SRTM hillshade is on the right (click on the image, it’s best appreciated full size):

We can see the World Hillshade + SRTM Hillshade layer shows much finer detail. We see a parallel array of roughly north-south orientated lines, these are fractures and faults that cut the Slieve Gullion Complex that were perhaps enhanced by glacial erosion. Also, look carefully, there seems to be some roads meandering across the landscape (hint, bottom of the map and right of the scale bar). You should get even better results with higher resolution World Hillshade data. We also notice that bending SRTM derived hillshade with World Hillshade adds a naturalistic illumination not apparent in multi-directional hillshading. So we have the best of both worlds, a high resolution hillshade and realistic looking illumination.

Hope you found this tutorial helpful.


Baxter, S., 2008. A Geological Field Guide to Cooley Gullion, Mourne & Slieve Croob [pdf]. Geological Survey of Ireland, Dublin. p. 43-53.

Imhof, E. 1982. Cartographic Relief Presentation. Walter de Gruyter GmbH & Co KG.

QGIS Layout and Reporting Engine Campaign – a success!

Thanks to the tireless efforts and incredible generosity of the QGIS user community, our crowdfunded QGIS Layout and Reporting Engine campaign was a tremendous success! We’ve reached the funding goal for this project, and as a result QGIS 3.0 will include a more powerful print composer with a reworked code base. You can read more about what we have planned at the campaign page.

We’d like to take this opportunity to extend our heartfelt thanks to all the backers who have pledged to support this project:

We’ve also received numerous anonymous contributions in addition to these – please know that the QGIS community extends their gratitude for your contributions too! This campaign was also successful thanks to The Agency for Data Supply and Efficiency, Denmark, who stepped up and have funded an initial component of this project directly.

We’d also like to thank every member of the QGIS community who assisted with promoting this campaign and bringing it to the attention of these backers. Without your efforts we would not have been able to reach these backers and the campaign would not have been successful.

We’ll be posting more updates as this work progresses. Stay tuned…


2017 QGIS Governance Update


Screen Shot 2017-05-22 at 11.33.46 PM
QGIS Developers and Community Members working on QGIS at our recent meet up in Essen, German,

Dear Voting members (and interested QGIS community members out there)

This is an open letter that was emailed to all QGIS voting members today

Just a quick note from me to thank you for participating in our ‘virtual AGM’ – I know it is a bit of an unusual system but it suits our geographically diverse nature well and we seem to have pretty good participation in the process (though I really encourage those voting members who did not participate to do so next time!).
I have done a bunch of updates on our governance section of the web site so you can find the AGM minutes, annual report, budget etc. all on the site, and I (or whoever is chair) will post them there in future years too so everything is in one place and easy to access. Here with the relevant links:
Since we have approved a new version of the statutes, I have replaced the old PSC page on the web site with the new charter:
Thank you all for the many useful hints, tips and suggestions I regularly receive on how to make things smoother within the project (keep them coming!) – hopefully we will get into a steady routine with this governance now. We have been going through a lot of ramp up trying to get templates, processes, etc in place as we switch over to QGIS.ORG legal entity etc. We appreciate your patience while we figure things out – and a very big thank you to Andreas Neumann and Anita Graser who have pitched in with a lot of administrative work behind the scenes to help get the QGIS legal entity in place!
What’s next? I will be starting the nomination process for 4 new community voting members, soon (one to match each of the incoming country user groups for Norway, Sweden, South Africa and France). At the end of that process we will have 31 voting members.
Soon QGIS.ORG will be in the Swiss Trade Registry, which means we can be VAT registered, can take ownership of the QGIS.ORG trademark (which is currently held in proxy for us) and of course present ourselves as a well governed project, hopefully attractive to large funders who recognize the global good a project like QGIS does!
Tim Sutton
QGIS Project Steering Committee Chair

Call for presentations and workshop proposals: QGIS Conference 2017

NOTE: Deadline for proposals is May 15 2017

We are going back to Nødebo! Each year we combine one of our QGIS Developer Meetings with a User Conference. The User Conference is a great opportunity for QGIS users to meet developers and share their experiences – both with developers and with other users. Our first ever User Conference was held in Nødebo, Denmark in 2015 and we are thrilled to be going back to the beautiful venue at the University of Denmark’s Forest and Landscape College.


The user conference will be combined with the QGIS Developer Meeting and a summer school event, with the first week being focussed on the User Conference, the intermediate weekend on the QGIS Hackfest and the second week on the Summer School. The event will run from the 2nd of August through to the 11th of August 2017.

We would like to invite those who are interested in presenting a talk to apply now (NOTE: Deadline for proposals is May 15 2017). There are four kinds of contributions you can make (see the conference website for full details):

  • 20 minute ‘lightning’ talks
  • 1-2 hour short workshops
  • half and full day workshops
  • posters (which should be presented in the form of a map)

We have identified a number of themes for the User Conference:

  • QGIS Software Development
  • New Technology
  • Business
  • Government/Municipality
  • Science
  • Education

Presenters of full day workshops are eligible for a EUR 1000 reimbursement to offset their costs. You can find out more details at the conference web page (as well as registering your talk / presentation):

We are looking forward to seeing a great programme come together for the conference!




QGIS Grant Programme #2 Results

We are extremely pleased to announce the winning proposals for our 2017 QGIS.ORG grant programme. Funding for the programme was sourced by you, our project donors and sponsorsNote: For more context surrounding our grant programme, please see:

Our intent with the QGIS.ORG Grant Programme is to support work from community that would typically not be funded by client/contractor agreements, and that contributes to the broadest possible swathe of our community by providing cross-cutting, foundational improvements to the QGIS Project.

Voting to select the successful projects was carried out by our QGIS Voting Membership. Each voting member was allowed to select up to 6 of the 13 submitted proposals by means of a ranked selection form. The full list of votes are available here (on the first sheet). The second sheet contains the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:

Screen Shot 2017-04-30 at 3.23.08 PM

A couple of extra notes about the voting process:

  • The PSC has an ongoing program to fund documentation so elected to fund the processing documentation work separately from the grant programme (note *1).
  • Voting was carried out based on the technical merits of the proposals and the competency of the applicants to execute on these proposals.
  • No restrictions were in place in terms of how many proposals could be submitted per person / organization, or how many proposals could be awarded to each proposing person / organization.
  • Because of the importance of having good packaging systems on each of the three major platforms, the PSC elected to additionally fund the work on MacOS bundling scripts (note *2).
  • Although the budget for the grant programme was €20,000.00, the total amount for the four winning proposals is €19,800.00, with an additional €5, 800.00 being made available to support the processing work and and MacOS packaging work.
  • Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We had great participation in the voting process. Of the 27 voting members, 23 registered their votes.

Screen Shot 2017-04-20 at 4.11.45 PM
On behalf of the QGIS.ORG project, I would really like to thank everyone who submitted proposals for this call. There were many interesting proposals that I believe would be of great benefit to QGIS and I hope others perusing the proposals list will use their initiative and funding interesting proposals independently if they can.

Below you can find the detailed proposals of the successful applications – we look forward to seeing the results of their work land in the code base soon!

Details of the approved grant proposals


Proposer: Nyall Dawson

Amount: €1800

Details: Across the QGIS UI, numerous inconsistencies exist in the way different properties like opacity and rotation are exposed to users. These inconsistencies make QGIS harder to use, as behavior from one dialog differs to the behavior in another dialog. Some examples of this include:

  • Rotation of labels is done in the opposite direction in labeling to symbology. Accordingly, an equal rotation value will result in different rotation between labels and symbols.
  • Scales are inconsistently presented, with use of both the scale numerator and denominator in different dialogs. “Minimum” and “Maximum” scales also vary between dialogs, with some dialogs using “minimum” scale as the largest scale and some using “minimum” as the smallest scale. The labeling scale based visibility controls are the biggest offenders here.
  • Controls vary between specifying “opacity”, “transparency” and “alpha”. While these all have similar results, users must adopt values to map “opacity” to “transparency” in different dialogs. This is further compounded by different ranges used for each (eg 0-100%, or 0-255).

Due to the usual API freeze, it has not been possible to fix these discrepancies. The current API break introduced with version 3.0 allow a window for addressing these issues and standardizing behavior and API.

Despite the benefits in providing a consistent UI, the work involved in standardizing is fiddly (careful attention must be paid to not breaking existing projects) and repetitive, and unlikely to be undertaken by developers on a volunteer basis.  Furthermore it is highly unlikely that a commercial organisation could justify sponsoring UI standardisation efforts. Without grant funding it is unlikely that these issues will be addressed during the 3.0 development cycle, and the inconsistencies would remain for the lifetime of QGIS 3.x.

In this proposal I will:

  • convert all “transparency” controls to “opacity” controls, and consult with the community to determine the ideal value range presented (0-100% or 0-255) before making all opacity controls use the same range.
  • Ensure that rotation always operates in the same direction.
  • Fix the labeling scale ranges to use the same scale range definitions as layer visibility
  • As much as possible, automatically upgrade existing projects so that they open in QGIS 3.0 without any loss of transparency/rotation/scale settings
  • (As much as possible without large refactoring), adapt the PyQGIS API so for consistent naming and use of opacity/rotation and scale setting/getting methods. Making the API consistent makes scripting QGIS and writing plugins easier.

This proposal relates to the issues described at:

History: No work has currently been undertaken in this regard.

Qualifications: I am currently one of the most active QGIS developers, with a long history of quality contributions to the project. I’m passionate about seeing QGIS 3.0 address these kinds of long standing UI issues which detract from QGIS’ otherwise professional image and ease of use.

Implementation Plan:  The work will be undertaken prior to the QGIS 3.0 feature freeze period.

Proposal Link:


Proposer: Nyall Dawson

Amount: €2000

Details: Since QGIS 2.8, there has been an increased focused on creation of quality automated regression (“unit”) tests designed to flag issues in code before the code is introduced to the QGIS codebase. The increase in stability of recent QGIS versions can be directly attributed to this growth in unit testing. Despite this, many areas of the QGIS codebase remain with little or no unit test coverage.

One critical area which has insufficient unit tests is the geometry classes. The geometry classes form the basis of all geometry interpretation, algorithms, and rendering within QGIS. In order to provide stable QGIS releases, it is crucial that these fundamental classes are rock-solid, efficient, and do not suffer regressions between releases.

Some years ago (shortly after the introduction of the new geometry engine, in which support for Z/M values and curved geometries was added) I added full test coverage for the Point and Linestring classes, and partial coverage for the Polygon class. Unfortunately, writing geometry tests is tricky and time consuming. There’s many corner cases with unusual or invalid geometries which need to be tested. The time commitment required prevented me from writing additional tests, and to date the remaining classes (including multi geometries and all curved geometry types) have little or no test coverage.

This proposal covers writing additional unit tests to cover all the remaining geometry classes.

It is important to note that unit tests do NOT ensure bug free software. Unit tests only protect existing logic and avoid regressions when the covered parts of the code base are changed in future releases. Despite this disclaimer, the process of creating unit tests usually stress-tests existing code and in itself CAN reveal existing bugs. This was certainly the case when the existing tests for Point and Linestring classes were added – creation of the tests alone resulted in many fixed bugs and stabler Point and Linestring geometry handling.

History: This work would continue on from work I begun a number of years ago to provide 100% unit test coverage for the base geometry classes.

Qualifications: I have a long history of quality contributions to the QGIS project, and am currently one of the most prolific committers to the QGIS codebase. I have a long history with adding unit tests to QGIS and advocating for their increased usage amongst developers.

Implementation Plan: This work would be targeted to the QGIS 3.0 release, and would be committed to the codebase prior to the feature freeze/bug fixing period leading up to the 3.0 release.

Proposal Link:


Proposer: Martin Dobias

Amount: €10000

Details: I would like to propose a project that introduces 3D rendering capabilities in QGIS.
To summarize the planned work, the following features can be expected:

  • 2D view of map canvas rendered on the graphics hardware (GPU) allowing smooth zooming and panning of map view
  • 3D perspective view of the map
  • generation of 3D terrain model from DEM (digital elevation model) layers
  • map layers rendered as a texture on top of the 3D terrain
  • support for true 3D rendering of vector layers rather than having just flat appearance
  • map view widget that is dockable in the main window and synchronized with the main map canvas
  • support for picking (identification) of objects in 3D view and X/Y/Z coordinate display
  • support for 3D map view in map composer

The overall target is to introduce an extensible framework for 3D map view within QGIS, so that in the future developers can add various 3D rendering techniques for map data, using custom geometries and materials (which may involve writing own vertex/fragment shaders), possibly even allowing multi-pass rendering for advanced effects (e.g. to render shadows cast by buildings with a particular sun position).
3D support in QGIS is not only about adding the extra dimension to the rendering: it is also about making it possible to use graphics hardware for rendering of map in 2D – making map browsing even more pleasant and faster at the same time. Rendering 2D maps with OpenGL also opens the door to various new graphical effects that would be otherwise very expensive

to achieve by using just CPU for map rendering.
This proposal does not assume addition of new geometry types like polyhedral surface (with read support for those) into QGIS – the aim of the work is to get 3D rendering engine running and new geometry types may be added at some point later.

State of the art

QGIS features very good 2D rendering capabilities, however its 3D support has been very limited. Prior work on 3D in QGIS includes:

  • Globe plugin – a C++ plugin developed by Matthias Kuhn and Sourcepole based on OpenSceneGraph and osgEarth libraries. OpenSceneGraph is a generic toolkit that provides higher-level abstraction on top of OpenGL, making it easier to develop 3D applications than directly using low-level OpenGL interfaces.OsgEarth project then builds on top of OpenSceneGraph and provides a toolkit for working with geographical data: it has a terrain engine that combines elevation layers into a terrain, applies textures from “image” layers and adds feature layers with true 3D objects.The plugin acts as a bridge from QGIS environment and feeds scene data into osgEarth to do the 3D rendering.
  • Qgis2threejs plugin – a Python plugin developed by Minoru Akagi. It is able to export QGIS project (with various configuration options) into a HTML page that uses three.js library to render map in 3D within web browser using WebGL.
  • Horao – developed by Oslandia. It is a standalone 3D viewer based on OpenSceneGraph that may be controlled by a QGIS plugin to display map from QGIS in 3D environment. It has explicit support for true 3D geometries in PostGIS.

While these projects solve some use cases for 3D rendering of map data, each of them have their own limitations. For example, osgEarth library used by Globe plugin has its own data access and rendering of vector features implementation, duplicating QGIS code and not having parity in their capabilities. Moreover it has been difficult over time to keep the build working on all platforms supported by QGIS. The main limitation of Qgis2threejs plugin is the fact that the 3D view is exported to web browser, so the user cannot use benefits of having 3D view tightly integrated with the rest of QGIS. The fact that Horao has a standalone viewer

application results in similar limitations as when using Qgis2threejs (although it has some degree of integration with QGIS application).

Proposed approach
Now that QGIS 3.0 is based on Qt5, we can use some of the great new functionality added recent releases of Qt5. In version 5.5, a new framework for working 3D graphics has been introduced and every major Qt5 release since has been adding more functionality, improving performance, compatibility and stability. The 3D support nicely integrates with the rest of the Qt framework, providing a familiar API and at the same time staying very generic and highly efficient.
The 3D framework provides high level abstractions just like other libraries (e.g. OpenSceneGraph, three.js). 3D scene is built with nodes (called entities) with various components (e.g. transformation, mesh, material).
The idea is to build 3D support in QGIS on top of the Qt 3D framework. From my initial tests of the framework this looks feasible and it will allow us to stick with Qt APIs without requiring extra dependencies.
The work can be divided into the following chunks of work:

  1. Rendering engine core: develop a framework that will do rendering of the map scene in 3D. The engine will have the responsibility of processing raster layers with elevation into a mesh geometry and texturing the mesh with map images rendered by the existing QGIS 2D rendering engine. The engine will support levels of detail (LOD) and tiling in order to be able to display high-resolution data in real time without having to load all the data into memory at the time of scene creation (which may be prohibitively expensive with more complex layers). 3D scene will be dynamically updated as user browses the map, keeping the amount of rendered triangles low while appropriate quality of the terrain for given zoom level.

All of the processing needs to be done in the background, so the user may freely browse the map and the scene will be continuously updated with data (changing between higher/lower detail when zooming, loading more data when moving map).

  1. Handling of user input: controller for camera that will make the camera fly on top of the map. Support for picking will be added to allow identification of objects in the map and display of coordinates at the mouse position.
  1. Integration with QGIS environment: dockable 3D map widget for the main window, synchronization with 2D map canvas, support for printing of 3D views in map compositions.
  1. Advanced 3D rendering techniques: interface that will allow adding new methods for data visualization in 3D and exploration of methods for rendering. By default map layers will be rendered into map image with the existing 2D map renderer – this interface will allow map layers to instead have 3D renderer associated which will provide entities with custom meshes and materials. As a result we will be able to achieve true 3D appearance of objects (e.g. point clouds, trees as 3D models, tesselation of polygons, buildings with extruded geometry and custom texture). Implementation of the advanced techniques is a task with nearly unlimited scope, so the idea is to develop a suitable interface and as the time will allow, implement some techniques.

History: For this proposal I have studied various sources:

  • looked into existing 3D viewer projects related to QGIS
  • explored Qt 3D framework
  • researched some academic papers regarding terrain generation and vector data display

As a proof of concept, I have created a simple prototype in C++ using Qt 3D framework. It displays aerial imagery on top of a terrain model created from a raster layer (DEM) and allows simple camera control. The code is available here:

Qualifications: I have been a core QGIS developer for more than 10 years and I have a very good knowledge of QGIS codebase, especially the existing 2D map rendering pipeline.
Previously when working at the university, on a project for stereo matching (creation of point cloud out of a pair of images) I worked on visualization of 3D data using OpenGL.
Implementation Plan: The plan is to work on the project between May and July 2017. As of now, the plan for QGIS releases (according to the mail from Paolo) is that QGIS 3.0 will have feature freeze in July 2017 and final release in September 2017. If nothing changes in the QGIS release schedule in meanwhile, the 3D support could be integrated into QGIS master branch before the feature freeze and thus released in QGIS 3.0.
If the project would be accepted, the first step will be to develop a prototype of the 3D rendering engine, then prepare a more detailed architecture proposal as a QEP and continue the implementation once the QEP gets accepted by the community. The work progress should be available on a branch in GitHub for anyone interested.
Proposal Link:


Proposers: Matteo Ghetta, Alexander Bruy

Amount: €4000

Details: This proposal aims to improve the existing Processing algorithms documentation. With the pull request it is possible to add external links for the documentation (both local and remotes). However the effective use of the pull request is not yet included in Processing.

With this proposal the existing code will be incorporated in Processing, allowing to have a Short Help tab (the existing one on the right of the Processing algorithm window) and a Long Help tab (next to the Log tab).

The Short Help tab will be collapsible in order to have a bigger window for the algorithm parameters, while the Long Help tab will point to the on-line existing documentation of Processing for each algorithm (

The default link of the on-line documentation will be added in the QGIS Settings (thanks to the pull request already merged) in order to have the standard documentation visible but to let the user the choice to overwrite it and load custom paths.

In addition to the code part, this proposal aims also to document the GDAL/OGR provider and the QGIS core algorithms. Existing documentation will be reviewed and pictures will be added when useful, while for algorithm not yet documented, the help will be written from scratch with description and additional pictures.

Currently there are:

  • 49 GDAL/OGR total algorithms, 35 to enhance with pictures, 14 to write from scratch
  • 154 QGIS algorithms, 38 to enhance, 116 to write from scratch

This means a total of 73 algorithm to enhance and 130 to write from scratch.

History: The pull request is already merged and it is worth to make it effective to have nice, rich and translatable documentation for the Processing algorithms.

Qualifications: Matteo Ghetta: working since the release 2.0 on the documentation and made several improvements and pull request to both documentation and Processing code.

Alexander Bruy: core developer since 2010, co-maintainer of the QGIS Processing framework.

Implementation Plan: The code and the documentation will be ready for the QGIS 3 release.

Proposal Link:


Proposer: Régis Haubourg

Amount: €6000

Details: QGIS has reached a mature level and offers now a very good framework to create professional applications. One of the main reasons is that QGIS is a very strong client for spatial databases, and in particular with PostgreSQL and postGIS for which it was initially created.

Since version 2.14, QGIS offers the not-so-well-known ability to handle transaction groups, which means it can instantly evaluate triggers on database side, and refresh all layers in the same transaction. This is a big win for usability, but some drawbacks glitches remain, such as the lack of the undo/redo edit buffer, a very raw way of saving (ie quitting edition session) or having the legend cluttered by so many edit symbols (a pen symbol). Current proposal is to go a step beyond to make QGIS even better for PostgreSQL by achieving the following targets:

1 Restore an undo /redo feature by taking advantage of PostgreSQL. If possible we will try to take advantage of PostgreSQL named Savepoints.

2 Allow to have some layers not switching to edit mode in QGIS,  even if they belong to the same connection. These layers will still benefit from the instant refresh, but won’t clutter the legend with the edit pen symbol everywhere, nor risk to load QGIS snapping cache for nothing. A UI for those settings could be an evolution of the current “identify layer” list in the project properties.

3 We would like to submit a mechanism to allow converting error messages raised by the provider, like a RAISE from postgres, into custom user oriented message. Say for instance, instead of a “provider error – duplicate key for… “, QGIS project could be tuned to display first “You tried to insert a feature using the same identifier as another one”.

The error message list and regexp rules would be optionally stored in qgis project or read from a datasource table (for instance when error messages rewrites are shared by other applications). The original error message would be still avaiblable by expanding the details of the messageBar and in the general message log.

4 Cherry on cake point, we wish to have QGIS take advantage of PostgreSQL NOTIFY signals to trigger behavior in QGIS when something changes in the database (see . A first implementation proposal is to allow a map canvas refresh, but we can imagine really dynamic applications driven by the database events by converting NOTIFY messages into QGIS signals (oh yeah!).

History: In our team, we already use transaction groups for production tools and that is much appreciated. We already use some python logic to catch error message and convert them to more user oriented ones. We frequently develop applications where QGIS is linked with heavy database containing most of the intelligence. Having a really interactive edition process, speaking the same langage as average users, and being able to be triggered from database process will unleashed many possible applications.

Qualifications: Oslandia has three QGIS developers, two of them being core comiters and high  skills with Postgres and Postgis (core comiter too). We believe that developing using thick databases is a major strength of QGIS, and we have great fun getting involved in that area of the code 😉

Implementation Plan:  We currently are quite involved in QGIS 3 server refactoring and major changes such as Auxiliary Storage for project or core solutions for label connectors. We also are involved in applications build on top of QGIS for Water management like QWAT or QGEP. Such changes would benefit immediatly to those project. Our target is to provide those improvements with all necessary unit tests for 3.0 release.

Proposal Link: coming soon..




Proposer: Larry Shaffer


Amount: €1800


Details: Currently, the macOS bundling routines (to create a self-contained application) in CMake scripts where created by William Kyngsburye many years ago. Since then, CMake has added many features for bundling, e.g. BundleUtilities (, that handle similar functionality to what has been arduously maintained in the CMake scripts. While the current setup does function, it is quite antiquated and adding any new QGIS dependencies to be bundled is an error-prone ordeal. I propose to fully update the bundling routines to leverage modern CMake capabilities, since building on macOS usually uses the latest CMake versions. Once completed, anyone with appropriate dependencies should be able to produce a production-ready bundle, including the QGIS project itself.


History: I will first build upon the existing work to ensure there is a minimal bundled, then completely refactor the same functionality using a modern CMake code workflow.


Qualifications: I have extensive knowledge in CMake and frequently utilize it in my work for my employer, Boundless Spatial. I have already completed a fully bundled distribution by my employer (similar to the first phase of the proposed work here), though Boundless now uses a different installation approach. I have been working for years on the OSGeo4Mac project in anticipation of producing better CMake bundling routines, to ensure the QGIS project can independently produce its own macOS distributions.


Implementation Plan: Basic work will follow these steps:

  • Append minimal bundling to existing CMake setup, so there is a least a functioning bundling routine, regardless of whether the proposed work is accomplished in time for the major next release.
  • Ensure the bundle is code-signed
  • Create a new methodology, based upon CMake’s BundlesUtilities, *in-line* next to the existing CMake routines, so both can be used, until there is a valid replacement.
  • Focus on minimal bundling, then add GRASS
  • Continue extending bundling routines to include major Processing providers, e.g. OTB, Saga, TauDEM, etc.
  • Ensure new method’s is properly code-signed
  • Enable bundling on Travis CI infrastructure, via Travis’ cron jobs, thereby adding the capability for the QGIS project to produce fully bundled nightlies of macOS builds.
  • Once new method represents a full replacement, old method will be removed, not just deprecated


Intended completion is in time for QGIS 3.0 release and packaging efforts.


Since the new method does not affect any existing code, as soon as useable functionality is achieved, it will be merged directly into master, then further code committed as work progresses.

Proposal Link: None at this time. Should I consider a QEP? Not many developers beyond the few existing packagers and experimenters would be involved. I would prefer to write a blog post after the work is completed, though post to the QGIS dev mailing list the intention to do the work, if this proposal is granted.

Update on the QGIS Grant Applications

In February this year, we put out a call for applications for the second (yay!) round of the QGIS grant programme. The intent of the programme is to leverage donor and sponsor funding in order to support community members with great ideas to improve the underlying infrastructure of the QGIS project and code base.

We have had a really great response to the call for applications (detailed list of applications is here for your reading pleasure – 231KB download).

Given that we have 13 proposals (down 7 from our last call) and only 20,000 Euros to disburse, the QGIS voting members will need to make some tough, pragmatic choices.The voting for the grant proposals ends at the mid April 2017, and we plan to announce the successful candidates soon after that. The PSC will arbitrate in the case of a dead heat or the proposal amounts of the top voted proposals not adding up to our funding target.

Although the number of proposals submitted is down from last year, the quality and utility of the proposals this year is really top notch and it is sad to know that we will not be able to fun them all through the grant programme. If you have the wherewithal to further support some of the grant proposals that did not make the cut, or the QGIS 3.0 effort in general, please get into contact with our treasurer, Andreas Neumann (finance [at] or head over to our sponsorship or donations page to support their work!

Lastly, I appeal to those QGIS Voting Members who have not yet cast their votes to check your email and head over to the voting form to cast your vote!

2017 Hackfests and Summer Camp

Where is QGIS being developed?

That is a questions my students often ask. Open Source is a strange and new ‘world’ for most of them. So I try to explain: QGIS is a software, developed and maintained from all over the world by developers who are employed by companies, self-employed or working for free…

Some of the work is paid for by QGIS and some by users and as written – some do it for free – yay!  The core developers meet two times a year for ‘Hackfests’  (do not confuse with ‘Hacking’).

Sometimes a Hackfest is combined with a user conference – where developers and users can meet, listen to presentations and discuss functionality.

In 2017, the first Hackfest will take place at the Linuxhotel in Essen – Germany from Friday from 28th April – 1st May. This Hackfest is only going to be hard work for the developers – QGIS 3.0 is being developed and launched this year. More details and signing in for this weekend on the event wiki page.

The second Hackfest in 2017 will include a Summer Camp and take place in Nødebo at University of Copenhagen, Forest and Landscape College (Denmark) from Wednesday  2. August till  Friday 11. august

The Summer Camp will be a combination of work and leisure for the developers. And for users there will be workshops.

It is the first time we are having a Summer Camp at the Forest and Landscape College. We have both the place for work and the nature for exploring.

There are 28 rooms/56 beds, 3 large shelters and a large lawn where you can bring a tent sleeping bag and mattress.

Nearby the wonderful forest and lake.

The setup is as following:

Users pay for participating in workshops, food and accommodation (room/bed) – Shelter and tent are free.

Developers and workshop lecturers stays for free.

Call for workshops and sponsors: If you have a topic for a workshop or want to contribute as sponsor, please send me an e-mail at

Save the dates – and we will send out more information about the Summer Camp later this month.

Posted on behalf of Lene Fischer, QGIS Community Organizer

QGIS Top Features 2016

A year ago I have asked QGIS’s community what were their favourite QGIS new features from 2015 and published this blog post. This year I decided to ask it again. In 2016, we add the release of the second long-term release (2.14 LTR), and two other stable versions (2.16 and 2.18).

2016 was again very productive year for the QGIS community, with lots of improvements and new features landing on QGIS source code, not to speak of all the work already in place for QGIS 3. This is a great assurance of the project’s vitality.

As a balance, I have asked users to choose wich were their favorite new features during 2016 (from the visual changelogs list). As a result, I got the following Top 5 features list.

5 – Paste a style to multiple selected layers or to all layers in a legend group (2.14)

This is a productivity functionaly that I just realized that existed now, with so many people voting on it. If copy/paste styles was, in my opinion, a killer feature, being able to use it in multiple layers or even a group is just great.


4 – fTools plugin has been replaced with Processing algorithms (2.16)

While checking the Vector Menu, the tools seem the same as previous version, but it’s when you open them that you understand the difference. All vector tools, provided until now by the fTools core plugin, were replaced by equivalent processing Algoritms. For the users it means easier access to more functionality, like running the tools in batch mode, or getting outputs as temporary layers. Besides some of the tools have been improved.



3 – Virtual layers (2.14)

This is definitly one of my favourite new features, and it seems I’m not alone. With virtual layers you can run SQL queries using the layers loaded in the project, even when the layers are not stored in a relational database. We are not talking about WHERE statments to filter data, with this you can do real SQL queries, with spatial analysis, aggregations, and so on. Besides, virtual layers will act as VIEWs and any changes to any of the input layers will automatically update the layer.

Screenshot from 2017-01-05 01-12-10.png

2 – Speed and memory improvements (2.14)

It’s no surprise that speed and memory improvements we one of the most voted features. Lots of improvements were made for loading and managing large datasets, and this have a tremendous impact in all users. According to the changelog, zoom is faster, selecting features is faster, updating attributes on selected features is faster, and it consumes less memory. So don’t be afraid to put QGIS to the test.

1 – Trace digitising tool (2.14)

If you do lots of digitising, you better look into this new feaure that landed on QGIS 2.14. It allows you to digitize new feature by using other layers boundaries. Besides the quality improvement of layers topology, this can make digitizing almost feel pleasing and fast! Just click the first point, move your mouse around other features edged to pick up more vertex.



There were other new features that also made the delight of many users. For example, several improvements on the labeling, Georeference outputs (eg PDF) from composer (2.16), Filter legend by expression (2.14), 2.5D Renderer. Personally, the Style docker made my day/year. But you can check the full results of the survey, if you like.

Obviously, this list means nothing at all. All new features were of tremendous value, and will be useful for thousands (yes thousands) of people. It was a mere exercise as, with such a diverse QGIS crowd, it would be impossible to build a list that would fit us all. Besides, there were many great enhancements, introduced during 2016, that might have fallen under the radar for most users. Check the visual changelogs for a full list of new features.

On my behalf, to all developers, sponsors, and general QGIS contributors, once again


I wish you a fantastic 2017.

Let’s make a big funding push for QGIS 3.0!

In 2017 we are planning to release QGIS 3.0. This new major version will become the basis of the next LTR release (QGIS 3.2) and is set to be a sea-change in the development of QGIS. It will modernize the architecture to get rid of many legacy issues that we were unable to resolve in the minor release series of 2.x releases. For example we are switching to Qt5, Python3 stripping out deprecated API’s, cleaning away many old code artifacts, and making a huge range of under the hood tweaks to improve the performance and stability of QGIS. Here are some of the other key issues that need to be worked on before we can release QGIS 3.0:

  • QGIS Server needs to be updated to work with QGIS 3.0
  • QGIS Composer needs an overhaul

There are many more ‘under the hood’ items like this that we would like sort out before we can release QGIS 3.0.

Recently we announced the winners for our new grant programme which directly funds developers wishing to make improvements to the QGIS project. We would like to amp things up a notch further and thus with this blog post we would like to make this appeal:

  • If you are an individual user please consider making a donation to the project (donations can be made by PayPal or by direct bank transfer).
  • If you work for a company, please consider becoming a project sponsor. Our entry level sponsorship is not a lot of money and will make a great contribution to the project. We are still looking for our first platinum sponsor – perhaps your company could be the first! Here is the list of sponsorship levels for quick reference:
Euros Sponsorship level
27,000+ Platinum Sponsor
9,000+ Gold Sponsor
3,000+ Silver Sponsor
500+ Bronze Sponsor
  • If you are a company that makes use of contract QGIS developers, include in your contracts a provision for the developer to get your new features into the 3.0 code base with a nice set of tests so that the burden does not get passed upstream to volunteer developers to port your features to QGIS 3.0.
  • If you are a company that has in-house QGIS developers, consider allocating some of their time to supporting the QGIS 3.0 development effort.
  • If you are a country user group, please try to hold a funding drive within your user group and pass the funds either to the upstream QGIS.ORG project or support developers who are in your country to do bug fixing and implementation work for QGIS 3.0.

If you have other ideas about how to support the effort we will be glad to hear them! We will put as much money from QGIS.ORG funds as possible into developers that are willing and able to work on the preparation of QGIS 3.0.

A huge thank you to all of those that have already contributed time and money into the effort to get QGIS 3.0 ready for release!

QGIS UK Edinburgh: an overview

6th Scottish QGIS UK user group meeting
Informatics Forum, University of Edinburgh, Edinburgh
3rd November 2016

A full house with all tickets sold. Our biggest event yet. A last minute decision to video the talks. A first ever raffle to raise funds for the QGIS project. More than half the attendees were at a QGIS user group for the first time. All sectors represented and a range of talks from accessible introductions to QGIS functionality to wonderful technical geekery to varied FOSS4G use cases.



How deep is your loch?
Phil Taylor (@scienceandmaps) from CEH opened up the day with a detailed explanation of how he lovingly captured the plumbed depths of four Scottish lochs and turned them into interactive 3D visualisations. You can see his results at



QGIS Server: the good, not-so-good and the ugly
Fiona Hemsley-Flint showed us the exploratory work she and her team have done with QGIS Server as a possible replacement for MapServer and Cadcorp GeognoSIS. QGIS server is capable and can render complex styles and labels well but was generally 5 to 10 times slower than GeognoSIS in rendering the maps.



Installing QGIS on a Network
Tom Armitage (@MapNav_Tom) from the University of Edinburgh gave a quick run through of the requirements for installing QGIS 2.14.3 across 3000 computers.



Mapping narrative: QGIS in the Digital Humanities 
Anouk Lang (@e_a_lang) from the University of Edinburgh explained how mapping and visualisation were used to engage students and explore literature in a different way.



QGIS Plug-in for Parallel Processing in Terrain Analysis
Art Lembo (@artlembo) from Salisbury University, Maryland, USA got everyone excited about advances in personal computing power and how graphics cards can be harnessed to speed up spatial processing. The trouble with geographic data is that it is usually a large chunk of data with relatively little processing required. Parallel processing likes small chunks of data that need huge amounts of processing. The plugin hits the limit of the ability of Python to pass through more data. That’s how fast the graphics cards are.



Viewshed analysis and how to find the heart of Scotland
Neil Benny (@bennymapper) from thinkWhere gave a very useful overview of how to use the different tools in QGIS to generate viewsheds which a lot people at the event could see a use for in their workflows. See for more information.



qgis2web: geocrustin’
Tom Chadwin (@tomchadwin) from NNPA gave an entertaining talk on how and why he developed the qgis2web plugin. He showed us how to use it and you can see why it is such a popular extension to QGIS.


QGIS 3.0, WMTS previews and XYZ support in QGIS 2.18
Pete Wells (@lutraconsulting) from Lutra Consulting gave a more technical talk on some behind the scenes work that they have been doing to make using QGIS 3.0 even better for the user. No more waiting for the base map to load as the WMS server thinks about the request – tiled services quickly and seamlessly fill the screen. For more information see


Decision Support Systems in Forestry
Stephen Bathgate (@Forestry_Research) from the Forestry Commission gave a real world example of how a GIS, and then an open source GIS infrastructure, delivered improved workflows, better efficiencies and made a smaller workforce more effective.



Collecting spatial survey data with Leaflet and OpenStreetMap
Louise Sing (@sing_louise) from Forestry Commission gave a lightning talk on how she used tips learned at previous QGIS user group meetings to put together a simple Leaflet map to collection information about how people use different areas of forest.


Indoor 3D routing with QGIS and pgRouting
Tim Manners (@tmnnrs) from Ordnance Survey demonstrated the interactive 3D route solving application created using QGIS and the QGIS2threeJS plugin. It can be used to route between locations spread across multiple floors in a building. It can take into account width and height restrictions such as doorways and lifts and can be used to model mass evacuations of a workforce.



Using QGIS for wildlife surveys and reporting
Andrew Whitelee (@VerdantWildlife) from Taylor Wildlife lead an interactive talk highlighting the difficulty of undertaking robust repeatable wildlife surveys in the great outdoors. He showed how the use of high quality mapping and GPS tracking improved the quality of the surveys and how much sense the use of open source software made for small enterprises.



Them Thar Hills: shadin’, texturin’, blendin’
Ross McDonald (@mixedbredie) from Angus Council gave a lightning talk on different ways to generate hillshaded images from elevation models. Regular hillshaded images can be enhanced by generating texture shaded images. Texture shading enhances the drainage network and the visual hierarchy of the landscape. Blender can be used to create rich shaded relief by modelling real sunlight and reflection across the landscape. See for more information or press F7 in a recent version of QGIS to open the live style dock.



DOHA: Doha Online Historical Atlas
Michal Michalski from Scottish Government and the DOHA project showcased the mapping work he has been helping with in Doha and the archaeological investigation into the origins of the city. The website is a fantastic example of the integration of different resources including historic maps, photographs, videos and historic records. See for more information.


3D indoor maps with QGIS
Tim Jenks (@eeGeo) from eeGeo gave a short talk on how QGIS and other tools were used to build navigable 3D maps of cities and buildings. See for a demo.


Tom Armitage closed with some remarks on how open source software works and how the QGIS community supports the QGIS project. Roger Garbett managed the raffle (all 500 tickets sold!) with some great prizes (Splash-Maps voucher, QGIS t-shirt voucher, OS colouring map book, Art Lembo’s text book on geospatial processing, stickers and others) the proceeds of which will go to the QGIS project. There is, after all, no such thing as a free lunch. Even if fantastic and generous sponsors – Ordnance Survey, thinkWhere, Angus Council, Cawdor Forestry, eeGeo and EDINA – give us a lovely selection of food and drink (thanks BlueSkyCatering) and a top-class venue for a brilliant day out.



The day ended in the Potting Shed with (strong) cask ales and ciders refreshing parched throats. Always a great way to wrap things up.


Notes from the QGIS-UK South West user group

Yesterday Dartmoor National Park was host to the third QGIS user group for the South West region. We a great range of talks from the worlds of academia, offshore exploration and local government to name but a few. The slides from these are below.

Teaching in QGIS

Using PostGIS within our Geospatial Workflows at Lloyd’s Register

The Adoption of QGIS at Plymouth Community Homes

Integrating QGIS functionality into a data workflow through both automated processing and a plugin

PopChange: An Academic Open Source Project

Building a Mixed GIS Environment at the Met Office

We are looking at having another meet up in the spring and are thinking of running some workshops on form designing and plugin building. Keep an eye on the main QGIS user group page on Google+ for any news.

Thanks again to everyone who attending and presented.  We also need to give a special thanks to Clear Mapping Company for sponsoring the event.



QGIS2 compatibility plugin

Lately I’ve been spending time porting a bigger plugin from QGIS 2.8 to 3 while maintaining 2.8 compatibility. You can find it at and One code to rule them all. My target was to have to edit the

What are trusted plugins?

The core team of QGIS strives hard to provide the most advanced and user friendly GIS for free use by everyone. In the core QGIS project, every line of code that gets committed is subject to peer review when contributed by a non core developer. This gives us an opportunity to identify and correct inadvertent (or intentional) security issues that a developer may introduce into the code base. By contrast, all of the plugins that are published via the QGIS plugin repository are reviewed by the plugin developers themselves and we don’t have good insight into how much due diligence is applied to plugin code management.

The vast majority of our plugins (listed in and inside your copy of QGIS) are developed by third parties, either individuals, companies, and institutions. As such, they are outside our direct control and the developers often relatively unknown to the QGIS community. We view this as a potential security risk. We are convinced the risk is small, because of many factors including the “many eyes” principle (the code is visible to everybody, and in use by thousands of people), but cannot exclude the possibility that someone tries to inject malicious code into a plugin.

In order to address this situation, we looked into the opportunity of implementing automatic tools to scan plugins, before their publication, and spot potential problems. Our research indicated that this approach would be difficult and costly, and easy to circumvent.

We (the PSC) therefore decided to implement a simple yet robust approach to security, based on the ‘web of trust’ principle: we trust people we know well in the community. You will see on the web site that there is a ‘Trusted Author’ tag has been applied to plugins created by those members of the community that we know and trust.

The criteria for ‘Trusted Authors’ includes those community members that regularly meet at our QGIS developer meetings, and and those that are in almost daily contact with the core team via our developer mailing lists or background project discussions. The remaining plugins (and there are wonderful, reliable, robust, and useful plugins in the list) have not been given the ‘trusted’ label.

We would be delighted if a side effect of this choice would be to stimulate more active and direct involvement of plugin developers in the QGIS community. All plugin developers are therefore invited to join us at one of the next developer meetings (AKA HackFest), or otherwise become a recognized, active member of the community, so they can be integrated as ‘trusted’ plugin developers.

Results of the QGIS user survey 2015

In autumn last year, we ran a rather large-scale user survey, which was translated into many languages and advertised here on this blog. The final reports can be found here:

(Let me know if you have links to other language versions which were not sent to the mailing list.)

Looking at the English report, most responses were filed by regular (49.7%) and advanced users (35.9%) who use QGIS at least several times per week. One interesting result is that responders feel that the project should still prioritise new features when spending funds:

Top 3 “highest priority for spending QGIS funds”

  1. Important features that are missing (50%)
  2. More bugfixing (24.1%)
  3. Improved user documentation (12.4%)

This is also confirmed by the free comments section were roughly 23% of responders were asking for new features, 19% called for more stability (fewer releases and new features), and 9% for better documentation.

Documentation improvements were followed closely by calls for a more structured approach to plugins (making it easier to find the right tool for the job), stricter plugin documentation requirements, consolidation of plugins with similar functionality, and integration of key plugins into core.

When interpreting these results, it’s important to keep in mind that responses are skewed towards experienced users, who are more likely to require specialist functionality. Beginners on the other hand might rank stability, ease of use of core functionality, and good documentation higher.

QGIS Grants: Call for applications

We are pleased to announce the first round of funding for the QGIS grant programme.

What is the grant programme?

The QGIS.ORG grant programme is our way to accelerate and streamline development of the QGIS.ORG project by rewarding committed developers and contributors for their work through a grant system. It is a way to distribute our funds amongst our team members in a fair and transparent way.

Why have a grant programme?

There are four main reasons for embarking on a grant programme.

  1. The first intent of the grant programme is to amplify the contributions of grantees by allowing them to spend more time on QGIS over and above what they would be able to do on a purely volunteer basis. At the broader level we would also like to avert the potentially negative reaction to funded development work in QGIS: “Why should I donate my time to work on QGIS when others are paid to do it?” And rather create an aspirational environment: “If I make a large contribution to QGIS I could also be eligible for a grant like other dedicated contributors have received.”
  2. To simplify the decision making process for how to spend the funds received in the QGIS project via our Sponsorship and Donations programmes. The grant programme would allow us to streamline our decision making when it comes to funding developers. We receive many proposals for funding various activities in QGIS which invariably lead to protracted debate. In addition, not having a cohesive plan for how to disburse QGIS funds results in funding being done in a very ad hoc manner – which in turn results in a skew of funding towards development related activities and away from other critical project activities such as improvement of user documentation, API documentation, sysadmin tasks and so on.
  3. To get things done that volunteers don’t naturally gravitate towards doing, such as housekeeping, maintenance and so on.
  4. To transparently spend QGIS.ORG funds to advance the QGIS project.

In this funding round, we are ring-fencing EUR 20,000 for the grant programme. We expect to run further grant calls in the future if this round proves to be a success and as funds allow.

Applicants may submit more than one proposal and the proposal may be on any topic that you think is relevant and beneficial to the greater QGIS community. Some examples of the kinds of topics you could propose are:

  • Updating and improving documentation
  • Updating and improving web infrastructure
  • Implementing a new feature in QGIS
  • Curating the pull request queue
  • Bug fixing
  • Improving API documentation
  • Improving the API and help making QGIS 3.0 a reality
  • Rewriting and improving a part of the code base
  • A security review of QGIS
  • Helping new QGIS devs to get started with improved developer documentation and utilities
  • etc.

The closing date for applications is Thursday, 15 September 2016

PLEASE NOTE: All applications made here will be PUBLICLY VISIBLE, including your name.


Here are a list of frequently asked questions relating to the grant call. Please check back on this article regularly – we will update it as any new questions are raised so that everyone may benefit from the answers.

1) Q: Are collaborative proposals allowed?

A: One person should be the proposal lead though. Additional collaborators can be mentioned in the proposal details section.

2) Q: Can I make a proposal for a smaller amount?

A: Yes

3) Q: Can I make a proposal for a larger amount?

A: No

4) Q: Can I charge VAT / additional expenses on top of the grant allocation?

A: No, the amount should be all-inclusive.

5) Q: How will the grant awards be decided?

A: Grant applications will be decided on by vote of the QGIS Board Voting Members

6) Q: Can the grant be made on behalf of my company or a group of people?

A: Yes. Just note that any application you make should be inclusive of all costs, VAT, Taxes etc.

7) Q: How many grants will be awarded from the 20,000 Euros?

A: We expect to award at minimum two grants, possibly more if there are a number of smaller grant proposals that are worthwhile.

8) Q: Can I make more than one application?

A: Yes

9) Q: Is this like Google Summer of Code – a mentorship programme?

A: No. We will not provide mentorship – we expect that you are already an established developer or contributors to the QGIS project and do not need any ‘hand holding’ other than via normal community consultation processes like QEP’s.

10) Q: I am thinking of submitting a proposal to do XYZ. Would that be considered a valid proposition?

A: We don’t have any specific pre-conceived ideas of what a valid proposal is, so I would encourage you to make a submission if you think it is worthwhile. During the decision about which proposals to access, we will consider factors like:

  • how broadly useful the proposal is to all our users,
  • how unlikely is it that the feature or improvement would be done without Grant funding,
  • how much ‘value’ does the work bring to the project,
  • how feasible is it that the applicant will actually achieve their goals etc.

11) Q: Have you thought of how to handle situations where person A submits a proposal and, later, person B submits the same proposal but cheaper?

A: In these cases, we will use criteria such as the applicant’s standing in the community, the technical details of their implementation plan, etc. Price would probably be a low-weighted factor but certainly could enter into it if there is a significant difference.

12) Q: I’ve read that QGIS 3 might land in first quarter of 2017 (if everything goes well). Do you expect proposals to be tied to QGIS 3? Should bug fixes, plugins, PyQGIS book translations, should they be planned, developed, and tested against QGIS 3’s code base?

A: Where proposals relate to the code base, yes we would expect that they are ‘3.0 ready’ – though they do not necessarily have to be completed when 3.0 is released.

13) Q: Do you have an indication of how long it will take for the grants to be awarded after the closing date?

A: It’s a bit hard for me to say how long it is going to take. The process will entail asking the QGIS voting community to rank all the proposals. Depending on how many proposals we receive we will need to allow for sufficient time of this to happen. We hope we can do it within a month of the closing date for applications but it we get a hundred proposals we will need more time probably….
Q: I still have questions, who can I ask?

A: Please contact if you have further questions, or write to the pic mailing list.


How to apply:

To apply please use this online form


Report back: 15th QGIS hackfest in Girona, Spain

Time flies when you are having fun! It seems like only yesterday that I was writing about the 14th Hackfest in Gran Canaria. At the end of May 2016, we held the 15th QGIS hackfest! QGIS has been on an incredible journey since the project was started by Gary Sherman 14 years ago, and the fact that the hackfest was held in tandem with the 2nd QGIS International User conference is a testament to the growth and strength of the project.

2nd International QGIS Conference

Isn’t it amazing – we just held the second international QGIS User’s Conference! We really need to give credit to the amazing team who ran a totally seamless operation to organise the event: Gemma Pons, Toni Hernández, Josep Sitjar, Alexandre Busquets, Ferran Orduña, Rosa Olivella, Laura Olivas, & Lluís Vicens

Girona Organising Team

We would like to give a special thank you to the University of Girona’s Director of GIS Service (SIGTE) – Gemma Boix who helped to organised the event as well as ensuring the institutional support for the event. In case I have missed mentioning someone by name, our thanks to all the other volunteers and the sponsors of the conference. Not only did the conference team host the conference event, they also covered a large part of the costs of the hackfest that followed the conference – for which we can’t thank them enough! OSGeo also supported the hack fest financially for which we are extremely grateful.

The conference team also extends their thanks to the attendees and presenters, instructors and developers who also actively participated on the event!  For those interested in viewing the various talks at the conference, here are some handy links:


State of QGIS

The project is in a very healthy state right now. For my talk at the user conference (video here) I got some fresh download stats from our servers and the numbers are quite astounding: QGIS 2.8 LTR (release Feb 2015) has been downloaded over 679, 000 times for the Windows Standalone installer (which includes all bug fix releases). Even after controlling for overestimates (from bot downloads, multiple downloads per user, “try and don’t use”) and underestimates (single downloads being distributed to many users) it is clear that we have an extremely large and constantly growing user base. By another metric, our most popular plugin, the OpenLayers plugin has been downloaded over 700 000 times!

Something else that is clear from the make up of the talks, workshop topics and attendees at the user conference and hackfest: QGIS is increasingly moving from single user environments to large multi-user deployments. This ‘edge of network effect’ is a common phenomenon in FOSS and is largely how Linux came to be such a lynchpin in the dev-ops world. Sys admins and (in the case of QGIS) GIS power users, test out the software on their own devices, see the potential for it in their workplace and start integrating it into their workflows in the office until eventually it has become a mission critical piece of software for an organisation.

One thing my slides probably do not make clear is that there is a huge amount of investment being made into QGIS and plugins for QGIS to fulfil a wide variety of needs. These investments are largely external to the project (i.e. not factored into the financial figures I mentioned in the talk) and happen in direct client-to-developer relationships completely bypassing (from a financial sense) the upstream  QGIS.ORG project. This is a really good model since we do not need to deal with contract delivery, competing interests etc.

If we do a simple calculation based on direct revenue for 2015/2016 (around EUR 69, 000) to downloads, the average revenue per download of QGIS 2.8.x was around EUR 0.10. All of the money we receive into the project goes into improving the QGIS, maintaining infrastructure and funding travel and accommodation for hackfests. I mention these numbers both because they are interesting and because it is good to emphasise how incredibly grateful we are to each and every one of our sponsors and donors that support the project. We really do run on a shoe-string budget and we have audacious goals and a vision to put spatial decision making tools into the hands of everyone on the planet who wants to use them. Your sponsorship and donations are a key enabler to making this vision a reality!

By the way, my apologies for not mentioning Gary Sherman (our project founder) by name at the start of my talk – that was totally unintentional! Before I talk about the main activities, let me make a quick aside to mention the small excursion we took:

Underwater autonomous vehicles & QGIS


One of the really cool things we did at the hackfest was take a little side trip to visit the Computer Vision and Robotics Institute. Natália Hurtós (who works for the institute) kindly gave a bunch of us QGIS geeks a tour. The work they are doing building [relatively] cheap underwater autonomous vehicles is really awesome and inspiring – all the more so because Natalia is planning to build the mission planning tool using QGIS libraries!

Ok so what actually happened at the hackfest? Lets dig in and find out!

Cool stuff from the QGIS Hackfest

I am only going to focus on the hackfest here because the videos from the talks at the QGIS User Conference have been posted online (see above), so you can take in all the QGIS goodness you like from those. There was a lot going on at the hackfest, so these are only the nuggets I managed to cherry-pick from the talks.

Give processing some love

Screen Shot 2016-06-12 at 22.13.15

During the hackfest and user conference, Victor Olaya (lead developer for the QGIS processing framework) really did a great job of promoting the idea of writing processing plugins rather than ‘normal’ plugins. His argument is that most plugins that are intended to provide single purpose analytical capabilities (we are looking at you geeks about to write the 300th buffer plugin!) would  be better off implemented as processing plugins:

  • the plugin author would not need to spend valuable time writing user interfaces, input validators and so on.
  • users of the plugins could chain the tool into complex workflows easily, rather than only being able to use it on a once off basis.
  • we would grow the amount of options available in the processing toolbox while at the same time reducing the sometimes overwhelming amount of choice in the QGIS Plugin Manager.

ILWIS processing tools coming soon

Also on the topic of plugins, Bas Restsios from the ILWIS Project gave a demo of the ILWIS software in order for QGIS developers to be more aware of its capabilities. Although currently Windows only, the ILWIS developers are in the process of porting the software to be based on the Qt5 framework, which means us Linux and OSX users will get to enjoy using it too soon. ILWIS is Open Source and does its rendering using OpenGL. Because of their smart rendering system, everything draws lightning fast. ILWIS packs in many remote sensing tools and raster analysis tools and should be on anyone’s radar if they are interested in FOSSGIS. The best part (from my point of view) is that Bas and his team members are also busy creating a set of processing plugins for QGIS that call out to ILWIS’s command line tools. This means you can expect a huge leap forward in the number of raster based analysis functions you can do with QGIS in the near future.

GeoPackage, JPEG2000, WFS improvements

It was really great to have Even Rouault (maintainer of GDAL/OGR) present at the hackfest. Even recently received core committer rights to the QGIS code repository and has been making great contributions by adding support for the OGC Geopackage format (death to shapefiles!). The shapefile format is long in the tooth and doesn’t serve the GIS community well as a de facto standard for GIS data interchange. It also doesn’t make a good format for intermediate  representation of data processing outputs (e.g. when using multi algorithm processing models). Even has also been working on improvements to WFS support in QGIS which many will appreciate.

Not directly related to QGIS, but Even also mentioned he has been giving the GDAL driver for JPEG2000 some love – gaining good performance increases. This gives me some hope that there will be a viable open format alternative to ECW and MrSid in the future – something which QGIS will benefit from greatly. One of the interesting things that GDAL supports with the JPEG2000 specification is embedded vectors – you can write the raster with gdal_translate and then during creation pass a shapefile or GML stream to the gdal_translate command. I look forward to the day (not currently on the roadmap) where we can ship JP2 images with embedded vector masks and use those embedded vectors  seamlessly in QGIS.

Planning for 3.0 release

We did some planning for the 3.0 release of QGIS and, in particular, fine tuned the plans for how we will manage the transition from QGIS 2.x to 3.x. In February 2016 I posted an outline of the general approach we planned to follow. Some developers felt that we would be better off having the core of the 3.0 transition work happening on the master branch of QGIS so that it has more attention and testing focussed on it. I guess there are two main interest groups to consider here, so I will break down the outcome between take-home points for developers and general users:

For developers:

  • 2.16 gets released off master.
  • After 2.16 we create a 2x branch and the 2x branch will be put into caretaker mode.
  • Support for Qt4 and Py2 will be discontinued in master and we do packaging only against Qt5 and Py3.
  • Once Qt5 and Py3 only are supported in master, nightly build packages may not be immediately available on master as we need to get the packaging systems update.
  • After 2.16 is released API breaking changes will be allowed in master (but code must build and packaging not broken, plugins will be broken).
  • All API breaking changes should be annotated by means of a Doxygen page patch to indicate what changes were made.
  • We target the API change window to end in Feb 2017 so that we can have a 3.0 release in March 2017.
  • We may do a 2.18 release off the 2x branch  if there have been substantial changes in the 2x branch. If there are no substantial changes in the 2x branch following 2.16, we will not do a 2.18 release.
  • In January 2017 we will have a review to establish if all the API breaking changes are complete. If someone has specific implementation plans that are in progress and they need more time, we will (under agreement from the dev community) extend the API breaking window and may push out the release date.
  • Following the release of 3.0 we will implement API freeze again and polish up the codebase for an LTR release based on 3.2
  • 2.14 LTR support will be extended until 3.2 is ready
  • Note: for QGIS 3.x, a minimum of Qt 5.5 is recommended
  • Note: for QGIS 3.x a minimum of Python 3.4 is recommended
  • Note: We are looking for a volunteer to set up a  windows build system using vagrant on win 7 so that we can test and build automaticallyl

For General Users

We propose that for general users, you rather share the following more easy to digest bullet list as it does not contain all the technical details above that mainly developers will care about.

  • 2.18 release is not guaranteed
  • We are planning a 3.0 release in March 2017
  • This release date may be postponed – we will do a review in January to establish whether we are on track for the release date
  • The 3.0 release will break your plugins – we will publish a migration guide and tools to help you migrate your plugin to the new platform
  • If you have any queries about the process please feel free to contact us (via the developer or user mailing lists preferably)

Style repository

Akbar Gumbira, our Google Summer of Code (GSOC) student joined us at the hackfest. For his GSOC project, Akbar is working on a unified way to share styles, symbols, ramps and markers in QGIS. The idea will be very similar to the QGIS plugin repository, where users can host their favourite cartographic elements for everyone else to enjoy. There was quite a lot of technical discussion about the exact mechanisms to use for hosting shared symbology with the key elements of the debate being about whether to use git as a hosting system, simple zip files or some other mechanism. If you wish to chat to Akbar about his work, visit this chat room or comment on the QEP.

OSX Packaging and Building

QGIS is an attractive proposition for OSX users since the big commercial vendors typically don’t support OSX. Since QGIS is built on cross platform technologies, this does not pose a huge limitation for us, but there are few OSX developers in the QGIS developer team and the platform requirements and constraints are pretty complex. Larry Shaffer has been doing awesome work to cut through the various issues and simplify the installation process – both for end users and for developers. It’s finally pretty easy to get a development environment up and running on a Mac now. Using brew (a package manager for OSX) you can install all the needed dependencies and get  QGIS compiling in Qt Creator with full debugging support. The next challenge is going to be supporting this under Qt5 for QGIS 3.0 and Larry has been doing a bunch of great work to make that happen.


There are several web client frontends for QGIS out there. Lizmap is probably the most feature rich of them. Michaël Douchin (@kimaidou on twitter) showed off the latest version of Lizmap. If you are doing any web mapping, you really should check it out!


Marco Bernasocchi showed off the work they have been doing on QField – an Android app for your mobile device. The workflow for using QField is simple: Create a QGIS project on your desktop, copy it over to your device’s SD Card or internal storage, then open the same project on your device. Since it uses the same QGIS 2.14 backend as you are probably running on your desktop, all the cartographic elements from your desktop are supported – including the new 2.5D rendering. The main use case for QField is field data collection and new in QField is the ability to capture point data and edit / update feature attributes. This opens many possibilities for asset management and field survey work.

Marco shared some roadmap plans for QField including broader support for form elements. Value maps are already implemented, value relations, date and picture support are coming soon!. There is also beta support for digitising lines which should land in your installed version soon. I am eagerly looking forward to seeing how QField develops!

During the hackfest I did some testing of QFied using a PostGIS layer in a project with the data coming from a remote QGIS server – and it works (assuming you have internet connectivity). I also did some testing using BTSync to create a synchronised file system between my mobile device and my desktop. Edits to layers on the desktop and the mobile device can easily be pushed back and forth, making it very very easy to push out maps and new data to workers in the field.


There were lots of interesting things going on for those interested in testing. Alessandro Pasotti showed off some really cool stuff he has been working on for running python tests directly in QGIS instead of using a mock QGIS iface object. There are huge benefits to doing this since your tests run in  a ‘real’ QGIS environment. He also showed off how they are testing QGIS plugins in Docker using the above mentioned technique.

If you do need / want to use an mock iface object, Matthias Kuhn has been promoting the use of the new qgis.testing python module improvements which includes an iface object which is comprehensive in terms of API stubs. For pythonistas:

from qgis.testing import start_app, unittest 

Matthias has also created a unittest subclass that you can use which includes nice goodies like letting you do asserts that geometries match.

Matthias Kuhn, Nyall Dawson and others have really been leading the charge to build a more comprehensive test suite in QGIS and there were lots of other interesting tips and tricks been shown like how to make your travis tests run against multiple versions of QGIS – which can be very handy for plugin authors.

Victor Olaya also showed off the tester plugin – for automated GUI testing based on recorded interaction sequences.

Nice things for developers

Martin Dobias showed off some of the tools they have been developing including:

  • The report plugin (see that lets you trap python exceptions and send a bug report directly to a github issue tracker.
  • Martin also showed of the First Aid plugin which lets you capture tracebacks in a more elegant way and also debug your plugin, stepping through the code and execute python instructions in the current run context. The First AID plugin makes a great alternative to using remote debugging from an IDE which is time consuming to set up and technical for less experienced developers to do.

Training plugin

Victor Olaya showed of a plugin (the Lessons plugin) they are working on to facilitate interactive training in QGIS. It uses a simple dock interface to guide the user through a series of activities. Interestingly you can ask it to play recorded macros (saved as python code) of the active being explained so that you can see how it is done if you can’t figure it out yourself. Their authoring system also allows you to record these  macros.



Docker is increasingly becoming a useful building block for those wishing to deploy QGIS in server side contexts. Patrick Valsecchi and Stéphane Brunner did some really awesome work refactoring the QGIS Server docker image – you can get a preview here (read the README for usage notes). Patrick’s work strips down the size of the docker image to make it much less of an overhead to pull the image. We would like to eventually merge this into the upstream QGIS repo so that we have a versioned docker build set up for each QGIS release.



Martin Dobias showed off the Crayfish plugin. Crayfish includes some really awesome multi temporal visualisation tools – really useful if you have time slice data in NetCDF or similar formats and you want to view layers sequentially as animations. It also has cool symbology additions to show flow / directionality arrows over your raster.


GeoNode QGIS Server Demo

Etienne Trimaille demonstrated the work he, Ismail Sunni and Rizky Maulana have been doing to implement a QGIS Server backend for GeoNode. GeoNode is a spatial content management system that allows you to easily upload and share geospatial data on the web. With their implementation you can upload a shape file or TIFF along with a QGIS .qml style file and the layer is published directly as a tile service in the original QGIS styling. Bye-bye hard do create SLD’s, hello easy to create QGIS styles. (Disclaimer: I work with Etienne, Ismail and Rizky so I am tooting our own horn a bit here).


The work of the documentation team is often overlooked in the frenzy to enjoy the new cool stuff that developers churn out. Take a look over at the documentation GitHub pulse page to see how just as much effort is going on in the documentation work. During the hackfest Yves Jacolin and the rest of the documentation team were hard at work getting things ready for the next QGIS Manual release. If you are able to lend a hand with the documentation effort (no coding skills required), please do contact Otto Dassau, the QGIS Documentation Lead!

Lightning talks

Here is also a quick-fire list of features that were shown off -that are coming down the QGIS conveyor belt – mostly for QGIS 2.16 but also new plugins and other efforts:

  • Style dock in QGIS 2.16 with undo / redo – Nathan Woodrow
  • Dynamic hillside rendering – Nathan Woodrow
  • Awesome new gradient editor – Nyall Dawson
  • D3 & Plotly charting with chart interaction showing on the layer – Matteo Ghetta and Michael Douchin
  • Forms improvements: the ‘drag and drop’ editor will support multiple columns – Matthias Kuhn
  • Table view will be able to filter which columns to show (to let you hide unwanted columns) – Matthias Kuhn
  • Action widget columns in the attribute table: you can place one or more action widgets (and icons) into the attribute table making it very easy to fire off an action (e.g. python script) for a particular record – Matthias Kuhn
  • Support for changing column order display in attribute table – Matthias Kuhn
  • In composer you can get have JSON of all layer relations that you can use in your html widget – Nyall Dawson
  • Aggregation in expressions. We will explain this more in the visual changeling for the next release, but you will be able to compute attribute aggregates (e.g. sum of areas) in your reports – Nyall Dawson
  • Default values for fields – Matthias Kuhn showed upcoming work to add support for field defaults in when adding a new record to a vector layer.
  • Transaction groups / cascaded editing mode when you are editing a feature so that related tables get put into edit mode (project property needs to be enabled) – again we will explain this more in the upcoming 2.16 changelog – Matthias Kuhn
  • SectorPlot plugin: a plugin to let you make ‘pizza plots’ of your data – Raymond Nijssen and Richard Duivenvoorde
  • Denis Rouzaud showed off work he has been doing to create a standard settings dialog that you can use in your plugins. It has support for different input types and layer chooser etc. They provide a settings dialog base class that you can derive from in your plugin which will take care of reading and writing your settings to Settings.
  • User profiles plugin – lets you create customised user interface for different user categories – Alex Bruy
  • Georeferenced PDFs and outputs from composer (sorry not yet GeoPDF) but you can use composer to create a  PDF – and then add that into QGIS just like any other raster layer. Nyall Dawson
  • Nyall Dawson chatted about his work on QGIS Task manager – a tool to let you easily create concurrent background tasks and show the progress of each task in a simple UI. I believe he is looking for funding to help him get this finished, so if you are interested please contact him.
  • Bivariate legends plugin (not published yet).  Thomas Gratier showed off work he is doing to support the creation of bivariate legends.


Albireo QGIS Fork


Sandro Mani showed off an awesome new QGIS front end they have been working on at Sourcepole. Their implementation creates a brand dew ribbon based UI paradigm for QGIS (don’t scoff, it’s actually pretty cool!). They have pared down the number of features and grouped functionality into discrete areas, both the menus and ribbon icons changing based on the context of what you are doing. You can see the source code here:  Here are some bullet notes I made while watching his presentation:

  • 3D Globe updates to get it ready for production use. They have also integrated the 3D extrusion support and lots of improvements to the globe that Matthias Kuhn did as part of his masters thesis. Its really exciting to think that these improvements may make their way into the official QGIS builds sometime soon and we can all enjoy them.
  • Redlining – you can sketch onto the map without saving those geometries in a specific layer.
  • Measuring & profile tools
  • Shift-drag for zoom – just like you can do in OpenLayers and Leaflet (Nyall then went and added this to QGIS for 2.16 – yay!)
  • Switch coordinate reference systems used for cursor position display easily from the status bar

There were many other cool features – some of them may make their way into the mainstream QGIS desktop. If you are looking to support users who need a simplified QGIS user interface, Albireo QGIS spin off is something to watch.


Girona was an absolutely awesome venue for the QGIS Conference and Hackfest. I hope the participants of the conference gained good benefit from the experience. The hackfest had around 50 participants and beyond the above notes, there was such a lot going on including work on the documentation system, discussions on the proposed community voter system (more on that in a follow up blog post) and many other things. I really encourage you to attend these events if you want to keep track of the leading edge of QGIS developers.




Licensing requirements for QGIS plugins

One thing we have been encountering lately in the QGIS project is plugin authors not understanding the licensing requirements for publishing their QGIS plugins. In this article I will try to clarify this a little:

QGIS is Open Source Software and provides a great platform for third parties to distribute additional functionality to users through our plugin system. QGIS is licensed under the GPL version 2 or greater. This license is provided with every copy of the QGIS and in the source code and is available on our web site here:

Under the terms of this license, it is a requirement that all plugins distributed via (or through other repositories that may be self-hosted) should comply with the GPL version 2 or greater license. In particular all code included in any plugin should be made clearly and easily available in source form. It has come to our attention that some plugin authors are distributing plugins that do not comply with this condition.

We ask you to consider the fact that many thousands of hours of work and large amounts of financial outlay from individuals and companies has gone into the creation of QGIS. This work is done under the basis that in-kind contributions raise the quality and capabilities of the platform for everyone. When you create a plugin, you only need to spend a minimal amount of effort to solve your specific requirements because we have done the rest of the work needed to provide an entire platform for you and our community of users. This is a key value proposition of Open Source: ‘a rising tide floats all boats’.

By publishing the source code for your plugin, others may inspect the underlying code of your plugin and learn from it and use that knowledge to further improve the platform. Not releasing your source code breaks this model. Besides being a contravention of the licensing conditions under which you received the QGIS software, withholding your source code does not advance the body shared knowledge, and does not embrace the spirit of sharing that has made the QGIS project such a success to date.

Thus if you are a plugin author who is distributing your plugin without the accompanying source code, you need to be aware that the source code needs to be made available to each person who receives the binary sources for your plugin.

One query that plugin authors have raised is whether the requirement to publish the sources of their plugin precludes their ability to sell or otherwise commercially benefit from their plugin work. This is not the case – you can sell you plugin as long as you make  the sources of your plugin available under the same license as QGIS to each purchaser.

Should you have any queries about how to better collaborate within the QGIS community we are available to you – please direct your queries to

Call for nominations for voting members of the board.

Dear QGIS Community members
As many of you will be aware, in this last year we have been embarking on the process to transition from a loose-knit community organisation to a more formal organisation. This new organisation ‘’ will be a legal entity and will afford us a greater amount of flexibility in how we manage funds, legal agreements and so forth. You can read the statutes for the organisation for more info.
Under the statutes of the new organisation, there will be one user group voting member put forward for each registered user group (user group registration page is here). For each user group voting member we will have a community voting member elected. In addition there will be one voting member from the OSGEO leadership. It is probably best explained by way of a simple (contrived) example:

1) The Martian user group puts forward Joe Alien to be their QGIS User Group Voting Member.
2) QGIS committers put forward nominations for a matching Community Voting Member from within the community. Community member with the highest number of nominations is elected. Only people with git commit rights to an official QGIS repository or write access to the QGIS translation platform on transifex can put forward nominations. The nominated person can be any person from within the QGIS community who is willing to serve as a voting QGIS community member.
3)  The Moon user group puts forward Janet Luna to be their QGIS User Group Voting Member.
4) QGIS committers again nominate a matching Community Voting Member
5) OSGEO puts forward one person to act as the OSGEO voting member.

Voting members will elect the QGIS Board, Board Chairman and approve budgets and the annual report. Once elected, the board will make day to day decisions on behalf of the project as needed. The OSGEO voting member will also serve to ensure that there are always an odd number of voting members to avoid deadlocks. Voting members will have their continued membership confirmed on a 3 yearly basis.
Since we are bootstrapping the organisation, we have not yet elected any voting members. Currently there are 10 QGIS User Groups registered (this number may be different when you read this due to new registrations), thus we would like to invite all people who have Git commit access to any official QGIS repo, or transifex write access to make their nominations for their community voting members. The 10 consenting nominees with the highest number of nominations will be appointed as community voting members.
We will close the nomination period on Wed 11 May if at least 10 unique persons have been nominated, otherwise as soon as 10 unique persons have been nominated.
We will maintain a list of the QGIS Voting Members on the web site for public viewing.
After all of the voting members have been elected they will be asked to elect the members of the board. Board members need not be voting members, any QGIS community member can be elected to the board. For formation of the new board, existing PSC members will automatically be nominated and the community voting members can also put up additional nominations. We would then put the election of the board members to a vote (maintaining the same number of members as are currently in the PSC for now). Once the board has officially been elected, the voting members can then select a chair for the board. Note that all voting will be done electronically via an online form.
By this process we will have a democratically elected board entrusted with stewardship of the new Organisation.
Each year we will hold an annual general meeting and voting members can elect a new chair, or re-elect the existing chair. Similarly on a rotational basis, board members will be up for re-election each year. If things are a little unclear above, I have made a simple diagram which hopefully clarifies things (see below).
Note that Gary Sherman (QGIS project founder) is board member emeritus and this will not be up for re-election as he has life long tenure on the board.
So if you are eligible to nominate voting members (i.e. you are a committer on any official QGIS repo or a Transifex author), please head over to the form provided to  make your nomination!
Tim Sutton
Current QGIS Project Steering Committee Chair

QGIS: Qt5 and Python3 migration, current state

Behind the scenes a lot has happened to get ready for Qt5 and Python3. On the same codebase that is becoming the next release QGIS 2.16. This is really a great thing since we can focus work on a single

  • Page 1 of 5 ( 81 posts )
  • >>
  • uncategorized

Back to Top