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

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

http://brouter.de/osmoscope/#map=17/9.78397/50.98126&l=http://brouter.de/osmoscope/active_deferred.json

:slight_smile:

Hallo,

die vielen Fehlermeldungen an (U-)Bahnhöfe kommen daher, dass die Bahnsteige oft als Multipolygone gemappt sind und GraphHopper sie gar nicht auswertet.

Viele Grüße

Michael