kerb=* beschreibt kein Feature, sondern ist eine Eigenschaft von einem barrier=kerb oder highway=crossing.
https://wiki.openstreetmap.org/wiki/DE:Key:crossing#Zusätzliche_Merkmale
Siehe auch What to tag when there is a different kerb on each side of a crossing?
StreetComplete Implementation des genannten Quests: add crossing kerbs quest by westnordost · Pull Request #5104 · streetcomplete/StreetComplete · GitHub
Jah, einer Seite war einem flush ander Seite normal, ‘nicht’ raised!
Ah, interessant. Dann ist What to tag when there is a different kerb on each side of a crossing? umso relevanter.
Zusammengefasst wurde gesagt, dass für einen solchen Fall kerb:left und kerb:right benutzt werden kann, und so steht es auch momentan in der Wiki…
Alternativ, kann auf dem kreuzenden Knoten,
kerb:left=*undkerb:right=*genutzt werden.
… aber es wurde von einigen Diskussionsteilnehmern angezweifelt, dass dies (in Grenzfällen?) sinnvoll möglich ist. (Ich tagge mal hier @Nadjita ). Sollte die Dokumentation geändert werden so dass sie von der Nutzung dieser tags abrät?
So oder so würde es wohl Sinn machen, wenn StreetComplete nicht nach der Beschaffenheit der Kantsteine fragt, wenn kerb:left und kerb:right gesetzt sind?
Ja, leider ist das Bordsteintagging in OSM sehr merkwürdig definiert (wohl historisch so gewachsen).
Was OSRM angeht werden kerbs an hw=crossing generell ignoriert.
Die Kombination ist in der Tat seltener
Trotzdem finde ich das Schema - wie @chris66 und @flohoff anmerkt - grundsätzlich auch sehr seltsam. Das macht die Nutzung von OSM-Daten noch einmal ein Stück “schwieriger”. Gelinde gesagt.
Ja, das liebe Bordstein-Tagging 
Das Schema ist dämlich, weil historisch so gewachsen, aber was will man machen?
Das SC-Problem des doppelten Taggens wurde auch ein paarmal kritisiert, aber es ist wohl zu schwierig („such complexity is not really worth to implement“).
Das denke ich auch. Es ist ja alles damit gesagt, was es zu sagen gibt 
Es ist ja eine grundsätzliche Geschichte Dinge auf Kreuzungsnodes zu packen. Da gilt dann immer für alle beteiligten Wege. Das haben wir bei traffic_signals, barrier etc. Muss man sich schon gut überlegen.
Und Richtungsinformationen auf nodes ist schwierig bei einem way, bei mehr als einem isst es quasi nicht lösbar und kaputt. Die ganzen traffic_signals direction forward/backward geht ja auch nicht vernünftig. D.h. bei seperat gemapptem traffic_signals hat man die penalty immer mehrfach.
Und barrier=* ist halt immer - “Ne - hier geht nix” - Deshalb sollte man da schon sparsam mit umgehen und wissen was man tut - Das wie mit der gießkanne zu verteilen macht halt viel kaputt. Und ich bin gerade wieder über einen Changeset von vor 4 Monaten gestolpert wo jemand MASSENHAFT barrier=kerb verteilt hat - Mir war das wegen kaputtem routing aufgefallen. Angeschrieben. Jetzt nach 4 Monaten wieder drüber gestolpert - bisher aber keine Antwort - Nervt halt.
Ja - Die router wollen/ziehen nach mit “barrier=kerb/kerb=lowered” geht dann wieder für alle modalitäten - aber was soll denn so ein mumpitz. Dann gleich das barrier weglassen.
Flo
Und weshalb korrigierst Du es dann nicht selber?
Kannst Du das CS mal nennen? Die Query liefert im Raum OWL derzeit keine Barrier-Nodes, die in OSRM sperrend wirken.
Ich setze auch haufenweise barrier=kerb + kerb=lowered dort, wo ein abgesenkter Bordstein eben ist – hauptsächlich service=driveway – und hab bei noch keinem Router Probleme festgestellt. Was das soll? Vorfahrt gewären natürlich und für Rollstuhlfahrer beim Routen auch wichtig. Oder was meinst Du genau? Auf Kreuzungsknoten gehört das natürlich nicht…
Ist ja korrekt, wenn sich der Bordstein wirklich auf der Straße/Zufahrt befindet.
Du kennst das Thema Skaleneffekte?
Ich kann hinter 100 Leuten herlaufen und das korrigieren. Dann mache ich nichts anderes.
Oder ich kann anfangen diesen Leuten zu erklären das sie da einen Fehler machen und hoffen das sie sie nicht mehr machen. Dann mache ich über die Zeit aus 100 Leuten die quatsch eintragen vielleicht 20. Dann muss ich nur noch hinter 20 aufräumen.
Es hilft NICHTS Fehler zu korrigieren wenn nicht vorher aufgehört wird sie immer und immer wieder zu machen. Dann wird die Anzahl der Leute die quatsch eintragen größer, und die Anzahl der Leute die die bereinigen kleiner weil die Frustriert aufgeben.
Das ist eine Frage wie man so seine Rolle sieht. Und Kommunikation (Wir hatten das Thema schon bei den Notes) ist ein Multiplikator. Man kann das für Doof halten (hat man mir ja schon bei den Notes erzählt) - aber das ist halt wie aufgeben. Achselzuckend daneben stehen wie Quatsch in die Datenbank gespült wird und wie Don Quijote gegen Windmühlen kämpfen.
Und ich habe es mehrfach hier erlebt wie ein EINZELNER Mapper innerhalb von Tagen bis Wochen ganze Landstriche verwüstet weil grundlegende Dinge nicht verstanden waren. Es geht darum die früh und schnell zu entdecken und mit denen zu kommunizieren um Fehler zu verhindern und nicht es geschehen zu lassen und die dann mühsam zu bereinigen.
Und wie ich das versuche kannst du ja by HDYC sehen was die Anzahl der Changeset Comments und Notes angeht.
Mal zum vergleich zwischen uns beiden weil es so schön passt - Wir haben fast Zeitgleich angefangen bei OSM:
https://hdyc.neis-one.org/?flohoff
OSM Notes: Closed w/ comment 2,315 (w/o 170), commented 1,511 and opened 3,986
Changeset discussions: Participated in 1,703 and created 2,518 comments
Rollbacks performed: Reverted 650 changesets w/ 2,800 changes of 307 contributors
https://hdyc.neis-one.org/?chris66
OSM Notes: Closed w/ comment 2,229 (w/o 5), commented 405 and opened 498
Changeset discussions: Participated in 201 and created 244 comments
Rollbacks performed: Reverted 966 changesets w/ 17,994 changes of 602 contributors
Ich habe faktor 8.5 mal mehr an Changeset Diskussionen Teilgenommen
Ich habe faktor 10.3 mal mehr Changeset Kommentare geschrieben
Ich habe faktor 8 mal mehr Notes eröffnet
Ich habe faktor 3.7 mal mehr Notes kommentiert
Ich habe aber nur 0.67 mal so viele Changesets reverted.
Bestätigt das was ich oben schrieb. Kommunikation verhindert quatsch in der Datenbank den man ansonsten aufräumen oder reverten müsste.
Auf die Kommunikation “Ich glaube hier ist ein Fehler” mit “Und weshalb korrigierst Du es dann nicht selber?” ist halt überhaupt nicht zielführend.
Flo
Ist vielleicht etwas harsch rübergekommen. Es war als sachliche Frage gemeint, die Du sachlich beantwortet hast, alles ok. Es gibt halt unterschiedliche Persönlichkeiten, Leute die gerne reden und Leute die gerne machen. 
Ich habe es gerade nochmal getestet - Spannend - Alle bestehenden router (valhalle, osrm, graphhopper) im Bicycle profil ignorieren reine barrier=kerb - Au backe. Das ist natürlich genauso falsch.
Im car profile ist mittlerweile barrier=kerb + kerb=lowered/flush passierbar.
Hier mein Test. Da sind barrier=kerb gesetzt ohne lowered/flush. Spannend … Hat sich die Situation geändert. Aber nur bedingt besser.
Flo
Ich mache sowas Beruflich. Ich bin seit fast 30 Jahren der externe IT Aufräumer. Ich komme in Firmen und räume deren IT Altlasten/Technical debt weg und baue denen basierend auf dann sauberen Daten Automatisierungen.
Und das ist eine der Erkenntnisse - Wenn du nicht aufhörst damit Schrott einzutragen in die Datenbanken hast du verloren. Man kann das nicht als einzelner Aufräumen. Du hast dann ggfs 1000 Leute die Schrott eintragen und vielleicht 2-3 die Aufräumen. DAS skaliert nirgends.
Deshalb geht es darum die 1000 abzuholen das sie eben saubere Daten pflegen. DANN kannst du mit 2-3 den Bestand aufräumen, und DANN kannst du anzufangen zu Automatisieren.
Immer nur im klein hinterher zu reparieren bringt dich nirgends hin.
Flo
Ja, im Fahrrad- und Fuß- Profil werden Bordsteine von OSRM ignoriert. Ist ja auch korrekt, man kann da drüber fahren ohne dass das Rad kaputt geht, bei einem Auto ist das anders.
PS: Das Radweg-Tagging dort ist verbesserungswürdig, Note ist erstellt.
Fuß sehe ich ein - Mit dem Rennrad oder mit dem 30kg eBike fährst du keinen Bordstein hoch. Ich hätte erwartet das barrier=kerb gemieden wird es sei denn es ist kerb=lowered oder kerb=flush gesetzt.
Flo
Das hätte ich auch gedacht. Prinzipiell kommt man ja auch mit einem Auto den Bordstein hoch – gibt genug Parken halb auf dem Bordstein. Der Unterschied für Fßgänger vs. Fahrrad und Auto ist, dass man das eigentlich nicht darf, bzw. soll. Für mich ist das bei nicht beschilderten Wegen der Hauptfaktor: ist die Führung auf die Straße abgesenkt? Dann Fahrräder erlaubt. Wenn nicht, dann sollen die da nicht hin. Also ich fände es besser, wenn die Router das ignorieren würden, aber letztendlich kann man ja immer auch absteigen und anheben 
barrier=kerb ohne kerb=* wiederum ist Murks. 6876-Vorkommnisse alleine in Deutschland. Das ist wohl ein Fall für eine MR-Challenge
Problem: Lässt sich nur vor-Ort prüfen.
Kerb ‘features’ certainly are important to the wheelchair and trike-bike bound for their mobility, seeing the occasional SC flag saying to have answered N times of interest to these. Crossings in cyclepath signed as a cycle crossing where you have to perform the hop trick are disgusting particularly if it goes immediately 90 degrees to turn parallel to the road and pavement is wet but such is the quality of the city planners… Poor.
Oder Mapillary / Kartaview. Und bei manchen Orten bin ich mir sicher, dass man das auch aus dem Luftbild seht. Allerdings sind die meisten Vorkommnisse auf Fuß-/Radwegen. Fragt SC bei solchen fehlenden Tags auch nach?