How are you qualified to do this?

What is your implementation schedule / plan?

OpenLitterMap QGIS Plugin. Easily access open data on plastic pollution anywhere!

OpenLitterMap data is open data. However, users need to download the data from OLM and import into QGIS manually. To improve data utility and increase science on plastic pollution, we are planning to integrate an OpenLitterMap plugin into QGIS. With support, we could do it sooner.

https://openlittermap.com

https://opengeospatialdata.springeropen.com/articles/10.1186/s40965-018-0050-y

Full stack developer in PHP and JavaScript. Looking to expand into other domains and make a contribution to QGIS.

even.rouault@spatialys.com

Use of FileGeodatabase spatial index in OpenFileGDB driver

Outside of the open-source geospatial realm, ESRI software is the dominant vendor in the geospatial industry. Regardless of how open-source friendly a particular organisation or user is, the reality
is that they will need to interact with ESRI data formats on a regular basis. Many official government data portals provide spatial data only in ESRI formats, and some customers will only supply source data in these formats. It is critical to the success of open-source geospatial software that this software has stable and performant capabilities to read these propreitary ESRI formats and provide a means to convert this data into standard, open-source friendly formats.

Since all of QGIS' support for reading and writing disk based files is provided by the underlying GDAL library, it is natural that support for these proprietary ESRI formats be added or extended in GDAL itself. While QGIS will directly benefit from this work, investment in GDAL also directly benefits many other open-source geospatial tools, including GRASS GIS, PostGIS, R, rasterio / fiona, MapServer, etc.

While an open-source driver (OpenFileGDB : https://gdal.org/drivers/vector/openfilegdb.html) exists for reading vector datasets stored within ESRI geodatabase (gdb) files, this driver has been developed from reverse engineering efforts. One major component missing from the driver is the lack of support for spatial indexes, which results in very slow vector layer access from these files. Unfortunately, storing vectors in GDB files is the standard practice for ESRI software, and accordingly many users are required to access vector data stored in
these formats. This is especially critical for users in administrations where the official government data portals are based on ESRI server software, providing these users with no choice but to
obtain official datasets in these formats. An optimised open-source GDB driver which can utilise spatial indexing from these formats will directly benefit a huge number of QGIS users.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/172

The GDAL/OGR OpenFileGDB driver already exists, and offer all expected functionality from a read/only driver, except the use of spatial index when they are available. Further research, done in collaboration with Nyall Dawson, has lead us to understand what was missing to be able to exploit spatial index files.

I've reverse-engineered the FileGDB format and published its specification at https://github.com/rouault/dump_gdbtable/wiki/FGDB-Spec. The GDAL OpenFileGDB driver has been built upon it. More generally, I'm one of the maintainers of GDAL/OGR and a core committer to QGIS, as well as other free & open-source geospatial software (PROJ, etc)

The work will be completed for the release of GDAL 3.2 (planned for beginning of November 2020)

even.rouault@spatialys.com

FileGeodatabase raster read support

Outside of the open-source geospatial realm, ESRI software is the dominant vendor in the geospatial industry. Regardless of how open-source friendly a particular organisation or user is, the reality
is that they will need to interact with ESRI data formats on a regular basis. Many official government data portals provide spatial data only in ESRI formats, and some customers will only supply source data in these formats. It is critical to the success of open-source geospatial software that this software has stable and performant capabilities to read these propreitary ESRI formats and provide a means to convert this data into standard, open-source friendly formats.

Since all of QGIS' support for reading and writing disk based files is provided by the underlying GDAL library, it is natural that support for these proprietary ESRI formats be added or extended in GDAL itself. While QGIS will directly benefit from this work, investment in GDAL also directly benefits many other open-source geospatial tools, including GRASS GIS, PostGIS, R, rasterio / fiona, MapServer, etc.

This proposal covers creation of extending the existing OpenFileGDB driver, currently only handling vector layers, to be able to reader raster layers stored within an ESRI geodatabase (gdb) file. There is currently NO way to read these raster files within QGIS (or with any other open-source software widely available), which entirely prevents users from either viewing these datasets or converting them to alternative standard raster formats. This presents a critical road block to open-source adoption by users who have previously used ESRI software and have existing raster GDB files, OR by users who can only access official raster data in these formats. Access to all data formats from open-source software is a priority one requirement, and the inability to read these rasters formats from any tool presents a critical risk to the open-source geospatial community.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/173

The GDAL/OGR OpenFileGDB driver already exists to read vector layers. Further analysis was done by James Ramm specifically on raster tables, and a proof-of-concept conversion utility was written by Richard Barnes (https://github.com/r-barnes/ArcRasterRescue)

I've reverse-engineered the FileGDB format and published its specification at https://github.com/rouault/dump_gdbtable/wiki/FGDB-Spec. The GDAL OpenFileGDB driver has been built upon it. I've also taken part to initial work regarding reading of raster content in FileGDB. More generally, I'm one of the maintainers of GDAL/OGR and a core committer to QGIS, as well as other free & open-source geospatial software (PROJ, etc)

The work will be completed for the release of GDAL 3.2 (planned for beginning of November 2020) and for QGIS part for QGIS 3.18 at the latest

blottiere.paul@gmail.com

QGIS Server, OGC tests and Continuous Integration

QGIS Server continues to increase in popularity so we have to keep focusing on its robustness. Currently, QGIS Server is certified for WMS 1.3.0 and OGC tests are performed every night on master to ensure that we're still compliant.

However, considering that these tests are performed on master branch once a day, OGC compliancy is checked after a new development have been merged. Of course, when we have doubts, "someone" manually tests the new feature or the bugfix before merging, but this situation is far from being optimal and can lead to regressions. Moreover, it can be hard and frustrating to not be able to run these OGC tests locally during the development phase.

This proposal will allow to run compliancy tests both locally - in a simple and direct manner - as well as for each Pull Request, focusing on the WMS 1.3.0 testsuite for now.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/175

OGC compliancy tests are already running every night and corresponding scripts are available on the QGIS-Server-CertifSuite repository. Thus, it'll be the starting point.

I'm a QGIS core committer and I especially worked on QGIS Server these last years. Lastly, I worked on the OGC API Features certification (see http://blog.qgis.org/2020/05/13/qgis-server-and-ogc-api-features/) and I'm maintaining the OGC certification infrastructure for QGIS Server.

The whole package should be ready for QGIS 3.16.

peter.petrik@lutraconsulting.co.uk

QGIS MacOS Packaging Update

The proposal is to use the new system of dependancies instead of Homebrew for the QGIS MacOS packages to facilitate the maintenance effort in the long run. It would also mean updates of PROJ, GDAL, GRASS and other libraries for MacOS user to latest stable versions.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/177

I have created proof of concept for the new packager system that can be seen in https://github.com/qgis/QGIS-Mac-Packager and which is now used for QGIS MacOS CI builds.

I have implemented the current MacOS all-in-one bundle packager.

I would like to have testable prototype for 3.14 release as soon as possible. Based on the testing feedback and issues found, one of the following patch release for 3.14 could be already released fully with the new system. The system can be also used for the LTR build.

Alessandro Pasotti and Even Rouault

This proposal will allow to import any QGIS supported raster format into an existing Postgis database with optional tiling and overviews, the functionality will be available from the QGIS browser panel through drag & drop (with an intermediate dialog to allow setting of options) and it will be made available to plugins and further menu actions integration through the QgsRasterFileWriter core API

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/174

The work will consist of improvements in the GDAL library implemented by Even Rouault that has a long history of QGIS and GDAL contributions, Alessandro Pasotti will take care of QGIS integration and tests and he also has a long history as a QGIS contributor.

Alessandro implemented the new native Postgres Raster Provider available in 3.12 and Even has a huge experience in GDAL development, they are both happy and excited about the possibility to see this last piece of the Postgres Raster puzzle fall into place.

We think that a realistic target for this task is Q4 2020 but we may be able to deliver before.

Alessandro Pasotti and Nyall Dawson

Port DB Manager Table Management Functionalities to Browser (part 2)

With a constantly growing set of data provider supporting the connections API we are now in the position to start the implementation directly in the browser of another group of functionalities that are currently available in DB-Manager, the functionality we intend to port include most of the table management capabilities:

creation of new tables
creation of new fields
removal of existing fields

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/171

This is the continuation of an ongoing effort to replace DB-Manager python implementation with wel tested C++ core API. It started last year with another grant where the connections API was introduced and was continued with other PRs during the last few months.

Alessandro and Nyall are two active QGIS core contributors with a lot of experience in QGIS development and they have been working on this area of the code for years. They are excited to be able to continue the porting work from Python to C++ in order to bring stability with a well tested and solid implementation to the QGIS browser panel .

Reasonable delivery time is Q4 2020 but we might be able to do the job a little earlier.

Romário Moraes Carvalho Neto

romariocarvalho@hotmail.com

Cookbook Cheat Sheet written as ESRI/ArcPy documentation

This proposal may embrace three of the eight examples of topics: Updating and improving documentation; Improving API documentation; Helping new QGIS devs to get started with improved developer documentation and utilities.
The Cookbook is a wonderful way to help new QGIS devs to get started, but the QGIS Python API is complex and may seem confused for someone that is just starting. I propose to enrich the Cookbook Cheat sheet, aiming to have it on the same standard as the ESRI documentation, for the tools in the toolbar and for the information that is already in it, to provide a smooth way to conduct the beginner devs from the cookbook to the API. Example of ESRI doc standard: Summary, Discussion/Usage, Syntaxes (maybe a link to the QGIS Python API) and code example. Let’s do it for the cheat sheet and add image of the results.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/178

I pretend to build on the work that already has been done at the Cookbook Cheat Sheet. At this time, I teach Python for QGIS. I based my proposal on the experience I had and I believe many others may have as well.
I started to work with Python along with ArcGIS, about 7 years ago for my Ph.D. When I started to program for GIS uses, I got used to the clean and direct way the documentation of ArcPy was (and still is), explaining what a particular function would do, explaining its syntax, arguments types and with a clear simple example of its use. With basic Python and knowing what I need to do, I could look at the documentation and do it. When I finish school and started to work with QGIS, I got lost with the difference between the clearness of the ArcPy and the QGIS information. Something what took me few minutes to perform, now took me hours of research and attempts. Things may get even harder when English is not your first language. It is great to see how the QGIS documentation is getting much better in the past few years, with the QGIS Python API and especially with the PyQGIS Cookbook, which surely can give guidance to start to develop with Python, but I feel we still have a gap to provide a more straight, clear, official documentation for those that are looking to start or already have an intermediate knowledge of Python.

I’ve being working with Python for a little more than 7 years now. I’ve developed two plugins for QGIS by the names: a) BHCgeo , b) Weighted Multi-Criteria Analysis – WMCA. I will follow the Documentation Guidelines at:
https://docs.qgis.org/3.10/en/docs/documentation_guidelines/index.html
to write and accomplish the proposed work. I’m a Forest Engineer with Master’s degree in Civil Engineering (in the Water Resources and Environmental Sanitation Area), Ph.D. (in Forestry) by the Federal University of Santa Maria (UFSM), Brazil and Ph.D. (in Land Environment Resources and Health) by the Università Degli Studi di Padova (UniPD), Italy. I am just finishing a Specialization on Geomatics (UFSM), focusing strongly in Python for QGIS. I’m now working online as a freelancer, teaching Python for beginners in QGIS, where they learn to code directly on the text editor of QGIS. I have all time of the world with this quarantine, which is only half way through here in Brazil (where I live) and may take a month or so to finish.

Since the target version is QGIS 3.16, and its release is programed to be 2020-10-23, the proposed work is planned to be done by September the 30th.
Counting from June to October, and considering the eleven items already in the Cheat Sheet, the plan will be for four months.
June: Learn about the Documentation Guidelines; Add information of processing tools (Processing algorithms);
July: Keep adding information of processing tools (Processing algorithms); August: User Interface, Settings, Toolbars, Menus, Canvas, Layers;
September: Continue Layers, Table of contents, Advanced TOC, Decoratos, Composer.

Turning Plugin Management into Actual Package Management

QGIS Python plugins can not explicitly depend on regular Python packages. Although QGIS Python plugins can depend on other QGIS Python plugins, introduced in QGIS 3.8, this mechanism is far away from mature. Code quality, design and maintainability of the entire current plugin management system within QGIS, based on a detailed analysis of version 3.12, are questionable at best. This document proposes (a) to re-implement the existing plugin management system with all of its features, (b) to clean up the cross-plugin dependency design and (c) to add support for both the `conda` and the `pip` Python package managers for managing QGIS Python plugins - effectively adding support for dependencies between QGIS Python plugins and regular Python packages. These proposed changes are fully backward compatible and do not introduce adverse performance characteristics.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/179

- I explored options by developing a proof-of-concept QGIS plugin - [see Github repo](https://github.com/qgist/pluginmanager).
- I tried and studied every bit of proposed technology in terms of figuring out the overall feasibility of the proposed changes.
- I explored, debugged and documented all relevant sections of QGIS source code (as documented in the QEP).
- I got in touch with developers through the developer mailing list, exploring design issues and asking questions for gaining a deeper understanding of the subject matter (as documented in the QEP).

- I have built (i.e. compiled) QGIS from scratch many times and successfully applied changes.
- I have intensely studied QGIS code base (as documented in the QEP).
- I develop and maintain QGIS plugins (some open source, some proprietary).
- I develop and maintain established open source Python packages.
- 15 years of Python experience, for the past 6 years on a daily & professional basis
- 7 years of experience in using Qt
- While I am confident that I can handle the proposed C++ cleanups myself, I would be happy to collaborate with an experienced QGIS C++ developer in this particular matter.

- Most of this work will be carried out in July and August of 2020.
- It is supposed to be finished and tested before the feature freeze of QGIS 3.16 on 2020-09-11.
- Step 1 (as described in QEP) has mostly been implemented. Open points:
- Transplant existing work on step 1 into QGIS code base.
- Finish the unfinished pieces (dependency mechanism cleanup and plugin loading sequence) of step 1. Required time: 2 to 3 days.
- Implement step 2 (as described in QEP). Required time: Roughly 2 full weeks.
- Implement tests for new plugin manager module and fix bugs along the way. Required time: Roughly 1 to 2 full weeks.
- Write documentation. Required time: Roughly 2 to 3 days.
- Total allocated time for project: 5 weeks full time, including buffers.
- I am planning to maintain this code long-term.

Matteo Ghetta and Håvard Tveite

matteo.ghetta@gmail.com

Enhance QGIS Documentation

We aim to close a lot of old issues, perform a general issue triage but most important we will focus on all the chances to enlarge the community. We will produce videos for the Documentation Guidelines, we will provide webinars with live session where interested people can see how the documentation works and how to write/edit/add content.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/183

Both of us are working on the QGIS documentation and we are committer of the repository. We both know the documentation structure and the weak point where to act.

We are contributor of the QGIS documentation since long and we are committer of the repository (Havard 3rd committer, Matteo 8th committer).

We aim to do this by the release of QGIS 3.16 (2020-10-23). If we have still resources we will continue the work on the documentation by documenting new features and by closing other issues.

denis.rouzaud@gmail.com

Analysis of the potential use of Qt for Python (in place of PyQt)

Qt6 is at the corner (end of the year) and we should start thinking at what we are willing to accomplish for the next big turn with QGIS 4.
Qt bindings will have to change in any case (PyQt5->PyQt6), it is therefore an opportunity to question this choice.

This proposal aims at analysing Qt for Python and Shiboken to:

* evaluate if it is technically possible to replace our current Qt bindings (PyQt5) and bindings generator (SIP)
* list and evaluate the risks involved in this change, mainly the effort that plugin authors will have to achieve compared to a migration to PyQt6.
* draw a road plan and a rough estimate of the work required

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/163

At the moment, I have mainly spent some time reading info about Qt for Python and been discussing with some other core devs about the opportunities/risks of moving away from PyQt6 and also thought about the technical implications.

I have written our bindings generator (sipify) which automatically creates the Python bindings out of the c++ code. I have a great interest around the Python bindings (I am also the maintainer of PyQGIS API docs)

This work will be achieved within 4 months after its acceptance.

denis.rouzaud@gmail.com

QGIS application settings are spread over the source code and are prone to many errors (typo, different default values, type change (e.g. int to enum, double to int), etc.).
We propose here to introduce a registry for settings which will allow preventing such errors.
This registry will also provide some extra information like description or validity domain (min, max, etc).
We believe this is a great addition both for the correctness and completeness of QGIS core but also as a time saving tool for plugin authors.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/124

I have done some prototyping in Python and have done some work around the settings in QGIS core, especially for enum based settings.

I am a core committer since 2012 and one of the most active developper currently around QGIS.

This will be achieved within 4 months after its acceptance.

Smarter Map Redraws + Tile Download Manager

This proposal would like to address two separate issues with map rendering:
1- Smarter redrawing of map canvas to avoid flicker
2- Download manager for tiled data sources

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/181

All of the work planned here will be based on other qgis_core code (and it will reside in qgis_core as well). For the smarter redrawing this is an idea that came out of usage of QGIS and comparison with the user experience of web maps. For the download manager I have started prototyping code for it.

I have been a core developer in QGIS since 2005 and the internals of map rendering in QGIS has been always of my interest. Over time I have done various pieces of work to make the map rendering better, such as multi-threaded rendering or previews of WMTS/XYZ rendering.

I would like to implement the fixes in QGIS 3.16.

Alexandre Neto, Giovanni Manghi, Alexander Bruy (QCooperative)

alexandre.neto@qcooperative.net

QGIS Quality Assurance methodology and infrastructure

In the last years, the QGIS project has given important steps towards improving QGIS stability. This includes: having regular, long term, and point releases; one-month feature freeze periods with funded bug-squashing; larger unit test coverage and continuous integration.

Unfortunately, one of the weak points is still the lack of enough user’s testing during the feature freeze period, which may lead to releases with too many unknown bugs. These bugs are only found when general users start to use the new stable version.

This proposal aims to create the necessary infrastructure and suggested a methodology to organize and encourage systematic testing before each release:

- Setup a Testing management system to organize test cycles, assign and track tests execution (kiwi TCMS);
- Elaborate and document a methodology to execute testing to help testers
- Resurrect and move the tester plugin to QGIS repositories. Publish it in the QGIS official repository
- Create an initial set of relevant test cases
- Organize and execute the initial test cases for the next releases (3.18, 3.20, 3.22)

Not covered by this grant funding, we plan also to:
- Help onboarding new testers from the community
- Create more test cases
- Implement test cases as automated or semi-automated tests for the tester plugin

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/180

At Boundless Spatial, the QGIS team’s main project was the production of an alternative QGIS installer for windows and Mac OS, which included specific configurations, patches, and plugins for our clients.

For Quality Assurance (QA), the team created and polished a detailed workflow to test each release. A large set of test cases was created, with step by step instructions, to test the installers, product functionality, and integration with other software, like PostGIS and Geoserver. The team have also created a tester plugin for QGIS, which allows running automated and semi-automated tests within QGIS.

When the project was canceled and the team dismantled, all this work, knowledge, and experience got lost or idle. The idea is to use our personal knowledge and recover part of the work to adapt and implement the testing cycle for the QGIS community to use.

In different periods of time, both Alexandre Neto and Giovanni Manghi assumed the role of Quality Assurance (QA) Lead. As QA Lead they were responsible for creating and managing test cycles for new releases, or new qgis plugins releases.

On the other hand, Alexander Bruy is the co-author of the QGIS tester plugin, together with other members of the QCooperative: Victor Olaya and Luigi Pirelli. He has also created many automated and semi-automated tests for the tester plugin.

As a team, we all worked together to systematically run the test cycles against release candidates and fix the problems found by the process.

We pretend to have the base infrastructure and a sample set of test cases ready for the QGIS 3.18 release (3.17 Feature release 2021-01-15). From that point on, we would guarantee running the sample set of test cases for the next releases until the next LTR (3.22) for the main Operating System, Windows 10, and help onboard more community testers.

vincent.picavet@oslandia.com

QGIS Server documentation improvement

This grant propose a work on various aspects of QGIS Server documentation, to improve its overall quality and completeness. Deployment, system configuration, user configuration, FAQ, feature matrix and missing documentation parts are among the items we want to improve.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/184

QGIS Server documentation has improved lately thanks to numerous contributions. There is still work to do on top of the current documentation. We will add new content and integrate what we learned implementing QGIS Server for our clients.

Oslandia has contributed a lot to QGIS Server since the rewriting has begun. We contributed to the certification platform and performance testing platform. We deploy QGIS server for high-demanding applications and have gathered a lot of experience and knowledge, identifying corner-cases and optimizations. We will work on this grant application as a team to gather our knowledge into the documentation. Among the team members willing to contribute : Julien Cabièces, Bertrand Rix, Vincent Picavet, Régis Haubourg, Sébastien Peillet, and also Benoit Blanc who focus on QWC 2 integration.

The work will span during this summer, to be able to be ready for QGIS 3.16.

blottiere.paul@gmail.com

QGIS Server and performance monitoring

QGIS Desktop and the underlying core library is in constant evolution: map rendering process, data providers, ... But since QGIS 3.0, the map renderer used by QGIS Server is the same as the one used by the desktop application. It's very handy but this also means that QGIS Server rendering time is affected by every changes (the good, the bad and the ugly) made in the core library. However, from a map server perspective, a lost in rendering or data fetching performances might be very troublesome.

How can we easily monitor QGIS Server performances to avoid regressions on the development branch?

It's a very broad question but it raises a basic need: performances monitoring. A project currently exists, named QGIS Server PerfSuite, and the purpose of this proposal is to improve this infrastructure to become a more useful and relevant tool.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/185

Performance tests are already running every night and corresponding scripts are available on the QGIS-Server-PerfSuite repository. Thus, it'll be the starting point.

Both of us are QGIS core committers with a strong experience in QGIS Server development and deployment. Paul Blottiere is maintaining the current performance infrastructure for QGIS Server as well as the corresponding project QGIS-Server-PerfSuite.

It should be done for QGIS 3.16.

hugo.mercier@oslandia.com

Vectorization of selective masking

Avoid forced rasterization of the rendered map when selective masking is enabled.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/186

This proposal enhances the existing feature of "selective masking"

Oslandia is a long term contributor to QGIS. Hugo is the original author of the selective masking feature. Bertrand has been recently involved in some bugfixes around this feature

The implementation can be scheduled for the 3.16 release. Side note: The requested grant amount is not enough to cover the whole task. A complementary (self) investment will be added to fulfill the implementation.