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 2024.
Lizenz
Dieses Dataset ist unter der Lizenz CC-BY 4.0 verfügbar und erfordert den folgenden Quellenverweis: „Das Satellite Embedding-Dataset der AlphaEarth Foundation wird von Google und Google DeepMind erstellt.“
Dieser Bucket ist als „requester pays“ eingerichtet. Für das Herunterladen von Daten können daher Egress- und andere Gebühren anfallen.
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 die entsprechende 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. Die Größe des Mittelwerts wurde normalisiert, sodass er die Länge 1 hat.
Die Channels entsprechen in der Reihenfolge den Achsen A00 bis A63 des Satellite Embedding-Datasets. Die Channels werden in den COGs ebenfalls so benannt.
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 unten beschrieben.
Der Wert -128 entspricht einem maskierten Pixel. Wenn sie in einem Channel vorhanden ist, ist sie in allen Channels vorhanden. Die Selbstkosten spiegeln dies wider (d.h., der Wert NoData ist auf -128 festgelegt).
Der Name jeder Datei enthält ebenfalls einige Informationen. Betrachten Sie beispielsweise die Datei mit dem Namen gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff.
Wie oben beschrieben, ist diese Datei Teil der jährlichen Einbettung von 2019 und befindet sich in der 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 Satellite Embedding-Bildes 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 liegt daran, dass jedes Earth Engine-Bild (16.384 × 16.384 Pixel) unterteilt werden musste, damit die resultierenden COGs nicht zu unhandlich werden.
Dequantisierung
Um den rohen signierten 8-Bit-Wert (der zwischen -127 und 127 liegt, da -128 als „no data“-Wert reserviert ist) in jedem Kanal jedes Pixels in den analysebereiten Gleitkommawert (der zwischen -1 und 1 liegt) 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 ausgedrückt:
# 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 Basisschicht dieser COGs erstellen möchten (z. B. nach dem Mosaikieren mehrerer Dateien), müssen Sie die unten beschriebene Vorgehensweise verwenden. Mit Standardtechniken für Rasterpyramiden (z.B. mit gdaladdo mit -r average für die Roh-Ganzzahlwerte) werden keine korrekten Ergebnisse erzielt.
- Dequantisieren: Konvertieren Sie die 8‑Bit-Ganzzahlen mit der oben beschriebenen Methode in Gleitkommazahlen.
- Vektoren summieren: Führen Sie eine elementweise Summe der dequantisierten Vektoren aus.
- Normalisieren: Berechnen Sie die euklidische Norm des resultierenden Summenvektors und teilen Sie ihn durch die Norm, um ihn 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 einfach verwenden und müssen keine Berechnungen durchführen.
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 Bereich 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 dieser Geometrie finden Sie unten. 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/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 umgebende Rechteck des Pixel-Arrays 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 transformiert werden. Bei diesem Polygon wird die Gültigkeit/Ungültigkeit von Pixeln im Bild nicht berücksichtigt, sondern nur die Grenzen des Pixelarrays des Bildes.
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 hinausragen, nicht berücksichtigt werden. Das Auslassen dieser Pixel aus dem Index sollte keine Probleme verursachen, da ein Bild aus der benachbarten UTM-Zone diesen Bereich abdecken sollte.
Wenn Sie das Clipping auf den minimalen/maximalen Längengrad der UTM-Zone beschränken, überquert kein Polygon den Antimeridian. Das sollte die Verarbeitung der Datei etwas vereinfachen.