<div><div dir="auto" style="font-size:inherit">Hi all,<br style="font-size:inherit">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.<br style="font-size:inherit">Best,<br style="font-size:inherit">Sionigdha</div><br></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 10 Mar 2026 at 10:32 PM, Sionigdha Sadhukhan <<a href="mailto:snigdha.lee75@gmail.com">snigdha.lee75@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p>Hi Valentin,</p>
<p>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.</p>
<p>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:</p>
<ul>
<li>Extend ogrinfo/ogrinfojson: expose the missing typed parameters (-where, -fid, -sql, -spat, -geom, -fields, -limit) as proper inputs alongside EXTRA rather than replacing it</li>
<li>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)</li>
<li>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</li>
</ul>
<p>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.</p>
<p>Happy to share a rough outline before writing a full draft.</p>
<p>Best, Sionigdha</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 9 Mar 2026 at 16:09, Sionigdha Sadhukhan <<a href="mailto:snigdha.lee75@gmail.com" target="_blank">snigdha.lee75@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Valentin,<br><br>My name is Sionigdha and I'm interested in contributing to QGIS through GSoC 2026.<br><br>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.<br><br>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: <a href="https://github.com/OSGeo/gdal/pulls?q=author%3ASionigdha+is%3Amerged" target="_blank">https://github.com/OSGeo/gdal/pulls?q=author%3ASionigdha+is%3Amerged</a><br><br>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: <a href="https://github.com/qgis/QGIS/pulls?q=author%3ASionigdha+is%3Amerged" target="_blank">https://github.com/qgis/QGIS/pulls?q=author%3ASionigdha+is%3Amerged</a><div><br></div><div>I'm currently working on building QGIS from source as per Exercise 0 my machine has hardware constraints but I'm working through them. </div><div>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. <br><br></div><div>My proposed project for GSoC would be:<br>1. Expose all missing ogrinfo parameters as typed, modelable inputs in both ogrinfo and ogrinfojson<br>2. Make ogrinfojson output structured and chainable within the processing framework field count, feature count, geometry type, extent as named outputs<br>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<br>4. Full test coverage for all additions targeting QGIS 4.x<br><br>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.<br><br>Would you be open to discussing this as a GSoC 2026 proposal?<br><br>Best,<br>Sionigdha Sadhukhan<br>GitHub: <a href="https://github.com/Sionigdha" target="_blank">https://github.com/Sionigdha</a></div></div>
</blockquote></div>
</blockquote></div></div>