さまざまなラスターデータ形式の速度


25

さまざまなラスターファイル形式の議論や比較ベンチマークを見つけるのに問題があります(たとえば、Rでのデータ分析で使用するため)。特定の形式が高速または低速である理由について誰かが洞察を持っていますか?それとも、違いは最小限にすべきでしょうか?

特に、ラスター(たとえば、GEOTIFFファイル)を別の形式(たとえば、netCDF)に変換することが、読み取り/書き込みやその他の操作を高速化するために価値があるかどうかに興味があります。


2
この質問はGISに関連していますが、Rの専門家の強力なサブコミュニティを持つSOで回答を得る可能性が高いと思われます。すぐに回答が得られない場合は、この質問にフラグを立ててください。モデレーターが移行します。
whuber

回答:


9

ファイルサイズとフォーマットのアクセス時間を調べている私の古いブログ記事があります。書き込み速度は調査せず、アクセス時間のみを調査しました。おそらく直接関係していると思いますが、それを保証することはできません。

記事の要約:Packbitsは(ディスク容量を犠牲にして)最高のアクセス時間を提供するように見えますが、Deflateは中/小ファイルの中間/低速アクセス時間を提供します。また、さまざまなサイズのサムネイルを作成し、所要時間を計ることにより、アクセス時間をより経験的にテストできます。コマンド例:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

この場合、Rに関連する唯一のことは、他のプロセスと同様に、ファイルからデータをどれだけ速く読み取ることができると仮定した場合、適切な指標が得られるはずです。


リンクされた記事の+1ですが、重要な情報はオフサイトにあり、そのページがダウンしたり移動したりすると失われます。この記事が要約された結論を出すことをお勧めします。そうすることで、ページが一瞬でも利用できなくなった場合でも、読者は今後の研究や思考のために何か手を組むことができます。ありがとう!
マットウィルキー

けっこうだ!Deflateを使用すると、ディスクスペースを犠牲にして最高のアクセス時間が得られますが、Deflateを使用すると、中間/小さなファイルのアクセス時間が中程度/低速になります。また、さまざまなサイズのサムネイルを作成し、所要時間を計ることにより、アクセス時間をより経験的にテストできます。例コマンド: "時間gdal_translate -outsize <サムネイル寸法> -of GTiff <圧縮画像ファイル> <サムネイルファイル>"
R Thiede

1
ありがとう!要約を回答自体にまとめたので、より自己完結型です(各回答/質問の左下にある編集リンクを参照)。
マットウィルキー

@RThiedeには有効な懸念事項がありました。ブログへのリンクはもはや有効ではないようです。
マティフォー

@RThiedeリンクは無効です新しいリンクを提供できますか?
マジッド・ホハティ

6

以下のために、読み取り/書き込み操作、あなたは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なので、ディスク操作が高速です)

これは単にファイルをロードすることであり、操作することではありません。


4

たぶん、どのラスターイメージ形式がより良いオープニングベンチマークを持っているかという問題ではないかもしれません-むしろ、どのラスターイメージ形式が、R数値配列への入力として開いて読み取るための最も効率的なラスターソース形式であるかということです。そしてその後-結果をラスターに出力することを想定して、Rからの最も効率的な出力形式は何ですか?

いずれにせよ、Rでラスターを使用する場合はrgdalパッケージとR ncdfパッケージを使用して、R ラスターパッケージに含まれるものを補完する可能性があります。主にgdalwarpコマンドに依存しています。ラスターを選択するには、そこで形式の依存関係を解決する必要があります。SOおよびさまざまなOSGEOおよびRフォーラム/ブログ/ wikiでかなりの範囲をカバーしています。

しかし、これはPythonの使用が比較的優勢なGISフォーラムであるため、ラスターの読み込み、変換、およびエクスポートのためにgdalライブラリに同様に依存するPython numpy配列のラスターデータを操作する利点があることに注意します。ネイティブRよりもPythonのメモリ管理とコード構造の方が望ましいと感じる人もいます。RPy2またはPypeRのどちらかが分析用途に適している可能性があります。


RでnetCDFデータ(ラスターソースなど)を操作するための2つのR CRANホストnetCDFパッケージ、ncdf4-cran.r-project.org/ web / packages/ncdf4/ index.htmlおよびRNetCDF- cran
Vスチュアートフート

4

大きな問題は、処理する前にラスター全体をファイルからメモリに読み込むのか、ファイルが大きすぎてインクリメンタルに処理するのか、ファイル全体のサブセットを処理するのかです。

すべてをメモリにロードすると、ほとんどシーケンシャルアクセスが行われ、最速のフォーマットはプレーンストレージと圧縮ストレージの間のトッソップになります(CPUとディスクの速度などによって異なります)。バイナリファイル形式のいずれかはおそらくかなり近いでしょう(ASCIIは遅くなります)。

非常に大きなファイルのサブセットを処理する必要がある場合、必要なサブセットをグループ化する形式のほうが高速です。たとえば、タイルやオフセットを計算できる形式です。特に、非常に大きな行の一部のみが必要な場合は、画像の特定の部分がファイル内のどこにあるかを計算するのは簡単なため、非圧縮アプローチがここで得られることがありますが、アクセスパターン。

申し訳ありませんが、万能ではなく、アクセスパターンに応じてベンチマークを行う必要があります。もちろん、ファイル形式と上記の要因だけでなく、その形式のドライバーとソフトウェアにも依存します。


2

この種の問題について考える方法は、アプリケーションがファイルにアクセスする方法と、ファイル内のデータのレイアウト方法の観点からです。アイデアは、データにシーケンシャルにアクセスできる場合、ランダムにアクセスする場合よりもはるかに効率的であるということです。

GeoTIFFは、2D「画像」または配列のコレクションです。NetCDFは、多次元配列用の汎用ストレージです。ただし、GeoTIFFと同じ方法で配列をNetCDFに保存すると、ほぼ同じパフォーマンスが得られます。

netCDFのデータを再配置することもできるため、原則として読み取りパターンに最適化できます。私の推測では、ほとんどのGISアプリケーションはGeoTIFF 2Dレイアウト用に最適化されているため、再配置することで得られるものはあまりありません。

最後に、私は、少なくとも数十メガバイトの非常に大きなファイルがある場合にのみ本当に重要だと言います。


ランダムアクセス、または任意の場所の読み取りが、ファイル全体の読み取りが完了するまで連続して行われるものとは非常に異なるという点については、+ 1。私はベースから外れているかもしれませんが、Geotiffはタイルストレージと任意のアクセスもサポートしていると思います。ストリップ/行では最も一般的で広くサポートされているだけです。また、最近のGISの「非常に大きなファイル」は、数GBの範囲にある傾向があります。;-)
マットウィルキー


2

rgdal、QGIS、GRASSなど、非常に多くのパッケージがボンネットの下でGDALを使用しています。これらのパッケージのいずれかを使用している場合、イメージをvrtに変換することを考えます。2つのGDALコマンドを使用する必要がある場合、読み取りオーバーヘッドが最小限であるため、中間ファイルはvrtファイルにすることをお勧めします(たとえば、http://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html)。ワークフローは次のように思えます。一度変換して何度も読む。たぶんvrtが適切でしょう。

[編集:リンク調整]

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.