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

[Sionigdha Sadhukhan]

Subject: Re: GSoC 2026 Draft Proposal : JSON Handling Toolkit for the QGIS
Processing Framework

Hi Valentin,
Thank you for the detailed feedback it's very helpful, and thanks for
guiding through.
The point about the two-headed proposal makes complete sense. I've already
started reworking the proposal to make the JSON toolkit the clear centre of
gravity. The ogrinfo typed parameter work is out I'm replacing those weeks
with 2 additional JSON algorithms (JSONFromAttributes and MergeJSONArrays),
bringing the total to 6 C++ algorithms that together cover the full JSON
data lifecycle inside a QGIS model.On the QEP I understand the timing issue
you raised and appreciate you flagging it. I'll draft the QEP during the
community bonding period and submit it for community review before coding
begins, so it doesn't block the proposal submission if that is fine?
I also went through the Qt JSON documentation you linked. The
implementation plan is built entirely around Qt's built-in JSON classes
QJsonDocument, QJsonObject, QJsonArray, and QJsonValue no third-party
libraries needed.
I'll share the updated proposal with you .Please let me know if there's
anything else you'd like me to address.
Kind regards,
Sionigdha

On Tue, 17 Mar 2026 at 17:14, Valentin Buira <valentin.buira at gmail.com>
wrote:

> 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/20260318/02f2f0bd/attachment-0001.htm>