概要:タイル、.vrt、またはその両方に?


10

大量の画像コレクションをオンザフライでモザイクするためにを使用する場合、個々のラスターまたは最終的な.vrt、あるいはその両方に概要(ピラミッド)を追加する方が良いですか?(「より良い」とは、最終的な画像の使用と閲覧にスムーズなエクスペリエンスを提供しながら、必要以上にストレージを使用しないことの間のバランスポイントを見つけることを意味します。)


モザイクを使用する理由を
教えてください

回答:


8

それは主に、イメージレイヤーを表示するための最小スケールに依存します。

レイヤーを部分的に更新すると、個々のラスターの概観図をより柔軟に作成できます。古い画像を削除して、概要が表示された新しい画像を配置するだけです。.vrtのビルド概要がある場合は、更新後に再度作成する必要があります。ただし、個々の概要は小規模ではうまく機能しません。元の画像がそれぞれ10x10 kmをカバーし、100x100 kmの領域を画面に表示したい場合、システムは概要を読み取るために100個の個別ファイルを開く必要があります。.vrtの概要を作成している場合、開くファイルは1つだけであり、高速になります。

ハイブリッドモデルを使用することもできます。いくつかの内部概要レベル(2 4 8)を作成し、次に.vrtから次の概要のピクセルサイズで新しい物理ファイルを作成します(16)。サブサンプリングされた画像の内部概要を作成し、最後にすべてを組み合わせてスケール依存グループにします。個々のイメージが新しいイメージに変更された場合、物理的な概要ファイルを更新する必要はありません。なぜなら、変更はとにかく小さなケースでは見えないからです。

ディスク容量が必要になると、どちらの場合も同じです。ただし、概要を圧縮することを忘れないでください。航空写真を使用すると、概要をJPEG方式および測光解釈で圧縮することにより、ディスク領域の90%以上を節約できます。

あなたがあなたの質問をするとき、私はあなたの.vrtのために圧縮された概要を作成すると言うでしょう。同じ量のディスク容量が必要であり、どのような規模でもブラウジングエクスペリエンスは良好です。更新について書いたことを今でも覚えています。


ハイブリッドのアイデアはとても面白いです!レベル16の物理ファイルがなぜあるのか知りたいです。それは何かを提供してgdaladdo foo.vrt 16 32 64いませんか?...それは私にも起こります。個々のタイルが仮想モザイクと同様にアクセスできるインスタンスでは、タイルとvrtの両方の概要が必要になる場合があります。
マット・ウィルキー

gdaladdo foo.vrt 16 32.64物理ファイルを作成しますが、gdaladdo foo.vrt 2 4 8以前に作成した場合は、すでにfoo.vrt.ovrファイルがあります。まあ、.ovrファイルは実際には単なるtiffであり、少し複雑な新しい.vrtファイルを使用して、名前を変更して概要レベルを手動で構築できます。仮想モザイクall_foo.vrtにfoo_1234.tifがあるが、一部のユーザーはその単一のtiffに直接アクセスする必要がある可能性があるということですか?そうすれば、ソフトウェアはall_foo.vrt.ovrから概観を推測することができません。
user30184

ああ、たぶん、あなたは個々の画像に対して2 4 8の概要を書き、VRTに対して16 32 64 ...を書くつもりでした。確かに素晴らしいアイデアです。
user30184

はい、2番目の応答、タイルの場合は2 4 8、vrtの場合は16 32 64です。
マットウィルキー

議論されている問題は私が頻繁にハッキングしようとしている問題であり、それは常に苦痛の原因です。10 km2のフォルダに配置された大量のファイルがあります。各フォルダーについて、VRTを生成し、概要を追加します(2 4 8 16)。次に、vrt-filesを1つに集約します(gdalbuildvrt aggreg.vrt * .vrt)。aggreg.vrt(32 64 128 256)の概要を1つ作成するのは面倒です。gdalbuildvrtは、すでにビルドされたovrファイルではなく、ソースファイルに直接移動するのではないかと思います...これは正しいですか?その場合:回避策はありますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.