Schon komisch was einem an Themen so vorgeschlagen wird.
Aber weggerostet ist sie nicht. Aber ich bezweifele mal die OTG-Existenz des Wanderweges an der Stelle.
Kommt Zeit, kommt Mapping…
Erstaunlich, wer schon alles vor 12 Jahren mitdiskutiert hat …
Nun ja, mit diesen Luftbildern und Mapillary könnte die Leitplanke nun mal wirklich detailliert gemappt werden …
<ot>
Bei einigen Namen wird man schon nostalgisch 
</ot>
man kann jetzt endlich die Beiträge entsprechend mit emojijis würdigen 
Wirklich… Ist das also eine Leitplanke zu mappieren in ID oder JOSM, Ost-West, West-Ost, links rum oder rechts rum, vorwärts oder rückwärts entlang der Straße? Muss jah achten das die Pfosten am richtige seite erscheinen. :O)))
Genau!
Ausführlich diskutiert hier:
Mein erster Beitrag im “neuen” Forum. Die Rede von Nostalgie bei alten Namen, auch wenn wahrscheinlich nicht ich gemeint war, motiviert mich zu einem Kommentar. Ich finde es grundsätzlich gut, an alte Themen anzuschließen, wenn es neue Erkenntnisse dazu gibt, wie eben hier:
In Google Streetview sieht man es besser.
Also ein Weg ist eindeutig da, und zu meinem Entsetzen muss man tatsächlich über die Leitplanke steigen (oder drunter durchschlüpfen). Ich denke, es ist richtig, ihn durchgehend zu mappen, da er vor Ort ja sichtbar ist. Weil er zudem Teil einer offiziellen Route ist, sehe ich auch keine Rechtfertigung für informal=yes – es sei denn, der Verlauf der Route ist falsch gemappt. Das kann ich mangels Gebietskenntnis nicht beurteilen.
barrier=guard_rail würde ich vorzugsweise als Linie mappen, halt mit Schnittpunkt zum Weg. Aber als Node ist es besser als gar nicht. Auf keinen Fall gehört access=no auf diesen Node, denn ich sehe in Google Streetview kein Schild, dass das Übersteigen verboten ist. Meiner Meinung nach war die Vorversion (siehe Node History: 820562402 | OpenStreetMap) richtiger und die letzte Änderung eine Verschlechterung. Ich denke, am besten taggt man den Node mit barrier=stile wie in der Vorversion, aber ohne foot=yes (denn dass das Übersteigen erlaubt ist, ist vor Ort ebensowenig angeschrieben wie dass es verboten ist – bitte mappt, was ihr seht und nicht was ihr aus Gesetzen ableiten zu können glaubt oder was irgendein schwindliger Validator getaggt sehen will) und mit description=* statt note=* ; und die Leitplanke als Linie mit barrier=guard_rail.
O.k. bin davon ausgegangen, das dies als Absperreinrichung zu verstehen ist. Dieses Urteil sagt aber:
VGH München, Az. 11 ZB 19.1685 vom 04.09.2019 (Entscheidung) | REWIS RS 2019, 3884
Leitplanken seien weder Verkehrszeichen noch Verkehrseinrichtungen im Sinne der StVO. Ihre Anbringung könne ausschließlich der Sicherung der Straßenführung dienen und enthalte keine Sperrwirkung mit Regelcharakter.
Warum? Das ist dort doch nun wirklich nicht.
Ich hab keine Lust die ganze Leitplanke einzumalen. Nur einen Teil einzumalen halte ich für falsch. Es handelt sich um eine Barriere. Den Wert guard_rail darf man als Erläuterung verstehen.
Natürlich mappen wir auch Verbote die sich aus Gesetzen ergeben und nicht nur dinge die vor Ort beschildert sind.
Ich kann mir kaum vorstellen, dass diese Route in der Form noch gewartet wird. Das darf ein Ortskundiger gerne prüfen. Eine Umleitung über die Ampel weiter südlich wäre ja durchaus denkbar.
Laut Webseite wurde die Route über die Ampel verlegt
im Übrigen hätte die Routen-relation eh mal Wartungsbedarf.
links rum oder rechts rum
Leitplanken bitte umfahren 
Umfahren, oder umfahren? duck und weg
na umfahren natürlich
Mensch, das verstehen doch der translate-Button und unsere internationelen Mitleser nicht…
Gerichtsurteile sind fürs Tagging irrelevant. Relevant ist, was vor Ort feststellbar ist, s.u.
Es ist kein richtiger Überstieg vorhanden, aber die Leitplanke ist zu übersteigen, also praktisch wie ein Überstieg. Aber ich habe dazu keine ausgeprägte Meinung. barrier=guard_rail ist auch ok. Aber das würde ich nicht auf Node+Linie zugleich setzen, sondern nur auf die Linie (sofern gemappt) oder nur auf den Node (wenn die Leitplanke nicht als Linie gemappt ist).
Du kannst einen Teil einzeichnen und mit fixme=continue oder fixme=unvollständig o.dgl. versehen. Grundsätzlich finde ich, man sollte Objekte, die jemand anderer gemappt hat, nur entweder nach Absprache mit ihm umtaggen, oder wenn man sie oder ihre Umgebung genauer mappt. Bestehende Objekte nach eigenem Geschmack nur umzutaggen ohne Informationen hinzuzufügen ist nicht die feine Art und demotiviert die lokalen Mapper, die die wirkliche Arbeit leisten.
Wie kommst du darauf, dass das natürlich ist? Access-Defaults, die sich aus Gesetzen ergeben, sind spezifiziert in: OSM tags for routing/Access restrictions - OpenStreetMap Wiki. Gesetze können sich ändern, die Tags auf OSM-Objekte ändern sich dann nicht automatisch mit. Den Default im Wiki zu ändern ist hingegen eine Aufgabe von einer Minute.
Gerichtsurteile ins Tagging einfließen zu lassen finde ich sogar noch problamatischer, weil Gerichte oft von Fall zu Fall (oder je nach persönlicher Meinung der Richter) unterschiedlich entscheiden.
Tagging sollte vor Ort nachvollziehbar und verifizierbar sein. OSM ist eine Geodatenbank und kein Rechtsinformationssystem.
Ich bin etwas verwundert da du dich in der damaligen Diskussion ebenfalls skeptisch bzgl. der Route und des Taggings als Überstieg ausgesprochen hast. Der Weg dort ist gefährlich und so garantiert nicht von der Verkehrsbehörde vorgesehen. (Daher hatte ich den Schleichweg als informal umgetragen - aber ja, der ist offensichtlich gebaut und nachträglich durch die Leitplanke versperrt worden)
Die Geo-Route verläuft dort nicht mehr. Das müsste jemand vor Ort erkunden denn fremde Daten wollen wir ja nicht abmalen.
Nur weil man irgendwo drübersteigen kann, ist dort noch lange kein barrier=stile.
Das ist dort eine ganz normale Leitplanke. Es gibt dort keinen Überstieg (von der Art einer Treppe, Leiter).
Den Ansatz mit Default-Werten unterstüzte ich voll, funktioniert aber nur wenn die Tags (sowohl key als auch value) passend benutzt wurden. Bei stile statt guard_rail kann das nicht wirklich funktionieren.
Den Eindruck habe ich auch.
Ich denke doch, dass wir das wollen – sofern 2 Voraussetzungen erfüllt sind: Es muss erlaubt sein, und die abgemalten Daten müssen stimmen. Als operator=* ist der Regionalverband Ruhr getaggt. Soweit ich es verstehe, ist das eine Behörde. Da sehe ich gute Chancen, über eine Anfrage sowohl an einen aktuellen Routenverlauf als auch an die Genehmigung zu kommen, die Route in OSM abzubilden. Wobei letzteres rechtlich gesehen gar nicht nötig ist, aber eine explizite Genehmigung vermeidet OSM-interne Streitereien.
Je mehr ich drüber nachdenke, desto weniger bin ich in diesem Fall von barrier=stile überzeugt, denn jedes OSM-Objekt sollte einem realen Objekt entsprechen und dort gibt es keine 2 verschiedenen Objekte (Leitplanke und Überstieg), sondern nur eines (Leitplanke). Die Leitplanke sieht auf den Bildern relativ niedrig, somit übersteigbar aus, aber die Bilder können täuschen und die Übersteigbarkeit lässt sich besser mittels height=* angeben.
Für barrier=* finden sich im OSM-Wiki wenig Default-access-Werte, weil auch die Gesetze wenig darüber aussagen. Ich weiß von einer Ausnahme in der österreichischen StVO (“Fußgänger dürfen Schranken, Seil- oder Kettenabsperrungen nicht übersteigen, eigenmächtig öffnen oder unter diesen Einrichtungen durchschlüpfen”), aber daran hält sich kein Mensch, und ich weiß nicht, wie das in Deutschland ist. Vor Ort angeschriebene Verbote beziehen sich normalerweise auf den Weg oder das Areal hinter der Absperrung und nicht die Absperrung selbst. Darum finde ich es grundfalsch, dass manche Validatoren access-Tags auf barrier=* verlangen. Ich vermute den Hintergrund dieser Validator-Regeln in einer Verwechslung zwischen phsyischer und rechtlicher Benutzungsmöglichkeit.