Cloud-Native Geospatiale Formate

Welche Probleme lösen Cloud-Native-Geoposition-Formate?

Cloud-native Formate lösen drei Probleme: ineffiziente Vollfile-Downloads, Integrationslücken bei Analyseplattformen und Herausforderungen bei der Datenerkennung. Traditionelle Formate wie Shapefile und GeoTIFF erfordern das Herunterladen vollständiger Dateien, um auf eine kleine Region zuzugreifen. COG, GeoParquet und STAC ermöglichen HTTP-Range-Anfragen, spaltengebundene Analysen und durchsuchbare Metadaten. Bevor wir uns mit Lösungen befassen, seien wir präzise über das, was wir lösen.

Das Präzisionszugriffsprinzip: Extrahieren Sie nur das, was Sie aus dem Ganzen benötigen.

Wie funktioniert Cloud-Optimized GeoTIFF (COG)?

COG reorganisiert Standard-GeoTIFF mit interner Kachelung, Übersichten und Kopfzeilenerster Struktur, die HTTP-Range-Anfragen ermöglicht, um bestimmte Pixel zu lesen, ohne die vollständige Datei herunterzuladen. Das Lesen von 1km² aus einem 50GB-Raster dauert 14 Minuten (vollständiger Download) bis 2,3 Sekunden (Range-Anfrage). COG ist kein neues Format - es ist ein GeoTIFF, das auf eine bestimmte Art und Weise organisiert ist, um einen effizienten Cloud-Zugriff zu ermöglichen. 2023 wurde COG als offizieller OGC-Standard angenommen.

Wie COG funktioniert

Eine Standard-GeoTIFF speichert Pixel in sequenziellen Streifen. Um ein beliebiges Pixel zu lesen, müssen Sie normalerweise von Anfang der Datei an lesen. Eine COG reorganisiert diese Struktur mit drei Hauptfunktionen:

Kachel-basierter Zugriff: Fordern Sie nur die Zelle an, die Sie benötigen, lassen Sie den Rest unberührt.

COGs erstellen: Was tatsächlich wichtig ist

gdal_translate input.tif output_cog.tif \
  -of COG \
  -co COMPRESS=DEFLATE \
  -co OVERVIEW_RESAMPLING=LANCZOS \
  -co BLOCKSIZE=512

Kompression: DEFLATE bietet gute Komprimierungsverhältnisse mit schneller Dekompression. JPEG ist für Bilder geeignet, bei denen ein gewisser Qualitätsverlust akzeptabel ist (70-80 % kleinere Dateien).

Kachel-Größe: 512x512 kann die Leistung bei großflächigen Abfragen auf Kosten von etwas mehr Datenübertragung für kleine Abfragen verbessern.

Vertiefung: GeoParquet

Wenn COG das Rasterproblem löst, behebt GeoParquet Cloud-native Vektordaten. Aber es ist mehr als "Shapefile, aber schneller."

Der spaltenbasierte Vorteil

Shapefiles und File Geodatabases speichern Daten Zeile für Zeile. Um ein beliebiges Attribut einer beliebigen Funktion zu lesen, müssen Sie typischerweise durch Datensätze sequenziell scannen. Parquet speichert Daten Spalte für Spalte - optimiert für Analyseanfragen, die auf bestimmte Attribute zugreifen, über Datensätze aggregieren oder basierend auf Werten filtern.

Zeilen vs. Spalten: Zufälliger Zugriff gegenüber präziser Auswahl dessen, was Sie benötigen.

GeoParquet erstellen: Praktischer Code

import geopandas as gpd

# Read source data
gdf = gpd.read_file("input.shp")

# Write to GeoParquet
gdf.to_parquet(
    "output.parquet",
    compression="snappy",  # Fast decompression
    index=False
)

Wenn Sie von ArcGIS wechseln, deckt unser ArcPy zu GeoPandas Übersetzungsleitfaden den kompletten Workflow-Konvertierungsprozess ab.

Vertiefung: STAC (SpatioTemporal Asset Catalog)

COG und GeoParquet lösen Zugriffs- und Analyseprobleme. STAC löst Entdeckung.

STAC ist eine Spezifikation für Metadaten, nicht für ein Datenformat. Es definiert eine Standard-JSON-Struktur zur Beschreibung von Geospatialbestanden - was sie enthalten, wo sie sich befinden, wann sie erfasst wurden und wie man auf sie zugreift.

Warum dies im großen Maßstab wichtig ist

Überdenken Sie: 10 Jahre Luftbildaufnahmen, Satellitendaten von 3 Anbietern, LiDAR aus 5 Erfassungsprojekten und abgeleitete Produkte wie DEMs. Ohne STAC erfordert die Suche nach relevanten Daten die Kenntnis von Ordnerstrukturen, das Verständnis von Namenskonventionen und das manuelle Überprüfen von Datumsbereichen. Mit STAC fragen Sie eine einzelne API ab:

from pystac_client import Client

catalog = Client.open("https://your-stac-api.com")

# Find all Sentinel-2 imagery for summer 2023
results = catalog.search(
    collections=["sentinel-2-l2a"],
    bbox=[-122.5, 47.5, -122.0, 48.0],
    datetime="2023-06-01/2023-08-31",
    query={"eo:cloud_cover": {"lt": 20}}
)

for item in results.items():
    print(f"{item.id}: {item.datetime}")

Wann sollten Sie NICHT diese Formate verwenden

Cloud-native Formate sind nicht überall überlegen. Hier ist, wenn traditionelle Ansätze möglicherweise angemessen sind:

Integration mit modernen Datenplattformen

Der strategische Wert von Cloud-nativen Geospatialformaten ist die Integration mit der Enterprise-Dateninfrastruktur.

df = spark.read.format("geoparquet").load("s3://bucket/parcels/")
df.select(st_area("geometry"), st_centroid("geometry")).show()

SELECT parcel_id, ST_AREA(geometry) as area_m2
FROM parcels_ext
WHERE ST_CONTAINS(aoi_polygon, geometry);

Der moderne Stack: Cloud-native Formate integrieren sich nahtlos mit der Enterprise-Dateninfrastruktur.

Migrationsstrategie: Ein praktischer Fahrplan

Migration ist kein Wochenendprojekt. Hier ist ein schrittweiser Ansatz, der Risiken minimiert.

Der Modernisierungsweg: jeder Schritt leichter als der letzte.

Fragen, die Sie vorher stellen sollten