Leitplanke

:confused: 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.

:smile:

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 :heart_eyes:
</ot>

man kann jetzt endlich die Beitr√§ge entsprechend mit emojijis w√ľrdigen :star_struck:

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.

Note: 3719290 | OpenStreetMap

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 :smiley:

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.