Radwegenetze

Neben ausgeschilderten Radwanderwegen und Radrouten gibt es in Deutschland in den meisten Regionen auch ausgeschilderte Netze fuer Radfahrer, die die komplette Region (meist ein Landkreis) abdecken. In den letzten Wochen habe ich mir in vier verschiedenen Kreisen in drei Bundeslaendern die Beschilderungen naeher angeschaut. Sonderlich sinnvoll scheint mir das nicht, was ich vorgefunden habe, aber das ist ja kein Grund, die Sachen nicht in die OSM-Datenbank aufzunehmen. (Und wenn es auch nur ist, damit potentielle Nutzer rechtzeitig erkennen, wie unsinnig die Netze haeufig sind.)

Wie immer bei OSM gilt auch hier: Die Daten koennen nur genutzt werden, wenn man sich auf eine halbwegs einheitliche Darstellung in der Datenbank einigen kann, was Ziel dieser Diskussion sein soll:

Meiner Erfahrung nach sind die Hauptelemente von den Radwegnetzen Wegweiser, die jeweils an den Punkten stehen, an denen sich die Netze verzweigen. In den folgenden Bildern sind Beispiele fuer solche Wegweiser abgebildet, die mir in den verschiedenen Kreisen begegnet sind:

http://wiki.openstreetmap.org/wiki/Image:Radwegnetz_Bremen_Wegweiser.jpg
http://wiki.openstreetmap.org/wiki/Image:Radwegnetz_Verden_Wegweiser.jpg
http://wiki.openstreetmap.org/wiki/Image:Radwegnetz_Storman_Wegweiser.jpg
http://wiki.openstreetmap.org/wiki/Image:Radwegnetz_Lauenburg_Wegweiser.jpg

Fuer Wegweiser gab es das Tag amenity=signpost. In der Zwischenzeit ist es zwar das dazugehoerige Proposal aus mir unerfindlichen Gruenden auf rejected gesetzt und das Tag wieder aus den Mapfeatures entfernt worden, zum brauchbaren Erfassen der Radwegnetze scheint mir etwas Entsprechendes aber unverzichtbar. Im Wiki scheint nun heute information=guidepost die bevorzugte Variante zu sein. Was auch immer, Hauptsache man einigt sich irgendwie.

Analog zu den Radwanderwegen sollte man die Radwegnetze mit einer Hierachie (network=lcn) und einem Operator kennzeichnen (operator=Landkreis Verden). Ob diese Tags an den einzelnen Wegweiser angebracht werden sollten, oder aber an Relationen, die die kompletten Netze zusammenfassen, waere noch abzuwegen. Im zweiten Fall muessten dann die Wegweiser natuerlich auch Mitglied einer entsprechenden Relation sein.

Ausserdem scheint es mir sinnvoll zu sein, an jedem Wegweiser die ausgeschilderten Richtungen und Entfernungen einzutragen. Zum einen ist diese Angabe notwendig, weil meiner Erfahrung nach die Angaben auf den Schildern nur sehr bedingt mit den dazugehoerigen Teilrouten korrelieren. Zum anderen koennen diese Angaben helfen, Erfassungluecken in den Netzen zu erkennen (ausgeschilderte Richtungen, ohne dazugehoerige Teilrouten).

Mein Vorschlag ist, alle Ziele in eine Richtung zusammenzufassen, und diese jeweils anhand der groben Himmelsrichtung north, northeast, east, …) in die Datenbank aufzunehmen. Das wird dann in der Praxis wie folgt aussehen:
direction_west=Reinbek 8.0km; Ohe 3.5km

Ausserdem sind die einzelnen Wegweiser u.U. durchnummeriert (siehe http://wiki.openstreetmap.org/wiki/Image:Radwegnetz_Lauenburg_Referenz.jpg)), eine solche Kennzeichnung koennte man als ref=0655 eintragen.

Ausser den Wegweisern an den Abzweigstellen bestehen die Radwegnetze noch aus dem Streckenverlauf zwischen diesen Punkten. Soweit ich es gesehen habe, wird dies ueblicherweise durch einfache Zwischenwegweiser angezeigt:
http://wiki.openstreetmap.org/wiki/Image:Radwegnetz_Lauenburg_Zwischenwegweiser.jpg

Diese Streckenabschnitte sind sinnvollerweise ueber Relationen in der OSM-Datenbank zu erfassen, deren Mitglieder die einzelnen Wege sind. Die Teilstrecken koennte man ueber die ueblichen route-Relationen erfassen. Das hat aber den Nachteil, dass die doch recht weit verbreiteten Radwegnetze sich nicht von den Radwanderwegen unterscheiden lassen und letztere somit deutlich schlechter zu erkennen sind.

Ausserdem ist zu ueberlegen, ob man jeden Streckenabschnitt in einer einzelnen Relation erfassen sollte, oder aber ob eine Relation fuer das gesamte Netzwerk sinnvoller ist. Im ersten Fall koennte man die Relation entsprechend der Ausschilderung an den Wegweisern an den Endpunkten markieren (z.B. im name-Tag). Soweit ich gesehen habe, sind an einem Wegweiser aber durchaus vier verschiedene Ziele in einer Richtung angegeben, das wuerde dann fuer den Streckenabschnitt fuer beide Richtungen zusammen eine Bezeichnung aus bis zu acht Ortsnamen ergeben, was mir nicht wirklich praktikabel erscheint.

Wenn man die Streckenabschnitte nicht einzel erfassen will, sondern nur gesammelt in einer einzigen Relation, dann sollte man auf alle Faelle einen neuen Typ dafuer erfinden (z.B. type=network), denn die weit verbreiteten route-Relationen sind sicherlich fuer was anderes gedacht als fuer komplexe Netzwerke (entsprechend sind auch die Tools z.B. in JOSM oder der Relation-Checker ausgelegt).

Wir seht ihr die Sache im Allgemeinen? Wie ist eure Meinung zu den von mir offen gelassenen Fragen?

Wenn man sich hier auf einen roten Pfaden einigen kann, dann wuerde ich eine entsprechende Seite im Wiki anlegen.

Gruss
Torsten

Hey.

Finde ich ne super Idee.
Kann dir leider keine wirkliche Hilfe sein, aber alles was du aufführst halte ich für vollständig.
Gerade für die Wegweisen halte ich für sehr wichtig.
Ich kenn es auch nur als information=guidepost, wobei ich mich eigentlich zu 80% auf JOSM verlasse.

Gruß

Hallo,

für NRW hatte man sich hier schon mal Gedanken gemacht:
http://wiki.openstreetmap.org/wiki/Radverkehrsnetz_NRW
nachdem die Erfassung aller beschilderten Wege in einer landesweiten Relation an Datenbankkonflikten gescheitert war.

Mittlerweile gibt es für jeden Landkreis eine rcn-Relation, in der erstmal die beschilderten Wege erfasst werden.
Zusätzlich natürlich noch die benannten Themenrouten.

Für die Radregion Münsterland gibt es ein Wabensystem, in dem jede nummerierte Wabe eine Relation hat, sodass jedes Wegstück von zwei Wabenrelationen bedient wird.

Knotenpunktnetzwerke gibt es in den Niederlanden und in den Kreisen Heinsberg und Aachen, hier hat jeder Wegweiser eine groß aufgemalte Nummer, und die Wegabschnitte kann man mit X-Y als Relation erfassen.

Ich meine, je nach Ausschilderungssystem sollte man sich zwischen den drei Alternativen entscheiden können.

Die Wegweiser in NRW sind als tourism=information information=guidepost getaggt (weil es da in josm ein schönes Symbol für gibt), die Knotenpunkte in den Niederlanden haben nur ein rcn-ref tag, welches aber in der Cycle Map entsprechend dargestellt wird.

Gruß,
ajoessen

Ich hatte irgendwann mal eine Diskussion dazu gelesen. Also Wegweiser auf einer Landkarte darzustellen, ich weiß ja nicht. Die meisten Leute haben dem auch wohl widersprochen. Zudem führen bei uns in der Gegend die Wege überall hin, jedoch nie direkt ans Ziel. Wären die Wege selbst sehenswert, so könnte man für die Wege eine Route (Relation) bauen, jedoch nicht die Punkte dazwischen als Wegweiser markieren. Es gibt wichtigere Dinge zu mappen wie z.B. Gewässer oder Wälder auf dem Weg.

Routen zwischen Knotenpunkte werden auch in Relationen gefasst, und ebenso alle Knotenpunkte selber:

http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging

Das die Wegweiser in die Datenbank eingetragen werden, bedeutet j anicht zwangslaeufig, dass sie auch auf Karten dargestellt werden muessen.

Alleine schon als Hilfsmittel, um leichter erkennen zu koennen, wo noch Teile des Netzes fehlen, finde ich die Wegweiser in der Datenbank sinnvoll.

Das ist fuer mich der Hauptgrund, um die Wegweiser im Rahmen der Radwegnetze zu erfassen: Die einzelnen Teilabschnitte fuehren nicht wirklich zu irgendwelchen Zielen, sondern sie stellen bloss Verbindungen zwischen den Knotenpunkten her. Ohne diese Knotenpunkte, die sich alleine durch Position der Wegweiser ergeben, liegen die Teilanschnitte haeufig scheinbar willkuerlich in der Gegend.

Gruss
Torsten

Moin,

die Vorlagen/Referenzen aus NRW und den Niederlanden bieten verschieden Moeglichkeiten Radwegnetze abzubilden, was mal wieder das uebliche OSM-Problem der fehlenden Einheitlichkeit zeigt. Wahrscheinlich sind die einzelnen Radwegnetze einfach so unterschiedlich, dass man nich alle komplett gleich behandeln kann, aber eine grobe Vorgabe fuer die Richtung waere schon nicht schlecht.

Der Ansatz aus den Niederlanden laesst sich leider nicht eins zu eins umsetzen, weil in den von mir untersuchten Netzen die Knotenpunkte nicht so betont werden. Z.T. sind den Wegweisern zwar Ordnungszahlen zugewiesen, aber die finden sich eher im Kleingedruckten und sind nicht als Erkennungsmerkmal gedacht. Und in mindestens einem Netz sind die Wegweiser gar nicht selber gekennzeichnet, so dass man sie auch nicht als Basis fuer eine Benamungsschema nutzen kann.

Ausserdem stuetzen sich die Vorlagen immer auf route-Relationen als Grundlage. Wie es auf den Seiten im Wiki bereits erkannt wurde, hat dies aber zur Folge, dass dadurch eine Unterscheidung zu den “echten” Routen fehlt, und somit alle Radwanderwege in den Radwegenetzen untergehen.

Das gesamte Netzwerk kann man ja in einer Ueber-Ralation fuer Typ network erfassen. Entsprechend wird ja auch bei den Verkehrsverbuenden vorgegangen, wo es eine Relation fuer den Verbund gibt, in der die einzelnen Linien dann Mitglied sind. Analog koennte man die Teilabschnitte des Radwegenetzes dann als Routen erfassen, und die Wegweiser aehnlich den Haltestellen mit in die Relation aufnehmen. Es bleibt dann aber immer noch das Problem der Unterscheidung von eigenstaendigen Radrouten.

Gruss
Torsten

Moin,

ich habe das jetzt mal Beispielhaft fuer eine Ecke umgesetzt.

Fuer das Radwegenetz im Landkreis Verden habe ich die Relation 373530
(http://www.openstreetmap.org/browse/relation/373530/history) mit den folgenden Tags angelegt:

type=network
network=lcn
name=Radwegenetz Landkreis Verden
operator=Lankreis Verden
route=bicycle

Das Tag route=bicycle gehoert eigentlich nicht in die network-Relation, aber z.Z. wuesste ich keinen besseren Weg, um auszudruecken, dass es sich hierbei um eine fahrradspezifische Relation handelt. Das steckt zwar auch im network=lcn drin, das alleine finde ich aber ein bisschen kryptisch.

In diese network-Relation habe ich nun die einzelen Kanten des Radwegenetzes (die Verbindungen zwischen den Wegweiser-Knotenpunkten) als route-Relationen getan, So z.B. die Relation 373690 (http://www.openstreetmap.org/browse/relation/373690). Diese Relation hat die folgenden Tags:

type=route
route=bicycle
network=lcn
operator=Landkreis Verden
name=Fischerhude - Oyten

Die Tags network und operator sind eigentlich bei der Route ueberfluessig, da sie ja bereits in der network-Relation gesetzt sind. Da ich aber nicht weiss, wie gut die verschiedenen Auswerteprogramme mit Relationen von Relationen zurecht kommen, habe ich sie vorerst bei den Routen explizit angegeben.
Am schwierigsten ist die Sache mit dem name-Tag. Ohne ein solches Tag geht es nicht, man verliert sonst viel zu schnell die Uebersicht zwischen den einzelnen Routen.
Die Kanten stellen ja die Verbindung zwischen zwei Wegweisern dar, so dass man sie theoretisch darueber gut identifizeiren koennte. Zum einen haben die Wegweiser aber nicht in allen Netzen eigene Kennungen (Referenznummern), zum anderen sind diese Referenznummern wenn vorhanden so nichts sagend, so dass sie einem Nutzer der Karten nicht weiter helfen wuerden.
Mein erster Ansatz war dann, selber Namen/Beschreibungen fuer die Wegweiserpunkte zu vergeben. Das war aber dann doch zu willkuerlich, um das allgemein so zu handhaben.
Als Loesung habe ich nun die Beschilderung auf den Wegweisern als Grundlage fuer die Routenbennenung benutzt. Die Route ergibt sich ja dadurch, dass an ihren beiden Enden Wegweiser zu Zielen in Richtung der Route zeigen. Fuer die Benneung der Route habe ich nun einfach immer das am weitesten oben angegebene Ziel genommen. Die beiden Ziele (von jedem Ende eines) sind dann alphabetisch sortiert und durch Leerzeichen, Minuszeichen und noch ein Leerzeichen getrennt (Damit man erkennen kann, dass es zwei Orte sind und nicht ein Ortsnamen mit Bindestrich).
Falls es fuer eine Route keine Ausschilderung in der Gegenrichtung gibt, so wird einfach nur ein Name angegeben (im obigen Beispiel waere das dann name=Fischerhude).
Falls man nicht weiss, was am anderen Ende der Kannte auf dem Wegweiser steht, aber trotzdem schon mal ein Stueck der Kannte erfassen will, so laesst man einfach den zweiten Namen weg, behaelt aber das Trennzeichen bei (im obigen Beispiel ware das dann name=Fischerhude - ).
Falls eine Kannte an der Grenze des Netzes endet (meist eine Kreisgrenze), so wird bei der Namensfindung einfach der naechste wegweiser im Nachbarnetz verwendet (falls vorhanden.)

Dieser Ansatz hat die folgenden Vorteile:

• Fuer jede Kante ergibt sich ein deterministischer Name.
• Die Namen der Kanten sind auch hilfreich fuer jemanden, der unterwegs mit einer Karte eine Route abfahren will, denn am Kanntennamen erkennt er ja, welchen Richtungsschildern er folgen muss.

Natuerlich ist nichts perfekt, so hat auch dieser Ansatz seine Nachteile:

• Der Name der Kante ist etwas irrefuehrend. Denn obiges Beispiel fuehrt nicht komplett vom Ort Fischerhude zum Ort Oyten, sondern die route-Relation markiert nur einen kleinen Streckenabschnitt zwischen den beiden Endpunkten.
• Die Namen der Kanten sind nicht eindeutig. So kann es zwischen den Orten Fischerhude und Oyten mehrere Kanten im Radwegenetz geben, die aufgrund ihrer beschilderung den selben Namen erhalten.

Wenn gleichnamige Kanten direkt aufeinander folgen, so kann man sie sehr gut in einer gemeinsamen Relation erfassen, z.B. Relation 373662 (http://www.openstreetmap.org/browse/relation/373662).
Wenn aber zwei gleichnamige Kanten parallel zueinander verlaufen, dann gibt es nach diesem Schema halt leider zwei Relationen mit dem selben Namen. So gibt es neben der Relation 373662 auch noch die Relation 373529 (http://www.openstreetmap.org/browse/relation/373529) mit dem Namen Oberneuland - Osterholz.

In den route-Relationen sind nicht nur die Verbindungswege von einem Wegweiserknoten zum naechsten gespeichert, sondern zusaetzlich auch noch die Wegweiser selber, damit eine Verbindung vom Wegweiser zum Netzwerkkante hergestellt werden kann. Das ist deshalb notwendig, weil ich die Wegweiser nicht direkt auf die Strassenknotenpunkte gesetzt habe, sondern als eigene Punkte neben die Strasse, halt dorthin wo der Wegweiser auch in Wirklichkeit steht. Dieser Ansatz bietet die folgenden Vorteile:

• Manchmal stehen die Wegweiser etwas abseits und sind nur sehr schlecht von der Strasse aus zu erkennen. Wenn sie entsprechend in der Karte eingezeichnet sind, weiss man dann auch gleich, wo man sie zu suchen hat.
• Manchmal gibt es an einem Knotenpunkt mehr als einen einzigen Wegweiser, bei grossen Kreuzungen in Bremen hat jede Strasse, die auf die Kreuzung zufuehrt, ihre eigenen Wegweiser.
• Wenn in Zukunft die (Un-) Sitte sich immer mehr verbreitet, Radwege oder verschiedene Fahrspuren als eigene Ways in der OSM-Datenbank zu erfassen, dann ist sowieso nicht mehr klar, welcher Knotenpunkt dann genau eine Kreuzung beschreibt.

Als Beispiel fuer die Erfassung eines Wegweiser sei hier der Knoten 582608008 (http://www.openstreetmap.org/browse/node/582608008) angefuehrt, der mit den folgenden Tags gekennzeichnet ist:
tourism=information
information=guidepost
network=lcn
operator=Landkreis Verden
route=bicycle
direction_east=Bassen 5km; Sagehorn 0.3km
direction_north=Fischerhude 7km; Oberneuland 5.8km
direction_south=Achim 8km; Oyten 1.5km
direction_west=Osterholz 5km; Meyerdamm 1.2km

Die Tags network, operator und route sind wiederum eigentlich nicht notwendig, da sie ja bereits durch die uebergeordneten Relationen gegeben sind. Aber auch hier gilt, dass ich sie z.Z. lieber explizit beim Element mit angebe.

Die direction_… Tags sind die Beschriftungen der einzelnen Richtungshinweise. Wie oben ersichtlich habe ich die einzelnen Namen jeweils durch Semikolon getrennt. Bei den Entfernungsangaben habe ich die Einheit hinzugefuegt und das Dezimaltrennzeichen von Komma auf Punkt geaendert.

Von diesem Punkt aus nach Norden verlaeuft uebrigens die oben angegebenen route-Relation 373690. Entsprechend ist dieser Punkt auch Mitgleid in der Relation, und das “Fischerhude” im Namen der Relation ergibt sich aus dem direction_north Wert des Wegweisers.

Was sagt ihr zu dem Schema?
Gruss
Torsten

Also mir ist das etwas sehr umständlich. Solange die Informationen nicht in Routingsoftware oder Karten ausgewertet werden können, wirst du dafür wohl kaum Mitstreiter finden. Da erscheint mir die all-in-one-Relation eher praktikabel.

Ich hab hier selber noch zwei Aktenordner voll mit handschriftlichen Wegweiseraufzeichnungen aus NRW, für die ich noch keine EDV-taugliche Umsetzung gefunden habe. Anfangs hab ich das mal als Excel-Tabelle versucht, heute tendiere ich eher zu SVG.

Für deinen Landkreis kannst du das ja so als Pilot-Projekt eintragen. Vielleicht kannst du damit beim Landkreis für OSM-Unterstützung werben.

Ich hätte als Relationsmanen eher Nahziel1-Nahziel2 gewählt, dann gibt es weniger gleichlautende Namen. Kommen diese dennoch vor, würde ich die einfach fortlaufend durchnummerieren.

gruß,
ajoessen

Ich denke mal, mit all-in-one-Relation meinst du den Ansatz, alle Wegstuecke in eine gemeinsame route-Relation zu packen. Sicherlich ist sowas einfacher zu mappen, allerdings werden dabei ja auch viel weniger Informationen erfasst. Sind diese Informationen wesentlich? Ich weiss es nicht. Ich weiss nicht mal, ob die Radwegenetze ueberhaupt wesentlich sind. Mir ist naemlich noch kein wirklich brauchbares begegnet.

An der gemeinsamen route-relation stoeren mich die folgenden Punkte:

1. Ist ein Netzwerk was anderes als eine Route, so dass der Typ der Relation schon mal prinzipiell falsch ist. Ok, man koennte die auch genausogut in eine network-Relation umaendern. Allerdings sind all unsere heutigen Relations-Wartungs-Tools auf lineare Routen ausgelegt, so dass bei einem verzweigten Netzwerk damit nichts mehr anfangen kann.
2. Werden diese Relationen viel zu gross, um noch wirklich handhabbar zu sein. Deshalb ist man in NRW ja auch dazu uebergegangen, das Gesamtnetz mehr oder minder beliebig in Teilnetze aufzuspalten.

Was die mangelnde Auswertung auf Karten angeht (vom Routing verspreche ich mir nicht viel, dafuer sind die mir bekannten Netze einfach zu schlecht): Solange keiner die Daten entsprechend in die Datenbank eintraegt, wird auch keine Kartensoftware dafuer eine Unterstuetzung einbauen. Das kommt von alleine, wenn genug Leute entsprechende Eintraege machen. (Henne-Ei-Problem)

Hatte ich auch erst erworgen, beim Ausprobieren hat sich die Fernziel-Fernziel-Variante aber als brauchbarer rausgestellt:

• Dadurch gibt es haeufiger mal aufeinanderfolgende Abschnitte mit gleichen Namen, die sich besser zusammenfassen lassen.
• Sie sind eine bessere Indikation fuer die grobe Richtung. Die Nahziele liegen winkelmaessig doch haeufiger weiter ab.
• Die Nahziele sind nicht so eindeutig auswaehlbar. An manchen Wegweisern finden sich mehrere gleichrangige.
• Immer den am weitesten oben angegebenen Namen zu nehmen erleichtert auch die Nutzung. Wenn man mal eine Route nachfahren will, dann braucht man am Wegweiser nicht erst grossartig die gesamte Liste von moeglichen zielen durchgehen, sondern findet bereits immer an oberster Position den Namen, der an der Route auf der Karte steht.

Gruss
Torsten