Vorgehen bei erfassen von lokalen Radwegenetz

Ich möchte in meiner Gegend das lokale Radwegenetz erfassen.
Beschilderung ist hier bei uns mit der grünen Radwegsbeschilderung.
Ich würde nun die Radwege abfahren, als Orientierung für das Abfahren die Karten des Kreises/der Stadt hernehmen.
Wie ich jetzt vorgehen würde:

  • Erstellen einer Master-Relation für z.B. den Landkreis.
    Tags: type=network; network=lcn; name= Radwegenetz Landkreis Aschaffenburg; operator=Landkreis Aschaffenburg
  • Mitglieder der Master-Relation wären dann Relationen der Wegstücke. Beispiel die Strecken die ich erfassen möchte.
    => Ist es richtig, dass dann, sobald sich zwei Wege treffen, eine neue Relation erstellt werden soll?
    Tags: type=route; route=bicycle (mehr nicht oder?)
  • Wohin mit den Wegweisern? Die stehen ja in der Regel an einem Treffpunkt von zwei Wegen. Sind die dann Mitglied bei beiden Wegstücken?

Um evtl. bereits erfasste Strecken zu finden und eventuell das tagging zu korrigieren

  • overpass-Suche nach Wegen mit lcn=yes
    nach Überführung in eine Relation das lcn=yes dann löschen
  • overpass-Suche nach route=bicycle
    evtl. bereits vorhandene Relationen in die Master-Relation stecken und deren Tagging verbessern, Themenrouten natürlich bestehen lassen.
    Beispiel 1 Relation 4019219, Beispiel 2 Relation 13293825, Beispiel 3
    => Beispiel 3: name, from und to ist doch unnötig? network:type ist auch falsch?

Gibt es Musterbeispiele in dem ein Radwegenetz in einem Landkreis/Stadt “perfekt” erfasst worden ist, an dem ich mich orientieren könnte?

Beispiele für Radverkehrsnetze, z. B. das von Bielefeld, finden Sie auf dieser Website. Loggen Sie sich mit Ihrer OSM-ID ein und Sie sehen weitere Details.

Beispiele für einer Master-Relation, Routen und Knoten sind auf dieser Website zu finden.

Ihr Netzwerk wird automatisch in die Website aufgenommen, sobald Sie die Master-Beziehung (ordnungsgemäß) erstellt haben.

Wenn Sie expected_rcn_route_relations zu den Knoten hinzufügen, zeigt die Website auch einen guten Überblick darüber, was noch fehlt.

Siehe auch DE:Tag:network:type=node_network

Hallo Maskulinum,

Bin auch ein sehr aktiver Radwege-Mapper und beantworte deine Fragen mal so, wie ich vorgehe.

Erstellen einer Master-Relation für z.B. den Landkreis

Das ist eher keine gute Idee. Wurde früher vielleicht das ein oder andere Mal gemacht, aber solche Sammelrelationen verwahrlosen in der Regel und sind meistens veraltet. Ich empfehle dir eher an den einzelnen Routen-Relationen das Tag cycle_network= zu verwenden. In deinem Fall würde cycle_network=DE:BY:AB für Aschaffenburg passen.

Ist es richtig, dass dann, sobald sich zwei Wege treffen, eine neue Relation erstellt werden soll?

Ja, ist eine gängige Vorgehensweise und mache ich auch so. Eine Routen-Relation ist dann die Verbindung zwischen zwei Wegweisern mit jeweils 3 oder mehr Richtungsangaben.

Tags: type=route; route=bicycle

Das sind zumindest die notwendigen Tags, oft fügt man z.B. noch eine Beschreibung von wo nach wo die Route verläuft mittels note= ein. Und wie oben geschrieben würde ich cycle_network= empfehlen. Es gibt natürlich noch einige weitere optionale Tags, siehe zum Beispiel eine von mir hinzugefügte Routen-Relation.

Wohin mit den Wegweisern?

Ich füge sie immer in die jeweiligen Routen-Relationen mit ein.

Gibt es Musterbeispiele in dem ein Radwegenetz in einem Landkreis/Stadt “perfekt” erfasst worden ist, an dem ich mich orientieren könnte?

In BW habe ich schon in einigen Regionen das Radwegenetz flächendeckend und einheitlich erfasst, siehe z.B. der Link oben.

Es gibt aber auch im Wiki ein paar Hilfeseiten, z.B. DE:Bicycle/Radverkehrsnetze kartieren.

2 Likes

Sorry, nicht gewollt… @Moderation, bitte wiederherstellen. Es war ein Fehlklick!!

1 Like

wiederhergestellt

PS: mit @mods-germany klappt es etwas direkter…

Welche Anwendungen seht ihr in dieser Datenerfassung? Geht es um die Darstellung auf Karten, dem Verwenden im Routing oder etas auf das ich nicht komme?

Ich poste noch einmal hier mit Verweis auf eine etwas übergeordnetere Betrachtungsweise. Ich glaube nicht, dass sich im Rahmen des allgemeinen Netzwerkes überhaupt noch sinnvoll von einem “lokalen Radwegenetz” sprechen läßt, da es im Prinzip deutschlandweit eine gemeinschaftliche Wegweisung gibt, und gerade Ferntouren über die teilweise als lokal bezeichneten Wege führen.

Es gibt noch einige ungeklärte Fragen, wie allgemein das aktuelle deutsche Radwegenetz erfaßt werden könnte - und das beinhaltet das hier thematisierte “lokale Radwegenetz”.

Ich habe eine neues Thema dazu aufgemacht, in der Hoffnung, dass die Diskussion etwas gebündelt wird: https://community.openstreetmap.org/t/reprasentation-des-aktuellen-offiziellen-deutschen-radverkehrsnetzes-nach-den-vorgaben-der-fgsv-in-osm/4805

Grüße,

Sebastian

2 Likes

Normalerweise zeigen Karten den Verlauf einer Route als Abfolge von Wegen an, die sich von Knoten zu Knoten erstrecken.
Sebastian hatte hierzu auf die Knotenpunktnetzwerke hingewiesen. Ebenso erstellen Routing-Apps eine solche Abfolge von Strecken, die vom Start zum Ziel führen. Dazu benötigen beide das Mappen der Routen über entsprechende Tag, um bei einer Straße oder einem Pfad zu entscheiden, wie sie dargestellt werden, bzw. ob sie in die Route aufgenommen werden sollen.
Dabei ist in der Darstellung in der Karte meist nicht unterscheidbar, ob Hin- und Rückweg identisch sind bzw. ob nur einer von beiden existiert. Und für das Routing müssten erst die in der Nähe der Start- und Zielpunkte gelegenen Wegweiser daraufhin untersucht werden, ob sie etwas mit der Route zu tun haben und tatsächlich eine Weg entlang der Route anzeigen. Ich versuche seit langer Zeit dafür eine algorithmische Lösung zu finden, aber bin bisher gescheitert. Aber ich habe in meiner Umgebung auch noch keine Wege, die gemäß Sebastians Vorschlag gemappt sind.
Ich möchte nun zur Diskussion stellen, ob ein unabhängiges Erfassen der Beziehungen zwischen den Wegweisern nicht ausreichend wäre. Denn die Radwegweisung ist ja so ausgelegt, dass Radelnde zwischen den Wegweisern Zwischenwegweiser vorfinden, die ihnen den weiteren Verlauf anzeigen. Dann wäre nur zu erfassen, welcher Wegweiser an Start steht, welcher am Ziel und wie groß die Entfernung zwischen beiden ist.
Für die Gegenrichtung, falls sie existiert, wäre eine eigene Erfassung erforderlich, da sie durch eine abweichende Streckführung eine andere Länge haben kann.
Dies würde, IMHO, sowohl für Knotenpunktnetzwerke als auch für solche mit Zielangaben funktionieren.
Split-Nodes (oder mehrere Tabellenwegweiser an einer größeren Kreuzung) wären keine Schwierigkeit, denn sie treten nur an der Startposition auf, dort können sie für ein Ziel in einer Liste zusammengefasst werden, denn ihre Ziel- und Entfernungsangaben müssen/sollten definitionsgemäß identisch sein. Auch bei Split-Nodes am Ziel gibt es dort immer nur einen Wegweiser an dem diese Teilstrecke endet und wo eine neue beginnt.
Die anzuzeigenden Zielangaben kann die App aus den übereinstimmenden Zielangaben an Start und Ziel entnehmen, da diese definitionsgemäß fortgeführt werden (sollen?).
Eine weitere Diskussion könnte dann auch Fragen von Fehlern in der Anlage der Wegweisung und Fälle von Vandalismus aufnehmen. Zu diesen anlegten Fehlern gehören u.a. unterschiedliche Routen die Wege teilweise gemeinsam nutzen oder sich kreuzende Routen ohne entsprechenden Knoten.
Die Aufnahme des Tags network:type=basic_network in das Schema halte ich für sinnvoll, um die Verbindung zum Mappen der Routen herzustellen.

Vielleicht kopierst Du den Post (teilweise?) noch hierher? Repräsentation des aktuellen offiziellen deutschen Radverkehrsnetzes (nach den Vorgaben der FGSV) in OSM An der Stelle habe ich auch etwas dazu kommentiert, weil auch ein anderer User sich zu den Guideposts geäußert hat. Im Prinzip finde ich den Ansatz gut.

Grüße,
Sebastian

Hallo Sebastian,
dein Wunsch ist umgesetzt.
Grüße
Jens-Uwe

1 Like

Ich habe seit meinem letzten Beitrag zu diesem Thema weiter an meiner Vorstellung einer Kennzeichnung gearbeitet. Das Ergebnis kann z.B. hier, hier und hier betrachtet werden. Die Relationen enthalten jeweils die Wegweiser als role:guidepost am Anfang und Ende der Relation. Dabei muss jeweils mindestens ein Wegweiser an jeden Ende stehen, es können aber auch mehrere sein. Letzteres ist insbesondere bei Tabellenwegweisern der Fall. Dazwischen befinden sich die Wege, hierbei können die rollen forward und backward vergeben werden, sie kennzeichnen dann die Wege, die nicht identisch auf den Hin- und Rückweg sind. Ihre Richtung bezieht sich dabei immer auf die Richtung der Relation siehe hierzu die Relation 14956019 in Richtung Norden.
Auswertenden Programme können so die Route auf einer Karte darstellen und Routing-Anwendungen auch über die Wegweiser geführt werden.

Sehr schön, das sieht doch gut aus.
Nur eine Kleinigkeit: Könntest Du die Nummer der Wegweiser bitte nicht mit “lcn_ref”, sondern mit “ref” eintragen? “lcn_ref” bzw. “rcn_ref” steht für die Nummer des Knotenpunktes bei einer Knotenpunktwegweisung (siehe https://wiki.openstreetmap.org/wiki/DE:Key:lcn_ref). Auf der Radfahrerkarte werden die Wegweiser jetzt auch alle so gerendert, als ob es sich um Knotenpunkte handeln würde.

1 Like

@klnkengi : Es freut mich, dass der Vorschlag sinnvoll erscheint.
Du schlägst vor, ref statt lcn_ref zu verwenden. Ich kann dem folgen, aber ich wüsste gern, ob du mögliche Kollisionen mit anderen Tags siehst, die auch ref verwenden. Dies könnte dann zutreffen, wenn an einer Straßenlaterne auch ein Wegweiser hängt. Dann kämen sich (in den seltenen Fällen) die Refs der Lampe und des Wegweisers ins Gehege. Wenn beide getaggt sind, indem z.B. beide durch Semikolon getrennt eingetragen werden, ist die Unterscheidung, welcher Ref zu welcher anderen Tag gehört, schwierig. Daher hatten wir uns früher für lcn_ref entschieden. Die Frage ist nun ist das ein Problem des Renderers oder des Taggings? Eine Lösung bestünde auch darin, in solchen Fällen zwei Nodes für die Lampe und den Wegweiser einzutragen. Was denkst du?

Wenn Namenskollisionen drohen, dann lieber zwei Knoten.
Mittelpunkt der Lampe und des Schildes sind ja eigentlich ein paar Zentimeter auseinander und es sind auch zwei unterschiedliche Objekte.

So habe ich das bisher auch immer gemacht.

Manchmal sind am selben Laternenmast ja auch noch Mülleimer oder weitere Elemente angebracht, dann wird es erst recht schwierig, alle Infornationen im selben Node unterzubringen

Guten Abend,

ich habe heute einen Hilferuf von @TheNet1996 als PN bekommen bezüglich eines derzeit erfassten lokalen Fahrrad-Netzwerkes als Sammelrelation. Im Detail handelt es sich um die Relation Radverkehrsnetz Kreis Landsberg am Lech

Für mich typische alte Radwege-Sammel-Relation…

Das Problem ist hier, daß ob der Größe das Monsters z.B. mit iD nicht mehr bearbeitbar ist…

Ich erinnerte mich gleich an das Proposal von @JochenB : https://community.openstreetmap.org/t/proposal-wander-radweg-ggu-anderen-wege-mit-wegweisern-hervorheben/92851

Im Prinzip trifft es doch genau das…

Ich habe ihm geraten, das o.g… Monster im Sinne des Proposals in Verbindungsrelationen mit entprechenden Tags zu zerlegen. Das wird sicher noch etwas dauern. Ungeachtet dessen hatte er das wohl bereits angrenzend gemacht, ohne jedoch Kenntnis von network:type=basic_network zu haben… Das ändert sich nun…Mit einer Quick&Dirthy-Abfrage hat er nun von mir ein schnelles Werkzeug bekommen zum Nachtragen…

Fragen, Kommentare, Meinungen?

Ich glaube, über fundierte Hilfe im Sinne von PN und/oder beim Mapping vor Ort wäre er sicher nicht abgeneigt…

Viele Grüße,

Sven

Nachtrag: wenn man sich diesen ganzen Zusammenhang im Detail betrachtet, so ist für mich network:type=basic_network nur die logische Folge von network:type=node_network. Weitere Folgen für mich: eine direkte Angabe von network=lcn|rcn|undso dürfte an diesen Verbindungsrelationen mittelfristig obsolet werden, sei es basic_network oder node_network…

2 Likes