<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div id=":1c3" class="Am aiL Al editable LW-avf tS-tW tS-tY"
aria-label="Corps du message" role="textbox" aria-multiline="true"
contenteditable="true" style="direction: ltr; min-height: 360px;"
tabindex="1" spellcheck="false" aria-owns=":1ei"
aria-controls=":1ei" aria-expanded="false">
<div dir="ltr">
<div dir="ltr">Hi Sionigdha<br>
<br>
First off congrats to your first PR(s) merged, and taking on
the challenge of a GSoC !<br>
<br>
As Andreas said the missing ogrinfo parameter are already
exposed as an advanced parameter. And you could theoretically
achieve what you want with the "string concatenation" tool in
modeler albeit with more difficulty than what you propose.<br>
Also remember we can't outright remove an existing parameter.
because it would break the API, but it can be set as
deprecated and kept around, see [<a
href="https://github.com/qgis/QGIS/commit/5bde6fec42ccc10b9fd1c4fc822fbe1a4ae05a30#diff-2f887124009e37c4f965e787aee9ac3c82f892ff2472580e037ab546d8369102R191"
target="_blank"
data-saferedirecturl="https://www.google.com/url?q=https://github.com/qgis/QGIS/commit/5bde6fec42ccc10b9fd1c4fc822fbe1a4ae05a30%23diff-2f887124009e37c4f965e787aee9ac3c82f892ff2472580e037ab546d8369102R191&source=gmail&ust=1773172617655000&usg=AOvVaw1ap1IiURifCJdcZau56vvf">1</a>]</div>
<div>But overall I think it's a good idea to have them as
separate parameters.</div>
<div dir="ltr"><br>
> Make ogrinfojson output structured and chainable within
the processing<br>
> framework field count, feature count, geometry type,
extent as named<br>
> outputs<br>
<br>
* I think that's also a good idea to have more outputs like
that in general. One thing that could be improved is that in
the modeler, there is no specific output for extent, or CRS,
we rely on a string output (<br>
`QgsProcessingOutputString`) with a specific format to connect
further in the parameters. I would like to see a One to One
mapping between parameter and output type.<br>
<br>
* Another way you could improve the output of the ogrinfo json
is to take a step back and improve json handling in general in
the processing. with a dedicated output and algorithms : to
flatten json, extract values etc...</div>
<div dir="ltr"><br>
It's up to you which direction you want to go. At the moment I
think it's a bit light to be a GSoC proposal on it's own (And
since you already contributed to GDAL/QGIS you might complete
it too quickly :-) ). But it is good to have your own idea
and I encourage you to build upon it, and to get more
feedbacks on it.<br>
<br>
<div>If you want to lean more on the GDAL side, it is
absolutely fine. But GDAL is not my area of expertise, I
need to dive into the code a bit more myself before giving
you confirmation that I can mentor you on this project. (Or
maybe another person in the community could step in as a
mentor ? )</div>
<br>
Kind regards,<br>
Valentin Buira<br>
<br>
[1] <a
href="https://github.com/qgis/QGIS/commit/5bde6fec42ccc10b9fd1c4fc822fbe1a4ae05a30#diff-2f887124009e37c4f965e787aee9ac3c82f892ff2472580e037ab546d8369102R191"
target="_blank"
data-saferedirecturl="https://www.google.com/url?q=https://github.com/qgis/QGIS/commit/5bde6fec42ccc10b9fd1c4fc822fbe1a4ae05a30%23diff-2f887124009e37c4f965e787aee9ac3c82f892ff2472580e037ab546d8369102R191&source=gmail&ust=1773172617655000&usg=AOvVaw1ap1IiURifCJdcZau56vvf">https://github.com/qgis/QGIS/<wbr>commit/<wbr>5bde6fec42ccc10b9fd1c4fc822fbe<wbr>1a4ae05a30#diff-<wbr>2f887124009e37c4f965e787aee9ac<wbr>3c82f892ff2472580e037ab546d836<wbr>9102R191</a><span></span><span></span></div>
</div>
</div>
<p><br>
</p>
</body>
</html>