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

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

Hier habe ich zwei false positive: http://brouter.de/osmoscope/#map=17/11.06142/49.44404&l=http://brouter.de/osmoscope/active_deferred.json
Eine Ursache dafür kann ich mir derzeit nicht herleiten. Möglicherweise liegt es an der Straßenklasse “service” - obwohl mit access=yes für alle Verkehrsarten freigegeben?

Zur Situation:
Die Kohlenhofstraße ist hier seit längerem bis auf wenige Ausnahmen gesperrt ( https://www.openstreetmap.org/way/43111670 ) und es gibt eine “Umgehungsstraße” im besseren Baustellenausbaustandard (aber sogar mit Straßenbeleuchtung), die korrekt angebunden ist.

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=49.44394%2C11.05975%3B49.44439%2C11.06354
routet richtig.

@pyram Das hat aber nichts mit dem OSM Inspector zu tun? Du kommentierst doch Meldungen von Arndts Qualitätssicherungsdienst?

Uups. Entschuldigung. Dabei nutze und kenne ich den eigentlich gar nicht. Da habe ich nicht aufgepasst und den Link von #21 genutzt :-/

Hallo,

der OSMI zeigt jetzt auch Routinginseln für Radfahrer und Pkws an. http://tools.geofabrik.de/osmi/?view=routing_beta&lon=13.40148&lat=52.51709&zoom=15&baselayer=GeofabrikStandard&overlays=islands,islands_car,islands_bicycle,islands_all

Bei Fahrrädern und Pkw werden Access-Beschränkungen ausgewertet. Beim Layer für alle Fahrzeuge passiert das nicht, dort werden nur gänzlich unverbundene Straßen ausgegeben. Daher erlauben der Fahrrad- und Pkw-Layer einen Blick in die Access-Logik von GraphHopper.

Ein großer Teil der Fahrrad-Inseln in Städten kommt daher, dass GraphHopper highway/public_transport=platform nicht akzeptiert. Dazu gibt es (unabhängig von meinen Aktivitäten) ein Pull-Request, das solche als Schiebestrecken einstufen möchte.

Viele Grüße

Michael

Hi Nakaner,

unter dem OSMI steht “Data from 2019-05-06 22:58 (UTC)”. Das stimmt nicht, oder?

Die Anzeige der Inseln find ich auch gut, allerdings machen die Bahnhaltestellen doch viel false positives. Kannst Du die ausschließen oder den Patch in deine Graphhopper-Instanz reinpatchen? Oder sollen wir einfach abwarten bis GH upstream den pull request approved (Denglisch level 11 :wink: )?

Viele Grüße,
gormo

Hallo,

Ganz genau sagen, wann der aktuelle Datenstand ist, kann ich nicht, weil das Planetfile, aus dem ich das erzeugt habe (Job gestern gegen 18:30 MESZ gestartet), jeden Tag aktualisiert wird. Ein geschätztes Datum habe ich jetzt eingetragen.

Ich würde gerne abwarten, bis die Änderungen upstream akzeptiert sind. Danach muss ich dann den aktuellen GraphHopper wieder mit meinem Fork zusammenführen (der ist kein 3-Zeilen-Patch mehr).

Ich möchte bei den Routingprofilen, so weit es geht, beim Original bleiben.

Viele Grüße

Michael

Hi,

ich hab noch einen false positive: Bergstraße matcht mit Tunnel untendrunter: http://tools.geofabrik.de/osmi/?view=routing_beta&lon=11.44495&lat=46.92147&zoom=18&baselayer=GeofabrikStandard&opacity=0.71&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5,unconnected_open_ends_6 .

…und bei Brücken auch: http://tools.geofabrik.de/osmi/?view=routing_beta&lon=11.40365&lat=47.20456&zoom=18&baselayer=GeofabrikStandard&opacity=0.71&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5,unconnected_open_ends_6

Viele Grüße,
gormo

Nicht nur “ihrer Gegend”: https://forum.openstreetmap.org/viewtopic.php?id=66258 . Deine Befürchtung bestätigt sich…

Das Tool ist nützlich. Ich habe damit mir damit Kiel angesehen und einige Fehler sowie diverse kleine Unstimmigkeiten (z.B. wenn “access” einer Schranke und des dahinterliegenden Wegs nicht passten) gefunden.

Es werden leider zu viele falsch positive Treffer angezeigt.

  • Eine Straße, die am Endpunkt ein “highway=turning_circle” hat, sollte nicht (oder allenfalls mit geringster Priorität) als Treffer angezeigt werden.
  • “service=driveway” und “service=parking_aisle” werden weit überwiegend als falsch positive Treffer angezeigt. Es wäre unschön, wenn jetzt überall “noexit” nachgetragen wird.
  • Wenn ein Weg kürzer als die Lücke am Wegende ist, liegt meist kein Fehler vor. Das tritt insbesondere auf Wegstummel zu Hauseingängen auf.
  • Wenn eine Straße endet und in der Nähe nur ein “highway=service” liegt, sollte dies nur als möglicher Fehler mit geringer Priorität angezeigt werden. In Gewerbegebieten findet man oft Straßen, die erst wenige Meter hinter der letzten Firmenzufahrt enden.
  • “man_made=pier” wird fast immer als Insel angezeigt. Das ist sinnlos.
    Überwiegend wird “pier” für kleine Holzstege verwendet, ohne eine öffentliche Nutzung zu implizieren.

Die Prioritätsstufen im Tool widersprechen dem Sprachgebrauch (1 als höchste, 5 als niedrigste Priorität)

Hallo,

ich habe die Daten gerade aktualisiert.

Kannst du da bitte ein Beispiel nennen? So schlimm ist es mir bislang nicht ins Auge gestochen.

In vielen Fällen dürfte es helfen, Zäune, Hecken, Böschungen, Mauern oder Stützmauern zu ergänzen. Die Software schließt aus, dass keine bemängelte fehlende Verbindung eine solche linienförmige Barriere kreuzt.

Wenn die Wege bis an die Haustür führen, kannst du die Tür mit entrance=* taggen. Dann wird der Punkt nicht mehr als Fehler ausgegeben werden und die Daten werden nützlicher, ohne dass es reines Tagging für den OSMI ist.

Da müsste ich ein konkretes Beispiel sehen.

Die Insel-Layer für Pkw und Fahrrad sind gedacht, die Welt so zu zeigen, wie GraphHopper sie sieht. Nur der Insel-Layer, der alle Wege beachtet, hat weniger Einträge, dafür aber echte Inseln.

Ich habe die Bezeichnungen angepasst.

Viele Grüße

Michael

Hier sind zwei.

http://tools.geofabrik.de/osmi/?view=routing_beta&lon=10.11495&lat=54.35686&zoom=18&baselayer=GeofabrikStandard&opacity=0.71&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5

Das trifft nicht immer zu. Oft laufen mehrere Parkreihen parallel und werden untereinander als Nachbarn erkannt.

http://tools.geofabrik.de/osmi/?view=routing_beta&lon=10.13459&lat=54.31051&zoom=18&baselayer=GeofabrikStandard&opacity=0.71&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5

Einige Meter östlich in der Straße Kesselschmied werden die Enden trotz des Zauns als Fehler erkannt.

Das wäre eine Lösung. Aber auch ohne entrance könnte man hier die meisten Fehleranzeigen unterlassen.

http://tools.geofabrik.de/osmi/?view=routing_beta&lon=10.10945&lat=54.35670&zoom=18&baselayer=GeofabrikStandard&opacity=0.71&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5

http://tools.geofabrik.de/osmi/?view=routing_beta&lon=10.19935&lat=54.31797&zoom=18&baselayer=GeofabrikStandard&opacity=0.71&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5

Dann ist die Annahme von GraphHopper falsch, dass alle Stege für Radfahrer geeignet sind.

Danke.

PS: Die Links sind zu lang. :wink:

Ist Nicht-Auswertung von Multipolygonen auch der Grund dafür, dass diese Linie hier als Routinginsel bemängelt wird? Oder liegt das eventuell an fehlender Unterstützung für Flächen mit highway=footway? Die Linie ist an beiden Enden mit dieser Fußwegfläche verbunden. Es gibt dort auch Warnungen über vermeintlich unverbundene Knoten, etwa diesen Node.

Hier noch der zugehörige Link: http://tools.geofabrik.de/osmi/?view=routing_beta&lon=13.45643&lat=48.57130&zoom=18&opacity=0.52

Hallo,

Wendeplatten sind nicht zwangsläufig am Ende einer Straße. Oft zweigt ein Feldweg ab. Ich habe letzte Woche genügend Feldwege in Rheinland-Pfalz gesehen, die Fortsetzungen innerörtlicher Wohnstraßen sind, die am Ortsrand mit einer Wendeplatte enden.

Das intensive Mapping von Fußwegen als separate Ways schafft von Natur aus unzählige Routingefehler, weil sich damit nicht alle Verbindungen praktikabel abbilden lassen. Manchmal wären sie sogar praktikabel mappbar, werden aber nicht gemappt, wie in San Jose, wo seit 1 1/2 Jahren ein unvollständiger Bürgersteigimport vor sich hin gammelt.

Ich habe eine Parallelitätsprüfung für service=driveway und service=parking_aisle ergänzt. Auf typischen Supermarktparkplätzen werden Fehlermeldungen jetzt unterdrückt weden.

Der Anzeige des Fehlers östlich der Straße Kesselschmid liegt ein Bug in meinem Code zu Grunde, den ich behoben habe.

Ich bin nicht so begeistert, dafür eine Extraregel einzuführen. Wenn man Mikromapping macht (Abzweige von der Reihenhauszuwegung zur Haustür), sollte man es bitte richtig machen und gleich noch entrance=yes/main ergänzen. Ich habe bei Fußwegen (footway, path, steps) eine Prüfung eingebaut, die Meldungen um 1 Relevanzstufe abstuft, wenn die Distanz der zwei Punkte über den Graphen nur zwei- bis sechsmal so lang ist wie die die Luftlinie. Wenn die Distanz über den Graphen maximal doppelt so lang ist wie die Luftlinie, wird der Fehler gar nicht mehr ausgegeben.

Wenn da kein weitere Weg, auch kein Trampelpfad weitergeht, kann man da noexit=yes taggen, ohne dass man sich als Für-den-OSMI-Mapper fühlen muss.

Ja, GraphHopper hat nicht mal einen rudimentären Multipolygon-Support. Das fällt auch bei Bahnhöfen auf. Das einzubauen würde den Rahmen des Projekts OSMI-Routing-View sprengen.

Wir werden in den nächsten Tagen den alten Routing-View im OSMI durch den neuen ersetzen, weil der alte mittlerweile nicht einmal mehr tägliche Updates schafft (es beschweren sich schon Stammnutzer per E-Mail).

Viele Grüße

Michael

Hallo,

Ich kontrollierte bis vor kurzem beinahe täglich die Unconnected mayor roads <1m im westlichen Europa und mehr, welche praktisch immer true positive’s waren und sich schnell fixen liessen. Diese Fehler-Kategorie hat meiner Meinung nach einen grossen Impact auf die Routingqualität, weshalb ich es motiviert zu verbessern versuchte.

Seit dem Stoppen der Datenaktualisierung des “alten” Routing-Views, gab ich dem neuen Routing-View eine Chance und konzentrierte mich auf die Unconnected nodes (urgent/very high likely errors). Leider bin ich sehr entäuscht. Neben den vernachlässigbaren false positives durch vermutlich alte Daten, gab es sehr viele andere Dinge, die für einen false positive sorgten oder für einen Sesselmapper nicht zu fixen waren. Alles in allem eine jeweils kleine Ausbeute an gefixten Fehlern. Noch dazu kann man nicht mehr so weit herauszoomen, was für eine schlechtere Übersicht sorgt.

Schade um die gut funktionierende alte Lösung. Falls die Rechenleistung nicht reichen sollte, könnte man meiner Meinung nach einfach mal die höheren Distanzen weglassen oder die Daten nur noch alle x Tage aktualisieren.

Vielleicht bessert es sich noch, aber im jetzigen Zustand werde ich vermutlich in Zukunft die Zeit für effizientere QA’s einsetzen.

Just my two cents… trotzdem Danke für Eure Arbeit!