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

Ich würde im meiner Gegend diese Relationen ganz Löschen, da mit der Geschichte eh nichts mehr anzufangen ist. Natürlich sollte jedes Mitglied auf lcn=yes überprüft werden vor der Löschung, was eine Menge Arbeit machen wird. Kann ja aber Ortschaft für Ortschaft durchgearbeitet werden, bis die Relation keine Mitglieder mehr hat.

+1, hier sind wir einer Meinung. Die Definition von Punkt-zu-Punkt ist ein anderer Thread.

Bei mir entfallen dadurch dann die Probleme, dass mein Maschennetz ohne erkennbare Grenzen und ohne Namen oder Nummerierungen von Wegweisern richtig dargestellt wird. Es ist halt lcn=yes an den einzelnen Wegen (und braucht keine Monstersammelrelation) und darüber zig “richtige” Fahrradrouten mit z.T. höherem Netzwerkbezeichnungen (rcn …) und dies über Landkreisgrenzen hinweg, ah, stopp, über nationale Grenzen hinweg.

Ich finde beides hat Vor- und Nachteile, also mit ‘lcn=yes’ an den Wegen oder per Relationen mit z. B. ‘network:type=basic_network’. Ich würde beides als mögliche Lösung beschreiben. Die Relationen dürfen freilich keine Sammelrelationen sein sondern dürfen jeweils nur eine durchgehende Wegekette enthalten. Diese Sammelrelationen sind für die Datenpflege der worst case!

Relationen zu Taggen ist etwas aufwendiger und nicht jeder kann damit gut umgehen. Für den Anwendungsfall, wenn man nur einen kleinen Teil der Verbindung vor Ort überprüfen konnte finde ich ‘lcn=yes’ auch besser.

Andererseits finde ich die Pflege von Relationen wesentlich leichter, zumindest in JOSM. Ich vermute auch, dass die Akzeptanz nicht da ist, wenn wir bestehende (Nichtsammel-)Relationen löschen und durch ‘lcn=yes’ an den Wegen ersetzen.

Wichtig wäre, dass Wege ‘lcn=yes’ nicht genauso dargestellt werden wie Fahrrad-Routen mit ‘lcn=yes’. Die Hauptmotivation dieses Beitrages ist ja, dass man beides voneinander unterscheiden kann. Das wäre dann eine Empfehlung an die Rendererprogrammierer. Wege mit ‘lcn/rcn=yes’ sind ja erst kürzlich aus der Rendererdarstellung von thunderforest rausgeflogen, es sollte dann in anderer Form wieder rein.

Wenn man erst mal die Knotenpunktnetze betrachtet, sind diese ja in meinen Augen sehr gut strukturiert. https://www.knooppuntnet.nl/en/analysis prüft ja zunächst nur die als echte erfassten Knotenpunktnetze. Ich halte das für ein sehr gutes und nach einer Einarbeitung für leicht anwendbares Prüftool von solchen Routen-Geschichten. Ich kann mir aber sehr gut vorstellen, daß das auch auf andere Arten von solchen hier disskutierten Netzen anwendbar wäre. Ich meine auch, daß es sicher zur Fehlerprüfung von themenbezogenen Rad- und Wanderwegen geeignet wäre…

Da wäre ich froh, ein solches erweitertes Mittel in der Hand zu haben.

Sven

Die Idee klingt gut, damit kämen wir ohne zusätzliche Tags aus.

In der Praxis gibt es jedoch durchaus Netze aus Themenrouten mit entsprechender Master-Relation, z. B. das Themenroutennetz des Rad- und WanderParadies Schwarzwald und Alb. Drum braucht es schon irgend einen Tag, der Themenrouten von sonstigen Verbindungen unterscheidet.

Alternative wäre, die Wege ohne Routenname immer in network-Relationen zu sammeln, das wäre dann Variante a) mit den beschriebenen Nachteil, dass man beim Wander/Radnetz network-Relationen in zwei verschiedenen Bedeutungen verwendet. Die wäre an sich OK, aber Relationen sind so schon für viele Mapper eh’ ein rotes Tuch, da hilft jede vermiedene Verwirrung.

Was wäre denn eine passende Definition für “Themenroute”?

Tag name existiert reicht vermutlich noch nicht aus, da auch Netzwerk-Routenverbindungen durchaus mal Namen haben wie z.B. “Von A nach B”.

Existenz eines eigenen Symbols eventuell? Wäre das zwingend? Wie wäre “eigenen” zu definieren? (z.B. keine Nummer,…)

Wäre “Rundweg um Hintertupfingen, roter Punkt” eine Themenroute?

Versteht mich bitte nicht falsch, ich bin ein Fan von Relationen (selbst von type=node bei komplexen Wegweisern an Laternen und auch von type=destination_sign).

Ich halte es für die richtige Idee Route Relationen weiter zu klassifizieren (das betrifft zum Teil auch route=road, Themenrouten) von daher machen neue network:type Werte Sinn. Leider lassen sich aber bestimmte Situationen nur schwer in Relationen pressen und wenn ich keinen genauen Anfangs und Endpunkt habe wird es schwierig. Auch sehe ich nicht warum ich zwei aufeinanderfolgende Wegweiser mit dem gleichen Ziel als Route definieren kann. Machen wir das beim motorisierten Verkehr auch? Die Information ist ja mit den Wegweisern und einem einfachen Tag an den Wegen abgebildet. Meinetwegen könnte ja aauch ein andere Wert für *cn und *wn eingebracht werden wie lcn=basic_network oder auch lcn:type=basic_network oder vielleicht sogar lcn:basic_network=yes.
Sollte am besten auch für die Wegweiser verwendbar sein.

@JochenB: Kann also auch bitte ein Vergleich zu Verwendungen von Tags und wenigen bis keine Relationen in die Tabelle aufgenommen werden oder als Alternative zu den Relationen beschrieben werden? Danke.

Dein Rundweg ist wohl eher eine “normal” Route mit roundtrip=*. Das Symbol gehört in die dafür vorgesehen Tags.

Eine Themen-Route hat aus meiner Sicht Informations-/Themen-Stationen. Wenn also auf Deinem Rundweg die Geschichte/Geografie/Geologie/Ökologie/Kunst/Technik etc an bestimmten Punkten erklärt wird, ist es eine Themenroute.

Themenroute ist nur eine Teilmenge von dem, was ich meinte. Themenroute meint so was wie “Lutherwanderweg”.

Gemeint sind aber alle Routen, die anhand eines Namens oder eines Symbols eindeutig referenziert werden können.

Im Radnetz mit FGSV-konformer Wegweisung ist es einfach: Die Netzverbindungen werden durch die Zielwegweiser definiert. Die Radrouten über die “Einschubplaketten”, die unten an die Wegweiser gehängt werden, die Knotennetzwerkverbindungen genauso.

Im Wandernetz könnte man sagen, alle Wanderwege mit einem Symbol sind Routen, alle ohne Symbol sind Netzverbindung.

Allerdings gibt es in manchen Wandernetzwerken ein Symbol für “sonstige Routen”. Dort kann man die Route nicht über das Symbol referenzieren, das wären m. E. eher Netzberbinungen.

Ein Unschärfe ist, dass bei Wanderrouten die Anzahl der verwendeten Symbole of gering ist, so dass sich zwei unterschiedlicher Routen mit z. B. grünen Strich auf weißem Grund mitunter recht nahe kommen. Da braucht es halt Augenmaß bei der Entscheidung ob Route oder Netzverbinung.

Hab mir schon vorgenommen, eine Spalte mit lcn=yes, alternativ bcn=yes hinzuzufügen, falls du das meinst. Mal sehen, ob ich am Wochenende dafür ein Zeitfenster finde.

1 Like

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.