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

Ein Knotenpunktnetzwerk zu taggen ist höllisch viel Arbeit. Gut 80% davon ist nur der Kompensation von SW-Schwächen geschuldet. Warum ist Taggen für den Renderer verpönt, aber taggen für die SW akzeptiert? Für ein Netzwerk möchte ich alle Wege in 1 Relation werfen können und fertig. Ich weiß, dass die Ladezeiten im Browser groß werden, aber ist deshalb ein besonderes Tagging für ein schnelleres Laden gerechtfertigt? Wer mag darf ja, aber ich mag weder müssen noch in meinen Konzepten davon ausgehen wollen.

Ein Maschennetz erlaubt einen besonderen Routing-Algo, der für Liniennetze so nicht anwendbar ist.

Hinweise für die Art der Wegweisung bekomme ich auch von anderen Tags: sind die Knoten benannt/unbenannt? Gibt es Routen und sind sie benannt? Was steht in den „guideposts“? Mir persönlich reicht das.

Reine Netzformen wird man selten antreffen. In der Realität wird es alle Mischformen geben. Das Überwiegende entscheidet. Ein großes Liniennetz mit einigen wenigen Maschen ist immer noch vom Typ „Liniennetz“ und ein Maschennetz mit einigen Zugängen ist immer noch vom Typ „Maschennetz“. In Grenzfällen entscheidet der Mapper. Ein paar Wege hinzu wird den Typ nicht grundlegend ändern.

Generell
Ich möchte einen anderen Zugang zum Proposal vorschlagen:
• Use Cases „Rad- und Wandernetze“ sammeln
• In Varianten taggen
• Bewerten
• Proposal erstellen

Ich verstehe deinen Anmerkungen nicht ganz, ich lese aber daraus, dass wir verschiedene Dinge wollen.

Hab ich es richtig verstanden, dass du es v. a. Routing-Algorithmen einfacher machen möchtest?

Ich möchte eine Unterscheidbarkeit zwischen

  • (I) Rad-/Wanderverbindungen mit klassischer Zielwegweisung,

  • (II) Verbindungen mit Knotenpunktnummer-Wegweisung und den

  • (III) benannten Themenrouten

Zudem möchte ich eine Alternative zu den riesigen Sammelrelationen mit über 2.000 Mitgliedern, die kaum noch gepflegt werden weil man sie nicht mehr pflegen kann.

Das sind verschiedene Dinge. Die Routingalgorithmen habe ich bislang nicht auf dem Schirm gehabt.

Hauptanwendungsfall wird sein, (I), (II) und (III) in der Karte unterschiedlich darzustellen.

Beim Fahrradnetz ist

  • (I) das grundlegende Radverkehrsnetz, dass sich oft auch stark an Alltagsradfahrer richtet (siehe z. B. Radkonzeption von NRW).

  • (III) v. a. Themenradrouten, die über das Netz aus (I) laufen. Sie richten sich meist an Radtouristen.

  • (II) Die Knotenpunktnetze. Sie sind ähnlich (I), haben aber zwischen den Knotennummern benannte und per Symboleinschub ausgeschilderte Routen analog zu (III).

Algorithmen können das nicht erkennen, weil das Tagging in (I) und (III) identisch ist. Woher sollen sie wissen, dass eine bicycle-route-Relation mit ‘ref=NRW’ das Grundnetz mit Zielwegweisung laut (I) beschreibt, eine solche Relation mit ‘ref=PRN’ dagegen eine touristische Themenroute laut (III)?

Daher braucht es einen Tag dafür. Bei (II) gibt es den Tag schon: ‘network_type=node_network’, bei (I) und (II) nicht.

Was meinst du damit? Um zu sehen wie Renderer damit umgehen? Das habe ich für einige Renderer gemacht. Das Ergebnis ist in der Tabelle beschrieben.

Allerdings sollten wir nicht für Renderer taggen sondern den Renderern die Daten liefern, dass sie es unterscheiden können, dass das auch geschieht müssen die Renderprogrammierer aktiv werden. Für eine Akzeptanz von Änderungen ist eine Rendererunterstützung aber Voraussetzung, daher meien Tests.

Ich habe auch probehalber eine solche Riesenrelation in handhabbare durchgehende Verbindungen aufgeteilt, ähnlich der Knotenpunktnetzwerke. Hier die ehemalige Sammelrelation, sie ist nun eine Master-Relation mit den einzelnen Verbindungsrelationen als Mitglieder: Relation 55602: Radverkehrsnetz NRW, Kreis Mettmann

Andere Regionen machen das schon immer so, z. B. das benachbarte Solingen (Relation 8753534).

Da sind wir gerade: In der Tabelle sind Vor- und Nachteile genannt. Den Thread hier habe ich eröffnet, um das zu diskutieren, ergänzen und zu bewerten.

Das war mein Plan, so notwendig. Bei Variante b) laut Ausgangspost wäre es ja nur ein weiterer Wert ‘basic_network’ für einen vorhandenen Schlüssel ‘network_type’. Womöglich ist da ein extra Proposal wie mit Kanonen auf Spatzen schießen.

Danke für Dein Unterstützungsangebot!

Ich hab da nur Laienverständnis. Mit diesem bin ich immer davon ausgegangen, dass die Routing-Algorithmen einfach die Info aufnehmen, das die Wege zum Rad-/Wandernetz gehören. Anhand dieser Info können sie die Wege beim Fahrrad-/Wanderrouting anders gewichten und bevorzugen.

Ich glaube nicht, dass es sich lohnt, extra Routingalgorithmen für Liniennetze zu erstellen. Die vorhandenen Algorithmen können doch ganz gut durch Maschennetze routen, dann schaffen die Liniennetze erst recht. Zumal das Wander-/Radverkehrsnetz ja nicht isoliert ist, sondern verbunden mit den anderen Wegen ohne Wegweisung. Demnach haben wir nahezu immer Maschennetze.

User segubi hat gestern im alten Thread von 2019 Folgendes zum Aufteilen der großen Radverkehrnetz-Relationen geschrieben. Ich zitiere das hier mal, denn es passt gut in die Diskussion.

Nö, finde ich nicht… Ich habe hier in Südbrandenburg einiges an solchen Netzen bearbeitet… Das ist letztendlich nur ein systmatisches zusammenklickern der Routen. Man sollte natürlich immer das Minimum an nötigen Pflichangaben beachten und das Erfasste kontrollieren: https://www.knooppuntnet.nl/en/analysis/cycling/de/networks Was aber durchaus etwas aufwendig werden kann ist die Abarbeitung von Fehlern in den Routen, vorallem unklare Situationen von oneway=yes an Wegeabschnitten oder z.B. unklare access-Angaben.
Viel schlimmer ist ein schlecht oder unvollständig ausgeschildertes Netz in der Realiät ins digitale versuchen umzusetzen.

Sven

Wie du auf dieser Seite schreibst ist Variante (a), Relationen vom Typ network, seit 2011 gelebte Praxis und im Wiki beschrieben. Eine solche Praxis sollte man zugunsten eines neuen Schemas nur dann aufgeben, wenn es dafür stichhaltige Gründe gibt, die von der Mehrzahl der betroffenen Mapper geteilt werden. Diese Gründe sehe ich nicht. Das fehlende Rendering ist ärgerlich, aber das muss mit den Karten-Erstellern geklärt werden.

Ich halte type=network auch deshalb für den angebrachten Relationstyp, weil es sich um Netze und nicht um Routen handelt. Sie bestehen aus Zielwegweisern, auf denen weder die Knoten noch die Verbindungen bezeichnet sind. Verbindungen von A nach B gibt es keine. Wenn in OSM dennoch Verbindungen als Relation erfasst werden, handelt es sich um Verbindungen, die von Mappern aus den Zielangaben und der Verkehrsbedeutung der Endpunkte abgeleitet wurden. In den Planungsunterlagen der Netze, die ich kenne, tragen nur die Knoten bzw. Wegweiser eine Referenz. Bezeichnete bzw. ausgewiesene Verbindungen gibt es dort nicht.

Ich habe mir zu dem Thema in letzter Zeit auch viele Gedanken gemacht, da ich gerade dabei bin, in meiner Region verschiedene Freizeitnetzwerke zu mappen. Ich wende dabei in der Regel so etwas wie Variante b an.

Für die Wanderwege des Schwarzwaldvereins habe ich (in Absprache mit Anderen) das bereits etablierte Tag network:type=node_network verwendet. Dazu hat ein niederländischer Kollege auch ein Proposal angelegt, das auch Knoten mit Namen statt nur ref-Nummern in node_networks möglich machen soll. Wie gesagt wenden ich und einige andere Mapper im Schwarzwald das auch schon an, siehe z.B. Waymarkedtrails. Das Ziel, das Basisnetzwerk von den Themenrouten zu trennen, ist damit also schon ganz gut erreicht, ohne neue Tags zu erfinden.

Beim Radroutennetz geht das leider nicht so leicht, da die Knotenpunkte ja keine Namen oder Nummern haben, was die Voraussetzung für node_network ist. Aber auch hier habe ich einzelne Routen-Relationen zwischen den Knotenpunkten angelegt. Um diese nun abzugrenzen, habe ich den Key cycle_network verwendet. Strecken des Basisnetzes im Landkreis Rastatt haben somit zum Beispiel alle das Tag cycle_network=DE:BW:RA. Wenn Renderer das auswerten würden, würde meiner Meinung nach auch das schon zur Abgrenzung reichen, ohne sich wieder ein neues Tag auszudenken. Auch hier mal als Beispiel Waymarkedtrails. Das selbe habe ich übrigens bei den MTB-Netzen in meiner Gegend gemacht.

Karthoo/Leon

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.