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

Im Knotenpunktnetz haben die einzelne Routen auch fest definierte Anfangs und Endpunkte und bilden zusammen eine Maschennetz, da sehe ich keinen Widerspruch.

Sobald zum Betreiber mehr als nur der Name vorliegt, bietet es sich an, eine Master-network-Relation zu verwenden um die Werte nur einmal zentral zu taggen. Freilich kann man alle Infos auch an jede Route einzeln taggen, dann muss man halt bei der Pflege alle Relationen anfassen, wenn sich z.B. die Webseite ändert. Ist m. E. Geschmackssache.

Den letzten Satz verstehe ich nicht ganz. meinst du, dass die Beschilderung im ‘basic_network’ keine Annhaltspunkte für die zitierten Schlüssel liefert?

Das ‘basic_network’ sind beim Radverkehrsnetzwerk die Strecken mit einer klassischen Zielwegweisung. Ein ‘operator’ lässt sich dabei oft ausmachen, zumindest für die Wegweisung (Wer die Straßen betreibt sollte an die Straße bzw. deren Relationen). Für die anderen Tags stimmt das, sie sind nicht wirklich aus der Realität vor Ort abzulesen.

Ja, so sehe ich das auch.

Ich wollte damit auch nur sagen, dass wir hier den Netzwerk-Type über den Wegweisungs-Typ definieren, denn das ‘basic_network’ erkennt man an den Wegweisern, ‘node_network’ an den Nummerneinschüben und -schildern, ‘distinct_symbol’ an Symbolen oder Namen.

Man könnte den ‘network:type’ auch für was anderes nehmen, wie z. B. ‘mash_network’ und sich für den Wegweisungstyp einen anderen Schlüssel ausdenken.

Man kann ‘network_type’ auch für meherer Infos gleichzeitig verwenden. Dann bekommen wir aber das Problem, dass mehrere Werte auf eine Route / eine network-Relation zutreffen können. Dann müsste man auf die Variante von alo8 zurückgreifen mit ‘network:type:mash_network=yes’ + ‘network:type:basic_network=yes’.

Die Gedanken sind für mich aber eher theoretischer Natur, ich hab das alles nicht vor.

Hab es mit aufgenommen: wiki/User:JochenB/Wegweisungsnetz-Alternativen

Ich werde allmählich das Gefühl nicht los, dass man über der Suche nach dem passenden Tagging immer wieder den Umstrukturierungen der Wege und der Beschilderung hinterherläuft. Bei der Definition des tags network ist ein wesentliches Kriterium, dass das Netzwerk von einem Betreiber unterhalten wird.
Was nun z.B. das https://www.radverkehrsnetz.nrw.de angeht, so hat dies gar keinen einheitlichen Typ. Auf der Website wird das aktuelle System in einer ausführlichen Veröffentlichung beschrieben, alles Teile des “Radverkehrsnetz NRW”: Knotenpunktnetzwerke und “Themenrouten” - offenbar in der Regie der Landkreise, dazu ebenfalls gehörige Wegabschnitte, die nicht Teil einer weiteren zwischengeordneten Struktur sind. Das Problem ist allerdings, dass die Website nicht gut gepflegt ist, und weder das Kartenmaterial aktuell, noch die dort aufgeführten “Themenrouteneinschübe” noch den tatsächlichen Gegebenheiten voll entsprechen.

Man kann aber der Seite entnehmen, dass die dort genannten Themenrouten allesamt bestimmte behördliche Kriterien erfüllen müssen, damit sie an die offiziellen Wegweiser kommen können (z.B. Werbeverbot), bei denen es sich um Verkehrsschilder nach StVO handelt. Man kann der Seite ebenfalls entnehmen, das die Verantwortung für die Routen teilweise auch bei nicht staatlichen Stellen liegen kann (z.B. “Deutsche Fußball Route NRW e.V.”).

Alle diese Routen sind aber Teil des Radverkehrsnetzes NRW und sollten daher auch meiner Meinung nach in die entsprechende übergeordnete Relation aufgenommen werden. Die Routen, die in der Verantwortung eines Kreises sind, gehören dann nicht in die Relation “Radverkehrsnetz NRW” sondern in die jeweilige Unter-Relation “Radverkehrsnetz NRW, Kreis xy”, eventuell sollten auch die Knotenpunktnetzwerke nicht in der NRW-weiten Relation zusammengefaßt werden, sondern ebenfalls in die Relation des jeweiligen Kreises, der ja ggf. auch für Reparaturen etc. ansprechbar ist (hier in Bielefeld so erlebt, ob das allgemein so ist, weiß ich nicht. Ein Knotenpunkt im Kreis Gütersloh, der aber zum Bielefelder Netz gehört, fehlte, der entsprechend mit der Stadt Bielefeld geführte Email-Dialog lief so ab, dass auch die Stadt Bielefeld mich informierte, dass der Knoten inzwischen ausgeschildert sei…)

Wenn sich nun plötzlich Strukturen ändern, müßte nicht alles umgetaggt werden, sondern man würde Relationen verschieben. Das entspricht auch eher dem realen Vorgehen: Es werden ja nicht alle Schilder sofort ausgewechselt, sondern Trägerschaften ändern sich, und weitere Änderungen folgen allmählich).

Das Tagging kann bei OSM ja sehr schön an verschiedenen Stellen erfolgen, es kann ja ein einzelner “way” bei Bedarf ein anderes Tag als der direkt folgende haben, auch wenn die übergeordnete Relation dieselbe ist. Technisch möglich ist ja sogar, ein Netzwerk als rcn zu taggen und die einzelnen Routen darin in rcn und lcn zu differenzieren, falls das irgendwie sinnvoll ist.

Danke

Wie im anderen Thread und der Frage nach sich wiederholenden Nummern ersichtlich wurde, bracht es bei Nummern wohl eher eine Zuordnung wegen Uneindeutigkeit.

Beispiele von Sammelrelationen die mittlerweile wieder gelöscht wurden gibt es zuhauf. Da fallen mir die Sammlungen zu Autobahnen, Bundesstraßen oder auch Straßenbahnlinien in einer Stadt ein. In D ist associatedStreet ein weiteres Beispiel.

Mit der Vererbung habe ich so meine Probleme. Zum Erkennen der Tags brauche ich schon mal mehrere Objekte oder kennst Du einen Editor, der Dir die vererbten Tags mit anzeigt? Auch ist es wesentlich einfacher alle Relationen mit entsprechenden Tags zu suchen als jetzt die Mitglieder von Master-Relationen zu filtern nach Tags mit widersprüchlichen Werten.

Ich kenne Master-Route-Relation gut vom PTv2 und sehe eine Verbindung zu Fahrradrouten mit eigenen Teilen in eigenen Relationen als Etappen oder Varianten, Transit usw., die Master-network-Realtionen bleiben für mich in dieser Auslegung aber eine klare unnötige Sammel-Relation. Duck und weg.

Ich habe hier als Grundnetz ein “Maschennetz” ohne klare Übergänge (Start/Ziel) von den Orten mit Entfernungsangaben. Die Schilder haben weder Namen noch Nummern. Es gibt weiter Entfernungen die sich aber an beiden Enden und auch zwischendrin Aufteilen und eben keine genaue Anfangs- und Endpunkt haben, dazwischen gibt es immer noch kürzer Richtungsangaben mit zum Teil dem gleichen Verhalten des sich Teilens sowie zusätzlich noch Richtungsangaben die nur für kurze Entfernung angegeben sind und natürlich jede Menge kurzer “Fäden” die die Maschen enger machen.
Ein Beispiel ist “Universitätszentrum”. Wird nur innerhalb weniger Kilometer in der Stadt verwendet. Es gibt keine Klare Definition des Gebiets, viel mehr ist der Name in der Stadt schon nicht eindeutig. bildlich für dieses Ziel ist wohl eine Sternroute wobei das Ende ein riesiges Areal ist und der Anfang nach willkürlich da anfängt wo die markanteren Zwischenziele erreicht sind und wieder Platz auf dem Schild ist.

Ah, ich hatte schon Möglichkeiten aufgeführt, wie mit lcn=basic_network oder subtags lcn:basic_network=yes and den einzelnen Wegen eine Unterscheidung und Differenzierung möglich wäre auch ohne Sammelrelation.

Stimmt, du hattest es differenzierter geschrieben.

Mit ‘lcn:type=basic_network’ oder ‘lcn:basic_network=yes’ konkretisiert man ja das ‘network=lcn/lwn’. Man muss das also mit angeben. Da eine Wegekante mehreren Netzen zugehörig sein kann, eher ein ‘lcn/lwn=yes’, z. B.

network=lwn
lwn:type=basic_network

Das hat den Nachteil, dass man zwei Tags braucht. Es soll ja eine einfache Alternative sein. “Keep it simple” wäre ein alleiniges

lwn=basic_network

oder noch einfacher und bislang etabliert:

lwn=yes

Beim Letzten bleibt offen, ob der Mapper damit eine klassische Themen-Route gemeint hat.

Ich sollte nur mit einer Alternative für Verbindungs-Relationen ins Rennen gehen, am liebsten mit ‘lcn/lwn=basic_network’. Das ist einfach und ähnlich zum vorgeschlagenen Taggingschema mit ‘network:type=basic_network’.

Wenn Renderer ein ‘lcn/lwn=yes’ vorfinden, würde ich aber empfehlen, das wie ‘network:type=basic_network’ darzustellen. Es ist wesentlich wahrscheinlicher, dass damit eine Verbindung ohne Symbol und Name gemeint ist als eine Route mit Symbol und Namen.

Passt das?

Die Wegeverbindungs-Relation ist m. E. keine Sammelrelation.

Bei den übergeordneten Kreis- oder Landes-network-Relationen trifft das schon eher zu, zumindest, wenn da keine Netz-spezifischen Informationen enthalten sind.

Diese Art der Hierarchierung ist aber etabliert, man wird sie vermutlich nicht wieder wegbekommen. Drum wäre mir es lieber, im Wiki zu beschreiben, wie man sie richtig anwendet, als sie undokumentiert zu lassen.

Mir haben die network-Relationen auf Kreisebene geholfen, beim Mappen die Übersicht zu wahren.

Wer für welches Schild zuständig ist, ist regional unterschiedlich und nicht immer für den Mapper / Nutzer so gut ersichtlich wie scheinbar in NRW. Aber grundsätzlich gebe ich dir Recht, bei Veränderungen muss nur die Relation geändert werden. Wenn man mit Relationen umgehen kann, machen diese vieles einfacher - aber auch nur dann.

Was fehlt ist ein strukturiertes Tagging, woran man direkt erkennt, zu welcher Ebene ein Netz oder eine einzelne Verbindung gehört. Das heute steht in 'name='* der Relation. Im Radnetz von NRW zusätzlich das ‘ref=NRW’.

Ich möchte vorschlagen, dafür das strukturierte Schema zu verwenden, das andernorts im network-Tag verwendet wird:

cycle_network=<Land>:<Bundesstaat>:<Region>:<Kommune>

Siehe wiki/DE:Key:network#Hierarchisches_Format. Hier also z. B.

cycle_network=DE:NRW:Kreis Mettmann

Alternativ auch mit 'hiking_network='*, falls das sinnvoll ist.

Das kann man auch direkt an der Relation der Wegeverbindung machen, es braucht nicht unbedingt die network-Sammelrelation bzw. erlaubt es Abweichungen zur Elternrelation, z. B. bei den Verbindungen, die in den Nachbarkreis gehen und mehrere Elternrelationen haben

‘ref=NRW’ ist wohl ein Workaround dafür, dass Renderer keine Chance haben, Netz und benannte Routen zu unterscheiden. In meinen Augen hat diese Krücke einige Nachteile:

  • Anhand von 'ref='* stellen Renderer den Name der Route als Abkürzung in der Karte dar. Der Nutzer sollte den Namen also draußen wiederfinden.

  • ‘ref’ steht für Referenz, also etwas, womit man die Route von benachbarten Routen abgrenzen kann.

Im Grundnetz mit *'ref=NRW'* ist beides nicht gegeben. Der Normalnutzer wird unter "NRW" einen Radwegnamen erwarten, z. B. "Nordrevierradweg" oder so (von mir erfunden) oder eine NRW-spezifische Route ähnlich der "Tour Brandenburg". Dass "NRW" für das Grund-Netz steht, erschließt sich ihm erst, wenn er mitbekommt, dass dieser Radweg in der Karte massenhaft auftaucht und keine sinnvolle Wegekette ergibt oder gar erst vor Ort, wenn er gemerkt hat, dass da keine entsprechenden Routensymbole sind.

Ideal wäre es, wenn das Grundnetz in der Karte anders dargestellt ist, dann muss man es nicht mittels Buchstaben von den Themenrouten abgrenzen. Daher ja auch meine Vorschläge für ein abweichendes Tagging von Netzverbindungen.

… naja, das NRW-Netz ist schon so stark ausdifferenziert wie z.B. Knotenpunktnetzwerke. Wegweiser stehen praktisch nur an Verzweigungen, dazwischen werden rote Pfeile eingesetzt. Die sind das Symbol der Routen. Man könnte statt “NRW” auch einen roten Pfeil benutzen. Er ist aber Symbol jeder Route. Aber diese Route stellen wieder nur einen kleinen Ausschnitt aller Radwege dar, und auch nur einen Ausschnitt aller typischen Radrouten. Es ist nicht ungewöhnlich, dass an einer Stelle, an der auf gelben Verkehrsschildern Fahrradwege z.B. nach links abzweigend ausgeschildert werden, und nicht-Fahrradbezogene Ortswegweiser (für alle Verkehrsmittel) z.B. nach rechts und geradeaus bestimmte Ortschaften weisen, zu denen man auch auf ganz regulären Fahrradwegen gelangt, dann dennoch nur ein roter Pfeil die Wegfortsetzung nach gradeaus anzeigt. Nur dieser Weg ist dann Teil des “Radverkehrsnetzes NRW”.

Die Themenrouten werden oft auch mit Buchstabenkürzeln gerendert, weil die Symbole nicht mit den Bordmitteln der Zeichensätze darstellbar sind. Das “draußen wiederfinden” ist also sowieso relativ, und m.E. im weiteren Sinne durchaus gegeben.

Bin mal gespannt, wie sich das entwickelt. Ich habe das “NRW” bei meinen Fahrradfahrten in benachbarte Städte sehr hilfreich gefunden, weil ich damit auf Langstrecken einigermaßen darauf hoffen kann, halbwegs fahrradfreundlich, aber meist dennoch recht flott durch die Gegend zu kommen. Gerade, wenn ich spät abends noch 50 km irgendwie nach Hause fahre, liebe ich es nicht so sehr, auf einer Landstraße ohne Radweg fahren zu müssen, das ist bei den “NRW”-getaggten Wegen nur relativ selten der Fall, und durch die roten (reflektierenden) Schilder habe ich auch auf den Nebenstrecken mit gelegentlichem Zickzack eine Chance. Ich finde, das ist es Wert, ein eigenes Logo zu bekommen.

Die anderen Routen haben diese Merkmale nicht.

Viele Grüße

Ich denke auch, dass man dieses Grundnetz unbedingt anders darstellen sollte. Ich würde mir halt wünschen, dass das nicht unstrukturiert anhand von frei definierten Textfeldern passiert sondern strkturiert anhand von Schlüssel-Wert-Kombinationen wie ‘network:type=basic_network’.

Somit kann der Renderer selbst entscheiden, ob er eine andere Farbe wählt, andere Streichbreiten oder -formen oder ob er zusätzliche Tags wie 'network=‘* oder 'cycle_network=’* auswertet.

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.

Ja, danke.

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.

Die Verwendung hatte ich in wiki/DE:Bicycle/Radverkehrsnetze_kartieren dokumentiert:

“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.”

Und das eigentliche Tagging dann unter wiki/DE:Relation:network.

Die hierarchische Anwendung ist nur aus Seiten wie DE:Radverkehrsnetz Schleswig-Holstein beschrieben:

“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…

Meine Abfrage https://overpass-turbo.eu/s/16Oa liefert das derzeit erfasste Knotenpunktnetz Brandenburgs.

Dinge wie

network=lwn
lwn:type=basic_network
lwn=basic_network
lwn=yes

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.

Sven

+1

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.

Unterm Strich wäre für mich anstelle

network:type=node_network

besser

network:type=cycle_node_network

und vergleichbar gut… das lokale, regionale ect… kann man für solche Netzwerke komplett verwerfen. Beispiel: https://www.knooppuntnet.nl/en/analysis/network/12473838/map ist das lokal, regional, national, international?

Sven

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.

Die Diskussion bzgl. “Knotenpunktnetzwerken”, wo ich mehr geschrieben habe, läuft z.T. überlappend mit Inhalten von hier.

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

cycle_network=<Land>:<Bundesstaat>:<Region>:<Kommune>:<ggf. Netzwerkname>

Nunja, alles hat so seine Vor- und Nachteile:

  • ‘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 :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.