DE talk:Bicycle/Radverkehrsnetze kartieren
Jump to navigation
Jump to search
Auslöser für das Erstellen der Seite war eine Diskussion im Forum: https://forum.openstreetmap.org/viewtopic.php?id=66366&p=2
Allgemeines
Die Strukturierung gefällt mir sehr gut. Die „Quick-Links“ vor dem Inhaltsverzeichnis sind auch in der finalen Fassung eine gute Idee.
Einordnung
Die generischen Typen würde ich so beschreiben (Änderungen kursiv):
- Fahrradinfrastruktur (Straßen, Radfahrstreifen, Radwege, Feldwege u. ä.)
- ausgeschildertem Fahrradnetzwerk (Wegenetz mit Fahrradwegweisern)
- ausgewiesene Fahrradrouten (von A nach B- Wege mit Symbol, Nummer oder Name)
Der letzte Satz in diesem Abschnitt „Ausgewiesene Fahrradrouten sind immer Teil eines oder mehrerer Fahrradnetzwerke.“ ist mir unklar. Worauf willst du hinaus? Ich hätte eher einen Satz erwartet wie: „Die Routen eines Betreibers können ein Netz bilden“. Wenn die Routen keine Verbindung haben, sind sie kein Netz. Unterscheidest du zwischen Netz und Netzwerk?
--RobHubi, 15 June 2019
- zu "(Wegenetz mit Fahrradwegweisern)":
- wird übernommen.
- zu "(von A nach B- Wege mit Symbol, Nummer oder Name)":
- A nach B muss nicht sein, kann ja uch ein Rundkurs sein. Zudem kommen A nach B auch außerhalb der Radrouten vor. Irgendwas wird ja immer auf den Wegweisern stehen. Daher finde ich, dass das zur schnellen Abgrenzung eher nicht so richtig hilft.
- zu „Ausgewiesene Fahrradrouten sind immer Teil eines oder mehrerer Fahrradnetzwerke.“:
- Ich meinte damit, dass in den Routen ja auch immer eine Netzwerkangabe steht und diese damit automatisch Teil des angegbenen Netzwerkes sind. Zudem gehen z. B. Deutschland-Routen über mehrere lcn oder rcn und sind damit Teil von mehreren Netzwerken.
- Aber wenn das mehr verwirrt als hilft dann sollten wir das lieber weglassen, oder?
- zu "Ich hätte eher einen Satz erwartet wie: „Die Routen eines Betreibers können ein Netz bilden“. Wenn die Routen keine Verbindung haben, sind sie kein Netz.":
- Stimmt, das ist nur in der Einleitung kurz erwähnt, das fehlt noch.
- zu "Unterscheidest du zwischen Netz und Netzwerk?":
- Nein
- zu "(von A nach B- Wege mit Symbol, Nummer oder Name)":
- A nach B muss nicht sein, kann ja uch ein Rundkurs sein. Zudem kommen A nach B auch außerhalb der Radrouten vor. Irgendwas wird ja immer auf den Wegweisern stehen. Daher finde ich, dass das zur schnellen Abgrenzung eher nicht so richtig hilft.
- zu "(von A nach B- Wege mit Symbol, Nummer oder Name)":
- Hm, ich wollte auf das Pendant zum Netz hinaus. Was hältst du davon (Route durch Wegelinie ersetzt):
- 3. ausgewiesene Fahrradrouten (Wegelinie mit Symbol, Nummer oder Name)
- Hm, ich wollte auf das Pendant zum Netz hinaus. Was hältst du davon (Route durch Wegelinie ersetzt):
Welche Wege gehören zu einem Fahrradnetzwerk
Zu „Alle Wege mit einer durchgängigen Fahrradwegweisung gehören zum Fahrradnetzwerk. Durchgängig bedeutet, dass an Kreuzungen und Abzweigungen per Fahrradwegweiser erkennbar ist, wie die Radverbindung fortgeführt wird.“
- Das ist mir zu streng formuliert. Der Abstand zu einem Netz aus Routen wäre nur mehr klein. Meine Vorstellung sieht so aus:
- Ein ausgeschildertes Netz ist kein Routennetz. Die Beschilderung ist nicht durchgängig, sondern überwiegend zweifelsfrei. Bestätigungszeichen und Vorwegweiser sind eher unüblich.
- Es sollen nur Wege zwischen 2 Wegweisern aufgenommen werden. Der Abstand zwischen den Wegweisern sollte so klein sein, dass ein Ankommen für durchschnittliche Radfahrer wahrscheinlich ist.
- Zusätzlich zu den Wegen, sollen auch die Wegweiser, inkl. aller Zielangaben, kartiert werden. Erst damit wird das Netz verifizierbar. Die kartierten Wegweiser des Netzes sind quasi das Gegengewicht zur durchgehenden Ausschilderung von Routen, deren Wegweiser i.a. nicht kartiert werden.
- Du machst den Unterschied zwischen Netzwerk und Radroute an der Qualität der Wegweisung fest. Das klingt für mich ein wenig so, als sollten network-Relationen die bad bank für schlechte Fahrradrouten sein. Wenn dem so ist, dann verstehen wir unter einem 'Fahrradnetzwerk' etwas völlig Unterschiedliches.
- Ich finde nicht, dass es eine Eigenschaft eines Fahrradnetzwerks sein sollte, dass die Wegweisung lückenhafter sein darf. Unzureichend ausgeschilderete Netzverbindungen helfen den Nutzern von OSM genausowenig wie unzureichend ausgeschilderte Radrouten, man verfährt sich einfach. Warum sollte ein Radfahrer, der nur von A nach B will eine schlechtere Wegweisung bekommen gegenüber einem Radfahrer, der das Wegenetz nutzt, um z. B. auf der Spur der Krabat-Sage zu fahren (Krabat-Radweg)?
- Ich habe mein Verständnis von fahrradnetzwerk aus der ersten sächsischen Radverkehrskonzeption (viele andere Konzeptionen sind analog, vermutlich basierend auf den FSGV-Hinweisen). Dort ist beschrieben, dass ein gut ausgeschildertes Netzwerk von Wegen das Radverkehrsnetz bilden soll ("SachsenNetz Rad", network-Relationen). Die Radrouten werden dort drüber gelegt, indem Einschübe mit Routen-Symbolen unten in die Wegweiser gesteckt werden (route-Relationen). Der Unterschied zwischen Netzwerkverbindung und Route ergibt sich daraus, dass eine Route Name, Nummer oder Symbol hat (wobei in Ausnahmefällen auch eine in beiden Richtungen durchgehende Zielangabe den Namen bilden kann). Die Qualitätsansprüche an Wege ohne Radrouten und Wege mit Radrouten sind dabei die gleichen, es gibt eher Unterschied innerhalb der Radrouten (Premium-Radrouten und sonstigen Radrouten/Netzverbindungen).
- In der sä. RVK heißt es z.B.:
- Das SachsenNetz Rad ist ein Landesnetz für den Radtourismus. Unter der Dachmarke SachsenNetz Rad (SNR) werden Radfernwege, Regionale Hauptradrouten und sonstige Strecken zusammengefasst:
- Radfernwege (SNR I) sind benannte Routen für den Radtourismus mit landesweiter Bedeutung,
- Regionale Hauptradrouten (SNR II) haben regionale Bedeutung und tragen einen Namen.(route-relationen)
- Sonstige Strecken ergänzen die Radfernwege und Regionalen Hauptradrouten zu einem geschlossenen Netz, dienen der Erschließung wichtiger touristischer Schwerpunkte mit überregionaler und landesweiter Bedeutung sowie der Anbindung an Bahnhöfe und sonstige funktionelle Elemente des Radtourismus (network-relationen)
- Das SachsenNetz Rad ist ein Landesnetz für den Radtourismus. Unter der Dachmarke SachsenNetz Rad (SNR) werden Radfernwege, Regionale Hauptradrouten und sonstige Strecken zusammengefasst:
- In der sä. RVK heißt es z.B.:
- In den Schulungen zu Radverkehrskonzeption wurde davon ausgegangen, dass sich das Wegenetz nur selten ändert, während die Tourismusverbände immer wieder neue thematische Fahrradrouten kreieren und vermarkten. Dazu müssen sie nur die kleinen Symbolschildchen beschaffen und einschieben.
- Auch die Mapper in Schleswig-Holstein scheinen die network-Relation eher als "Netz mit Wegweisung" verstanden zu haben als ein "Netz mit geringerer Qualität", denn sie haben alle Wege mit Wegweisung in den (teils sehr großen) Relationen erfasst.
- "Nicht durchgängig" und "überweigend zweifelsfrei" widerspricht sich. Durchgängig und Zweifelsfrei sind m. E. das Gleiche. Zweifelsfrei und Durchgängig wird es, wenn an jedem Knoten oder Abzweig Zwischen- oder Haupt-Wegweiser stehen.
- Der Luxus von Vorwegweiser ist keine spezifische Eigenschaft von Radrouten. Es ist eine Eigenschaft eines hochwertigen Radverkehrsnetzes. Die meisten Radrouten die ich kenne, haben relativ selten Vorwegweiser, insbesondere lokale (lcn) (Mitteldeutschland).
- In der Realität ist die Ausschilderung der Radwege von sehr unterschiedlicher Qualität. Insbesondere die zielorientierte Wegweisung weist eine große Bandbreite auf: von zielwiederholter Wegweisung, mit Routenqualität bis zu vereinzelt herumstehende Wegweiser, die man nur als Wegweiser taggen kann.
- Dazwischen gibt es m.E. eine Gruppe von Wegweisungen die keine Routenqualität haben, aber dennoch ein Wegenetz kennzeichnen. Die Ausschilderung kann sparsam sein, nach der Devise „bleib auf deiner Wegeklasse“ und „immer geradeaus“ braucht keine Ausschilderung. Die Zielauswahl auf der Ausschilderung mag für Alltagsradler ausgerichtet sein und weniger für ortsunkundige Touristen.
- Der User:Juwe beschreibt das für Lübeck mit folgenden Worten: „Die Verbindungen wurde in der Planungsphase mit Nummern versehen, um Start- und Endpunkte ergänzt und als Alltags- oder Freizeitroute klassifiziert. Die Nummern der Routen und ihre Start- und Endpunkte sind weder auf Wegweisern, noch auf Hinweisschildern an diesen Punkten erkennbar.“ Beispiel für einen Wegweiser. Die Wege wurden als Routen in OSM aufgenommen.
- Mein Use Case ist Zürich: Analyse der Velowegweisungen in Zürich Stadt. Die Situation in Zürich ist fast identisch mit der Situation in Lübeck.
- Ich würde die Qualität dieser Wegweisungen nicht unbedingt als schlecht bezeichnen, sondern eher als „für Alltagsradler ausreichend“ einstufen.
- Einige (viele?) OSM-Mapper finden dennoch, dass diese Radwegenetze es wert sind, in die OSM-Datenbank aufgenommen zu werden. Ich auch. Mangels sichtbarer Alternativen werden dazu oft Routen-Relationen missbraucht.
- Um den Missbrauch von Routen zu verhindern brauchen wir eine Alternative. Die Relation Network scheint mir eine Möglichkeit zu bieten. Aber nicht als Bad Bank, sondern als Möglichkeit die „grundsätzliche Qualität“ der Ausschilderungsarten darzustellen. Meine Rangfolge:
- Routennetz
- Knotenpunktnetz
- zielorientierte Wegweisung mit kontinuierlicher Zielwiederholung
- zielorientierte Wegweisung ohne kontinuierlicher Zielwiederholung
- Für 1.) und 2.) gibt es bereits Lösungen, die Darstellung in der Relation Network sollten wir aber mitbedenken.
- Ich habe es verstanden und habe es auch ein wenig weicher formuliert. Die Worte sind so gewählt, dass Interpretationsspielraum bleibt ("relevant", "z B.", "große Lücken"). Tatsächlich ist die Wegweisung außerhalb der großen Radrouten oft sparsamer und lückenhafter.
- Allerdings die Art und Qualität der Zielweisung nicht zwingend mit der von dir beschriebenen Ebenen verbunden. Es gibt ebenso sehr gut ausgeschilderte Verbindungen außerhalb der markierten Routen. Umgekehrt entsprechen viele Radrouten nichtmal dem Kriterium, dass du an die sonstigen Netzverbindngen stellst.
- Hier wäre es m.E. sinnvoller, die Qualität der Wegweisung als extra Schlüssel zu vermerken, ähnlich den Schlüsseln trail_visibility oder smoothness bei higway=path.
- Mir wäre es wichtig, dass die echten Lücken in den Verbindungen sichtbar bleiben. Wenn ich mir eine solche Route in OSM aussuche möchte ich darauf vorbereitet sein, dass ich in den Lücken selber navigieren muss. Hab das so reingeschrieben. Passt das aus Deiner Sicht so?
- Die Idee, in den Lücken nur die Wegweiser zu taggen, habe ich mit aufgenommen
- Zu "Allerdings die Art und Qualität der Zielweisung nicht zwingend mit der von dir beschriebenen Ebenen verbunden"
- Verstehe, kann man so sehen. Du ziehst offenbar eine einzige Ausprägung vor – die zielwiederholte Wegweisung – und gibst mit der weichen Formulierung Spielraum für andere Ausprägungen und Qualitäten.
- Ich fürchte, dass dies viele Diskussionen auslösen kann.
- Die möglichen Ausprägungen – ich meine nicht die Lücken – sollten wir explizit ansprechen:
- moderne Fahrradwegweisung
- traditionelle Fahrradwegweisung
- Die moderne Fahrradwegweisung hast du beschrieben. Aus meiner Sicht hat sie einen betonten Zielführungsanspruch, ähnlich den Routen.
- Die traditionelle Fahrradwegweisung in einem Netz hat keine Ähnlichkeit mit Routen. Der Anspruch ist Orientierung zu geben. Man merkt das an der Zielauswahl bei den Knoten, sie haben einen individuellen Charakter und sind nicht durchgehend aufeinander abgestimmt.
- Beispiele für traditionelle Fahrradwegweisung:
- das Fernziel wird nicht festgehalten, einmal wird das nähere, dann wieder das fernere Fernziel angegeben
- Fernziele und Nahziele sind nicht getrennt und werden abwechselnd genannt
- die Zielauswahl ist individuell. Für das Ziel im Norden: die vom W kommen sehen ein Nahziel, die vom O kommen sehen ein Fernziel
- Asymmetrie der Ziele in Vorwärts- Rückwärtsrichtung
- Willst du ein Netz mit traditioneller Wegweisung ausschließen oder einschließen? Wenn einschließen: mit oder ohne besonderen Kennzeichnung?
- Ich wollte es nicht auf die moderne Wegweisung beschränken. Wenn das so rüberkommt, muss hier noch etwas ergänzt werden.
- Ich habe keine Beispiele älterer oder abweichender Wegweisungen gebracht, weil sich regional teils extrem voneinander unterscheiden. Mir ging es darum überhaupt zu erklären, was eine Wegweisung ist und eben die schön greifbare Geschichte mit den Routeneinschüben.
- Ich denke wir sollte nur erwähnen, dass es davon zahlreiche abweichende Wegweisungsarten gibt. Solange klar erkennbar ist, dass sie vorrangig Radfahrer adressieren, sind sie Teil des Fahrradnetzwerkes. Hab es wie folgend formuliert, passt das so?
- Daneben gibt es andere, teils ältere Fahrradwegweisertypen, die sich regional unterscheiden. Die damit ausgeschilderten Verbidnungen gehören ebenso zum Fahrradnetzwerk, wenn die oben genannten Bedingungen erfüllt sind.
- Ich glaube weiche Formulierngen müssen mitunter sein, die Seite soll ja übliche und sinnvolle abweichedne Tagging-Schema nicht auschließen. Wenn die Formulierungen aber zu Missverständnissen führen, muss da nachgebessert werden.
- Ich denke die Art der Wegweisung ist für die Frage, ob der Weg Teil des Fahrradnetzes ist keine wichtige Rollle spielt. Auch ist das für den praktischen Nutzer (Radfahrer) eher wenig von Belang. Mitunter wird mit einem Schlag eine alte Wegweisung durch eine neue ersetzt, an den Wegen und der Dichte der Wegweiser ändert sich damit erstmal nichts.
- Meine Wahrnehmung ist, das der Übergang von Network (Schleswig-Holstein) zur Route-Relation (Stuttgart) fließend ist. So wie es jetzt hier beschrieben ist (verbunden mit einer bez. "durchgängigem Ziel" angepassten route-Relations-Seite) sollte es einen guten Anhaltspunkt geben, wo besser route- oder network-Relationen genommen werden.
- Wenn man die Art der Wegeisung taggen möchte, sollte das m. E. an den Wegweiser geschrieben werden. Es kommt mitunter ja auch vor, dass auf einer Route oder Netzwerkverbindung die Art der Wegweisung wechselt, z.B. an einer Gemeindegrenze.
- Ich kenne aber kein passendes Tag "wegweisungstype". Mit einem solchen Tag könnte ein Datennutzer die Inhalte von Wegweisern so darstellen, wie sie draußen auch zu finden sind, z.B. in einer bebilderten Wegbeschreibung eines Routing-Programms.
Zu „Moderne Fahrradwegweisung besteht in Deutschland …“
- Der Vollständigkeit halber müsste auch noch die Schweiz und Österreich hinzugefügt werden. --RobHubi (talk) 20:58, 16 June 2019 (UTC)
- Die Wegweisung macht den Unterschied zwischen Radweg und Fahrradnetzwerk aus, ist als das wesentliche Merkmal des Fahrradnetzwerkes.
- Es gibt (vermutlich nicht radfahrende) Mapper, die sehen in blauen Radwegschildern oder in weißen Fahrradmarkierungen Radwegweiser ("Weist den Radfahrer auf den Radweg"). Demnach wäre jeder straßenbegleitende Radweg gleich Radverkehrsnetz. Drum beschreibe ich dieses wesentliche Unterscheidungsmerkmal etwas detaillierter.
- Die Beschreibung ist m. E. auch hilfreich, um den Unterschied Netz <> Route zu verstehen: Die Wegweiser beschreiben das Netz; die Einschübe mit den Symbolen beschreiben die Route. (Die im Forum diskutierten Ausnahmen sollten wir auf der route-Seite beschreiben)
Abgrenzung zur Fahrradroute
Zu „die Wegekette ist durchgängig ohne Lücken oder Äste“
- Warum schließt du Äste aus? Was ist mit Schleifen (α-Form)? Dem Ersteller von Routen würde ich diesen Freiraum lassen, wenn er die durchgehende Beschilderung hinbekommt …
- Ins Detail zu Routen wollte ich erst auf der Seite für die route-Relation gehen und die Ausnahmen dort beschrieben (DE:Bicycle/Fahrradrouten_kartieren derzeit hier DE:Fahrradroutentagging). Das hier ist ja die neue Seite für Netzwerke. Hier würde ich nur nennen, dass es Ausnahmen gibt und die andere Seite verlinken. Wird sonst zu groß und zu redundant.
- Aber auch dort: Eine Route-Relation sollte eine durchgängige Wegekette bilden, wobei sich Hin- und Rückrichtung unterscheiden dürfen (Rollen 'forward' und 'backward'). Schleifen sind damit möglich. Äste oder Alternativrouten aber nicht, das ergibt Lücken, wo man nicht sofort sieht, ob es Fehler sind (Lücken) oder gewollt (Äste). Sauber getaggt, gehören Äste oder Alternativrouten in eigene Relationen. Beim ÖPNV (route=bus) ist das ganz gut beschrieben, dort gibt es nach neuem Schema sogar getrennte Relationen für Hin- und Rückrichtung sowie für jede Fahrtvariante (Ast). Das macht das Überprüfen von Routen einfach. Lücken lassen sich sogar maschinell erkennen.
- Wenn man Äste innerhalb der relation zulässt, bekommt man das hier: Relation 222560. Das ist nicht im Sinne einer Route.
Sonderfall "Fahrradknotenpunktnetzwerke
Zu „Bei Fahrradknotenpunktnetzwerken hat jeder Knotenpunkt eine Nummer, also jede Wegekreuzung oder jeder Abzweig.“
- Das mag häufig sein, aber Bedingung ist es m.E. nicht. Hier ein Beispiel wo es nicht so ist: Attendorn Routen 45<->26 und 45<->43
Jede Wegeverbindung in einer eigenen Relation?
Zu „Jede Wegeverbindung sollte in einer eigenen Relation abgebildet werden“
- Meinst du mit type=route? Bei der modernen Wegweisung mit Zielwiederholung kann ich mir das gut vorstellen. Aber bei der traditionellen Wegweisung? Hast du eine Idee? --RobHubi (talk) 21:30, 22 June 2019 (UTC)
- Ich meinte Network-Relationen, für die Rote-relatinen gibt es ja eine eigene Seite. Im Idealfall ist die Handhabung von Netzwerk-Verbindungen und Routen die selbe.
Zu „Jede Wegeverbindung sollte in einer eigenen Relation abgebildet werden“
- Die Praxis in NRW, riesige Netze in eine Relation zu packen ist nicht so toll. In den Relationen hast du keinen Überblick mehr, was eine Lücke ist und was eine andere Verbindung, das lässt sich sehr schlecht pflegen. Da das aber weit verbreitet ist und wir hier beschreiben solle, was die gängige Praxis ist, habe ich den letzten Satz aufgenommen, aber das auf kleinere Netzwerke beschränkt. Dss Relationen nicht zu groß werden sollten ist m. E. Konsens in OSM. Was "Klein" ist, ist dann wieder so eine absichtliche weiche Formulierung. --Jo (talk) 22:38, 22 June 2019 (UTC)
- Große Netze haben unangenehme Ladezeiten, ja, aber die Pflege finde ich nicht so schwierig. Auf die automatisierte Prüfung muss ich verzichten, aber sie macht ohnehin nur einen kleinen Teil der Qualitätssicherung. Kleine Lücken in einer Wegekette zu übersehen finde ich weniger tragisch, als komplette Kanten und Äste.
- Viele Relation zu warten finde ich unangenehm. Wie stelle ich überhaupt das ganze Netz dar? Ich muss das gemeinsame Tag kennen und Overpass beherrschen. Nicht nur für Anfänger eine Hürde.
- Beispiel: Ich finde 2 neue Wegweiser, die in keiner Relation enthalten sind. Wie finde ich alle Relationen in der Umgebung, um auf eine mögliche Verbindung prüfen zu können?
- Eine geographische Gliederung finde ich natürlicher. Flüsse, Autobahnen, Bahnlinien etc. können Grenzlinien definieren.
- Ich würde es den Mappern vor Ort überlassen, welche Methode sie wählen, um die Größe der Relationen zu begrenzen.
- "Wie stelle ich überhaupt das ganze Netz dar? Ich muss das gemeinsame Tag kennen ...?"
- Die Frage, woran man die Zugehörigkeit zum Netzwerk festmacht, ist genau der Punkt, den ich unten im letzten Thema angesprochen habe ("Wozu dient die network-Relationen im Fahrradnetz...").
- Mit lcn=yes an den Wegen lässt sich das kaum machen.
- Bei Verwendung von Relationen sehe drei Möglichkeiten, die Zusammengehörigeit eines Netzwerks zu beschreiben:
- man macht die Zugehörigkeit an einem einheitlichen "operator" o. ä. an den Relationen der Äste und Verbindungen fest. So macht man es bei Buslinien im Verkehrsverbund.
- alle Relationen der Äste und Verbindungen werden in eine Art Master-Relation aufgenommen. So wird es in einem Knotenpunktfahrradnetzwerk gemacht. Alle Äste und Verbindungen sind dort route-Relationen, die in einer network-Relation zusammengefasst werden.
- alle Wege werden in einer einzigen network-Relation getaggt.
- Methode 1) finde ich auch schlecht, weil man nirgens festhalten kann, auf welches Tag und welche Bezeichnung/Schreibweise man sich in einer Region geeinigt hat. Eine regionale Abgrenzung ja nicht so eindeutig wie bei Verkehrsverbünden.
- Methode 2) und 3) sind da einfacher. Zudem kann man dort Hinweise in das note- oder description-Tag der übergreifenden Relation schreiben, z. B. "Fahrradnetzwerk des Tourismusverbandes Niederlausitz, erkennbar an den roten Wegweisern".
- Möglichkeit 3) hat die von mir beschriebenen Probleme der Riesen-Relationen, die würde ich ungern gleichwertig neben der zweiten stehen lassen. (Meine Versuche, die Wege in einer Riesen-Relation so zu sortieren, dass ich der Reihenfolge nach alle Verbindungen durchgehen und auf Vollständigkeit prüfen kann, endeten erfolglos mit Kopfschmerzen.)
- "Ich finde 2 neue Wegweiser, die in keiner Relation enthalten sind. Wie finde ich alle Relationen in der Umgebung, um auf eine mögliche Verbindung prüfen zu können?"
- Wenn die am Wegweiser ausgewiesene Verbindung schon eine vollständige Relation hat, so reicht ein Blick auf den Weg neben den Wegweiser, in welchen Relationen dieser enthalten ist.
- Sollte dort keine Relation sein, so muss man in Richtung des ausgeschilderten Ortes nach einer entsprechenden (noch lückengahften) Relation suchen und die Lücke schließen. Sollte keine passende Relation zu finden sein, sollte man eine neue anlegen.
- Das ist übrigens bei Netzwerken mit route-Relaionen nicht anders ("Wie finde ich 2 Bushaltestellenschilder, die in keiner Relation enthalten sind. Wie finde ich alle Busrelationen der Umgebung ...")
- "Viele Relation zu warten finde ich unangenehm."
- Bei Fahrradknotennetzwerken wird das genau so gemacht, ich persönlich fand das Taggingschema dort übersichtlich und angenehm.
- Vermutlich ist es auch Geschmacksache, ob man alle Wege eines Netzwerkes in einer Relation taggt oder jeden Ast und jede Verbindung in einer einzelnen Relation.
- Ich wollte die seperaten Relationen als Standard beschreiben, weil es bei route-Relationen ja auch der Standard ist. Abweichungen wollte ich aber nicht ausschließen, denn die Praxis alle Kanten in eine Relation zu packen ist ja verbreitet.
- "Eine geographische Gliederung finde ich natürlicher. Flüsse, Autobahnen, Bahnlinien etc. können Grenzlinien definieren. Ich würde es den Mappern vor Ort überlassen, welche Methode sie wählen, um die Größe der Relationen zu begrenzen."
- Was die Gemeinsamkeiten eines Netzwerkes sind (und damit dessen Grenzen definieren kann) hatte ich bislang nur in der Einleitung erwähnt (Wegweisungsstandard, ggf. weitere Standards, Betreiber). Das muss m. E. bleiben, denn das ist die Existenzberechtigung der Fahrrad-network-Relation. Achtung: Relationen, wie "Alle Radwegweiser in Sachsen" oder "Alle Fahrradverbindungen zwischen Elbe und Mulde" sind reine Sammelrelationen. Ich habe den Eindruck, dass solche Sammelrelationen sehr ungern gesehen werden. Eine rein georgrafische Begrenzung eines Ntzwerkes wäre m. E. nicht konsensfähig unter Mappern.
- Ansonsten habe ich bewusst offengelassen, wie man Grenzen eines Netzwerkes definiert, die regionalen Gegebenheiten sind dafür zu verschieden.
- Wann genau man eine Riesenrelation aufteilt, habe ich bewusst nicht beschrieben. Ich habe es allgemein gehalten, dass sie aufpassen sollen, dass die Dinger nicht zu groß werden.
- Zu „Ich wollte die seperaten Relationen als Standard beschreiben, weil es bei route-Relationen ja auch der Standard ist. Abweichungen wollte ich aber nicht ausschließen“
- Einverstanden. Das sollte aus der Formulierung deutlicher hervorgehen, Was hältst du davon:
- „Es empfiehlt sich, jede Wegeverbindung als eigene Relation abzubilden, so dass …“
- und
- „Bei kleineren Netzwerken werden mitunter alle Wegeverbindungen und Wegweiser des Fahrradnetzes in einer Relationen abgebildet. Bitte achtet darauf, dass diese Relationen nicht zu groß und unhandlich werden und teilt sie gegebenenfalls nach lokalen Gegebenheiten oder wie oben beschrieben.“
- Zu „Eine rein georgrafische Begrenzung eines Ntzwerkes wäre m. E. nicht konsensfähig unter Mappern.“
- Meinen wir dasselbe? Mein Use Case ist die Stadt Zürich. Den Aufbau des dortigen Netzes aus Einzelrouten halte ich für wenig praktikabel. Der äußere Umfang des Netzes ist klar definiert. Der Limmat und der See teilen das Netz ganz natürlich in die inneren Teilnetze West und Ost. Ich würde so beginnen, in der Hoffnung, dass die Größen der Relationen beherrschbar bleiben.
- Mein Use Case mag ein Einzelfall sein – nun ja, Lübeck scheint ähnlich zu sein – er sollte aber durch die Formulierung im Wiki nicht ausgeschlossen erscheinen. Formulierungsvorschlag s. o.
- Andere Beispiele: Radnetz Bergstraße West, Radverkehrsnetz Kreis Ostallgäu:
- Ich ergänze hier einmal mein Vorgehen für die Kreisfreie Stadt Bielefeld: Ausgehend davon, dass ich nicht in der Lage war, in dem ganzen Wegechaos in der einen Relation Radverkehrsnetz NRW, Stadt Bielefeld nachzuvollziehen, wo ich schon die Strecken überprüft habe, und wo nicht, habe ich nachdem ich das Knotenpunktnetzwerk eingearbeitet habe, die übrigen Strecken ebenfalls als einzelne Relationen eingearbeitet, und mit dem survey:date-Tag mir Anmerkungen machen können, was ich wann überprüft habe. Ich kann mir eine Wartung gar nicht anders vorstellen. Ich habe die Routen sehr kleinteilig, immer nur von Abzweig zu Abzweig genommen, da durch die Wegweisung Routenmerkmale beschrieben werden, die dann auch noch getaggt werden könnten. (Siehe auch User:Segubi/Elemente_NRW-Radwegenetz). Damit sind aus weit über 1000 ungeordneten Einzelwegen 113 Relationen in einer übergeordneten Relation geworden, die ich schon sehr handlich im Umgang finde. (Ich habe mir schon einmal erlaubt, diesen Teil des Netzwerks mit network:type=basic_network zu taggen, sowie type=network. Das läßt sich sehr übersichtlich bearbeiten mit einem geeigneten Kartenstil in JOSM und ist kompatibel mit waymarkedtrails, und CyclOSM sowie der Radfahrerkarte auf openstreetmap.org. Ein ref=NRW konnte ich auch weglassen, so werden die Routen tatsächlkich ohne Ballast von Markierungen (mit ein paar Ausnahmen, bei denen ich noch nicht verstanden habe, wo die Renderer das NRW hernehmen...). Dies bietet die Grundlage für eine erleichterte automatisierte Auswertung für Routenplaner und Kartenapps. Mit einem anderen Vorgehen könnte ich jetzt gar nicht wissen, dass es jetzt praktisch komplett ist und um viele veraltete Abschnitte bereinigt.
- Die übrigen Routen des Radverkehrsnetzes NRW in Bielefeld sind alle Teil des Knotenpunktnetzwerks Bielefeld, übrigens hier im Moment 209 Einzelrouten, also deutlich mehr als das verbleibende basic_network. Es fehlen nur noch die Routen zu 2 Knotenpunkten, die im Moment durch Baustellen nicht befahrbar sind.
--Segubi (talk) 22:45, 18 May 2021 (UTC)
"Als lcn=yes an den Wegen"?
- Wir sollten darauf hinweisen, dass lcn=yes mehrdeutig ist und international auch echte Routen bezeichnet. Ich würde sogar so weit gehen, es nicht als erste Wahl zu nennen. Neue Mapper brauchen eine Entscheidungshilfe. Wenn wir keine Empfehlung geben können, so sollten wir zumindest die Vor- und Nachteile gegenüberstellen.
- Für mich war das auch ein Aulaufmodell, in der Diskussion im Forum gab es aber mindestens einen Nutzer, der dieses Schema stark verteidigte. Im regionalen Wiki von Ulm ist das sogar als eine Standardmethode beschreiben. Daher habe ich das aufgenommen, der letzte Satz dort sollte aber schon aufzeigen, dass das in den meisten Regionen ein Auslaufmodell ist.
- Fällt dir dafür eine andere Formulierung ein?
- Vielleicht so?
- lcn=yes kennzeichnete Routen und Netzwerke bevor die Relation „erfunden“ wurde. Der Einfachheit wegen wird in manchen Regionen die Zugehörigkeit eines Weges zum Fahrradnetzwerk weiterhin mit dem Schlüsselpaar lcn=yes oder rcn=yes an den Wegen abgebildet. Die Nachteile – keine Eindeutigkeit und keine Metainformationen über das Netzwerk – werden in Kauf genommen.
- Ich stimme dir zu und habe es so ähnlich geschrieben. Jetzt geht m. E. deutlich hervor, dass das Schema eher ein Auslaufmodell ist, ohne das vorzuschreiben. Es gibt hier ja andere Ansichten dazu.
- Ob die Relationen tatsächlich später erfunden wurden oder ob sie sich nur erst später durchgesetzt haben, weiß ich nicht. Drum habe ich deinen Vorschlag nicht 1:1 übernommen.
- Deine jetzige Formulierung finde ich gut. Was bedeutet der Code [[DE:Key:{{{1}}}|{{{1}}}]]=* ?
- Am 30. März 2020 hast du diese Formulierung wieder rückgängig gemacht. Jetzt wird xcn=yes wieder gleichwertig zur Relation network gesetzt. Hast du deine Meinung geändert?
- Ich meine weiterhin, das steht im Widerspruch zum engl. Wiki wo es nur für Routen und Routen-Netze verwendet wird. Mit xcn=yes wird unsere Intention Netze von Routen unterscheidbar zu machen konterkariert. Zudem wurde es in der dortigen Diskussion schon 2008 als „deprecate“ angesehen und nur der Kompatibilität zum damaligen Bestand wegen weitergeführt. Das sollte jetzt wirklich vorbei sein.--RobHubi (talk) 20:34, 12 January 2021 (UTC)
Abgrenzung zur Wegweisung
Ich sehe schon das Ziel ;-) nur die Abgrenzung zur Wegweisung ist mir noch ein Anliegen. Bildet jede Gruppe von durchgehenden (Rad-)Wegweisern ein Netz? Beispiele:
- Aus verschiedenen Richtungen gibt es Wegweiserketten „Zum Hauptbahnhof“. Zurück gibt es nichts.
- In einem Weinbaugebiet finden sich Wegweiserketten „Buschenschank A“, „Buschenschank B“ usw. Von der Buschenschank zurück gibt es nichts.
Meiner Ansicht nach, bilden solche Wegweiser kein Fahrradnetzwerk. Es sollten nur Wege im Netzwerk aufgenommen werden, die in allen möglichen Fahrrichtungen ausgeschildert sind.
--RobHubi (talk) 22:04, 24 July 2019 (UTC)
Wozu dient die network-Relationen im Fahrradnetz? Wegeverbindungen ohne Name beschreiben? Umfang eines Netzes darstellen? Beides?
Ruhobi fragte "Ich hätte eher einen Satz erwartet wie: „Die Routen eines Betreibers können ein Netz bilden“. Wenn die Routen keine Verbindung haben, sind sie kein Netz.". Beim Überlegen, wie ich die Antwort auf die Frage in den Text formuliere hat sich mir die in der Überschrift genannte grundsätzliche Frage aufgestellt. Vor allem frage ich mich, ob die Aussage "Wenn die Routen keine Verbindung haben, sind sie kein Netz." auch für die als network-Relation getaggten Wegeverbindingen zutrifft.
Der Tag network=* bzw. seine Brüder lcn=yes beschreiben ja nur die Zugehörigkeit zu einem Netzwerk, nicht das Netzwerk ansich.
Nun kann man mit der network-Relation zwei Dinge machen:
- Komfortabel die Wege einer Wegeverbindung markieren, an die man sonst das Tag network=* bzw. lcn=yes taggen würde.
- Alle Verbindungen des Netzwerkes in einer Art Sammel-Relation zusammenfassen. Somit könnten Anganben zum Netzwerk zentral an einer Stelle gespeichert werden und müssten nicht an jedem Wegeelement geschrieben werden
Das sind grundsätzlich zwei verschiedene Dinge, eher vergleichbar mit Relationen type=route / type=route_master:
- 1) wäre analog zur route-Relation nur eben mit dem Unterschied, dass diese Verbindungen keine Eischübe an den Wegweisern haben, wo Symbol, Name und/oder Nummer drauf ist. Daher haben auch die network-Relation eher kein Name oder Nummer.
- 2) wäre analog zur route_master-Relation, sie enthalt alle Relationen im Sinne von 1)
Ich sehe 3 Möglichkeiten damit umzugehen:
- A) eine neuen Relationstyp definieren für die Wegeverbindung (z. B. type=network_connection) oder für die Sammelrelation (z. B. type=network_master)
- B) Beides mit network-Relationen abbilden. Die Relation im Sinne von 2) enthält dann alle network-Relationen der Wegeverbindungen. Die network-Relationen der Wegeverbindungen wiederum enthalten die einzelnen Kanten und Wgeweiser der Wegverbindungen im Sinne von 1).
- C) network-Relationen bei Fahrradnetzwerken nur für Abbildung der einzelnen Wegeverbindungen beschränken im Sinne von 1). Auf die Anwendung im Sinne 2) wird verzichtet.
- (D Alle Verbindungen des Netzwerkes als route-Relationen, network für als Sammelrelation im Sinne 2))
Die Möglichkeiten hätten m. E. folgend Vor- und Nahcteile:
- A) wäre eine saubere Lösung und durch die Analogie zur route/master_route sicher leicht zu erklären. Ich bezweifle aber, dass ein neuer Relationstyp Akzeptanz findet und habe auch nicht die Zeit, um einen enstprechenden Proposal zu machen.
- B) Erschlägt beide Anwendungen mit einem Relationstype und kommt mit den vohandenen Werkzeugen aus. Ich halte das aber für verwirrend.
- C) Wurde dem Motto "keine Sammelrelationen" entsprechen, allerdings wird genau das in einigen Regionen intensiv betrieben.
- Dafür spricht, dass man auch bei Busnetzen keine Masterrelationen für die Netzwerke von Verkehrsverbünden (z. B. "Mitteldeutscher Verkehrsverbund") oder für die Betreiber (z. B. "Leipziger Verkehrsbetriebe") anlegt. Bei Busnetzen werden die Info an die einzelnen Routen getaggt (network=MDV operator=LVB). Das Netzwerk eines Betreibers lässt sich z.B. durch Filtern nach 'operator' leicht finden.
- D) würde der Definition von routen-relationen widersprechen, wonach sie Name, Nummer oder Symbol haben sollen. Es ist ja gerade das Ziel, dass sich ausgewiesene Routen vom restlichen ausgeschilderten Wegenetz abgrenzen lassen, um sie z.B. in einer Karte gesondert hervorzuheben, auch wenn sie beide z.B. network=lcn sind.
Ich pendele zwischen B) und C), wober vermutlich C) die sauberere Löung ist. In diesem Fall wäre "Wenn die Routen keine Verbindung haben, sind sie kein Netz." nicht zutreffend, da 'network' im eher im Sinne von Klassifikation als im Sinne von 'gemeinsamer Betreiber' oder 'räumliche Ausdehnung' zu sehen ist. Dann müsste ich auch in der Einleitung auch den Hinweis auf Betreiber und einheitliche Standards als verbindende Eigenschaft rausnehmen.
Hm, oder ich beschreibe beide Möglichkeiten. Oder lässt sich die site-relation als Master verwenden?
--Jo (talk) 11:36, 16 June 2019 (UTC)
Seite jetzt online
Nach Abschluss der Diskussion im Forum setze ich nun die Seite online (https://forum.openstreetmap.org/viewtopic.php?pid=810969#p810969).
Erneute Diskussion des Schemas im Forum, bitte beteiligt euch um das Ergebnis auf eine breite Basis zu stellen
Das Schema für namenslose Verbindungen im Radverkehrsnetz wird erneut diskutiert, u. a. um eine einheitliche Lösung mit Wanderwegen zu finden.
Seid eingeladen, euch zu beteiligen und berücksichtigt im Anschluss die Ergebnisse beim Mappen von Radverkehrsnetzen, auch wenn deren Dokumentieren eine Weile dauern könnte:
Proposal: Wander-/Radweg ggü. anderen Wege mit Wegweisern hervorheben?
Danke, Jochen --Jo (talk) 23:53, 8 April 2021 (UTC)
Alte Fragmente des "R-Wege-Netz" / cycle_network
Ich bin mir unklar darüber, wie man mit dem alten R-Wege Netz in NRW umgehen sollte, selbst nach dem Maßstab, nur die Situation "on the ground" zu taggen, ist es nicht so einfach. Nach der Website http://www.achim-bartoschek.de/rad_nrw01.htm ist dieses Netz nie völlig fertig gestellt worden, und schon über 40 Jahre alt. Zum Teil ist es auch offensichtlich abgebaut, ich habe bei einer Radtour aber auch Schilder gesehen, die vermuten lassen, dass es auch an einigen Stellen zuletzt noch gepflegt wurde.
Ich habe einen Thread in der community, Altes “R-Radwegenetz” in Nordrhein-Westfalen - was tun? aufgemacht.
Ich finde, das wäre eine Verwendung für cycle_network=*. Und da es überall einen Haufen veralteter und inkompletter Netzwerkreste gibt, vielleicht sogar standardmäßig etwas wie cycle_network=DE:legacy:xxx? Habe ernste Kandidaten dafür im Kreis Herford (NRW), Kreis Gütersloh (NRW), Wetteraukreis (Hessen), Waldeck-Frankenberg (Hessen) gefunden.
(Und vielleicht eine Verlinkung von der englischen Wikiseite für cycle_network=* auf diese hier? cycle_network wird in Deutschland intensiv und in sehr uneinheitlicher Form benutzt, das Tag wäre nützlicher, wenn es klarer wäre, wie man es nutzt.)
Grüße,