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