Proposal: Wander-/Radweg ggü. anderen Wege mit Wegweisern hervorheben?

Laut dem unteren Schild hat die Route einen Namen “SHS1”. Es ist demnach eine klassische Fahrradroute mit name, ref oder Symbol. Bei klassischen Fahrrad- oder Wanderrouten ist Unterscheidung nach lokal und regional durchaus sinnvoll.

Das Proposal bezieht sich aber auf namenslose Verbindungen mit Wegweisung. Ich kann mir eine Klassifizierung dieser Verbindungen z. B. innerhalb eines Ortes kaum vorstellen.

Unterschiede in der Wegweisung ergeben sich oft aus dem Alter der Wegweiser. Mitunter gibt es ein Nebeneinander von z. B. alten Wegweisern der Kommune und neuen Wegweisern des Landes. Ursache ist meines Erachtens aber nicht eine angedachte Klassifizierung, sondern die sparsame Verwendung von Steuergeldern.

Wenn im Rahmen der Wartung alte Wegweiser ausgetauscht werden, verschwindet der Unterschied. Die Kommunen halten sich dann i.d.R. an die Landesvorgaben, schon weil es sonst kein Fördergeld gibt, aber auch, um ein einheitliches Radverkehrsnetz zu schaffen.

Grundsätzlich würde ich das Tag 'network='* im Wiki nicht verbieten, nur eben das ‘network=lcn’ als Standard beschreiben, der nicht extra angegeben werden muss.

Hallo,

ich würde gerne noch ein Beispiel anbringen, wo mir ein Konsens, wie das Basis-Netzwerk getaggt werden sollte, sehr weiterhelfen würde. In den Landkreisen Barnim und Oberhavel in Brandenburg ist ein Knotenpunktnetzwerk mit teilweise sehr groben Maschen ausgeschildert. Zwischen den Knotenpunkten mit Nummern gibt es weitere unnummerierte Abzweigungen mit ausgeschilderten Routen, die das Netz verdichten. Zum Beispiel die Wege, die ich in diesem Changeset https://www.openstreetmap.org/changeset/108558909 mit dieser Relation https://www.openstreetmap.org/relation/13015873 eingetragen habe.

User Streckenkundler hat in der Diskussion zu dem Changeset zurecht angemerkt, dass network:type=node_network für diese Relation falsch ist, auch wenn die Beschilderung vor Ort so aussieht, als ob sie Teil des Knotenpunktnetzwerkes wäre und die Knotenpunktnummern nur “fehlen”. Zum Beispiel ist die Verbindung zwischen Bernau und Hohen Neuendorf, die auf den Knotenpunktwegweisern regelmäßig als Fernziele auftauchen, über diese Wege ausgeschildert.

Ich habe jetzt das network:type in basc_network geändert. Ist das so in Ordnung oder gibt es noch eine bessere Möglichkeit?

Eine Lösung, mit der die Radfahrkarten solche Verbindungen ähnlich wie Knotenpunktnetzwerke rendern könnten, fände ich sehr hilfreich.

Danke! In Markleeberg gibt es das auch reichlich.

Das Proposal geht in kleinen Schritten voran und ist nun recht weit, es fehlt vor allem an der englischen Übersetzung wiki/User:JochenB/proposed_feature/basic_network

Grüße,
Jochen

Hallo zusammen, insbesondere Jochen und Sebastian,

wie ihr wisst war ich vor einiger Zeit auch bei der Diskussion um die Abgrenzung der Radverkehrsnetze von den Themenrouten dabei. Im Frühling/Sommer bin ich nicht zu viel gekommen.

Eure Proposal und hier geschilderten Überlegungen finde ich korrekt und gut. Durch meine eigenen Überlegungen komme ich praktisch zu den gleichen Ergebnissen.

In den letzten Wochen habe ich mich mal daran gemacht, das Radverkehrsnetz NRW im “Stadtkreis” Köln (https://www.openstreetmap.org/relation/55607) entsprechend umzubauen. Aus einer Sammelrelation mit 1500+ way membern ist eine Relation geworden, die nun 240 Route Relationen enthält.

Folgendes habe ich etwas anders gemacht als Sebastian in Bielefeld:

  • Ich habe auch Strecken angelegt und in die Netz Relation aufgenommen, über die eine Knotenpunktroute verläuft. Irgendwie kann ich mich nicht damit anfreunden, diese wegzulassen. Knotenpunktrouten liegen ja auf dem Radverkehrsnetz, das Netz ist die absolute Basis und sollte nicht lückenhaft sein. Eine vollständige Erfassung bringt jedoch deutlich mehr Aufwand mit sich…
  • Ich habe meistens eine Route nur zwischen zwei “Kreuzungen” des Radverkehrsnetzes (ich will nicht “Knoten” sagen) angelegt. D.h. es gibt bis auf wenige Ausnahmen keine Routen, die über solch eine Kreuzung hinausläuft. Jede Verbindung ist eine eigene Relation.
  • Ich wollte allen Relationen wenigstens eine kurze Beschreibung geben, von wo nach wo sie läuft. Nun ist es so, dass Tags wie description, note, name unpraktisch für das aktuelle Rendering von waymarkedtrails sind. Teilweise werden sie verwendet um ein Ref Tag zu generieren. Diese sollten im aktuellen Rendering der Übersichtlichkeit wegen vermieden werden. Daher habe ich zunächst provisorisch die Tags from und to verwendet, um die Straßen am Anfang und Ende der Route anzugeben.

Ich denke es ist wichtig, verschiedene Details in unterschiedlichen Regionen auszuprobieren, um einfach Erfahrung zu sammeln, wie sie funktionieren.

Folgende Gedanken habe ich nach der Umsetzung in Köln:

  • Die Übersichtlichkeit der Netzwerk Relation hat sich erheblich verbessert. Die großen Sammelrelation mit den Tausenden von unsortieren way Mitgliedern war einfach fürchterlich. Der Zustand der Sammelrelation war in Köln sehr schlecht. Neben dem Fehlen ganzer Strecken (ok, bisher nicht erfasst) gab es sehr viele Lücken und es gab viele “falsche” Mitglieder, die vermutlich durch Änderungen an den Wegen in die Relation gerutscht sind. Wenn es keinen eindeutigen Routenverlauf gibt, kann solch eine Sammelrelation einfach nicht gepflegt werden.
  • Das Anlegen einer eigenen Relation für jede Verbindung führt zu einigen Relationen mit teilweise sehr wenigen oder gar nur einem way Mitgliedern und zu einer recht hohen Gesamtanzahl von Route Relationen auf relativ kleinem Raum. Dies kann jedoch eine Besonderheit in Köln sein, da es hier im Vergleich zu anderen Regionen ein sehr engmaschiges Netz und somit vielen “Kreuzungen” gibt.
  • Pflegeaufwand: Ein automatisches Analysetool für das Radverkehrsnetz ähnlich wie knooppuntnet.nl wäre schön, um unvollständige oder defekte Routen zu erkennen. Ich sehe allerdings nicht, wie dieses ohne das Taggen von “Kreuzungen” vollständig funktionieren kann. Diese Kreuzungen wären auch sinnvoll, damit andere Mapper, die nicht im Thema sind, genau erkennen können, zwischen welchen Punkten eine der Verbindungsrelationen verläuft. Dadurch könnten sie bei Änderungen an den Wegen die Verbindungen relativ einfach aktuell halten. Praktisch gibt es oft jedoch nicht den einen einzigen Punkt als Kreuzung, sondern analog zu den Knotenpunkten an komplexen Kreuzungen häufig split nodes. Diese zusammen mit den route tentacles flächendeckend im Radverkehrsnetz einzuführen erhöht die Komplexität enorm und ist zumindest aus meiner Perspektive absolut unrealistisch.
  • Parallel verlaufende Netzwerk/Knotenpunkt/Themen-Routen: Praktisch wäre, wenn man Knotenpunkt- und Themenrouten nicht parallel anlegt, sondern aus den einzelnen Verbindungen des Netzwerks zusammensetzen kann. Das würde Aufwand der Pflege und das Anlegen neuer Knotenpunkt-/Themen-Routen erheblich reduzieren (“Zusammenklicken von bestehenden Relationen”). Dafür sind jedoch wohl die eben beschriebenen split nodes / tentacles nötig…
  • Es könnte sinnvoll sein, die Zielwegweiser an den beiden Kreuzungen einer Netzwerk Verbindung in die jeweilige Relation mit aufzunehmen. Damit hätte man einen einfach verständlichen Anhaltspunkt, was Anfang und Ende der Verbindung entspricht. Wie geht man dabei allerdings mit Tabellenwegweisern an komplexen Kreuzungen, fehlenden/zerstörten Wegweisern und generell komplexen Situationen um?

Das ist mir auch schon unter die Finger gekommen und ich dachte mir, wer soll das entflechten? Danke!

Ein hauch Perfektionismus, oder? :slight_smile: Finde ich OK.

Ich finde das Verwenden von 'from=‘* und 'to=’* gut, allerdings bei Kreuzungen mitten im Nichts wird es schwierig sein, einen passenden namen zu finden.

Dass waymarkedtrails note für das Rendering auswertet finde ich komisch und ncit gut. Das sind ja eher OSM-interne Komentare.

Die Schweizer empfehlen für ihr Wanderwegenetz auch 'from=‘* und 'to=’* statt 'note='*. Sie führen die Wege oft weiter, bis sie auf ein Ziel mit Namen stoßen. Das führt zwar dazu, dass man mitunter mehrere Relationen an einer Kante hat, aber reduziert die Anzahl der Relationen. Hier der Link zu deren Seite: wiki/DE:Switzerland/HikingNetwork

Ich denke es wäre kein Problem, wenn du eine langere Relation über den Abzweig hinaus bis zum nächsten Ziel verlängerst und damit kurze Reletionen einsparst. Im Gegensatz zum Knotenpunktnetzwerk gibt es ja keine festgelegten Ziele für die Relationen. Wichtig ist nur, dass die Relation eine durchgängige Wegekette bildet, damit man sie daran leicht püfen kann.

Meinst du damit, dass man analog den Knotenpunkten aus “Radeln anch Zahlen” Knoten definiert, an denen alle Relationen einer Kreuzung verknüpft werden? Das halte ich auch für einen hohen Anspruch. Das mit den Split Nodes habe ich hier zwar versucht, verständlicher zu formulieren, aber die viele Mapper wollen nicht solch komplizierte Anleitungen lesen müssen.

Hatte ich auch schonmal überlegt und wurde irgendwo auch schonmal diskutiert, ich finde es nur nicht außer hier: User_talk:JochenB/proposed_feature/basic_network

Ich würde einfach alle Wegweiser am Ende der Relatin aufnehmen, die in eine der beiden Richtungen der Relation zeigen. Sie erhalten dann die Rolle ‘guidepost’.

Auch ich stimme Duvodas sehr zu, habe mich noch nicht ganz zu dieser Konsequenz durchgerungen.

Ich setze vielleicht etwas andere Akzente als Jochen, daher noch meine Anmerkungen…

Es geht mir wie Duvodas, habe das aber nicht gemacht, weil es ziemlich viele Doppelungen ergibt. Man bräuchte eigentlich vorher ein Tagging, das es einem Renderer ermöglicht, die Darstellung des Grundnetzwerkes zu unterdrücken, wenn eine Knotenroute oder andere Route darüber liegt. Bei den Knotenpunktrouten geht es noch so einigermaßen, da diese dem offiziellen Radnetz immer angehören müßten und somit eine Teilmenge davon sind, aus der sich die Einzelrouten auch herausrechnen ließen. Für anders benannte Routen gilt das leider nicht, da gibt es die Geschichte mit den “Routenabzweigern”, die dann “noch” nicht den HBR folgen.

Das ist nicht durchgängig so: Siehe z.B. hier, unbenannte Route, Tag note verwendet. Waymarkedtrails scheint einen Cache zu verwenden, wenn da einmal etwas drin ist, wird es wohl nicht ohne weiteres gelöscht, ich habe versucht im Kreis Herford unbenannte Abschnitte zu generieren, es ist mir nicht gelungen… Wahrscheinlich würden die Bezeichnungen wieder verschwinden, wenn man die Relation löscht und neu anlegt, was bitte NIEMAND (großflächig) tun möge, weil das natürlich die ganze History mit löschen würde usw. (das wäre “deleting for the renderer”). Ich habe konsequent note=“RVN KREIS-KZ, Gemeinde, dann eine Beschriebung” verwendet, wobei mir description lieber gewesen wäre, dann wäre es in JOSM aber nicht mehr sichtbar gewesen und ich hätte den Überblick verloren… (habe den Änderungswunsch mitgeteilt… wahrscheinlich muß ich mich an dem Quelltext von JOSM selbst vergreifen - oder es ist schon geändert und ich hab’s nicht gemerkt…)

Das hat Peter Elderson mal kommentiert und für eine längere Route in den Niederlanden mal ausprobiert. Es scheint gar nicht so leicht zu sein - gerade mit den Split nodes - für eine richtige Reihenfolge und Richtung zu sorgen, da auch für komplette Relationen die roles forward und backward noch nicht vorgesehen sind. Ich finde bloß nicht so schnell seinen Post… Für das Knotenpunktnetzwerk halte ich das im Moment für unrealistisch, die Routen zu zerlegen und in weitere Relationen zu splitten, weil es für das aktuelle Tagging einen Internationalen/Mitteleuropäischen Konsens gibt. Inzwischen wird das Tagging in den Niederlanden, Belgien, Luxemburg, Frankreich, Spanien, Österreich, Deutschland benutzt. Viel Spaß dabei, die User aus den Ländern von einem anderen Verfahren zu überzeugen, nur weil in Deutschland die Nummerierung der Knotenpunkte dünner ist als anderswo. Ich vermute, es ist einfacher, intelligentere Software zur Auswertung zu schreiben…

Finde ich gar nicht so schlecht. Damit könnte man auch rekonstruieren, was für ein Streckenpiktogramm für den jeweiligen Abschnitt gültig ist (Freizeitstrecke, Bahntrasse, Steigung usw.), ohne dafür ein neues Tagging für die Routenrelation zu benötigen, das bei der z.T. auch inkonsistenten Ausschilderung ja dann auch oft nicht das abbilden würde, was tatsächlich sichtbar wäre (obwohl mir das besser gefallen würde: xyzleisure=yes yxzbahndamm=yes oder so).

@Knoten: Das ist immerhin genau der Begriff, der sich für die Kreuzungen in den HBR NRW findet (da wird in der Begrifflichkeit allerdings etwas ungenau operiert. Knotenpunkt meint dann nur die nummerierten Punkte…).

In Bielefeld ist das genauso. Und hier weiche ich von Jochen ab. Ich finde die Wartung deutlich komplizierter, wenn man längere Abschnitte in eine Relation nimmt. Ich lege bei der massiven kontinuierlichen Umbautätigkeit hier in Bielefeld (das mag hier eine Besonderheit sein, “Bielefeld, die freundliche Baustelle am Teutoburger Wald” ist eine Abwandlung eines Slogans, der mindestens seit den 50er Jahren den Zustand gut beschreibt) großen Wert auf den Key:survey:date=*, wenn die Relation zu lang ist, kann man ihn nur noch verwenden, wenn man eine längere Strecke komplett abgefahren ist, das ist unpraktisch. Ich habe mir zur Regel gemacht, dass eine Relation mindestens 100m lang sein muß, wenn sie kürzer ist, betrachte ich sie als split node (ab 100 m können die Entfernungsangaben auf den Wegweisern nicht mehr identisch sein - ich habe allerdings inzwischen Stellen im Kreis Paderborn gefunden, wo die Entfernungsangaben auch bei einem eindeutigen Einzelknoten auf zwei Straßenseiten abweichen, da haben sie wohl ziemlich genau gerundet…). Ganz konsequent war ich allerdings nicht - die Regel habe ich mir auch erst vor einigen Monaten auferlegt…

Tiefer Seufzer… Ich habe mit der Idee den Betreiber von knooppuntnet.nl (vmarc - ganz herzliche Grüße und Respekt, wenn Du Dir die Mühe machen solltest, hier auf Deutsch mitzulesen…) kontaktiert und eigentlich schon über ein halbes Jahr mit ihm darüber sprechen wollen. Ich habe mir auch die Software auf den Rechner geholt und ein wenig scala gelernt, um ein paar unklare Knoten in Bielefeld besser zu verstehen, die das Programm bemäkelt. Das Projekt ist allerdings so groß für mich, dass ich als normal berufstätiger Familienvater nur im Schneckentempo vorankomme… Aber: Das wäre grundsätzlich gar kein Problem, wenn es ein einheitliches Tagging gebe, und man das gesamte Netz einheitlich markieren würde. Oder zumindest Kriterien definieren könnte, an denen die Software erkennen kann, welche Relationen es auf die Art wie Knotenpunktnetzwerke auswerten kann.

Es ist ein absolut relevanter Wunsch. Die Relationen hier haben eine geringe Haltbarkeit, weil immer wieder Menschen Unterbrechungen in die Relationen einbauen, indem sie bei Baumaßnahmen die Relationen z.B. gar nicht mit korrigieren. Z.B. wenn bei der Einrichtung einer Fahrradstraße die Fußwege nicht mehr mit dem Fahrrad befahren werden dürfen, aber die Relation weiter über diese Wege läuft. Oder bei Baustellen Wege gelöscht werden und wieder neu angelegt werden, wenn sie fertig ist - dann fehlen sie aber in allen Relationen, die die alten Wege benutzt haben. Eine Software, die zügig darauf hinweist, wäre hilfreich.

Problem ist allerdings, dass das gegenwärtige Schema für die Knotenpunktnetzwerke noch nicht einmal für die Abbildung der hiesigen Realität ausreicht, weil die Verhältnisse der Tentakel manchmal ganz schön unübersichtlich sein können. Mit der Verallgemeinerung würde es nicht einfacher.

Sorry, ist doch ganz schön lang geworden. Hoffe, es ist nicht so viel Kraut und Rüben, da ich mich hier leider jetzt um andere Dinge kümmern muß und nur grob Korrekturlesen kann.

Ich habe mein Vorgehen auf meiner Userseite versucht zu beschreiben: Da sind auch Abbildungen dabei.
Grüße und einen schönen Abend,
Sebastian

Nunja, normalerweise ist ja ein Wegweiser als Punkt getaggt und, ggf. deren angezeigten Inhalte nach Himmelsrichtungen. Da den Wegweiser der richtigen Himmelsrichtung rauszufinden ist algorithmisch schon eine Herausforderung und trotzdem wird es nicht immer richtig sein.

Ich habe es anders gemeint. Es ging ja um sehr kurze Relationen. Vor allem in der Stadt ergeben sich mitunter Relationen, die nur eine oder sehr wenige Weglinien enthalten. Die kann man einfach an eine längere mit dranhängen, das macht den Kohl dann nicht fett.

Gut, da stimme ich zu. Solange man sich noch nicht daran macht, das potenzielle Analysetool zu programmieren, ist es erst einmal egal. War (z.B.) da auch nicht päpstlicher als der Papst.

Wobei es schon hilfreich ist, durch ein Ende der Relation zu signalisieren, dass es eine Abzweigmöglichkeit gibt. Bei Kreuzungen mit anderen Netzwerken kann es unter Umständen keine Hinweise auf einen Abzweig geben: z.B. hier. Hier werden die Routen einfach gekreuzt geführt ohne Hinweis auf die jeweils andere. (Radverkehrsnetz NRW mit Themenroute “Architektour” kreuzt Europaradweg, der hier unabhängig vom offiziellen Radverkehrsnetz nach HBR verläuft).

Dafür wär natürlich eine ordentliche Trennung der Netzwerke nach Tag auch eine theoretische Möglichkeit (ich benutze hier leicht mißbräuchlich das “network:type=basic_network” auch für Abschnitte mit Themenrouten…). Ist aber nicht ganz einfach, weil die anderen Netzwerke Routenabschnitte und auch Ausschilderung gelegentlich mitbenutzen…

Grüße,
Sebastian

Also ich weiß nicht. Das Ende der Relation ist im Netz hat m. E. keine Bedeutung, wenn dort eine gleichartige Relation wieder anschließt. Worin genau siehst du den Vorteil, wenn an einer Kreuzung 4 Relationen enden gegenüber wenn dort 2 Relationen kreuzen? Die Aussage ist doch die gleiche: Es geht in 4 Richtugen auf dem Rad-/Wanderwegnetz weiter.

Man könnte das Netz auch so taggen, dass man die auf dem Rad-Wegweiser oben stehen Hauptziele als Anfang und Ende einer Relation definiert und diese dann in ‘from’ und ‘to’ schreibt. So wird es mitunter in der Schweiz im Wanderwegnetz gemacht. Da mehrere Wege nach Rom führen können, kann es dazu kommen, dass es mehrere Routen mit identischem ‘from’ und ‘to’ gibt. Vor dem Ziel werden dann häufig mehrer Relationen überlappen. Vorteil ist, dass Start und Ziel immer benennbar sind.

Das Tag ‘network_type=basic_network’ an eine Themenroute zu taggen macht dessen Zweck zunichte, zwischen benannten Routen (ohne ‘network_type=basic_network’) und restlichen Netz (mit ‘network_type=basic_network’) zu unterscheiden. Das ist das Gegenteil von dem, was der Erfinder im Sinne hatte :).

Man kann das ausgeweisene Radverkehrsnetz als eine Schicht sehen, in der benannten Radrouten und eben Basisverbindungen existieren, hier darf eine benannte Route kein ‘network_type=basic_network’ haben.

Man kann (aber muss nicht) beides als zwei unterschiedliche Schichten verstehen:

  • Basisnetzwerk als Grundschicht (Zielwegweiser)

  • benannten Routen als darüber liegende Schicht (Symboleinschübe)

Hier kann man auch unter eine benannten Route noch die Verbindung des Basisnetzwerks als eigene Relation taggen. Die bekommt dann das ‘network_type=basic_network’. Aber auch hier darf es nicht an der benannten Radroute stehen.

So, ich habe mein Proposal für ‘basic_network’ als Wert für die Schlüssel ‘network:type’, ‘lcn’ und ‘lwn’ nun offiziell zur Diskussion gestellt:

wiki/Proposed_feature/basic_network

Bitte gebt auf der dortigen Diskussionsseite Hinweise, wenn aus eurer Sicht etwas angepasst werden sollte, damit es Akzeptanz findet.

Segubi und Robhubi haben mich vor allem bei der Übersetzung ins Englische unterstützt, vielen Dank nochmal dafür!!!

Hier noch etwas verspätet meine Antwort auf eure Kommentare, mit denen ich fast vollständig übereinstimme.

Anfang und Ende einer Verbindungsrelation

Die Aufnahme der guideposts am Anfang und Ende in die Relation halte ich für eine sehr gute Idee. Dadurch können sich alle Mapper schnell einen Eindruck davon machen, von wo nach wo die Relation verlaufen soll. Das hilft stark bei der Pflege, da ein Fehlen von Relationsmitgliedern dann nicht nur in der Mitte sondern auch an den Enden auffallen würden. Die guideposts an sich sind als OSM Objekte im Gegensatz zu den Wegen der Route ja sehr konstant. Auch sehe ich dadurch eine Möglichkeit der automatischen Kontrolle ähnlich knooppuntnet.nl! Die Software könnte dann checken, ob es für beide Richtungen einen durchgehende Verbindung zwischen den guideposts gibt. Dabei werden im Gegensatz zu den Knotenpunktrouten dann nicht die Knoten auf den Wegen verwendet, sondern einfach eine Fläche mit z.B. maximalem Abstand von 50m zu dem guidepost. Das wäre zwar an den Enden etwas ungenauer, aber besser als nichts und auch ein vernünftiger Kompromiss zwischen Komplexität/Verständnis und logischer Kontrolle/Vollständigkeit. split nodes sind nicht nötig. Bei Pfeilwegweisern kann man sogar evtl. die Anzahl der Richtungen mit der Anzahl der Relationen abgleichen (sofern jede Verbindung eine einzelne Relation ist). Ich habe begonnen, das Radverkehrsnetz im Kreis Neuss nun mit den guideposts umzustruktieren.

Das halte ich für keine gute Idee. Es gibt im Radverkehrsnetz NRW keinen festen Punkt, an dem die Fernziele “erreicht” sind. Auch können sich die Ziele auf halber Strecke schon ändern. Eine Überlappung von mehreren basic_network Relationen finde ich ganz schlecht, da es faktisch ja nur eine Ausschilderung gibt und es den Pflegeaufwand erhöht. In engmaschigen Gebieten kann es außerdem sehr viele unterschiedliche Wege mit dem gleichen Fernziel geben. z.B. gibt es in Köln möglicherweise 20 “Startpunkte” mit dem Fernziel Leverkusen, deren Verlauf sich am Anfang unterscheidet, am Ende aber überlappt. Dann hätte man 20 Relationen auf einer Strecke mit nur einer Beschilderung.

Hier bin ich nicht sicher, ob ich dich richtig verstehe. Ich habe den Verdacht, dass Jochen dich da bereits falsch verstanden hat. Abschnitte von Themenrouten, die nicht auf dem Radverkehrsnetz liegen, bekommen selbstverständlich kein “network:type=basic_network”. Aber das ist dir eh klar oder? Also als Beispiel, in Köln gibt es “RegioGrün” Routen, die so nah wie möglich Bachverläufen folgen. Das Radverkehrsnetz hingehen führt nicht über diese manchmal schlechten Wege sondern geht seinen eigenen Weg. Die Themenroute ist dann mit einem eigenen Pfosten und/oder Schild ausgeschildert und natürlich nicht Bestandteil des Basisnetzwerks.

… stimme voll zu.

Ich werde mal Fotos zusammensuchen, die das illustrieren. So, wie ich Dich verstanden habe :wink: , stimme ich zu und handhabe es genau so. Ich habe Jochen wiederum so verstanden, dass er es (zumindest in den ersten Ansätzen) bevorzugt hätte, dass mit basic_network ausschließlich Streckenabschnitte markiert werden, die auch kein Teil einer benannten Route sind.

In Bielefeld ist die Wegestruktur einfach, sämtliche Themenrouten sind nach einer Neugestaltung in den letzten 2 Jahren komplett nach HBR ausgeschildert und so ein Teil des Radverkehrsnetzes geworden. In den Nachbarkreisen geht das sehr durcheinander. Da gibt es z.B. im Kreis Herford Gruppen von Themenrouten, die zu ca. 90 % und mehr nach HBR ausgeschildert sind, und dann plötzlich über einen Routenabzweiger einen Abschnitt haben, der da nicht mehr ganz der Ausschilderung folgt (aber trotzdem die roten Zwischenwegweiser verwendet). In den Kreisen Lippe und Gütersloh gibt es Routen, die eher nur zu 20 % die Wegweisung mit dem Radverkehrsnetz teilen und auch auf den eigenen Streckenabschnitten nicht die roten Zwischenwegweiser benutzen. Dann gibt es noch die “Terra”-Routen, die z.T. gemalte Markierungen auf Bäumen verwenden, z.T. aber auch Wegweiser, die an die Routenabzweiger erinnern. Und es gibt einen Haufen Reste alter Radverkehrswegweisungssysteme, wie einzelne Wegweiser des alten R-Netzes, eine frühere, nun meist blind endende Wegweisung im Kreis Herford mit kleineren roten Schildern, ähnlich wie die aktuellen, die z.T. auch Farbmarkierungen zusätzlich haben, aber praktisch keine konsequente Wegweisung mehr verfolgen.
Ich tagge im Moment nur die Wegabschnitte mit basic_network, wenn sie über Zielwegweiser miteinander verbunden sind, oder ich davon ausgehen kann, dass das Fehlen eines Zielwegweisers in einer Richtung tatsächlich ein Fehler ist (z.B. zu erkennen durch: beidseitig ausgeführte Zwischenwegweiser, Aufführung des Abschnittes in radverkehrsnetz.nrw.de, abbrechende Fernzielwegweisung, wenn man den Streckenabschnitt nicht berücksichtigen würde - letzlich z.T. Hinweise auf Vandalismus).

In Bielefeld habe ich nur die Abschnitte so berücksichtigt, die nicht zum Knotenpunktnetzwerk und nicht zu den Themenrouten gehören, da alle diese Routen auch zum Grundnetzwerk gehören und die Information insofern redundant ist. (Inhaltlich könnte man das alles auch mit einem Tag wie cycle_network=DE:NRW:xyz-Netzwerk-nach-HBR markieren…

In den Nachbarkreisen geht das so nicht. Da braucht es eine zusätzliche Markierung, wenn man in OSM darstellen möchte, dass ein Abschnitt zum Grundnetzwerk nach HBR gehört, und ich habe angefangen, einzelne Relationen zu ergänzen, wenn ich sie selbst mal abgefahren bin und weiß, wie die Ausschilderung ausgeführt ist.

Grüße,
Sebastian

Wow, bin durch die Anzahl der kritischen Äußerungen und das teilweise Unverständnis, doch überrascht.
cycle_network mag Teile des Problems lösen, aber der Tag cycle_network=* ist auch nur “in Benutzung” und ein Proposal zumindest nicht verlinkt. Für mein Problem, das Taggen von l*n=* an den einzelnen Wegen, da die Relation noch fehlt oder nicht möglich ist, gab es auch keine Lösungsvorschläge.
Ich habe mich bisher im meiner Region zurückgehalten und lcn=yes in lcn=basic_network geändert, da ich mir nicht sicher bin, ob das von den Renderer unterstützt wird.

Ich denke, der Status Quo und damit das Problem der gruseligen network-Sammelrelation contra eindeutiges Taggen an den einzelnen Wegen sollten besser hervorgehoben werden. Das Relationen entweder zu Kleinteilen mit dann etlichen Ebenen von Superrouten führen können oder schlichtweg nicht wirklich umsetzbar sind, sollte auch verdeutlicht werden.
Ich kann allerdings auch verstehen, wenn Du (i.M.) keine Lust hast, hier weiter zu arbeiten.

Ja, mich hat die auch Diskussion erschlagen, fast 300 Diskussionsbeiträge! Gerechnet habe ich mit 30.

Hier der Link zur Diskussion. Ich arbeite grad an einer Zusammenfassung, die poste ich dann im Forum um zu beraten, wie es weitergeht. Ich bin etwas gelähmt aber nicht demotiviert.

Es gibt aber keine grundlegende Ablehnung. Das Proposal muss jedoch in der Beschreibung überarbeitet werden. Zudem sollten wir einen besseren Schlüssel als ‘network:type’ finden, dessen Namen selbstsprechend ist oder gleich einen neuen Routentyp ‘route=bicycle_net/hiking_net’ oder ähnlich.

Bis dahin würde ich den Schlüssel wie im Proposal vorgeschlagen verwenden. Das tut niemanden weh. Das hinterher zu verändern, sollte mit einem kontrolliertem, mechanischem Edit kein Probelm sein.

Das finde ich auch gut.

Allerdings nehme ich bislang bei Rad- und Wanderrouten immer alle Wegweiser in die Relation mit auf. Mitunter gibt es an Kreuzungen ein Wirrwarr von Wegweisern, da kann man sich die Wegweiser seiner Route hervorheben lassen. Wenn die Wegweiser in der Relation nicht sortiert sind, ist das mit dem Erkennen des ersten und letzten Wegweiser wieder nicht so einfach.

Man könnte den eersten/ letzten Wegweisern freilich Rollen in der Relation vergeben, dann wäre es wieder ersichtlich.

OK, das leuchtet mir ein. Es sollte demnach immer nur eine basic network-Relation pro Kante geben.

Allerdings müssen sie nicht wie bei Knotenpunktnetzwerken am nächsten Knoten enden, man kan sie auch mit der nächsten Relation zusammenführen. Das hilft, Ein-Kanten-Relationen zu vermeiden.

So hätte ich das auch gesehen. Das basic network erkennt man an einer einheitlichen Beschilderung, im deutschen Radnetz wären das die grünen oder roten Zielwegweiser und die Pfeil-Zwischenwegweiser.

Wenn man es komplett erfassen will, müsste man auch die Abschnitte unter Themenrouten oder Knotenpunktnetz-Verbindungen (KN) erfassen. Entsrechend der Ursprungs-Idee wären das eigene basic-network-Relationen. Ein Weg im basic network, über den eine KN-Verbindung und eine Themenroute verläuft, wäre dann Teil von drei entsprechenden route-Relationen.

Zumindest bei den deutschen KNs ist das m. E. aber nicht notwendig. Alle KNs die ich kenne verlaufen zu 100% auf dem basic network. Wir könnten für Deutschland einfach per Definition festlegen, dass die KNs Teil des basic networks sind. Alternativ können wir den (neuen) basic-network-Tag auch an alle KN-route-Relationen hängen anstatt alles redundant nochmal für das basic network zu erfassen. Ich fände letzteres am Besten, das lässt sich datentechnisch besser auswerten als eine “Papier”-Definition im Wiki.

Die basic network-Verbidnungen auch unter den Themenrouten zu erfassen ergibt dann einen Mehrwert, wenn diese tatsächlich mitunter abweichend verlaufen oder wenn auf den Wegweisern des basic network Informationen stehen, die an die dazugehörige Relationen gehören.

Ich würde da aber keine Prio drauf legen. Mir ist erstmal wichtig, die reinen basic-network-Verbindungen als solche zu taggen, damit man sie anders darstellen kann. Alles andere ist dann Kür.

PS: Sorry für die späte Antwort. Ich war mit der langen Diskussion in der Mailingliste komplett ausgelastet.

Verstehe ich, da hilft mir manchmal Abstand, um dann eventuell in ein paar Monaten eine gute Idee zu haben.

Von einem komplett neuen Wert für route=* halte ich nicht so viel plus hilft es nicht bei l*n=yes an den Linien. Dann schon eher l*n:network=local oä. als Ersatz (l*w=yes) bzw Zusatz (Relation).

Ich hatte verstanden, dass lcn=yes an Linien wieder ausgewertet wird. Bin ich da auf dem falschen Dampfer?

+1, für alle Wegweiser, möglichst geordnet in der Relation.
Bei Routen in nur eine Richtung, gebe es schon “start” und “stop” plus ein paar Varianten. Eventuell auch “first_guidepost”/“last:guidepost” oder “guidepost:first”/“guidepost:last”. Aber wie machen wir das bei Routen, die in beide Richtungen verlaufen?

‘from’ und ‘to’ bei Routen, die in beide Richtungen gelten, halte ich für irreführend.
Bei langen Routen, ist es sinnvoll diese in Abschnitte zu Teilen und die Teile in einer superroute-Relation zusammenzufassen. Schwierig wird es meiner Ansicht nach nur, wenn die Relationen zu viele Mitglieder bekommen (+500) oder es zu zu vielen Ebenen von Superrouten kommt. Daher wäre ich auch vorsichtig mit der Verwendung von Basisnetzwerkabschnitten in Route andere Kategorie.

Hallo zusammen,

ich möchte diesen Thread noch mal aufwärmen und die Anregung von Duvodas aufgreifen, Erfahrungen aus verschiedenen Regionen zu teilen.

Ich habe angefangen, das Radverkehrsnetz der Stadt Potsdam als Basic-Network-Relationen zu kartieren (Relation Relation: ‪Radverkehrsnetz Landeshauptstadt Potsdam‬ (‪15818943‬) | OpenStreetMap mit z.Zt. 78 Unter-Relationen als Mitgliedern). Eine ganze Menge Abschnitte fehlen noch, trotzdem wollte ich hier schon mal auf den Zwischenzustand hinweisen. Vielleicht habt Ihr ja auch Hinweise, was ihr anders machen würdet.

Folgende Gedanken sind mir beim Erfassen gekommen:

  • Das Netz in Potsdam ist teilweise sehr dicht, vor allem in der Innenstadt. Hinzu kommt, dass sehr oft die beiden Fahrtrichtungen über unterschiedliche Ways verlaufen (sei es, weil die Radwege separat kartiert sind, sei es weil es sich um Straßen mit getrennten Richtungsfahrbahnen handelt). Dadurch ist das Kartieren ziemlich aufwändig.

  • Ich habe versucht, die Relationen in der Regel an den Knoten zu unterbrechen und dann gemäß dem Split-Node-System mit Tentakeln zu arbeiten. Das ist an den großen Kreuzungen allerdings ziemlich komplex, und ich befürchte, dass Mapper, die möglicherweise später diese Kreuzungen verändern, das System nicht verstehen. Hier bin ich mir unsicher, ob die gewählte Lösung so die beste ist.

  • Teilweise gibt es „Kreuzungen“, die so groß sind, dass es ziemlich unklar ist, wo eine Relation enden und die nächste anfangen sollte. Zum Beispiel der Luisenplatz: Relation: ‪Luisenplatz‬ (‪4127339‬) | OpenStreetMap. Da stehen sowohl mitten auf dem Platz als auch rings um den Platz Wegweiser, die in die unterschiedlichsten Richtungen weisen (wer es nachvollziehen will, ich habe die Ziele erfasst, z.B. für diesen Wegweiser auf dem Platz: Waymarked Trails - Cycling. Theoretisch könnte man den ganzen Luisenplatz als einen riesengroßen Split Node interpretieren. Das halte ich dann aber definitiv für zu unübersichtlich.

  • Teilweise fand ich es zu umständlich, die Relationen wirklich an jedem Knoten zu unterbrechen. Zum Beispiel entlang der Breiten Straße habe ich daher eine zusammenhängende Relation erstellt (Waymarked Trails - Cycling). Zum Teil entstehen aber auch extrem kurze Relationen, zum Beispiel Waymarked Trails - Cycling.

  • Manchmal habe ich auf einem Way mehrere Relationen des Grundnetzes erfasst. Zum Beispiel überlagert sich diese Relation Waymarked Trails - Cycling mit anderen Relationen. Ich fand es aber auch nicht sinnvoll, sie noch weiter zu zerstückeln, weil sonst Anfangs- und Endpunkt in beiden Richtungen nicht mehr identisch wären.

  • Bei manchen Wegweisern ist nicht ganz klar, ob sie zu einem Einzelziel abseits des Grundnetzes weisen oder ob man die abzweigende Strecke als Teil des Grundnetzes verstehen sollte. So ist z.B. an dieser Kreuzung Node: 1256656382 | OpenStreetMap Richtung Süden als auch an dieser Kreuzung Node: 119689452 | OpenStreetMap nach Norden jeweils das Ziel „Fachhochschule“ ausgeschildert, sonst aber nichts weiter. Die Fernziele verlaufen jeweils über Ost-West-Routen entlang der Kiepenheuerallee bzw. der Pappelallee. Ist jetzt die Georg-Hermann-Allee zwischen diesen beiden Kreuzungen Teil des Radrouten-Grundnetzes oder sind das jeweils nur zwei Abzweige zu dem Einzelziel Fachhochschule?

  • An einigen Stellen ist die Wegweisung nicht symmetrisch aufgebaut. Zum Beispiel an folgender Stelle, wo ich die Routen bisher noch nicht eingetragen habe: Der Wegweiser Waymarked Trails - Cycling zeigt nach Norden über den Weg Way: 334825830 | OpenStreetMap Richtung Eiche, in Eiche gibt es an dieser Stelle aber keinen Wegweiser Richtung Süden. Umgekehrt zeigt der Wegweiser Waymarked Trails - Cycling Richtung Süden über Am Grünen Weg nach „Campus Neues Palais“ und „Zentrum“. Umgekehrt gibt es aber an der Kreuzung Am Grünen Weg / Lindenallee keinen Wegweiser Richtung Norden. Sollte man da jetzt zwei Relationen mit „signed_direction=yes“ anlegen? Das wäre übrigens auch ein Beispiel für eine Situation, wo das vermeintlich einfachere „lcn=yes“ direkt am Way die Situation nur unvollständig abbilden könnte.

+1 Das würde in Potsdam auch nicht funktionieren, gerade in der Innenstadt mit dem dichten Netz und nur wenigen immer gleichen Fernzielen, die ausgeschildert sind.

Das gibt es in Potsdam auch. Zum Beispiel hier (Foto ist von diesem Abzweig: Node: 3619751866 | OpenStreetMap):



Das Basis-Netzwerk (Wegweiser mit grünem Fahrrad) verläuft um die Ecke, während der “Gartenkulturpfad Inselrundweg” (Symbol gelbes Rad) geradeaus entlang der Havel weiterläuft. Die Strecken, auf denen schon Themenrouten erfasst sind, sind also nicht automatisch auch Teil des Radroutengrundnetzes.

2 Likes

Hallo,

Idee: Vielleicht sollten bei komplizierten Knoten die hier begonnenden/endenden Relationen schon an der ersten Verzweigung beginnen/enden. Alle Verbindungen innerhalb des Knotens kämen dann in eine eigene Relation.

Da der Knoten räumlich sehr begrenzt ist, wäre es auch nicht so schlimm, wenn da nicht alle Wegelinien innerhalb der Relation eine durchgehende Kette bilden. Man kann Lücken ja per Augenschein im JOSM erkennen, so dass man die durchgehende Kette nicht zwingend braucht. Vermutlich wird sich in vielen Fällen zumindest ein Kreis bilden lassen mit ein paar Abstechern.

Wäre das eine akzeptable pragmatische Lösung, wennd er Knoten zu komplex wird?

Brauchst du ja auch nicht. Im Proposal habe ich nur geschrieben:

Die Verbindungen werden so geschnitten, dass jede Verbindung aus einer durchgängigen Kette von Wege-Linien besteht, also ohne Verzweigungen

Damit ist es möglich, Verbindungen vor und hinter einer Kreuzung zusammenzufassen, solange es in der Relation weiterhin eine durchgehende Wegekette gibt. So kannst du die Anzahl der Relationen verringern. Es ist ja nicht wie beim Knotenpunktnetzwerk, wo Beginn und Ende einer Verbindung durch die Ausschilderung vorgegeben werden. Im Grundnetz haben wir da Entscheidungsspielraum.

Ich habe in den neuen Proposal-Entwurf einen erläuternden Satz dazugeschrieben, diese Möglichkeit erschließt sich sonst nicht sofort. (Das heißt aber nicht, dass ich die Diskussion in der Mailinggroup nochmal starten möchte.)

Ich denke man sollte da nicht päpstlicher als der Papst sein. Die Handhabbarkeit ist wichtiger. Zu viele und kleine Relationen sind da abträglich. Daher ja auch die Idee, mehrere hintereinander liegende Verbindungen möglichst in einer Relation zu erfassen.

Gibt es in beiden Richtungen Radwegweiser? Das würde ich als Indiz verstehen, den Abstecher als Verbindung des Grundnetzes zu betrachten. Bei längeren Abstechern kommt noch dazu, ob die Weigweisung in Ansätzen durchgehend ist. Das ist sie, wenn es z. B. Zwischenwegweiser an Unterwegskreuzungen gibt.

Auch hier bietet sich es an, den Abstecher als Verbindung in eine andere Verbindungs-Relation mit aufzunehmen. Wenn die Mitglieder der Relation weiterhin eine durchgehende Wegekette bilden entspricht es exakt dem Proposal.

Wenn das nicht gelingt, muss man m. E. nicht übergenau ein. Wegen eines kurzen Abstechers über vielleicht 3 Kanten würde ich nicht zwingend eine neue Relation aufmachen. Da würde ich auch eher in den sauren Apfel beißen, dass die Wegekette nicht durchgehend ist und den Abstecher in die durchgehende Relation mit aufnehmen. Bei den “Tentakeln” an komplizierteren Knoten machen wir das ja auch.

Das würde es m. E. unnötig kompliziert machen. Du kannst den Wegelinien in den Relationen die Rolle ‘forward’ und ‘backward’ geben. Wenn man die Linien entsprechend reiht wird das in JOSM auch sehr schön dargestellt. (‘forward’ = Die Radfahrer werden in Richtung der Wegelinie geführt.)

Ich würde auch eher „lcn=basic_network“ verwenden, denn sonst ist offen gelassen, ob da eine Radroute drüber verläuft oder nur das Grundnetz.

Passt das so für dich?

Danke @klnkengi für den anschaulichen Praxisbericht.

Es ist zwar nur selten genutzt, aber lcn:forward=yes bzw lcn:forward=basic_network (finde auch ich passender) könnte das schon vollständig darstellen.
https://taginfo.openstreetmap.org/keys/lcn%3Aforward#overview

Hm, in Einzelfällen wäre das vielleicht eine Lösung.

Für den Luisenplatz in Potsdam denke ich, dass ich jetzt eine ganz gute Variante gefunden habe: Ich habe alle Routen zu einem zentralen Punkt auf dem Platz geführt (Node: 10048754488 | OpenStreetMap) und die Wege am Rand des Platzes jeweils einer passenden angrenzenden Relation zugeschlagen.

Solange wir es etwas freier handhaben als beim Knotenpunktnetzwerk, weil sowieso nicht ganz klar definiert ist, wo eine Relation endet und die nächste beginnt, findet sich wahrscheinlich meistens eine Lösung. Wichtig finde ich Deinen Hinweis, dass wir da pragmatisch vorgehen sollten.

Ja, das ist gut. Ich habe in den letzten Tagen einige weitere Relationen ergänzt, bei denen ich das beherzigt habe. Im Nachhinein denke ich mir, dass ich gerade in der Innenstadt ruhig noch längere Abschnitte zu einer Relation hätte zusammenfassen können.

An der Kreuzung Georg-Hermann-Allee/Kiepenheuerallee gibt es Wegweiser mit dem Ziel “Fachhochschule” Richtung Süden und an der Kreuzung Pappelallee/Georg-Hermann-Allee gibt es Wegweiser mit dem Ziel “Fachhochschule” Richtung Norden. Dazwischen gibt es keine weiteren Wegweiser, aber der zwischen diesen beiden Kreuzungen liegende Straßenabschnitt ist ja auch ziemlich kurz.

Hier bin ich mir nicht sicher, ob ich Dich richtig verstehe. Es gibt Kreuzungen mit Hinweis auf ein Einzelziel, wo in Richtung des Ziels keine weitere Radroutenbeschilderung mehr folgt. Z.B. ist an der Kreuzung Node: 931650094 | OpenStreetMap in Richtung Osten “Campus Babelsberg 0,3 km” ausgeschildert, sonst gibt es aber keine weitere Wegweisung mehr. Der Weg Way: ‪August-Bebel-Straße‬ (‪24605616‬) | OpenStreetMap gehört damit nach meinem Verständnis überhaupt nicht zum Radroutennetz.

Anders an der direkt benachbarten Kreuzung Node: 931650094 | OpenStreetMap, wo nach Osten “Bhf. Griebnitzsee 0,4 km” ausgeschildert ist und es direkt am Bahnhof auch einen Wegweiser nach Westen gibt. Da gehört die Prof.-Dr.-Helmert-Straße natürlich schon zum Radroutennetz.

Ja, die Verwendung von “forward” bzw. “backward” ist klar. Ich wollte vor allem darauf hinweisen, dass manche Routen nur in einer Richtung ausgeschildert sind. Hier gibt es noch so einen Fall, wo es nur vom Uferweg in Richtung Zeppelinstraße eine Beschildergung gibt, aber nicht umgekehrt: Relation: 15988534 | OpenStreetMap

Ok, danke für den Hinweis. Ich habe trotzdem eine leichte Tendenz für die Verwendung von Relationen, weil sie m:E. übersichtlicher sind. Aber die Erfassung des Radroutengrundnetzes über lcn=basic_network direkt am Weg würde dann auch funktionieren.