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

Hallo rainerU,

Ja, network-Relationen wäre für mich zumindest Nr 2. Ich könnte gut damit leben, wenn Rendererprogrammierer mitmachen. Aus folgenden Gründen sind sie trotz deiner guten Argumente für mich nicht Nr 1.

Das Argument ist nicht so stark, wie es auf den ersten Blick aussieht. Man könnte sogar sagen wir reaktivieren/reformieren ein veraltetes Taggingschema.

Im Wiki beschrieben ist es erst seit Dezember 2020 vor allem durch mich. Diskutiert wurde das hier ca. 1 Jahr zuvor, ein Proposal oder ähnliches gab es nicht. Der erste Versuch es wiedereinzuführen scheiterte daran, dass massenhaft Relationen aus den Karten verschwanden und das keine Akzeptanz fand.

Gelebt wurden network-Relationen nur in Teilen des Landes und in Kombination mit Riesenrelationen. Das war 2019 weitgehend eingeschlafen, weil die entstandenen Relationen nicht mehr pflegbar waren und dadurch mitunter gnadenlos veralteten mit ‘note=Bitte nicht mehr weiterverwenden’ oder ähnlichem. (z. B. Relation Nr. 1761883 (Landkreis Rems Murr), Nr. 28282 (Münchner Umlandroutennetz) oder Nr. 4525010 (Radverkehrsnetz Stadt Freiburg)). Renderer unterstützen es nicht (mehr).

Außerhalb Deutschlands wird das Schema meines Wissens nach nicht verwendet.

Für Wanderwege wäre das Verwenden von network-Relationen für die Wege-Verbindungen ganz neu.

Das Verwenden von route-Relationen für das Grundnetz ist weitaus verbreiteter. Das Rad-Landesnetz NRW ist z. B. komplett als route-Relationen abgebildet, nur eben ohne Unterscheidungsmerkmale zur Themenradroute.

Kommt darauf an, wie man “Route” und “Netz” definiert.

Im Wiki steht: “Relation:route fasst eine Gruppe von Linien zu einer gemeinsamen Route zusammen (Relation).”. Das würde hier gut passen.

Nimmt man es genauer und macht eine eindeutige Referenz und - durch andere - klar definierten Anfang und Ende als Bedingung, dann passen route-Relationen tatsächlich nicht.

Allerdings bekämen die network-Relationen auch ein ‘route=bicycle’, um die Verbindungen von den Master-Relationen abzugrenzen. Damit würde eine kleine Inkonsistenz zur Aussage, “Verbindungen sind keine Routen” verbleiben .

Wenn man die Verbindungen als network-Relation taggt, die Master-Relationen aber auch, dann hat man zwei verschiedene Auslegungen von network-Relationen in der gleichen Sache. Das verwirrt.

+1

Ich hatte mir eine Relationsvorlage gemacht, die ich für jede Verbindung kopiert habe, so ging das recht schnell.

Alles andere ist identisch zum Mappen von Riesenrelationen, insbesondere wenn draußen etwas nicht stimmt.

Das ist meines Erachtens eine sehr unglückliche Entwicklung, denn hier wird ein vorhandener Wert für etwas verwendet, dass das Gegenteil von dem beschreibt, wofür der Wert stand. Warum nicht einen neuen Wert einführen?

Für mich macht es das umso dringender, passende Werte für ‘network:type’ zu definieren.

“Knotenpunktnetzwerk”*) ist ein Fachbegriff für eine Wegweisung nach Knotenpunktnummern (“Radeln nach Zahlen”). Grundidee war, dass Menschen sich Zahlen leichter merken können als Ortsnamen. In Deutschland wurde sie meines Wissens nur für Radverkehrsnetze angewendet.

Merkmale einer Knotenpunktwegweisung sind

  • Knoten mit Nummern statt Ortsnamen

  • Ausschilderung (nur) der nächsten Knotennummer

  • Karte des Netzes mit den Nummern an den Knotenpunkten

Diese Wegweisung ist in Deutschland zusätzlich zur Zielwegweisung des Grundnetzes, als Einschub unten an den Ziel-Wegweisern. (siehe z. B. Beschilderungsstandards im Radverkehr in Baden-Württemberg pdf, Seite 37)

All das trifft auf das Wanderwegenetz im Schwarzwald nicht zu. Es ist also ein eigener - anderer- Wegweisungstyp.

*) Der Name “Knotenpunktwegweisung” ist m. E. reichlich dämlich gewählt, denn alle Netzwerke sind “Knotenpunktnetzwerke” mit Knoten und Kanten. Wie man hier sieht, sind solche Marketing-Bezeichnungen Steilvorlage für Missverständnisse

Es gibt nach meiner Kenntnis derzeit folgende Methoden, das Radverkehrsnetz eines Landreises/einer Region zu erfassen:

  1. lcn/rcn=yes an den Wegen

  2. Eine große Relation, die alle Wege enthält

  3. Einzelne Relationen für Verbindungen innerhalb des Netzes

Wenn ich deinen Vorschlag richtig verstehe, bezieht er sich auf Realtionen des Typs c). Hier ist in der Tat type=route das zutreffende Attribut. Fasst man die die Verbindungs-Relationen eines solchen Netzes in einer Master-Relation zusammen, wäre für diese jedoch type=network angebracht.

Ergänzend zu deinem Vorschlag und unabhängig davon, für welche Variante wir uns entscheiden, schlage ich vor, die Methoden a) und b) weiterhin zuzulassen und für die Relationen des Typs b) type=network zu empfehlen.

Ich halte es auch für sinnvoll, das Ergebnis vollständig im Wiki-Artikel Radverkehrsnetze_kartieren zu beschreiben und im Artikel DE:Relation:network nur einen Verweis darauf zu belassen. Dann hätte man alles an einer Stelle, somit weniger Pflegeaufwand und ein geringeres Risiko von Inkonsistenzen zwischen den beiden Artikeln.

Ja, dass ist gut. Dann hatte ich dich falsch verstanden.

Danke, ja das ist vermutlich besser. RobHobi und ich wollten das eh’ nochmal überarbeiten. Bislang habe ich es umgekehrt gemacht, alles bei dem jeweiligen Tag beschrieben und in der Übersichtsseite verlinkt.

Mein Vorschlag ist zumindest in Bezug auf Fahrrad-Maschennetze ohne Knoten und “echte” Anfangs-/Endpunkte: Zurück zum Anfang. Bei Wanderwegen gibt es zumindest eindeutige Namen auf den Schildern.

Relationen sind keine Kategorien, galt auch schon vor 10 Jahren, daher verstoßen die großen Sammelrelationen schon immer gegen die Regeln. Auch sollten maximal 2000 Mitglieder in einer Relation sein, was hier nicht möglich ist. Daher lcn=yes an die Wege ohne Relation und gut ist.

Ich habe hier folgendes Bild: Eine unabhängige Stadt und zwei Landkreise in einem Maschennetz ohne jegliche Erkennung wie Namen oder ref an den Wegweisern und mit zum Teil fünf bis sechs eigenen Fahrradrouten mit Symbolen aber ohne jegliche Richtungs- und Entfernungsangaben. Auf dem eigentlichen Weg verlaufen somit die richtigen Routen und sechs bis acht lcn-Abschnitte.

Der Übergang von den Zielen findet nicht an der Landkeis-/Stadtgrenze statt somit gehören die (wenn überhaupt) möglichen Routen für das Netz zu zwei bis drei Netzen. Zusätzlich splittet sich die Richtungsangeben in der Stadt mit unterschiedlichen Varianten durch die Stadt, wo ich dann auch mit Varianten-Relation zusätzlich arbeiten müsste, da ich nach Fahrtrichtung aufgeteilte Teilabschnitte habe.

Nein bitte nicht b) erhalten. Höchsten als Sammlung der einzeln Relationen à la route_master, aber nicht diese Monster. Wenn es um den Bezug von Wegen zu bestimmten Netzen geht, reicht overpass nach lcn=yes innerhalb der Grenzen und an den Wegweisern kann ja operator=* verwendet werden.
Auch habe ich dann eine Abgrenzung zwischen wirklichen Routen und Maschennetzen.

Ja, aber noch sehe ich sie als vereinbar an. Schau‘n wir mal, was noch alles an Ideen und Vorstellungen auf den Tisch kommt.

Andersrum. Der Standardfall ist ein Liniennetz, das können alle mehr oder weniger gut. Das Routen in Knotenpunktnetzen unterstützen nur wenige vollständig:
https://cycle.travel/map?from=47.177,14.686&to=47.1599,14.7605
https://experimental.knooppuntnet.nl/de/map/cycling#5jlgrm-w4sjj2
Schau auf die Turn by Turn Anweisungen und auf die Ausgabe/Knotenstreifen. Es wäre schön, wenn auch Maschennetze mit (Fern-)Zielwegweisung so gut unterstützt werden.

Verstehen wir unter „Netz“ dasselbe? Stell dir folgendes Szenario vor: Der örtliche Tourismusverband von Hatschendorf schildert drei Wanderwege aus. Diese führen vom Dorf zum See, zum Wasserfall und zum Aussichtsturm. Sie sind durchgehend markiert mit einem aufgemalten „gelben Fuß“. An der örtlichen Bahnhaltestelle gibt es einen Übersichtsplan:

Weitere Wegweiser gibt es nicht.

Die Routen haben keinen Namen und auch keine Nummer, sie sind nicht individualisierbar. Man könnte natürlich Namen erfinden und die drei Wanderwege als Routen taggen, aber so ganz sauber ist es nicht.
Sauberer ist es, die drei Wanderwege als Netz zu beschreiben. Maschen hat es keine, die Netzform ist ein Stern. Das ist mein Use Case für das Tag „Liniennetz“ network:type=line_network.

Wie würdest du taggen?

Ich kann diese strenge Sicht nicht teilen. Das wesentliche:
• Die Knoten sind benannt
• Die Wegweisung zeigt zu den Nachbarknoten
ist doch erfüllt. Ob die Benennung mit Namen oder Nummern erfolgt halte ich für unwesentlich.

Da kann ich nicht viel zur Diskussion beitragen, weil ich mich da nicht auskenne. Ich nutze Naviki und OSMAND und bin einigermaßen zufrieden. Ob das Taggen des Unterschieds Maschen/Liniennetz den Routern hilft müsste jemand bewerten der solche Algorithmen schreibt. Um Knotenpunktnetze ging es mir hier nicht.

Ich würde es gar nicht taggen, weil es draußen keine Wegweiser gibt.

Wenn es Wegweiser ohne Symbole oder Knotenpunktnummern gäbe, dann würde ich in einer der eingangs genannten Möglichkeiten taggen.

Wenn alle drei Wege auf gleiche Art und Weise ausgeschildert sind und es keine weiteren Wegweisungen gibt, dann ist eine Unterscheidungsmöglichkeit zwischen Wegweisung ohne Symbole (Grundnetz) und mit Symbolen (Themenwanderwegen) nicht wichtig, denn es gibt nur eines von beiden.

Ob die Wegweisung wirklich ein Netz mit Maschen beschreibt oder nicht, ist mir als Wanderer eigentlich gleich. Ich will nur wissen, wo die Wege mit Wegweisung langgehen und ob ich Symbolen folgen muss und mir Nummern oder Namen einprägen muss. Hier wäre es letzteres. Den Routern möchte ich mitgeben, dass sie beim Wandern diese Wege bevorzugen sollen.

Sorry, dass ich hier ein Nebenthema aufgemacht habe. Lass es uns im Knotenpunktnetzwerke-Thread weiter diskutieren. Ich antworte mal dort: Knotenpunktnetzwerke #193

Wenn du mit “nicht erhalten” meinst, dass dieses Vorgehen für zukünftig zu erfassende Netze nicht verwendet werden soll, dann sind wir uns einig.

Mir geht es darum, dass es neben der Arbeitsweise, bei der das Netz in Punkt-zu-Punkt-Verbindungen aufgeteilt wird, die dann jeweils als Relation erfasst werden, ein weiteres, einfach zu handhabendes Schema für Radverkehrsnetze gibt, das ohne diese Aufteilung auskommt. Ich halte dafür lcn=yes an den Wegen für die beste Lösung.

Beim Lesen des gut ausgearbeiteten Proposals stolpere ich darüber, dass es implizit nur das Thema “Verbindungsrelationen” behandelt, jedoch gar nicht auf Master-Relationen von Wegenetzen eingeht.

Dies wird z.B. deutlich bei Aussagen wie:

Eine fehlende Unterscheidungsmöglichkeit kann ich hier nicht wirklich nachvollziehen, denn Renderer/Overpass/Benutzer können (wenn gewünscht) sehr wohl entscheiden ob eine Routenrelation zum Wegenetz gehört oder nicht: Diese Routen sind Member einer Netzwerk-Relation, die Themenrouten hingegen nicht.

Die ganze Motivation des Proposals kommt also nur dann zum Tragen, wenn das Wegenetz nicht durch eine (Master) Netzwerk-Relation abgebildet wird (z.B. Radwegenetz Landkreis Kassel).

Damit ergeben sich aus meiner Sicht zwei grundsätzlich verschiedene Möglichkeiten das Thema anzugehen:

1. Verwendung von Netzwerk-Relationen
Jedes Wegenetz wird in OSM durch eine Netzwerk-Relation mit type=network (und route=hiking/bicycle) beschrieben.
Verbindungsrelationen mit route=hiking/bicycle und type=route als member in diese Netwerk-Relation (wird i.A. bei den populären Renderern dargestellt). Die Netzwerk-Relation wird damit zur Master-Relation.
Oder für kleine Netzwerke die Wege direkt in der Netzwerk-Relation. Das ist dann Vorschlag (a).
Sind Knotenpunkte mit Nummer oder Name versehen, werden diese auch als member in die Netzwerk-Relation mit aufgenommen.

Dieses Vorgehen entspricht dem existierenden Vorgehen bei Radroutennetzen/Fahrradknotenpunktnetzwerken sowie Knotennetzwerken im Allgemeinen.

Eine Unterscheidungsmöglichkeit zwischen Themenrouten und Wegenetzen ist über die Mitgliedschaft in der Netzwerk-Relation gegeben.

Eine Unterscheidungsmöglichkeit zwischen Wegenetztypen (reines Verkehrsnetz oder Knotenpunktnetzwerk mit Nummer oder mit Name oder Mischform) ist durch die Mitgliedschaft der Knotenpunkte sowie deren Tags gegeben. Möchte man diese Unterscheidungsmöglichkeit der Wegenetztypen zusätzlich mit einem Tag an der Netzwerk-Relation beschreiben ist network:type sinnvoll. Z.B. mit dem etablierten Wert node_network für Knotennetzwerke oder neuen Werten wie das vorgeschlagene basic_network für eine noch genauere Unterscheidung.

2. Ohne Netzwerk-Relationen
Möchte man keine Netzwerk-Relationen benutzen fehlt schlichtweg erstmal die Information ob es sich um ein Wegenetz handelt oder nicht. Diese Information sowie alle weiteren Infos zum Wegenetz müssen deshalb an die einzelnen Verbindungsrelationen getaggt werden.
Dafür gibt es dann viele Möglichkeiten (Vorschläge (b)-(d)).

Netzwerkrelationen sind also mehr als reine “Sammelrelationen”, denn sie beinhalten die Information das hier ein Wegenetz existiert.

Vorteil von 1. sehe ich darin das es ein erprobtes Vorgehen ist und keine Änderungen beim Tagging vorhandener Routenrelationen notwendig ist. Aber 2. ist auch möglich.

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.