Ist eine Zielwegweisung eine Route im OSM-Sinne?

Ja, die Mini-Strecken würde ich auch als Routen-Relation sehen. Was nicht passt sind die Knotenpunkte. In dieser Routen-Relation findet sich bei den Knotenpunkt-Wegweisern die Knotenpunkte **nicht **als Ziel. Ich sehe keinen Grund, diese Wegweiser als Knotenpunkte, im Sinne von Fahrradknotenpunktnetzwerke , zu bezeichnen.

+1

In meinen Augen haben sich mir schon lange folgende “Rangstufen” ergeben:

1. einfache Radwege
2. Radwege mit ausgewiesener Zielwegweisung
3. Fahrradknotenpunktnetzwerke
4. Themenorientierte Radrouten.

Aufsteigende Zahl=aufsteigende Bedeutung

Während (1) und (4) in meinen Augen gundsätzlich gut representiert ist, sehe ich durchaus größere Defizite bei (2) und (3).

Zielwegweisungsnetze und Fahrradknotenpunktnetzwerke stellen meiner Ansicht nach etwas völlig Separates dar und sollten in den Erfassungen mit einem eigenen Schlüssel erfasst werden.

Fahrradknotenpunktnetzwerke werden derzeit üblicherweise derzeit mit network=rcn einigermaßen gleichmäßig erfasst. Für mich ist das aber suboptimal. Sie stellen für mich eine völlig eigene Gruppe dar, weswegen ich hierfür einen eigenen network-Key abtrennen würde: z.B. network=cnn (cnn=cyclenodenetwork)

Ähnlich sehe ich das bei den Zielwegweisungsnetzen. Diese sollten auch separiert werden: z.B. network=twn (targetwaynetwork)

Beide network-Keys sind fixe Ideen von mir und nicht angewendet.

Hintergund für mich ist, daß man Zielwegweisungsnetze und Fahrradknotenpunktnetzwerke nicht wirklich nach regional (rcn) oder lokal (lcn) abtrennen kann, je nach Betrachtungsweise sind sie das eine oder andere oder beides… Fahrradknotenpunktnetzwerke hingegen sind durch das zugrunde liegende nummerierte Knotenssystem in meinen Augen strenger zu betrachten, als Zielwegweisungsnetze, darum in meiner persönlichen Lichte die höhere Rangstufe.

Ich befürchte aber, daß das Kind für eine Umklassifizierung entsprechender Netze bereits in den Brunnen gefallen ist und eine in dieser Art angelehnte Umschlüsselung kaum noch möglich sein wird…

Sven

Missverständnis. Ich meine nicht, dass die Wegweiser nummeriert sind, sondern dass an den Wegweisern Nummern oder Namen hängen für die Strecke. Das sind meist kleine Einschubschildchen,so wie hier. Dann sind es eindeutig Routen, denn sie haben einen Namen, Nummer oder ein Symbol. Wenn sie das nicht haben, ist es m. E. im Regelfall nur Netzwerk, aber keine Route.

Die Abgrenzung zwischen (2) und (4) ist ja heute schon möglich. (2) wird in vielen Regionen über network-Relationen abgebildet (oder über lcn=yes an den Wegen). Das scheint gelebte Praxis. (4) wird laut Wiki über route-Relationen abgebildet. Ein Renderer kann also network-Relationen schwächer einfärben, dann sind heben sich die Routen a la (4) wieder deutlich ab. Wunderbar!

Wenn das so wäre, wäre die Abgrenzung allerdings wieder futsch. Dann können Renderer oder Routingalgorithmen (2) und (4) nicht mehr unterscheiden. Genau das wäre aber mein Anliegen. Deswegen finde ich das nicht gut, solche Netzwerkteile als route-Relation zu tagen.

Oder hast du eine Idee, wie Renderer Themenradtrouten a la (4) von ausgeschilderten Netzen a la (2) unterscheiden sollen, wenn beide als route-Relation getaggt werden?

Ich sehe schon, es ist sehr schwer das sauber abzugrenzen, ab wann sowas Route ist und wann nur Netzwerk, wenn man von der harten Forderung nach Symbol, Name oder Nummer abweicht.

Den Wunsch (2), (3) und (4) voneinander abzugrenzen, habe ich auch. Auch über ein Knotennetzwerk kann eine Themen-Radroute gelegt werden. Auch hier sollten Renderer die Möglichkeit bekommen, sie vom Knotennetzwerk zu unterscheiden.

Bei (2) sehe ich auch, dass es oft schwierig ist, zu entscheiden, ob Netze nun örtlich oder regional sind. Kurze Streckenteile des Netzes liegen innerhalb einer Kommune oder eines Kreises, längere aber auch landkreisübergreifend. Einzige sinnvolle Grenzen in Deutschland wären i.d.R die Ländergrenzen, weil die Fahrradwegweisungestandards hierzulande länderspezifisch standardisiert sind. Es sei denn, es gibt begrenzte kleinere Netzwerke mit abweichender Beschilderung.

Wenn die Grenzen des Netzes draußen eindeutig erkennbar sind, würde ich bei (2) die network-Relation mit dem Tag ‘network=rcn/lcn’ versehen. Wenn nicht, so wird es bisher oft mit ‘network=lcn’ versehen. M. E. wäre besser ein allgemeinderes Tag ‘network=bicycle’.

Bei (3) sehe ich das anders. Knotenpunktnetzwerke haben einen Betreiber. Die Regionale Ausdenhnung ist begrenzt und i.d.R. für den Radfahrer sowohl in Karten auch draußen erkennbar. Diese Netzwerke orientieren sich nicht zwangsläufig an den Kreisgrenzen, sondern häufig an Tourismus-Regionen, z. B. in Brandenburg. Die Netze haben meist auch ein eigenen Namen und werden gesondert vermarktet, ähnlich von Themenrouten, siehe z. B. dieprignitz.de.

Hier macht network=lcn/rcn durchaus Sinn, jenachdem, wie weit das Knotenpunktnetzwerk geht.

Um das Knotenpunktentzwerk dennoch von (2) und (4) abzuheben, bräuchte es einen neuen Tag.

Ich würde dafür plädieren, (2) und (3) als network-Relation zu taggen, wobei (3) einen neben ‘network=rcn/lcn’ noch ein ‘nodenetwork=yes’ oder so bekommt. Route-Relationen wären dann ausschließlich für (4) vorgesehen.

Dann müsste man allerdings alle bestehenden Knotenpunktnetzwerke umtaggen, die einzelnen Verbindungen innerhalb des Netzwerkes sind heute alle route-Relationen.

Will man das nicht, definiert man (3) als eine Untermenge von (4) und belässt es bei den route-Relationen. Auch hier würde wieder ein zusätzliches ‘nodenetwork=yes’ den Renderern helfen, Knotenpunktnetzerke von (4) zu unterscheiden.

Ich halte network=lcn|rcn für reine Zielwegweisungsnetze und Knotenpunktnetze für nicht erforderlich. Was soll das bringen? Anhand Knotenpunktnetze kann man das recht gut erklären, warum ich das so sehe… Ich kann mir bei einem Knotenpunktnetz eine kleine Route z.B. über 3 oder 4 Knoten zusammenbauen, die dann in der Gesamtheit den Charakter von lcn hätte. Ich kann aber auch z.B. über 10-12 Knoten gehen und käme dann auf eine Route, die eher den Charakter von rcn hätte…
Das Argument von Nutzern, daß eine Route ausschließlich zwischen zwei Knoten (eigentlich) lcn wäre, kann ich verstehen, bezogen auf ein Gesamtknotennetz aber passt das dann aber irdendwie nicht mehr. Bei Zielwegweisernetzen ist das auch so. Daher Verzicht auf Unterscheidung von lcn und rcn. Eine Erfassung und Darstellung “hier ist ein Knotenpunktnetzwerk, hier schließt sich ein Zielwegweisungsnetz, ect…” reicht aus.

Ich bin mir aber auch im Klaren, daß das dann eine größere Sache wäre, die ggf. ein eigenes Proposal und in dem Fall auch einen Autoedit nachsich ziehen würde, nebst der Notwendigkeit der Anspassungen div. Auswertetools, Karten… Ich sehe mich aber nicht in der Lage das anzuschieben/umzusetzen.

Sven

Nun dann ist es bei Radrouten genauso. Dort kann ich auch nur ein Teilstück befahren, dann ist eine Deutschlandroute für micht nur lokal. Genauso kann ich mir aus mehreren regionalen Routen eine Tour zusammenstellen, die über mehrere Länder geht.

Interessante Frage, was hilft das network Tag dem Nutzer?

Network soll m. E. nur etwas über die Größe des Netztwerkes aussagen. Vielleicht auch über die zuständige Administrationsebene. Davon kann der Nutzer sich womöglich ableiten, wie bedeutend und bekannt dieses Netzwerk ist. Ist vermutlich für die meisten eher begrenzt interessant. Eher für die Renderer, die können verschiedene Netzwerke unterschiedlich darstellen, so dass sich die längeren Routen von kürzeren abheben. Das hilft wenn man annimmt, dass die längeren Routen häufiger durchgehend befahren werden.

Du hats schon Recht, Bei 2 und 3 nimmt lcn/rcn an Bedeutung ab. Vielleicht wäre ein eigener Netzwerkbegriff auch gut. Aber ich glaube auch, dass das Arbeit macht und das der Leidensdruck hier nicht so groß ist, dass das jemand durchzieht.

Naja, Themenradrouten sind zunächst einmal so angelegt, daß man sie in Gänze abfahren kann (auch wenn es mehrere Tage dauert). Natürlich kann man auch nur Teilstücke befahren… Hier ist eine Unterscheidung nach lcn, rcn, ect. auf jeden Fall Sinnvoll.
Ich sehe aber keinen Sinn, daß auch bei Zielwegweisungen und Knotennetzen zu machen. Diese beiden stellen für mich nicht nach lcn|rcn unterscheidbare ausgeschilderte Basis-Radnetze dar, über die Themenorientierte Radrouten geführt werden können, nicht müssen.

Sven

Möglich und empfehlenswert müssen nicht deckungsgleich sein. In Stuttgart scheint es eine zielwiederholte Wegweisung zu geben. Aus meiner Sicht können daher Fahrstrecken – isoliert betrachtet – als Routen interpretiert werden. Als Ganzes gesehen ist es sicher eher ein Netzwerk mit (guter) zielorientierter Wegweisung, als ein Netzwerk aus Routen.

Falls es doch jemand versuchen sollte, das Netzwerk aus einzelnen Routen nachzubilden, er wird ziemlich sicher scheitern – ich hab‘ es auch schon mal erfolglos probiert. Es ist sehr viel Arbeit … Gelingt es, ohne die Regeln zu verbiegen, wäre es aber m.E. ok.

Stimme also mit dir überein, type-network ist für Netzwerke mit zielorientierter Wegweisung die empfehlenswerte, arbeitssparende und erfolgssichere Variante.

Diese Route ist gleichwertig einer Themenroute. Das auch im Tagging beschreiben zu können, war meine Intention.

Meine Rangfolge:

1. einfache Radwege (highway mit bicycle=designated)

2. Radwegenetz mit zielorientierter Wegweisung (type=network)

3. Fahrradknotenpunktnetzwerke (type=route)

4. Radrouten mit Eigenname, Symbol, Nummer oder Zielbezeichner (type=route)

Falls du bei der Formulierung „… oder Zielbezeichner“ Missverständnisse befürchtest, könnte man es auch so ausdrücken:

Routen mit Eigenname*), Symbol oder Nummer
*) In Sonderfällen kann der Eigenname auch ein Zielbezeichner sein. Bsp.: „Rathaus - Kulkwitzer See“

Ist diese Formulierung akzeptabel?

Das Umtaggen der Knotenpunktnetzwerke möchte ich nicht befürworten. Die Ergänzung mit ‘nodenetwork=yes’ gefällt mir hingegen gut.

Hierauf habe ich noch nicht geantwortet:

Ja das meinte ich

Die Idee habe ich verstanden. Allerdings glaube ich nicht, dass sich richtungsspezifische Radrouten-Relationen durchsetzen werden bzw. dass die Mehrheit versteht, warum da jemand Radrouten in mehrere Teilen zerlegt hat. Ich glaube die meisten werden A<=> D als eine Route mappen, fertig.

Vielleicht sollten wir das Wiki nicht mit diesen Sonderfällen überstrapazieren sondern den Mappern die Freiheit lassen, das so zu machen, wie es zu den örtlichen Gegebenheiten passt. Mit ein paar Weichmacherwörtern (“in der Regel”, “weitgehend”, “möglichst”) kann man ja zeigen, dass man da auch selber entscheiden sollte.

D’accord. Was hältst du davon: Die abschnittsweise Übergabe der Zielführung an eine andere Route kann, der Einfachheit halber, wie eine durchgehende Zielführung betrachtet werden.

Ich habe das Gefühl, dass die Themen “zielwiederholte Wegweisung“ und „ausgeschilderte, strukturlose Radwegenetze“ weitgehend diskutiert sind. Sollen wir darangehen, das Wiki zu erweitern? Ich helfe gerne mit.

Sagt bescheid wenn ihr fertig seit, dann lese ich mir das durch und versuche mal mein gebiet anhand der Beschreibung zu bauen

Mach ich gerne, werde dazu mal eine temporäre Seite einrichten auf der wir rumprobieren können, ohne dass alle Mitwirkenden mit Änderungsnachrichten genervt werden.

Die erste Seite habe ich eingerichtet und einen Entwurf niedergeschrieben. Bitte dort weiterdiskutieren:
wiki/User:JochenB/DE:bicycle/Fahrradnetzwerke_kartieren

Ich hole mal dieses Thema aufgrund von https://www.openstreetmap.org/changeset/95276593 hoch. Sind die Vorschläge unter https://wiki.openstreetmap.org/wiki/User:JochenB/DE:bicycle/Fahrradnetze_kartieren mittlerweile “offiziell” und sollen umgesetzt werden? Ich habe User-Wikiseiten immer nur als “in Arbeit” betrachtet und nicht als “gesetzt”.

Der Bedarf für diese Lösung wurde oben diskutiert, die Wiki-Entwürfe jedoch noch nicht.

Ich habe die Vorschläge aus der Diskussion oben in die Wiki-Entwürfe eingearbeitet, die sind eigentlich fertig. Vielen Dank dabei an RobHubi, der kritisch gegengelesen und ergänzt hat!

Wegen meiner Arbeitslast u. a. aufgrund Covid habe ich die Ergänzungen hier aber noch nicht zur Diskussion gestellt, dann machen wir das jetzt mal.

Hintergrund:

Es gibt einen Bedarf, das mit Wegweisung versehene Radverkehrsnetz in OSM zu kartieren und es dabei von Fahrradrouten zu unterscheiden, siehe Diskussion oben.

Es ist gelebte Praxis, dass für ausgeschilderte Radverkehrsnetze network-Relationen verwendet werden, wenn die Kriterien von Route-Relationen nicht erfüllt sind (kein Name, kein Symbol, keine Nummer oder wechselnde Ziele auf den Wegweisern).

Die Art und Weise, wie diese network-Relationen getaggt wurden ist teilweise unzufriedenstellend - es entstanden riesige Sammelrelationen.

Vorgeschlagende Ergänzungen

Ziel der Wiki-Ergänzung ist, die gelebte Praxis mit network-Relationen in handhabbare Bahnen zu leiten. Dabei soll bewusst keine Präferenz auf die Verwendung von network-Relationen oder das Taggen von 'network='* an den Kanten gegeben werden. Beides hat Vor- und Nachteile, ist regional unterschiedlich verbreitet und am Ende Ansichtssache.

Dazu habe ich die englische Seite zur Network-Relation übersetzt und einen entsprechenden Passus “Radverkehrsnetze kartieren” ergänzt. Demnach sollte eine Netzwerkrelation möglichst auf eine Wegeverbindung im Radverkehrsnetz beschränkt sein, ähnlich der Kartierung von Knotenpunktnetzwerken.

Hier der Vorschlag:User:JochenB/DE:Relation:network

Um den Unterschied zwischen Infrastruktur (*highway=**), den mit Wegweisung versehenen Radverkehrsnetz (network-Relationen) und den ausgeschilderten Fahrradrouten (route-Relationen) zu erklären, habe ich eine Überarbeitung von DE:Fahrradroutentagging vorgeschlagen in Form einer Zweiteilung:

• Vorschlag DE:Bicycle/Radverkehrsnetze_kartieren (v. a. ‘network’-Relation)

• Vorschlag DE:Bicycle/Fahrradrouten_kartieren (v. a. ‘route’-Relation; als Überarbeitung von DE:Fahrradroutentagging)

Ich habe die Chance genutzt, die Ursprungsseite zu überarbeiten. Die Seiten beschreiben nun nur noch das grundsätzliche Vorgehen und die Abgrenzungen. Für das genaue Taggingschema wird auf die Seiten der entsprechenden Tags verweisen. Das vermeidet Redundanzen - und damit Widersprüchlichkeiten - und macht die Seiten kompakter. Zudem habe ich sie mit Beispielen illustriert.

Die Verwendung des network-Tags an den Kanten als Alternative zu network-Relationen wird dort gleichwertig beschrieben.

Die in der Diskussion oben von RuHobi angebrachten Kriterien einer durchgehenden Zielwegweisung findet sich ebenso wieder wie Hinweise aus der Diskussion z. B. zum Umgang mit fehlenden Wegweisern.

Also, wie steht ihr zu dieser Überarbeitung? Ist etwas missverständlich, unlogisch nicht gut bzw. findet ihr Eure Beiträge zur Diskussion in den Änderungen wieder?

from= (optional) Knotenpunktnummer am Start, z.B. 27
to= (optional) Knotenpunktnummer am Ende, z.B. 86 **

Der Zweck dieser Tags erschließt sich mir bei Wander- und Radrouten überhaupt nicht, weil man so gut wie jede Route in jeder beliebigen Richtung begehen oder befahren kann. Bisher sind mir noch keine Einwegrouten zu diesen Routenarten untergekommen. Ausnahmen sind vielleicht Themenrouten wie Lehrpfade usw. wo die Informations- oder Lehrinhalte aufeinander aufbauen.

Du warst scheinbar auf der alten Fahrradroutentagging-Seite. Auf der überarbeiteten Seite werden die einzeln Tags nicht mehr erklärt sondern auf die entsprechenden Tag-Seiten verwiesen, in diesem Fall auf DE:Tag:route=bicycle. Dort werden from=* und to=* nicht beschrieben, sollte in deinem Sinne sein .

Ein gutes Beispiel, warum es sinnvoll ist, die Tags selber nur an einer Stelle zu erklären.

Unabhängig davon denke ich nicht, dass 'from=‘* und 'to=’* heißt, dass die Route ‘oneway=yes’ ist. Somit ist es Geschmackssache, in welche Richtung man den from und to angibt. Es sei denn, in dem offiziellen Namen ist eine Reihenfolge zu erkennen, wie z. B. im Radweg “Berlin - Kopenhagen”. Die Angabe der beiden Endpunkte fand ich als Anwender schon hilfreich, z.B. auf waymarkedtrails.org.

Das sehe ich ja auch so. Da sie ja im ref (z.B mit 1-2, optional noch als name inclusive Ort) angegeben und damit auch bei waymarkedtrails/Radkarte und anderen Karten gerendert werden ist diese Information ja vorhanden. Wozu also noch from/to?

gruß

Im Vorschlag sind from und to nicht mehr enthalten. Mir ist entgangen, dass das nur auf der einen Seite dokumentiert war.

Allerdings wäre das ein Ding, was man von der alten Seite hinüber nach DE:Tag:route=bicycle “retten” könnte. Allerdings weniger bei der Sonderanwendung “Knotenpunktnetzwerk” sondern vielmehr für Fahrradrouten allgemein.

Dort halte ich die Angaben insbesondere dann für hilfreich, wenn Start und Ende im Namen nicht enthalten sind, wie z. B. hier bei der Radroute “Sächsische Mittelgebirgskette”: https://cycling.waymarkedtrails.org/#route?id=4193229.

Darüber hinaus liegt der Mehrwert darin, dass die Information strukturiert und damit maschinenlesbar vorliegt. Das aus dem Namen abzuleiten würde bedeuten, dass alle das gleiche Namensschema verwenden müssen. Das wird schon daran scheitern, dass Start und Ziel in vielen Namen gar nicht vorkommen, siehe Beispiel von oben.

Wäre das also OK, das from und to in den Abschnitt “Fahrradrouten kartieren” von DE:Tag:route=bicycle aufzunehmen?