QGISで巨大なジオティフ（またはvrt）を表示しますか？

30mの解像度でグローバルラスタを操作および処理しています。合計ラスターサイズは通常[1,440,000 560,000]です。スーパーコンピューターにアクセスできるので、グローバルラスタを扱いやすいチャンクに分割し、いくつかの計算を並行して実行し、それらをディスクに非常に迅速に書き込むことができるコードを作成しました。

しかし、結果を表示することに関しては、壁にぶつかっています。私は通常、地球をカバーするタイルの仮想ラスターを作成し、それをQGISに取り込みます。しかし、それは信じられないほど遅いです（もしそうならロードするのに数分）。そして、パンまたはズームしようとすると、さらに数分かかります。この問題を解決するための最初のアプローチは、gdaladdoを使用して概要を作成することでした。ただし、これらのビルドには（日単位のように）永久にかかるため、アルゴリズムの開発には役立ちません。これが私が試したことのリストと、なぜ/どのように失敗したかです。

1. vrtの概要を構築します。上記のように、これは8つのレベルで完了するのに2日以上かかります。それは私の目的には受け入れられません。

2. 個々のタイルの概要を作成し、概要を含むvrtに何らかの方法でマージします。タイルのオーバービューを比較的迅速に作成できます（スーパーコンピューター）が、それらを再マージすることはできません。私は試した：

   2a。概要付きのタイルのgdal_merge。ただし、概要は出力tiffに保持されません（または少なくともQGISで認識されません）。

   2b。概要付きのタイルでgdalbuildvrtを使用しましたが、上記のように、概要は保持されませんでした。[これは正しくありません。編集を参照してください。]

   2c。レベル1〜6のタイルの構築概要とvrt（直接オプション2b）でレベル7〜8を直接構築するハイブリッドも試してみましたが、これら2つのレベルだけではまだ時間がかかります。いくつかのテストを行ったところ、タイルの概要が実際にvrtの概要を作成するために使用されていることがわかりましたが、vrtの概要を完了するにはまだ1日ほどかかります。

だから私はここに誰かが私が次にどこに行くべきかについていくつかの提案があることを願っています。ここに私が検討しているいくつかのオプションがあります：

1. 手動でグローバルピラミッドを手動で作成します。それらを.ovrファイルに再結合するのは注意が必要です。

2. マップサーバー（ジオサーバー）を使用します。私はこれについてほとんど知りませんが、プロセスに複雑さを加えている間に時間のハードルを克服できないのではないかと心配しています。

3. 大陸またはその他の地域によってドメインを分割します。私は本当にこのオプションを避けたいです。

「なぜ地球全体を30mの解像度で表示する必要があるのですか？」1つの例：私は水のピクセルのマスクを（全体的に）取り、それをスケルトン化して川を見つけ、測定を実行します。私のスケルトン化アルゴリズムは少しの調整が必要で（枝刈り、ループの削除、一般的なクリーニングなど）、出力は必ず30mです。川や景観は世界中で多様であるため、実装した変更の影響を確認するには、周囲をパンできる必要があります。

また、QGISを調べて、巨大なラスターをより速くレンダリングするために使用できる設定がないことを確認しましたが、何も表示されませんでした。SSDドライブを購入するのに足りないので、私はそれができるだけ速く動いていると思います。（私のHDDのI / Oは〜250MB / sです）。

個々のタイルで概要を作成し、次にvrtを作成しても概要が維持されていることがわかりました。ファイルのメタデータのQGISの「Pyramid」セクションは空ですが、「Dimensions」セクションには概要の各レベルのエントリがあります（X 720000、Y 140、X 360000、Y 70など）。だから私は2bについて間違っていました。

また、すべてのタイルをQGISにプルしただけでは1分未満でレンダリングされますが、タイルを参照するvrtをプルした場合は、5分以上かかります（処理する）。

SSDを搭載したコンピューターでいくつかのテストを行ったところ、グローバルなvrts（概要なし）を適切な速度で正常に読み込み、表示、レンダリングできることがわかりました。私のコンピューターでも同じことができることを期待して、1TB PCIe SSDを注文しました。結果で更新されます。

あなたは2つの主要な懸念を持っているようです：VRT IDはブラウジングで遅く、グローバルな概観を構築するのは遅いです。

GDAL VRTが私と私のMapServerにとって何年も前に遅くなっていると確信していますが、状況が変わった可能性があります。私は10000枚の航空写真（10000x10000から12000x12000ピクセルの画像/タイルサイズ）でテストレイヤーを作成し、GDAL VRTはネイティブMapServerシェープファイルインデックスより実際に高速で、テストコンピューターで1秒あたり6タイル（256x256）のシンプルなテストで機能しますGetMapsが常に最初の概要レベルに到達する1つのスレッド。10000枚の画像を含むモザイクはまだ非常に小さいものです。私のテストでは、LinuxのVRTファイル全体がキャッシュメモリにあると思います。VRTには何枚の画像がありますか？

次の章には古い情報が含まれている場合があります。責任を持って読んでください。

VRTに膨大な数の画像が含まれている場合、VRTが遅くなるという証拠がいくつかあります。これは、VRTがXML形式のインデックスであり、XMLファイル全体を毎回フルスキャンする空間インデックスをサポートしていないためです。VRT http://osgeo-org.1560.x6.nabble.com/gdal-dev-Don-t-we-の空間インデックスの実装についていくつかの議論があったとしても、プレーンなGDALでそれを改善するためにあなたができることは何もありません。 have-any-ideas-for-GSoC-2017-td5309810.html。

新しいソフトウェアをインストールする場合、最も簡単な回避策は、MapServerをtileindex http://www.mapserver.org/optimization/tileindex.htmlで使用することです。あなたはgdaltindexとタイルインデックスを作成した場合http://www.gdal.org/gdaltindex.htmlとshptreeと同様にタイルインデックス用のインデックスを作成http://www.mapserver.org/utilities/shptree.htmlその後、MapServerは、所有しているすべての画像ファイルに非常に高速にアクセスできるはずです。個々のタイルの概要を作成し、WMS for QGISを介してレイヤーを提供します。これで問題の最初の部分は解決しましたが、グローバル概要の問題は解決していません。個々のタイルの概要を作成した場合でも、広い領域をカバーするために何千もの画像ファイルを開くのは遅くなるため、より広い領域をカバーする概要画像を作成してファイルの数を制限する必要があります。これは、gdaladdoを使用してVRTホールの概要を作成することですでに試みたものです。

GDAL / MapServerの世界で、グローバルピラミッドを自動的に作成するための既製のツールは知りません。スライド式の-prowjinまたは-srswinを使用してgdal_translate http://www.gdal.org/gdal_translate.htmlを実行するスクリプトを記述することにより、グローバルVRTからのタイルをより大きなピクセルサイズの一連の画像に変換できます。次に、gdalbuildvrtまたはgdaltindexを使用して、結果のタイルを新しい概要レイヤーに結合できます。

GeoServerの使用も検討しているので、ケースを処理するために記述されたgdal_retileスクリプトhttp://www.gdal.org/gdal_retile.htmlで戦利品を用意することをお勧めします。gdal_retileがVRTを構築してQGISの概観図として直接作成するタイルを使用することもできます。ただし、遅い巨大なVRTファイルに関する最初の問題は残ります。

さて、私は両方の問題を解決しました...主にNVMe SSDを購入することで。ディスクの読み取り/書き込みが125 MB /秒から1200 MB /秒になりました。

プログラム的には、読み取り/書き込み速度を向上させるためにできることがいくつかあります。まず、tiffのブロックサイズを検討します。ストライプ化されたtiffを使用している場合、特定の領域にズームすると、GISソフトウェアは、表示されないtiffの部分を含む、領域の各行全体を読み取る必要があります。たとえば、256 x 256ピクセルの領域にズームインする場合、縞模様のTIFFがある場合、ソフトウェアは少なくとも256ブロック（1行に1つ）を読み取る必要があります。タイル化されたtiff（256 x 256でタイル化）を使用している場合、読み取る必要があるブロックの最大数は4（最低1）です。したがって、最初にできることは、タイル化されたtiff（gdalのTILED = YES作成オプション）を使用していることを確認することです。

第二に、概観へのハイブリッドアプローチはうまくいくようです。操作を並列化できれば、個々のタイルに概観図をすばやく追加できますが、これはタイルサイズよりも小さい解像度の場合にのみメリットがあります。個々のタイルにレベル2 4 8 16 32および64の内部概要を作成しました。次に、VRTを作成し、VRTでレベル128、256、512の概要を作成します（これらは30m解像度のグローバルデータセット用であることに注意してください。レベルは、TIFFのピクセル数に応じて変化します）。個別の概要を作成するための合計時間は数分程度です（実行できるスレッドの数とタイルの数によって異なります）が、VRTで概要を作成するのは1時間程度です。私の最初の投稿に対するランタイムの改善は、SSDとVRTで作成されるレベルが少ないためです。

3番目に、このページの下部で説明されているように、vrtsを構築するときにGDAL_MAX_DATASET_POOL_SIZEオプションを使用して遊ぶことができます。一度にメモリに保持するtiffの最大数を設定します。

第4に、PACKBITSで圧縮すると、表示時間が最も速くなることがわかりました。ファイルはLZWほど小さくはありませんが、それはあなたが喜んで作るかもしれないトレードオフです。

その結果、VRTが迅速に読み込まれ、パン/ズームがほぼシームレスに行われます。