[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