<div dir="ltr"><div>I'm working on this in the spare time... btw I'm not sure if this is a good work to do.</div><div>I face the problems described by Rudi, because gdal_calc has some limitations working with not homogeneous rasters... this doe not not affect the native raster calculalator. BTW raster calculator has a "old" and "not standard" syntax whilst gdal_calc can use all the numpy power (that's a really big difference)</div><div><br></div><div>adding operators in raster calculator need c++ coding, doing in gdal_calc is not necessary (numpy is enough)</div><div><br></div><div>I know that some power users are stuk to 2.18 for the lack r.calc in grass7 integration in qgis (that seems will be solved soon)</div><div><br></div><div>My question (poll) is... does it make sense to patch native raster calc instead of override gdal_calc limitation?</div><div>Make sense to solve raster calculator bug only if these bugs are generic and does not depend of the specific organization of the raster calculator GUI.</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Luigi Pirelli<br><br>**************************************************************************************************<br>* LinkedIn: <a href="https://www.linkedin.com/in/luigipirelli" target="_blank">https://www.linkedin.com/in/luigipirelli</a><br>* Stackexchange: <a href="http://gis.stackexchange.com/users/19667/luigi-pirelli" target="_blank">http://gis.stackexchange.com/users/19667/luigi-pirelli</a><br>* GitHub: <a href="https://github.com/luipir" target="_blank">https://github.com/luipir</a><br>* Mastering QGIS 2nd Edition:<br>* <a href="https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition" target="_blank">https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition</a><br>* Hire me: <a href="http://goo.gl/BYRQKg" target="_blank">http://goo.gl/BYRQKg</a><br>**************************************************************************************************</div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 29 Jun 2018 at 22:35, Rudi von Staden <<a href="mailto:rudivs@gmail.com">rudivs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'm trying to make some updates to qgis:rastercalculator in processing<br>
to make it work better in models. The raster calculator evaluates<br>
expressions based on the source file name. The problem with using this<br>
in the model builder is that the file names are not always known up<br>
front.<br>
<br>
The list of layers in the expression widget are of class<br>
QgsProcessingModelChildParameterSource, so I'm trying to figure out<br>
how to set an appropriate source name for different situations.<br>
<br>
1. The layer is an input parameter<br>
In this case there's no way to know the source name up front, but it<br>
could be approximated by lyr.parameterName(). This assumes that the<br>
parameterName and the source name of the layer are the same. It's a<br>
bit of a stretch, but I can't think of a better way to do it.<br>
<br>
2. The layer is an anonymous layer output by another algorithm<br>
In this case the name of the output file can be known for certain from<br>
lyr.outputName(). This adds another problem though, since most<br>
algorithms have the same outputName ('OUTPUT'). I have worked around<br>
this by adding an incrementing number to the end of the index (i.e.<br>
OUTPUT, OUTPUT1, OUTPUT2, etc.). It's not perfect but at least then<br>
there would be a viable way to build expressions with multiple inputs.<br>
<br>
3. The layer is a named output from another algorithm<br>
If the algorithm has a named output, then the source file name would<br>
be a predictable composite of lyr.outputChildId() and the 'Parameter<br>
name'. I expected to get this from lyr.outputName() once set, but it<br>
seems that outputName is not updated (it remains OUTPUT for most<br>
algorithms). Is there some other way to get the 'Parameter name'<br>
string from QgsProcessingModelChildParameterSource (or some other<br>
way)?<br>
<br>
Handling these three situations would improve the situation, but it's<br>
still a bit clunky (and complicated for users to understand). Another<br>
option would be to forego the source() names altogether, and use an a,<br>
b, c notation like many of the other raster calculators do. The<br>
challenge then is to have the layer identifiers in the expression<br>
builder match the layer identifiers that are passed to<br>
QgsRasterCalculator. One way to achieve this would be to have the<br>
'Layers' list in the expression builder show only layers that are<br>
selected as 'Reference layers'. That way, only the layers that are<br>
passed to Raster Calculator as parameters could be included in the<br>
expressions, and there can be a consistent referencing pattern whether<br>
you are using it as a standalone algorithm or in a model. I'm just not<br>
sure how to get the list of selected Reference layers from inside<br>
ExpressionWidgetWrapper. If there's interest in reworking it in this<br>
way and somebody can point me in the right direction I'd be happy to<br>
give it a go.<br>
<br>
Some background to this here: <a href="https://issues.qgis.org/issues/19302" rel="noreferrer" target="_blank">https://issues.qgis.org/issues/19302</a><br>
<br>
Kind regards,<br>
Rudi<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>