Cloud-optimierte GeoTIFFs (COGs) in der Earth Engine

Mit Google Earth Engine können Sie Rasterdaten verarbeiten, die in Ihren eigenen Google Cloud Storage-Buckets (GCS) gespeichert sind. Mit Cloud-optimierten GeoTIFFs (COGs) können Sie direkt in Earth Engine auf Ihre Daten zugreifen und sie analysieren, ohne die Pixel in den Asset-Speicher von Earth Engine aufnehmen zu müssen.

Dieser Cloud-First-Ansatz bietet mehrere Vorteile, insbesondere bei der Verwaltung großer Datensätze oder der Einbindung von Earth Engine in umfassendere Google Cloud-Workflows oder externe Tools und Plattformen.

Warum Cloud Storage und COGs verwenden?

  • Flexibilität und Interoperabilität:Speichern Sie Ihre Daten in Standard-Cloud Storage-Buckets, auf die andere Tools und Dienste zugreifen können. Unabhängig davon, ob Sie die Daten direkt hochladen oder aus Earth Engine exportieren, dient Cloud Storage als einzige verlässliche Quelle für Earth Engine- und externe Workflows.
  • Steuerelemente für Daten und ausgehender Traffic:Wenn Sie Daten in Cloud Storage speichern, stehen Ihnen standardmäßige Funktionen zur Verwaltung von Objektspeichern zur Verfügung. So können Sie Ihre Daten mit Cloud Storage-Funktionen wie „Zahler zahlt“ oder öffentlichen Buckets herunterladen, migrieren oder freigeben und den Zugriff mit dem Standard- Cloud IAM verwalten.
  • Flexible Skalierung: Vermeiden Sie Speicherlimits in Earth Engine. Cloud Storage bietet eine praktisch unbegrenzte, selbstverwaltete Speicherskalierung bis in den Petabyte-Bereich.
  • Keine Wartezeit für die Aufnahme:Die Registrierung eines COG ist schnell abgeschlossen, da Earth Engine nur die Metadaten (z. B. Projektion und Abmessungen) aus dem Dateikopf für die Indexierung und Validierung liest. Die eigentlichen Pixeldaten verbleiben in Cloud Storage und werden bei Bedarf während der Berechnung gelesen, sodass keine separate Aufgabe für die Aufnahme erforderlich ist.

COG-Workflows in Earth Engine

Earth Engine unterstützt bidirektionale Workflows mit COGs in Cloud Storage: Sie können COGs direkt aus GCS in Earth Engine lesen und Berechnungsergebnisse aus Earth Engine direkt als COGs in GCS schreiben.

COGs aus Cloud Storage lesen

Es gibt zwei Möglichkeiten, in GCS gehostete COGs in Earth Engine zu verwenden:

  1. Direktes Laden (ee.Image.loadGeoTIFF): Laden Sie ein einzelnes Bild direkt über den GCS-URI. Diese Methode eignet sich am besten für schnelle Tests, Ad-hoc-Analysen oder temporäre Daten:

    JavaScript

    var image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif');

    Python

    image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif')

    Vollständige Beispiele finden Sie unter Bilder aus Cloud-GeoTIFFs.

  2. Registrierte Assets: Registrieren Sie ein oder mehrere COGs als ein Earth Engine-Asset mit einem Upload-Manifest (siehe die Anleitung zur COG-Registrierung). Dies ist der empfohlene Weg für Produktions-Workflows, insbesondere beim Erstellen von Bildsammlungen.

Funktion Direktes Laden (loadGeoTIFF) Registriertes Asset (Manifest)
Einrichtung Keine (nur GCS-URI) Manifest (Python-Client, CLI oder REST)
Leistung Standard (Kopf wird beim Lesen gelesen) Optimiert (bei der Erstellung indexiert)
Verwaltung Kein Asset erstellt Wird auf das Kontingent für die Anzahl der Assets angerechnet, nicht auf den Speicher.
Anwendungsbeispiel Prototyping, Ad-hoc-Analyse Produktions-Workflows, die schnelles Lesen erfordern.

COGs in Cloud Storage schreiben

Wenn Sie Earth Engine-Berechnungsergebnisse als COGs in Ihrem Cloud Storage-Bucket speichern möchten, verwenden Sie die Export.image.toCloudStorage Batch-Exportfunktion (siehe Bilder exportieren) und legen Sie den cloudOptimized Parameter auf true in formatOptions fest. Dadurch wird Earth Engine angewiesen, das Bild zu kompilieren und als vollständig konformes COG direkt in Ihren GCS-Bucket zu schreiben.

Unterstützte Cloud Storage-Bucket-Standorte

Damit Earth Engine auf Ihren Cloud Storage-Bucket zugreifen kann, muss sich der Bucket in einer der folgenden Rechenzentrumsregionen oder multiregionalen Standorten befinden:

  • Die multiregionale Region us
  • Jede US-Dual-Region, die us-central1 umfasst
  • Die Region us-central1

Wenn sich Ihr Bucket in einem anderen regionalen Rechenzentrum befindet, lehnt Earth Engine Registrierungs- und Leseanfragen ab. Earth Engine greift nur auf COGs zu, die in Google Cloud Storage-Buckets gespeichert sind. Externe Cloud-Speicheranbieter und generische HTTP-URLs werden nicht unterstützt.

Earth Engine-Exportspezifikationen für COGs

Wenn Sie Analyseergebnisse aus Earth Engine mit Export.image.toCloudStorage mit cloudOptimized: true in formatOptions exportieren, wendet der integrierte Exporter von Earth Engine automatisch die folgenden Standards an:

  • Dateistruktur:Erstellt ein BigTIFF (BIGTIFF=YES) mit interner Kachelung (TILED=YES) und kopiert alle Übersichten an den Anfang der Datei.
  • Automatische Übersichten:Wenn die Abmessungen des Ausgaberasters 512 × 512 Pixel oder größer sind, erstellt Earth Engine automatisch fünf Ebenen von Übersichten mit Zweierpotenzen ([2, 4, 8, 16, 32]). Earth Engine wählt die Methode für das Resampling der Übersicht dynamisch basierend auf dem Datentyp der Ausgabepixel aus: Kubisches Resampling für Gleitkomma-Bilder und Nearest-Neighbor-Resampling für alle anderen Ganzzahl- oder diskreten Bilder.
  • Standardkomprimierung und ‑kachelung:Earth Engine exportiert COGs mit 256 × 256 Pixel-Blockkachelung und LZW-Komprimierung (COMPRESS=LZW). Komprimierung und Kachelabmessungen können in formatOptions nicht angepasst werden.
  • Automatische Shard-Erstellung: Wenn ein exportiertes Raster groß ist (mehr als 4 GiB unkomprimiert), unterteilt Earth Engine den Export automatisch in mehrere räumliche Kacheln mit dem Namen baseFilename-yMin-xMin (siehe Exporte großer Dateien).
  • Limits für die Shard-Erstellung überschreiben:Wenn Sie große Raster (bis zu einem Limit von 16 GiB unkomprimiert und 131.072 Pixel pro Kante) als eine einzelne Datei ohne Shard-Erstellung exportieren möchten, geben Sie fileDimensions in formatOptions an. Jeder Wert muss ein positives ganzzahliges Vielfaches der Kachelgröße sein (standardmäßig 256, z. B. [65536, 65536]). Da fileDimensions die maximale Dateigröße und nicht das Ausgabebegrenzungsfeld festlegt, wird durch die Angabe eines hohen Limits der Export in eine einzelne Datei erzwungen, ohne dass genaue Rasterberechnungen erforderlich sind. Sie können auch skipEmptyFiles: true übergeben, um zu verhindern, dass leere Hintergrundkacheln generiert werden.
  • Kompromisse bei der Optimierung:Wenn Sie große Exporte konfigurieren, wägen Sie den Kompromiss zwischen der Anzahl der Dateien und der Exportgeschwindigkeit ab. Wenn Sie kleinere fileDimensions oder shardSize angeben, werden mehr Dateifragmente erstellt, aber die parallele Verarbeitung durch Backend-Worker wird maximiert, was zu schnelleren Exportzeiten führt. Wenn Sie hingegen Limits überschreiben, um eine einzelne große Datei zu generieren, wird die Dateiverwaltung und die Datenweitergabe vereinfacht, die Exportzeiten können sich jedoch aufgrund der Zusammenstellung einer einzelnen Datei und von E/A-Engpässen verlängern. Bei sehr großen COG-Exporten mit einer einzelnen Datei, die sich dem Limit von 16 GiB unkomprimiert nähern (insbesondere bei Bildern, die sich nicht gut komprimieren lassen), kann auch die temporäre Speicherkapazität während der Erstellung von Übersichten und COGs überschritten werden. Wenn ein Export fehlschlägt, sollten Sie die Datei in kleinere Dateien aufteilen oder einen Standard-GeoTIFF-Export extern konvertieren.

COG-Erstellung außerhalb von Earth Engine anpassen

Der direkte Export mit cloudOptimized: true ist zwar die einfachste Möglichkeit, für die meisten Workflows sofort einsatzbereite COGs zu generieren, Sie können aber auch ein Standard-GeoTIFF (cloudOptimized: false, Standardeinstellung) exportieren und es mit externen Tools wie GDAL selbst in ein COG konvertieren. Ein zweistufiger Export- und Konvertierungsworkflow kann in folgenden Fällen nützlich sein:

  • Komprimierung und Layout anpassen: Passen Sie Blockgrößen (z. B. 512x512), Prädiktoren, Methoden für das Resampling von Übersichten oder Komprimierungscodecs (z. B. ZSTD) an Ihren Datensatz an (siehe COGs vorbereiten).
  • Kapazitätsfehler bei massiven Exporten mit einer einzelnen Datei vermeiden:Wenn Sie die Erstellung von Übersichten und das Umschreiben des COG-Layouts während des Exports überspringen, werden der Speicher- und der temporäre Speicheraufwand reduziert, sodass es weniger wahrscheinlich ist, dass bei sehr großen Exporten mit einer einzelnen Datei Kapazitätslimits erreicht werden.
  • Ausführungszeit für Earth Engine-Exporte verkürzen:Wenn Sie die Erstellung von Übersichten und die COG-Formatierung in Ihre eigene Compute-Umgebung auslagern, wird die Earth Engine-Exportphase verkürzt.

Kostenüberlegungen und Speicherklassen

Wenn Sie registrierte COG-Assets analysieren, fallen bei Lesevorgängen aus Earth Engine keine Gebühren für Cloud Storage-Lesevorgänge oder Datenabrufe für Ihr Google Cloud-Projekt an.

Cloud Storage berechnet Ihnen in erster Linie die monatlichen Standardgebühren für die Speicherung inaktiver Daten (GB/Monat) sowie alle Gebühren für die Datenübertragung durch externe Clients oder für ausgehenden Netzwerktraffic (abhängig vom Bucket-Standort und der Netzwerkkonfiguration des Clients).

Empfehlungen für Speicherklassen

  • Standard Storage (empfohlen) : Standard Storage eignet sich am besten für aktive Earth Engine-Workflows. Da es keine Regeln für die Mindestspeicherdauer gibt, können Sie temporäre COGs frei überschreiben, aktualisieren oder löschen, ohne dass Gebühren für die vorzeitige Löschung anfallen. Wenn Sie oder Ihre Mitarbeiter außerdem mit Desktop-GIS-Software, GDAL-Skripts oder Machine Learning-Notebooks außerhalb von Earth Engine auf den Bucket zugreifen, fallen bei Standard Storage keine zusätzlichen Gebühren für den Einzelhandel an.
  • Nearline Storage, Coldline Storage und Archive Storage:Alle Cloud Storage-Klassen bieten den gleichen Zugriff mit niedriger Latenz und den gleichen Durchsatz wie Standard Storage. Es gibt also keine Einbußen bei der Leseleistung, wenn Sie in Earth Engine kältere Speicherstufen verwenden. Earth Engine-Berechnungen können diese Stufen zwar auch lesen, ohne dass Gebühren für den Einzelhandel für den Datenabruf anfallen, aber die Einzelhandelsregeln von Cloud Storage erzwingen strenge Mindestspeicherdauern (30 Tage für Nearline Storage, 90 Tage für Coldline Storage, 365 Tage für Archive Storage). Wenn Sie Dateien vor Ablauf der Mindestspeicherdauer ändern oder löschen, fallen Gebühren für die vorzeitige Löschung an. Außerdem fallen bei Zugriffen auf kalte Objekte von einem externen Client-Tool aus kostspielige Gebühren für den Datenabruf an.

Ausführliche Informationen zu Einzelhandelspreisen und Richtlinien zur Mindestspeicherdauer finden Sie im Google Cloud Storage-Preisleitfaden.

Allgemeiner Workflow

Typische Workflows für die Verwendung von COGs in Earth Engine umfassen die folgenden Schritte:

Für den Import externer Daten :

  • Optimieren:Konvertieren Sie Ihre Rasterdateien mit externen Tools (z. B. GDAL, Skripts für lokale Arbeitsstationen oder Cloud-Verarbeitungspipelines) in das COG-Format.
  • Hochladen:Laden Sie die COGs in einen unterstützten Cloud Storage-Bucket in us-central1 oder einer multiregionalen Region in den USA hoch.
  • Berechtigungen: Achten Sie darauf, dass Sie und alle Projektmitarbeiter Lesezugriff auf die Dateien in Cloud Storage haben (siehe COG Berechtigungen).
  • Registrieren: Registrieren Sie die COGs mit der Python-Clientbibliothek, dem earthengine Befehlszeilen tool oder der REST API als Earth Engine-Assets (siehe COG Registrierung).

Für den Export von Ergebnissen :

  • Exportieren: Führen Sie einen Batch-Export von Earth Engine nach Cloud Storage aus, wobei cloudOptimized auf true gesetzt ist (siehe Bilder exportieren).
  • Registrieren (optional): Registrieren Sie das exportierte COG zur weiteren Analyse wieder in Earth Engine als neues Asset (siehe COG-Registrierung).

Startbereit? Folgen Sie der detaillierten Anleitung zur COG-Registrierung, um Ihr erstes Asset zu registrieren.