Page 1 of 1 (3 posts)

  • talks about »
  • qgis grant programme


Last update:
Tue Mar 28 06:50:12 2017

A Django site.

QGIS Planet

QGIS Grants #2: Call for Grant Proposals 2017

Dear QGIS Community

Last year we held our first ever call for Grant Proposals and it was a great success. If you are an early adopter using QGIS 3.0 preview builds, you can already try out some of the new capabilities that have arrived in QGIS thanks to these grants.

We are very pleased to announce the second round of Grants is now available to QGIS Contributors. The deadline for this round is Sunday, 19 March 2017. All the details for the Grant are described in the application form, and for more context we encourage you to also read these articles:

We look forward to seeing all your great ideas about how to improve QGIS!

Tim Sutton

QGIS Project Chair

Winning QGIS Grant Proposals for 2016

We are extremely pleased to announce the winning proposals for our 2016 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 18 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 those proposals that received one or more votes, along with brief notes on the methodology used:


A couple of extra notes about the voting process:

  • 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.
  • Although the budget for the grant programme was €20,000.00, the total amount for the three winning proposals is €20,500.00 – an additional €500.00 was made available by the PSC towards the grant programme to accommodate this.
  • Voting was ‘blind’ (voters could not see the existing votes that had been placed).

As mentioned in our previous blog post about this selection process, this is the first time that we have asked our newly formed group of QGIS Voting Members to vote. It is extremely gratifying to see such enthusiastic participation in the voting process. Of the 27 voting members, 24 registered their votes. There was one late submission that unfortunately had to be excluded, and 2 non-votes.

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

Implement a flexible properties framework in QGIS (Nyall Dawson) – €10,000


Details: I am applying for a QGIS grant to cover the implementation of a flexible “properties framework” for QGIS. I honestly believe that implementation of this framework will unlock cartographic power in QGIS well beyond anything that is currently possible in any of the desktop or web based mapping applications.

I propose to implement a system of managing and evaluating properties for generic objects within QGIS. Properties include all settings relating to symbology, such as a line marker’s width, color, or offset, label settings (eg font size, color, shadow opacity, etc), diagram properties (colors, size, etc) and composer item settings (position, rotation, frame size and color, etc). While currently many of the properties can be set to use “data defined overrides”, the properties framework will extend these capabilities by making them both more flexible and easier to use.

This proposal is being driven by a number of factors:

1. To avoid the current multiple duplicate code paths involving storage, retrieval and evaluation of data defined properties and to make it easier to add data defined support to more things (eg diagrams) without incurring even more duplicate code. Currently labeling, symbology and composer all have their own methods for handling data defined properties, which makes maintenance of data defined code very difficult.

2. To allow creation of other property types besides the current “data defined” (ie bound to field value or expression result) property, eg time based properties for a future in-built animation framework.

3. To avoid the complexity of requiring users to write their own expressions to map values to colors, sizes, etc and apply scaling functions to these, and instead expose these to users in an interactive, flexible way. Think Mapbox studio’s approach to zoom level styling (, but available for all property types. Eg data defined values can be set to preset ease in/ease out curves, or manually edited curves through an interactive GUI.

4. Enable the possibility of having live project wide colors. Ie a color palette could be created in the project properties, and color based properties “bound” to these colors. Altering the color would then automatically update every property which was bound to this preset color. This also brings the possibility of “color themes” for maps, eg binding properties to a predefined color types such as “highlights”, “background features”, etc, and then interactively changing all these color bound properties by applying a color theme to the project.

5. To allow a system of inherited and overridden properties. Eg QGIS default label font overridden by a project default font and finally overridden by label font setting. The proposed composer rewrite (layouts work) would use this property inheritance to bind layout item properties to a dynamic template. Changes in the template would be reflected in all linked layouts, but individual items could overwrite the inherited properties as required. Layout item properties could then be set globally (eg, font size), per project (eg font family), via a “master template” and finally individually per layout item.

6. The labelling engine has a need for predefined label styles. Label properties could be set globally, per project, via a predefined style, or overridden for a particular layer.

Technical details regarding this proposal are available in QEP 22 (

I am seeking funding to:

1. Implement the core functionality for the properties framework
2. Port symbology, labeling and diagrams to the framework, and enable data definable control of all appropriate diagram settings (currently diagrams have a very limited data defined control available)
3. Implement the GUI for the property framework, including:
– a widget for controlling property behaviour
– interactive widgets for size and color properties (which have been designed to work inside 2.16’s live layer styling dock)
– interactive widgets for setting the “easing” for properties, with choices of preset ease in/out methods + an interactive curve editor for manual control

If funds are remaining following these items, I will undertake (in order of priority):

4. Bound project colors
5. Begin work on labeling styles

History: Because I believe so firmly that this framework is required within QGIS, I have been building toward this work through numerous hours of development over the previous 2 years of QGIS releases. There were a number of prerequisite changes required first, such as the implementation of expression contexts. An initial PR ( for the properties framework was filed in May 2016, which includes some of the core parts of this proposal. Changes were required based on feedback from that PR , however to date all work on this has been on a volunteer, unsponsored basis and unfortunately I am no longer able to complete such large scale changes as are required by this proposal without funding. Aside from the changes required from the initial PR, significant work remains in implementing GUI, unit tests, and porting symbology and labeling to the new framework.

Qualifications: I have an extensive history of large-scale contributions to QGIS since 2013 and a proven track record for writing polished UI with extensive unit testing. I’m passionate about QGIS, being a daily GIS user and strongly believe that this framework is required to take QGIS to the next level of cartographic abilities.

Implementation Plan: Due to the extensive refactoring and API changes which are required for implementing the properties framework, this work MUST be done in the QGIS 3.0 timeline. If it is not completed during the 3.0 API break period, the amount of work and cost required would substantially increase, and numerous methods across the symbology, labeling and diagrams API would be deprecated. Accordingly this work will be conducted during the QGIS 3.0 timeline, and for greatest testing I would aim to complete the work ASAP (likely complete by late October). Due to the changes required this work would NOT be suitable to backporting to the >= 2.18 branch and will be targeted at QGIS 3.0 only.

Proposal Link:  A QEP detailing technical implemention is available at:, and an initial PR available at


Introduce everything necessary for QGIS3 to OSGeo4W (Jürgen Fischer)- €6,000


Details: For QGIS3 we need packages of Qt5, PyQt5 and Python 3 (including many extensions currently available for Python 2).   The goal of this proposal is to introduce all required dependencies to OSGeo4W (32&64bit) that are necessary to build and package QGIS3. The requested amount will cover 60h of work on this.

History: I also did the packaging of Qt4, PyQt4 and QGIS.  I’ve also already started to build and package Qt 5.7 using Visual C++ 2015.

Qualifications: See previous point (or well known history)

Implementation Plan: I plan on doing it this in Q4 this year to have it available for the release and I don’t expect significant extra effort to support Windows (ie. if the issues are solved on a platform that already has Qt5 and friends available it should also work on Windows).

Implement an inbuilt Task Manager in QGIS for background long running tasks (Nyall Dawson) – €4,500

Details: QGIS requires a centralised, in built task manager to handle background threading of long running analysis tasks. Currently these long running tasks are either conducted while blocking the UI (such as when a snapping index is built for a layer) leading users to conclude that QGIS has frozen, via blocking progress dialogs which prevent interaction with QGIS while the operation proceeds, or via custom threaded implementations. By building a standard framework for handling these long running tasks, we will benefit by:

1. Avoiding UI blocking tasks, allowing users to continue working while the task is completed.
2. Simplify background task threading for plugin, processing algorithm (and core) developers by exposing a simple API for creating and scheduling long running tasks.
3. Benefit from the stabler code which comes as a result of having a single, well tested implementation of background threading rather than multiple custom implementations of this code.
4. We “catch up” to our commercial competitors (ie ArcGIS and MapInfo Professional), who currently have inbuilt background threading of long running tasks already available in their software.

This work was begun in, however significant changes are still required before the task manager can be merged into QGIS. It is vital that the task manager implementation is rock solid and with a future proof API which addresses our needs for the 3.x release cycle.

Accordingly, this grant proposal covers:

1. Building off the work started in the pull request, first addressing the feedback received from GitHub and from direct conversations with interested stakeholders and stabilising the API.
2. Completion of the unit tests to cover all parts of the framework.
3. Polish the GUI for interacting with running and completed tasks.
4. Writing documentation for the Python cookbook demonstrating how the task manager should be used from Python code.

(Please note that this proposal does not cover porting any existing code (such as processing) across to the new framework.)

History: An initial prototype of the work was begun in  

Qualifications: I have an extensive history of complex changes to QGIS code, and am currently one of the most active QGIS core developers. I have a track record of implementing stable, heavily unit tested code and supporting code I write for extended periods. I am also a daily user of QGIS as a GIS software application, so am invested in making the software as powerful, stable and easy to use as possible!

Implementation Plan: This work would be completed ASAP to allow for lengthy testing prior to the QGIS 3.0 release, and to allow the maximum time possible for developers to adapt their code and plugins to the new task manager interface.

Proposal Link: An initial prototype of the work was begun in, and a video demonstration is available at   


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!

  • Page 1 of 1 ( 3 posts )
  • qgis grant programme

Back to Top