Ja, bei punktförmigen Barrieren wird es aber auch in dem Sinne verwendet wer die Barriere passieren kann.
Warum einige Mapper den Bordstein gern auf den Schnittpunkt mit der Straße setzen möchten, obwohl laut Wiki davon abgeraten wird, weiß ich auch nicht.
Link zum Bugrep: Issues · Project-OSRM/osrm-backend · GitHub
Ich hoffe sogar, dass Router eine Strecker über einen barrier=kerb + kerb=raised mit einem dicken Penalty belegen. Ich möchte da nicht entlanggeleitet werden 
Ich kenne auch nur einen einzigen Weg mit einem barrier=kerb + kerb=raised und der ist zusätzlich mit einem Poller versehen.
Haben wir denn in Deutschland so etwas? Rampenschwellsteine, die keine Bordsteine sind, ja, aber so runde Bordsteine habe ich hier noch nicht gesehen. Sollte natürlich trotzdem überfahren werden können.
Ah, danke, das war mir nicht klar. (Ist im Wiki glaube ich auch nicht so dokumentiert, wie so vieles.)
Meine Vermutung ist, dass das kaum jemand bewusst so macht. Wenn ich mir die Changeset comments so anschaue, steht da immer so was wie “unvollständige Tags vervollständigt”, “tagfix” … nachdem in einem früheren Changeset StreetComplete kerb=raised gesetzt hat (“Add whether there is a crossing”) Die Mapper meinen es also gut, denn iD zeigt das kerb= ohne barrier= ja klar als Fehler an. Daher mein Drängen darauf, dieses Verhalten in iD zu korrigieren. Vielleicht liest hier jemand mit, der sich im iD-Code auskennt, sodass man die Arbeit an einem Pull Request anfangen könnte? Ich bin mir nicht mal 100%ig sicher, ob es ein Bug in iD selbst ist oder im iD Tagging Schema.
Weiß nicht, hab mal geschaut, ein paar gibt es anscheinend schon: overpass turbo
Die kommen nicht von StreetComplete, sind also vermutlich sehr bewusst so getaggt worden.
| osmuser63783
March 31 |
- | - |
chris66:
Ja, bei punktförmigen Barrieren wird es aber auch in dem Sinne verwendet wer die Barriere passieren kann.
Ah, danke, das war mir nicht klar. (Ist im Wiki glaube ich auch nicht so dokumentiert, wie so vieles.)
diese Sichtweise ist auch nicht unumstritten. Was sind denn “punktförmige” Barrieren? Da kommen mir “gate”, “bollard”, “lift_gate” und “block” in den Sinn (zumindest sind die meist als Nodes gemappt, wenn es sich in der Realität vielleicht in der Projektion auf die “Zeichenfläche” auch um lineare Dinge handelt), und das sind wohl auch die meistgenutzten: https://taginfo.openstreetmap.org/keys/barrier?filter=nodes#values
Bei diesen Barrieren bezeichnet access in aller Regel den rechtlichen Aspekt: wenn man bei einem “block”, “bollard”, “lift_gate” oder auch “gate” physisch zwar durchgehen kann (steht z.B. offen), das aber nicht darf, dann würden wir wohl foot=no / private setzen, und nicht foot=yes, weil es physisch ginge.
Die Mapper meinen es also gut, denn iD zeigt das
kerb=ohnebarrier=ja klar als Fehler an. Daher mein Drängen darauf, dieses Verhalten in iD zu korrigieren.
vielleicht sollte iD als allererstes einen Disclaimer erstellen den die bei allen Hinweisen voranstellen, wo sie klarmachen, dass es unmöglich ist, dass iD zu allen Taggingfragen und in allen Situationen auf dem Laufenden ist und die Lage korrekt “einschätzt”, und dass daher alle Hinweise zu veraltetem tagging, unnötigen tags, vermutlichen Fehlern, evtl. fehlenden tags, etc. alles nur Hinweise sind, bei denen man keineswegs davon ausgehen kann, dass sie stimmen (vielleicht steht da schon so was, aber es ist sicher nicht klar genug). Am besten, diese Hinweise würden überhaupt nur erfahrenen Mappern angezeigt (z.B. nach x hochgeladenen Changesets, so was wie 100 oder 300), weil die anderen sie nicht einschätzen können und daher zu Handeln gedrängt werden (tags ergänzen, entfernen oder ändern), ohne dass sie die Grundlagen haben, diese Änderungen zu bewerten.
Ich habe jetzt tatsächlich nie mit iD gearbeitet, sind das jetzt nicht Warnungen wie bei JOSM à la „overlapping buildings“, sondern Meldungen für Objekte, die man gar nicht angefasst hat, also eher à la Osmose?
So sieht das aus:
“Ignore” gilt leider nur für einen selbst und nur für die Session. Anders als “false positive” bei Osmose
Vor dem Hochladen wird nochmal gewarnt, falls man so ein Objekt angefasst hat:
Standardmäßig sieht man auch die erste Warnung nur, wenn man die Node anklickt. Es gibt auch ein Feature, wo man sich à la Osmose alle Warnungen für Objekte im aktuellen Sichtfeld anschauen kann.
ich habe iD schon länger nicht mehr angesehen, vor einiger Zeit hat er vorgeschlagen, massenhaft tags im runtergeladenen Bereich automatisch zu “fixen”, und ohne dass man die Sachen überhaupt angezeigt bekam konnte man mit einem Schlag hundert Objekte umtaggen indem man einfach auf “OK” geklickt hat 
Das ist wohl abgestellt, war noch zu Brians Zeit, aber anhand des Satzes “Die Mapper meinen es also gut, denn iD zeigt das kerb= ohne barrier= ja klar als Fehler an.” gehe ich davon aus, dass nach wie vor Dinge “klar als Fehler angezeigt” werden, wo es eben nicht “klar” ist, weil es eben nie völlig “klar” sein kann, solange man alle tags die man will setzen kann. Von daher die Bitte, es auch nicht so aussehen zu lassen, als wäre es “klar” ein Fehler.
was ist denn das Problem mit “looks like a common feature with nonstandard tags”? Sind nonstandard tags nicht ein Feature von OSM? Wieso hat das ein Warnsymbol?
Genau über diesen Dialog könnte man den Disclaimer setzen, dass es keineswegs Fehler sind, sondern nur Hinweise auf mögliche Fehler, und den Dialog Neulingen überhaupt nicht anzeigen, und anstatt von “Warnings” könnte es “Hinweise” heißen, etc.
Bisher ist es so, dass iD damit die Anfänger “fernsteuert”, nach Gutdünken des Editorautors Änderungen am bestehenden tagging vorzunehmen. Ein stückweit gibt es unpassende Hinweise auch vom JOSM-Validator, wobei da die Unterscheidung in note, warning und error zumindest schonmal bestimmte Hinweise als weniger relevant / sicher kennzeichnet, und man bei JOSM mehr Leute hat, die auf die Regeln draufsehen (habe zumindest diesen Eindruck). Werde mal versuchen, den neuen Maintainer dazu zu bewegen, das weniger authoritativ aussehen zu lassen.
Im von mir gezeigten Ausschnitt wird hier beim Klick auf “upgrade the tags” der operator Tag einer charging_station von “Stadtwerke Stuttgart GmbH” zu “Stadtwerke Stuttgart” geändert, und dem telecom=exchange mit operator=Deutsche Telekom AG wird noch operator:wikidata=Q9396 hinzugefügt
Das scheint ein generelles Problem zu sein, siehe dazu z.B. auch NSI suggestions are treated as valid when they are often not · Issue #9529 · openstreetmap/iD · GitHub
Ja, bei JOSM wird eher eine konservative Linie gepflegt. Bei zu vielen “false positives” wird höchstens die niedrigste Stufe gewählt, welche in den Einstellungen zunächst manuell aktiviert werden muss.
Auch wird eine automatische Korrektur sehr selten angeboten. Meist kann nur das Objekt ausgewählt werden. Gibt es diese Option in iD überhaupt?
ford=yes ist ein weiterer Kandidat, wo häufig blind vertraut wird, anstatt sich die Stelle genau anzuschauen und dann entsprechend zu entscheiden ob es sich um eine Brücke, einen Rohrdurchfluss oder Tunnel, oder eben wirklich um eine Furt handelt. 
Warum sollte man nicht über den oben von mir verlinkten 4 cm raised kerb geleitet werden? Porsches brechen da wohl auseinander, so langsam wie Autos manchmal über kleine Kanten fahren, aber für Radfahrer ist das ja nix außergewöhnliches …
es gibt übrigens ein proposal für “normalhohe” Bordsteine, https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular
allerdings abgelehnt (m.E. zurecht, weil es etablierte Werte umdefinieren wollte anstatt sie kompatibel zu ergänzen oder längerfristig zu ersetzen).
Ich könnte mir vorstellen, weitere Definitionen für kerbs einzuführen.
die etablierte 3cm-Unterscheidung ist gut und würde ich behalten, aber den Wert “raised” würde ich entweder deprecaten weil die Info zu grob ist (alles zwischen 3cm und ~33cm Höhe bzw. nach oben offen), oder mit einem weiteren key “raised” verfeinern (was dann aber langfristig bedeutet, dass man für alle nicht abgesenkten kerbs mind. 2 tags setzen muss, nur um deren Zugehörigkeit zu einer groben Höhenklasse auszudrücken).
Als neue Klassen (Vorschlag der sicher noch verfeinert oder verbessert werden kann),
neue Klasse zwischen lowered (3) und “normal/regular” (8?), Name unklar (“low”? “medium”?)
neue Klasse regular 8-12(?)
neue Klasse high (über 12)
ggf. noch eine Klasse über “high”
Evtl. könnte man auch die funktionale Klassifizierung weiter ausbauen, wikipedia erwähnt einen “Buskapstein”?
Was meint Ihr?
Messen und genau eintragen wäre zwar am universellsten verwertbar, und kann man auch gerne promoten, nur glaube ich nicht dran dass es mittelfristig passieren wird (außer jemand macht eine app, die das automatisch mit den Sensoren des Handies ermittelt).
Ich fände es schon sinnvoll, wenn wir zwischen flush, low(ered), high und raised unterscheiden würden. High wäre dann alles, wo kein Fahrzeug unbeschadet und ungebremst hochkommt, raised dann speziell erhöhte Dinge wie z.B. für Busse. Der Ausdruck „Regular“ war vermutlich einfach zu schwammig, aber wir wissen hier alle, was gemeint ist. Wobei ich ehrlicherweise „raised“ nur brauche, so lange ich die Bürgersteige noch nicht separat erfasst habe oder wenn es an einer Kreuzung tatsächlich mal keinen abgesenkten Bordstein gibt. Und bei der Handvoll habe ich derzeit kerb:height=0.12 ergänzt, weil das dem Standard hier entspricht. Und ob das nun in Wirklichkeit 10 cm oder gar 14 cm sind interessiert doch auch keinen. Soooo präzise sind wir dann auch nciht.
ja, die cm-Angaben dienten nur als Richtschnur, selbst wenn man versuchen würde, genau zu messen würde man vermutlich auch leicht unterschiedliche Höhen am selben Bordstein messen. Und man müsste festlegen, wo genau man misst, weil z.B. durch mehrfaches Aufbringen der Deckschicht diese teilweise wächst, so dass von der Rinne nur noch ein schmaler Spalt zwischen Asphalt und Bordstein übrigbleibt, weil der Asphalt “drüberquillt”, d.h. die ursprüngliche Höhe / die direkt am Bordstein interessiert nicht mehr, wenn der Streifen der sie hat nur noch 2 cm breit ist
Was soll eigentlich die Kombination:
barrier=kerb + kerb=no aussagen?
Ist das nicht ein Widerspruch in sich?
Anzahl Fälle in D ca. 80.
Stimmt, das macht keinen Sinn. Hab mir mal ein paar Fälle angeguckt. Die meisten stammen ja wohl von StreetComplete. Wenn ein footway oder path auf eine Straße trifft, fragt SC ja, wie da der Bordstein aussieht. Wenn da gar kein Bordstein ist, wurde ursprünglich barrier=kerb kerb=no gesetzt. Letztes Jahr hat das jemand als Bug gemeldet und inzwischen ist es behoben. (Jetzt wird nur noch kerb=no gesetzt.)
Die 80 Fälle stammen wohl noch aus der Zeit davor.
Ich finde es auch wenig sinnvoll, wenn alles ab 4cm “raised” ist. Das ist auch nicht sehr intuitiv, denn bei “raised” (“erhöht”) denke ich als erstes an einen Bordstein, den man bewusst höher gebaut hat als die normale Höhe der Bordsteine in der Umgebung.
Das gleiche gilt im Prinzip auch für den Begriff “lowered”. Nun kann man argumentieren, dass es für einen Rollstuhl- oder Fahrradfahrer egal ist, ob der Bordstein 3cm hoch ist, weil man den Bordstein bewusst abgesenkt hat, oder weil der Bordstein dort einfach niedrig ist.
Der Unterschied zwischen 5 und 25cm ist aber wichtig. Außerdem ist es praktischer, wenn man eine “Pi mal Daumen” Kategorisierung wie flush/lowered/high/raised hat, als jeden Bordstein mit einem Zollstock zu vermessen. Kurz: ich wäre dafür, hier mindestens eine neue Kategorie einzuführen.
Ich wusste manchmal auch nicht, was ich für eine “normalhohe” kerb von ca. 5 (?) Zentimetern nehmen sollte, über die Rollstuhlfahrer nicht so einfach drüber kommen. Habe damals dann kerb=yes getaggt.
Tja, von alleine fixen die sich nicht…
Hier noch die OPQ (noch 33 Fälle, Hotspot Braunschweig):
EDIT: b=kerb+kerb=no ist nun in D-Land bereinigt.
