[R-sig-Geo] bug in raster::stackApply when raster not in memory

Bastien.Ferland-Raymond at mffp.gouv.qc.ca Bastien.Ferland-Raymond at mffp.gouv.qc.ca
Fri Nov 11 17:50:50 CET 2016


Dear list,

I think I've found a bug with the stackApply() function of the raster package.  The bug was already pointed out at : 
http://r-sig-geo.2731867.n2.nabble.com/raster-stackApply-problems-td7589291.html

It says that it was fixed, however I think it wasn't 100% fixed.  I've experienced the same problem with a raster the isn't in memory.

Here an example.  (I'm sorry you have to download files, I've couldn't manage to reproduce the problem with R-made rasters)

################

## download these four rasters:
https://www.dropbox.com/sh/aoxou1qiqxdiskk/AAAMHeDio6FW6eLDqjMshP2Ka?dl=0

library(raster)

sta <- stack("G:\\ layer_1.tif","G:\\ layer_2.tif","G:\\ layer_3.tif","G:\\ layer_4.tif")

indices <- c(1,2,2,3)
stackApply(sta, indices, fun=sum)  

indices <- c(3,2,2,1)
stackApply(sta, indices, fun=sum)

##  If you compare the max-min, you'll see it's not the same between the two calls of stackApply(). 
##  However, the way the function is described in the help, only the names should be different, not the max-min

##  Interestingly, this problem doesn't happen if we crop the file small enough the stack become in memory

e <- extent(-515000,-460000,635420,708890)
sta.crop <- crop(sta,e) 

indices <- c(1,2,2,3)
stackApply(sta.crop, indices, fun=sum)  ### This one works fine!

indices <- c(3,2,2,1)
stackApply(sta.crop, indices, fun=sum)

##  This time is the same (and good) results between the two calls!

##############

BTW, I'm using R 3.3.2 64bits and the latest raster package version from CRAN.

Is it really a bug or I'm doing something wrong?

Thanks for your help,

Bastien Ferland-Raymond
Division des orientations et des projets spéciaux
Direction des inventaires forestiers
Ministère des Forêts, de la Faune et des Parcs



More information about the R-sig-Geo mailing list