特别是，我感兴趣的是是否有必要将栅格（例如GEOTIFF文件）转换为其他格式（例如netCDF）？加快读/写和其他操作。
#1 楼
这是我的一篇老博客文章，着眼于文件大小和格式访问时间。我没有调查写入速度，只是访问时间。我想说它们可能是直接相关的，但无法为其担保。文章摘要：Packbits似乎为您提供了最佳的访问时间（以磁盘空间为代价） ，而Deflate为您提供对中/小文件的中/慢访问时间。此外，您可以通过创建各种大小的缩略图并确定需要花费多长时间来更经验地测试访问时间。示例命令：
time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file> 假设在这种情况下，与R有关的唯一事情是，它可以像读取其他任何进程一样快地从文件中读取数据，那么这应该给您一个很好的指示。
评论
+1为链接的文章，但是重要信息不在现场，如果该页面出现故障或移动，该信息将丢失给我们。我建议给出文章的总结性结论，以便在无法使用该页面的情况下，即使是暂时的，读者也可以使用它们进行将来的研究和思考。谢谢！
–马特·威尔基
2011年9月6日19:22
很公平！ Packbits似乎为您提供了最佳的访问时间（以磁盘空间为代价），而Deflate则为您提供了对中/小文件的中/慢访问时间。此外，您可以通过创建各种大小的缩略图并确定需要花费多长时间来更经验地测试访问时间。示例命令：“ time gdal_translate -outsize <缩略图尺寸> -of GTiff <压缩图像文件> <缩略图文件>”
–R Thiede
2011年9月7日下午6:21
谢谢！我将摘要汇总到答案本身中，以使其更加独立（请参见每个答案/问题左下方的编辑链接）。
–马特·威尔基
2011年9月7日在18:57
@RThiede有一个有效的担忧：现在看来，指向博客的链接不再有效了吗？
–马蒂富
17年6月21日在18:27
@RThiede您的链接已死，可以提供一个新链接吗？
– Majid Hojati
18年2月11日在7:34
#2 楼
对于读/写操作，您可以使用system.time（）测试这些操作的速度。这是将R（光栅包）中的DEM文件加载为四种格式（ASCII，IMG和TIF，无压缩和压缩）的结果。例如，在〜26MB的栅格上：> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
user system elapsed
0.154 0.002 0.157
'Elapsed'给出了操作花费的总时间（秒）。每次运行10次并查看平均经过时间：
mean diff
ASC 0.2237 0.3317
IMG 0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none 0.1495 0.0000
tif-pack 0.1513 0.0118
没有压缩的TIFF是最快的...紧随其后的是Deflate（慢0.1％）和TIFF-Packbits（慢1.8％），然后是IMG（慢3.2％）和ASC（慢33％）。 （这是在具有SSD的Macbook Pro 2.4 GHz上，因此可以快速进行磁盘操作）
这仅仅是加载文件，而不是对其进行操作。
#3 楼
也许实际上不是哪个栅格图像格式具有更好的打开基准的问题，而是哪个栅格图像格式是最有效的栅格源格式，用于打开和读取作为R数值数组的输入。然后，假设您将结果输出回栅格，这是R中最有效的输出格式。无论哪种方式，如果您要在R中使用栅格，您可能会使用rgdal和R ncdf软件包来补充R raster软件包中包含的内容。主要依靠gdalwarp命令。需要在那里计算格式依赖性，以便选择栅格。您会在SO以及各种OSGEO和R论坛/博客/ wiki上找到相当多的报道。
但是由于这是一个GIS论坛，其中Python的使用相对优势，我将指出在Python numpy数组中使用栅格数据有很多优点，并且对gdal库的栅格加载，转换和导出的依赖性类似。有些人发现Python中的内存管理和代码结构优于本机R-也许看看RPy2或PypeR，因为两者都可能适合您的分析使用。
评论
要在R中操作netCDF数据（光栅源或其他格式），请链接到两个R CRAN托管的netCDF软件包，即ncdf4-cran.r-project.org/web/packages/ncdf4/index.html和RNetCDF-cran。 r-project.org/web/packages/RNetCDF/index.html
–V Stuart Foote
2011年9月4日15:17
#4 楼
一个大问题是，是否要在处理文件之前将整个栅格从文件中读取到内存中，或者文件是否太大以至于您将对其进行增量处理，或处理整个文件的某些子集。如果将它们全部加载到内存中，那么您将主要执行顺序访问，最快的格式将是在普通存储和压缩存储之间进行折衷（取决于CPU与磁盘的速度之类的因素）。任何二进制文件格式都可能非常接近（ASCII会更慢）。
如果需要处理非常大的文件的子集，则可以将想要分组的子集分组在一起的格式可能会更快-例如：图块或可以计算偏移量的格式。有时，未压缩的方法在这里会得到好处，因为计算图像的任何给定部分在文件中的位置可能很简单，尤其是如果您只需要一个非常大的行的一部分时，但是可以以细粒度的方式进行压缩，这对于某些对象来说效果很好访问模式。
很抱歉，您可能必须根据访问模式进行基准测试，而不是一刀切。当然，它可能不仅取决于文件格式和上述因素，还取决于该格式的驱动程序和您的软件。
#5 楼
您考虑这类问题的方式取决于应用程序访问文件的方式以及文件中数据的布局方式。这个想法是，如果您可以顺序访问数据，则与随机访问相比，效率将大大提高。GeoTIFF是2D“图像”或数组的集合。 NetCDF是多维数组的通用存储。但是，如果将数组以与GeoTIFF中相同的方式存储在netCDF中，则或多或少会获得相同的性能。
还可以重新排列netCDF中的数据，因此原则上可以优化您的读取模式。我的猜测是，大多数GIS应用程序都针对GeoTIFF 2D布局进行了优化，因此重新排列并没有太大好处。兆字节。
评论
+1表示随机访问或读取任意位置与顺序访问非常不同，直到整个文件读取完毕。我可能不满意，但我认为Geotiff还支持分片存储和任意访问，只是条带/行是最常见且得到广泛支持的。如今，GIS中的“非常大的文件”也趋向于数GB。 ;-)
–马特·威尔基
2011年12月8日在22:33
#6 楼
几年前，我读了几页关于此的文章，从那时起，我将tiff与packbits压缩结合使用，并与geotiff标头平铺，因此感到非常高兴。arcpad团队文章
wiki
但是阅读以下内容后，我会重新考虑并可能使用deflate品种。
Arcpad网站
#7 楼
如此多的软件包在后台使用GDAL，例如rgdal，QGIS，GRASS等。如果我使用的是这些软件包之一，那么我会考虑将图像转换为vrt。我经常看到它建议，当您需要使用两个GDAL命令时，由于读取开销很小（例如，http://www.perrygeo.com/lazy），因此中间文件应为vrt文件。 -raster-processing-with-gdal-vrts.html）。听起来您的工作流程是：转换一次并读取多次。也许vrt是合适的。
[编辑：链接已调整]
评论
这个问题与GIS有关，但是我怀疑您更有可能获得SO的答案，SO具有R专家的强大子社区。如果您没有迅速得到答案，请标记此问题，主持人将为您迁移。