[R-sig-Geo] Brick and Stack in package raster

Robert J. Hijmans r.hijmans at gmail.com
Sat Nov 27 21:16:59 CET 2010

Hi Agus,

You are right, thanks for this correction. You can set the band-order
for native formats via the 'bandorder' argument (with BIL as default),
but this is ignored for other formats (that was not in the docs). For
the gdal formats that support different types of band interleaving,
you can use an options=c(" ") argument and pass valid gdal options.
E.g. to write band interleaved GTIFF files (with x being a RasterStack
or RasterBrick)

x <- writeRaster(x, filename='test.tif', options="INTERLEAVE=BAND")


On Sat, Nov 27, 2010 at 3:14 AM, Agustin Lobo <alobolistas at gmail.com> wrote:
> Thanks
> Just noting that you also have BIL for envi format and that
> BIP seems to be the default for geotiff (at least that's what gdalinfo
> reports for
> tif files written by writeRaster() :
> Image Structure Metadata:
> Also, I understand that the order is BIL also when brick() writes a
> file by default (i.e. /tmp/R_raster_tmp/raster_tmp_789131022710.grd)
> Agus
> 2010/11/26 Robert J. Hijmans <r.hijmans at gmail.com>:
>> On Fri, Nov 26, 2010 at 2:25 AM, Agustin Lobo <alobolistas at gmail.com> wrote:
>>> Robert,
>>> At some point you made this comment:
>>>>>> (as you are dealing with large
>>>>>> files, I think it is more efficient to first make a stack and then
>>>>>> write the results to a brick)
>>> But I have some doubts:
>>> bN = brick(N1,N2,N3,...,N72)
>>> where
>>> N1 = raster(paste(midir,"NDV_19990101__Extract.img",sep="")) etc
>>> takes a very long time. Is a file on disk being written somewhere?
>> That is why I am saying that it is better to do
>> sN = stack(N1,N2,N3,...,N72)
>> and then, perhaps,
>> bN <- brick(sN )
>> But that is probably not worth it. I may change a few things in the
>> code and manual to make this go smoother.
>> I think the approach is to always makes a stack if you have separate
>> files and a brick if it is a single file. Adding a layer to a brick
>> should perhaps result in a stack. Computations on a stack/brick always
>> result in a brick (single file if on disk)
>>> Is overlay() going to be any faster with brick than with stack objects? ie:
>>> bNv2 <- overlay(bN, bSM,
>>> fun=fun1,filename="bNv2.tif",overwrite=TRUE,NAflag=0) faster than
>>> sNv2 <- overlay(sN, sSM, fun=fun1,filename="sNv2.tif",overwrite=TRUE,NAflag=0) ?
>>> (bN, bSM, brick objects; sN, sSM, stack objects)
>> Yes, I would think that would be faster with a brick, because the data
>> need to come out of a single object/file (i.e. 72 times fewer files
>> need to be opened and closed). But I am not sure if it is worth it to
>> first make a brick from the stack, because that also takes time.
>>> When you write a brick to a file, can you control if the resulting
>>> file is going to be BSQ or BIL?
>> Yes, but only for the native format (not when writing via rgdal, e.g.
>> GeoTIFF). BIL is default and should work. BIP is rather inefficient
>> except for extracting point values. BSQ best for extracting single
>> layers.
>>> Are the files written by writeRaster() identical for stack and brick objects?
>>> writeRaster(bNv2,
>>> filename="bNv2b.tif",overwrite=TRUE,format="GTiff",datatype='INT2U',NAflag=0)
>>> writeRaster(sNv2,
>>> filename="sNv2b.tif",overwrite=TRUE,format="GTiff",datatype='INT2U',NAflag=0)
>> Yes, always writes a single file (brick object).
>>> Thanks
>>> Agus
>> Cheers, Robert
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

More information about the R-sig-Geo mailing list