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

Mir ist aufgefallen, was das Problem sein könnte.

Der Name “Knotenpunknetzwerk” steht vor allem für die Art der Wegweisung im Netz.

Die Motivation nach Differenzierung zwischen Route und Netz liegt u. a. darin, die verschiedenen Wegweisungs- und Wegführungstypen unterscheidbar zu machen.

Das hat in erster Linie nichts mit der Netzform (Maschen) zu tun, denn Routen können auch ein Maschennetz bilden, siehe Beispiel Rad- und WanderParadies Schwarzwald und Alb, sondern mehr mit der Wegweisungsart (Muss ich mir nur ein Symbol merken, eine Nummernfolge oder Orte?)

Demnach wäre der Tag ‘signposting_type’ treffender als ‘network:type’. Das ist ein kleiner Kollateralschaden des missverständlichen Fachbegriffs “Knotenpunktnetzwerk”, wo man sich entschieden hat, ihn mittels ‘network:type=node_network’ abzubilden. “Knotennummernwegweisungsnetz” wäre ein treffenderer, wenn auch längerer Fachbegriff gewesen.

Da ‘network:type’ nunmal für die Art der Wegweisung verwendet wird, würde ich davon aber nicht mehr abrücken, sonst müssten wir unzählige Routen umtaggen. Für die geometrische Betrachtung des Netzes eher mit einem anderen Tag abbilden, z. B. ‘network:form=mesh_network’ oder ähnlich.

Ich versuche mal eine systematische Herangehensweise für ein allgemeines Wegenetz:

Jedes Wegenetz ist aufgebaut aus Verbindungsknoten (nodes) und Verbindungsstrecken (relation mit type=route oder ways) und evtl. weiteren Elementen wie Wegweisern (information=guidepost). Die Zusammengehörigkeit ist entweder über die Mitgliedschaft in einer Netzwerkrelation (type=network) gegeben, oder über Tags an jedem Element (network,operator) oder die räumlich Lage (z.B. Verbindungsknoten sind an den Enden der Verbindungsstrecken; Wegweiser in der Nähe einer Verbindungsstrecke;…)

Die *Verbindungsknoten *können folgende Eigenschaften haben, die für die Beschilderung des Wegenetz relevant sind:

  • Nummer (Tags: z.B. lwn_ref)
  • Name (Tags: z.B. lwn_name oder einfach den Namen in das ref tag)

Die *Verbindungsstrecken *können folgende Eigenschaften haben, die für die Beschilderung des Wegenetz relevant sind:

  • Beschilderung mit Symbol (Tags: symbol, osmc:symbol, wiki:symbol)
  • Beschilderung mit Name (Tag: name) (Falls der Name nicht auch im tag symbol eingetragen ist, ist leider oftmals unklar ob Beschilderung mit Namen wirklich vorhanden ist)
  • Zielrichtung (Tag: destination)

Eigenschaften der Beschilderung, die nur aus der *Gesamtheit *aller Elemente des Wegenetzes ableitbar sind:

  • Sind an jedem Verbindungsknoten Nummern/Namen? (Tag: network:type=node_network)
  • Sind die Symbole der Verbindungsstrecken alle gleich?
  • Sind die Symbole der Verbindungsstrecken alle individuell?
  • Sind alle Verbindungsstrecken mit Zielrichtungen versehen?

Sonstige Eigenschaften die nur aus der Gesamtheit aller Elemente des Wegenetzes ableitbar sind:

  • Hat das Wegenetz Maschen?

Diese Eigenschaften können auch in Kombination auftreten. Deshalb ist die Verwendung nur des einen Tags network:type suboptimal, da eine vollständige Klassifizierung einen Wert für jede Kombination bräuchte. Evtl. wären hier Tags wie network:type:destination = yes oder network:type:distinct_symbol=yes oder network:type:mesh=yes hilfreich.

Da jedoch Kombinationen der Beschilderungs-Eigenschaften nicht so häufig vorkommen, wäre die einfache Alternative neue Werte für network:type wie basic_network, symbol_network, destination_network.

Diese Eigenschaften können alle aus den Daten selber hergeleitet werden. Insofern sind Tags dafür nicht zwingend notwendig. Da die Herleitung aber meistens sehr aufwändig ist, wäre ein Tagging hierfür hilfreich. (Bsp: Wer prüft schon ob alle Verbindungsknoten einen ref Wert haben um festzustellen das es ein Knotenpunktnummern-Wegenetz ist? Da benutzt man doch lieber network:type=node_network.)

Wegweiser (node mit information=guidepost) tragen in der OSM Datenstruktur nichts zur formalen Beschreibung der Beschilderung des Wegenetzes bei (ausser sie sind gleichzeitig ein Verbindungsknoten mit Nummer/Name). Sie dienen lediglich zur Information wo welche Beschilderung steht.

Zielwegweisungsnetze sind meistens nicht als solche in OSM erfasst (Tag destination an den routen/ways fehlt oder keine destination_sign Relationen vorhanden). Navis können diese dann nicht verwenden. Um zumindest zu dokumentieren das es ein Zielwegweisungsnetz ist, können die Vorschläge von oben benutzt werden (oder vielleicht einfach destination=yes).

Vorsicht, wir reden erst einmal von Netzwerk (network). Im Deutschen wird dafür häufig “Netz” verwendet, ganz egal welche Form es hat noch wie es aufgebaut ist, z.B. Straßenbahnnetz. Daher passt Maschennetz bzw Maschennetzwerk nicht.

Mmh, diese Relation ist doch auch nur eine Sammlung und die einzelnen Routen scheinen klar mit Start- plus Endpunkt definiert. Die Information wie Operator sollten doch auch lieber an die einzelnen Routen. Ich hätte jetzt erwartet, dass es zumindest Verbindungsrouten (connection, approach, transfer) gibt. So sind das für mich einfache lcn Routen mit Namen und Ref. Oder habe ich was übersehen?

Jetzt verstehe ich Dich leider nicht mehr ganz. Wir haben network, name, ref, symbol, operator und network:type. Ich dachte es geht hier um die Definition wenn eben genau die Kriterien nicht gegeben sind, da eben die Beschilderung das nicht zulässt. Im Endeffekt wird es immer ein Mischnetzwerk sein aus allen Routen und global betrachtet sind die Grenzen dieses Netzwerk von der Natur definiert. Für Fahrrad ist das Wasser und Steigung und nicht etwa die Verwaltungsgrenze.

Danke für dies Auflistung.

  • Sind immer nur das am nächste Ziel in eine Richtung angegeben oder mehrere aufeinanderfolgende?

Aber genau an den Wegweisern orientieren wir uns ja, und es ist das “on the ground” Element.

Ich bin da eher für die Erfassung der Wegweiser mit destination_sign Relationen. Ohne diese könnte ich die einzelnen destination-Routen in meinem destination_network sowieso nicht eintragen, ganz abgesehen von der Problematik des genauen Start- und Endpunkts.
Daher lcn=destination_network an die Wege und die Wegweiser mappen. Wenn mal der größte Teil erfasst ist, kann ich schnell mit overpass die Wegweiser finden und dann immer noch entscheiden ob eine eigene Relation für die Route nötig ist.

Ich rede hier immer von Systemen ohne Nummern, Refs oder Namen an den Wegweisern und mit maximal allgemeinen Symbol wie gelbe Raute oder grünes Fahrrad.

Ja, als node erfasst werden sollten die Wegweiser auf jeden Fall.
Und dann zusätzlich destination_sign Relationen oder destination Tags (destination:forward, destination:backward) an die Routen/ways, je nach Gusto.

Danke alo8 für diese tolle systematische Beschreibung!

Grundsätzlich sollte 'network:type:destination=yes und ‘network:type=destination’ das Gleiche sein und immer beides möglich sein. Aber ich weiß nicht, ob Router und Renderer so generisch vorgehen, dass sie auch automatische beide Taggingvarianten erkennen, zumal der Bedarf des parallelen Taggings mehrer Netztypen selten sein sollte.

Häufiger wird vorkommen, dass eine Themenroute über eine Verbindung des Grundnetzes verläuft. Dann sind das aber zwei getrennte Relationen, so man das Grundnetz hier überhaupt mappt.

Das ‘basic_network’ was ich kenne hat meistens auch eine ‘destination_network’-Beschilderung. ‘destination_network’ wäre damit auch eine alternativer Wert. Er bezieht sich noch mehr auf die Art der Wegweisung und noch weniger darauf, dass damit ein Grundetz an Wegen ausgewiesen wird. Mir wäre beides wichtig, daher fänd ich ‘basic_network’ besser

+1 Zumal auch im Knotenpunktnetzwerk nicht alle Knoten Nummern haben, z. B. der hier.

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.