Kritische Tester für den neuen OSMI-Routing-View gesucht

TL;DR
Wir überarbeiten in der Geofabrik gerade Routing-Views des OSM Inspectors und suchen Leute, die sich dessen gemeldete Fehler ansehen.

Hallo,

in der Geofabrik sind wir gerade dabei, das Backend des Routing-Views neu zu schreiben, weil die PostGIS-basierende Lösung zur Ermittlung fehlender Verbindungen im Straßennetz zunehmend an Grenzen stößt. (Inseln, Quellen und Senken ermittelt OSRM für uns – sie sind ein Abfallprodukt des Updateprozesses eines unserer Routingserver.)

Im Rahmen dieser Tätigkeit habe ich auf GraphHopper-Basis einen Ersatz geschrieben, der all das auf einmal und zügig ausrechnen soll. Der Ersatz hat nicht das Ziel, exakt oder annähernd dieselben Ergebnisse wie die alten Programme zu erzeugen. Stattdessen habe ich nur mit der groben Vorgabe, fehlenden Verbindungen zu finden, angefangen.

Während Inseln, Quellen und Senken recht gut definiert sind und man sich nur darüber streiten oder wundern kann, wie man Durchfahrtsverbote auswertet, gibt es bei unverbundenen Straßen keine exakte Definition, welche Fehlermeldungen zutreffend sind. Ich habe daher einmal für die ganze Welt ausgerechnet, wo Verbindungen im Straßennetz fehlen könnten. Dazu habe ich für jeden Knoten im Routinggraphen, der nur eine Kante hat (also Sackgassen) ermittelt, welche andere Kanten die nächstgelegenen sind. Um die Anzahl der False Positives zu reduzieren, habe ich folgende Maßnahmen ergriffen:

  1. noexit=yes und entrance=* (außer entrance=no) werden nicht gemeldet
  2. Kanten, die Nachbarn der Sackgasse sind, zählen nicht als Treffer.
  3. Kanten, die Nachbarn von Nachbarn der Sackgasse sind, zählen auch nicht als Treffer.

Regel 2 und 3 sind erforderlich, weil sonst Sackgassen an Stellen mit dichtem Mapping, wo die Kanten oft kürzer als der Suchradius sind, auf sich selbst oder ihre Zugänge matchen. Das betrifft v.a. Parkplatzwege und Fußwege in Grünanlagen. Sie führen manchmal aber auch zu unsinnig erscheinenden Treffern, weil deutlich näher liegende Kanten nicht berücksichtig worden sind.

Der Suchradius beträgt 15 Meter.

Leider war es mit diesen Regeln nicht getan. In meinem Testgebiet waren unzählige False Positives dabei. Ich finde es nicht gut, wenn der OSM Inspector seine Benutzer dazu verleitet, in einer Gegend noexit=yes mit der Gießkanne zu verteilen, um Qualitätssicherungsdienste ruhigzustellen. Deshalb berechne ich für jeden Treffer noch ein paar numerische Maße. Wenn ihr auf die Punkte klickt, werden sie in der rechten Seitenleiste angezeigt.

  • distance: Entfernung in Metern
  • ratio: Quotient aus der Entfernung der zwei Punkte über den Graphen und der Luftlinie
  • angle1: Winkel zwischen dem letzten Segment der Sackgassen-Kante und dem Segment der Kante, die als Treffer gewählt wurde
  • angle2: meist wie angle1, außer der nächstgelegene Punkt ist ein Knoten im Graphen oder ein Stützpunkt einer Kante

Die fehlenden Verbindungen werden jeweils zweimal doppelt dargestellt:

  • Jeder gefundene Punkt wird farbig ausgegeben. Der nächstegelegene, nicht aus irgendwelchen Gründen verworfene, Punkt auf dem Graphen wird in schwarzer Farbe in Zoomstufe 18 gerendert.
  • Es gibt drei Layer, in denen die Punkte nach der Entfernung gerendert werden, sowie drei Layer, in denen sie nach dem Wert der Spalte ratio gerendert werden.

Ich habe in meinem Testgebiet (Straubenhardt) beobachtet, dass Treffer mit einer ratio kleiner als 11 in der Regel False Positives sind.

unverbunde Punkte klassifiziert nach Entfernung

unverbundene Punkte klassifiziert nach dem Quotienten aus der Entfernung über den Graphen und der Luftlinienentfernung

Leider ist mein Horizont beschränkt, sodass ich mich freuen würde, wenn ihr euch bekannte Gegenden, aber auch abgelegene Gegenden (z.B. HOT-Aktivitätsregionen, das TIGER-Land, das Canvec-Land, Städte mit separat gemappten Bürgersteigen usw.) anschauen würdet. Vielleicht liefert meine Software dort hilfreiche oder hinderliche Hinweise? Das Feedback von Mappern mit einem Fokus auf Qualitätssicherung liegt uns sehr am Herzen.

Noch ein paar Anmerkungen:

  • Den Quellcode findet ihr unter https://github.com/geofabrik/osmi_routing. Es wird ein Fork von GraphHopper als Git-Submodul verwendet, den ich auch für OpenRailRouting verwende. Die Ausgabe erfolgt im GeoJSON-Format. Der Betrieb mit mehr als einem Thread ist empfohlen. Der Speicherbedarf ist mit dem originalen GraphHopper ohne Contraction Hierarchies vergleichbar.
  • Unter https://kunden.geofabrik.de/ccfe3e46ecf224aad3fc9407fe9fffdd/ könnt ihr die gefundenen Fehler als Shapefiles (gesamter Planet) herunterladen.
  • Abbiegeverbote und Durchfahrtsverbote werden nicht berücksichtigt. Es kommt ein Allweg-Routingprofil zum Einsatz, das alle Straßen und Wege nutzt. Einbahnstraßen werden ebenfalls ignoriert.
  • Routinginseln werden eliminiert und ausgegeben. Es werden keine Quellen/Senken ausgegeben, weil das verwendete Routingprofil Einbahnstraßen ignoriert.
  • Nur für die Sackgassen-Nodes sind momentan OSM-Node-IDs enthalten. Wenn der nächstgelegene Punkt kein Node, sondern ein Way-Segment in OSM ist, könnte ich dazu eine Way-ID ermitteln.
  • Der Testdatensatz wird nicht aktualisiert und nur wenige Tage lang verfügbar sein, bis wir genügend Feedback erhalten haben. Später wird der View dann aber täglich im OSMI ausgerechnet und dort abrufbar sein.

Viele Grüße

Michael

Hi Michael,

die generierten Node-IDs passen zumindest bei mir in meinen Tests manchmal nicht:

Hier http://tools.geofabrik.de/osmi/?view=routing_beta&lon=9.69082&lat=52.39410&zoom=18&baselayer=GeofabrikStandard&opacity=0.66&overlays=unconnected_open_ends_gt10,unconnected_open_ends_gt5elt10,unconnected_open_ends_elt5,snap_points gibts einen blauen Punkt (am Eingang der Turnhalle, Hausnummer 11, Wendlandstraße, unter dem Platz da. Anklicken liefert node-id 4376992713 . Die ist aber https://www.openstreetmap.org/node/4376992713 in Tasmanien…
Korrekte node-id wäre https://www.openstreetmap.org/node/6025074608 .

Hier http://tools.geofabrik.de/osmi/?view=routing_beta&lon=9.68498&lat=52.39386&zoom=18&baselayer=GeofabrikStandard&opacity=0.66&overlays=unconnected_open_ends_gt10,unconnected_open_ends_gt5elt10,unconnected_open_ends_elt5,snap_points (Nordende des Parkplatzes, östlich vom “Forum Herrenhäuser Markt”) stimmt die node-id.

Beides übrigens echte Fehler in den Daten, die ich dann auch irgendwann behebe, wenn du die nicht mehr zum Testen brauchst. Danke!

zu false positives: die meißten false positives die ich sehe sind an Straßen, die access=private o.ä. haben. Hier z.B. http://tools.geofabrik.de/osmi/?view=routing_beta&lon=9.72473&lat=52.39001&zoom=18&baselayer=GeofabrikStandard&opacity=0.66&overlays=unconnected_open_ends_gt5elt10,unconnected_open_ends_elt5,snap_points am Feuerwehrparkplatz zwischen Weidendamm und Bahn.

Kannst Du auswerten, ob die Luftlinie zwischen Punkt und Snap Point eine barrier-Linie schneidet?

Hallo Michael,

ich habs probiert mit den ratio>10 Triggern und auf Anhieb etliche Fehler gesehen, aber in diesen kompakten Wohnsiedlungen trotzdem überwiegend false positive.

Ich finde Deine Analyse richtig, dass Nutzer no-exit Tags als false-positive Datenbank missbrauchen könnten, aber Deine Schlussfolgerung völlig falsch, deshalb die Kriterien zu verschärfen.

Denn die ganz offensichtlich Lösung ist ja, dem Tool eine false-positive Datenbank zu spendieren.

Ich hab einige Hauseingänge gemappt und die werden bei dir mit bunten Punkten bedacht, z. B:
http://tools.geofabrik.de/osmi/?view=routing_beta&lon=9.97919&lat=53.60333&zoom=18&baselayer=GeofabrikGerman&overlays=unconnected_open_ends_gt10,unconnected_open_ends_gt5elt10,unconnected_open_ends_elt5

Ich sehe nicht was an denen falsch ist. Achja, und wenn man drauf klickt landet man in Neuseeland.
Soll das heißen, dass keine geheime Verbindung zwischen den Hauseingängen in Hamburg und dem Lake Taupo existiert?

Hallo,

die Ursache für die falschen Node-IDs habe ich gefunden. Nach dem Entfernen der Routinginseln aus dem Graphen wird der Graph komprimiert, indem die Node-IDs der gelöschten Nodes wiederverwendet werden. Mein Mapping von Node-IDs auf OSM-IDs wird dabei natürlich nicht aktualisiert. Deshalb kommt man dann irgendwo anders raus.

Die Software prüft jetzt, ob die wahrscheinlichste Verbindung eine linienförmige Barriere (Zaun, Mauer, Stützmauer, Böschung) schneidet. Falls ja, wird an dem Node grundsätzlich keine fehlende Verbindung ausgegeben.

Der Datensatz wird gerade frisch aus dem Planetdump von gestern Abend ausgerechnet. Das dauert ca. 7 Stunden und das Update wird nicht automatisch hochgeladen.

Naja, in 15 Metern Umkreis ist eine andere Kante im Graphen, die nicht ein Nachbar der dort endenden Kante ist. Meine Software wertet entrance=* aus und zeigt diese nicht als Fehler an. An dem Objekt fehlt das Tag wohl. entrance=* halte ich für ein sinnvolles Tag, das nicht nur für einfach gestrickte Qualitätssicherungssoftware existiert.

Es wäre schön, wenn das der OSM Inspector hätte, aber dieser ist ursprünglich gar nicht als reines Qualitätssicherungswerkzeug gedacht, sonst hieße er bestimmt OSM Issue Finder. Es würde den Rahmen dieses Projekts, nämlich den Routing-View neu zu machen, sprengen.

Viele Grüße

Michael

Bei meiner Gegend enden die Fußwege an den Hauseingängen als false positives. Oder soll ich den (öffentlichen) Gehweg im Haus als
access=permissive
covered=yes
weiter taggen? :smiley:
Vielleicht kannst Du die Wege, die an building=* enden, aus Deiner Suche rausnehmen.

Hallo,

Kannst du mal bitte einen Permalink aus dem OSM Inspector hier veröffentlichen?

Wenn Wege an Hauseingängen enden, sollte der Weg mit der Hauswand verbunden sein und der letzte Node mit entrance=* getaggt sein. Dann wird er wie noexit=yes behandelt.

Nein, building=* werde ich im Routing-View sicherlich nicht auswerten. Er ist jetzt schon etwas zu langsam. Wenn ich building=* auswerte, muss ich einen Index aller Gebäude der Welt aufbauen, was performancemäßig ein Albtraum werden wird und die Performance-Optimierungen des OSM-Imports von GraphHopper zu Nichte macht, der darauf optimiert ist, nur Straßen zu importieren und nicht die restlichen ca. 70% der OSM-Daten.

Viele Grüße

Michael

Ich hatte oben schon nen Link gepostet.
Hier nochmal einer der markierten Nodes: https://www.openstreetmap.org/node/6019786355

Was kann ich am Tagging verbessern?

In Frankfurt hat so gut wie jede Haltestelle mehrere Fehler, meistens in Verbindung mit Plattformen - das dürften mehr als die Hälfte aller Fehler sein. Ein weiteres Viertel sind wie von den anderen berichtet kurze Stichwege / Zugangswege. Einen echten Fehler habe ich bis jetzt noch nicht gefunden zwischen all den falschen Meldungen.

Dieser Fehler ist auch der häufigste Fehler in Nürnberg. Dieses in meinen Augen eigenartige Mapping der Bushaltestellen stammt von “Weltstaat” (Firma Mentz) und ist im Grunde schon ein Fehler. Weder sind (bei uns) die meisten der Bushaltestellen eigenständige Flächen (sondern einfach Teil des Gehsteigs), noch zweigt auf dem Gehsteig ein eigener Weg zum Haltestellenschild ab :frowning:

@Nakaner
In HOT-Gebieten funktioniert die Fehlersuche damit gut.
Bei path/footway würde ich aber den Höchstabstand anders setzen (maximal 5 Meter), als bei highway. In gut gemappten Gebieten ist ein größerer Abstand häufig ein false positive. Und in Entwicklungsländern ist in Gegenden, wo ein größerer Abstand tatsächlich auch ein Fehler ist, so viel falsch, dass man da sowieso mit der Motorsäge die gröbsten Fehler ganz ohne Validator zurechtschnitzen muss/kann.

Falls noch nicht: Waterway sollte auch als Barriere gelten :wink:

Hörst Du inzwischen Lob lieber als früher? Falls ja: cooles Tool, danke!

Hier http://tools.geofabrik.de/osmi/?view=routing_beta&lon=9.80850&lat=52.40456&zoom=18&baselayer=GeofabrikStandard&opacity=0.66&overlays=unconnected_open_ends_gt10,unconnected_open_ends_gt5elt10,unconnected_open_ends_elt5,snap_points wird der Snap Point für mich komisch gesetzt (auf dem Weg der in die Sackgasse führt), oder die Daten sind da wirklich verquer. Ich habs mir nicht näher in den Daten angeguckt, sieht nur merkwürdig aus.

An Bahnsteigen sehe ich auch ne menge Fehlermarker (Beispiel 1, 2 (OMFG wer hat die Verkehrsinsel da so verhunzt? auf meine to do liste schreib)), aber da bin ich mir nicht sicher, was korrektes Tagging ist.

Der Blick auf die Innenstadt von Frankfurt/Main zeigt überwiegend Marker im Bereich ÖPNV, an unterirdischen Bahnstationen (vulgo: U-Bahn).

Sagst Du hier bescheid wenns nen neuen Datenstand gibt und wir wieder testen können?

Hallo,

für die unverbundenen Linien (nicht die Inseln) sind jetzt neue Daten online (OSM-Datenstand irgendwann am Samstag). Geändert ist:

  • Zäune, Mauern, Stützmauern, Böschungen und Leitplanken (jeweils als Ways gemappt) sind jetzt Barrieren. Wenn die sonst ausgegebene Verbindung eine solche Barriere kreuzen würde, wird sie gar nicht ausgegeben und die Sackgasse nicht als fehlerhaft betrachtet.
  • Ausgabe der Node-IDs korrigiert
  • highway/public_transport/railway=platform sind jetzt akzeptierte Tags für begehbare Kanten. Bei flächenförmigen Bahnsteigen dürfte es jetzt weniger Meldungen über unverbundene Punkte geben, bei linienförmigen kommen momentan noch welche dazu. Ich werde aber da noch Hand anlegen und einfach keine Fehler bei Bussteigen (bei Bahnsteigen vielleicht schon) ausgeben.

Bei Ways mit indoor=yes liebäugle ich damit, nur fehlende Verbindungen zu Objekten auf demselben Layer zu ermitteln, damit Passagenebenen in U-Bahnhöfen nicht mit der darüberliegenden Straße oder den darunterliegenden Bahnsteigen “verbunden” werden.

Viele Grüße

Michael

Naja, die Parkplatzzufahrt hat keinen gemeinsamen Node mit dem Radweg. Der Radweg ist deshalb keine Nachbarkante der Zufahrt. Wären die beiden verbunden, wären sie zueinander jeweils Nachbarn und würden als Treffer ausgeschlossen werden. Der Snap Point liegt nicht auf der Zufahrt, sondern ein klein wenig weiter nordwestlich, weil das der Lotfußpunkt des Sackgassen-Endpunkts auf den Radweg ist.

Danke! So hab ich jetzt tatsächlich Fehler an Bahnsteigen gefunden (die Treppe führte auf eine Baumreihe, und nicht auf den dahinterliegenden Bahnsteig…).

Für mich taugt das so schon gut was!

Bei den Parkplatzwegen mit service=parking_aisle bin ich mir unschlüssig. Einerseits seh ich da schon oft Fehlermarker dran, andererseits müsste man sich die Stellen tatsächlich OTG angucken, um zu entscheiden, ob man noexit=yes dranschreibt oder nicht (haben wir dazu Regeln?). Ich fahr die Stelle aber nächstens mal mit dem Rad ab und entscheide dann.

Mir ist allerdings ein “leeres” QA tool auch nicht wichtig. Wenn ich da permanent 10 Marker sehe, von denen ich aber weiß das ich sie ignorieren kann weils false positive ist, dann ignorier ich die. Ob das alle so machen, d.h. ob man das nötige Augenmaß bei Mappern vorraussetzen kann kann ich nicht beurteilen.

Hallo,

noexit=yes gehört IMHO nur dran, wenn man vor Ort war und weiß, dass dort nichts weiter geht. Eine Tür ins Gebäude hindert mich aber nicht daran, noexit=yes zu ergänzen, sofern nicht absehbar ist, dass man das eines Tages indoormappt, weil es öffentlich ist. Eine Garagenzufahrt bekäme also noexit=yes.

Ich fürchte, dass es selbst unter den Nutzern des OSM Inspectors, die i.d.R. keine unkundigen Anfänger sind, sicherlich zu viele sind, um den OSM Inspector mit False Positives zuzumüllen. Es dürfte genug Nutzer geben, die ein Bedürfnis haben, die Karte ihrer Gegend weiß zu bekommen.

Trotz Auswertung der linienförmigen Barrieren wird sich der Wald an False Positives nicht groß lichten. Ich habe gedacht, dass ich die Meldungen anhand ihrer Straßenklasse (highway=*), Öffentlichkeit (access=no/private vs. alles andere) und Distanz in fünf Klassen einteile, die als Layer im OSM Inspector auswählbar sind:


              |           Entfernung in Meter          
Straßenklasse | bis 3,75 | bis 7,5 | bis 11,25 | bis 15
--------------+----------+---------+-----------+--------
motorway      |        1 |       1 |         1 |      2
trunk         |        1 |       1 |         1 |      2
primary       |        1 |       1 |         1 |      2
secondary     |        1 |       1 |         1 |      2
--------------+----------+---------+-----------+--------
tertiary      |        2 |       2 |         3 |      3
unclassified  |        2 |       2 |         3 |      3
residential   |        2 |       2 |         3 |      3
living_street |        2 |       3 |         3 |      4
track         |        2 |       2 |         3 |      4
--------------+----------+---------+-----------+--------
pedestrian    |        3 |       4 |         4 |      5
footway       |        4 |       5 |         5 |      5
cycleway      |        4 |       5 |         5 |      5
path          |        4 |       5 |         5 |      5
steps         |        5 |       5 |         5 |      5
platform      |        4 |       5 |         5 |      6
--------------+----------+---------+-----------+--------
service       |        3 |       4 |         4 |      4
  driveway    |        4 |       4 |         5 |      5
  parking a.  |        4 |       4 |         5 |      5
  alley       |        3 |       4 |         4 |      5
--------------+----------+---------+-----------+--------
road          |        3 |       3 |         4 |      4
raceway       |        2 |       2 |         2 |      3
ferry         |        2 |       3 |         3 |      3

1 ist höchste Priorität, 5 niedrigste Priorität. _link-Klassen sind ihrer Hauptklasse gleichgestellt (also trunk = trunk_link). Straßen mit access=no/private komme in die nächstniedrigere Kategorie. Die Kategorie 6 enthält alle 5er-Fehler, die von Ways mit access=no/private stammen.

Bei meinen Testdaten aus Rheinland-Pfalz finden sich in Kategorie 1 ein oder zwei echte Fehler (unsere lieben Straßenbaustellenmapper :)), in Kategorie 2 haufenweise unverbundene Feldwege in der Eifel, ab Kategorie 3 sind dann mehr False Positive dabei und bei 4 beginnen sie zu dominieren. Noch habe ich keinen gefunden, aber ich warte noch darauf, bis jemand einen unverbundenen Feldweg präsentiert, der seit dem Lizenzwechsel nicht mehr verbunden ist.

Der neue Datensatz steht vsl. morgen zur Verfügung (mit OSM-Daten von gestern Abend).

amenity=parking_entrance ist jetzt mit noexit=yes gleichgestellt, weil das in Innenstädten einzelne False Positive erzeugt hat.

Viele Grüße

Michael

Mit den Bugfixes sehe ich hier einige true-positives. Ich wundere mich, dass keepright die nicht auch findet, z. B.: https://www.openstreetmap.org/way/167490789

Meine Hauseingänge werden nun größtenteils nicht mehr angemeckert. Außer ich hab den entrance=* vergessen :slight_smile:

Mit der neuen Version sehe ich Prio1-Fehler quasi nur an Brückenbaustellen, z.B. http://tools.geofabrik.de/osmi/?view=routing_beta&lon=9.78343&lat=50.98150&zoom=17&baselayer=GeofabrikStandard&opacity=0.66&overlays=unconnected_open_ends_1,snap_points .

Ist richtig gut geworden, auch die Einteilung.

Hallo,

gormo war ein paar Minuten schneller als ich. :slight_smile: Ich habe heute Vormittag die neuen Daten hochgeladen und vorher die Layerstruktur umgebaut.

Habt ihr Vorschläge zum Rendering oder den Mindestzoomlevel der einzelnen Layer?

Nicht nur dort, sondern an Straßenbaustellen, wenn es parallele Feld-/Radwege gibt, weil highway=construction nicht in den Graphen aufgenommen wird. Seht ihr das auch als False Positive oder findet ihr solche Meldungen eher sinnvoll?

Die Rohdaten, die hinter dem WMS-Dienst stehen, stehen unter https://kunden.geofabrik.de/ccfe3e46ecf224aad3fc9407fe9fffdd/ zum Download bereit, falls jemand damit herumexperimentieren möchte.

Viele Grüße

Michael

Uuii, sieht der Kaiserstuhl aus. Da wird es wohl Zeit, mal all die Böschungen zu mappen, damit die Fehler von meiner Software gleich aussortiert werden. Anderswo habe ich das Gefühl, dass ich damit genügend unsorgfältig gemappte Wald- und Feldwege finde. http://tools.geofabrik.de/osmi/?view=routing_beta&lon=7.70892&lat=48.09368&zoom=13&baselayer=GeofabrikStandard&opacity=0.66&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4