Bug report #21516

GRASS r.series: broken as it only considers the first map of multilayer input

Added by Markus Neteler about 1 year ago. Updated about 1 year ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Processing/GRASS
Affected QGIS version:3.6.0 Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:Yes Copied to github as #:29333

Description

r.series is currently only considering the first raster map of the list of input maps.

Example: attached test case of 3 raster layers with values 1, 3, 12 leads when computing the "r.series average" the result 1. This is wrong and the reason appears to be that only the first map in the stack is considered.

testcase_multilayer.tif - multilayer GeoTIFF (North Carolina sample dataset) with 3 raster maps of values 1, 3, 12 (created with r.mapcalc in GRASS GIS and exported to GeoTIFF) (2 KB) Markus Neteler, 2019-03-07 09:52 PM

testcase_value_one.tif (499 Bytes) Markus Neteler, 2019-03-08 02:36 PM

testcase_value_three.tif (499 Bytes) Markus Neteler, 2019-03-08 02:36 PM

testcase_value_twelve.tif (499 Bytes) Markus Neteler, 2019-03-08 02:36 PM

History

#1 Updated by Giovanni Manghi about 1 year ago

  • Status changed from Open to Feedback
  • Subject changed from r.series: broken as it only considers the first map to GRASS r.series: broken as it only considers the first map

Is this about the tool in the processing toolbox or in the GRASS plugin (I guess is the former)?

Does the tool work if instead of a multilayer input you use different input layers?

#2 Updated by Markus Neteler about 1 year ago

Giovanni Manghi wrote:

Is this about the tool in the processing toolbox or in the GRASS plugin (I guess is the former)?

Yes, the tool in processing.

Does the tool work if instead of a multilayer input you use different input layers=

It also fails with separate layers. I have attached then for testing.

#3 Updated by Giovanni Manghi about 1 year ago

  • Category changed from GRASS to Processing/GRASS

It also fails with separate layers. I have attached then for testing.

this is what I see on my machine:

g.proj -c proj4="+proj=lcc +lat_1=36.16666666666666 +lat_2=34.33333333333334 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"

r.external input="/home/giovanni/Downloads/testcase_value_one.tif" band=1 output="rast_5c82851c9860f2" --overwrite -o
r.external input="/home/giovanni/Downloads/testcase_value_three.tif" band=1 output="rast_5c82851c986663" --overwrite -o
r.external input="/home/giovanni/Downloads/testcase_value_twelve.tif" band=1 output="rast_5c82851c986944" --overwrite -o

g.region n=229000.0 s=215000.0 e=645000.0 w=630000.0 res=1000.0

r.series input=rast_5c82851c9860f2,rast_5c82851c986663,rast_5c82851c986944 method="average" range="-1e+8,1e+8" output=outputd59db1a653ea4832a59215aef02756c2 --overwrite

g.region raster=outputd59db1a653ea4832a59215aef02756c2

r.out.gdal -t -m input="outputd59db1a653ea4832a59215aef02756c2" output="/tmp/processing_e91bb38b329144f0bcae672eb1f9a380/9d5939a6d1d54b3da3e7a6632c2ed1da/output.tif" format="GTiff" createopt="TFW=YES,COMPRESS=LZW" --overwrite

and I get an output raster with 5.33333 as value, so is this wrong, confirm?

#4 Updated by Markus Neteler about 1 year ago

Giovanni Manghi wrote:

this is what I see on my machine:

...

and I get an output raster with 5.33333 as value, so is this wrong, confirm?

That looks good as:

(1+3+12)/3 = 5.333333

Does it work for you with the multi-layer file as well? And, which QGIS version did you use?

#5 Updated by Giovanni Manghi about 1 year ago

Does it work for you with the multi-layer file as well? And, which QGIS version did you use?

I tried on 3.6, but I also tried 3.4.5 on Windows.

I think the real issue is that Processing is not designed (yet?) to support such cases of multilayer rasters where each layer must enter as a separate inputs into some tool.

I think we should change the title and description to better reflect that, do you agree?

#6 Updated by Markus Neteler about 1 year ago

  • Subject changed from GRASS r.series: broken as it only considers the first map to GRASS r.series: broken as it only considers the first map of multilayer input

Agreed (title changed). I suggest that the r.series description (or more) in Processing is modified to clearly communicate that separate layers are needed (which is obviously a limitation when it comes to climatic time series).

#7 Updated by Giovanni Manghi about 1 year ago

Markus Neteler wrote:

Agreed (title changed). I suggest that the r.series description (or more) in Processing is modified to clearly communicate that separate layers are needed (which is obviously a limitation when it comes to climatic time series).

what other modules could be affected by this limitation?

#8 Updated by Giovanni Manghi about 1 year ago

Markus Neteler wrote:

Agreed (title changed). I suggest that the r.series description (or more) in Processing is modified to clearly communicate that separate layers are needed (which is obviously a limitation when it comes to climatic time series).

see #21531

#9 Updated by Giovanni Manghi about 1 year ago

  • Resolution set to fixed/implemented
  • Status changed from Feedback to Closed

Markus Neteler wrote:

Agreed (title changed). I suggest that the r.series description (or more) in Processing is modified to clearly communicate that separate layers are needed (which is obviously a limitation when it comes to climatic time series).

closed in favor of #21531

Also available in: Atom PDF