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