Ich kann gut mit neuen Werten für *wn und *cn leben. Meine Varianten mit zwei Tags würden halt nichts ändern sondern nur einen neuen Tag hinzufügen. Damit bleibt es dann der Software überlassen, ob der Tag ausgewertet wird. Mit neuen Werten für einen etablierten Schlüssel bedarf es Anpassungen bei jeder Software, allerdings wird/würde lcn und Konsorten ja auch wenig ausgewertet. Bei guidepost werde ich wohl nicht drumrum kommen eine Möglichkeit für mehrere Netzwerk-Typen mir zu überlegen.
Das bleibt den einzeln überlassen. Könnte auch zwei unterschiedliche Darstellungen wählen, damit ich gleich die Unterschiede erkenne und nicht erst Overpass bemühen muss.
Sorry, da habe ich mich ungenau ausgedrückt. Die übergeordnete Relation welche Varianten und Abstecher bzw. Zugänge einer Route vereinigt ist absolut in Ordnung. Mir ging es um die übergeordneten Ebenen:
Wo gibt es dafür den ein Proposal? Habe beim THW gerade solche Relationen entdeckt, über mehrere Ebenen obwohl alles mit Tags schon ausgedrückt wird. Grauenhaft, diese Kollektionen ohne zusätzlich Informationen, wo es doch Overpass gibt und die admin-Grenzen gut zur Eingrenzung verwendet werden können.
Gegen eine Dokumentation spricht aber nichts, da kann ich dann auch meine Meinung manifestieren.
Ich finde sie fürchterlich und ohne Mehrwert, liegt aber auch daran, dass es eine Monster-Sammelrelation bei mir ist. Insgesamt ist das aber wohl das Werk einiger weniger und eventuell ein Phänomen von iD, da ich dort weder gescheit filtern noch einfach mal eine Overpass-Abfrage auf einen Landkreis loslassen kann.
“Bei Bedarf können alle Wegeverbindungen, Fahrradrouten und Teilnetze eines Radverkehrsnetzes in einer Master-network-Relation zusammengefasst werden. Somit können Angaben zum Netz zentral an einer Stelle gespeichert werden und müssen nicht separat an jede Wegeverbindung bzw. jedes Teilnetz geschrieben werden.”
“Es wird also nur noch ausschließlich mit Network-Relationen gearbeitet, die auf die Landkreise aufgeteilt sind und der Super-Relation „Radverkehrsnetz Schleswig-Holstein“ untergeordnet werden.”
Ich hab mich ja hier in Brandenburg in den letzten Jahren doch recht internsiv mit den hier entstandenen Knotenpunktnetzen beschäftigt. Was solche Radwegenetze anbelangt, halte ich dafür schon länger network=cn für absolut überflüssig. Eine Unterscheidung bei solchen Netzen nach lokal, regional, national… funktioniert nur aller äußerst begrenzt. Bezogen auf Radwege, sind es* immer **regionale Netze… Für mich ist es nur nötig zu unterscheiden, ob es Netz A oder Netz B ist oder vielleicht noch eine Übergang von Netz A zu Netz B.
Meiner Ansicht ist es für jede Art von netzartige Ragwegesituationen primär es ausreichend, ein network:type=* zu haben, für Knotenpunktnetze dann network:type=node_network und meiner Ansicht nach, verbunden mit cycle_network=[Name des Netzwerks].
Ich selbst betrachte die notwendige übergeordnete Netzwerkrelationen wie mein heimisches Netz: https://www.openstreetmap.org/relation/10953719 als Mittel um zu prüfen, ob alles da ist und diese innerhalb derer konsistent ist, einschließlich der Übergänge zu benachbarten Netzen…
sind für mich überflüssig. Die Art des Netzes wird mit network:type=* angegeben und cycle_network für eine Art Zustänigkeit, fertig… mehr ist nicht nötig.
Wobei man genauso sagen kann, Knotenpunktnetzwerke sind immer lokal, weil Verbindungen zwischen zwei Knoten meist vergleichsweise kurz sind.
Das “l” in ‘lwn=basic_network’ halte ich bei Netzen tatsächlich auch für überflüssig, das “c” bzw. “w” ist umso wichtiger. Irgendwie muss ja sagen, das die Wegekante Teil eines Fahrrad-/Wanderwegnetzes ist.
Bei Relationen gibt es dafür das ‘route=bicycle/hiking’. Wenn man keine Relationen verwenden und die Werte direkt an die Wegekante schreiben will, dann braucht man eine Alternative, möglichst ohne zusätzlichen weiteren Tag.
Die Verbindungen selbst möge man vielleicht als lokal einstufen können… Das Netzwerk als solches funktioniert aber als solches nur im Ganzen. Da spielt lokal keine Rolle mehr… Auch nicht mehr regional, da man z.B. ein geschlossenes Netz wie wir es in Nordbrandenburg haben weder als lokal, noch als regional bezeichnen kann… Meiner Ansicht nach kann man ein Fahrradknotenpunktnetz nicht nach lokal, regional oder was auch immer trennen. Das geht nicht. Von dem Gedanken habe ich mich schon lange gelöst. Das Konzept dahinter ist ein anderes, als das, was man bisher bei den Themenradrouten hatte…
Denn bei diesen Themenradrouten hingegen ist das was völlig anderes… da funktioniert lokal, reginal, national…
+1 …und deswegen ist das “l” auch bereits bei den Knoten-zu-Knoten-Routen unnötig.
Das sehe ich zumindest in NRW auch so. Für NRW ist sicher, dass “basic_network” nicht paßt. Es gibt EIN Netzwerk, in das quasi paritätisch Themenrouten und nummerierte Knotenpunktnetzwerke integriert sind. Ich empfehle für die Situation in NRW noch einmal sehr die offiziellen Richtlinien der Beschilderungen, aus denen das klar hervorgeht, und die wahrscheinlich die nächste Zukunft der Fahrradwegweisung hier noch mehr dominieren werden. Es wäre interessant zu schauen, ob das für andere Bundesländer anders ist. Es würde mich nicht wundern. Es macht dabei dann eventuell wirklich Sinn zu schauen, was ein gemeinsamer Nenner wäre, und welche Taggings je nach Situation dann darauf aufsetzen würden.
Aber nicht über alle Strecken des “EINEN” Netzwerks (=“Basisnetzwerks”) verlaufen Themenrouten.
Gerade in NRW sehe ich das Problem, dass das Basisnetzwerk als “route=bicycle”, “type=route” und “network=lcn” mit “ref=NRW” getaggt ist. Und man diese Routen in der Karte nicht von den Themenrouten unterscheiden kann.
Ich habe letztes Jahr eine Tour von Berlin nach Köln unternommen und mit Komoot geplant, und in NRW (vor allem im Bereich Ruhrgebiet) war es total schwierig zu erkennen, wo die touristisch interessanten Strecken verlaufen.
Gibt es in NRW wirklich flächendeckend nummerierte Knotenpunktnetzwerke? Wenn das so ist, braucht es tatsächlich kein zusätzliches “basic_network”, weil das Knotenpunktnetzwerk quasi das Basisnetzwerk bildet. Zumindest letztes Jahr war das aber nicht überall in NRW der Fall. Ich halte es für wichtig, dass die Themenrouten von den anderen ausgeschilderten Routen auch dort unterschieden werden können, wo die “Knotenpunkte” nicht nummeriert sind. Ich unterstütze daher Jochens Ansatz, hierfür ein Tagging-Schema zu finden, wobei ich keine Meinung dazu habe, welche seiner alternativen Vorschläge ich bevorzugen würde.
Ich stimme dir dort zu, wo das Wegweisungsnetz/Grundnetz komplett mit Knotenpunktwegweisung ergänzt wurde. Dort gibt für ‘network=basic_network’ keinen Anwendungsfall mehr. Es macht keinen Sinn, eine Grundnetzverbindung zusätzlich zu einer Knotenpunktverbindung zu mappen, wenn diese sich komplett überlappen.
Ist es wirklich so, dass in den NRW-Knotenpunktnetzwerken jede Verbindung mit Wegweisung auch gleichzeitig eine Knotenpunktverbindung ist?
In meinen Augen ist NRW aber durchaus noch ein Musterbeispiel, dass das ‘basic_network’ notwendig ist. Das sieht man am dichten Netz von Radrouten mit ‘ref=NRW’, die in Echt gar keine Radrouten sind. Das Netz hat nahezu durchgängig eine Ziel-Wegweisung nach FSGV-Standard (Grundnetz) mit Einschüben für Themenrouten. In den Teilen, in denen es kein Knotenpunktnetzwerk gibt, braucht es m. E. das ‘basic_network’ dringend.
Hm, diese Konzepte der Länder gaben mir den Anstoß, zwischen basic_network, node_network und Themenradroute zu unterscheiden. Das ist in anderen Bundesländern ja ähnlich.
Auf Seite 1:
Demnach sind 1) und 2) ‘network=basic_network’. 3) sind klassische Radrouten und 4) ist ‘network=node_network’.
Ob man 1) und 2) per ‘network=lcn/rcn’ unterscheiden sollte, haben wir oben diskutiert. Ich finde das besser in ‘cycle_network’ oder 'operator='* aufgehoben, da die Verantwortung für den Radfahrer draußen nicht direkt erkennbar ist und das Kataster keine legale Quelle darstellt.
Weiter unten steht dann
Für OSM könnte man das so auslegen, dass es in NRW eine übergeordnete Relation für alle vier Ausprägungsformen 1) bis 4) gibt.
Ich halte diese Über-Relationen aber für nicht notwendig. Es sind letzten Endes Sammelrelationen. Man bekommt deren Inhalte durch eine entsprechende Abfrage auch ohne Relation geliefert bzw. kann das an jeder Verbindungsrelation mappen z. B. mit
‘network:type=cycle_node_network’ wäre ein Verändern des etablierten Werts ‘network:type=node_network’. Zudem bräuchte man dann weitere Werte ‘hiking_node_network’, ‘riding_node_network’ und das selbe nochmals für das ‘basic_network’.
‘network=bicycle’ mit ‘network:type=basic_network’ wären wieder zwei Tags an die Wegekante, die Lösung ohne Relationen sollte schlicht sein.
‘lcn=basic_network’ dagegen unterstellt eine Klassifizierung, die man hier garnicht braucht.
Bei diesen drei Optionen erscheint mir die dritte als die mit den geringsten Nachteilen. Zwar braucht man das “l” nicht, man kann es aber herleiten und erklären mit dem Satz: “Im Grundnetz sind die einzelnen Verbindungen i. d. R recht kurz.”.
Wenn wir zudem im Wiki dokumentieren, dass das Grundnetz immer ‘network=lcn/lwn’ ist, dann ist das einheitlich so und damit dann auch egal.
Nur im Radnetz NRW gäbe es eine Änderung beim Anwenden des neuen Schemas, da ein Teil dessen Grundnetzes bislang mit ‘network=rcn’ getaggt ist. Aber ob man das Tag nun löscht oder ändert, es sollte so oder so angefasst werden, damit es einheitlich ist.
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
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.
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.
Hallo allerseits,
ich bin in den letzten Tagen nochmal einige 100 km hier durch die Lande geradelt und habe Wegweiser besichtigt …
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.
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.
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.
