AlphaEarth Foundations GCS データ

gs://alphaearth_foundations GCS バケットには、AlphaEarth Foundations の年次 Satellite Embedding データセットを構成する COG(Cloud Optimized GeoTIFF)ファイルが含まれています。2017 年から 2025 年までの年間エンベディングが含まれています。

Google は、年次衛星エンベディング レイヤの継続的な作成に尽力しており、データセットの作成に依存する USGS と ESA からの入力データ ストリームの継続的な可用性を条件として、配信の変更が予想される場合は少なくとも 1 年前に通知します。

ライセンス

このデータセットは CC-BY 4.0 に基づいてライセンス供与されており、「AlphaEarth Foundations Satellite Embedding dataset は Google と Google DeepMind によって作成されたものです。」という帰属表示テキストが必要です。

このバケットは「リクエスト元による支払い」として設定されているため、データをダウンロードすると下り(外向き)料金などの料金が発生する可能性があります。

ディレクトリ構造

これらは年ごとにディレクトリに分割され、各年のディレクトリは UTM ゾーンごとに 1 つずつ 120 個のサブディレクトリに分割されます。サブディレクトリの名前は、ゾーン番号と半球(N または S)を反映しています。

各ディレクトリには、複数の COG ファイルがあります。これらのファイルには、その UTM ゾーンのすべてのピクセルデータが含まれています。

ファイル構造

各ファイルは 8,192 x 8,192 ピクセルで、64 チャンネルあります。逆量子化マッピング(下記参照)が適用された後の各ピクセルの大きさは、ユークリッド長が 1 になるように正規化されています。

ファイルには、4,096 x 4,096 ピクセル、2,048 x 2,048 ピクセルなどの概要レイヤが含まれており、最上位の概要レイヤは 1 x 1 ピクセルです。これらの概要レイヤは、各概要ピクセルがその概要ピクセルの下にある最高解像度ピクセルの平均値になるように構築されています。ここで、平均値の大きさは長さ 1 に正規化されています。

チャンネルは、Satellite Embedding データセットの A00 軸から A63 軸に順に対応します。COG にも、チャネルのこの命名が含まれています。

各チャネルの各ピクセルの値は、符号付き 8 ビット整数です。これらの値がエンベディングのネイティブ値([-1, 1] の範囲)にマッピングされる方法については、逆量子化をご覧ください。

値 -128 はマスクされたピクセルに対応します。1 つのチャンネルに存在する場合は、すべてのチャンネルに存在します。COG にはこのことが反映されます(つまり、NoData 値が -128 に設定されています)。

各ファイルの名前にも情報が含まれています。たとえば、gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff という名前のファイルを考えてみましょう。ファイル名からわかるように、このファイルは UTM ゾーン 1S(ゾーン 1、南半球)の 2019 年の年間エンベディングの一部です。ベースファイル名 x8qqwcsisbgygl2ry-0000008192-0000000000 は、このファイルを対応する Earth Engine 衛星エンベディング画像名にリンクするために使用されます。この例では、このファイルは Earth Engine 画像 GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry の一部に対応しています。ファイル名の 2 つの小数部分は、この COG の値がその Earth Engine 画像に対して相対的な位置を、Y のオフセットの後に X のオフセットとして指定します。この場合、COG のピクセル原点は、Earth Engine Image の原点を基準として(0, 8192)にあります。これは、結果として得られる COG が扱いにくくならないように、各 Earth Engine 画像(16384x16384 ピクセル)を細分割する必要があったためです。

逆量子化

各ピクセルの各チャネルの未加工の符号付き 8 ビット値(-128 は「データなし」の値として予約されているため、-127 ~ 127 の範囲)を分析可能な浮動小数点値(-1 ~ 1 の範囲)に変換するには、次のマッピングを行います。

  • 127.5 で割る
  • 正方形
  • 元の値の符号を掛ける

これは NumPy で次のように表現されます。

  # values is a NumPy array of raw pixel values
  de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)

Earth Engine では、対応するオペレーションは次のようになります。

  var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());

ダウンサンプリングされたピラミッドの作成

これらの COG の基本解像度レイヤから独自のダウンサンプリング バージョンまたは外部概要を作成する場合(たとえば、複数のファイルをモザイク処理した後など)は、次の手順を使用する必要があります。標準のラスター ピラミッド手法(未加工の整数値で -r average を使用して gdaladdo を使用するなど)では、正しい結果は得られません。

  1. 逆量子化: 逆量子化で説明されている方法を使用して、生の 8 ビット整数を浮動小数点数に変換します。
  2. ベクトルの合計: 逆量子化されたベクトルの要素ごとの合計を実行します。
  3. 正規化: 結果の合計ベクトルのユークリッド ノルムを計算し、そのノルムで割って単位長に再正規化します。
import numpy as np

# Assuming 'raw_values' is a NumPy array of shape (N, 64)
# containing the raw signed 8-bit integers from N pixels.
# N = 4 for a 2x2 aggregation, for example.

# 1. De-quantize
de_quantized_values = ((raw_values / 127.5) ** 2) * np.sign(raw_values)

# 2. Sum the de-quantized vectors
sum_vec = np.sum(de_quantized_values, axis=0)  # Shape (64,)

# 3. Normalize the sum vector
norm = np.linalg.norm(sum_vec)
# Add epsilon to prevent division by zero
pyramided_vec = sum_vec / (norm + 1e-9)

# 'pyramided_vec' is the correctly downsampled 64-dimensional unit vector.

COG の概要レイヤはこの手順で生成されています。ニーズに合っている場合は、追加の計算を行わずに、これらの概要レイヤをすぐに使用できます。

マニフェストとインデックス

このデータセット内のファイルの一覧は、gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt で確認できます。

ファイル名から対象地域を特定できないため、インデックスも 3 つの形式(GeoParquet、GeoPackage、CSV)でファイル gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquetgs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkggs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv に用意されています。このインデックスには、データセット内のファイルごとに 1 つのエントリが含まれています。各ファイルについて提供される情報は次のとおりです。

  • ファイルのジオメトリ(WGS84 形式)。EPSG:4326)ポリゴン。CSV 形式では、この値は WKT 列にあります。計算の詳細については、ジオメトリ処理をご覧ください。
  • crs: この画像が属する UTM ゾーンの CRS(EPSG コード、EPSG:32610 など)。
  • year: 画像が対象とする年。
  • utm_zone: 画像の UTM ゾーン(10N など)。
  • utm_westutm_southutm_eastutm_north: 生のピクセル配列の UTM 境界。これはジオメトリ処理を反映しておらず、有効かどうかに関係なくすべてのピクセルが含まれます。
  • wgs84_westwgs84_southwgs84_eastwgs84_north: WGS84 ジオメトリの最小経度と最大経度、最小緯度と最大緯度。

ジオメトリ処理

ピクセル配列はネイティブで一部の UTM ゾーンに存在するため、その UTM ゾーンではピクセル配列のバウンディング ボックスは単純な長方形になります。このバウンディング ボックスは、WGS84 のポリゴンに変換されます。このポリゴンには、UTM の直線が変換される WGS84 の曲線にエッジが沿うように、多くの追加ポイントが含まれています。このポリゴンは、画像のピクセルの有効性を考慮せず、画像のピクセル配列の境界のみを考慮します。

次に、ポリゴンは画像の UTM ゾーンの最小経度と最大経度にクリップされます。実際には、UTM ゾーンの端を越えて伸びる有効なピクセルがいくつか含まれない可能性があります。これらのピクセルをインデックスから除外しても問題はありません。隣接する UTM ゾーンの画像がその領域をカバーしているはずです。

UTM ゾーンの最小経度と最大経度にクリッピングすると、ポリゴンが子午線を横切らなくなるため、このファイルの処理が少し簡単になります。