<div dir="ltr"><p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">Hi Valentin,</p>
<p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">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 class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">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 class="gmail-[li_&]:mb-0 gmail-[li_&]:mt-1 gmail-[li_&]:gap-1 gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:last-child)_ol]:pb-1 gmail-list-disc gmail-flex gmail-flex-col gmail-gap-1 gmail-pl-8 gmail-mb-3">
<li class="gmail-whitespace-normal gmail-break-words gmail-pl-2">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 class="gmail-whitespace-normal gmail-break-words gmail-pl-2">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 class="gmail-whitespace-normal gmail-break-words gmail-pl-2">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 class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">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 class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">Happy to share a rough outline before writing a full draft.</p>
<p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">Best, Sionigdha</p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 9 Mar 2026 at 16:09, Sionigdha Sadhukhan <<a href="mailto:snigdha.lee75@gmail.com">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>