Skip to main content
9 events
when toggle format what by license comment
Jul 27, 2018 at 15:17 vote accept J. Cee
Jul 27, 2018 at 15:17 vote accept J. Cee
Jul 27, 2018 at 15:17
Jul 27, 2018 at 15:17 vote accept J. Cee
Jul 27, 2018 at 15:17
Jul 9, 2018 at 16:53 comment added Jeffrey Evans When you can get away with it, it is faster, processing wise, to operate on objects in memory. If raster is swapping blocks of data it is bound to slow things down. However, this is also a memory asymptote where processing really slows down on very large data. It is not a matter of removing the object, that is just good practice, but rather having a means of processing say, 10 billion observations. This is where the raster package advantage of reading/writing blocks of digestible data becomes very desirable.
Jul 9, 2018 at 16:05 comment added ndimhypervol Thanks for the clarification. So if that is true, can you explain why this function runs much faster than the regular randomPoints() even though getValues() reads the raster into memory? Can't one just rm() the raster out of memory when the function is done?
Jul 8, 2018 at 3:21 comment added Jeffrey Evans On large rasters the raster package uses gdal to read and write blocks for processing. In this way the raster is never fully read into memory. Certain function calls (eg., getValues) force the raster to be read. If you look at @dof1985's answer, it is using the row/column index so, never reads a vector of raster values. However, it also does not account for NA's.
Jul 7, 2018 at 20:54 comment added ndimhypervol Thanks for your reply. Can you explain what you mean by memory-safe, and why the function above would be a problem for a very large raster?
Jul 6, 2018 at 16:39 comment added Jeffrey Evans The reason that it is faster is that you have removed the memory-safe aspects of the function. There is no real problem with that excepting when somebody wants to sample a raster with billions of cells.
Jul 6, 2018 at 16:36 history answered ndimhypervol CC BY-SA 4.0