QGISで巨大なジオティフ（またはvrt）を表示しますか？
30mの解像度でグローバルラスタを操作および処理しています。合計ラスターサイズは通常[1,440,000 560,000]です。スーパーコンピューターにアクセスできるので、グローバルラスタを扱いやすいチャンクに分割し、いくつかの計算を並行して実行し、それらをディスクに非常に迅速に書き込むことができるコードを作成しました。 しかし、結果を表示することに関しては、壁にぶつかっています。私は通常、地球をカバーするタイルの仮想ラスターを作成し、それをQGISに取り込みます。しかし、それは信じられないほど遅いです（もしそうならロードするのに数分）。そして、パンまたはズームしようとすると、さらに数分かかります。この問題を解決するための最初のアプローチは、gdaladdoを使用して概要を作成することでした。ただし、これらのビルドには（日単位のように）永久にかかるため、アルゴリズムの開発には役立ちません。これが私が試したことのリストと、なぜ/どのように失敗したかです。 vrtの概要を構築します。上記のように、これは8つのレベルで完了するのに2日以上かかります。それは私の目的には受け入れられません。 個々のタイルの概要を作成し、概要を含むvrtに何らかの方法でマージします。タイルのオーバービューを比較的迅速に作成できます（スーパーコンピューター）が、それらを再マージすることはできません。私は試した： 2a。概要付きのタイルのgdal_merge。ただし、概要は出力tiffに保持されません（または少なくともQGISで認識されません）。 2b。概要付きのタイルでgdalbuildvrtを使用しましたが、上記のように、概要は保持されませんでした。[これは正しくありません。編集を参照してください。] 2c。レベル1〜6のタイルの構築概要とvrt（直接オプション2b）でレベル7〜8を直接構築するハイブリッドも試してみましたが、これら2つのレベルだけではまだ時間がかかります。いくつかのテストを行ったところ、タイルの概要が実際にvrtの概要を作成するために使用されていることがわかりましたが、vrtの概要を完了するにはまだ1日ほどかかります。 だから私はここに誰かが私が次にどこに行くべきかについていくつかの提案があることを願っています。ここに私が検討しているいくつかのオプションがあります： 手動でグローバルピラミッドを手動で作成します。それらを.ovrファイルに再結合するのは注意が必要です。 マップサーバー（ジオサーバー）を使用します。私はこれについてほとんど知りませんが、プロセスに複雑さを加えている間に時間のハードルを克服できないのではないかと心配しています。 大陸またはその他の地域によってドメインを分割します。私は本当にこのオプションを避けたいです。 「なぜ地球全体を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を注文しました。結果で更新されます。