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

Ich habe gerade im Zusammenhang zu Knotenpunktnetzwerken noch einiges hier geschrieben, was mir für die Diskussion hier auch wichtig wäre.

Und bei allen Modifikationen an den Knotenpunktnetzwerken gebe ich zu bedenken, dass das verwendete Tagging längst international ist, und auch so zumindest kompatibel bleiben müßte. NRW-West (=Rheinland), Belgien und die Niederlande sind praktisch ein zusammenhängendes Knotenpunktnetzwerk.

Für den Rest gilt vieles im anderen Thread erläuterte.

Ja, aber nicht eine nummerierte. So soll es zumindest sein.

Im Prinzip kann man es ja auch so sehen. Im Grunde ist es allerdings nicht ein basic-network sondern es sind basic-routes. Das basic-network ist, wenn man Themenrouten und Nummerierte Knotenrouten wegläßt, in einer Region wie hier überhaupt nicht mehr zusammenhängend, da passt der Begriff nicht so gut. Taggingpraxis könnte das schon werden. Ich tagge hier in Bielefeld frech und nicht im Sinne des Erfinders die Nummernrouten als rcn (weil das ursprünglich für Knotenpunktnetzwerke gefordert wurde) und die basics als “lcn”, die Themenrouten hat irgend jemand auch als rcn gesetzt. Waymarkedtrails macht die Knotenrouten dünn rot, die rcn gelb (Themenrouten), die lcn (blaulila) das basic-network.

Ist einigermaßen übersichtlich im Resultat… Aber nur in der passenden Zoomstufe :wink:

Edit: Irrtum: rcn sind nur ganz wenige Themenrouten getaggt. Konsistent ist das alles noch nicht… Aber die Themenrouten habe ich noch nicht angepackt - bis auf ihren Verlauf an manchen Stellen.

Ich wollte dort eigentlich nichts verändern, sondern Elemente des Knotenpunktnetzwerk-Taggings auf die Netze ohne Knotenpunktnummern übertragen.

Das meine ich ja, nicht jede Verbindung hat diese Nummerneinschübe des Knotenpunktnetzwerks. Um diese von den Knotenpunktnetzwerk zu unterscheiden wäre könnte das ‘network:type=basic_network’ helfen. Alternativ gibt es auch das ‘state=alternate’.

Wenn man es ganz konsequent machen würde, würde man das gesamte Netz mit Wegweisung erstmal als Grundnetzverbindungen taggen. Das Rad-Grundnetz wird ja durch die grüne bzw. rote Zielwegweisung definiert. Dann wäre es zusammenhängend.

Über dieses Netz legt man dann die Routen des Knotenpunktnetzwerks, die über die Einschübe mit den Knotenpunktnummern definiert werden. Darüber dann die Themenrouten mit ihren Symboleinschüben.

Naja, wer zu viel Zeit hat soll das machen! Ich würde die Grundetzverbindungen nur dort taggen, wo keine Knotennetzwerk-Verbindung drüberläuft. Dadurch wirkt das in der Master-Relation zwar lückenhaft, ist es draußen aber nicht.

Die Antwort darauf habe ich grad im Knotenpunktnetzwerks-Thread geschrieben. Ich würde die Verbindungen des Knotennetzwerks und des Grundnetzes zusammen in eine Master-Relation aufnehmen.

Die unterschiedlichen Wegweisungstypen erkennen die Renderer ja am ‘network:type’ an den route-Relationen der Verbindungen. Es sollte auch kein Problem sein, wenn in der Master-Relation ein ‘network:type=node_network’ stände, in einzelnen enthaltenen Verbindungen aber ein ‘network:type=basic_network’. Angaben der Kinder-Relation sollten die Angaben in der Master-Relation überschreiben.

Hallo Jochen,
ich habe noch einmal etwas über den Bielefelder Radwegen gebrütet, und mich doch so ein wenig mit dem network:type=basic_network angefreundet. Das Ergebnis kann man hier ansehen. Ein gewisser Schönheitsfehler ist, dass ich so mit den tags basic_network und node_network im Grunde keine Angabe zum Netzwerk sondern zu den Routen mache. Das ist aber im Prinzip das Dilemma, es gibt faktisch kein eigenständiges Knotenpunktnetzwerk. Dieses ist nur ein Teil des Radverkehrsnetzes. Insofern ist das auch wiederum egal.

Ich hoffe, der Kartenausschnitt macht das anschaulich. Ich habe übrigens tatsächlich network:type=basic_network getaggt und einen Kartenstil dahingehend ergänzt, der das auswertet… Waymarkedtrails stört sich zumindest nicht daran. Das “NRW” steht übrigens nur in der übergeordneten Relation, es ist leicht, es zu entfernen oder auch wieder hineinzunehmen.

Ich habe nun mit dem network:type=basic_network weiter experimentiert:

Ich habe insbesondere das ref=NRW aus der Master-Relation genommen, um einmal eine um die NRW-Tags bereinigte Karte ansehen zu können. Waymarkedtrails übernimmt das ref-Tag von einer beliebig weit entfernten Elternrelation. Da alle Landkreis-Relationen bis auf Mettmann, Solingen und Bielefeld das Tag ref=NRW haben, gibt es dort keinen optischen Unterschied, und es bietet die Möglichkeit von Kreis zu Kreis zu entscheiden, wie man das Tagging machen möchte.

Schade ist es, dass waymarkedtrails.org dennoch nicht so gut damit klarkommt. Ein fehlendes ref-Tag einer Route führt dazu, dass auch die ganzen anderen Informationen, wie z.B. das Höhenprofil nicht gezeigt werden. Eventuell ist das auch noch nicht der Weisheit letzter Schluß… Ich steige leider nicht durch die Struktur von waymarkedtrails auf github durch. Das wäre ein Projekt für die nächste Zeit, zu schauen, wie ggf. unbenannte Routen vollständiger gezeigt werden können. Vielleicht ist es aber auch sinnvoller und einfacher, dass die Anzeige des ref-tag bei network:type=basic_network unterdrückt wird, wie ja auch bei network:type=node_network; man ahnt schon: es müssen sicher nur ein paar Zeichen im Code ergänzt werden, damit das klappen würde. Dann könnte man die Referenz einfach beibehalten, und so z.B. verschiedene Basisnetzwerke bei Bedarf voneinander abgrenzen. (Unterschiedliche Ausschilderungen in den Ländern und Staaten).

Grüße,
Sebastian

edit: ?!? Entweder dauert das update länger… oder? NRW steht weiter überall dran, obwohl weder in der Masterrelation, der Bielefelder Relation noch in den Einzelrouten vorhanden…
edit 2: 1) dauert etwas länger 2) wenn ich das lcn entferne, gibt es auch die Höhenprofile. (Logik?) und ein NRW ist bei mir irgendwo immer noch im Cache… verschwindet vielleicht auch noch…

Sehr schöne Übersicht, danke! Das hat Arbeit gemacht!

Folgendes fiel mir dazu auf:

Zielwegweiser: Da kannst du erwähnen, dass die Wegweiser das Grundnetz definieren (route-Relationen mit ‘network:type=basic_network’).

Einzelziel: Einzelziel-Wegweiser würde ich auch mappen, analog zum normalen Zielwegweiser. route-Relationen aber nur, wenn am anderen Ende auch ein Wegweiser in die Gegenrichtung steht.

Zielpiktogramme: Das haben wir oben zwar schonmal diskutiert. Mir fällt dazu noch ein, dass es bereits ein etabliertes Tagging an den Wegekanten gibt, siehe destination:symbol. Vielleicht lässt sich dass durch einen entsprechenden Namensraum auf Radverkehr begrenzen.

Streckenpiktogramm: Könnte man an der route-Relation taggen, wenn es auf die gesamte Route zutrifft. Ein Schema haben wir dafür aber noch nicht gefunden (Idee: ‘incline_symbol=up’, eher nicht: ‘incline=up’)

Routeneinschub: Da kannst du noch erwähnen, dass diese Einschübe klassische Radrouten bzw. Knotenpunktnetzwerk-Verbindungen definieren (route-Relationen).

Knotenpunkthut/Wegweisername: ‘name=78’ hatten wir bereits an anderer Stelle diskutiert, da gehören meines Erachtens nur verbale Dinge rein, keine Zahl (Quelle). Dann lieber ‘rcn_ref=78’ auch am Wegweiser. Hier wären Meinungen anderer zu ‘name=78’ spannend.

Übersichtstafel: Irgendwie sollte schon erkenntlich sein, wenn dort das Knotenpunktsystem erläutert wird und nicht nur eine Landkarte hängt.

Hierarchie der Relationen: “Radnetz NRW” > “Fahrradknotenpunktnetzwerk NRW” (FKN). Das FKNs eine eigene übergeordnete Relation haben finde ich sehr verwirrend. Es führt dazu, dass es zwei Relationen je Kreis gibt, eine fürs FKn und eine fürs Grundnetz ohne Nummern. Ist das wild gewachsen oder hat man das irgendwo strukturiert diskutiert und entschieden?

Wenn ersteres, würde ich für eine Vereinfachung plädieren: Pro Kreis eine network-Relation für Verbindungen des FKN und des Grundnetzes gemeinsam. Die Unterscheidung, ob es eine FKN oder Grundnetzverbindung ist dann durch das Tag ‘network:type=node_network/basic_network’ an der route-Relation der Verbindungen.

“Mir erscheint es sinnvoll, immer die Strecken zwischen zwei Zielwegweiser als eine Route aufzufassen”. Vorsicht, wenn es Zielwegweiser auch zwichen zwei Netzknoten gibt hättest du damit zwei Relationen auf einer Verbindung. In Bielefeld gibt es dazwischen vielleicht nur Zwischenwegweiser, das ist aber nicht überall so. Besser fände ich “… Strecken zwischen zwei Netzknoten …”.

“Themenrouten … erscheint es mir am sinnvollsten, die Relationen unabhängig vom “Radverkehrsnetz NRW” zu lassen…”. Das sehe ich auch so.

“… Nachteil davon ist, dass bei Änderungen der Routenführung im NRW-Netz auch manuell alle Themenrouten und benannten Routen mit geändert werden müssen”. Das müssen sie doch so oder so, egal ob sie in die Sammelrelation aufgenommen werden oder nicht.

Taggingschema der Relationen: Hier würde ich die Einordnung über ‘cycle_network=::::<ggf. Netzname>’ anregen. (Das könnte irgendwann auch die Abbildung der Hierarchie über Relationen ablösen)

Zwischenwegweiser in Relationen: Du schreibst, dass Zwischenwegweiser (höchstens) in die Sammelrelation des Kreises aufgenommen werden sollen. Ich denke auch dort gehören sie nicht hin. Nach meinem Wissensstand wurden (Ziel-)Wegweiser bisher nur in die route-Relation der Verbindung aufgenommen, nicht in die network-Sammel-Relationen. Wenn man unbedingt die Zwischenwegweiser aufnehmen will, dann doch nur hier.

'information=route_marker ’ finde ich hier gut, ‘information=guidepost’ passt dafür irgendwie nicht.

edit: Zwischenwegweiser ergänzt

Hallo Jochen,

Vielen Dank für die Rückmeldungen!

Hm, im Grunde sehe ich das ja so, aber die Knotenpunktrouten und Themenrouten gehen auch alle darüber. Ich kann ja für eine Route nur 1 network:type-Tag setzen, oder ich müßte zwei Routen anlegen, wäre eher ungünstig.

Ich habe die Einzelziele alle gemappt, und auch Routen angelegt - das Merkmal der Einzelzielwegweiser ist allerdings, dass am Ende die Rückwärtswegweiser fehlen. Aber es gibt Zwischenwegweiser bis zum Ziel, so dass sich schon eine Route ergibt.

Auf den ersten Blick dachte ich, das paßt, aber wenn man sich anschaut, wie sie aktuell verwendet werden… jetzt hier in der Umgebung finden sie sich nur auf den Autobahnen oder ähnlich großen Straßen zum Markern von den einzelnen Spuren. Das paßt leider noch überhaupt nicht zur Verwendung bei den Radwegen. (Soll man dann einfach nur den ersten Weg mit dem Tag versehen, der von einem Knoten abgeht? Das erscheint mir sehr willkürlich.)

Habe festgestellt, dass ich, indem ich zunächst alles nach Schema aus den Niederlanden gemacht habe, auch tatsächlich nur rcn_ref benutzt habe… (hoffentlich).

Ich finde, durch die Aufnahme der Karte in die übergeordnete Relation wird das klar. In den HBR wird der Zusammenhang zu den Knoten sehr genau klargestellt. Oder meintest Du das anders. Also die Karten, die an den Knoten aufgestellt sind, erläutern das Knotenpunktsystem, oft eine Themenroute vor Ort und zeigen dies auch auf der Karte. Ich tausche gleich noch das Beispielfoto aus, dann sieht man den Bezug zum Knotenpunktnetzwerk besser.

Ich kenne mich nicht gut genug in openstreetmap aus, um das herauszufinden. Ich finde, es riecht ein wenig nach Wildwuchs. Aber es hat schon auch einen vernünftigen Zweck. Ich halte es für sehr sinnvoll, dass alle diese Unteraspekte des Radverkehrsnetzes NRW (das ist das einzige, das tatsächlich offiziell ein Netz ist! Alles andere sind Erfindungen von osm-usern…)

Es gäbe ein ziemliches Durcheinander, wenn man das FKN und das Grundnetz zusammen in eine Relation packt. Das ist dann auch z.B. von knooppuntnet erst einmal nicht mehr auswertbar und ich fände es ziemlich unübersichtlich. Das FKN besteht aus Routen, die zwischen den Nummernknoten liegen, dazwischen liegen aber auch viele Verzweigungsknoten, die Routen des FKN entsprechen von der Datenstruktur also eher den Themenrouten und bauen auf dem Grundnetz auf.

Nein, es gibt auch in Bielefeld eine Stelle, an der Zielwegweiser nur in zwei Richtungen zeigen, das ist allerdings der Ostbahnhof, der im Grunde damit ein Knoten einer doppelten Zielwegweisung ist. An der Stelle habe ich aber die Route nicht aufgeteilt, weil dieser Wegweiser auf einer Knotenpunktroute liegt, also im Moment in der Sparversion nicht im basic_network liegt. Es ist nach den HBR NRW schon auch so gemeint, dass Wegweiser nur an Verzweigungen oder ggf. POIs liegen. Ansonsten sollen normalerweise nur die unbeschrifteten Zwischenwegweiser zum Einsatz kommen. Es wird sicher die eine oder andere Ausnahme geben. Ich denke, man sollte im Einzelfall entscheiden, wie logisch einem die Aufspaltung in zwei Routen vorkommt.

Nicht, wenn ich die Themenrouten aus den ROUTEN des basic_network zusammensetze. Dann ändere ich nur die Wege des Grundnetzroute zwischen zwei Verzweigungsknoten, und alle Themenrouten, die diesen Abschnitt als Element haben, ändern sich mit.

Das kommt in Bielefeld auf mich zu, wenn die Baustellen an den Knoten 29, 6 und 4 beendet sind. Ist nicht soo wild, aber irgendwie auch unelegant.

Die Zielwegweiser werden im Knotenpunktnetzwerk in die Sammelrelation aufgenommen und nicht in die Routen. Das macht auch Sinn, da sie ja Element mehrerer Routen wären, man müßte sie vielfach aufnehmen (für jeden Routeneinschub gibt’s ein Duplikat…), so habe ich es auch mit dem basic_network gehandhabt - und in anderen Kreisen ist das ja sowieso so, da die Sammelrelation ja meist nur Wege aber nicht Routen sammelt…

Was die Zwischenwegweiser angeht, hast Du recht. Die könnten in die tatsächliche Route übernommen werden. Ich mach mir allerdings nicht die Mühe, dafür sind sie mir zu unwichtig. Wenn die Stadt Bielefeld sie gerne in osm hat, sollen sie schauen, was sie damit wollen. Meinethalben müssen sie wie gesagt, gar nicht aufgenommen werden.

Viele Grüße,
Sebastian

Hallo allerseits,
ich bin in den letzten Tagen nochmal einige 100 km hier durch die Lande geradelt und habe Wegweiser besichtigt :wink:

Dabei bin ich später beim Mappen im Nachbarkreis Herford darauf gestoßen, dass für viele Gemeinden ein Unter-Netzwerk angelegt wurde, als Lokales Netzwerk, das parallel zum Netzwerk NRW bestehen soll. Das sind leider nur die fern gelegenen Gemeinden gewesen, in denen ich nicht gewesen bin, ich habe aber den starken Verdacht, dass diese Netzwerke nicht “ähnlich” wie das NRW-Netzwerk sind, sondern ein Teil davon.

Nun habe ich mir Pfostenaufkleber hier in der Nähe mal näher angesehen und bin darüber gestolpert, dass es z.B. in Bielefeld Aufkleber gibt, in denen überhaupt nicht von Bielefeld die Rede ist, sondern nur auf das “Radverkehrsnetz NRW” verwiesen wird - mit der entsprechenden Servicenummer, die für ganz NRW gleich ist (oder ist sie sogar Bundesweit???).

Der Nachbarkreis Gütersloh hat seine eigenen Aufkleber, wenn man nachliest (in den HBR, S. 11), kann es durchaus sein, dass die Aufkleber veraltet sind, oder aber es läuft dort unter dem Begriff “lokale Netze”. Wenn ich aber hier die Routen abfahre, wechselt der Aufklebertyp munter von Pfosten zu Pfosten innerhalb der selben Route. Es geht auch chaotisch über die Kreisgrenzen hinweg, so dass ich zunächst in Bielefeld einen Pfosten mit dem Hinweis NRW und einem Code, der nach dem Bielefelder Stadtbezirk Dornberg mit “DOR” kodiert ist, dann folgt einer mit dem Aufkleber “Radverkehrsnetz - Gütersloh - Radverkehrsnetz.nrw”, der nach der Stadt Werther “WE” kodiert ist, dann kommt man wieder ins Stadtgebiet Bielefeld - und oha, der Pfosten ist auch mit “Radverkehrsnetz - Gütersloh” markiert, dann aber mit einem Code “BI” für Bielefeld…

Das wird auf diese Weise völlig undurchführbar, da sich die Unter-Netzwerke überhaupt nicht auf irgendeiner Ebene sauber abgrenzen lassen. Allen gemeinsam ist letztlich, dass sie den HBR-NRW folgen.

Das läuft für mich darauf hinaus, dass man letztlich nur cycle_network=NRW taggen könnte. Es wird die gemeinsame Wartungs-Infrastruktur genutzt. Das gilt dann auch entsprechend für die Tags operator und maintenance. Ich habe keine Ahnung, wie man für einzelne Abschnitte genau herausbekommen soll, wer in der Verwaltung für welche Teile zuständig ist. Vielleicht weiß es jemand genauer. Ich vermute, dass die Kreisgrenzen das entscheiden, so dass bei den übergreifenden Routen die Verwaltungen kooperieren. Wie flexibel das ganze läuft, weiß ich nicht. Aber ich frage mich, ob das überhaupt eine Debatte ist, die für das Mappen relevant ist.

Das wäre für mich ein Plädoyer dafür, die Tags cycle_network nur für Netzwerkabschnitte zu benutzen, bei denen bereits durch die Ausschilderung völlig klar ist, wozu etwas gehört. Das wird dann aber nur für die Routen gelten können, da die Wegweiser gemeinsam genutzt werden. So gibt es zum Beispiel in Gütersloh Fahrradrouten, die GT + Nummer heißen (durchaus Kreisgrenzen überschreitend). Die sind allerding sehr alt und im Prinzip nur ein historisches Relikt. Da könnte man von cycle_network=Gütersloh sprechen. Die Entsprechungen in Bielefeld (BI1-10) sind gerade ziemlich komplett abgehängt worden und durch “Routentipps 1-10” nach Knotenpunktfolgen ersetzt worden, die aber nicht mehr auf den Wegweisern erscheinen. So ähnliche Routen gibt es auch auf Gemeindeebene.

Die tags maintenance und operator sollten nur gesetzt werden, wenn man das wirklich weiß - nicht nach vagen Vermutungen. Ich habe die Informationen für meine Region nicht für alle Routen und schon gar nicht die Wegweiser herausfinden können. Die Wegweisung ist wohl formal nur Landessache.

Grüße, Sebastian

Wenn das für jemanden außerhalb der Verwaltung so schwer zu erkennen ist, dann sollte man es auch nicht taggen oder es zumindets nicht im Wiki vorschlagen.

Wahrscheinlich ist es wirklich das Einfachste, das ‘ref=NRW’ damit zu ersetzen und basta.

Ich würde aber ‘cycle_network=DE:NRW’ wählen, somit ist es dann wirklich eindeutig referenzierbar. Wenn es dann darunter tascählich noch spezifische und gut abgrenzbare Netze gibt, kann ja , und/oder hinzugefügt werden.

Wenn man die Angabe auf das Bundesland beschränkt, so sollte es doch kein Problem sein, oder?

Ist sicher ein absolutes Randthema. Ich denke aber, dass ein Nachfolger für das ‘ref=NRW’ schon empfohlen werden sollte, denn sonst wieder ‘ref=NRW’ getaggt.

+1

+1

Hallo allerseits,
mit meinem Versuch, das “NRW” aus dem Rendering bei waymarkedtrails.org im basic_network herauszubekommen, stoße ich auf merkwürdiges Verhalten, auch wenn es weitgehend funktioniert: Z.B. im Kreis Herford, Gemeinde Hiddenhausen habe ich zwei Abschnitte gleich getaggt (soweit meine blinden Augen das erkennen können), im Kartenausschnitt aktuell ein Bogen unterhalb der Löhner Straße, der westliche Teil wird hübsch blauviolett ohne Angabe eines Routennamens gerendert, der Weg, der dann ostwärts weiterführt (Relation Schlattstraße etc.) zeigt 2 Linien: Dick-Orange für rcn und blau für lcn, ohne dass ich das irgendwo anders finden kann (auch nicht in den Elternrelationen), und er bekommt die Referenz RNR, was der Renderer nun wohl automatisch aus dem Namen des übergeordneten Netzwerk gebastelt hat “Radverkehrsnetz NRW, Kreis Herford” (solange es als type=route getaggt war, bestand das Problem bei allen diesen Wegabschnitten).
Hat jemand eine Idee, ob es irgendwo im Tagging etwas gibt, das das auslöst? Ich habe auch schon einmal in die Wege geschaut, aber auch nichts gefunden. Ebenso gibt es keine überlagernde andere Relation, aus der das kommen könnte. Es scheint so, als ob waymarkedtrails.org selbst die Renderings nicht synchron aktualisiert, so dass zu einem Zeitpunkt irgend etwas entsteht, und dann bei Änderungen nur manches übernommen wird.
In Bielefeld entsteht etwas ähnliches, einige Routen werden ohne Bezeichnung gerendertm andere mit “NRW”, dabei ist das Tagging beider Kreise fast identisch (rcn vs. lcn ist ein Unterschied, stammt nicht von mir, lasse ich erst einmal bestehen). Einziger auffindbarer Unterschied zwischen den beiden Routen (12638942 und 12621947) ist, dass die eine das survey:date enthält…
Insbesondere, wenn ich in Herford das “RNR” nicht wegbekomme, werde ich wieder “ref=NRW” einsetzen, damit andere nicht evtl. noch mehr daran ändern…
Sieht mir im Moment nach einem Problem von waymarkedtrails.org aus, so dass ich da, wenn auch hier keiner eine bessere Idee hat, mal Kontakt aufnehmen würde. Die Layer in Openstreetmap (CyclOSM und Radfahrerkarte) zeigen das nicht, Das Problem ist, dass ich nicht genau weiß, wann die updates kommen, die sind nicht so schnell wie waymarkedtrails. Bei CyclOsm funktioniert es wohl, so wie es soll, die “Radfahrerkarte” mag das Tagging network= [leer] network:type=basic_network anscheinend nicht, und überspringt es. (Sobald die Renderer das fressen, würde ich auch network=bicycle wieder reinnehmen wollen!)

Grüße, Sebastian

Nachtrag: Ich hatte mich geirrt, als ich dachte, dass type=network statt type=route im Rendering ausreichend funktionieren würde, wenn die Relation noch Wege enthält. Radfahrerkarte und CyclOSM schaffen das, waymarkedtrails doch nicht. (Da hatte ich überlagernde andere Routen übersehen, so dass man nicht merkte, wenn Wege fehlen… Ich werd gleich noch meinen Wiki-Kommentar abändern… und vor dem verlängerten Wochenende wieder für Herford auf type=route und ref=NRW gehen. Bei dem Betrieb hier mit Fahrrädern werden sonst zig Mapper unterwegs sein und darüber stolpern…
In Bielefeld bleibt das Phänomen aber so nativ beobachtbar.

… noch etwas ist mir beim intensiveren Befahren der Kreise Lippe, Herford und Gütersloh durch den Kopf gegangen.
Es finden sich in den genannten Kreisen neben der Ausschilderung entsprechend den HBR NRW noch alte zusätzliche Routen mit unabhängiger Beschilderung, die ebenfalls durch die offiziellen Stellen durchgeführt wird (wurde?).

(Schloß Holte-Stukenbrock)

Es gibt dabei auch Rundrouten, bei denen absichtlich mit Schildern gespart wurde, so dass die Routen nur in eine Richtung befahrbar sind - so in der Stadt Halle/Westf.

Dies ist eine Stelle, wo mir die Benutzung von lcn und rcn doch noch Sinn zu machen scheint. Diese Routen sind ganz klar lokal, nur auf die Gemeinde bezogen. Wenn man das konsequent anwenden würde, müßte man im Grunde sämtliche Routen des Radverkehrsnetzes NRW als rcn bezeichnen, auch wenn es teilweise nur sehr kurze Streckenabschnitte sind. Und diese Routen (SHS in Schloß Holte-Stuckenbrock, HW in Halle/Westf., Oe in Oerlinghausen etc.).

Das ist auch klar auf ein Bundesland bezogen, da das Netzwerk in einem Nachbarland dann anders aussehen kann. Ich weiß es im Moment nur für Niedersachsen, aber da ist halt alles grün. Damit bekommt auch ncn einen klaren Sinn - wenn es Länderübergreifend wird, die D-Routen, und icn für die europäischen Routen.

Im Moment ist es so, dass in manchen Kreisen die grundlegenden Routen des “basic_network” NRW als rcn (Herford, Minden-Lübbecke, Dortmund) und in manchen als lcn (Bielefeld, Kreis Gütersloh, Kreis Unna) getaggt werden.

Ist das Argument genug für eine Empfehlung/Definition im wiki? Es ist ja denke ich absehbar, dass die Radwege nach dieser HBR weiter in Deutschland so ausgebaut werden.

Grüße, Sebastian

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.