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