Der gs://alphaearth_foundations-GCS-Bucket enthält COG-Dateien (Cloud Optimized GeoTIFF), die zusammen das jährliche Satellite Embedding-Dataset von AlphaEarth Foundations bilden. Sie enthält die jährlichen Einbettungen für die Jahre 2017 bis 2025.
Google verpflichtet sich, weiterhin jährlich Satellite Embedding-Ebenen zu erstellen. Bei einer erwarteten Änderung der Bereitstellung wird Google mindestens ein Jahr im Voraus benachrichtigen, sofern die Eingabedatenstreams von USGS und ESA, auf denen die Erstellung des Datensatzes beruht, weiterhin verfügbar sind.
Lizenz
Dieses Dataset ist unter CC-BY 4.0 lizenziert und erfordert die folgende Quellenangabe: „Das AlphaEarth Foundations Satellite Embedding Dataset wurde von Google und Google DeepMind erstellt.“
Ab Juli 2026 wird dieser Bucket als „Anbieter zahlt“ eingerichtet.
Verzeichnisstruktur
Sie sind nach Jahr in Verzeichnisse unterteilt. Das Verzeichnis für jedes Jahr ist in 120 Unterverzeichnisse unterteilt, eines für jede UTM-Zone. Die Namen der Unterverzeichnisse geben die Zonennummer und die Hemisphäre (N oder S) an.
Jedes Verzeichnis enthält mehrere COG-Dateien. Diese Dateien enthalten alle Pixeldaten für diese UTM-Zone.
Dateistruktur
Jede Datei hat eine Größe von 8.192 × 8.192 Pixel und 64 Kanäle. Die Größe jedes Pixels wurde nach der Anwendung der Dequantisierungszuordnung (siehe unten) so normalisiert, dass sie eine euklidische Länge von 1 hat.
Die Dateien enthalten Übersichtsebenen mit 4096 × 4096 Pixeln, 2048 × 2048 Pixeln usw. bis hin zu einer 1 × 1-Übersichtsebene der obersten Ebene. Diese Übersichtsebenen werden so erstellt, dass jeder Übersichtspixel der Mittelwert der Pixel mit der höchsten Auflösung unter diesem Übersichtspixel ist, wobei die Größe des Mittelwerts auf die Länge 1 normalisiert wurde.
Die Channels entsprechen in der Reihenfolge den Achsen A00 bis A63 des Satellite Embedding-Datasets. Die COGs enthalten auch diese Benennung für die Channels.
Der Wert jedes Pixels für jeden Channel ist eine signierte 8-Bit-Ganzzahl. Wie diese Werte den nativen Werten (im Bereich [-1, 1]) der Einbettungen zugeordnet werden, wird unter Dequantisierung beschrieben.
Der Wert -128 entspricht einem maskierten Pixel. Wenn sie in einem Channel vorhanden ist, ist sie in allen Channels vorhanden. Das wird in den Selbstkosten berücksichtigt (d.h., der Wert NoData ist auf -128 festgelegt).
Auch der Name jeder Datei enthält einige Informationen. Betrachten Sie beispielsweise die Datei mit dem Namen gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff.
Wie aus dem Dateinamen hervorgeht, ist diese Datei Teil der jährlichen Einbettung von 2019 für die UTM-Zone 1S (Zone 1, südliche Hemisphäre). Der Basisdateiname x8qqwcsisbgygl2ry-0000008192-0000000000 dient dazu, diese Datei mit dem entsprechenden Namen des Earth Engine-Satelliten-Einbettungsbilds zu verknüpfen. In diesem Beispiel entspricht diese Datei einem Teil des Earth Engine-Bildes GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry. Die beiden Dezimalstellen des Dateinamens geben an, wo sich die Werte dieses COG relativ zum Earth Engine-Bild befinden, als Y-Offset gefolgt von einem X-Offset. In diesem Fall liegt der Pixelursprung des COG bei (0, 8192) relativ zum Ursprung des Earth Engine-Bildes.
Das ist erforderlich, weil jedes Earth Engine-Bild (16.384 × 16.384 Pixel) unterteilt werden musste, damit die resultierenden COGs nicht zu unhandlich werden.
Dequantisierung
Um den unstrukturierten signierten 8-Bit-Wert (zwischen -127 und 127, da -128 als „no data“-Wert reserviert ist) in jedem Channel jedes Pixels in den analysebereiten Gleitkommawert (zwischen -1 und 1) zu transformieren, ist die folgende Zuordnung erforderlich:
- durch 127,5 teilen
- Quadratisch
- mit dem Vorzeichen des ursprünglichen Werts multiplizieren
In NumPy würde das so aussehen:
# values is a NumPy array of raw pixel values
de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)
In Earth Engine wäre der entsprechende Vorgang
var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());
Downsampling-Pyramiden erstellen
Wenn Sie eigene downsampling-Versionen oder externe Übersichten aus der Basissauflösungsebene dieser COGs erstellen möchten (z. B. nach dem Mosaiking mehrerer Dateien), müssen Sie so vorgehen: Standardtechniken für Rasterpyramiden (z.B. die Verwendung von gdaladdo mit „-r average“ für die Rohganzzahlwerte) führen nicht zu korrekten Ergebnissen.
- Dequantisieren: Die 8‑Bit-Ganzzahlen werden mit der unter Dequantisierung beschriebenen Methode in Gleitkommazahlen umgewandelt.
- Vektoren summieren: Führen Sie eine elementweise Summe der dequantisierten Vektoren aus.
- Normalisieren: Berechnen Sie die euklidische Norm des resultierenden Summenvektors und teilen Sie sie durch die Norm, um sie auf Einheitslänge zu normalisieren.
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.
Die Übersichtsebenen in den COGs wurden mit diesem Verfahren generiert. Wenn sie Ihren Anforderungen entsprechen, können Sie sie sofort ohne zusätzliche Berechnungen verwenden.
Manifest und Index
Eine Liste der Dateien in diesem Dataset finden Sie unter gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt.
Da anhand der Dateinamen nicht ermittelt werden kann, auf welchen Teil der Welt sie sich beziehen, wurde auch ein Index in drei Formen (GeoParquet, GeoPackage und CSV) in den Dateien gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquet, gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkg und gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv bereitgestellt. Dieser Index enthält einen Eintrag für jede Datei im Dataset. Die Informationen für jede Datei sind
- die Geometrie der Datei als WGS84 (d.h. EPSG:4326) Polygon. Im CSV-Format befindet sich diese Information in der Spalte
WKT. Weitere Informationen zur Berechnung finden Sie unter Geometrieverarbeitung. crs: Das Koordinatenreferenzsystem (CRS) der UTM-Zone, zu der dieses Bild gehört, als EPSG-Code, z. B.EPSG:32610.year: Das Jahr, das das Bild abdeckt.utm_zone: Die UTM-Zone des Bildes, z. B.10N.utm_west,utm_south,utm_east,utm_north: Die UTM-Grenzen des Rohpixel-Arrays. Hier wird keine Geometrieverarbeitung berücksichtigt und alle Pixel werden einbezogen, unabhängig davon, ob sie gültig sind.wgs84_west,wgs84_south,wgs84_east,wgs84_north: Der minimale und maximale Längen- und Breitengrad der WGS84-Geometrie.
Geometrieverarbeitung
Das Pixel-Array befindet sich nativ in einer UTM-Zone. In dieser UTM-Zone ist das Rechteck, das das Pixel-Array umschließt, also ein einfaches Rechteck. Dieser Begrenzungsrahmen wird in ein Polygon in WGS84 umgewandelt. Dieses Polygon enthält eine Reihe zusätzlicher Punkte, sodass seine Kanten den gekrümmten Linien in WGS84 folgen, in die die geraden Linien in UTM umgewandelt werden. Bei diesem Polygon wird die Gültigkeit von Pixeln im Bild nicht berücksichtigt, sondern nur die Grenzen des Pixel-Arrays des Bilds.
Das Polygon wird dann auf den minimalen und maximalen Längengrad der UTM-Zone des Bildes zugeschnitten. In der Praxis kann es vorkommen, dass einige gültige Pixel, die über den Rand der UTM-Zone hinausgehen, nicht berücksichtigt werden. Das Auslassen dieser Pixel aus dem Index sollte keine Probleme verursachen, da dieser Bereich durch ein Bild aus der benachbarten UTM-Zone abgedeckt wird.
Durch das Beschneiden auf den minimalen und maximalen Längengrad der UTM-Zone wird sichergestellt, dass kein Polygon den Antimeridian überschreitet. Das sollte die Verarbeitung der Datei etwas vereinfachen.