Bug report #19302

[processing] Modeler and Raster Calculator fail to calc

Added by Luigi Pirelli about 2 years ago. Updated about 2 years ago.

Assignee:pablotcarreira -
Affected QGIS version:3.2 Regression?:Yes
Operating System:Linux, Win Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:27130


2 issues here. I'm working on that , but I open it because probably Nyall can solve faster than me.

context: Raster Calculator added in a Processing model + 1 rasters as input

1) Expression in Raster Calculator widget shows the Layer object and not the layer name
issue is here:
should be:
"lyr.parameterName()" instead of "lyr"
Check if in https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/qgis/ui/RasterCalculatorWidgets.py#L220
have to use tghe same code (or a lambda) as in

2) Running the model with expression "<input raster>@1" e.g. copy the input raster in the output => generate always a float raster with [-1.7:1.7]
this happend for every expression you can set

raster_calculator.PNG (16.3 KB) Rudi von Staden, 2018-06-29 11:52 AM

rastercalculator_test.zip (709 KB) Rudi von Staden, 2018-06-29 02:49 PM

Associated revisions

Revision 580ecafa
Added by Luigi Pirelli about 2 years ago

Merge pull request #7396 from luipir/rastercalculator_model_fix

[processing] Rebirth RasterCalculator in Modeler. Fixes #19302


#1 Updated by Luigi Pirelli about 2 years ago

nyall feel free to assign to me, I assigned to you just to ping you and if you can drive me faster where is the problem

#2 Updated by Rudi von Staden about 2 years ago

I just ran into this issue myself. I can confirm that the fix suggested works for simple models where it's a direct input to the raster calculator. It doesn't work when the input to the raster calculator is the output from another algorithm (in that case the expression resolves to "@1").

In the attached screenshot, the 'Output' file is generated correctly, but lyr.parameterName() is empty for the "'Output' from algorithm 'Raster calculator'" layer.

#3 Updated by Luigi Pirelli about 2 years ago

tnx @rudi for the test and confirmation

#4 Updated by Rudi von Staden about 2 years ago

I've done a bit more testing, and it seems it worked because the layer name in the layer index of the project and the parameter name were coincidentally the same. If they are different, it won't work.

I have also found that using "[email protected]" works if you add the input layer as a 'Reference layer', but if you are using two 'output' layers as input, then I'm not sure how to resolve it.

I've attached a test project if anyone wants some input data to test. I included a sample model which demonstrates some of the problems.

#5 Updated by Luigi Pirelli about 2 years ago

really useful to replicate different kind of problems, really tnx

#6 Updated by Rudi von Staden about 2 years ago

Glad to help, @luigi. There's a related issue at

layersDict = {os.path.basename(lyr.source().split(".")[0]): lyr for lyr in layers

The layer indexing is based on the file name. Most algorithms use OUTPUT as the file name, which means you won't be able to reference more than one of them in the raster calculator. I have a way to resolve that, but I don't think it's a perfect solution because it would be hard to predict in the Expression builder:

layersDict = {}
def _lyrIndex(lyrName):
lyrIndex = lyrName
lyrNumber = 0
while lyrIndex in layersDict:
lyrNumber +=1
lyrIndex = f"{lyrName}{lyrNumber}"
return lyrIndex
if layers:
for lyr in layers:
name = _lyrIndex(os.path.basename(lyr.source().split(".")[0]))
layersDict[name] = lyr

I'm not sure if this should be reported as a separate issue? I also have some broader thoughts on how to improve the Raster calculator for use in models, which I've sent to the qgis-developer list (also not sure where's the best place for such discussions).

#7 Updated by Luigi Pirelli about 2 years ago

  • Assignee changed from Nyall Dawson to pablotcarreira -
  • Pull Request or Patch supplied changed from No to Yes

#8 Updated by Luigi Pirelli about 2 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

#9 Updated by Giovanni Manghi about 2 years ago

  • Resolution set to fixed/implemented

Also available in: Atom PDF