Ich sehe die Aktion als Revert des von den Editoren (ID,SC) verursachten Fehltaggings.
Im zweiten Schritt kann dann natürlich gerne diskutiert werden, wie man das Borsteintagging generell verbessern kann.
So wie es jetzt ist (Tagging mal an der tatsächlichen Position und mal am Kreuzungspunkt mit der Straße) ist nicht sinnvoll auswertbar.
Was meinst du?
sehe ich nicht als so wichtig an, weil ich als Datenauswerter diesen tag alleinstehend ignorieren würde, ich würde aber auch das Entfernen des “alleinstehenden” tags von ways unterstützen. Auf nodes würde ich ihn lassen, weil da eher ein Zusatztag fehlt (crossing/kerb)
So wie es jetzt ist (Tagging mal an der tatsächlichen Position und mal am Kreuzungspunkt mit der Straße) ist nicht sinnvoll auswertbar.
es gibt wirklich Stellen wo man mit “üblicher” Interpretation falsch liegt, wenn z.B. am crossing node ein beidseitiger “kerb” angegeben ist, seitlich davon nochmal barrier=kerb dann würde man denken es ist derselbe Bordstein, es könnte aber auch 2 Bordsteine geben (z.B. bei Arkaden - Bordstein - Gehweg - Bordstein - Straße ….) oder auch sonst selten.
Abgesehen von solchen Ausnahmen ist es von der Auswertbarkeit her meistens egal, wohin man die kerb-Information taggt
So, ich habe mein Skript jetzt laufen lassen. Es verbleiben noch ca. 350 Knoten weltweit mit barrier=kerb kerb=raised auf Straßen, viele davon zurecht (z.B. wo die Straße endet und ein Fußweg anfängt). Etwa 150 davon sind in der “Mitte” der Straße (also nicht der erste oder letzte Knoten des highway). Diese müsste man wohl manuell durchgehen, um das Routingproblem (und Datenproblem!) zu beseitigen.
Vielleicht ist dafür Maproulette geeignet?
Danke, dann werde ich hier die Fälle weiter einzeln durchgehen.
lowered kerbs werde ich nicht ändern, auch wenn ich da das barrier ebenfalls für einen Fehler halte (wenn auf dem Kreuzungspunkt mit der Straße gesetzt).
Also in Zirndorf gibt’s “astreines” Mapping für den Rollstuhlrouter, mich würde mal interessieren ob sich die Bordsteine wirklich da befinden wo sie eingezeichnet sind.
Bei barrier=kerb ohne weitere Angabe geht OSRM einfach mal vom Worst-Case aus (10 Zentimeter hoher Bordstein) und sperrt das Routing für Autos.
Hat dein Editor kein Luftbild, oder ist es in der Gegend so unscharf? Ist aber vermutlich für den Rollstuhlfahrer nicht ganz so relevant ob der Bordstein 50 cm weiter vorne oder hinten liegt, das sieht und merkt er dann schon.
Finde ich richtig so.
Den lass ich mal so und rette damit einige tiefergelegte BMWs.
Und den Reifen- und Felgenmörder auch:
Das ist klar, mir geht’s darum ob der Bordstein auch in Realität direkt in der residential liegt.
Das konnte ich aus deiner Grafik aber nicht erkennen.
Aber in dem Punkt stimmen wir vermutlich überein: Ein Fein-Mapping sollte auch mit der entsprechenden Genauigkeit erfolgen, sonst lieber keine Borsteine einzeln einmalen.
Moin, @osmuser63783
Die Mapper ergänzen schon wieder fleissig das fehlende barrier=kerb… 
So ist in Hamburg schon wieder alles rot.
Das ist alles vom gleichen User. Haben wir noch ein QA-Tool, dass das als Fehler markiert? Der ID-Editor ist es ja jetzt nicht mehr.
Als Editor hat er iD 2.25.2 genutzt.
Ich hab das jetzt mal als crossing markiert und den Nutzer benachrichtigt.
Hier eine modifizierte Version des Abfrage-Skripts:
Prüft auch end-nodes und hw=crossing Nodes werden ausgefiltert, da sie in OSRM keinen Routing-Fehler verursachen.
Der derzeitige Hotspot Hamburg ist vor-eingestellt.
Die Mittelknotenprüfung hast du auskommentiert.
Ja, schrieb ich ja, dadurch wird mehr gefunden, wovon ein Teil aber false-positive ist.
service-roads wie diese Parkplatzauffahrt sind natürlich auch betroffen (wurden in den Overpass-Abfragen bisher ausgespart).
Komisch, denn eigentlich ist die Änderung seit dem 5. Mai im iD tagging schema drin. Vielleicht wird das nicht unmittelbar in iD übernommen?
Aktuell schlägt iD das nicht mehr vor, also hoffentlich ist es jetzt damit vorbei.
