Page 1 of 1 (8 posts)

  • talks about »
  • qgis funding


Last update:
Sat Sep 23 22:05:14 2017

A Django site.

QGIS Planet

Plotting the future of QGIS

During the developer hackfest at our recent QGIS Conference in Nødebo, the developers present had a discussion session about the future (post 3.0) road map for QGIS. Note that the ideas laid out here do no necessarily represent a consensus between all the QGIS developers and community members since those present at the hackfest were only a subset of the great QGIS community. However the discussion probably provides a good idea of the kind of things on our minds as we move forward to QGIS 3.0 and beyond. Just a note before you get too excited reading the article below: This was a future looking session of great ideas that will take QGIS forward, but there may not be anybody actively working on these ideas (if you are looking for something to fund it would be a great start!). Here are twelve ideas that were raised (in no particular order)…

1. We need to beef up the analytical capabilities in QGIS

There was a general feeling that we should have stronger analytical capabilities in QGIS. Somewhere along the line we lost ManageR (the R integration with QGIS) and we have missed the boat in having something like Pandas / Jupyter Notebooks, embedded into QGIS (with iface available to the console). Whilst many data scientists are using R, going the python route with Pandas and Jupyter Notebooks might be a better fit in terms of being harmonious with the other work that has been done to provide python bindings for QGIS. But hey, why not provide both a Jupyter Notebook that supports both Python and R out of the box? Technically curious may want to look here for some hints on how we might go about integrating Jupyter into the QGIS application…

2. We need to improve our ‘first open’ experience

Especially for new users and novice GIS users, starting a QGIS project with a blank white canvas and many buttons and menus can be quite intimidating. We want to provide some basic projects (e.g. based on OpenStreetmap tiles) that can appear as a default layer when you open the QGIS application so that you can immediately get a sense of place and space – much like you would get in Google maps or any web mapping application. Naturally we will provide the option to disable this for those who are not interested in this functionality, but we would make it a default behaviour for new users…

3. We need a better way of communicating with our users

We do not even know simple things like how many users we have (I estimate broadly between 500 000 and 1 000 000 users based on downloads). Most users are silent users – they never communicate with the upstream project via our mailing lists or other communication mechanisms. Not knowing stuff about our users makes it hard to build a better product for them, and not having a communication channel with our users makes it hard for us to let them know about important updates, bug fixes, events etc. and it is a bit silly to be in this situation because every time a user opens QGIS, we have an opportunity to share this kind of information with them. So in the future it would be nice to have a way to provide timed and targeted messages to our users (for example letting them know when we have made a new blog post on the official QGIS blog). It would be nice to have the notification system scriptable by plugin. Of course it should be easy to opt out of or filter the messages by category (e.g. don’t show me event announcements) we share with our users. Imagine on the projects list view you see when you first open QGIS that we have a panel to the right of the projects list which just lists the headlines of the latest announcements. Perhaps there are other ways we can communicate with our users, but we should really make it a priority to get to know our users and this seems like a good start. By seeing how many times a given article gets read after it as been posted in the QGIS announcement area, we might get a better indication of how many users we have. Another example – when a new LTR bug fix comes out, we can publicise it better to make sure users are aware of the important fixes.

4. We need to focus on Quality Assurance (QA)

Especially as relates to reducing the incidence of side effects, QA is going to be critical as the project grows and gains a user base that uses it for critical functions. Side effects happen when e.g. a developer implements one feature that (probably unbeknownst to him) breaks another feature. Side effects are bad because they are hard to test for and hard to trace back to the root cause. The development of QGIS happens in a largely ad hoc manner – developers get contracts to build features their clients need, there is no top-down approach to how we roll out new features. This makes it difficult for us to ensure that side effects do not happen. We are not only concerned with side effects, but QA in general and would like to have the time and resources to spend on really taking the work that has already been put in place (automated testing on Travis for example) to the next level.

5. We need more dedicated (paid) effort to take care of the project

QGIS has become too big of a project to rely entirely on volunteers to take care of all aspects of the project. Many of us still contribute many hours of unpaid volunteer time to the project and will continue to do so. It has long been my vision that we eventually recruited a corps of professional (i.e. paid) contributors to work on QGIS, especially to take care of things that contract work will never cover. For example triaging the pull request queue (which is extremely time consuming), managing the issues in the issue tracker, expanding our test suite coverage, writing documentation, fixing bugs and building ‘cross cutting functionality that typically would not be funded by client work but that everyone will derive benefit from. Our project revenue (from sponsorships and donations) has been steadily growing (thank you to all of those that have contributed!) and if we can increase the revenue a little more we will reach the point where we can start to recruit some of our community members to work for on a professional basis – maybe on a part time basis in the beginning, but eventually building a corps of full time paid staff. This has long been a vision of mine for QGIS and if it is the one thing we achieve while I am project chair, I will be a happy chappie!

6. We need to automate trace captures

This relates somewhat to 3. above – when a user experiences a crash in QGIS, we have no automated way to get that crash information (and no Apple / Microsoft do not pass along the tracebacks to us when they offer to let you post them to their domain 🙂 ). Services like Sentry can aggregate crash data and help us understand the impact of different issues – and thus how to prioritise fixes.

7. We need to find ways to include a more diverse range of people in the project

In this particular brain storming session, we had one lady (hi Sophie!) in a room full of maybe 40 men.

We also have little representation from Africa, Asia, Latin America. A few years ago we added a diversity statement and a code of conduct to our web site, but  we need to ‘get out there’ and be more active about ensuring that people of all ages, genders, races, religions and cultures feel welcomed into our project and start actively participating as ‘makers’ not just consumers. We are a friendly and welcoming project and we should take the effort to let everyone know they are welcome in our community. Some ideas were aired about e.g. having scholarships to fund people from developing nations who would like to attend our conferences and hackfests, and scholarships to fund new developers to port plugins to QGIS 3.0 or similar more entry level tasks. It would be great to have users out there in the commercial world reach out to us to help make this happen (e.g. by offering to fund the travel and expenses of a developer who would normally not be able to attend due to costs).

8. We need to work on maintaining good relations with providers

QGIS sports a growing list of independent commercial support providers – some with very large user bases. I’ve written before here on the blog about some things providers should do to be ‘QGIS friendly’. We really want to encourage providers to use the QGIS LTR’s (Long Term Releases) as the basis for their support services, upstream their fixes to the QGIS project and avoid providing forked copies of QGIS to their clients. Why? It will improve the quality of the LTR QGIS packages and clients of every support provider will benefit. We would also really like to appeal to our commercial support providers to refer to QGIS upstream LTR builds as the ‘Official’ QGIS releases and not some lesser adjective like the ‘Community’ QGIS Release. There was the sentiment in the meeting that  calling it a community release implies that the vendor’s packaged copy is the ‘good one’ and the is the ‘not so good one’ and we would like to reverse that perception. It may seem like splitting hairs to some but we would like to see that there is not fragmentation in the user base of QGIS so we think that it is important to set the right tone from the get-go.

9. We need to promote that QGIS is now a legal entity

It has taken a lot of work, planning and hoop jumping, but is now a legal entity – a Swiss Association / Verein. We are VAT registered, have our own bank account and can now hold our own trademarks and IP instead of working through a proxy. We hope this will open a new chapter in the future growth of QGIS – in particular in our ability to attract much more substantial funding and to make formal agreements with entities where needed. A huge thank you to Andreas Neumann (QGIS PSC Member and project treasurer) for making the whole process happen!

10. We should establish credibility by code signing our products

There was some discussion about the fact that QGIS installers don’t always get recognised by operating systems as a ‘good’ application – virus checkers might flag it or system preferences my reject applications that are not code signed. The good news is that since the meeting Jürgen Fischer has added code signing for the Windows binaries (if that makes you happy please buy him a beer or something :-)) and there is work in progress by Larry Shaffer (who might also be motivated by beer :-)) to have code signed MacOS installers. Of course Linux users are probably scoffing here since they have a nice package distribution mechanism in place and they are already signed.

11. We need a smoother path to integration of code contributions

There was an extended discussion in our meeting about how we should manage contributions to QGIS as we move forward. Some were in favour of forcing everyone to use Pull Requests (PR’s) with a peer review. Others were in favour of also being able to push directly to the code base. Various other permutations were discussed. For now we are going to continue on with our current approach more or less which is to not prevent direct pushes to the code tree, but to discourage it – and of course non-core users will be required to use PR’s since they don’t have direct push rights to the official repo. Suffice to say we are aware of the fact that we have a large backlog of PR’s that are not merged and that it can sometimes be difficult to get your work merged. Hopefully in the future the ideas outlined in point 5. above will help to alleviate this situation….

12. Intergalactic domination

This was a late addition to our meeting notes, but still a worthwhile cause. Martin Dobias  felt strongly that we should include in our roadmap (thus not pictured below), plans for intergalactic domination and hey, if we are going to do something like that, we will need a good GIS to help us find our way around right? 🙂

Thanks to Nyall Dawson for prompting the discussion, it was great to once again experience how convivial and constructive our community discussions are, even when the topics can sometimes get difficult or technically involved!

Screen Shot 2017-08-25 at 12.20.05 PM


Report back on the 3rd QGIS Conference in Nødebo, Denmark

We just wrapped up the 3rd QGIS User Conference at the University of Copenhagen’s “Skovskolen” Forestry and Landscape College, just outside of Copenhagen. The conference programme was split into three parts:

  1. A general user conference of three days
  2. The a QGIS hackfest – where many developers brought their families along
  3. A week of workshops where attendees can learn in-depth topics such as expressions or the new QGIS Web Client version 2

We are extremely grateful to the event sponsors (you can find links to our sponsors at the bottom of this page):

Click to view slideshow.


Here are some of the highlights from the conference presentations:

Search – a cool unifiedsearch tool for QGIS

Klavs Pihlkjaer (from Septima) showed off the QGIS (version 2) search plugin. The plugin provides a unified search interface for datasets loaded in QGIS. You can also search external OGC services. If you are still using QGIS 2.x releases, run, don’t walk to try the search plugin. The Search Plugin also allows you to create third party plugins (via a simple python API) that integrate with it by adding new search sources to the list. If you are using QGIS 3, check out the ability to write plugins for the new locator bar! Klavs is still looking at porting his work over to work with the upcoming QGIS 3 release.

Impact Analysis plugin

Bo Victor Thomsen showed off the plugin he has built to support searching through many layers in multiple databases and database tables in a fast an efficient way. The layers do not need to be loaded in QGIS and the system uses a centralized configuration management approach so that adding new searchable sources is done once and is then immediately available for all users (e.g. in an enterprise environment) of the plugin. The plugin is currently used when searching municipal databases to see if there is any impact assessment needed or inspection needed in a given place.

Danish National Data Search

Mie Winstrup and Tom Weber showed off the national data search plugins they have developed for Denmark that allow you to easily search for local and national data. They want to be an example for other countries to show how easy it is to make national data searchable and available.

Casper Bertelsen on registering urban green areas

Casper showed the system he has developed for managing a cadaster of green spaces. The system includes versioning so that you can see changes over time. It also implements topology rules to ensure that areas do not overlap. He also provides tools for administrations to e.g. see what the maintenance cost for a given area will be.

QGIS as a digitizing platfom

Saber Razmjooei from Lutra Consulting showed off QGIS as a digitizing platform. He also showed us new digitizing coming in QGIS 3. He showed off some of the great tools coming in QGIS 3 for node editing.

QGIS Web Client – Version 2

Andreas Neumann showed of the new generation of QGIS Web Client (QWC2). The new web client is really nice – responsive design and takes advantage of open layers 3 including rotating maps, permalink for any map view / set of layers, map tools for measure, draw, export etc.

Future plans include improved redlining tools including text, polygons, user authentication via LDAP or oauth, support QGIS ‘drag and drop’ forms, clip and ship and a QGIS plugin for the configuration so you do not need to edit JSON files. Also thinking about supporting vector tiles for the base maps.

I bet you didn’t know you could do this with QGIS

Nyall Dawson gave an awesome demo of the power and capabilities of QGIS’ labelling, symbology and expression features. His demo took us through an adventure story where each scene in the story was rendered using QGIS (based on the upcoming version 3 release). This included animated clouds floating by, lightning effects, electrical effects, smoke effects and many more cool and interesting ideas that really showed off the power and versatility of QGIS.

Screen Shot 2017-08-09 at 10.42.51 AM


Martin Dobias (Lutra Consulting) gave a presentation on the QGIS grant proposal  work he has been doing to support 3D visualizations natively in QGIS 3.  His work leverages the new Qt 3D framework provided in Qt5 (the toolkit used to develop QGIS) and allows you to use an elevation model to model a 3D terrain and use a new tab in the vector style properties dock to extrude features out from the landscape. We have had a number of 3D  tools in QGIS in the paste but none has ever been a mainstream component of QGIS, enabled and ready to use ‘out of the box’. Expect Martin’s work to change that. There were many ideas passed around about how the 3D support in QGIS could be extended but the grant proposal only supports the first-pass implementation, so please do fund Martin’s work if you would like to see him add specific features in the future.


QIGS as a cadastral management platform

Prof. Erik Stubkjaer gave two presentations – one as a call for interest in those interested in building land parcel / cadastral management tools. He also gave an overview of the state of domain models for managing and recording property rights, including LADM (Land Administration Domain Model) and STDM (Standard Tenure Domain Model). He outlined that world aid organizations are increasingly putting an emphasis on enabling better tax revenue as a path to economic and social stability, and having a cadaster is a key element to the enablement. There are already a number of cadastral management tools out there for QGIS – it would be great to heed Prof. Stubkjaer’s clarion call and build a generic toolset for cadastral management in QGIS.

The future of coordinate reference system support in QGIS

Kristian Evers from the Danish Agency for Data Supply and Efficiency spoke about the use of Coordinate Reference Systems in QGIS and the use of WGS84. He pointed out the fact that there are 6 different versions of WGS84 and they vary by up to a meter. He also highlighted the issue that e.g. ETRS89 drifts more out of sync each year. In addition the earth is dynamic with plates shifting and different regions moving with different velocities. He showed a really nice video made in Australia highlighting the issue (see here: for details and the video). They use a plate fixed datum (which moves with the plates) together with a global datum (fixed to the center of the earth). This new approach is being planned / used in other places too (e.g. Iceland) and are called “dynamic datums”.  The dynamic datums will rely on a time stamp too as well as coordinates.

To address this they are introducing the concept of transformation pipelines in Proj.4 (the library used by QGIS to support projection) – there will be a new release of Project.4 which includes support for this.


Tim Sutton (your humble blog post author) gave a presentation about InaSAFE – a plugin for QGIS that helps communities prepare for disasters.

Jonas van Schrojenstein Lantern (from Nelen & Schuurmans)

Jonas’ company built really fast and efficient models for flood models including 3D visualization. They have a really nice plugin for QGIS that lets you view a pipe model and different behaviors based on changed water levels. It requires a specific data model (d3i) in the Postgres backend and then you can visualize water levels in any pipe section. The plugin also lets you do the digitizing of the pipe network etc. The software also requires the use of som 3di services that Jonas will clarify how the licensing etc. should work.

Mie Winstrup – Septima – sometimes Open Source is just plain better

Mie shared a case study about how they used Open Source to replace a tool built with ArcMap + Model Builder for flood modeling. They used malstroem  – a python command line module and also integrated with QGIS. It assumes the terrain is an impermeable surface and that water flows from one cell to another. The tool models where water will accumulate in the landscape and what the depths are at each ‘blue spot’. It also models how much water will flow from the blue spots (based on modeled precipitation amount e.g. 100mm rain). It generates an event layer which shows how many cubic meters of water will spill over to the neighboring watershed.

Saber Razmjooei – Lutra consulting – Crayfish plugin

Crayfish C++ plugin for QGIS adds a new renderer for gridded data. Works with HDF, NetCDF and GRIB.

What to watch out for in QGIS 3.

Nyall Dawson (core QGIS developer) gave a talk on what to expect in QGIS 3. The talk was not a feature round up but rather aimed at those concerned about the potential gotchas they will have to take care of when they migrate from QGIS 2 to QGIS 3 in their production environments. I record


Monica Balestrin Nunes & Ana Paula Maciel (National Secretariat for Housing in the Ministry of Cities, Brazil)

Monica and Ann Paula presented a talk on how the Ministry of Cities in Brazil are using QGIS and mapping to manage the roll out of housing projects to support  provision of housing for the poor “My House, My Life”. The project aims to help 4.5 million people get into housing.  They used QGIS to develop a site selection process too. They used a simple process to map urban areas, developed versus undeveloped urban areas, schools. They also used public transport as a parameters to further constrain the available areas. These data were used to produce a synthesis map which shows high, medium and low suitability of areas for housing development. They used a digital coding system to classify each area (which can be mapped back to the high, medium and low assessment ratings). They also used GeoServer, GeoKettle, PostgreSQL/PostGIS.

Sophie Commelinck – University of Twente

Automated cadastral mapping using UAVs. Sophie showed workflows she is building for automatic extraction of parcel boundaries from UAV imagery. She showed some interesting work in doing boundary line detection using the SLIC algorithm which creates smoothed lines along boundaries. See for more details.


Kimberley Briscoe, Abingdon School, UK

Kimberley has been doing interesting things with high school kids learning GIS via QGIS. This work included using the time manager plugin to visualize global earthquakes and using r.lake.coordinates to do flood modeling. They also use ‘field trip gb’ mobile app to do field data collection. Many other plugins were used like EVIS, QGIS2Threejs. They also use interesting national datasets like crime etc. and data from for their classroom work.


Badri Basnet – The University of Southern Queensland

Badri is a lecturer and has 90% online students in many different locations worldwide and with varying levels of internet access.  Badri has made many open content QGIS training videos and worksheets that he uses for his courses (which are based on QGIS). His videos are all on YouTube.


QField – Matthias Kuhn and Marco Bernasocchi (

Matthias and Marco gave presentations on QField – an Android field data collection app based on QGIS (but with a mobile centric user interface). Matthias showed us many of the cool features QField has, whilst Marco outlined strategies for integrating field work, web publishing and desktop GIS work in a seamless workflow. I made some videos with my phone – audio and video quality is not brilliant but should be enough to follow along for those interested:

Lene Fischer (Skovskolen)

Lene (who also happens to be the event organizer – hurrah for the great job she did along with her team of volunteers!) showed how they approach teaching GIS and QGIS using ‘flipped learning’ where users first need to self study content on their own, and then use the lecturer as a consultant.


Tim Sutton – Cadasta

Your trusty author again – I presented work we have been doing to support mapping land rights of people in developing nations using the Standard Tenure Domain Model style approach where tenure is treated as a continuum rather than an absolute. You can find out more about this project at



The event was also filled with great workshops – two during the main conference, and then a week of post conference workshops. Most of the workshops were presented by developers or QGIS project members and represented a fantastic opportunity for attendees to learn straight from the experts!

Town hall meeting

At the end of the user conference, we held a town hall meeting where developers and active QGIS community members fielded a range of questions from the audience. It is always a please to hold these sessions – we get a direct channel of communication with our users and they get to speak directly to the people making the software they use and find out why we make the choices we make!



The “hackfest” (developer meeting – we use ‘hack’ in the positive sense of the word) was a chance for the QGIS community members to roll up their sleeves and work on new features, bug fixes, documentation and general polish of QGIS and related resources. It is always great to be able to work side by side for a few days – compared to our very geographically dispersed nature over the rest of the year. It was especially nice this event that many developers brought their families along to enjoy the beautiful scenery and great facilities at the Skovskolen. Here is a group photo taken by Mary Anne Lister:



On behalf of the whole QGIS community, I would like to extend our heartfelt thanks to Lene Fischer (event organizer), her team of volunteers, all the attendees who took the time to attend the conference – and of course all the developers and QGIS Community Members who attended and made it such a great event!


Event sponsor links:



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!

A report on QGIS Income 2016

Greetings wonderful QGIS Users, Developers and Supporters! 2016 was quite an  exciting year for QGIS – we released QGIS 2.14LTR which has been a great stable release. We also set the wheels in motion for QGIS 3.0 which we plan to release later this year. QGIS development takes a lot of time and effort – and much of the work is done by volunteers – especially the core project maintenance work which typically does not attract paid-for consulting work like new feature work does.

We are extremely lucky and grateful to have a growing band of sponsors that are helping us to slowly but surely fund more core QGIS project work too. In this post we want to say ‘thank you’ to the many sponsors that have stepped up to the plate when we asked for help and sponsored QGIS. We also want to provide some insight as to what level of funding we receive and hopefully stimulate some friendly enthusiasm to stepping up funding efforts from our users around the world.

Our project treasurer, Andreas Neumann, has been so kind as to compile a very detailed report about the sponsorships and donations received over 2016 which we would like to share with you. Before I share his actual report, let me just clarify that we have two distinct ways of contributing money to the project:

  • Donations: You simply nominate an amount you wish to contribute and pay it to the project. Donations are intended as a way for individual users to show their support for QGIS (although we welcome large donations too).
  • Sponsorships: Sponsorships are aimed at organizations. We have fixed tiers of contribution (see below) and each tier includes some benefits in terms of marketing exposure for your company or organisation.

QGIS sponsorship can be made at one of four levels:

2017-01-30 01_22_27-Projecta_ Sponsorship Levels -.png

Higher tier (silver and up) sponsors are included in the footer of our main web site, e.g.:

Screen Shot 2017-02-25 at 8.50.22 AM.png

If you want to see your company listed there, why not head over to the QGIS Sponsorship page to find out how to become a sponsor?

Some interesting highlights from Andreas’ report:

Screen Shot 2017-02-25 at 9.00.07 AM.png

We had  1128 donations in 2016 amounting to a total of  €25108. We had  47 Sponsors in 2016 which raised a total income of  €67921. December is the month that attracts the highest income from donations and sponsors (though that may coincide with additional marketing we did calling for sponsors).  Looking at contributions by country, Denmark was the highest national contributor in 2016, providing a total of  €17795 to the QGIS.ORG project. If you normalize by population,  Iceland provided the largest per capita contribution to QGIS, providing  €9056 per million people.  Iceland also had the highest contribution rate when measured against GDP with  ~€154 per billion GDP.

Screen Shot 2017-02-25 at 9.04.34 AM.png

You can read Andreas’ full report in this PDF – a huge thank you to Andreas for preparing this fascinating report, and of course to everyone out there who shared their hard earned money with us – your funding has become a vital enabler for moving the project forward.



Tim Sutton
(QGIS Project Chair)

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!

Update on the QGIS Grant Programme

At the beginning of August this year, we put out a call for applications in our newly launched 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 – 233KB download). There has also been some good discussion on the QGIS Developer mailing list about the evaluation process.

Given that we have 18 proposals and only 20,000 Euros to disburse, the QGIS voting members will need to make some tough, pragmatic choices. Its also noteworthy that this is the first time since establishing our community of QGIS Voting Members that we have asked them to vote on an issue. Our intent with the voting member system is to have a streamlined process for deciding on important issues whilst ensuring good representation of all members of the community. In case you are wondering who the QGIS Voting members are, I have prepared this little infographic below which lists the members and shows how they are elected  etc.

qgisoperationalstructure-votingmembersonlyThe voting for the grant proposals ends at the end of the September 2016, and we plan to announce the successful candidates soon after that – probably on the 4th of October. 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.

This round of grant proposals is special not only because it is the first time we are doing this, but also because the grant programme precedes the upcoming release of QGIS 3.0. Providing grants to facilitate this work will help to assure that QGIS 3.0 gets all the love and attention it needs in order to make it a success. That said, there is a huge amount of work to do, and it is mostly being done by a handful of very dedicated and generous (with their time) individuals. 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!

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


  • Page 1 of 1 ( 8 posts )
  • qgis funding

Back to Top