概述#
Cloud Optimized GeoTIFF (COG) は二つの補助技術に依存しています。
-
第一の技術は GeoTiff のストレージ能力です：特別な方法でピクセルを保存し、未処理のピクセルを直接保存するだけではありません。
-
第二の技術は HTTP Get による範囲リクエストのサポートで、この能力によりクライアントはファイル内の必要な部分だけをリクエストできます。
前者の GeoTIFF ストレージ方式により、後者のリクエストはファイル内の処理が必要な部分のデータを簡単に取得できるようになります。
GeoTIFF の組織方式#
COG が使用する二つの主要なデータ組織技術はタイルとオーバービューです。データの圧縮により、データのオンライン転送がより効率的になります。
タイルスライスは画像内にスライスを内蔵して作成され、単純にデータのストライプを使用するのではありません。データのストライプを使用する場合、特定のデータを取得するには全データを読み込む必要がありますが、スライスが指定された領域で迅速に取得できるようになると、同様の要求はデータの特定部分にアクセスするだけで済むようになります。
オーバービューは同じ画像のダウンサンプリングされた複数のバージョンを作成します。ダウンサンプリングとは、元の画像を「縮小」する際に多くの詳細が失われることを意味します（現在の 1 ピクセルが元の画像では 100 ピクセルまたは 1000 ピクセル存在する可能性があります）。同時に、データ量も小さくなります。通常、1 つの GeoTIFF には異なるズームレベルに対応する複数のオーバービューがあります。これにより、サーバーの応答が速くなります。なぜなら、レンダリング時に特定のピクセル値を返すだけで済み、1000 ピクセルを表すためにどのピクセル値を使用するかを再度探す必要がないからです。しかし、これによりファイル全体のサイズが大きくなることもあります。
データの圧縮により、ソフトウェアは画像を迅速に取得でき、通常はより良いユーザー体験を提供しますが、HTTP GET の範囲リクエストの効率的な動作を確保することも非常に重要です。
HTTP Get 範囲リクエスト#
HTTP の 1.1 バージョンは非常に優れた機能である範囲リクエストを導入しました。これはクライアントがサーバーからデータをリクエストする際の GET リクエストで使用されます。サーバーのレスポンスヘッダーにAccept-Ranges: bytesが含まれている場合、これはデータ内のバイトをクライアントが任意の方法で分割してリクエストできることを示しています。これは通常「バイトサービング」とも呼ばれ、ウィキペディアにはその動作原理についての記事があります。クライアントはサーバーから必要なバイトをリクエストでき、Web 分野では広く利用されています。例えば、ビデオサービスでは、クライアントはファイル全体をダウンロードすることなく操作できます。
範囲リクエストはオプションのフィールドであるため、サーバーがそれを実装する必要はありません。しかし、ほとんどのクラウドサービスプロバイダー（Amazon、Google、Microsoft、OpenStack など）のオブジェクトストレージツールはこのオプションを提供しています。そのため、クラウド上に保存されているデータのほとんどは範囲リクエストサービスを提供できるようになっています。
整合#
これら二つの技術を紹介した後、二つの部分がどのように連携して動作するかが明らかになります。GeoTIFF 内のタイルとオーバービューは、確定した構造でクラウド上のファイルに保存されているため、範囲リクエストはファイル内の関連部分をリクエストできます。
オーバービューはクライアントが全体の画像のクイックビューをレンダリングしたいときに機能します。このプロセスでは、各ピクセルをダウンロードする必要がなく、リクエストはより小さなサイズの事前に作成されたオーバービューをリクエストすることになります。GeoTIFF ファイルの特定の構造は、HTTP 範囲リクエストをサポートするサーバーによって、クライアントがファイル全体から必要な部分を簡単に取得できるようにします。
スライスは、全体の画像の一部を処理または視覚化する必要があるときに機能します。これはオーバービューの一部である場合もあれば、全解像度である場合もあります。注意すべき点は、タイルがファイル内の同じ位置に関連データの領域を組織しているため、範囲リクエストが必要なときにそれを取得できることです。
もし GeoTIFF がオーバービューとスライスで「クラウド最適化」されていない場合でも、いくつかのリモート操作を行うことは可能ですが、それらは全データをダウンロードする必要があるか、実際のニーズを超えるデータ量をダウンロードする必要があります。
利点#
ますます多くの地理情報データがクラウドに移行しており☁️、その大部分はS3やGoogle Cloud Storageのようなクラウドサービスに基づくオブジェクトストレージに保存されています。従来の GIS ファイル形式はクラウドに簡単に保存できますが、Web マップタイルサービスを提供したり、迅速なデータ処理を実行したりする際には、これらの形式はもはや効率的ではなく、通常はデータをすべて別の場所にダウンロードし、その後、より最適化された形式に変換するか、メモリに読み込む必要があります。
Cloud Optimized GeoTIFF は、いくつかの小技術を通じてデータフローをより効率的にし、クラウドサービスに基づく地理データワークフローを可能にします。オンライン画像プラットフォームのPlanet PlatformやGBDXは、この方法を使用して画像サービスを提供し、画像処理を非常に迅速にします。COG 技術を使用するソフトウェアは、必要なデータの部分を取得することで実行時間を最適化できます。
多くの新しい地理情報ソフトウェア（GeoTrellis、Google Earth Engine、IDAHOなど）も、ソフトウェアアーキテクチャに COG の理念を取り入れています。各処理ノードは、COG の部分ファイルストリームを取得することで高速に画像処理を実行します。
既存の GeoTIFF 標準への影響は、新しいファイル形式を導入することとは異なります。現在のソフトウェアは、COG を読み取るために何の変更も必要としません。流ファイルを処理する能力を持つ必要はなく、単にファイル全体をダウンロードして読み取るだけで済みます。
クラウド上で Cloud Optimized GeoTIFF 形式のファイルを提供することで、大量のファイルコピーを削減できます。オンラインソフトウェアはストリームファイルを使用でき、自分自身のコピーを保持する必要がないため、より効率的になり、今日の一般的なパターンとなっています。さらに、データ提供者はさまざまな形式のデータを提供する必要がなく、古いソフトウェアと新しいソフトウェアの両方がこれらのデータを読み取ることができます。データ提供者は、データの 1 つのバージョンを更新するだけで済み、余分なコピーやダウンロードを必要とせず、複数のオンラインソフトウェアが同時に使用できます。
QUICK START#
前言#
このチュートリアルは、開発者が Cloud Optimized GeoTIFF を使用および生成する方法を説明します。
读取#
最も簡単な使用方法は、GDAL のVSI Curl機能を使用することです。GDAL Wiki のHow to read it with GDALセクションを読むことができます。今日のほとんどの地理情報ソフトウェアは GDAL を依存ライブラリとして使用しているため、GDAL を導入することが COG 機能を読み取る最も迅速な方法です。
Planetでは、すべてのデータがすでに COG 形式であり、ダウンロードに関する小さなチュートリアルがあります：download part of an image。ほとんどのチュートリアルは Planet API の使用方法について説明していますが、GDAL Warp が大きな COG ファイルから単一の作業領域を抽出する方法も説明しています。
创建#
同様に、GDAL wiki の COG ページには、How to generate it with GDALがあります。
$ gdal_translate in.tif out.tif -co TILED=YES -co COPY_SRC_OVERVIEWS=YES -co COMPRESS=DEFLATE
または、rio-cogeoプラグインを使用します：
$ rio cogeo create in.tif out.tif --cog-profile deflate
他の多くの地理情報ソフトウェアも適切なサムネイルとスライスを追加できるはずです。
验证#
rio-cogeo プラグインを使用して：
$ rio cogeo validate test.tif