[QGIS-Developer] GSoC 2026 — Enhancing ogrinfo Processing Algorithms in QGIS
Sionigdha Sadhukhan
snigdha.lee75 at gmail.com
Thu Mar 12 23:16:50 PDT 2026
Hi all,
Following up on my previous email , I’ve put together a rough draft
proposal following the JSON handling direction Valentin suggested. Happy to
share it here or however is most convenient if early feedback would be
useful before I submit on the portal.
Best,
Sionigdha
On Tue, 10 Mar 2026 at 10:32 PM, Sionigdha Sadhukhan <
snigdha.lee75 at gmail.com> wrote:
> Hi Valentin,
>
> Thank you ,and thank you to Andrea as well. You're both right that EXTRA
> is available as an advanced parameter in models. I overstated the problem
> and will correct that framing.
>
> Your point about scope is also fair. I've been thinking about the
> direction you mentioned in improving JSON handling in the processing
> framework more generally and I think that's the right way to expand this.
> The rough shape I'm exploring:
>
> - Extend ogrinfo/ogrinfojson: expose the missing typed parameters
> (-where, -fid, -sql, -spat, -geom, -fields, -limit) as proper inputs
> alongside EXTRA rather than replacing it
> - Add JSON handling algorithms to the processing framework along the
> lines of: LoadJSONFile (bring JSON data into a model), ExtractJSONValue
> (pull a specific value by key path for use in downstream steps),
> JSONToLayer (convert a JSON array to a vector layer with attributes)
> - ogrinfo jason's structured outputs feature count, geometry type,
> extent would serve as the first concrete demonstration: pipe the JSON
> output into ExtractJSONValue, feed the result into a conditional branch in
> the model
>
> Since this direction is entirely Python and the processing framework, no
> GDAL internals.I wanted to check whether you'd be comfortable mentoring it,
> or whether you'd suggest someone else in the community to approach.
>
> Happy to share a rough outline before writing a full draft.
>
> Best, Sionigdha
>
> On Mon, 9 Mar 2026 at 16:09, Sionigdha Sadhukhan <snigdha.lee75 at gmail.com>
> wrote:
>
>> Hi Valentin,
>>
>> My name is Sionigdha and I'm interested in contributing to QGIS through
>> GSoC 2026.
>>
>> While exploring the QGIS codebase I looked at OgrInfo.py in the GDAL
>> processing algorithms and noticed that several GDAL ogrinfo capabilities
>> are not exposed as typed parameters specifically -fid, -where, -spat,
>> -geom, -fields, and -limit. Users currently have to use the raw EXTRA
>> string field to access these, which is undiscoverable and unusable in
>> processing models.
>>
>> This caught my attention because I've been contributing to GDAL for the
>> past 3 months with multiple merged PRs including #13904 (adding --fid to
>> gdalinfo/GDALVectorInfo, merged in GDAL 3.13.0), #13812 (WMS/WMTS
>> network-dependent test improvements), and several documentation fixes. Full
>> list:
>> https://github.com/OSGeo/gdal/pulls?q=author%3ASionigdha+is%3Amerged
>>
>> I've also been contributing directly to QGIS including PR #64620 (merged
>> into QGIS 4.0.0) clarifying QgsLogger behavior, and several other
>> documentation PRs targeting 4.0.0. Full list:
>> https://github.com/qgis/QGIS/pulls?q=author%3ASionigdha+is%3Amerged
>>
>> I'm currently working on building QGIS from source as per Exercise 0 my
>> machine has hardware constraints but I'm working through them.
>> I've been working on a prototype patch that adds -where, -fid, and -spat
>> as proper typed parameters to both ogrinfo and ogrinfojson, happy to share
>> it shortly.
>>
>> My proposed project for GSoC would be:
>> 1. Expose all missing ogrinfo parameters as typed, modelable inputs in
>> both ogrinfo and ogrinfojson
>> 2. Make ogrinfojson output structured and chainable within the processing
>> framework field count, feature count, geometry type, extent as named
>> outputs
>> 3. Add a new ogrfeatureinfo processing algorithm that takes a layer + FID
>> or WHERE clause and returns structured per-feature output field values,
>> geometry type, WKT usable as inputs in processing models
>> 4. Full test coverage for all additions targeting QGIS 4.x
>>
>> I'm comfortable in Python and PyQGIS, and I understand this targets QGIS
>> 4.x with GDAL 3.13.0 as the baseline — which aligns directly with my GDAL
>> work.
>>
>> Would you be open to discussing this as a GSoC 2026 proposal?
>>
>> Best,
>> Sionigdha Sadhukhan
>> GitHub: https://github.com/Sionigdha
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260313/fc2712ab/attachment.htm>
More information about the QGIS-Developer
mailing list