projectRaster 消耗太多內存

Question

我正在用 R 做一些空間方面的事情，突然之間我的一些代碼將不再在我使用多年的計算機上運行，​​特別是因為它“內存不足”。

## Raster going in
xx <- raster(fatNames[[i]])
xx
class       : RasterLayer 
dimensions  : 5160, 14436, 74489760  (nrow, ncol, ncell)
resolution  : 0.008333333, 0.008333333  (x, y)
extent      : -172.3, -52, 23.5, 66.5  (xmin, xmax, ymin, ymax)
coord. ref. : +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0 
data source : D:\Dropbox\wintor_aux\Results\myluFatReq_100_2_fat.inf.tif 
names       : myluFatReq_100_2_fat.inf 
values      : 0.1831425, 3.449095  (min, max)

## transform
x.rast <- projectRaster(xx,crs = CRS("+init=epsg:2955"))

錯誤：無法提供足夠的 4.2Gb 向量。

現在我知道這是一個大小合適的光柵（輸入光柵大小：75.5 MB）但是機器有 32Gb 的 RAM，沒有其他程序在運行，我仍然占用內存。 多年來，我已經做了數百次這樣的事情，據我所知，自從我大約一個月前做這件事以來，機器上的任何東西都沒有改變。

我試過重新啟動會話，重新啟動計算機並在谷歌上搜索了一下，但我仍然沒有任何運氣試圖追蹤問題。 當我在具有 1/2 RAM 的機器上嘗試相同的代碼塊時，我可以毫無問題地運行它（最大使用 ~ 8Gb ram）。 有沒有人對我如何解決這個問題有任何建議？

> sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=English_New Zealand.1252  LC_CTYPE=English_New Zealand.1252   
[3] LC_MONETARY=English_New Zealand.1252 LC_NUMERIC=C                        
[5] LC_TIME=English_New Zealand.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] raster_2.6-7         rgdal_1.3-3          sp_1.3-1             sf_0.6-3            
[5] RevoUtils_11.0.1     RevoUtilsMath_11.0.0

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.18    lattice_0.20-35 class_7.3-14    grid_3.5.1      spData_0.2.9.0 
 [6] DBI_1.0.0       magrittr_1.5    e1071_1.7-0     units_0.6-0     tools_3.5.1    
[11] yaml_2.2.0      compiler_3.5.1  classInt_0.2-3 

Answer 1

您應該首先將柵格包更新為其當前 (CRAN) 版本。 這可能會解決這個問題。 如果沒有，這可能是一種極端情況，您應該能夠通過將內存參數設置為較低的值來解決該問題。 在當前版本中，您可以執行rasterOptions(memfrac=.3) 。 在當前和舊版本中，您可以嘗試rasterOptions(maxmemory=1e+08)

順便說一句，鑒於輸入數據的經度跨度為 (172.3 - 52) = 120 度 --- UTM，您轉換為+proj=utm +zone=11 （請不要在示例中使用 espg 代碼）似乎相當可疑對大約 6 度的跨度有效。