The QGIS project would like to participate in the Google Summer of Code 2026 under the umbrella of OSGeo.

This page references ideas which have sparked interest from potential mentors in the community. But they are not the only GSoC ideas possible, feel free to come up with an idea on your own from your areas of interest.

Introduce non destructive workflow : Add "processing layer" in QGIS

Mentoring

Expected outcome:  a new "processing layer"
Skills required: C++/Qt
Mentors: Valentin Buira (@ValentinBuira on github), Denis Rouzaud (@3nids)
Difficulty:  Hard
Time : ~ 350 hours

Introduction

QGIS already has an extensive set of processing algorithms. However once an algorithm is executed the only way to modify its result is to re-run the algorithm altogether. The idea of this GSoC is to introduce a much more flexible way to run algorithm and edit the result through a new non-destructive layer called a “processing layer” and its associated data provider

A processing layer like a virtual layer, would be a special kind of layer. It allows you to define a layer as a result of a geo process involving another map layer in your QGIS project.

If you used the processing framework to do spatial analysis you know how your project can quickly be flooded with temporary output from the previous processing algorithm run. This GSoC project would short circuit the issue.

Why it's different from the current approach in processing framework:

• Compared to memory output, the underlying process to generate the processing layer can still be edited even after the generation of the layer.
• Compared to memory output, here If you modify the underlying data the processing layer is updated like a virtual layer
• Compared to edit in place, once an edit in place algorithm is applied the data before the transform are lost. Here the underlying layer data is kept as is.

If you are familiar with other software or want to draw some inspiration. This would be kinda similar to :

• Blender modifier
• Inkscape Live path effect
• Illustrator effect

So a processing layer data would only reflect the results of the processing. Thus they would not be editable.

Quick and dirty mockup

How to craft your proposal

This GSoC idea is not an easy task. It requires understanding multiple independent parts of the QGIS source code.

Your technical proposal needs to prove your understanding of the stakes, and provide a detailed plan on how you want to lead your proposal to completion.

Ideally at the end of your GSoC you should have a merge ready PR. It is better to have a minimal viable product rather than a half baked product, so try to construct your proposal in a way it's easy to have further improvements to build on top of your initial work. It's okay to split this suggestion idea to have a smaller scope in your final proposal.

Give your own touch to the mockup in these suggestions, as they are only here to give a glimpse of the possible UI.

Be proactive in your proposal, even if they are designated mentors. QGIS is an open project and discussions, questions should happen on the developer mailing list.

Catch to keep in mind for this proposal

• Only processing algorithm that don't have side effects would be allowed. e.g: They don't modify a file on your system or your qgis project. A good starting point would be algorithms that support "In place editing" but a new flag or function to know if it has side effects could be introduced.
• Since processing algorithm can produce multiple kind of layer like Vector layer or a Raster Layer, some code would be required to differentiate the type of layer instantiated, maybe it would turn out to be a non issue if the type is known in advance but the technical part of the proposal could clear this up.
• The processing layer needs to be updated appropriately when the other map layers it depends on are changed.
• Since the processing layer relies on other layers. Two processing layers CANNOT have a dependency loop with each other. Otherwise you would have an infinite update loop
• For model processing model and script processing take care if they are changed
• Error handling, if the algorithm fails, how do you communicated errors to the users ?
• You will need to store the result of an algorithm, and cache it to avoid needless recalculations

Reference from previous years:

In QGIS:

Ismail Sunni QGIS 3D improvement : https://docs.google.com/document/d/1RcXiEyziQyGurqDGRBN3g-het33liVD81WFjv8qQlt8/edit?usp=sharing

My own QGIS GSoC proposal model designer improvement https://docs.google.com/document/d/1iXHMTylTHLljfHBITfuIfJzi4_4hpQifEvj5GkM8OCc/edit?tab=t.0 and my post mortem on it https://lists.osgeo.org/pipermail/qgis-developer/2024-May/066764.html

From OSGEO:

https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2025_Ideas

Exercises:

A good understanding of processing would be required.

Language would be c++ and Qt library would be nice

Few exercises are possible to get your feet wet. Not all of them are required but the exercises follow multiple objectives:

• Prove than you can build QGIS, navigate the code, and submit a pull request
• Give you a rough idea of the amount of work needed to time estimate your proposal.
• Give you a first hand experience on the area of the QGIS source code you most likely are going to modify

Exercices

0. Build QGIS (mandatory)

Follow the instruction on install.md to build QGIS

1. Create a new algorithm

Add a new process algorithm, for example, there is a missing "Layer properties" that would have outputs similar to the layer_properties expression

Could also be in python and uploaded to hub.qgis.org as a processing script

2. Try one of the good first issue

This is a moving list, so if available at the time of your proposal you could try one of the good first issue

3. Try to add a data placeholder data provider

This one doesn't have to be a fully finished PR, but this would help when you start the actual work