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 lizenziert und erfordert den folgenden Quellenverweis: „Das AlphaEarth Foundations Satellite Embedding-Dataset 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 sie 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., für sie ist der Wert NoData 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 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());
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. Dabei 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 umgewandelt 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.
Durch das Beschneiden auf den minimalen/maximalen Längengrad der UTM-Zone wird sichergestellt, dass kein Polygon den Antimeridian überschreitet. Das sollte die Verarbeitung dieser Datei etwas vereinfachen.