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

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

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: