Thanks to generous supporters, we are in the wonderful position to be able to announce that another project is successfully funded:

• QEP#248 Authentication System: allow Database storage for authentication DB

Our thanks go out to:

• Gis3W
• QTIBIA Engineering and QCooperative
• QGIS User Group Germany (QGIS Anwendergruppe Deutschland e.V.)
• Hytech-imaging spectral imaging for environmental mapping and monitoring in civil and defence applications

for providing the additional funding to top up the QGIS Grant Programme contribution for QEP#248.

The next proposals on the wait list are:

• QEP#294 Fix access to remote data sources in WebAssembly builds
• QEP#265 Use pre-commit to automate installation and management of all pre-commit hooks
• QEP#295 Embedded end-user feedback

If you want to help make these improvement a reality, please get in touch.

With the QGIS Grant Programme 2023, we were able to support four proposals in the first round and an additional two proposals through the second round that are aimed to improve the QGIS project, including software, infrastructure, and documentation. The following reports summarize the work performed in the proposals. 

1. QGIS Bug Tracker cleanup #266 – Report
   While checking existing bugreports we have identified and closed ~291 tickets, among them:
   
   – 162 bugreports and feature requests which were already fixed or implemented
   – 29 bugreports and feature requests which are invalid (data issues, wrong use of functionality, etc)
   – 57 duplicate bugreports and feature requests
   – 5 won’t fix bugreports
   – 5 bugreports were converted to feature requests
   – 33 tickets were closed (does not contain steps to reproduce, test data and no feedback was provided within several month)
   
   Additionally we ensured that all tickets has correct tags assigned to to make them easier to find.
   
   
2. Porting to C++ and harmonization of Processing algorithms #271 – Report
   The work has been completed with several pull requests:
   – Port various geometry algorithms to C++ 
   – Port Align Rasters tool to Processing 
   – Port Raster Calculator algorithm to C++ 
   – Port XYZ Tiles algorithms to C++ 
   
   Existing Processing algorithms Voronoi Polygons and Delaunay Triangulation have been ported to C++ and now use GEOS instead of the unmaintained Python module. Both algorithms have been given additional parameters to disable post-processing step (adding attributes of input points for Voronoi polygons and adding feature IDs of the 3 points forming a triangle for Delaunay triangulation) and thus improve algorithm performance. The Concave Hull algorithm has been ported to C++ and uses GEOS for QGIS builds with GEOS >= 3.11, while a port of the existing implementation based on Delaunay triangulation is used for builds with older GEOS versions.
   
   Two algorithms for generating XYZ tiles (directory and MBTiles variants) have been ported to C++ using a safer and cleaner multi-threading approach.
   
   The Align Rasters tool (available from the Raster → Align Rasters menu), which was not exposed to Processing, has been removed and a new Processing algorithm with the same functionality has been added. To make this possible, we have added a new QgsProcessingParameterAlignRasterLayers parameter type to Processing, which provides an adapter to QList<QgsAlignRaster::Item>. The “Raster” menu item now opens the Processing algorithm. We have also added a separate, simplified modeler-only version of the algorithm that accepts a single raster to align and returns a single raster layer output.
   
   The existing Raster Calculator algorithm has been ported to C++. The algorithm now has two variants: a toolbox version that works the same way as before, and a modeler version that uses the same approach to input naming as the GDAL raster calculator (in the formula, you should use letters instead of layer names). The old algorithm implementation has been retained for compatibility with existing models and will be removed in QGIS 4. We have also added a separate raster calculator algorithm for creating virtual raster layers.
3. Improve test result handling on QGIS CI #268 – Report
   While the original proposal was explicitly stated to be a research project with no guarantees of success, the end result is predominantly a success (with some limitations!). You can see the new failure handling in action in this PR. 
   
   What we have now is that any tests which fail a rendering comparison will write a descriptive comment to the PR, as shown in the above link. The comment details which render tests failed, where they are in the code, and includes some helpful pointers to downloading the full test report and the QGIS developer documentation.
   
   Originally, I hoped to link directly to the full test report or include it as an attachment to the comment. Unfortunately this is NOT possible given the current Github API. There’s a bunch of notes I’ve added to the initial comment which link to the limitations / feature requests on Github’s side, so we can monitor the situation and further improve the reports if/when Github add this functionality.
   
   As well as the above described improvements on the CI side, I’ve also implemented lots of improvements in running the tests locally and how the render test reports are generated and presented to developers!
   
   
4. Unification of all geometric and topological verification methods #236 – Report
   Our efforts are primarily focused on two main aspects of the proposal:
   1. Unification of Algorithms:
   This component entails both refactoring existing algorithms and introducing new ones. While the refactoring phase did not reach the level of ambition initially envisioned, considerable cleanup has been achieved, particularly in eliminating code duplications, as evidenced by the PR submitted [1] [2] [3]. Other deduplications could be considered, but the main issue is not to break the small optimizations or adaptations to the logic of the existing code.
   
   2. Integration of Geometry Checker Algorithms:
   Following the discussions within the QEP framework, we have decided to transition algorithms to those already present in the geometry checker. These algorithms encompass topological considerations. Unfortunately, due to timing constraints with the year-end and the feature freeze period, this integration was not yet completed. [4] [5] 
    
   Processing Integration:
   Efforts have been made to incorporate the geometry checker’s algorithms into the processing framework [6] [7] [8]. Regrettably, these efforts have not yet been fully realized. We encountered challenges in aligning processing with the logic of the geometry checker. However, the ongoing PR by Jacky shows promising progress in overcoming these obstacles. We are optimistic about achieving the integration of geometry (and topology) checker algorithms into processing for the upcoming version. This integration aims to streamline ETL processes for verification and correction tasks, thereby enhancing codebase cleanliness.
   
   
5. The remaining project reports will be added as the projects wrap up.

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sustaining members and donors who make this initiative possible!

We are extremely pleased to announce the 5 winning proposals for our 2024 QGIS.ORG grant programme:

• QEP#289 Authentication system revision (v1.1)
• QEP#291 Mitigate Abusive Tile Fetching on OpenStreetMap (OSM)
• QEP#287 PyQGIS linter warnings
• QEP#290 Clean up point cloud index and improve its thread safety
• QEP#292 Implementing CI Qt6 Windows Builds through vcpkg

Funding for the programme was sourced by you, our project donors and sponsors! Note: For more context surrounding our grant programme, please see: QGIS Grants #9: Call for Grant Proposals 2024.

The QGIS.ORG Grant Programme aims to support work from our community that would typically not be funded by client/contractor agreements. This means that we did not accept proposals for the development of new features. Instead proposals focus on infrastructure improvements and polishing of existing features.

Voting to select the successful projects was carried out by our QGIS Voting Members. Each voting member was allowed to select up to 6 proposals. The full list of votes are available here (on the first sheet). The following sheets contain the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:

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.
• Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We received 39 votes from 21 community representatives, 17 user group representatives, and the OSGeo voting member.

On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!

Dear QGIS Community,

We are very pleased to announce that this year’s round of grants is now available. The call is open to anybody who wants to make a contribution to QGIS funded by our grant fund, subject to the call conditions outlined in the application form.

The deadline for this round is in four weeks, on 14 March 2024.

There are no new procedures in 2024. Please note the following guidelines established in previous years: 

• The proposal must be submitted as a ‘QEP’ (QGIS Enhancement Proposal) issue in the repo: https://github.com/qgis/QGIS-Enhancement-Proposals (tagged as Grant-2024). Following this approach will allow people to ask questions and provide public feedback on individual proposals.
• Proposals must clearly define the expected final result so that we can properly assess if the goal of the proposal has been reached.
• The project budgets should account for PR reviewing expenses to ensure timely handling of the project-related PRs and avoid delays caused by relying on reviewer volunteer time. 
• In the week after the QEP discussion period, the proposal authors are expected to write a short summary of the discussion that is suitable for use as a basis on which voting members make their decisions. 

The PSC of QGIS.ORG will examine the proposals and has veto power in case a proposal does not follow guidelines or is not in line with project priorities.

For more details, please read the introduction provided in the application form.

We look forward to seeing all your great ideas for improving QGIS!

We are extremely pleased to announce the 4 winning proposals for our 2023 QGIS.ORG grant programme:

• QEP#266 QGIS Bug Tracker cleanup
• QEP#271 Porting to C++ and harmonization of Processing algorithms
• QEP#267 Add vertical CRS handling to QGIS
• QEP#268 Improve test result handling on QGIS CI

Funding for the programme was sourced by you, our project donors and sponsors! Note: For more context surrounding our grant programme, please see: QGIS Grants #8: Call for Grant Proposals 2023.

The QGIS.ORG Grant Programme aims to support work from our community that would typically not be funded by client/contractor agreements. This means that we did not accept proposals for the development of new features. Instead proposals focus on infrastructure improvements and polishing of existing features.

Voting to select the successful projects was carried out by our QGIS Voting Members. Each voting member was allowed to select up to 6 proposals. The full list of votes are available here (on the first sheet). The following sheets contain the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:

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.
• Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We received 35 votes from 20 community representatives and 15 user group representatives.

On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!

Dear QGIS Community,

We are very pleased to announce that this year’s round of grants is now available. The call is open to anybody who wants to make a contribution to QGIS funded by our grant fund, subject to the call conditions outlined in the application form.

The deadline for this round is in four weeks, on 2nd May 2023.

There are no new procedures in 2023. Please note the following guidelines established in previous years: 

• The proposal must be submitted as a ‘QEP’ (QGIS Enhancement Proposal) issue in the repo: https://github.com/qgis/QGIS-Enhancement-Proposals (tagged as Grant-YEAR). Following this approach will allow people to ask questions and provide public feedback on individual proposals.
• Proposals must clearly define the expected final result so that we can properly assess if the goal of the proposal has been reached.
• The project budgets should account for PR reviewing expenses to ensure timely handling of the project-related PRs and avoid delays caused by relying on reviewer volunteer time. 
• In the week after the QEP discussion period, the proposal authors are expected to write a short summary of the discussion that is suitable for use as a basis on which voting members make their decisions. 

The PSC of QGIS.ORG will examine the proposals and has veto power in case a proposal does not follow guidelines or is not in line with project priorities.

For more details, please read the introduction provided in the application form.

We look forward to seeing all your great ideas for improving QGIS!

With the QGIS Grant Programme 2022, we were able to support four proposals that are aimed to improve the QGIS project, including software, infrastructure, and documentation. The following reports summarize the work performed in the proposals. 

1. Support building QGIS application on Qt 6 (#243) – Report
   In addition to the original plan of porting the “gui” and “app” libraries to Qt 6, it was possible to complete also the “3d” and “server” libraries. We now are at a stage where the majority of QGIS builds and runs without any significant issues on Qt 6. The Github CI setup has been updated to also run the C++ tests for gui, app, server and 3d, and the majority of these have been fixed so that they pass on the Qt 6 builds too. In addition, some tests which were failing under Qt 6 revealed some real QGIS bugs which have been fixed in the process of this work. (So there’s a direct benefit for the existing Qt 5 builds too!).
2. Add SQL Logging in the debugging/development panel (#242) – Report
   When debugging or developing a QGIS algorithm or a QGIS plugin and when investigating performances of a particular layer it is often useful to view the SQL commands that QGIS sends to the backend. The SQL logging was implemented for Postgres, GeoPackage, Spatialite and Oracle data providers.
3. QGIS setting registry follow-up (#245) – Report
   The work can mainly be seen here PR qgis/QGIS#51295 with the proposed approach to register settings in a hierarchical and organized way, without too much complexity in the API to actually use the settings.
   To have a clean approach, some keys have been renamed. There is a compatibility handling (both forward and backward). The GUI implementation will be worked on during the HF in NL this spring.
4. Fix handling of provider default value clauses/Autogenerate/nextval(…) handling (#247) – Report
   The bulk of these changes landed in the QGIS 3.28 release. A quick way to demonstrate on of the issues fixed is: open a Geopackage file, start editing the layer, add some features to it, but don’t save the edits, then right click the edited layer and try to save it to a different file. On older QGIS releases you’ll be spammed with a number of error messages because we tried to write a string value of “Autogenerate” into a number field for all the newly created features. On QGIS 3.28 this all just works as expected, with no errors encountered.

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sustaining members and donors who make this initiative possible!

We are extremely pleased to announce the four funded proposals for our 2022 QGIS.ORG grant programme. Funding for the programme was sourced by you, our project donors and sponsors! Note: For more context surrounding our grant programme, please see: QGIS Grants #7: Call for Grant Proposals 2022

These are the proposals:

1. Add SQL Logging to the debugging/development panel
2. QGIS setting registry enhancement
3. Fix handling of provider default value clauses/Autogenerate/nextval(…) handling
4. Support building QGIS application on Qt 6

Since the total requested budget is equal to the available budget, there is no need for a voting this year.

On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!

With the QGIS Grant Programme 2021, we were able to support eight proposals that are aimed to improve the QGIS project, including software, infrastructure, and documentation. The following reports summarize the work performed in the proposals. 

1.  QGIS Server and services documentation (#213) – Report
   The Services chapter of the QGIS Server documentation needed some love to
   be effectively representative of the underlying implementation. Numerous
   services, requests or parameters were not documented at all. Some others
   also had very sketchy descriptions. Thanks to this QEP, the Services
   chapter is now in a much better shape!
2. Rework handling of multi-layer, mixed-format datasets (#216) – Report
   While the work was partly motivated as an opportunity to clean up some
   older parts of the QGIS codebase which were fragile and had low test
   coverage, it has also resulted in many improvements and polish in the
   QGIS user interface.
3. Port DB Manager Table Management Functionalities to Browser: SQL execution (part 3) (#205) – Report
   Besides SQL execution functionalities, an additional PR adds to QGIS core the query layer management tool that was provided by DB Manager plugin. The new API is fully covered by unit tests.
4. Locale support for numeric input and display: revision and enhancements (#210) – Report
   The work has been completed with multiple pull requests that fixed all localization issues that have been reported plus countless unreported issues that have been identified along the way.
5. Integrate GPS Tools plugin functionality into core QGIS (#217) – Report
   This grant sees the removal of the old, unmaintained “GPS Tools” core plugin, with all functionality from the plugin moved to reusable Processing algorithms or the unified Data Source Manager dialog. Since the functionality now uses the Processing framework, users gain the ability to run these tools in batch modes, as part of graphical models, and from 3rd party scripts and plugins. As a bonus the new tools are all fully covered by unit tests.
6. QGIS Server, OGC tests and Continuous Integration: OGC API Features (part 2 (#212) – Report
   Thanks to the QEP funding, the OGC API Features standard for QGIS Server is
   now checked in QGIS continuous integration since end-November 2021.
7. Fixing terrain and camera issues in 3D (#215) – Report
   These improvements should make the 3D map view easier to use. Especially the camera control issues (unintuitivie camera rotation and wrong center point) were quite tricky to fix.
8. Review process on plugins.qgis.org and improvements (#219) – This proposal has been withdrawn.

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sponsor and donors who make this initiative possible!

Dear QGIS Community,

We are very pleased to announce that this year’s round of grants is now available. The call is open to anybody who wants to make a funded contribution to QGIS, subject to the call conditions outlined in the application form.

The deadline for this round is in four weeks, on 13th February 2022.

As of 2022, we are changing the procedure in the following ways:

• The project budgets should account for PR reviewing expenses to ensure timely handling of the project-related PRs and avoid delays caused by relying on reviewer volunteer time. 
• In the week after the QEP discussion period, the proposal authors are expected to write a short summary of the discussion that is suitable for use as a basis on which voting members make their decisions. 

Also, note the following guidelines established in previous years: 

• The proposal must be submitted as a ‘QEP’ (QGIS Enhancement Proposal) issue in the repo: https://github.com/qgis/QGIS-Enhancement-Proposals (tagged as Grant-YEAR). Following this approach will allow people to ask questions and provide public feedback on individual proposals.
• Proposals must clearly define the expected final result, so that we can properly assess if the goal of the proposal has been reached.

For more details, please read the introduction provided in the application form.

We look forward to seeing all your great ideas for improving QGIS!

We are extremely pleased to announce the 8 winning proposals for our 2021 QGIS.ORG grant programme. Funding for the programme was sourced by you, our project donors and sponsors! Note: For more context surrounding our grant programme, please see: QGIS Grants #6: Call for Grant Proposals 2021.

The QGIS.ORG Grant Programme aims to support work from our community that would typically not be funded by client/contractor agreements. This means that we did not accept proposals for the development of new features. Instead proposals focus on infrastructure improvements and polishing of existing features.

Voting to select the successful projects was carried out by our QGIS Voting Members. Each voting member was allowed to select up to 6 proposals. The full list of votes are available here (on the first sheet). The following sheets contain the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:

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.
• Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We received 39 votes from 23 community representatives and 16 user group representatives.

On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!

With the QGIS Grant Programme 2020, we were able to support ten proposals that were aimed to improve the QGIS project, including software, infrastructure, and documentation. The following reports summarize the work performed in the proposals. We’ll update this blog post as more reports come in:

1. Quality Assurance methodology and infrastructure (Alexandre Neto, Alexander Bruy, Giovanni Manghi)
   

   The Tester plugin has been updated to run on QGIS 3.x. It allows to run automated and semi-automated tests and helps to conduct testing by providing step-by-step instructions to perform manual or verification tasks. An initial small set of tests for QGIS core functionality has been implemented as a separate QGIS Core Tests plugin. Furthermore, a test management system and test plan based on KIWI TCMS has been set up and documentation for testers has been created and published.

2. Smarter map redraws + tile download manager (Martin Dobias)

   Smarter Map Redraws avoid the annoying flicker when map in the map canvas is zoomed or moved. It is especially noticeable with background maps. The work has reduced the problem especially for raster layers. See the videos of comparison before/after.
   Tile Download Manager is not going to be very visible to the users, but it should make QGIS behave nicely with remote servers – until now it would be common that QGIS would request raster/vector tiles, then abort the requests while they were in progress when map got moved/zoomed, only to start those requests again – this should be avoided now.

3. DB Manager Table Management Functionalities to Browser Port – part 2 (Alessandro Pasotti)

   QGIS browser now exposes a new “Fields” item for vector layers that can be expanded to show the underlying fields, an icon identifies the base field type. New context menu items allow user to create and delete fields. At the connection level, a new context menu item allows you to create a new table for all DB connections that support the Connections API (PG, Spatialite, GPKG, MSSQL). All the new functions are implemented using the new connections API and exposed to Python for plugins/scripts. There have been many other small improvements in the API and in the browser, such as homogenization of the error/warning/success reporting .

4. QGIS Server, OGC tests and Continuous Integration (Paul Blottiere)
   A Python tool named pyogctest has been implemented to run OGC tests in command line for the WMS 1.3.0 testsuite and has been integrated with GitHub Action in QGIS continuous integration mechanism to avoid regressions. The documentation chapter about OGC and conformance tests is now up-to-date with an explanation of how pyogctest can be used locally for server developers. Moreover, pyogctest is now also integrated with QGIS-Server-CertifSuite for the nightly tests. This way we have an homogeneous testing environment with CI. 
5. QGIS Server performance monitoring (Paul Blottiere)
   The whole QGIS-Server-PerfSuite has been upgraded to use 3.10 and 3.14 releases side by side with 2.18 and master branch. Performances may be now monitored daily with the latest releases. Moreover, a simple anomalies detection mechanism has been implemented and a mail is sent if a regression is detected. Several scenarios have been added to compare performance with the same data but relying on different providers (PostGIS, Spatialite, Geopackage and Shapefile). Finally, a simple mechanism based on multiprocessing has been implemented to simulate multi-clients situation. 
6. FileGeodatabase spatial index in OpenFileGDB driver (Even Rouault)
   This work has been successfully completed in GDAL master (for GDAL 3.2) and automatically benefits QGIS when it uses the OpenFileGDB driver. Performance-wise, for example, counting the number of features intersecting a spatial filter which returns 81 046 polygons, now runs in 400 ms with GDAL 3.2dev and the OpenFileGDB driver, versus 6.7 s before (full scan), vs 890 ms with the FileGDB driver (with FileGDB SDK 1.5). Interactive display in QGIS with the OpenFileGDB driver is as fluid as with the FileGDB one. Comparing behaviour of OpenFileGDB and FileGDB drivers with strace shows that they read a similar amount of data in the .spx file, which confirms it is uses correctly. The filegdb reverse engineered specification was also updated.
   
7. MacOS packages (Peter Petrik)
   All tasks from the proposal except the notarization process have been addressed since the work necessary to address critical bugs in projection, grass, saga, gdal, python and other parts of the MacOS packages exceeded expectations. (A note about the workaround for notarization has been added to the QGIS.org webpage for now.) Key improvements for QGIS 3.16 MacOS Packages are: QGIS-Mac-Packager without homebrew dependencies, updated GDAL3, PROJ6 & GRASS 7.8.2, fixed Grass, Saga &, GDAL provider loading, and many more. 
   
8. Evaluate Qt for Python (Denis Rouzaud)
   The initial evaluation was followed by a report on the migration to Qt-for-Python. The report’s recommendations are now being discussed in QEP#237.
9. Settings registry (Denis Rouzaud)
   The complete implementation of the core part has been achieved (settings, registry and Python bindings). All core settings were migrated. Other settings still have to be migrated, CI tests should be added to avoid usage of the old API and potential GUI improvements are outlined in the report.
   
10. To be continued 

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sponsor and donors who make this initiative possible!

Dear QGIS Community,

We are very pleased to announce that this year’s round of grants is now available. The call is open to anybody who wants to make a funded contribution to QGIS, subject to the call conditions outlined in the application form.

The deadline for this round is 21st March 2021.

For more details, please read the introduction provided in the application form.

We look forward to seeing all your great ideas for improving QGIS!

We are extremely pleased to announce the winning proposals for our 2020 QGIS.ORG grant programme. Funding for the programme was sourced by you, our project donors and sponsors! Note: For more context surrounding our grant programme, please see: QGIS Grants #5: Call for Grant Proposals 2020.

The QGIS.ORG Grant Programme aims to support work from our community that would typically not be funded by client/contractor agreements. This means that we did not accept proposals for the development of new features. Instead proposals focus on infrastructure improvements and polishing of existing features.

Two proposals focusing on documentation improvements were funded directly from the documentation budget. The remaining 10 proposals continued on to the voting.

Voting to select the successful projects was carried out by our QGIS Voting Members. Each voting member was allowed to select up to 6 proposals. The full list of votes are available here (on the first sheet). The following sheets contain the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:

Thanks to the generous support by our sponsors and donors, we are happy that all proposals will receive funding, even if QEP#124 had to be reduced in scope (core part only, no GUI: €2,600 from QGIS grants & €1,400 sponsored by OPENGIS).

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.
• Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We received 34 votes from 21 community representatives and 13 user group representatives.

On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!

Dear QGIS Community,

Our previous rounds of grant proposals have always been a great success (2019, 2018, 2017, 2016). We are very pleased to announce that this year’s round of grants is now available. The call is open to anybody who wants to make a funded contribution to QGIS, subject to the call conditions outlined in the application form.

The deadline for this round is 24th May 2020.

For more details, please read the introduction provided in the application form.

We look forward to seeing all your great ideas for improving QGIS!

With the QGIS Grant Programme 2019, we were able to support six proposals that were aimed to improve the QGIS project, including software, infrastructure, and documentation. These are the reports on the work that has been done within the individual projects:

1. Profile and optimise the QGIS vector rendering code (Nyall Dawson)
   We conducted in-depth research into code “hot spots” and inefficiencies in the QGIS rendering code using a number of code profiling tools. This work resulted in many optimisations in the vector rendering code and other parts of QGIS (such as certain Processing algorithms). These optimisations were made available in the QGIS 3.10.0 release.
2. “Rebalance” the labeling engine and fix poor automatic label placement choices (Nyall Dawson)
   We first designed unit tests covering a range of different label placement situations and then used these tests as a guide to re-work the label placement engine. Now, labels will never be placed over features from a layer with a higher obstacle weight, avoiding the complexities and bugs which were present in the older approach. To avoid disrupting existing projects, the new labeling logic is only used for newly created projects in QGIS 3.12 and later. (Existing projects can be upgraded via the project’s label settings dialog.)
3. Reuse core functionality to provide DB manager features (Alessandro Pasotti & Nyall Dawson)
   We have developed a new QGIS core API, fully exposed to Python, that makes it possible to manage stored connections to various data provider source in a unified and consistent way. This is part of a larger effort building a new connections API.
4. Snapping cache improvements (Hugo Mercier)
   Snapping is crucial for editing geospatial features. Snapping correctly supposes QGIS have in memory an indexed cache of the geometries to snap to. And maintainting this cache when data is modified, sometimes by another user or database logic, can be a real challenge. This it exactly what this work adresses. This feature has been merged into QGIS 3.12.
5. Fix problems in larger 3D scenes (Martin Dobias)
   We worked on two issues within 3D map views. The first one was that map tiles were only being prepared using a single CPU core – this is now fixed and we may use multiple CPUs to load tiles of 3D scenes faster. The other (and greater) problem was that data from vector layers (when they have 3D renderer assigned) were all being prepared at once for the whole layer in the main thread. That resulted in possibly long freeze of the whole user interface while data were being loaded. This is now resolved as well and data from vector layers are being loaded in smaller tiles in background threads (and using multiple CPU cores). As a result, the overall user experience is now much smoother.
6. Open documentation issues for pull requests (Matthias Kuhn and Denis Rouzaud)
   A documentation bot is now alive and automatically create an issue in the documentation repo for merged PR.

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sponsor and donors who make this initiative possible!

With the QGIS Grant Programme 2018, we were able to support seven proposals that were aimed to improve the QGIS project, including software, infrastructure, and documentation. These are the reports on the work that has been done within the individual projects:

1. Increased stability for Processing GUI and External Providers (Nyall Dawson)
   Many bugs in 3rd party providers have been fixed and lots of new unit tests added. The GUI includes new C++ classes and a  new framework that landed in QGIS 3.4. For more details see Nyall’s report on the mailing list.
2. OSGeo4W updates (Jürgen Fischer)
   The updates performed in this project were essential to bring QGIS 3.x to Windows.
3. Resurrect Processing “R” Provider (Nyall Dawson)
   The R provider has been implemented as a provider plugin. The plugin’s beta phase was first announced in Nov 2018 and the plugin is now available for general use.
4. OpenCL support for processing core algs (Alessandro Pasotti)
   The following processing algorithms have been ported: slope, aspect, hillshade, and ruggedness. Even if was not in scope for this QEP, the hillshade renderer has also been optimized. For more details see qgis/QGIS#7451.
5. QGIS server OGC compliant and certified for WFS (Régis Haubourg)
   This project fixed numerous issues to get closer to the goal of getting QGIS Server WFS certified. However, the project ran out of resources before the goal could be achieved. For details see the current WFS tests status page.
6. Charts and drawings on attribute forms (Matthias Kuhn)
   For details read “The new QML widgets in QGIS” and see qgis/QGIS#7801.
7. Update of QGIS Training Manual (Matteo Ghetta)
   This project hasn’t been completed yet.

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sponsor and donors who make this initiative possible!

We are extremely pleased to announce the winning proposals for our 2019 QGIS.ORG grant programme. Funding for the programme was sourced by you, our project donors and sponsors! Note: For more context surrounding our grant programme, please see: QGIS Grants #4: Call for Grant Proposals 2019.

The QGIS.ORG Grant Programme aims to support work from our community that would typically not be funded by client/contractor agreements. For the first time, this year we did not accept proposals for the development of new features. Instead proposals should focus on infrastructure improvements and polishing of existing features.

Voting to select the successful projects was carried out by our QGIS Voting Members. Each voting member was allowed to select up to 6 of the 10 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:

A couple of extra notes about the voting process:

• The PSC has an ongoing program to fund documentation so elected to fund the proposal “Open documentation issues for pull requests” even if this increases the total funded amount beyond the initial budget.
• Although the budget for the grant programme was €20,000, the total amount for the winning proposals is €22,200. This increase is possible thanks to the generous support by our donors and sponsors this year.
• 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.
• Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We received 31 votes from 16 community representatives and 15 user group representatives.

On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!

A number of interesting and useful proposal didn’t make it because of our limited budget; we encourage organizations to pick up one of their choice and sponsor it.

Dear QGIS Community

Our first three rounds of Grant Proposals were a great success. We are very pleased to announce the fourth round of grants is now available to QGIS contributors.

Based on community feedback, this year, we will not accept proposals for the development of new features. Instead proposals should focus on infrastructure improvements and polishing of existing features.

The deadline for this round is Sunday, 2 June 2019. All the details for the grants are described in the application form, and for more context we encourage you to also read last year’s articles:

• QGIS Grants #3: Call for Grant Proposals 2018
• QGIS Grant Programme 2018 Results

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

Anita Graser

QGIS PSC

While we are waiting for this year’s grant proposals to come in, it is time to look back at last year’s winning proposals and their results. These are the reports on the work that has been done within the individual projects:

QGIS 3D – Martin Dobias

Results are included in the QGIS 3.0 release. As proposed in the grant, a new 3D map view has been added together with GUI for easy configuration of 3D rendering. The 3D view displays terrain (either from a DEM raster layer or a simple flat area) with 2D map rendered on top of the terrain. In addition to that, vector layers can be rendered as true 3D entities: points may be visualized as simple geometric shapes or as 3D models (loaded from a file), polygons and linestrings are tessellated into 3D geometries. 2D polygons can be turned into 3D objects using extrusion, possibly with data-defined height – an easy way how to display buildings, for example. Data with 3D coordinates have the Z values in geometries respected. Although the 3D view is still in its early stages, it is already usable for many use cases. Hopefully this functionality will help to attract even more users to QGIS!

More details: https://github.com/qgis/QGIS-Enhancement-Proposals/issues/105

Improvements to relations – Régis Haubourg

Various improvements for deep relations with PostgreSQL were successfully added in QGIS 3.0:

• CTRL+Z is back in transaction group editing ! We restored the UNDO/REDO feature and all edits are temporarily saved inside PostgreSQL SAVEPOINTS. For more details, please jump here http://oslandia.com/en/2017/10/10/undo-redo-stack-is-back-qgis-transaction-groups/
• Transaction group allows now to play more easily with stored procedure calls. It is now possible to use ‘QgsTransaction.ExecuteSQL’, dirty the edit buffer to let user be able to save changes, and give a name to that action so that the UNDO/ REDO actions are more explicit. See the Pull requests for more details:
  • https://github.com/qgis/QGIS/pull/5376
  • https://github.com/qgis/QGIS/pull/5628
  • https://github.com/qgis/QGIS/pull/5663
• Trigger QGIS actions or layer refresh from PostgreSQL. Want to code a live dashboard and use QGIS to display messages, pictures, refresh map layers when PostgreSQL casts a NOTIFY signal? Read more at http://oslandia.com/en/2017/10/07/refresh-your-maps-from-postgresql/

Add consistency to UI controls – Nyall Dawson

We’ve unified all the various opacity, rotation and scale controls to use the same terminology and numeric scales. We’ve also updated ALL methods for setting opacity, rotation and scale within the PyQGIS API to use consistent naming and arguments, making the API more predictable and easy to use. Lastly, we’ve also added a new reusable opacity widget (QgsOpacityWidget) to the GUI library so that future code can (and 3rd party scripts and plugins) can follow the new UI conventions for opacity handling.

Extend unit test coverage for geometry classes – Nyall Dawson

We’ve extended the unit testing coverage for all the underlying geometry primitive classes (points, lines, polygons, curves, collections, etc) so that all these classes have as close to 100% unit test coverage as possible. In the process, we identified and fixed dozens of bugs in the geometry library, and naturally added additional unit tests to avoid regressions in future releases. As a result QGIS’ core geometry engine is much more stable. Furthermore, we utilised the additional test coverage to allow us to safely refactor some of the slower geometry operations, meaning that many geometry heavy operations will perform much faster in QGIS 3.0.

Processing algorithm documentation – Matteo Ghetta & Alexander Bruy

The new Help system is landed and already available: when opening a Processing algorithm and clicking on the Help button, the guide of the algorithm will be showed in the default browser.

Many of the QGIS Processing algorithm guides have been enhanced with pictures and new or enhanced descriptions. A consistency number of Pull Requests have been already merged and many others are in review. Just a few descriptions need to be still enhanced.

Currently all the QGIS algorithms have been described and all the PR in the doc repository have been merged (kudos to Harrissou for all the reviews!).

Right now the Help button of each Processing dialog will open the related page of the algorithm, BUT:

• if the name of the algorithm is made by only ONE word (e.g. clip, intersection…), the help button will open the browser to also the correct section (that is, the user will see directly the description of the related algorithm)
• if the name of the algorithm has >1 words (e.g. split polygon with lines, lines to polygon, ecc.) the Help button will open the correct page (so the algorithm GROUP) but is not able to go to the correct algorithm anchor. This is because sphinx converts “split with lines” in “split-with-lines” while QGIS system will always cast the words “split-with-lines” in “splitwithlines”. Not a big deal, but IMHO a pity.
  We are really too close to the solution.

So Processing Help system right now consists of:

• QGIS algs -> documented
• GDAL algs -> documented
• GRASS -> documented (own docs)
• Orfeo -> documented (own docs)
• SAGA -> nothing documented

Thanks to QGIS Grants to provide this chance to give a big improvement to the Processing framework even if not in a coding way!

Last but not least, we had another project that was not part of the grant programme but was also funded by QGIS.ORG in 2017:

Python API documentation – Denis Rouzaud

QGIS Python API Documentation is created using Sphinx and this work is available on Github. The repo is a fork of QGIS’ one and has been merged in the meantime. The docs are available at qgis.org/pyqgis. It uses a new theme (sphinx_rtd_theme aka ReadTheDocs theme). Some improvements were brought in (not exhaustive):

• QGIS theming with colors and icon
• Foldable toctree
• Summary of methods and attributes for classes
• Module index (not available before)
• Correct display of overloaded methods

Full Python signature in Docstring

In former SIP versions, it was not possible to use the auto generated signature if a Docstring already existed. This means any documented method could not have a signature created. Unfortunately for this project, the vast majority of methods in QGIS API are documented!

The source code of SIP was modified and theses changes got merged upstream. See rev 1788 to 1793 in SIP changelog. It will be released in upcoming 4.19.7 version. QGIS source code was modified accordingly to prepend auto generated Python signatures to existing Docstrings. Using a CMake configuration file for each module (core.sip.in, gui.sip.in, etc.) was required to avoid syntax errors when using former version of SIP (since bumping minimum version is not realistic).

Sipify adjustments

Many things were fixed in sipify script :

• Creation of links to classes, methods
• Handling/fixing of Doxygen annotations \see, \note, \param
• Handling of code snippets: c++ vs Python. Only Python are shown.

Thank you to everyone who participated and made this round of grants a great success and thank you to all our sponsor and donors who make this initiative possible!

Anita