Mit Computer Vision umgesetzte Kartenfunktionen in OpenStreetMap

 (blog.mozilla.ai)
3 Punkte von GN⁺ 2025-03-24 | 2 Kommentare | Auf WhatsApp teilen
  • Mozilla.ai hat den OpenStreetMap AI Helper Blueprint veröffentlicht, der OpenStreetMap-Daten mit Satellitenbildern verknüpft, Kartenobjekte findet, sie von Menschen prüfen lässt und anschließend wieder beiträgt
  • Der Ansatz trennt statt LLM/VLM YOLOv11-Objekterkennung und SAM2-Segmentierung: Ersteres identifiziert Positionen, Letzteres erzeugt Polygonkonturen
  • Das Beispiel zur Kartierung von Swimmingpools zeigt einen Workflow, bei dem Trainingsdaten mit dem Tag leisure=swimming_pool und Mapbox-Kacheln erstellt und die Ergebnisse auf den Hugging Face Hub hochgeladen werden
  • Bei der Inferenz werden Kacheln rund um einen interessierenden Punkt zusammengeführt und mit bestehenden OpenStreetMap-Objekten verglichen, um Duplikatkandidaten auszuschließen; nur neue Kandidaten werden von Menschen geprüft
  • Vollständig manuelle Arbeit schafft etwa 2–3 Pools pro Minute, während dieser Blueprint selbst mit nicht optimierter UX 10–15 schafft und damit rund 5-mal schneller ist

Warum OpenStreetMap-Daten für AI-Mapping genutzt werden

  • Mozilla.ai hat den OpenStreetMap AI Helper Blueprint veröffentlicht, weil das Unternehmen davon ausgeht, dass AI in offenen Kollaborations-Communitys repetitive und langsame Arbeiten reduzieren kann
  • Ziel ist nicht, dass AI Kartografen ersetzt, sondern die Zeit für das Finden von Objekten und das Zeichnen von Polygonen zu verkürzen, während die menschliche Prüfung als letzter Schritt erhalten bleibt
    • Die zentrale Aufgabe, die weiterhin Menschen übernehmen müssen, ist zu prüfen, ob die erzeugten Kartendaten tatsächlich korrekt sind
  • OpenStreetMap ist eine offen editierbare Karte, deren Daten zu Straßen, Wanderwegen, Cafés, Bahnhöfen und Ähnlichem von einer Mapper-Community erstellt und gepflegt werden
  • OpenStreetMap ist eine der vollständigsten offenen Kartendatenbanken und kann in Kombination mit anderen Quellen wie Satellitenbildern als Trainingsdaten für AI-Modelle genutzt werden

Entscheidung für leichte Computer-Vision-Modelle statt LLMs

  • Viele Map Features in OpenStreetMap werden als polygonförmige Flächen dargestellt
  • Das Finden und manuelle Zeichnen von Polygonen ist zeitaufwendig, aber mit ausreichend Daten lassen sich Computer-Vision-Modelle für diese Aufgabe trainieren
  • Der Blueprint nutzt moderne Nicht-LLM-Modelle in zwei getrennten Schritten
    • Objekterkennung: YOLOv11 von Ultralytics findet die Position relevanter Kartenfunktionen in einem Bild
    • Segmentierung: SAM2 von Meta verfeinert die exakte Form des erkannten Objekts als Kontur
  • YOLOv11 und SAM2 sind leichtgewichtig, schnell und gut für lokale Ausführung geeignet
    • Die kombinierten Gewichte der beiden Modelle liegen bei unter 250 MB
    • Das als Vergleich genannte SmolVLM ist 4,5 GB groß

Der dreistufige Ablauf des Blueprints

  • Schritt 1: Einen Datensatz für Objekterkennung aus OpenStreetMap erstellen

    • OpenStreetMap-Daten werden geladen, mit Satellitenbildern kombiniert und in ein fürs Training geeignetes Format umgewandelt
    • Ein direkt ausführbares Create Dataset Colab wird bereitgestellt
    • Für die Erfassung von OpenStreetMap-Daten werden zwei APIs genutzt
      • Nominatim API: ermöglicht Nutzern, ein Interessengebiet flexibel auszuwählen
      • Overpass API: lädt Polygone herunter, die innerhalb des ausgewählten Gebiets einem bestimmten Tag entsprechen
    • Im Pool-Beispiel werden Galicia fürs Training und Viana do Castelo für die Validierung verwendet
    • Der Ziel-Tag ist leisure=swimming_pool; Objekte, die zusätzlich mit location=indoor versehen sind, werden ausgeschlossen
    • Nach dem Herunterladen der Polygone wird ein zoom level gewählt und es werden die Kacheln identifiziert, die auf dieser Zoomstufe Polygone enthalten
    • Über die Static Tiles API von Mapbox werden Kacheln heruntergeladen
    • Polygone in Breiten- und Längengradkoordinaten werden in Bounding Boxes mit Pixelkoordinaten relativ zur jeweiligen Kachel umgewandelt und im Ultralytics-YOLO-Format gespeichert
    • Der fertige Datensatz wird auf den Hugging Face Hub hochgeladen; der Beispieldatensatz ist mozilla-ai/osm-swimming-pools

  • Schritt 2: Das Objekterkennungsmodell finetunen

  • Schritt 3: Zu OpenStreetMap beitragen

    • Mit dem finetunten Objekterkennungsmodell wird Inferenz über mehrere Kacheln ausgeführt
    • Ein direkt ausführbares Run Inference Colab wird bereitgestellt
    • Der Beispiel-Pool-Detektor kann in der HuggingFace Demo ausprobiert werden
    • Der Inferenzprozess erfordert einige menschliche Interaktionen
      • Zunächst wird auf der Karte ein interessierender Punkt ausgewählt
      • Um den ausgewählten Punkt herum wird anhand des Arguments margin eine Bounding Box berechnet
      • Bestehende interessierende Objekte werden aus OpenStreetMap heruntergeladen
      • Alle Kacheln werden von Mapbox heruntergeladen, zusammengeführt und zu einem gestapelten Bild gemacht
      • Das gestapelte Bild wird wieder in überlappende Kacheln aufgeteilt
    • Auf jeder Kachel läuft das YOLOv11-Objekterkennungsmodell
    • Wird ein interessierendes Objekt wie ein Pool erkannt, wird die Bounding Box an SAM2 übergeben, um eine Segmentierungsmaske zu erhalten
    • Die vorhergesagten Polygone werden mit bestehenden, aus OpenStreetMap heruntergeladenen Polygonen verglichen, um doppelte Uploads zu vermeiden
    • Als neue Objekte identifizierte Kandidaten werden einzeln angezeigt und vom Nutzer manuell geprüft und gefiltert
    • Objekte, die der Nutzer behalten möchte, werden als ein changeset zu OpenStreetMap hochgeladen

Performance und praktische Implikationen

  • Der OpenStreetMap AI Helper Blueprint zeigt, dass AI menschliche Beiträge zu Karten verstärken und gleichzeitig menschliche Prüfung in den Mittelpunkt stellen kann
  • In einem vollständig manuellen Prozess lassen sich pro Minute 2–3 Pools kartieren
  • Mit dem Blueprint lassen sich selbst bei nicht optimierter UX im selben Zeitraum 10–15 Pools kartieren, also etwa 5-mal so viele
  • Mit hochwertigen OpenStreetMap-Daten lassen sich Modelle wie YOLOv11 trainieren, um Objekterkennung durchzuführen
  • Nicht jedes Problem erfordert ein LLM; für die Erkennung von Kartenfunktionen und die Erzeugung von Polygonen kann eine leichtgewichtige Computer-Vision-Kombination die direktere Wahl sein
  • Wer Modelle für andere Kartenfunktionen trainieren oder zum Repository beitragen möchte, kann den OpenStreetMap AI Helper Blueprint verwenden
  • Weitere veröffentlichte Blueprints sind im Blueprints Hub zu finden

Verwandte Beiträge

2 Kommentare

 
depth221 2025-03-24

Soweit ich gesehen habe, wird „Map Feature“ üblicherweise mit (Karten-)Objekt übersetzt.
 
GN⁺ 2025-03-24
Hacker-News-Kommentare

  • Aus Sicht der OpenStreetMap Foundation sollten von KI erkannte Objekte nicht direkt in die Datenbank aufgenommen werden.
    Algorithmen haben ein Problem mit False Positives, und wie im vorletzten Screenshot gibt es das Problem, dass gerade, rechteckige Objekte in verwackelter Form kartiert werden.
    Als Hilfswerkzeug zum Finden fehlender Objekte ist das wertvoll, aber um zu prüfen, ob ein erkanntes Objekt korrekt eingezeichnet wurde, ist weiterhin menschliches Eingreifen nötig.
    Siehe: https://wiki.openstreetmap.org/wiki/Import/Guidelines und https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...

    • In der Demo-App und den bereitgestellten Codebeispielen gibt es einen Schritt, der verlangt, dass erkannte Objekte von Menschen geprüft werden.
      Ohne Änderung des Quellcodes kann nichts automatisch hochgeladen werden, und in der Dokumentation, dem verlinkten Beitrag und den Codebeispielen wurde menschliche Prüfung immer wieder betont.
      Es wurden nie automatisch Objekte hochgeladen; schon vor dem Training der ersten Version wurden Hunderte von Pool-Beispielen manuell bearbeitet und gelabelt.
      Wenn es Ideen gibt, wie sich der Ablauf verbessern lässt, um automatische Objekt-Uploads zu verhindern, würde ich sie gern hören und umsetzen.
      Manche werden wohl sagen, man solle das Tool gar nicht veröffentlichen, aber ich denke, es gibt einen besseren Weg, KI anzunehmen und zugleich offen darüber zu diskutieren.
    • Die verwackelten Polygone im Screenshot sehen so aus, weil es als Maske gezeichnete Anzeige-Polygone sind, die über das Bild gelegt werden sollten; die tatsächlich hochgeladenen Polygone haben dieses Verwackeln nicht.
      Es kommt tatsächlich vor, dass Vorhersage-Polygone verwackelt sind, daher wird empfohlen, solche Ergebnisse zu verwerfen.
      Trotzdem wurde diese Demo nicht veröffentlicht, bevor die erste Modellversion eine Mindestqualität erreicht hatte.
      Im Code steckt außerdem Logik zur Formvereinfachung, damit Vorhersage-Polygone nicht zu viele Nodes bekommen.
    • Es wäre gut, bei aus Machine Learning abgeleiteten Objekten Tags hinzuzufügen.
      Solche Tools werden wahrscheinlich bereits halbautomatisch genutzt, und das könnte helfen, eine Verunreinigung der gesamten Datenbank zu reduzieren.

  • Pool-Erkennung ist gut, und Solar-Erkennung steht ebenfalls auf der Liste der Dinge, die ich ausprobieren möchte.
    Ein großer Teil der Gegenreaktionen hier scheint von der Annahme auszugehen, dass OSM allein durch manuelles Mapping wachsen kann.
    Aber aus meiner Perspektive nach 60.000 Changesets in zehn Jahren lässt sich Mapping im globalen Maßstab nicht allein durch freiwillige Begeisterung so „lösen“, dass Kartendaten überwältigend nützlich werden.
    Wir brauchen ein skalierbares Framework für Datenimport und Pflege: etwa Möglichkeiten, Qualität, Herkunft und den Ort für Bugreports zu Datenquellen als Anmerkungen zu hinterlegen, sowie Leitlinien für Datennutzer.
    Wenn man zum Beispiel „Unternehmen des Typs X, die innerhalb des letzten Jahres von Menschen kartiert wurden“ abfragen möchte, geht das mit check date bis zu einem gewissen Grad.
    Aber es ist schwer zu wissen, wie genau dieses Attribut ist oder ob der prüfende Mapper nur einen Aspekt wie Name oder Standort betrachtet hat.
    Es könnte besser sein, die Öffnungszeiten-Daten von alltheplaces monatlich automatisch zu importieren und zu pflegen.
    Aus Sicht von Datennutzern wäre es womöglich besser, wenn sie nur bestimmte vertrauenswürdige Quellen herausfiltern könnten oder Daten mit bekannten Einschränkungen wie „per KI abgeleiteter Point of Interest“ nutzen könnten, auch wenn ein Polygon nicht perfekt ist.

  • Wenn man automatisches Mapping selbst erlebt hat, wird man extrem vorsichtig.
    Ich bin mit dem Motorrad durch Südamerika gefahren; in OSM gab es besonders in Brasilien viele Bearbeitungen, die automatisch wirkten, und manche Regionen waren kaum benutzbar.
    Das galt nicht nur für Landstraßen, sondern auch für ziemlich große Städte.

    • Remote-Mapping vom Schreibtisch aus kann immer schlechte Karten erzeugen.
      Auf Reisen nutze ich normalerweise mapwithme und versuche, Fotonotizen zu hinterlassen, die Probleme erklären.
      Ich fotografiere eher Zäune und Spielplätze, andere Leute machen Landschaftsfotos.
      Es kann automatisches Mapping sein, aber auch mein eigenes Remote-Mapping ist vor Ort geprüft manchmal ziemlich chaotisch.
    • Mich würde interessieren, welche Region in Brasilien das war.

  • Ich habe vor ein paar Jahren in diesem Bereich gearbeitet; es gibt enorm viele bestehende Modelle, Datensätze und Tools.
    https://github.com/satellite-image-deep-learning

    • Eine hervorragende Sammlung von Materialien.
      Ich habe mit QGIS herumgespielt, mich bei mehreren öffentlichen und privaten Satellitenbild-APIs angemeldet, Daten geholt und experimentiert.
      Bei der EU-Weltraumagentur gibt es viele gute Datenquellen mit vollständig öffentlichem Zugriff, sogar ohne Nutzerkonto.
      Ich freue mich darauf, mit dieser neuen Tool-Sammlung speziell für Machine Learning zu arbeiten.

  • Google wird das wohl nicht erlauben, aber Mapbox scheint es für nichtkommerzielle Zwecke oder für OSM-Nutzung zu erlauben.
    Allerdings nur, wenn Satellitendaten verwendet werden, nicht die Vektordaten von Mapbox.
    In den Nutzungsbedingungen steht zwar, dass Kunden keine Inhalte, Daten oder Informationen aus den Service-Angeboten nachverfolgen, ableiten oder extrahieren dürfen; es gibt aber eine Ausnahme, nach der man Mapbox Maps, die ausschließlich aus Satellitenbildern bestehen, mit Studio oder Drittanbieter-Software nachzeichnen darf, um daraus abgeleitete Vektordatensätze zu erstellen. Der Zweck muss dabei nichtkommerziell oder OpenStreetMap sein.
    Mapbox ist da also ziemlich entgegenkommend.

  • Ich habe vor ein paar Monaten an etwas Ähnlichem gearbeitet.
    Zwar für Geodaten in kleinerem Maßstab, aber: https://github.com/uav4geo/GeoDeep

    • Tolle Arbeit; ich würde gern über Ideen für eine Zusammenarbeit sprechen.

  • Man sollte nicht kartieren, was auf Satellitenbildern zu sehen ist, sondern das, wofür es Tatsachen vor Ort gibt.
    Was eine KI halluziniert hat, sollte auf keinen Fall beigetragen werden.

    • In OSM sind die Kriterien fürs Nachzeichnen selbst oft Satellitenbilder.
      Die Qualität dieses Nachzeichnens schwankt mitunter stark, und ich musste schon mehrfach seltsam verschobene Küstenlinien korrigieren, bei denen Straßen über dem Meer lagen.
      Wenn dieses Tool einigermaßen konsistent ist, könnte es besser sein als der durchschnittliche OSM-Beitragende.
      Allerdings wäre es gut, mit Segmentierungen von Häusern, Straßen und Gewässern zu beginnen, sie mit den aktuellen Daten zu vergleichen, Abweichungen zu finden und diese als Korrekturziele hervorzuheben.

  • Könnte Mozilla sich nicht darauf konzentrieren, einen guten Browser zu bauen?

  • Ich würde gern mehr Details dazu sehen, wie SAM/2 feinabgestimmt wurde, um Swimmingpools oder Solaranlagen zu erkennen.
    Beides wäre sehr nützlich, wenn es für Projekte zur Resilienz von Gemeinden kartiert wäre, aber SAM2-Feintuning war schwer nachzuvollziehen.
    Solaranlagen mit einem Yolov8-Modell zu finden und zu segmentieren funktioniert ziemlich gut, aber die Ränder sind so unsauber, dass die Bereinigung enorm viel Arbeit macht.
    Ich habe Ergebnisse eines trainierten SAM2 gesehen, und die sahen deutlich besser aus.
    Wegen Genauigkeitsproblemen würde ich das nicht in OSM eintragen, aber anderswo ist es durchaus brauchbar.

    • In diesem Projekt gibt es kein SAM2-Feintuning.
      Die Segmentierungsdaten von OSM sind qualitativ nicht gut genug, um ein Segmentierungsmodell sauber zu trainieren.
      Hier wird ein YOLO-Modell für Bounding-Box-Vorhersagen verwendet.
      Die Bounding Boxes von OSM reichen für diesen Zweck aus, und jede Bounding Box wird als Prompt an SAM2 übergeben, damit es das Innere segmentiert.
      Wir haben auch versucht, den Mittelpunkt der Box als Prompt an SAM zu übergeben, aber die Ergebnisse waren schlechter.

  • Wir haben unter Berücksichtigung verschiedener Rückmeldungen ein neues Release veröffentlicht und den gesamten Code zum direkten Hochladen nach OSM durch Export im OsmChange-Format ersetzt.
    Hoffentlich ist das ein Schritt in die richtige Richtung; die Diskussion werden wir im dafür vorgesehenen Thread im OSM-Forum fortsetzen.