Repräsentation des aktuellen offiziellen deutschen Radverkehrsnetzes (nach den Vorgaben der FGSV) in OSM

Communities Deutschland (Germany)
,
1

Wie ich immer wieder angekündigt, und doch vor mir her geschoben habe, eröffne ich hier einen neuen Thread für die etwas größere Thematik.

Da das Thema wie beim Kampf gegen die Hydra immer wieder dazu neigt, uferlos sowohl in Grundsatzfragen als auch regionale Detailfragen zu entgleiten, möchte ich folgenden Rahmen abstecken:

Es geht hier zunächst nur um die Situation für das deutsche Radverkehrsnetz, das inzwischen einigermaßen flächendeckend nach einem bestimmten Schema eingesetzt wird. Bei der ausgeprägten Regionalisierung, die Deutschland historisch aufweist, habe ich keine Bundesweit einheitliche Grundlage gefunden, exemplarisch ist aber z.B. die nordrhein-westfälische Beschreibung des Ausschilderungssystems auf der offiziellen Seite des NRW-Verkehrsministeriums zum Radverkehrsnetz recht nützlich.

Nach äußerst mühsamen Diskussionen in internationalen Foren, in denen das System nicht bekannt war, und teilweise auch das Ausschilderungssystem kritisch hinterfragt wurde, bitte ich hier darum, sich im Zweifel vor der Diskussion die Hinweise zur Ausschilderung durchzulesen.

In Kurzfassung lautet der Plan der Verkehrsministerien zur Radwegweisung (als verbindlicher Erlass 2004 beschlossen):

Es soll ein Fahrradnetzwerk aufgebaut werden, das

  • obligat mit mindestens jeder Aufzweigung (“Knoten” im weiteren Sinne) eine Zielwegweisung aufweist, die eine kontinuierliche Wegführung zu den angegebenen Zielen ermöglicht.

  • Themenrouten durch zusätzliche Routeneinschübe an den Zielwegweisern ausweist, also in das zielorientierte Netz integriert.

  • Präzisierung der genauen Route erfolgt durch Zwischenwegweiser ohne Zielangaben.

  • Es gibt innerhalb dieses Netzwerkes spezielle Sonderformen von Routen, die aber auch nur wie die Themenrouten die Zielwegweisung ergänzen: Knotenpunktnetzwerke mit nummerierten Knotenpunkten (Besonderheit: Routeneinschübe mit Zahlen sind in Wirklichkeit Zielangaben, logische Repräsentation in OSM als durch je 2 Zahlen benannte Routen); Radschnellwege (Besonderheit: Kilometrierung in der Ausschilderung, ansonsten ausschilderungstechnisch wie benannte Routen).

Die grundlegende ungeklärte Frage ist, wie man dieses - letztlich nationale - Netzwerk in OSM abbilden kann.

Es gibt hierzu auch eine tendenziell konvergierende Mappingpraxis in Deutschland, die aber weiter sehr kontrovers diskutiert wird, und auch viele Fragen offen läßt.

Einigermaßen einheitlich findet sich in Deutschland folgender Umgang mit dem offiziellen Radnetzwerk: (meine Prozentangaben, die folgen, sind völlig subjektiv und geschätzt, ich könnte versuchen, das genauer auszurechnen, damit wäre ich aber Wochen beschäftigt… ich kann zwar ein bisschen overpass, aber das ist mir dann doch zu heavy… zumal ich es mit meinen Routenfotos manuell abgleichen müßte)

Benannte Routen werden in Routenrelationen erfaßt. Das sind gefühlt für die Regionen, in denen ich geradelt bin, ca. 60-70% der Kilometer des offiziellen Netzwerkes, die hiermit abgedeckt werden. Schätzungsweise laufen jedoch ca. 10-20 % der route=bicycle Relationen nicht auf dem offiziellen Radverkehrsnetz, on the ground sind es noch etwas mehr, da viele der privaten Radsportrouten zwar mit Aufklebern markiert sind, aber i.d.R. nicht gemappt. Unklar ist, wie man die Unterschiede erfassen kann.

Abschnitte, die ein Knotenpunkt(unter)netzwerk bilden, werden entsprechend den aus den Niederlanden etablierten Regeln gemappt. In den Niederlanden scheint aber die Ausdifferenzierung des nummerierten Knotenpunktnetzwerkes anders zu sein, als in Deutschland. Einerseits gibt es in Deutschland keine sichtbare Zuordnung zu den Regionen auf den Wegweisern. Andererseits scheinen in den Niederlanden Themenrouten weitgehend über das Knotenpunktnetzwerk geführt zu werden. In Deutschland sind dies zwei Paar Schuhe. Themenrouten verlassen oft die Knotenpunktrouten. Die Knotenpunktrouten werden durch das Tag network:type=node_network gekennzeichnet.

Wegeabschnitte des offiziellen Netzwerkes, über die keine Themenroute laufen, werden ebenfalls erfaßt. Weitgehend etabliert sich, dass lineare, unverzweigte Wegabschnitte in eigene Routenrelationen genommen werden, und diese in eine größere Netzwerk-Sammelrelation, z.B. eines Landkreises, aufgenommen werden. Das Tag network:type=basic_network breitet sich zur Kenntlichmachung der Zugehörigkeit zum offiziellen Netzwerk aus. Die Praxis, die Wege unsortiert in einer Sammelrelation zusammenzufassen, oder überhaupt nur über die Wege zu taggen, hat dazu geführt, dass vor über 10 Jahren zwar viel erfaßt worden ist, aber Korrekturen und Änderungen kaum noch eingearbeitet wurden, da nicht mehr erkennbar war, welche Netzabschnitte validiert sind, und welche nicht.

Zusammengefaßt bekäme man also das offizielle Netzwerk als Vereinigung sämtlicher Routen mit network:type=basic_network, network:type=node_network + die passenden Abschnitte der Themenrouten erfaßt.

Problematisch ist, dass über die Themenrouten Wege mit erfaßt werden, die nicht der offiziellen Wegweisung folgen. Ggf. könnte man eine Themenroute, die komplett im Netzwerk läuft, entsprechend markieren. Ich selbst habe für die übrigen Themenrouten, die nicht konsequent im Netzwerk laufen, keine andere Lösung gefunden, als auch die Routenabschnitte des offiziellen Radnetzes, über diese Themenrouten laufen, im Netzwerk - ebenfalls in Routenrelationen - zu erfassen.

Zum Abschluss noch ein paar subjektive Sätze zum: “Warum überhaupt?”, weil das auch immer wieder in Frage gestellt wird…

Ich fahre selbst gerne in der Freizeit Fahrrad und nutze das Fahrrad auch für relativ lange Strecken, um von A nach B zu kommen. Hierfür habe ich die aktuelle Wegweisung grundsätzlich sehr schätzen gelernt, mit der ich mich einigermaßen darauf verlassen kann, dass ich auf dem Weg von A nach B nicht mal 20 km an einer Bundesstraße mit Abgas- und Lärmbelästigung radeln muß (was passiert, wenn ich einen Routenvorschlag über die Routing-Apps annehme), sondern wo möglich auch etwas verkehrsferner geführt werde, ohne dass ich mir einen Weg mühsam aus Themenroutenabschnitten und unzuverlässig getaggten “highway=track” Wegen zusammenklauben muß, um dann doch über Privatgelände mit freilaufenden Hunden zu geraten, weil ein access=private Tag gefehlt hat.

Wenn man aber eine Route planen will und nicht auf gut Glück auf eine längere Strecke losfahren will, ist es schön, eine Karte zu haben, in der man sehen kann, ob es in der gewünschten Region solche Strecken überhaupt gibt, und ob man auf große Umwege geschickt wird.

Hier ergibt sich eine massive Lücke: Openstreetmap ist selbst zum Zeitpunkt 2018, wo ich angefangen habe, nach Waymarkedtrails zu radeln, die zuverlässigste Quelle für die Wege gewesen - selbst die offizielle Website des Landes NRW hat es nicht hinbekommen, ihre Wege korrekt darzustellen. Aber auch OSM war nicht vollständig und hatte einiges an falschen Wegen drin. Also habe ich begonnen, die Daten zu korrigieren, wo ich auf den Touren stecken geblieben bin.

Ich hoffe das erklärt ein wenig mein Verhalten und meine Praxis… Maxime ist meinerseits möglichst undestruktiv zu arbeiten, d.h. keine Informationsreduktion zu betreiben, in der plötzlich Daten weg sind, die jemandem aus bestimmten Gründen wichtig gewesen wären. Daher lasse ich z.B. Wege in Relationen, wo sie auch vorher gewesen sind, nur dann halt innerhalb einer verschachtelten Unterrelation. Ich bemühe mich auch darum, nicht ohne Diskussion oder Kommentar tags zu ändern oder zu löschen, wenn sie nicht offensichtlich unpassend sind. Da sehe ich z.B. eine große Schwierigkeit bei der Verwendung des cycle_network tags, das regional sehr unterschiedlich gehandhabt wird. Und genau dies war der Grund für die Verwendung des network:type=basic_network tags: Das kann ich hinzufügen, ohne dass es mit irgendwelchen anderen Daten kollidiert, ich mußte nichts umwidmen oder ändern. Dass es nun keine Möglichkeit gibt, basic_network und node_network gleichzeitig anzuwenden, habe ich nicht vorher realisiert, aber: für Deutschland gilt, dass alle node_network-Routen zum Grundnetzwerk gehören. Das sollte insofern kein inhaltliches Problem ergeben, und die Daten sind weiterhin noch logisch so klar auswertbar, dass sie automatisiert auch im großen Stil geändert werden könnten, wenn es ein anderes System zum Tagging geben sollte. (Obligate Lektüre hierzu: https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct).

Ich bin gespannt auf Meinungen und Rückmeldungen.

Viele Grüße,

Sebastian (segubi)

3 Likes
2

Ich verlinke folgende Übersicht, die @JochenB auf seiner Wikiseite angelegt hat, welche die meisten Systeme samt Vor- und Nachteilen anzeigt.

https://wiki.openstreetmap.org/wiki/User:JochenB/Wegweisungsnetz-Alternativen

2 Likes
3

Nach meinem Verständnis sind diese Zielwegweiser das Fahrrad-Äquivalent zu schon deutlich länger bestehenden Zielwegweisern für Autos, welche wir mit destination= in OSM eintragen, und die von Routern (zumindest zur Visualisierung) häufig verwendet werden.
Im Sinne einer Konsistenz in der Datenbank wäre ein destination:bicycle= eine schlüssige Erweiterung. Es taucht bisher ca. 600 Mal in der Datenbank auf. Siehe auch Taginfo: Search results | OpenStreetMap Taginfo

Mittlerweile wird das Thema Zielwegweisung auch im Fußverkehr immer relevanter und diese Methode könnte wunderbar darauf erweitert werden.

2 Likes
4

Ich glaube, das Mapping der Zielwegweiser zeigt nur ein weiteres Problemfeld meiner Fragestellung und lenkt von der grundlegenden Frage ab: Wie kann man das offzielle deutsche Radverkehrsnetz (wie oben genauer erklärt, was damit impliziert ist) so in Openstreetmap abbilden, dass es überhaupt aus den Kartendaten rekonstruierbar ist?

Auch bei den Zielwegweisern gibt es das gravierende Problem, dass es aus den vergangenen Jahrzehnten konkurrierende Wegweisungssysteme gibt, einfach aus dem Grund, dass anders als beim Autoverkehr alte Wegweiser nicht systematisch abgebaut wurden (s. z.B node 6797380325 und node 6797380326, man wird über die Zwischenwegweiser, falls man der Wegweisung folgen sollte, dann auf den HF-7 umgeleitet). Z.T. widersprechend die Wegweisungen auch einander. Manche Gemeinden halten bis heute am Nebeneinander verschiedener Wegweisungen fest. Ob das absichtlich ist, oder nicht, ist mir nicht klar.

Mit den destination-Tags an den Wegen habe ich ehrlich gesagt, keine Erfahrung. Ich habe aber den Eindruck, dass die Fahrradverkehrsführung derart uneinheitlich ist, dass es ziemlich kompliziert sein dürfte, das Prinzip der destination-Tags einfach so zu übernehmen. Aus einer Wegweisung folgt nicht ohne weiteres, welcher OSM-way zu taggen ist. (Der highway=foot; bicycle=yes? Der highway=secondary; bicycle=use_sidepath? beide? Und ab welchem Punkt?). Manche Knoten sind etwas aufgesplittet, dann weichen z.T. dadurch auch die Kilometerangaben ab, wenn sich eine Wegaufspaltung über einen zu großen Raum verteilt. Ab welcher Verteilung betrachtet man eine Kreuzung noch als eine Kreuzung, ab wann als mehrere? Wie aufwändig wird das ganze dann zu warten, wenn es Änderungen im Netz gibt?

Bei allen Schwierigkeiten, die ich sehe, stimme ich aber zu: Eventuell kann man die Unterscheidung der Netze auch über die Wegweiser angehen - ich glaube, dann wäre aber auch noch einmal über die guidepost-Relation mit nachzudenken, oder zu schauen, ob man die guideposts systematisch in die Routenrelationen aufnimmt. Dann wäre unter Umständen an den Guideposts die Netzwerkzugehörigkeit zu taggen, für die Wegabschnitte ergäbe es sich dann. Die Wartung und Qualitätssicherung wäre aber ohne Auswertungssoftware nicht mehr zu stemmen. Das kriegt man glaube ich nicht mehr über ein mapcss o.ä. gerendert. Und damit wäre das Radverkehrsnnetz nur noch als Datenwolke in OSM für Eingeweihte und spezifische Software vorhanden.

Grüße,
Sebastian

2 Likes
5

Als Ergänzung zu Jochens Zusammenstellung von möglichen Repräsentationen in OSM verlinke ich noch meine Sammlung dessen, was ich “otg” so vorgefunden habe… Für NRW, und die anderen Bundesländer, hier bin ich noch dabei, die Fotos zu bearbeiten…

6

Repräsentation des aktuellen offiziellen deutschen Radverkehrsnetzes (nach den Vorgaben der FGSV) in OSM

Ich störe mich an dieser Überschrift, weil sie mehr impliziert, als da ist.
Es gibt ein fast 25-Jahre altes Merkblatt zur wegweisenden Beschilderung für den Radverkehr, was im Inhaltsverzeichnis nicht den Eindruck erweckt, was alles außerhalb dieser Beschilderung ist, gehört nicht zum Radverkehrsnetz. (Vielleicht nicht unwichtig zu wissen, nächstes Jahr kommt ein neuer Standard raus.)
Die von dir aufgeführten Handbücher sind eine Verdeutlichung des Standards für die Praxis im jeweiligen Bundesland. So weit ich mir das angeschaut habe, unterscheiden die sich in Details. Die Unterschiede kommen eher durch die Interpretation vor Ort.
Weiter, diese Beschilderung hat nur den Status einer nicht amtlichen Wegweisung. Deswegen spuckt overpass wahrscheinlich Unmengen von Wegweisern information=guidepost und bicycle=yes aus. Bzw. es verschluckt sich dabei.

7

Nicht wirklich, die Art und Weise der Beschilderung ist anders ausgeführt: https://www.mapillary.com/app/?pKey=458944275205534 Dort muß man aber aufpassen. Das verlinkte Bild ist Knotenpunkt 40 eines Wanderknotennetzes und Knoten 97 des Radknotennetzes. Da muß man mittlerweile auch hier aufpassen.

Aber auf den Karten an den Knotenpunkten, daraus geht das Netz hervor. Die Netze hier in Brandenburg wurden von den Landkreisen erstellt und sind kreisweise zu betrachten.

Nein. Zu mindestens in Brandenburg kenne nur ganz wenige Themenradrouten, die nicht ins Knotennetz eingebunden sind. Oft sind das nur Erfassungs- und Ausschilderungsmängel. Hier hab ich beobachtet, daß Themenradrouten eher auf das Knotennetz umverlegt wurden.

Sven

8

Das ursprüngliche Merkblatt ist so alt. Das stimmt. Und deshalb erweckt es auch nicht den Eindruck eines verbindlichen Anspruchs, denn der ist dort tatsächlich nicht vorhanden.

Für NRW sind hierauf aufbauende „Hinweise zur wegweisenden Beschilderung für den Radverkehr in NRW“ (HBR NRW) allerdings aktualisiert mit Stand 9/2017, und “per Erlass zur StVO-Wegweisung erhoben” worden. Es wird explizit darauf hingewiesen, dass die HBR NRW Verbindlichkeit haben.

Zitat Kap. 3, S. 17: “Neue Routen müssen dem Standard der HBR NRW entsprechen und sind mit einer
ziel- und routenorientierten Wegweisung zu kennzeichnen.”

Abweichungen sind nur noch als Ausnahme zulässig: (Kap. 3 S. 16) “Zweigt von den nach HBR NRW-Standard ausgewiesenen Routen eine Route ab, die aus Gründen des Bestandsschutzes mit ihrer vorhandenen, noch nicht HBR NRW-konformen Beschilderung weitergeführt werden soll, so ist an diesen Abzweigepunkten ein Zwischenwegweiser mit Routenlogo zu verwenden.”

Daran wird sich insgesamt nur so leidlich gehalten, aber im Grunde ist es einigermaßen konsistent.

Aussehen tut die Ausschilderung in den übrigen Bundesländern genauso, und es ist nicht zu beobachten, dass dieser Ausschilderungstypus irrelevant werden würde. Ganz im Gegenteil, es wird zunehmend nach diesen Prinzipien ausgeschildert, auch wenn ich nicht herausfinden konnte, wie die Rechtsgrundlage in den anderen Bundesländern aussieht.

Den logischen Zusammenhang kann ich nicht sehen. Overpass spuckt tatsächlich einen Haufen Wegweiser mit information=guidepost und bicycle=yes aus. Das liegt aber nicht an der vermuteten Nichtamtlichkeit der Wegweiser, sondern wahrscheinlich eher an der ausdrücklichen Empfehlung im OSM-Wiki, Wegweiser einzupflegen - wogegen wirklich nichts spricht. Alles, was on the ground stabil sichtbar ist, kann grundsätzlich in OSM eingepflegt werden. Schon vor Jahren hat es zahllose derartige nodes gegeben. Natürlich auch mit “hiking=yes” usw. Ich wüßte nicht, dass das jemand in Frage stellt.

Overpass kommt m.E. ganz gut damit zurecht. Wenn Dich die Daten nicht interessieren, mußt Du sie ja nicht abfragen. Ein gewisses Problem sehe ich nur darin, dass viele Mapper auch Zwischenwegweiser als information=guidepost eingetragen. Das ist tatsächlich unübersichtlich, und es macht Sinn, sie davon zu unterscheiden. In Deutschland hat sich hierfür information=route_marker etabliert.

Ich habe die etwas struppige Überschrift gewählt, weil ich nur genau das Thema aus der Überschrift klären möchte: Wie kann man das offizielle Radverkehrsnetz - bzw. das Netz, das kontinuierliche zielorientierte Wegweisung bietet - einheitlich in OSM darstellen, so dass man die Routen, die dieses Kriterium erfüllen, überhaupt finden kann?

Es geht mir nicht darum, eine Vorschrift zu erfinden, die jeder befolgen muß, sondern lediglich darum, ob man sich beim Taggen auf ein paar Bezeichnungen/Values einigen könnte, die die Suche erleichtern. Im Moment gibt es keine Möglichkeit, die Routen zu finden, da jeder Kreis, jede Gemeinde anders taggt.

Das wird hier mein letztes Statement sein, in dem ich mich der Frage widme, ob man das überhaupt machen sollte. Damit habe ich im vergangenen Jahr zu viel Energie verbraucht, das werde ich nicht noch einmal in dem Ausmaß tun.

Und mir ist wichtig, dass es einfach und praktikabel bleibt. Ich betone, ich lege großen Wert darauf, dass - was in OSM eigentlich selbstverständlich sein sollte - sowohl das Mappen und Erstellen der Daten einfach sein sollte, aber eben auch das Benutzen der Daten. Solange die gesuchten Informationen einigermaßen aus dem Datenbestand herauslesbar sind, ist mir egal, ob es völlig einheitlich ist. Es ließe sich mit einem spezifischen Tag ja sogar alles per Tagging an den Wegen erledigen - auch wenn das eine sehr aufwändige Methode wäre, kooperativ die Daten zu erstellen und zu warten. Aber ohne einen Konsens hierzu bekommen wir die Daten erst gar nicht.

Grüße,

Sebastian

1 Like
9

Gilt für NRW nur teilweise. Die Netze durchdringen sich doch ziemlich, die Abgrenzung bleibt etwas virtuell. Das Bielefelder Netz (dessen Nachbarkreise keine Knotenpunkte haben) hat Knoten in zwei Nachbarkreisen. Wenn dort begonnen wird, Knotenpunkte einzuführen, überlappen sich die Netze.

Von mir aus “manchmal” statt “oft”… Kann ich mir gut vorstellen, ist auch sinnvoll. In Bielefeld ist es eindeutig so, dass die Themenrouten auch absichtlich abweichen. Ich kann mir ein paar Gründe vorstellen (Einsparen von Knoten, Einbeziehung von speziellen Zielen). Es geht mir aber eigentlich mehr darum, dass man Themenrouten datentechnisch nicht einfach als Teilmenge der Knotenpunktnetzrouten sehen kann. Dass eine nationale Route wie der niederländische Limes-Radweg einfach nur als Superrelation von Knotenpunktrouten markiert wird, hat zwar eine gewisse Eleganz, habe ich aber hier so noch nicht gesehen.

Und … hast Du Vorschläge zum Thema?

Grüße, Sebastian

1 Like
10

Der Tag Destination wird bisher genutzt, um an Kreuzungen bei den weiterführenden Wegen anzugeben, wohin jeder einzelne führt. Also eine Hilfe beim Abbiegen.
Im Gegensatz dazu ist bei (Rad)-(Knotenpunkt)-Netzwerken mit dem Tag Guidepost ein Hinweis gemeint, welches Ziel in der angegebenen Richtung liegt. Bei Netzwerken wie den Wegweiser- oder Knotenpunkt-Netzwerken ist damit (implizit) ein Hinweis verbunden, wie Nutzende zu den benachbarten Wegweisern des Netzes kommen können. Die Vermutung ist, dass Nutzende die Wege zwischen den Wegweisern aus eigenem Wissen finden können. So lautet die Regel bei Fahrrad-Netzen: fahre immer der Straße nach oder an Kreuzungen oder Abzweigungen geradeaus. Wenn du an einer Kreuzung abbiegen musst oder einen Weg verlassen sollst, wirst du einen Hinweis finden.
Grüße Jens-Uwe

11

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.

12

Ich sehe hier keinen Unterschied. Auch mit dem Rad sind die Wegweiser eine Hilfe zum Abbiegen. Auch auch bei destination sehe ich, welches Ziel in der jeweiligen Richtung ist. Sowohl bei destination als auch bei guidepost ist immer ein bestimmter Weg gemeint, den man folgen muss um zum Ziel zu kommen. Bei beiden Varianten kann später ein erneutes Abbiegen nötig sein (mit neuem Wegweiser / Destination sign).

13

Hallo,
der Unterschied liegt darin, dass Radnetze im einfachsten Fall auf die Wegweiser und ihre Nachbarschaftsbeziehungen reduziert werden können ohne irgend welche Wege zuzuordnen.
Destination soll es erleichtern, zu einem Weg an einer Kreuzung denjenigen Wegweiser auszulesen um als Teil des Routings einen Hinweis an den Nutzenden zu geben, welchem Ziel zu folgen ist. Es ersetzt z.B. einen Straßennamen (Hauptstraße) durch eine Zielangabe (Köln) in der Annahme, dass der Name des Wegs vor Ort schwieriger zu lesen ist als die Bezeichnung auf dem Wegweiser. So mein Verständnis bisher.
Grüße
Jens-Uwe

14

Je mehr ich darüber nachdenke, desto mehr bin ich davon überzeugt, dass das offizielle Radverkehrsnetz direkt am highway dran und nicht in einer Relation sein sollte. Das mit den Relationen ist alles mühsam und kompliziert. Der Wert lcn=yes oder rcn=yes deckt das wichtigste ab:

  • Router können solche Wege bevorzugen
  • Renderer können solche Wege hervorheben (cyclosm macht das schon)
  • Datenauswerter können sich die Daten per overpass (oder wie immer sie wollen) herunterladen und (zB auf Lücken) analysieren, jedoch brauchts es hier womöglich andere Methoden als wenn man Relationen analysiert.

Die großen Nachteile der Relationen, dass sie irgendwann zu viel oder zu groß werden, fallen alle weg. Und auch der Nachteil von Relation an sich, dass sie für zahlreiche Mitwirkende per se abschreckend sind, ist nicht zu unterschätzen.
Vielleicht braucht es für Spezialfälle noch ein paar Zusatztags, aber die Mehrzahl aller Netzelemente wird mit dem einen Tag auskommen.

Wie @segubi geschrieben hat, ist diese Diskussion mehrmals gestartet worden und immer wieder frustriert aufgegeben worden. Ich glaube, es braucht ein kleines Team (ca. 5 Personen), welches ohne ständige Zwischenrufe ein in sich schlüssiges Proposal ausarbeitet, dieses dann gesammelt zur Diskussion stellt und hoffentlich zu einer positiven Abstimmung bringt. Ich wäre bereit, in so einer Kleingruppe mitzuarbeiten, aber möchte das nicht federführend bearbeiten.

Liebe Grüße

1 Like
15

So wurde das auch lange gemacht und wird es auch teilweise noch, bis es Mapper gab, die diese Wege in Relationen gepackt haben. Relationen halte ich eigentlich nur für notwendig, wenn es um konkrete (oft touristische) Routenvorschläge (zu einem Ziel oder bei Rundwegen) geht, nicht jedoch bei lokalen/reginalen Netzen.

1 Like
16

Ich will mich nicht querstellen, aber ich glaube, ob das mühsam oder kompliziert ist, ist wirklich Geschmackssache. Ich finde das mit den Wegen persönlich total unübersichtlich. Ich kann nie auf den ersten Blick sehen, wer da etwas eingepflegt hat und wann, ohne mich durch unendliche Changesets durchzuwühlen. Die hohe Popularität der Relationen spricht schon ein Stück für sich, ich stehe auch nicht alleine mit meinem Empfinden da. Vielleicht ist die Herangehensweise eine andere?
Natürlich ist es einfacher, die Wege zu markieren, wenn man von einer Karte etwas überträgt. Es ist aber, wenn man on the ground sich die Situation anschaut, viel einfacher, den gefahrenen Weg nachzugehen und die Relation mit dem Datum zu versehen als die ganzen Wege. Ich kann, was Nordrhein-Westfalen angeht, ziemlich klar sagen, dass nur ein Survey zu korrekten Daten führt, da es kein suffizientes Kartenmaterial gibt. Die offizielle website zeigt Daten, die z.T. über 10 Jahre veraltet sind, und dort neue Wege fehlen und abgebaute noch enthalten sind. (Mal ganz unabhängig davon, dass ich nicht weiß, ob die Quelle überhaupt zugelassen ist für OSM).

Man kann mit lcn/rcn nicht erkennen, ob es sich um Routen mit Zielwegweisung handelt oder nur einfach in irgendeiner Form ausgeschilderte Radrouten handelt.

In den Tags lcn/rcn sehe ich keine Aussage für das Grundnetz. Die unbenannten Netzabschnitte, bzw. das gesamte Grundnetz könnte mit gleichem Recht als ncn (Größe des Gesamtnetzwerkes) wie lcn (Länge zwischen zwei Knoten) betrachtet werden. In einigen Regionen werden (wurden? in HF habe ich es nach Diskussion geändert) diese Routen als rcn betrachtet.

Wenn man sich darauf einigen würde, z.B. am Weg NUR das reguläre Netzwerk zu taggen, und hierfür entweder dafür nur lcn oder nur rcn nehmen würde, oder wie @JochenB auch mal erwogen hatte, bcn einzuführen, DANN könnte ein Renderer diese Wege identifizieren. Im Moment sind auch zahlreiche Fragmente so getaggt, die irgendwann mal vielleicht Radnetzwerk im engeren Sinne waren.

Im Moment finde ich, gibt es die Definition von rcn/lcn nicht her, dass nur Wege mit Zielwegweisung erfasst werden. Ich fürchte, es kann mühsam werden, hierfür einen Konsens zu erhalten und ohne den wären die Daten wertlos.

Mich hält auch ab, dass die Routenrelationen mehr Informationen enthalten. Man könnte ohne weiteres automatisiert die Relationen in ein Tagging am Weg überführen, umgekehrt wäre es schon ziemlich schwierig, wenn man Besonderheiten drin haben will, wie signed_direction=yes oder spezielle Routenführungen in unterschiedliche Richtungen. Wie soll man das im Tagging unterbringen?

17

Ich stehe gerade in Kommunikation mit dem Tourismusverband der Niederlausitz betreffs Mängel an den ausgeschilderten Verbindungen zwischen den Knotenpunkten. Diese Verbindungen sind in einem Objekt zusammengefasst. Ich brauchte nur einen Link zu diesem Objekt zu senden, um darzustellen, worum es geht - extrem praktisch:

https://www.openstreetmap.org/relation/12311325#layers=Y

Ich denke, die Verwendung von Relationen wurde bereits vor Jahren durch die Praxis entschieden, fast überall hat man das so gemacht. Bei Knotenpunktnetzwerken sehr strukturiert, beim Rest in teils riesigen Sammelrelationen. Seit meinem Proposal-Entwurf wird auch das Grundnetz vermehrt ähnlich der Knotenpunktnetzwerke getaggt, die Sammelrelationen nehmen ab.

Zumindest mit JOSM ist das Taggen von Relationen komfortabel gelöst, ich erkenne daran nicht Kompliziertes. Aber ja, man muss erstmal überhaupt lernen, was Relationen sind. Das sollte einerseits Grundwissen für jeden Mapper sein, andererseits biete ich im Proposal ja auch eine “Einstiegshilfe” ohne Relationen an.

Bitte nicht lcn/rcn=yes verwenden, denn daraus wird nicht klar, ob es sich um eine klassische Route oder eine Verbindung im Netzwerk handelt. Damit wären wir wieder am Anfang beim ursprünglichen Problem. Wenn dann lcn/rcn=basic_network, das ist auch Teil des Proposals.

Wir sollten den Unterschied zwischen Netzwerk-Verbindung ohne Knotennummer und mit Knotennummern nicht dadurch abbilden, ob wir das mittels Relation an die Linie schreiben oder direkt an die Linie.

Inhaltliche Unterschiede sollten durch unterschiedliche Tag-Inhalte beschrieben werden und nicht durch unterschiedliche Verwendung von OSM-Konstrukten.

Also genau dort liegt einer der größte Vorteile der Relation: ein Blick in die Mitgliederliste und man erkennt Lücken auf einem Blick. Hier per Overpass zu gehen halte ich für mega-kompliziert, das ist dann wirklich nichts mehr für den Durchschnitts-Mapper.

Dieser Nachteil existiert in meinen Augen nicht, die Relationen sind meist recht kompakt. Ein paar durchgehende zusammenhängende Linien und ggf. am Ende noch die zugehörigen Wegweiserknoten.

Es ist eher umgekehrt, dass bei dichten Netzen sehr kleine Relationen entstehen können mit ein / zwei Linien. Aber dafür gibts ja auch die simple Lösung, mehrere hintereinander liegende Verbindungen in einer Relation zusammenzulegen.

Nun, dafür habe ich lcn/rcn=basic_network vorgeschlagen, das kann ja später jemand in Relationen mit network:type=basic_network überführen, der mit Relationen nicht fremdelt.

1 Like
18

Ich habe das nicht als frustrierend erlebt, sondern als sehr konstruktiv. Dass ich am Proposal nicht weitergemacht habe, hat einerseits private Gründe, anderseits habe ich meine Ziele bereits weitgehend erreicht.

Das Proposal wurde sehr umfangreich in der internationalen Mailingliste diskutiert. Gefühlt 70% war fehlendes Verständnis für den Bedarf bzw. für den Unterschied zu bekannten Tags, die nach meiner Einschätzung bereits etwas anderes beschreiben. 15% waren Abschweifungen und vielleicht 15% Verbesserungshinweise.

Diese 15% waren die Diskussion wert. Für mich war die Frage wichtig, ob es relevante Bedenken gibt und wir mit dem Vorschlag auf dem Holzweg sind. Von denen, die es verstanden haben, kam so etwas nicht. Damit ist für mich das Wichtigste erledigt.

Es gab vor allem die Bitte, einen selbst-beschreiberenden Tag-Namen zu finden als network:type. Zudem zahlreiche Hinweise für eine verständlichere, allgemeinere Beschreibung des Problems und der Lösung. Es gab auch Kritik an dem Vorschlag, ein Tagging ohne Relationen als “Einstiegshilfe” anzubieten.

Da sich network:type bereits durchgesetzt hat und mir auch nichts Besseres einfällt würde ich das Proposal mit denselben Tags weiterführen. Die Beschreibung, was ein “Grundnetz” ist, würde ich jedoch genereller durchführen, so dass es unabhängig vom Anwendungsfall “Wandern” oder “Radfahren” ist. Ich würde zudem begründen, warum ich die Vorschläge der Anwendung bestehender Tags nicht übernehme.

Macht viel Aufwand, aber wofür?

Ich habe ehrlich gesagt nur beschränkt Spaß daran, nochmal den Rest der Welt zu erklären wie die Situation in Mitteleuropa ist mit dem Risiko, dass es nicht verstanden und daher abgelehnt wird.

Das wäre der Worst Case. Dann haben wir ein abgelehntes Proposal für eine Praxis, die sich längst verbreitet hat. Wer hat Lust das nochmal mit einem erneuten Vorschlag anzugehen oder wer wird das bereits Getaggte alles nochmal abändern?

Also lieber die Kraft in das Wiki stecken. So sollten Knotenpunknetze und Grundnetz zusammen beschrieben werden, die Unterschiede sind ja gering.

Zudem gibt es viele redundante Beschreibung in den Seiten der einzelnen Keys. Das wäre besser zentral auf die Seiten Bicycle/Radverkehrsnetze kartieren und das Bicycle/Fahrradrouten_kartieren aufgehoben, von den Key-Seiten dann einfach darauf verweisen.

2 Likes
19

Ich ergänze noch einmal an diesem Ort einen Vorschlag von Jens-Uwe etwas expliziter, den ich gut finde, und den ich allmählich hier in der Gegend einpflegen werde, weil er offensichtlich unschädlich für bestehende Applikationen und hilfreich für neue Anwendungen ist:
In die Relationen können am Start- und Endpunkt die zugehörigen Wegweiser aufgenommen werden. Das hat den großen Vorteil, dass die Relationen deutlicher definiert sind, und die Verbindung zwischen Route und Wegweiser einfach herstellbar ist, ohne z.B. eine Umkreissuche um die Wege der Routen durchführen zu müssen.
Ich würde vorschlagen, Zielwegweiser, die unterwegs stehen, auch an der Stelle in die Relation einzusetzen, wo sie sich befinden. (Ich bin der Meinung, dass auch bei getrenntem Hin- und Rückweg EIN guidepost-node nur EINMAL aufgenommen werden sollte. Begründung unten…) Bei linearen Relationen, die auch über Abzweigungen laufen kann sich hieraus (wenn mehr als 2 Richtungen vorliegen) auch ein Hinweis ergeben, dass an dieser Stelle ein Abzweig liegt.

(@Jens-Uwe_Hagenah: Du hast von “deiner” Routing-Applikation gesprochen, die die Relationen entsprechend auswertet. Gibt es sie irgendwo? Man könnte sie ja gut zum Testen der Relationen verwenden…)

Viele Grüße und ein gutes neues Jahr hier…
Sebastian

Anhang: guidepost nur je einmal aufnehmen?
Pro:

  • Insgesamt nicht zu viele Elemente in eine Relation aufnehmen
  • Ungeschriebenes Gesetz: Elemente sowieso nicht doppelt in eine Relation aufnehmen (hier gibt es aber auch gut begründbare Ausnahmen)
  • Da die Daten, wenn man die Relation bereits zur Auswertung herunter geladen hat, ist die Zuordnung zu bestimmten Lokalisationen ohne erneute Datenabfrage lokal ohne Aufwand möglich. (Also die Zuordnung zum entprechenden Routenabschnitt/Routenpunkt der Gegenrichtung: Algorithmus: erstelle Route für Hinweg, erstelle Route für Rückweg, wähle jeweils den nächstliegenden Punkt der Route zum Wegweiser als Wegweisungspunkt)

Contra:

  • Woher soll der Router dann wissen, wo genau ein Abzweig ist?

Pro:

  • Das muss der Router aufgrund der Wege selbst herausfinden, da 1. erfahrungsgemäß die Relationen ohnehin ständigen Veränderungen unterliegen und die Ordnung sich je nach Editor, der damit hantiert, auch mal wieder ändern kann. 2. im Falle von Abzweigungen unter Umständen sowieso variable Routen auftreten können, bei denen es mehrere faktische Knoten (je nach eingeschlagenem Weg und Richtung) geben kann.

Contra:

  • Ich könnte mir Fälle vorstellen, wo ein Wegweiser nur von einer Routenrichtung aus sichtbar ist. Das könnte dann damit signalisiert werden. Im Falle von Verzweigungen würde ich dann allerdings ohnehin hoffen, dass dann ein zweiter Wegweiser für die andere Richtung vorhanden wäre - leider gibt es on the ground Ausnahmen, dass nämlich Aufzweigungen nur für eine Wegrichtung vorhanden sind und die Gegenrichtung keine Wahlmöglichkeit gezeigt bekommt. (halte ich prinzipiell für eine Ausschilderungsinkonsistenz, befürchte aber, das ist an manchen Stellen beabsichtigt - leider erinnere ich mich nicht mehr genau an die Beispiele. War irgendwo im Kreis Herford.)

Pro:

  • Warum bei so komplizierten Fällen nicht doch überhaupt die Relation an der Aufzweigung splitten und zwei Relationen machen??? Dann muß die arme Routinganwendung (bzw. deren Programmierer) sich nicht mit der Analyse dieser Spezialfälle beschäftigen… Sondern Knoten ist halt am Ende der Relation. Die Relation, die keinen Abzweig angeboten bekommt, bekommt halt auch keinen Guidepost node, wenn sich daraus eine Relation ergibt, in die nur von einer Seite aus eingebogen werden würde wegen der Ausschilderung, kann ein signed_direction=yes bekommen (Achtung: Es gibt auch Wegabschnitte, die zwar von der Zielwegweisung nur von einer Seite erfaßt werden, aber eine beidseitige Zwischenwegweisung haben. Da handelt es sich am wahrscheinlichsten um Vandalismus oder einen Ausschilderungsfehler. Ich würde dann kein signed_direction setzen, sondern bescheiden auf eine genauere Spezifizierung verzichten, und wenn ich viel Zeit übrig habe, mit der zuständigen Stelle des Landkreises/der Gemeinde Kontakt aufnehmen und fragen, ob das Absicht ist…)
20

Meine Idee besteht darin, Radwegweisernetze wie Knotenpunktnetze zu behandeln. Das bedeutet dass, dass jeweils eine Verbindung zwischen zwei entfernt voneinander liegenden Wegweisern erfasst wird aber nicht über diese Wegweiser hinausgeht.
Im Falle von Armwegweisern sind dann genau zwei Wegweiser beteiligt (Beispiel Relation 15089617).
Die Wege zwischen den beiden Wegweisern werden ohne Rolle erfasst wenn Hin- und Rückweg identisch sind. Was dabei der Hin- bzw. Rückweg ist, wird durch die Erfassenden willkürlich festgelegt. Die Strecken sollten vollständig sein, um die Gesamtlänge zu ziemlich genau zu erfassen. Eine Abweichung von dieser Regel wird weiter unten beschrieben.
Fallen Hin- und Rückweg streckenweise auseinander, so bekommen die Strecken, die nur auf dem Hinweg befahren werden, die Rolle forward (unabhängig von der Richtung des Way). Entsprechendes gilt für den Rückweg mit der Rolle backward (Beispiel Relation 14956019).
Gibt es nur einen Hinweg (ohne Rückweg) so bekommen alle Stecken die Rolle forward um sie von einer in beide Richtung befahrbaren Strecke zu unterscheiden.
Stehen an einem oder beiden Enden (mehrere) Tabellenwegweiser, so werden diejenigen aufgenommen, die zu dieser Relation gehören, d.h. auf das Ziel hinweisen (Es gibt leider krude Situationen, wo nicht alle Wegweiser die Ziele zumindest paarweise teilen. Das ist aber nur selten der Fall) . Den Normalfall zeigt das schon bekannten Beispiel Relation 14956019 am Anfang. Oder mit mehreren Wegweisern an beiden Enden (Beispiel Relation 14884215).
Für die Auswertung per Programm ist es wichtig, dass die Relation am Anfang und Ende jeweils Strecken so aufnimmt, dass die zugehörige Himmelsrichtung des Wegweisers mit der des ersten bzw. letzten Steckeinabschnitts übereinstimmt. Sonst versagt die Zuordnung dieses Abschnittes zu der Himmelrichtungen des Wegweisers und die zur Relation passende Zielangabe kann nicht gefunden werden. Siehe hierzu den Anfang in der Schillerstraße von Relation 15089790. Wird auch der kurze Way (das Teilstück Dorfstraße hinzugenommen, um den Anschluss zur angrenzenden Relation lückenlos zu machen (Relation 15089791), so würde dieses in Ost-West- statt in Nord-Süd-Richtung weisen. Und die Wegweisung (des Wegweisers 1593914894) in Richtung Ost (Bad Schwartau) statt Nordwest (Ahrensbök) zuordnen.

Ich hoffe hiermit einen brauchbaren Vorschlag zum Mapping von lokalen Radnetzen (network:type: basic_network) mit Wegweisern zu unterbreiten. Ich betrachte ihn als RFC.
Das ganze Beispiel mehrere Relation findet sich bei Turbopass.eu unter dem angegebenen Link.

@segubi: Vielen Dank für dein Interesse an meiner App (für Android-Smartphones). Ich stelle ich gerade auf dieses Schema im Mapping um. Aber ich werde wohl noch etwas brauchen :frowning: . Sobald ich etwas Vorführbares habe, werde ich dies hier auf Community.Open mitteilen :slight_smile: .