各种栅格数据格式的速度

我在查找不同栅格文件格式的任何讨论或比较基准测试时遇到麻烦（例如，用于R中的数据分析）。是否有人对为什么特定格式可能更快或更慢有任何见解？还是应该使差异最小？

具体来说，我感兴趣的是将栅格（例如GEOTIFF文件）转换为其他格式（例如netCDF）是否值得为了加快读取/写入和其他操作的速度。

这是我的一篇老博客文章，着眼于文件大小和格式访问时间。我没有调查写入速度，只是访问时间。我想说他们可能直接相关，但无法担保。

文章摘要：Packbits似乎为您提供了最佳的访问时间（以磁盘空间为代价），而Deflate则为您提供了对中/小文件的中/慢访问时间。此外，您可以通过创建各种大小的缩略图并确定需要花费多长时间来更经验地测试访问时间。示例命令：time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

假设在这种情况下，与R相关的唯一事情就是它可以从文件中读取数据的速度，就像其他任何进程一样，那么这应该给您一个很好的指示。

对于读/写操作，可以使用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 

“已用”给出了该操作花费的总时间（秒）。每次运行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上，因此磁盘操作快速）

这仅仅是加载文件，而不是操作它们。

也许实际上不是哪个栅格图像格式具有更好的打开基准的问题，而是哪个栅格图像格式是最有效的栅格源格式，用于打开和读取作为R数值数组的输入。然后，假设您将结果输出回栅格，这是R中最有效的输出格式。

无论哪种方式，如果要在R中使用栅格，则可能会使用rgdal和R ncdf软件包来补充R 栅格软件包中包含的内容。主要依靠gdalwarp命令。需要在那里计算格式依赖性，以便选择栅格。您会在SO以及各种OSGEO和R论坛/博客/ wiki上找到相当多的报道。

但是，由于这是一个GIS论坛，其中Python的使用处于相对较高的位置，因此我将注意到，使用Python numpy数组处理栅格数据有很多优点，并且对gdal库的栅格加载，转换和导出的依赖性类似。一些人发现Python中的内存管理和代码结构优于本机R语言-也许看一下RPy2或PypeR，因为两者都可能适合您的分析使用。

一个大问题是，是否要在处理文件之前将整个栅格从文件中读取到内存中，或者文件是否太大以至于您将对其进行增量处理，或者处理整个文件的某些子集。

如果将它们全部加载到内存中，那么您将主要执行顺序访问，最快的格式将是普通存储和压缩存储之间的折衷（取决于CPU与磁盘的速度之类的因素）。任何二进制文件格式都可能非常接近（ASCII会更慢）。

如果您需要处理一个非常大的文件的子集，则将想要分组的子集更紧密地组合在一起的格式可能会更快-例如：图块或可以计算偏移量的格式。有时，未压缩的方法在这里会得到好处，因为计算图像的任何给定部分在文件中的位置可能很简单，特别是如果您只需要非常大的行的一部分时，但是可以以细粒度的方式进行压缩，这对于某些对象来说效果很好访问模式。

抱歉，但是您可能必须根据访问模式进行基准测试，而不是一刀切。当然，它可能不仅取决于文件格式和上述因素，还取决于该格式的驱动程序和您的软件。

您对这类问题的思考方式取决于应用程序访问文件的方式以及文件中数据的布局方式。这个想法是，如果您可以顺序访问数据，则与随机访问相比，效率将大大提高。

GeoTIFF是2D“图像”或数组的集合。NetCDF是多维数组的通用存储。但是，如果将数组以与GeoTIFF中相同的方式存储在netCDF中，则或多或少将获得相同的性能。

您还可以重新排列netCDF中的数据，因此原则上可以针对您的阅读模式进行优化。我的猜测是，大多数GIS应用程序都针对GeoTIFF 2D布局进行了优化，因此重新布置没有太大的好处。

最后，Id表示，只有在您拥有非常大的文件（至少数十兆字节）时，它才真正重要。

几年前，我读了几页关于此的文章，从那时起，我将tiff与packbits压缩结合使用，并与geotiff标头平铺，因此感到很高兴。

Arcpad团队文章

维基

但是阅读以下内容后，我将重新考虑并可能使用deflate变量。

Arcpad网站

如此多的软件包在后台使用GDAL，例如rgdal，QGIS，GRASS等。如果我使用的是这些软件包之一，那么我会考虑将图像转换为vrt。我经常看到它建议您在需要使用两个GDAL命令时，将中间文件设为vrt文件，因为读取开销很小（例如，http ://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html）。听起来您的工作流程是：转换一次并读取多次。也许vrt是合适的。

[编辑：链接已调整]