Tl;dr

Dieser Beitrag erklärt, wie sich ein Radnetz, das durch Wegweiser ausgeschildert ist, in OSM abbilden lässt und wie ein Routing-Algorithmus diese Informationen nutzen kann.

Zunächst wird die Grundidee erläutert. Dann folgt ein Vorschlag zum EIntrag in OSM und die dafür erforlichen Tags auf Relationen, Ways und Nodes. Die erforlichen Rollen der Mitglieder der Relation und ihre Reihenfolg werden vorgestellt; dies schließt die Behandlung einiger Sonderfälle ein.

Eine mögliche Nutzung zum Routing auf diesem Radnetz und die dafür erforlichen Voraussetzungen wird diskutiert.

Grundidee

Die grundsätzliche Idee des Basisnetzes liegt darin, dass es miteinander verbundene Wege gibt, die jeweils von einem Kreuzungspunkt zu einem anderen Kreuzungspunkt führen und zusammen ein Netz bilden. Zu diesen Kreuzungspunkten gehören Wegweiser. Für Radverkehrsnetze sind dies Radwegweiser.

In OSM sind die Wegweiser als Node u.a. mit dem Tag information=guidepost abgebildet.

Wegweiser

An jedem Kreuzungspunkt steht mindestens ein Rad-Wegweiser, es können aber auch mehrere sein. Dies tritt in der Regel immer dann auf, wenn die Wegweiser die Form der Tabellenwegweiser haben.

Auf dem Wegweiser sind mindestens zwei Ziele angegeben und die Himmelsrichtungen der Ziele sind bekannt. Sie sind in der Form direction_* angegeben und bezeichnen 8 mögliche Himmerichtungen in 45° Grad-Schritten von northeast über east bis north in englischer Sprache. Siehe hierzu DE:Tag:information=guidepost – OpenStreetMap Wiki

Wege

EIn Weg bezeichnet in diesem Beitrag eine Verbindungen innerhalb des Radnetzes von Kreuzungspunkt zu Kreuzungspunkt. Er kann aus mehreren Teilstücken bestehen.

Die Wege sind in der Regel in beiden Richtungen befahrbar, also vom Anfang zum Ende und vom Ende zum Anfang. Der Hinweg führt vom Anfang zum Ende, der Rückweg vom Ende zum Anfang.

Teilstücke, die nur zum Hinweg oder Rückweg gehören nicht jedoch zu beiden, werden besonders gekennzeichnet.

Abweichungen von dieser Regel (wie z.B: für das Fehlen des Rückwegs) sind möglich und werden im Weiteren beschrieben.

Idee zum Eintrag des Netzwerkes in OSM

Der eintrag in OSM erfolgt über eine speziellen Relation.

Die Relation hat den Typ Route (type=route) und ist für Fahrräder gedacht (route=bicycle).

Um den Charakter als Netz darzustellen, werden zusätzlich die Tags network=lcn und network:type=basic_network genutzt. Hierzu gibt es ein inaktives Proposal von user JochenB.

So kann ein Routing auf diesem Netz zu erfolgen.

Anmerkung 1: Jede Kombination aus Anfang und Ende muss in genau einer Relation abgebildet sein.

Anmerkung 2: Dieser Vorschlag basiert auf der Idee von Sebastion (User Segubi), die Wege und Wegweiser in einer Relation mit dem Tag network:type = basic_network zu erfassen. Ich habe ihn ergänzt.

Tags der Relation

Es treten folgende Tags innerhalb der Relation auf:

• type: route (fester Bestandteil)

• route: bicycle (fester Bestandteil)

• network: lcn (fester Bestandteil)

• network:type: basic_network (fester Bestandteil)

• operator: (veränderlicher Bestandteil) Name des Betreibers als Zeichenkette, z.B. “Kreis Ostholstein”

• description: (veränderlicher Bestandteil) Beschreibung des Wegs in der Form “Radwegweisernetz: von <-> nach “, jeweils als Zeichenketten. Bei Wegen, die in beiden Richtungen befahren werden können steht “<->” zwischen Anfang und Ende, bei Wegen mit nur einer Richtung nur “->”. “Radwegweisernetz:”” sollte immer als unveränderlicher Bestandteil am Anfang vorhanden sein. Erfassende drücken hiermit aus, was sie erfassen wollten. Aus dieser Beschreibung können Daten zur Qualitätssicherung entnommen werden.

Mitglieder Relation

Die Mitglieder der Relation können Nodes für die Wegweiser und Ways für die Wege sein. SIe können/müssen in der Relation mit Rollen qualifiziert werden.

Die Mitglieder müssen in einer festgelegten Reihenfolge eingetragen werden.

Anmerkung: Die Bedeutungen der Rollen und der Reihenfolge der Einträge werden weiter unten erläutert.

Rollen der Mitglieder

Rollen für Wegweiser

Wegweiser müssen mit genau einer der beiden möglichen Rollen beschrieben werden.

• guidepost:direction_* mit Angabe einer Richtung, die von guidepost mit Doppelpunkt abgetrennt wird.
• guidepost ohne Angabe einer Richtung

Anmerkung: Die Angabe der Richtung in der Relation muss in den Angaben zu den Richtungen beim Wegweiser enthalten sein.

Rollen für Wege

In der Relation gibt es folgende Rollen für Mitglieder des Typs Weg:

• forward
• backward
• Die Rolle kann auch leer bleiben.

Reihenfolge der Mitglieder

Eine Auswertung der Relation erfordert, dass die Mitglieder identifierbar sind, und zwar als Wegweiser am Anfang, als Weg (mit seinen Teilstücken) und als Wegweiser am ende. Die Identifikation erfolgt durch die Reihenfolge der Mitglieder.

Die Einträge erfolgen in der Reihenfolge

• Alle Wegweiser, die am Anfang des Weges stehen, stehen auch am Anfang der Relation; mindestens jedoch einer

• Alle Teilstücke des Weges; mindestens eines

• Alle Wegweiser, die am Ende des Weges stehen; mindestens jedoch einer

Diskussion möglicher Fälle

Der einfachste Fall

 Der einfachste Fall und eine minimale Relation

Der einfachste Fall tritt auf, wenn ein einziger Weg zwei Armwegweiser verbindet.

Dann gibt es die minimale Relation mit drei Mitgliedern:

1. ein Node mit der Rolle guidepost:direction_* am Anfang
2. ein Weg (ohne Rolle)
3. ein Node mit der Rolle guidepost:direction_* am Ende

Der Regelfall

Der Regelfall ergänzt den einfachsten Fall um einen Weg aus mehreren Teilstücken.

• ein Node mit der Rolle guidepost:direction_* am Anfang
• erstes Teilstück (ohne Rolle)
• ….
• letztes Teilstück (ohne Rolle)
• ein Node mit der Rolle guidepost:direction_* am Ende

Anmerkung: Die Teilstücke sollten in der Reihenfolge angegeben werden, in der sie auf dem Hinweg durchfahren werden. Dies ist aber nicht zwingend erforderlich, um ein Routing zu ermöglichen. Ebenso sollten sie lückenlos sein, damit die Länge des Weges zutreffend berechnet werden kann.

Sonderfälle

Sonderfälle können bei Wegweisern und bei Wegen auftreten.

Sonderfälle bei Wegweisern

• Es stehen statt des Armwegweisers am Anfang oder Ende mehrere Tabellenwegweiser.

• Am Anfang eines Weges können mehrere Tabellenwegweiser stehen. Sie stimmen dann in der Angabe des Ziels für den Hinweg, der Entfernung und der Himmelsrichung überein. Sie bekommen jeweils die Rolle guidepost:direction_*. Derjenige Tabellenwegweiser, der nicht auf das Ziel des Hinwegs hinweist, aber am Ort des Anfangs steht, bekommt die Rolle guidepost ohne Richtung.

  Dies gilt entsprechend für Tabellenwegweiser am Ziel, nur dass es jetzt um die Zielangabe für den Rückweg geht.

• Die Angaben bei Armwegweisern sind über mehrere Wegweiser verteilt.

  Das Vorgehen erfolgt analog zu dem Vorgehen bei Tabellenwegweisern. Sie bekommen die Rolle guidepost:direction_*, wenn sie jeweisl für den Hin- oder den Rückweg auf Ziele hinweisen, sonst den Tag guidepost ohne Richtung.

• Hin- und Rückweg beginnen bzw. enden an unterschiedlichen Wegweisern. In diesem Fall sind bei Wege getrennt als Relationen zu erfassen, die alle Teilstücke (oder den einzigen Weg) mit der Rolle forward erfassen.

Sonderfälle bei Wegen

• Der Hin- und der Rückweg verlaufen über verschiedene Teilstücke. Die Teilstücke werden mit den Rollen forward für den Hinweg und backward für den Rückweg eingetragen. Sie stehen alle zwischen den Guideposts an Anfang bzw. am Ende. Siehe hierzu das Beispiel weiter unten.

• für den Fall dass die Führung des Weges beim Hin- und Rückweg keine Zusammenfassung über die Rollen forward und backward erlaubt, so müssen sie getrennt erfasst werden und alle Teilstücke bekommen die Rolle forward.

Beispiele für Relationen

Beispiel für den einfachsten Fall

Siehe hierzu auch die erläuternde Grafik für den einfachsten Fall im linken Teil (Weg von A nach B und zurück):

Die Grafik zeigt drei Wegweiser an den Orten A, B und C. Diese haben die Referenzen 1, 2 und 3. Ihre Wegweiser weisen in die Himmeldrichtungen Ost und West wie in der oberen Tabelle angeben. Die Ort sind durch zwei Wege mit den Referenzen 100 und 101 verbunden.

Der erste Eintrag in der oberen Tabelle liest sich z.B. so, dass in A ein Wegweiser steht, der in östlicher Richtung nach B weist.

Die schematische Darstellung der Relation zeigt für den Weg zwischen A nach B. Sie lässt sich für den Hinweg so lesen, dass der Wegweiser mit der Ref 1 ein Wegweiser ist (Rolle guidepost) und dass der Weg in östlicher Richtung abgeht, um nach B zu kommen (direction_east).

Für den Rückweg zeigt der Wegweiser mit der Ref 2 in westlicher Richtung um von B nach A zu kommen.

Beispiel für mehrere Wegweiser am Anfang des Hinweges

Die Grafik zeigt eine Kreuzung mit vier Tabellenwegweisern.

Die drei blau gefärbten Wegweiser (1, 3 und 4) in der Grafik haben alle dieselbe Zielangabe Richtung Osten, die bei dem gelben Schild (B) fehlt, da es nur Einträge nach Süden, Westen und Norden tragen kann.

Die zugehörige Relation zeigt für die Wegweiser am Anfang Tabelle:

Rolle	Typ	Ref
guidepost:direction_east	node	1
guidepost:direction_east	node	3
guidepost:direction_east	node	4
guidepost	node	2
	way	–

Beispiel für den Sonderfall einer getrennte Wegführung auf dem Hin- und dem Rückweg

Die schematische Grafik zeigt eine in der Mitte getrennte Wegführung:

Das Schema zeigt einen Weg von A nach B und zurück. Die gemeinsam genutzen Teilstücke haben die Referenzen 1001 und 1004. Das Teilstück mit der Referenz 1002 wird nur auf dem Hinweg befahren, das mit der Referenz 1003 nur auf dem Rückweg. Die zugehörige Darstellung in der Relation ist - mit den Wegweisern aus dem oben stehenden Beispiel:

Rolle	Typ	Ref
guidepost:direction_*	node	1
	way	1001
forward	way	1002
backward	way	1003
	way	1003
guidepost:direction_*	node	2

Idee für ein Routing

Grundsätzliches

Routing auf einem Netz erzeugt eine Reihenfolge von Knoten, die von einem Startpunkt zu einem Zielpunkt führen und dabei meist ein Kriterium geringster Kosten erüllt. Diese Kosten können im einfachten Fall durch die Länge des Weges vom Start zum Ziel gegeben sein.

Dabei wird vorausgesetzt, dass Radfahrende ziwschen den Wegweisern den Weg durch die Wegemarkierungen selbstständig finden können und nur an den Wegweisern Unterstützung benötigen.

Alternativen

Eine Alternative zum Routing durch ein Gerät wäre es, dass Radfahende vorab eine Route auf einer Karte suchen, die anzufahrenden Wegweiser auf Paiper in einer Reihenfolge zu erfassen (ähnlich der Reihenfolge der Knotenpunkte in einem Knotenpunktnetz) aund zu jedem Wegweiser aufzuschreiben, welchen Zielangaben jeweils zu folgen ist. Das ist möglich, wenn das Netz (also die Wege zwischen den Wegweisern) und die Wegweiser selbst mit den erforderlichen Informatioen erfasst sind. Eine Brechnung der Länge des Weges und die Optimierung müsste dann durch die Radfahrenden erfolgen, z.B mit der Hilfe von BRouter-Web. Das alles ist aber ziemlich mühsam und wird wahrscheinlich selten genutzt.

Eine weitere Alternative beseht in der Nutzung bekannter Navigationsprogramme wie OSMAnd, Komoot oder ähnlicher. Diese Programme berücksichtigen aber eine vorhandenes Radwegwegweisernetz nicht (außer vielleicht BRouter), sondern orientieren sich an Merkmalen der Wege, etwa dem Vorhandensein eines Radweges. Dies kann dazu führen, dass eine Route entlang einer viel befahrenen Bundes- oder Landestraße vorgeschlagen wird, obwohl ein ausgeschilderter WEg abseits großer Straßen vorhanden ist, der aber etwas länger ist.

Schritte zum Routing auf dem Radwegweisernetz

Die Idee für ein geräte-gestütztes Routing auf dem beschriebenen Radwegwegenetz besteht aus den folgenden Schritten:

Erfassen des Radwegenetzes in OSM wie beschrieben mittels der Relationen. Die Wege und Wegweiser müssen naturgemäß mit allen erfoderlichen Informationen erfasst worden sein.

Download der Daten aus OSM, das z.B. über overpass-turbo.eu erfolgen kann . Der Link zeigt eine geeignete Abfrage für den Kreis Ostholstein. Der Stand der Erfassung ist 2023-08-25.

Transformation der Daten in ein Format, das durch einen Routing-Algorithmus wie z.B. den A-Algorithmus]([A-Algorithmus – Wikipedia) erfolgen. Es gibt für viele Programmiersprache Implemtierungen des Algorithmus.

Der A*-Algorithmus nutzt ein Netz aus Knoten und Kanten. Die Knoten sind

Implementierung des Algorithmus in einer gewählten Programmiersprache (z.B. Kotlin) für eine gewählte Betriebssystem(z.B. Android) auf einem gewählten Gerät (z.B. Smartphone)

Nutzung des Algorithmus beim Radfahren. Dabei sind folgenden Interakationen zu betrachten:

• Die Wahl des Start- und des Zielpiunkts sind unabdingbar, eine Unterstützung durch eine Anzeige auf einer Karte erscheint wünschenswert.

• eine Lokalisierung des aktuellen Standorts und die Darstellung auf einer Karte ist hilfreich,

• eine Darstellung der berechneten Route mit Angaben zu Entfernung und Dauer sind hilfreich

• Angaben zum Abbiegen an Kreuzungspunkten, die eine zugehörige Zielangabe habe (z.B. A-Stadt) und eine Angabe der Entfernung (in km). Dies kann durch eine Angabe der Himmelsrichtung ergänzt werden sowie eine lokale Karte. Die Angabe von Ziel und Entferung kann mittels Umwandlung von Textt in Sprache auch über Audio-Funktionen erfolgen.

Abschließende Bemerkungen

Dieser Beitrag macht einen Vorschlag für die Nutzung von Daten in OSM, der die analoge Welt der Straßen und Wegweiser mit der digitalen einer Anwendung auf mobilen Geräten verbindet. Eine solche Verbindung gibt es nach der Kenntnis des Autors bisher nicht.

Die bisher erfolgte Erfassung von Basisnetzten für Radfahrende erfolgt in Relation, die viele Wege erfassen, aber keine Wegweiser z.B. im Osnabrücker Land mit 793 Mitgliedern (Stand 2023-08-24). Oder die Routen werden getrennt von den Wegweisern erfasst, obwohl in dem Bereich viele Radwegweiser (allerdings ohne Zielangaben) eingetragen wurden.

Der [Autor]([Jens-Uwe_Hagenah

OpenStreetMap](https://www.openstreetmap.org/user/Jens-Uwe_Hagenah)) freut sich auf Kommentare zu seinem Beitrag.