さまざまなラスターファイル形式の議論や比較ベンチマークを見つけるのに問題があります（たとえば、Rでのデータ分析で使用するため）。特定の形式が高速または低速である理由について誰かが洞察を持っていますか？それとも、違いは最小限にすべきでしょうか？
特に、ラスター（たとえば、GEOTIFFファイル）を別の形式（たとえば、netCDF）に変換することが、読み取り/書き込みやその他の操作を高速化するために価値があるかどうかに興味があります。
回答:
ファイルサイズとフォーマットのアクセス時間を調べている私の古いブログ記事があります。書き込み速度は調査せず、アクセス時間のみを調査しました。おそらく直接関係していると思いますが、それを保証することはできません。
記事の要約：Packbitsは（ディスク容量を犠牲にして）最高のアクセス時間を提供するように見えますが、Deflateは中/小ファイルの中間/低速アクセス時間を提供します。また、さまざまなサイズのサムネイルを作成し、所要時間を計ることにより、アクセス時間をより経験的にテストできます。コマンド例：time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>
この場合、Rに関連する唯一のことは、他のプロセスと同様に、ファイルからデータをどれだけ速く読み取ることができると仮定した場合、適切な指標が得られるはずです。
以下のために、読み取り/書き込み操作、あなたはsystem.time（）を使用してこれらの操作の速度をテストすることができます。R（ラスターパッケージ）のDEMファイルを4つのフォーマット（ASCII、IMG、および圧縮なしのDeflate）に変換した結果をいくつか示します。たとえば、〜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でかなりの範囲をカバーしています。
しかし、これはPythonの使用が比較的優勢なGISフォーラムであるため、ラスターの読み込み、変換、およびエクスポートのためにgdalライブラリに同様に依存するPython numpy配列のラスターデータを操作する利点があることに注意します。ネイティブRよりもPythonのメモリ管理とコード構造の方が望ましいと感じる人もいます。RPy2またはPypeRのどちらかが分析用途に適している可能性があります。
大きな問題は、処理する前にラスター全体をファイルからメモリに読み込むのか、ファイルが大きすぎてインクリメンタルに処理するのか、ファイル全体のサブセットを処理するのかです。
すべてをメモリにロードすると、ほとんどシーケンシャルアクセスが行われ、最速のフォーマットはプレーンストレージと圧縮ストレージの間のトッソップになります（CPUとディスクの速度などによって異なります）。バイナリファイル形式のいずれかはおそらくかなり近いでしょう（ASCIIは遅くなります）。
非常に大きなファイルのサブセットを処理する必要がある場合、必要なサブセットをグループ化する形式のほうが高速です。たとえば、タイルやオフセットを計算できる形式です。特に、非常に大きな行の一部のみが必要な場合は、画像の特定の部分がファイル内のどこにあるかを計算するのは簡単なため、非圧縮アプローチがここで得られることがありますが、アクセスパターン。
申し訳ありませんが、万能ではなく、アクセスパターンに応じてベンチマークを行う必要があります。もちろん、ファイル形式と上記の要因だけでなく、その形式のドライバーとソフトウェアにも依存します。
この種の問題について考える方法は、アプリケーションがファイルにアクセスする方法と、ファイル内のデータのレイアウト方法の観点からです。アイデアは、データにシーケンシャルにアクセスできる場合、ランダムにアクセスする場合よりもはるかに効率的であるということです。
GeoTIFFは、2D「画像」または配列のコレクションです。NetCDFは、多次元配列用の汎用ストレージです。ただし、GeoTIFFと同じ方法で配列をNetCDFに保存すると、ほぼ同じパフォーマンスが得られます。
netCDFのデータを再配置することもできるため、原則として読み取りパターンに最適化できます。私の推測では、ほとんどのGISアプリケーションはGeoTIFF 2Dレイアウト用に最適化されているため、再配置することで得られるものはあまりありません。
最後に、私は、少なくとも数十メガバイトの非常に大きなファイルがある場合にのみ本当に重要だと言います。
これについては数年前に数ページを読みましたが、それ以来、tiffをpackbits圧縮で使用し、geotiffヘッダーでタイリングし、満足しています。
しかし、以下を読んだ後、デフレレートバリエーションを再検討し、おそらく使用します。
rgdal、QGIS、GRASSなど、非常に多くのパッケージがボンネットの下でGDALを使用しています。これらのパッケージのいずれかを使用している場合、イメージをvrtに変換することを考えます。2つのGDALコマンドを使用する必要がある場合、読み取りオーバーヘッドが最小限であるため、中間ファイルはvrtファイルにすることをお勧めします（たとえば、http：//www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html）。ワークフローは次のように思えます。一度変換して何度も読む。たぶんvrtが適切でしょう。
[編集：リンク調整]