[QGIS-Developer] GSoC 2026 Draft Proposal : JSON Handling Toolkit for the QGIS Processing Framework

Valentin Buira valentin.buira at gmail.com
Tue Mar 17 04:44:00 PDT 2026


Hi Sionigdha,

I concur with Nyall on the technical part, new algorithms require a c++
implementation, thought you don't have to write a json parser from scratch,
take a look at how json is handled in Qt [1]

On  another note, I know you were initially interested in GDAL, but you run
the risk to have a "two headed proposal" . Maybe changing the input
parameters of GDAL algorithms is not the core of your proposal ? And more
JSON integration / algorithms would be more suitable for the proposal ?

>  Just FYI you'll need to submit a QEP before doing any of this work --
see https://github.com/qgis/QGIS-Enhancement-Proposals.

An accepted QEP would certainly weigh in your favor for your proposal. But
the deadline for submission of the GSoC is on 31 March, which makes it
really tight for the QEP process to go through.

When I advertised GSoC[2] I did not mention the QEP process, and I would
prefer not changing the requirements midway.



Lastly a note for potential mentors and the QGIS maintainers :

The articulation between GSoC and QEP needs to be clarify:

* Historically on the last two GSoC proposals we had  (2024 and 2019),
there were no QEP
* OSGeo requires it's own template for a proposal that is different from
our QEP
* I'd like to keep GSoC as a space of freedom of experimentation, sandbox
for idea etc... which could clash with the consensus nature of the QEP
* But... At the same time a GSoC without a QEP runs the risk of not getting
merged in the end.
* When I wrote the GSoC ideas this year I took care of not diving into
technical details nor writing a QEP because I believe it's the student's
job to write it and gain insight of the source code from it.
* Do we want students to invest time in a QEP while they are not sure of
being accepted ? Or just improve their initial proposal instead ? Should we
reserve the QEP for the community bounding periods ?

 Maybe we could change the GSoC process for next year ? Any thoughts on
this @Nyall ?

Kind regards,
Valentin

[1] https://doc.qt.io/qt-6/json.html
[2] https://github.com/qgis/QGIS/wiki/Google-Summer-of-Code-2026-Ideas

Le mar. 17 mars 2026, 07:00, Nyall Dawson <nyall.dawson at gmail.com> a écrit :

>
>
> On Tue, 17 Mar 2026 at 15:52, Sionigdha Sadhukhan via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>
>> Hello,
>>
>> I’ve prepared a draft of my GSoC proposal for improving JSON handling in
>> the QGIS Processing framework and wanted to share it here and
>> recieve your valuable feedback.
>>
>> I’ve attached the current version.I tried to incorporate the earlier
>> suggestion about looking at JSON handling more broadly in the processing
>> framework rather than focusing only on the ogrinfo parameters. If
>> there’s anything that seems unclear, unrealistic, or that should be
>> approached differently, I would really appreciate any feedback.
>>
>
> Thanks for sending this through Sionigdha!
>
> Just FYI you'll need to submit a QEP before doing any of this work -- see
> https://github.com/qgis/QGIS-Enhancement-Proposals. One sticking point
> that stood out to me is that you're proposing to implement the new
> algorithms in Python. That's explicitly blocked now, we want all new
> algorithms to be written in c++ (unless they rely on a specific python
> library).
>
> Kind regards,
> Nyall
>
>
> Thanks for your time.
>>
>> Kind regards,
>> Sionigdha.
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260317/fd3ed658/attachment.htm>


More information about the QGIS-Developer mailing list