OK, das habe ich bisher nicht so gesehen.
Was macht denn SC, wenn die Bordsteine bereits als barrier=kerb erfassst sind? Fragt es dann trotzdem beim crossing Node nach kerb?
Hier haben wir so eine Diskrepanz: An den barrier=kerb Nodes ist kerb=flush getaggt, am dazugehörigen crossing-Node kerb=lowered.
@Jörg_Roßdeutscher @aighes @OSM_RogerWilco @chris66
@Metzor Vielen Dank für den Hinweis und den Verweis auf das englische Wiki!
Ihr habt recht, eine doppelte Erfassung von kerb=* am Crossing-Node und gleichzeitig als barrier=kerb-Node in unmittelbarer Nähe ist suboptimal und könnte zu Problemen beim Routing führen.
Unser Vorschlag ist daher:
- Prüfung im Radius von ca. 4 Metern um einen Crossing-Node
- Wenn dort bereits ein
barrier=kerb-Objekt mitkerb=*existiert oder wenn der Crossing-Node selbst schon einkerb=*hat → kein weiterer Eintrag von unserer Seite. - Nur wenn es weder ein Barrier-Node mit kerb in der Nähe noch ein
kerb=*direkt am Crossing gibt, würden wir denkerb=*-Tag ergänzen.
Damit sollten wir vermeiden, dass Bordsteine doppelt eingetragen werden und gleichzeitig Crossings ohne Informationen weiterhin sinnvoll ergänzt werden können.
Hallo @aighes
Ich würde hier gerne auf eine andere Antwort an Jörg_Roßdeutscher verweisen.
Diese Heuristiken sind zwar schonmal ein Ansatz um einiges zu finden, da würde ich mir aber auch noch viele false-positives erwarten, sowohl bei breiten Straßen oder asymetrisch gezeichneter Kreuzungsgeometrie (also größerer Abstand) als auch durch das falsche Zuordnen anderer kerb-Punkte an Straßenecken. Besser wäre es, wenn die Topologie mitberücksichtigt würde, also beim Kreuzungsnode geschaut wird, ob er an einen highway=footway mit footway=crossing-Weg angeschlossen ist, und dann jeweils dort nachsehen, ob es darauf “in der Nähe” (also z.B. bis zum nächsten Schnittpunkt mit einem anderen footway) einen barrier=node-Punkt gibt, oder ob dieser Querungsweg einen Schnittpunkt mit einem barrier=kerb-Way hat.
Ich habe meine Grafik von oben mal um zwei rote Kreise ergänzt. Das ist nicht maßstabsgerecht soll aber einfach mal die „4 Meter“ visualisieren:
Ich vermute mal, dass eure 4-Meter-Lösung hier fehlschlägt. Gleichzeitig könnt ihr aber auch nicht sagen 5 oder 8 oder 15 Meter, sonst ist schnell jede Kreuzung blacklisted. Gerade bei wichtigen Kreuzungen, mehrere Fahrspuren pro Richtung, sind 4m ja auch „nix“.
Ich würde mal vermuten, ihr kommt nicht um eine ziemlich komplexe Lösung herum, den Zustand der Kreuzung zu analysieren, und zwar an allen Verkehrswegen. Und dummerweise gibt es bei OSM keinen Verweis wie „Way 123 ist der Gehweg zu Way 456 (die Strasse)“.
Das ist einfach keine Implementation „from scratch“, wo ihr einer leeren Karte schonmal ganz viel richtiges hinzufügen könnt. Sondern ihr findet einbestehendes Konstrukt vor, dass bereits existiert, teilweise sehr komplex, teilweise sogar fehlerhaft. Gleichzeitg ist der Qualitätsanspruch bei OSM sehr hoch.
Gefühlt finde ich, ihr habt da in eurem Plan eine, mir fehlt grad ein besseres Wort, „merkwürdige“ Balance:
- Um die Kerbs zu finden, fahrt ihr die volle KI-Breitseite auf mit einer vermutlich leistungsstarken Erkennung
- …aber um herauszufinden, ob das Resultat überhaupt in die Karte darf, wollt ihr wichtige Wege-Typen ignorieren und den guten alten Radius verwenden.
Sprich: Erkennung in der echten Welt klug genug für Weltherschaft, aber Erkennung in den OSM Daten {durchstreich}doof wie Brot{end-of-durchstreich} 
extrem vereinfacht. Das ergibt m.E. keine gut funktionierende Architektur.
1 Like
Schaut doch mal in den quelloffenen Code von StreetComplete. Der identifiziert nämlich Stellen, an denen sich aller Wahrscheinlichkeit nach noch nicht gemappte abgesenkte Bordsteine befinden, speziell an crossings. Der Grundgedanke ist dann ja, dass bei den so identifizierten Stellen der User gefragt werden kann, wie hoch der Bordstein ist.
Ihr könntet einen ähnlichen Algorithmus nehmen, um Kandidaten für Stellen zu identifizieren, wo Bordsteinhöhen fehlen, anstatt euch komplett auf die Genauigkeit des GPS zu verlassen.
Im SC-Code wird müsste ja auch irgendwie sichergestellt werden, dass die Kerbs nicht doppelt gemappt werden (also dass sie nicht auf den crossing node gesetzt werden, wenn sie schon separat gemappt sind). Das könntet ihr euch also auch evtl. da abgucken.
1 Like
Ich möchte mich hier nicht zu weit aus dem Fenster lehnen, aber ich hatte hier und dort schon den Eindruck, dass SC(EE) das Problem ebenfalls nicht gelöst hat. Siehe mein Screenshot oben, wo das anscheinen auch doppelt drin ist.
Ich vermute, das ist passiert, weil ich den Bordstein straßenbegleitend erfasst hatte, später hat jemand die Straße in Straße+Geh/Radweg aufgesplittet, und ich wurde dann wohl erneut bei SCEE nach dem Bordstein gefragt.
@dieterdreist @Jörg_Roßdeutscher Vielen Dank für eure Rückmeldungen!
Zum einen habt ihr recht: ein fixer Radius von 4 Metern ist zu klein. Wir können den Wert selbstverständlich erhöhen und auch flexibel handhaben, um unterschiedliche Kreuzungssituationen besser abzudecken.
Zum anderen haben wir uns nach interner Diskussion entschieden, dass wir vorerst im Rahmen dieses Projektes alle Ergebnisse, vor dem Import, selbst manuell prüfen.
Dadurch haben wir die Möglichkeit, praktische Erfahrungen zu sammeln, wie sich Bordsteine sinnvoll in OSM abbilden lassen. Gleichzeitig minimieren wir das Risiko, dass fehlerhafte Heuristiken OSM-Objekte beeinflussen.
Wenn wir erste Erkenntnisse über die Genauigkeit unseres Vorgehens gesammelt haben, können wir dann in einer neuen Diskussion sinnvolle Prozesse für eine vollständige Automatisierung finden.
Im Folgeprojekt, mit mehr Daten und stabileren Workflows, wollen wir diese Schritte dann automatisieren und dadurch eine nachhaltige und skalierbare Lösung schaffen.
6 Likes
Ich denke auch, dass es zunächst einen Testlauf geben sollte, bei dem noch keine Daten in OSM geändert werden. Das Ergebnis davon sollte mit der OSM Community besprochen werden.
1 Like
@mobilab_furtwangen kennt ihr die Sandbox for editing - OpenStreetMap Wiki
1 Like
@OSM_RogerWilco @Jörg_Roßdeutscher @osmuser63783 @dieterdreist @aighes
Aktueller Stand der Klassifikation
Um einen Einblick in den aktuellen Stand unseres KI-Modells zu geben, möchten wir hier eine Confusion Matrix sowie einige Beispielbilder zeigen.
Was zeigt die Confusion Matrix?
Die Confusion Matrix ist ein Werkzeug, um die Qualität einer Klassifikation zu bewerten.
- Zeilen = tatsächliche Klasse (Ground Truth)
- Spalten = vorhergesagte Klasse durch das Modell
- Ein Wert von
1.0bedeutet: 100 % der Fälle wurden korrekt zugeordnet. - Werte außerhalb der Diagonalen zeigen Fehler (z. B. wenn ein „flat curb“ fälschlich als „low curb“ erkannt wird).
In unserem Fall sehen wir:
- high curb und no curb werden sehr zuverlässig erkannt.
- flat curb und low curb werden teilweise miteinander verwechselt.
Das ist auch nachvollziehbar, da die Unterscheidung in der Praxis schwierig ist, sowohl für Menschen als auch für ein Modell.
Die Verwechslungen treten vor allem bei low curbs auf, die etwa 1 cm hoch sind und somit sehr nahe an den flat curbs liegen.
Diese Fehler sind aus unserer Sicht nicht gravierend, da sie nur an der Grenze zwischen zwei sehr ähnlichen Klassen entstehen und für die spätere Nutzung kaum praktische Nachteile haben.
Beispielbilder
Nächste Schritte
Als nächstes wollen wir erste Daten in die Testumgebung laden, um den gesamten Import-Workflow auszuprobieren.
Wie bewertet ihr diese Ergebnisse?
Seht ihr die Verwechslungen zwischen „flat“ und „low curb“ als akzeptabel an?
Sehr interessant! Woher nehmt ihr die Werte für die tatsächliche Höhe, also die “ground truth” / das “true label”? Habt ihr da mit dem Zollstock nachgemessen? Oder geht ihr für diesen Zweck davon aus, dass die bereits in OSM (z.B. mit StreetComplete) erfassten Daten korrekt sind? Die sind nämlich in der Regel auch nur nach Augenmaß erfasst, in dem Fall könnte also auch manchmal euer Modell richtig liegen und OSM falsch, oder der “richtige” Wert ist einfach nicht klar definiert. (Als Mapper denkt man auch nicht unbedingt darüber nach, wo jetzt genau die Grenze zwischen flush und lowered ist, bei 1cm oder 0,1 oder 0,01..)
1 Like
Für Blinde ist es schon relevant, ob eine Bordsteinkante ertastbar ist oder nicht.
1 Like
Deine Matrix sagt aber lediglich aus, wie sicher sich die KI selber ist, nicht wie sicher sie in der Realität ist.
2 Likes
32 posts were split to a new topic: Messstrecken von Bordsteinlängen usw. (ausgelagert aus Thread zu BaAn-frei)
Die Diskussion über die Messstreckenlänge und Wahl von Einheiten ist hier im Thread off-topic. Ferner ist es unkonstruktiv, auf die Beiträge anderer Nutzer mit kurzen W-Fragen oder „Beleg“ zu antworten. Im Übrigen gilt das On-Topic-Gebot. Daher wurden zahlreiche Beiträge von Tobias_Conradi und dazu gehörende Antworte in einen separaten Thread ausgelagert.
Ich rate allen Beteiligten davon ab, Off-Topic-Diskussionen in diesem Thread fortzuführen. Die Diskussion über Moderator-Entscheidung wäre in diesem Thread auch eine Off-Topic-Diskussion.
Konstruktive, sachliche Einwände gegen Moderator-Entscheidungen können per Direktnachricht an die Moderatoren vorgebracht werden. Die Nachricht ist über die Nachrichtenfunktion des Forums an @mods_germany zu addressieren. Alternativ steht der Beschwerdeweg über den OSMF-Vorstand offen (board@osmfoundation.org). Die Beschwerde ist zu begründen.
Was meinst du damit?
So eine Konfusionsmatrix stellt die vom KI-Modell “vorhergesagte” (d.h. geschätzte) und die tatsächliche Bordsteinhöhe gegenüber. Sie gibt also schon an, wie häufig die KI in der Realität richtig liegt.
Wie aussagekräftig die Matrix ist, steht und fällt natürlich damit, wie zuverlässig die Daten über die tatsächliche Bordsteinhöhe sind. Daher meine Frage, woher diese Daten kommen. Am besten wäre es, wenn das Projektteam hier selbst nachgemessen hat (bei einer Stichprobe von Bordsteinen). Evtl. haben sie es auch anhand der Fotos abgeschätzt (also selber, ohne KI). Oder sich auf die bereits in OSM vorliegenden Daten verlassen. Das wären dann etwas weniger zuverlässige Quellen (trotzdem ein interessanter Vergleich).
In dem Zusammenhang auch relevant: die Grenze zwischen flush und lowered wird gerade hier diskutiert.
Ja, sowas meinte ich. Eine Gegenüberstellung: Bordstein n: Gemessen 5cm, KI hat 4cm geschätzt, beide (Mensch+KI) kamen zum Ergebnis kerb=raised
Die Matrix und die Bilder sind arg verwirrend, zumindest für mich. In beiden wird eine Wahrscheinlichkeit angegeben, die scheinbar nix miteinander zutun haben. In den Beispielbildern sind Wahrscheinlichkeiten genannt, wo schon weiter oben gesagt wurde, eine KI sollte zu 99,n% sicher sein, die genannten Wahrscheinlichkeiten sind aber weit drunter…
und wenn die KI bei diesem Bild nur zu 72% sicher ist, dass es kerb=raised ist, bin ich mir nicht sicher, was das ganze soll.
@osmuser63783
Die „Wahrheit“ unserer Daten basiert auf manuell gelabelten Datensätzen, nicht auf OSM-Daten.
Diese Daten wurden von uns selbst gesammelt, in einzelne Bilder unterteilt und anschließend per Augenmaß manuell klassifiziert.
Für die Höheneinteilung haben wir uns an den Definitionen der OSM-Kerb-Tags orientiert.
Vielen Dank außerdem für den Hinweis zur aktuellen Diskussion zur Unterscheidung zwischen flush und lowered.
@OSM_RogerWilco
Natürlich wäre eine vollständig fehlerfreie Erkennung ideal.
Allerdings ist die Unterscheidung, ob ein Bordstein z. B. 0,0 cm oder 0,2 cm hoch ist, in der Praxis extrem schwierig.
Wir gehen davon aus, dass selbst bei manuell gelabelten Daten immer eine kleine Fehlerquote bestehen bleibt.
Die etwas höhere Verwechslungsrate zwischen flat curb und low curb halten wir deshalb für praktisch unvermeidbar.
@aighes
Die Auswertung basiert auf einem Datensatz, bei dem wir die richtigen Ergebnisse manuell bestimmt haben.
Die gleichen Bilder wurden (natürlich ohne das richtige Ergebnis) von der KI ausgewertet.
Die Bilder mit Masken (z. B. das Beispiel mit der hellblau markierten Fläche „high_curb 0.72“) zeigen die Segmentierungsergebnisse der KI.
Das bedeutet: Die KI schätzt, dass der markierte Bereich ein high curb ist und ist sich dabei zu 72 % sicher.
Dieses Ergebnis wird anschließend mit den manuell gelabelten Referenzdaten verglichen, um die Gesamtgenauigkeit zu berechnen.
Die Confusion Matrix zeigt schließlich, wie oft die KI die richtige Kategorie getroffen hat und in welchen Fällen sie falsch lag.
Vorhersagen mit sehr geringer Sicherheit (unter 30 % Confidence) werden dabei übersprungen und nicht weiter ausgewertet.
Ultralytics – Instance Segmentation
GeeksforGeeks – Confusion Matrix
Anbei ein paar Referenzlinks, welche das Segmentierungsverfahren und die Confusion Matrix etwas detaillierter besprechen.
@Tobias_Conradi
Eine Schätzung der exakten Bordsteinhöhe in Millimetern halten wir sowohl für KI-Modelle als auch für menschliche Einschätzungen für nicht realistisch.
Die Fehlerquote wäre bei dieser Genauigkeit vermutlich so hoch, dass die Werte kaum sinnvoll nutzbar wären.
Zudem variiert die Bordsteinhöhe selbst an einer einzelnen Stelle häufig leicht, sodass selbst auf einem einzigen Bild mehrere unterschiedliche Werte entstehen würden.
Ausblick und Abschluss der aktuellen Projektphase
Das aktuelle Projekt BaAn-frei neigt sich dem Ende zu, wird aber im geplanten Folgeprojekt wieder aufgegriffen und weiterentwickelt.
Im nächsten Schritt wollen wir das Thema hier zunächst abschließen, bevor es in die nächste Phase übergeht.
Dazu haben wir mehrere Kreuzungen in Freiburg ausgewählt, deren Bordsteine wir mithilfe unserer KI analysieren und anschließend manuell überprüfen werden.
Nur wenn die Ergebnisse der KI eindeutig korrekt sind und an den entsprechenden Crossing-Nodes keine bestehenden barrier=kerb-Einträge vorhanden sind, ergänzen wir dort die passenden kerb=*-Tags.
Damit wollen wir den gesamten Prozess im kleineren Rahmen testen und gleichzeitig eine gute Grundlage für das kommende Folgeprojekt schaffen.
Zum Schluss möchten wir uns herzlich für das viele konstruktive Feedback und die offene Diskussion hier im Forum bedanken.
Die Anmerkungen haben uns sehr geholfen.
Sobald das Projekt im Folgeprojekt fortgesetzt wird und wir neue Ergebnisse haben, melden wir uns wieder, um den aktuellen Stand vorzustellen.
2 Likes