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.
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:
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.
gormo war ein paar Minuten schneller als ich. 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 vielen Fehlermeldungen an (U-)Bahnhöfe kommen daher, dass die Bahnsteige oft als Multipolygone gemappt sind und GraphHopper sie gar nicht auswertet.
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.
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.
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 )?
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.
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)
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.