Hinweisschild Fahrrad

Nein: ‘ref’ ist die Nummer des guidepost

Wir entwickeln uns doch weiter, oder? Klar kann man jeglichen Fortschritt durch “Das haben wir schon immer so gemacht!” blockieren.

Was sagt https://wiki.openstreetmap.org/wiki/Key:bicycle?

Gut, jetzt kann man lange diskutieren, ob bei es der Formulierung von “Legal restriction for cyclists.” schon “information=guidepost” gab und ob man das dann anders formuliert hätte …

Welchen Mehrwert hätte “guidepost:bicycle=yes” gegenüber “bicycle=yes” mal abgesehen von der Formulierung “Legal restriction for cyclists.” an anderer Stelle?

Wie auch immer: wir haben die Co-Existenz von “guidepost:=yes", "guidepost=” und *=yes" und die wird bleiben und muss von allen Tools berücksichtigt werden.

Edit: “guidepost=*” hinzu

Nach meiner Kenntnis (ohne es jetzt im Wiki noch einmal überprüft zu haben, aber ich tagge viele Wander- und Radfahrwegweiser) ist bicycle=yes (bzw. hiking=yes) das veraltete Taggingschema und guidepost=bicycle (bzw. guidpost=hiking) das aktuelle. Ich gebe zu, dass ich - weil ich sicher gehen will, dass alle Anwendungen das erkennen, bislang beide Taggingformen an die entsprechenden Wegweiser pappe. Wahrscheinlich zementiere ich aber damit ungewollt die Coexistens beider Taggingschemata.

guidepost:bicycle=yes ist mir bislang noch nicht untergekommen.

Ich werde weiterhin bicycle|hiking=jes verwenden.

Davon halte ich überhaupt nichts… Man wäre gezwungen bei Wegweiserpfosten, die beides haben zwei Punkte zu setzen, was sich Real vor Ort anders darstellt! Hier in meiner Gegend haben solche Wegweiser an einem Pfosten sehr gerne entweder Radwegschilder (grüne Schrift auf weißem Grund) und Wanderwegschilder (weiße Schrift auf grünen Grund) oder je nach Landkreis nur Richtungsbeschilderung grüne Schrift auf weißem Grund und im Einschub drunter dann die nächste Knotenpunktnummer und Logo Themenradweg und Symbol Wanderweg. Gerne haben die auch zwei Nummern: eine gültig für die Wanderwegsschilderteil und eine für die Radwegschilderteil. Da nehme ich ref:hiking=* und ref:bicycle=*. …und dann kann das auch noch ein Rettungspunkt sein.

Das mit direction_= ist nett, da wird man aber auch adlig, eh man alles erfasst hat…

Als ehesten könnte ich mich an guidepost:bicycle=yes umgewöhnen… dann aber bitte auch eine bot-Aktion die alles in einem Rutsch umbaut… wird aber nicht passieren.

Sven

Du hast wohl Recht, Sven. Die access-Tags werden auch für andere Dinge verwendet (z.B. an E-Ladestationen). Ist halt unschön, weil widersprüchlich, was die Definition der verwendeten access-Tag betrifft.

Wobei, ist bicycle nicht einfach überflüssig bei:

lcn=yes
network=lcn

Das sind aber doch auch andere Gründe, diese Wegweiser - auch wenn sie an einem Pfosten hängen - als unterschiedliche nodes einzutragen. Ich trage bei solchen Wegweiser auch die Richtungs- und Kilometerangaben ein. Und bei solchen kombinierten Wegweisern kenne ich es nur so, dass sich die Ziele von den Radwegweisern deutlich von denen der Wanderwegweisern unterscheiden. Soll man dann noch mit direction_southwest:bicycle=Pusemuckl 4kmkm;Blitzeiche 14km und direction_southwest:hiking=Fernsehturm 2km;Stauteich 3km;Pusemuckl Bahnhof 5,3km arbeiten? Und wenn ein Notfallrettungspunktschild auch mit am Pfosten hängt, was soll dann der Renderer als Symbol anzeigen, dass für einen Rettungspunkt oder das für einen Wegweiser?

Was ist, wenn das alles auch noch an dem Pfosten einer Straßenleuchte hängt - fügen wir dann noch die Eigenschaften der Straßenleuchte mit hinzu? Daher habe ich mich längst von dem Gedanken verabschiedet, unterschiedliche Objekte, die an ein und dem gleichen Pfosten befestigt sind in einem einzigen Node einzutragen. Natürlich sind auch zwei, drei oder gar vier Nodes nah nebeneinander auch nicht das Gelbe vom Ei. Doch halte ich das Durcheinander von Attributen verschiedener Objekte in einem Node für problematischer.

Rettungspunkte sin eine eigener Namensraum. Das sollte kein Problem sein… Ich sträube mich etwas, diese direction-Angaben zu erfassen…

Ok, ja, die sind da. Was da ist, kann man erfassen… Aber man erfasst doch auch gleichzeitig das Radweg-Wanderwegnetz, bzw. deren Routen. Allein dadurch ergeben sich Richtung und Entfernung… Ich halte den Erfassungs- und Wartungsaufwand für zu hoch. Bei der Vielzahl an Wegweisern an den Knoten, Abzweigungen und Punkten dazwischen bekommt man immer nur einen kleinen Teil systematisch erfasst… Für mich ist das ein bisschen eine Kosten-Nutzen-Analyse… Erfassungs- und Wartungsaufwand ist meiner Ansicht nach sehr hoch, einen Nutzen, in Hinblick auf Auswertung und Verarbeitung beim Routing für Wandern/ Radfahren sehe ich im Moment eher als begrenzt an.

Ich erinnere mich auch noch an Disskussionen, das sogar als Relationen mit from - via - to (oder so) zu erfassen… ist schon ein paar Jahre her…

Ich für mich betrachte die Aussage: “Das ist ein Wegweiser für Rad und/oder Wandern mit/ohne Knotenpunkt mit/ohne Rettungspunkt” als ausreichend. Das an einem Punkt zu erfassen, funktioniert, meiner Ansicht nach.

Die zugehörigen ref-Nummern bei der Pfostennummerierung für Rad/Wanderausschilderung ist eigentlich schon eine nette Dreingabe… selbst hier sehe ich keine reale Auswertemöglichkeit/-notwendigkeit, wenn nicht der entsprechende Landkreis oder wer auch immer seine Datenhaltung konkret auf OSM ausrichtet…

Sven

Moin,

Das ist bislang wohl auch der einzige Sinn und Zweck dieser Angaben?
Da die Wegweiser ja getrennt vom highway-Netz aufgestellt (gemappt) sein sollten, können sie ja bei Routingansagen nicht (einfach) einbezogen werden.
Rein interessehalber stellt sich mir die Frage, ob daher nicht bei solchen Kreuzungen die direction-Angaben am highway analog zum KFZ-Verkehr für Routing-Ansagen sinnvoll wären?
Zumindest sofern es sich um eigenständige Rad-/Wanderwege handelt und es nicht mit dem allgemeinen KFZ-Verkehr kollidiert?

Grüße
Georg

Ich sehe bisher auch keinen Grund, solche Daten zu erfassen. Was soll das bringen ?

Das schrieb rainerU bereits:

Sorry, ich kann da immer noch keinen Sinn / Nutzen sehen.

Die Online-Karte https://hiking.waymarkedtrails.org zeigt in der Wander-Ansicht Wanderwegweiser, in de Radfahransicht Rad-Wegweiser an. Diese Wegweiser sind als anklickbare Symbole dargestellt. Durch Anklicken bekommt man die in OSM hinterlegten Informationen angezeigt, u.A. auch die Ziele, sogar mit einem Pfeil, der die Richtung der jeweiligen Ziele anzeigt. Da nicht alle Wander-Richtungswegweiser Teile von Knotenpunktnetzwerken sind, da auch auf manchen Wanderwegweiser Ziele gewiesen werden, zu denen in der gewiesenen Richtung keine markierte Wanderwegroute führt, halte ich diese Informationen durchaus für hilfreich. Ich kann sehen, dass der Wegweiser an eine bestimmten Kreuzung das Ziel “Beispiel-Aussichststurm” in westlicher Richtung weist, obwohl es offensichtlich in der Richtung keinen markierten Wanderweg gibt. Ich hätte vorab die Information, dass man als Wanderer über den entsprechenden Weg zum Aussichtspunkt wandern kann.

Es gibt halt in der Realität dreierlei Systeme: Durchgängig markierte Wanderrouten, durchgängig durch Wanderwegweiser an allen Knotenpunkten ausgeschilderte Knotenpunktnetzwerde und eine Vielzahl von einzelnen Zielwegweisern. Dass sich Zielwegweiser am schlechtesten auswerten lassen, ist für mich kein Grund, diese Information nicht in OSM bereitzustellen. Wie ich ja beschrieben habe, gibt es eine mögliche Nutzung (die ich persönlich auch schon genutzt habe) und es gibt bestimmt noch andere hilfreiche Nutzungen.

Hier ein Beispiel:

Es gibt hier genau eine Wanderroute und die führt von Nord nach Süd bzw. umgekehrt. Aber wer hier die ausgeschilderte Wanderroute verlässt und nach Westen abbiegt, kann durch einfaches Folgen des Forstweges diverse Wanderziele und andere Wanderrouten erreichen, obwohl der Weg selber keine Wanderroute ist. Und es handelt sich auch nicht um ein Knotenpunktnetzwerk. Ich habe also die Information, dass dieser Weg offensichtlich zum Wandern geeignet und darüber das gewünsche Ziel zu erreichen ist und dass es einen Wegweiser gibt, der mir anzeigt, wo ich genau in welche Richtung abbiegen muss.

Anderes Beispiel zu dem von mir in #20 geschriebenen:

Hier ist ein Wanderwegweiser in einem Bereicheingezeichnet, wo keine Wanderroute entlangläuft. Leider wurde nicht erfasst, in welche Richtung dieser Weg welches Ziel weist. Denkbar wären Ziele in Wegrichtungen aber auch Ziele abseits des Wegs wie z.B. ein Wegweiser, der auf eine Ruine 50m südlich des Wegs hinweist. Mit der Zielangabe an dem Wegweiser-Node hätte ich diese Information und könnt sie bereits bei der Planung einer Wanderer zuhause nutzen. Ohne die Zieleingaben (so wie der Wegweiser aktuell eingetragen ist), ist es eine relativ nutzlose Information: “Da steht irgendein Wanderwegweiser der irgendwohin weist”.

Ich sehe da neben dem von mir schon genannten praktischen Grund noch weitere:

  • Es ist genau so sinnvoll, wie viele Details, die an Objekten erfasst werden, bei denen ich mich auch nach dem Sinn/Nutzen frage, z.B. die Farbe von Parkbänken. Es ist eine sichtbare und vor Ort überprüfbare Eigenschaft des Objekts, und das reicht aus, um es in OSM zu erfassen.

  • Darüber hinaus bilden die Richtungsangaben die OTG-Grundlage für die in OSM erfassten Radverkehrsnetze. Diese Information zu erfassen ist daher genau so sinnvoll wie z.B. ein traffic_sign=DE:240 am Beginn eines Rad- und Fußwegs oder ein traffic_sign=DE:274[70] am Beginn einer Geschwindigkeitsbeschränkung.

  • Die Richtungsangaben auf Wegweisern am allgemeinen Straßennetz werden erfasst, warum dann nicht auch am Radverkehrsnetz?

Das Erfassen der Richtungsangaben mit direction_xxx=* am Wegweiser hat sich eingebürgert. Besser ware es allerdings, das analog zum Straßennetz als direction:bicycle=* an den abgehenden Wegen zu machen, so wie ich es schon vereinzelt gesehen habe: www.openstreetmap.org/way/31863324. Dann könnte diese Information auch von Navigationsanwendungen für Fahransagen ausgewertet werden.

Fürs Routing wäre dies zwar ein Vorteil, für die von mir geschilderte Nutzung ist die Erfassung am Wegweiser günstiger. Hier sehe ich auch einen Unterschied zwischen den Bedürfnissen von Wanderern und Radfahrern. Für Radfahrer wieg der Vorteil, während der Fahrt eine Ansage zu bekommen sicherlich schwerer als für Wanderer.

Betrachte es wie eine Note oder fixme. Vielleicht dann.

Ich weiß ja jetzt nicht ob ihr wisst, um wieviele Wegweiser es geht und wie die Dichte ist…

https://overpass-turbo.eu/s/18fm

gelb: unbestimmte Wegweiser
grün: Wegweiser mit Radweg- und Wanderweg-Infos
rot: reine Wanderwegweiser
schwarz: Radwegweiser
blau: Wegweiser für Bootsverkehr (hauptsächlich Spreewald).

Man sieht sehr schön die Erfassungslücken: westlicher, südwestlicher Rand des Ausschnitts , sowie nördlich und nordöstlicher Bereich…
Das sind sehr oft Bereiche, wo Wanderwege vorhanden, aber nicht erfasst sind, oder wo Knotenpunkte von Radknotenpunktnetzen noch nicht erfasst sind.

Narürlich mag das “nice to have” sein… eine systematische Erfassung meiner Ansicht nach nicht leistbar.

Sven

Muss ja auch nicht sein. Wie haben vieles in OSM, bei dem es nicht gelingt, es flächendeckend zu erfassen. Dort wo es aber erfasst ist, stellt es durchaus einen Mehrwert dar. Und wenn schon ein Wegweiser als Node erfasst ist, finde ich es besser, wenn mehr als ein “da steht ein Wegweiser” erfasst ist.

Das macht für mich Sinn.
Danke für die Erläuterungen. :roll_eyes: :sunglasses:

Für mich nicht. :roll_eyes: :frowning:

Bin nur Radfahrer. :sunglasses: