Ist eine Zielwegweisung eine Route im OSM-Sinne?

Zu lcn=yes gibt es auch eine andere Auffassung. Siehe z.B.
https://wiki.openstreetmap.org/wiki/Radverkehrsnetz_Ulm/Neu-Ulm
https://forum.openstreetmap.org/viewtopic.php?id=64437 #6

Gute Beispiele für den Missbrauch von Routen. Den Mappern mache ich das nicht zum Vorwurf, sie sahen nur keine Alternative. Ich kenne auch keine.

Dein Vorschlag zu „Relation:network“ klingt logisch, aber löst es unser Problem? Ich bin mir da unsicher. Ich versuch mal einen Lösungsweg zu beschreiben. Vielleicht ist er ohnehin in deinem Vorschlag enthalten. Von Anfang an:

Eine Route hat folgende Eigenschaften:

  1. ist durchgehend ausgeschildert bzw. markiert UND

  2. hat einen (Eigen-) Namen, Nummer, Symbol oder Zielbezeichner UND

  3. hat Anfang und Ende oder ist ein Rundkurs. Es ist kein Netzwerk!

Der Zielbezeichner ist der „Start – Ende“-Name bei zielwiederholter Wegweisung (Ausgangspost) bzw. in Knotenpunktnetzwerken.

Mir ist die UND-Bedingung zu den Bezeichnern wichtig, weil sie die Identifizierung vor Ort ermöglicht. Ein erheblicher Mehrwert. Der Bezeichner sollte auch unbedingt im Datensatz aufgenommen werden und nicht optional.

Du hast es ja schon geschrieben: Routen können ein Netzwerk bilden, eine Route kann aber kein Netzwerk sein. Explizit in den Kriterien hingeschrieben macht es aber einiges klarer.

Die Abschnitte zwischen den Knoten im Fahrradknotenpunktnetzwerk sind mit dieser Definition abgedeckt. Die Zusammenfassung in einer (weiteren) Relation hast du angesprochen.

Es bleibt noch der große Rest der Wege mit normaler Wegweisung und die der amorphen Netze, die – weil ohne Alternative – in die Routen gepresst wurden. Beispiele:

  • Radwegenetze in Städten mit normaler Wegweisung, ohne Routencharakter (Zürich, Ulm, Lübeck …)

  • Radwegenetze in Regionen mit normaler Wegweisung, ohne Routencharakter (NRW, SH …)

  • MTB Trails

Die unechten Routen könnte man „Tour“, „Itinerary“ oder was auch immer nennen. Die unechte Route hätte folgende Eigenschaften:

  • Ist beschildert

  • ist eine Wegstrecke oder ein Netz

Deckt sich das mit deiner Vorstellung?

Sie verwenden ‘lcn=yes’ am Weg als Alterative zur Fahrradrouten-Relation und beschreiben das als gleichwertig. Ist es aber nicht. ‘lcn=yes’ am Weg lässt offen, was für ein Teil des Fahrradnetzwerkes der Weg ist.

Es kann ein Teil einer Fahrradroute sein im Sinne von DE:Fahrradroutentagging.

Es kann aber auch einfach ein mit Wegweisern versehenes Netz ohne Fahrradroute drüber sein. Die Entsprechung als Relation wäre dann die von mir angesprochene Netzwerk-Relation (Relation:network)

Demnach ist ‘lcn=yes’ an den Wegen zwar unkonkreter, aber dadurch nicht falsch, selbst wenn über den Weg keine fahrradroute drüber läuft.

Wenn man konkreter sagen will, ob es eine Fahrradroute oder ein Fahrradnetzwerk ist, dass kommt man um die route bzw. network-Relation nicht herum.

Warum bist du unsicher? Es ist eine Lösung für den real existierenden Bedarf, das ausgeschilderte Radverkehrsnetz über Relationen abzubilden. Es bietet eine Alternative für den real existierenden Missbrauch der Route-Relationen.

Deine Abgrenzungsvorschläge im Wiki für Route-Relatonen finde ich auch gut. Dort sollten wir deutsich machen, was nur “network” ist.

Nur bei einem habe ich Bedenken:

Bei deiner Forderung nach durchgängigem Zielbezeichner sehe ich das von Pajopath geschilderte Problem, dass dies in der Praxis nicht ganz sauber durchgezogen wird/werden kann. Zwei fiktive (!) Beispiele, die mir dabei zusätzlich eingefallen sind:

  1. Eine regionale Route verläuft z. B. von Halle nach Leipzig. Auf den Wegweisern steht bis zum Stadtrand “Leipzig”. Ab dem Stadtrand steht z. B. “Rathaus”, denn "Leipzig wäre innerhalb der Stadt wenig hilfreich.

  2. In A-Stadt starten 3 Fahrradrouten nach B-Stadt, C-Stadt und D-Stadt. Anfangs verlaufen diese zusammen mit anderen Rouen auf dem gleichen Wegen. Da der Platz auf den Wegweisern begrenzt ist, wird anfangs nur “B” und “C” ausgeschildert, nicht jedoch D. Erst nachdem die Route nach B von dem gemeinsamen Weg abzweigt, erscheint auch “D” auf den Wegweisern. In der Gegenrichtung steht jedoch von D-Stadt bis A-Stadt auf den Wegweisern “A”

In beiden Fällen wechseln die Ziele auf den Wegweisern, einmal wird das Ziel konkretisiert, das andere mal ist kein Platz drauf. Beide Routen sind aber m.E. durchgängige Routen in dem Sinne von DE:Fahrradroutentagging.

Ich bin mir aber unsicher, was man tun sollte

  1. Forderung etwas weicher machen, z. B. ein “größtenteils durchgängigen” Zielbezeichner.

  2. konkrete Beispiele benennen, wann Zielbezeichner nicht durchgängig sein müssen

  3. die Definition nicht weiter konkretisieren oder weichmachen

a) hat das Risiko, dass dann wieder beliebige Netzwerk-teile in die Routen-Relationen geschrieben werden.
b) bläht das Wiki weiter auf, irgendwann liest/versteht das keiner mehr
c) provoziert Diskussionen und ggf auch Streit.

Ich habe es nicht als gleichwertig beschrieben, sondern sage, dass man die mit lcn=yes getaggten Wege einer Stadt oder eines Landkreises jederzeit auf einfache Weise in eine Relation überführen kann, wenn dies für sinnvoll und notwendig erachtet wird. Wenn dies jemand machen will, ist das ok für mich. Er sollte dann aber auch die weitere Pflege dieser Daten sicher stellen. Mir ist das Pflegen solcher Monsterrelationen zu aufwändig.

Ich habe mit “sie” die Webseiten gemeint, nicht dich :wink: .

Diese Riesen-Relationen finde ich auch gruselig, alleine die Ladezeit im Browser! Besser wäre es, die einzelnen Stränge als Teilnetz in einzelne Relationen zu taggen, so wie das beim Knotenpunktnetzwerk auch gemacht wird. In einer übergeorneten Netzwerk-Relation wird dann nur auf die Relationen der Teilnetze verwiesen. Das macht sie wesentlich schlanker.

Relationenen haben den Vorteil, dass man weitergehende Infomationen nur einmal an zentraler Stelle schreiben kann, das macht das Pflegen wesentlich einfacher. (Z.B. Infos zum Betreiber des Netzwerkes, des Namens und ein Link zu weiterführenden Informationen)

Wenn in einer Relation jeweils nur ein Strang enthalten ist, lässt sich die Vollständigkeit leichter überprüfen, diese Prüfung könnte man sogar automatisieren.

Auch lassen sich so Wege leichter mehreren Netzwerken und Routen zuordnen.

Nachteil ist, dass Relationen v.a. für Anfänger schwerer zu verstehen sind und deren Pflege in den Editoren nicht überall komfortabel ist.

Die riesigen Route-Relationen scheinen eine Spezialität aus NRW zu sein.

Ich habe eben gesehen, dass in Schlesweig-Holstein die Radverkehrsnetze tatsächlich schon als Relation ‘type=network’ mit ‘route=bicycle’ getaggt wurden, siehe DE:Radverkehrsnetz_Schleswig-Holstein#Kreise.

Auch die Bayern empfehlen network-Relationen, siehe Radverkehrsnetz_Bayern.

In Stuttgart dagegen hate man 2015 als “proof of concept” ausprobiert, wo jede Strecke zwischen den Wegweisern eine eigene Route-Relation werden sollte, siehe Stuttgart/Radroutennetzwerk. Ergebnis ist es eine Mischung aus Relationen und lcn=yes an den Wegen, gut anzusehen auf cycling.waymarkedtrails.org.

Mir ist unklar, ob die in Stuttgart als ‘ref’ und ‘lcn_ref’ angegebenen Routen-Nummern am OSM-Stammtisch definiert wurden. Wenn ja, wird das m. E. die Radfahrer draußen eher verwirren und der “on-the-ground”-Regel widersprechen.

Ulm empfiehlt das Taggen von lcn=yes an die Wege, schließt aber network-Relationen aber nicht aus, siehe Radverkehrsnetz_Ulm/Neu-Ulm.

Insofern ist die network-Relation für Fahrradnetzwerke eigentlich etabliert, so dass wir sie auch ins Wiki aufnehmen könnten. Nur das Netzwerkrelationen einen tag ‘route=bicycle’ erhalten ist m. E. falsch, wenn dann ‘network=bicycle’, besser jedoch ‘network=lcn/rcn/ncn/icn’.

Die Stuttgarter Routen-Relationen sind m. E. aber eher type=network, auch wenn Sie einen Beginn und Ende haben. Es sei denn, die Nummerrierung findet sich tatsächlich an den Wegweisern wieder. @ Robhubi, wie passt das zu deinem Vorschlag, die durchgehende Zielführung auf den Wegweisern als Kriterium für eine Route stärker hervorzuheben? Demnach würden solche Mini-Strecken Routen-Relationen sein und nicht Netzwerk-Relationen, ähnlcih von Knotenpunktnetzwerken.

Ulm empfiehlt nichts. Ebenso wie die anderen Wiki-Seiten, die du verlinkst, beschreibt die Seite das Tagging, auf das sich einige lokale Mapper in Ermangelung eines global eingeführten und dokumentierten Taggingschemas angesichts der örtlichen Situation geeinigt haben. Dort, wo sich aus der Beschilderung Punkt-zu-Punkt–Routen ablesen lassen, z.B. aufgrund eines durchgängig aufgeführten Ziels oder über eine Nummerierung, hat man sich für das Erfassen als Routen-Relationen entschieden. Dort, wo wie z.B. bei uns in Ulm/Alb-Donau keine Routen erkennbar sind und das Netz zu sehr verästelt ist, um es in Routen aufzudröseln, setzt man ein lcn/rcn=yes an die Wege.

Da beide Methoden von diversen Renderern und Routern ausgewertet werden, halte ich das für ein pragmatisches Vorgehen und sehe keinen Grund, daran etwas zu ändern. Hinzu kommt, dass die Radverkehrsnetze nahezu ausschließlich von Einzelmappern und kleinen lokalen Gruppen mit großem Aufwand erfasst und gepflegt werden. Denen Relationen aufzudrängen, wo es Tagging an den Wegen auch tut, ist kontraproduktiv, weil es zusätzlichen Aufwand ohne signifikanten Nutzen produziert.

Natürlich empfehlen die Wiki-Seiten Tagging-Schemas. Genau das ist das Ziel des Wikis, Orientierung beim Tagging zu geben.

Ich erkenne hier niemanden, der jemanden etwas aufdrängen möchte. Alles hat seine Vor- und Nachteile. Diese aufzulisten bedeutet nicht, jemanden etwas aufzudrängen!

In dieser Diskussion ging es bisher darum,

  1. dass die Wiki-Beschreibung von route-Relationen zwingend Nummer, Symbol oder Namen fordert. Die Intention des Ausgangsposts von Robhubi ist, ob die Formulierung nicht angepasst werden sollte, so dass eine konsistente Zielwegweisung auch ausreicht.

  2. wie hart die Forderung nach konsistenter Zielwegweisung sein muss, da mitunter die Zielbeschreibungen sich auf der Route ändern oder weggelassen werden (Post von Pajopath und von bus-mt).

  3. was genau ein Ziel ist (Post von Galbinus)

  4. ob die Taggingschemas statt in lokalen Seiten von diversen Akteuren (Ulm NRW Bayern) besser zentral dokumentiert werden sollten (lcn/rcn=yes und network-Relationen sind im deutschen Wiki gar nicht beschrieben)

  5. ob die Abgrenzung zwischen route-Relationen und network-Relationen klar genug beschrieben ist

  6. ob ein tag ‘route=bicycle’ an einer network-Relation sinnvoll ist

  7. wie üblich lcn=yes ist (Post von MalgiK und ghostrider44)

  8. ob Knotenpunktnetzwerke eine eigene Kategorie erhalten sollten, z.B. ‘network=kpn’ streckenkundler

  9. dass m. E. Netzwerke wie in NRW nicht in Route-Relationen gehören sondern in Network-Relation

  10. ob die ref-Nummern der Routen in Stuttgart tatsächlich existieren und wenn nein, ob deren Verwendung korrekt ist

Das sind sehr viele Fragen, die sich hier aufgetan haben.

Möchte mich zunächst noch auf den Ausgangspost konzentrieren …

Sehe kein Problem. Die Route „Halle – Leipzig“ geht bis zum Stadtrand Leipzig. Dort beginnt ev. eine neue Route mit Hauptziel Rathaus und wechselnden Unterzielen Stadtteil 1, Stadtteil 2 … Um auszudrücken, dass sie zusammengehören, kann man sie in einer Relation zusammenfassen.
Bei der Namensgebung würde ich elastisch sein. Ergänzungen aus dem Kontext heraus, können für Eindeutigkeit sorgen, sollten aber durch Klammern kenntlich gemacht werden. Beispiele:

  • für das Ziel: „Rathaus“ oder eindeutig „(Leipzig) Rathaus“

  • für den eindeutigen Zielbezeichner: „(Halle – Leipzig Stadtrand) – Rathaus“. Davon findet sich „Rathaus“ am eigenen Schild und „Halle“ beim benachbarten Schild für die Gegenrichtung. Das sollte für die Identifikation reichen.

Wenn die umgekehrte Fahrrichtung ähnlich ausgeschildert ist, dann gibt es am Ende 4 Relationen, die man, wie erwähnt, in einer weiteren Relation wieder zusammenfassen kann.

Du meinst so?

            (B)     (C)
             ║       ║
(A)=========(X)=====(Y)=====(D)

Lösungsvorschlag
Route A ↔ B: Relation(A-B)
Route A ↔ C: Relation(A-C)
Route A ← D: Relation (A-D)
Teil-Route1 von A → D: Relation(A-X) *)
Teil-Route2 von A → D: Relation(X-D)
Route A → D: Relation(Teil-Route1 + Teil-Route2 )
Route A ↔ D: Relation(Route A ← D + Route A → D )

*) Die Relation(A-X) bezieht sich auf die Route nach B-Stadt! Zielbezeichner: „A – B-Stadt (Teil bis Abzw.)“

Schaut vielleicht kompliziert aus, ist aber im Prinzip einfach:

  • bilde (Teil-)Routen genauso wie sie ausgeschildert sind. Die gesamte Route wird dabei u.U. in Teilstrecken und in vorwärts/rückwärts Richtung zerlegt

  • Die Teil-Routen in weiteren Relationen wieder zusammenfassen, analog zu EuroVelo-Routen.

Einverstanden?

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.