GeoGrapher: Eine Python-Bibliothek zur Erstellung von objektzentrierten ML-Datensätzen aus Fernerkundungsdaten

Ein Auge im All beobachtet die Erde, erfasst Veränderungen und verwandelt sie in wertvolle Erkenntnisse – für Entscheidungsträger in Wirtschaft und Regierung, für Wissenschaftler, Journalisten und Aktivisten. Satellitenbilder in Kombination mit modernen Machine-Learning-Techniken haben die Fernerkundung revolutioniert und ermöglichen tiefere Einsichten als je zuvor. Doch bevor Machine-Learning-Modelle aus diesen Daten Muster erkennen, Objekte identifizieren oder Vorhersagen treffen können, braucht es eine solide Grundlage: einen sorgfältig zusammengestellten Datensatz – und genau hier beginnt die eigentliche Herausforderung.

Besonders herausfordernd ist die Erstellung dessen, was wir hier als objektzentrierte Fernerkundungsdatensätze bezeichnen – Datensätze, bei denen die Daten um spezifische geografische Objekte herum organisiert werden. Im Gegensatz zu dem, was man als flächenzentrierte Datensätze bezeichnen könnte – also Datensätze, die mit Fernerkundungsbildern beginnen und erst danach Objekte annotieren – verfolgt ein objektzentrierter Datensatz eine umgekehrte Herangehensweise: Hier startet man mit einer vordefinierten Menge an Objekten und deren Positionen und sammelt anschließend die relevanten Fernerkundungsbilder. Diese Methode eignet sich besonders für Anwendungen, bei denen es darum geht, spezifische Objekttypen wie Gebäude, Straßen oder Minen zu erkennen oder zu analysieren, anstatt eine großflächige Landbedeckungsklassifikation durchzuführen.

Doch der Weg von einer Menge an Objekten – die im einfachsten Fall nur eine Liste von Breiten- und Längengraden sein kann, aber auch z.B. Segmentierungsmasken umfassen kann – hin zu einem vollständigen Datensatz ist oft überraschend anspruchsvoll. Genau hier setzt GeoGrapher an.

GeoGrapher ist eine Open-Source Python-Bibliothek, die den Prozess der Erstellung objektzentrierter ML-Datensätze aus Fernerkundungsdaten vereinfacht. Durch das systematische Verfolgen räumlicher Beziehungen zwischen Objekten und Satellitenbildern automatisiert sie zentrale Schritte der Datensatzvorbereitung. So können sich ML- und Fernerkundungsspezialisten stärker auf die Modellentwicklung konzentrieren, anstatt wertvolle Zeit mit Datenaufbereitung zu verbringen.

Im nächsten Abschnitt gehen wir auf die Herausforderungen ein, die sich ergeben, wenn man aus einer Liste von Objekten und deren Positionen (oder allgemeiner: aus Begrenzungsrahmen oder Segmentierungsmasken) einen ML-Datensatz aus Fernerkundungsdaten erstellt – und zeigen, wie GeoGrapher diese Probleme löst.

Beispiel: Ein Datensatz für Sportstadien

Um die Herausforderungen bei der Erstellung objektzentrierter Datensätze zu verdeutlichen, betrachten wir die Aufgabe der semantischen Segmentierung von Sportstadien. Unser Ziel ist es, einen Datensatz zu erstellen, in dem jeder Satellitenbildausschnitt eine Segmentierungsmaske enthält, die genau angibt, welche Pixel zu einem Stadion gehören.

Bei dieser Aufgabe arbeitet man mit zwei grundlegenden Typen von Fernerkundungsdaten:

• Vektordaten: Sie repräsentieren diskrete geografische Objekte wie Punkte, Linien oder Polygone. In unserem Fall wird jedes Stadion als Polygon dargestellt – eine Liste von Breiten- und Längengraden, die seine Begrenzung definieren. Solche Objekte werden als Vektor-Features bezeichnet.

• Raster sind bildähnliche Daten, bei denen jedem Pixel eine geografische Position zugeordnet ist. Die Satellitenbilder in unserem Datensatz sind Beispiele für Rasterdaten, wobei die Pixelwerte die RGB-Intensitäten repräsentieren. Neben optischen Aufnahmen kann jedes Pixel in einem Raster auch weitere georäumliche Informationen speichern, etwa Höhen, Feuchtigkeitswerte, die Bevölkerungsdichte oder Messwerte aus anderen Bereichen des elektromagnetischen Spektrums wie Infrarot- oder Radardaten.

Auch wenn unser Hauptfokus auf Segmentierung liegt, kann derselbe Datensatz auch für andere Computer-Vision-Aufgaben genutzt werden, etwa für die Objekterkennung (bounding boxes um Stadien¹). Unabhängig von der konkreten Aufgabe erfordert die Erstellung des Datensatzes eine präzise räumliche Passung der Stadion-Polygone zu den Satellitenbildern, um korrekte Labels zu gewährleisten.

Auf den ersten Blick scheint es einfach, aus einer Liste von Stadien einen Segmentierungsdatensatz zu erstellen: Satellitenbilder abrufen und Segmentierungsmasken generieren. In der Praxis treten jedoch mehrere Herausforderungen auf. Würde man den Datensatz manuell – ohne GeoGrapher – erstellen, wäre der Prozess mit zahlreichen Einzelschritten verbunden:

Angenommen, unsere ML-Aufgabe ist die semantische Segmentierung. Würde man dies ohne GeoGrapher von Grund auf umsetzen, müsste man folgende Schritte durchlaufen, um einen entsprechenden Datensatz aus einer Liste von Stadien und Polygonen zu deren geografischer Lage und räumlicher Ausdehnung zu erstellen:

1. Herunterladen von Rasterdaten: Man müsste Rasterdaten für die Stadionstandorte abrufen, beispielsweise Satellitenbilder der Sentinel-2-Mission der Europäischen Weltraumorganisation (ESA).

2. Datensatz zurechtschneiden: Satelliten-Raster sind oft sehr groß. Die Sentinel-2-Kacheln der ESA haben beispielsweise eine Bildgröße von 10.980 × 10.980 Pixeln und decken jeweils eine Fläche von 100 km × 100 km ab. Abhängig von der Anzahl der spektralen Bänder kann eine einzelne Kachel dabei bis zu 1 GB oder mehr an Speicherplatz belegen. Moderne Deep-Learning-Techniken erfordern den Einsatz von GPUs, und diese großen Raster passen nicht vollständig in den Arbeitsspeicher. Daher muss ein Datensatz aus kleineren Rasterausschnitten erstellt werden, die für das Training des ML-Modells geeignet sind.
   

3. Die Art und Weise, wie die Raster zugeschnitten werden, hängt von der jeweiligen Anwendung ab. In unserem Beispiel sind Stadien im Vergleich zu den 100 km × 100 km großen Rastern sehr klein. Wenn man diese Raster einfach in ein regelmäßiges Gitter aus kleineren Ausschnitten unterteilt, würde dies weiterhin zu einem starken Ungleichgewicht zwischen Vorder- und Hintergrundklassen im Datensatz führen. Zudem ist möglicherweise nicht bekannt, ob die vollständigen 100 km × 100 km großen Raster zusätzliche, nicht annotierte Stadien enthalten.

   Diese False Negatives – also Stadien, die auf den Satellitenbildern sichtbar sind, aber nicht in den Labels erfasst wurden – könnten das Modell während des Trainings in die Irre führen. Um dies zu vermeiden, ist es kann es sinnvoller sein, einen Datensatz mit kleineren gezielten Ausschnitten um die Stadien herum zu erstellen.

4. Erstellen von Labels: Um Labels zu erstellen, müssen die Stadion-Polygone (im Wesentlichen Listen von Längen- und Breitengraden) in Segmentierungsmasken umgewandelt werden. Eine Segmentierungsmaske ist ein Rasterbild, in dem jedes Pixel angibt, ob es zu einem Stadion gehört oder nicht. Bei binärer Segmentierung unterscheidet die Maske lediglich zwischen Stadion (Vordergrund) und Nicht-Stadion (Hintergrund). In einer Multi-Klassen-Segmentierung muss zusätzlich zwischen verschiedenen Objekttypen differenziert werden, etwa zwischen Fußball- und Leichtathletikstadien. Damit die Labels zuverlässig sind, ist eine exakte Ausrichtung der Masken auf die Satellitenbilder entscheidend – selbst kleine Abweichungen könnten die Modellleistung beeinträchtigen.

Die Herausforderungen

Versucht man, diesen Prozess umzusetzen, stößt man schnell auf Probleme. In allen Fällen besteht die zentrale Schwierigkeit darin, die räumlichen Beziehungen zwischen Vektor-Features (Stadien) und Rastern (Satellitenbildern) zu verwalten. Konkret müsste man nachverfolgen, welche Vektor-Features in welchen Rastern enthalten sind oder mit ihnen überlappen, um die Erstellung des Datensatzes zu optimieren.

1. Herunterladen von Rasterdaten: Ein naiver Ansatz würde für jedes Stadion ein separates Raster herunterladen. Allerdings treten Stadien häufig in Clustern auf, etwa in einem Olympischen Dorf mit mehreren Sportstätten. Wenn jedes Stadion einen neuen Raster-Download auslöst, führt das zu redundanten Bildern, in denen dieselbe Region mehrfach vorkommt. Dies hat zwei wesentliche Nachteile: Einerseits ist es ineffizient, da überflüssige Downloads den Speicherbedarf und die Verarbeitungskosten erhöhen. Andererseits entsteht ein Klassenungleichgewicht, weil Stadien in Clustern überrepräsentiert sind und den Datensatz verzerren. Eine starke Ungleichverteilung der Klassen kann das Training eines ML-Modells erheblich beeinträchtigen. Dies lässt sich vermeiden, indem nach jedem runterladen eines Rasters überprüft wird, welche weiteren Objekte darin enthalten sind.

2. Zuschneiden von Rasterdaten: Wenn man für jedes Stadion naiv einen separaten Ausschnitt extrahiert, führt dies dazu, dass sich die Ausschnitte um Stadion-Cluster überlappen können – dasselbe Stadion taucht dann in mehreren Ausschnitten mehrfach auf. Wie bereits beim Herunterladen der Rasterdaten verzerrt dies den Datensatz, führt zu einem Klassenungleichgewicht und beeinträchtigt das Modelltraining. Auch hier gilt, dass man die Einschlussbeziehungen zwischen Vektor-Features und Rastern kennen muss um dieses Ungleichgewicht zu vermeiden.

3. Erzeugen von Labels: Bei der Umwandlung von Stadion-Polygonen in Segmentierungsmasken muss man sicherstellen, dass jedes Raster korrekt mit den relevanten Vektor-Features ausgerichtet ist. Das bedeutet, dass man bestimmen muss, welche Stadien mit welchem Raster überlappen, um präzise pixelgenaue Labels zu erzeugen.

4. Aktualisieren des Datensatzes: Wenn neue Stadien hinzugefügt werden, muss man prüfen, ob sie bereits von vorhandenen Rastern abgedeckt sind oder ob neue Daten heruntergeladen werden müssen. Würde man naiv für jedes zusätzliche Stadion ein neues Raster herunterladen, würde man dieselbe Redundanz und dasselbe Klassenungleichgewicht erzeugen, das bereits durch Clusterbildung entsteht. Indem man nachverfolgt, welche Vektor-Features bereits in vorhandenen Rastern enthalten sind, kann man den Datensatz erweitern, ohne unnötige Downloads zu verursachen und das Klassenungleichgewicht minimieren.

5. Vermeiden von Datenlecks: Um ein ML-Modell zu trainieren, muss der Datensatz in Trainings-, Validierungs- und Testdaten aufgeteilt werden. Wenn die Raster einfach naiv in einen Naive Aufteilungen basierend auf Rastern oder Vektor-Features können jedoch zu einem Datenleck (data leakage) führen, wenn Teile desselben Stadions in mehreren Splits auftauchen. Dieses Problem kann entstehen, weil Stadien sich über mehrere Raster erstrecken können, sodass unterschiedliche Ansichten desselben Objekts sowohl im Trainings- als auch im Validierungsset landen.
   
   Um ein Datenleck zu vermeiden, muss nachverfolgt werden, welche Stadien in welchen Rastern enthalten sind, und es muss sichergestellt werden, dass alle Raster mit demselben Stadion zur gleichen Datensatz-Aufteilung gehören. Dadurch wird gewährleistet, dass das Modell auf tatsächlich ungesehenen Daten evaluiert wird, was zu verlässlichen Performancemetriken führt. Die Nachverfolgung, welche Raster welche Objekte enthalten, ist jedoch nicht nur bei der Datensatz-Erstellung nützlich. Nach dem Training eines Modells kann sie auch für weiterführende Analysen, Debugging oder Updates hilfreich sein, da man gezielt alle Raster abrufen kann, die ein bestimmtes Stadion enthalten.
   

Bipartite Graphen als Lösung!

Alle wichtigen Schritte bei der Erstellung des Datensatzes beruhen darauf, nachzuverfolgen, welche Vektor-Features (Stadien) in welchen Rastern (Satellitenbildern) enthalten sind oder mit ihnen überlappen. Eine elegante Möglichkeit, diese Beziehungen darzustellen, ist ein bipartiter Graph.

Was ist ein bipartiter Graph?

Ein bipartiter Graph ist eine spezielle Art von Graph, also eine Struktur aus Knoten und Kanten (siehe Abbildung). Das Besondere daran ist, dass sich die Knoten in zwei getrennte Gruppen aufteilen lassen, wobei jede Kante immer einen Knoten aus der einen und einen aus der anderen Gruppe verbindet – es gibt also keine Kanten innerhalb einer Gruppe.

In unserem Fall stehen die Knoten für Vektor-Features (Stadien) und Raster (Satellitenbilder). Eine Kante verbindet ein Vektor-Feature mit einem Raster genau dann, wenn das Feature entweder vollständig im Raster enthalten ist oder es schneidet. Da es zwei verschiedene Arten von räumlichen Beziehungen erfasst gibt (Einschluss und Überschneidung), gibt es auch zwei Arten von Kanten. Diese lassen sich beispielsweise durch unterschiedliche Farben visualisieren (z. B. Blau und Grün in der obigen Abbildung).

Die Verwendung eines bipartiten Graphen ermöglicht es, die zuvor genannten Probleme zu umgehen. Allerdings ist die manuelle Verwaltung dieser Beziehungen mühsam. Die neue GeoGrapher-Bibliothek automatisiert diesen Prozess und macht eine manuelle Verwaltung überflüssig.

Mit GeoGrapher, einer neuen von dida entwickelten Open-Source Python-Bibliothek, wird die Erstellung objektzentrierter ML-Datensätze deutlich vereinfacht. GeoGrapher erleichtert den Aufbau strukturierter, annotierter Datensätze für das Training und die Inferenz von Machine-Learning-Modellen und adressiert dabei zentrale Herausforderungen wie künstliche Klassenungleichgewichte und redundante Datenverarbeitung durch Objektcluster.

Ein zentraler Bestandteil von GeoGrapher ist ein bipartiter Graph, der die Beziehungen zwischen Vektor-Features und Rastern in Bezug auf Enthaltensein und Überschneidung erfasst. Dieser graphenbasierte Ansatz hilft, Clusterbildung zu vermeiden², redundante Downloads zu reduzieren, die Auswahl relevanter Raster zu optimieren und eine konsistente Zuordnung der Objekte über die verschiedenen Datensatz-Splits hinweg sicherzustellen.

GeoGrapher ist nutzerfreundlich konzipiert und bietet gleichzeitig die nötige Flexibilität für komplexere Workflows.

Key Features

GeoGrapher vereinfacht die Erstellung von Datensätzen und bietet Funktionalitäten für ein effizientes Management und Analyse von Datensätzen:

• Herunterladen von Fernerkundungsdaten: Unterstützt die meisten Fernerkundungsdatenquellen über eodag und vermeidet redundante Downloads durch Nachverfolgung der Objektabdeckung. Dank einer allgemeinen Downloader-Schnittstelle lässt sich GeoGrapher leicht um neue Datenquellen erweitern³.

• Erstellen von Labels aus Vektor-Features: Wandelt polygonale Vektor-Features in Segmentierungsmasken für Machine-Learning-Aufgaben um.

• Aktualisieren von Datensätzen ohne Redundanz: Prüft die bestehende Rasterabdeckung, um unnötige Downloads zu vermeiden und Updates effizient zu halten.

• Vermeidung von Datenlecks: Stellt sicher, dass beim Split in Trainings-, Validierungs- und Testsatz Vektor-Features und Raster sauber gruppiert werden und kein Datenlecks entsteht.

• Graphenbasierte Abfragen: Ermöglicht das Abrufen aller Raster, die ein bestimmtes Vektor-Feature enthalten oder mit ihm eine Überschneidungsbeziehung haben (z. B. ein Stadion), sowie aller Vektor-Features, die in einem Raster enthalten sind oder es überschneiden. Dies erleichtert die Inspektion, das Debugging und die Analyse von Datensätzen.

Ausgelegt für ML-Workflows in der Fernerkundung

GeoGrapher übernimmt die automatische Verwaltung komplexer räumlicher Beziehungen, sodass sich Fernerkundungsexperten und ML-Ingenieure auf die Modellentwicklung statt auf das mühsame Aufbereiten von Datensätzen konzentrieren können. Wir freuen uns, GeoGrapher mit der Community zu teilen, und hoffen, dass die Bibliothek sich als nützlich für Ihre Projekte erweist.

GeoGrapher im Einsatz

Möchten Sie GeoGrapher im EInsatz sehen? Werfen Sie einen Blick in unser Einführungs-Notebook, in dem wir zeigen, wie Sie GeoGrapher nutzen können, um:

• Sentinel-2-Satellitenbilder für Stadien herunterzuladen,

• automatisch Segmentierungsmasken zu erstellen und

• Rohbilder in einen ML-fähigen Datensatz zu überführen.

Hier geht es zum Notebook. →

Wir sind gespannt, wie Sie GeoGrapher in Ihren Projekten einsetzen. Lassen Sie uns gerne wissen, was Sie denken, und tragen Sie mit Feedback oder Beiträgen zur Weiterentwicklung bei!

¹ GeoGrapher unterstützt beliebige Vektor-Features in seinem bipartiten Graphen, jedoch ist die Label-Erstellung für Bounding Boxes zur Objekterkennung derzeit nicht implementiert. Das Problem bei der Objekterkennung ist, dass Bounding Boxes üblicherweise relativ zu einem festen Bildraster definiert sind, während Satellitenbilder durch die Position und den Blickwinkel des Sensors bei der Aufnahme ausgerichtet werden. Dadurch stimmen Rastergrenzen in der Regel nicht mit gezeichneten Bounding Boxes überein, was Objekterkennungs-Workflows komplizierter macht.

² Die Minimierung basiert auf einer einfachen Heuristik, die sich in der Praxis bewährt hat. Eine optimale Lösung würde eine Variante des NP-vollständigen geometrischen Set-Cover-Problems erfordern und ist daher nicht effizient lösbar. In zukünftigen Versionen könnte die Heuristik weiter verbessert werden.

³ Die Verarbeitung der Downloads erfordert zusätzliche Processor-Implementierungen, die auf die Datenquelle oder den Produkttyp zugeschnitten sind.