Grundsätzlich wäre ich dafür, Knotenpunktnetzwerke in eine eignene Kategorie zu packen… z.B. network=kpn (oder so; fixe Idee von mir…) Knotenpunktnetzwerke passen nicht wirklich im network =lcn|rcn…
Grundsätzlich sehe ich solche Zielwegweisungen auch als Routenrealationen im weiteren Sinne an…
Aber ich würde diese eine Rangstufe herunter setzen…
Also:
Grundsätzlich finde ich die Richtung sehr gut. Nur die Formulierung „besonders gut geeignet“ macht mir Probleme. Für „Wen“ gut geeignet? Alltag oder Freizeit? Sportlicher Student oder Familie mit kleinen Kindern? Warum nicht einfach nur als „ausgeschildert mit normaler Wegweisung“ definieren?
Ups, so habe ich das gar nie verstanden. Wenn sie durchgehend ausgeschildert sind, braucht es das Kriterium „Punkt zu Punkt“ oder „Rundkurs“ eigentlich nicht mehr extra. Oder? Hab‘ das bisher als Ergänzung zum besseren Verständnis verstanden.
Ich lese deinen Vorschlag so: Wege müssen eine Form (Linie/Kreis) haben ODER sie müssen eine Bezeichnung haben.
Da könnte man endlos diskutieren, es gibt einfach zu verschiedene Radlertypen und -ansprüche.
Grundgedanke ist nur der, dass ich als Radfahrer davon ausgehen darf, dass ausgeschliderte Radrouten fahrradtauglich sind, also nicht durch weichen Sand verlaufen oder Schlamm oder schlimmes Kopfsteinpflaster und dass sie nicht über eine Bundestraße ohne Radweg führen. Also das “besonders gut” gerne weglassen.
Das die Erwartung nicht immer erfüllt wird ist eine andere Sache. Hatte schon Radwegweiser an Wegen, wo aufgrund des weichen Sandes schon das Schieben sehr schwer fiel.
Worin unterscheiden sich 2) und 4) genau?
Bei 2.) ohne den Anspruch, dass das Ober-Ziel die ganze Zeit gleich bleiben muss und ohne dass es eine Route mit efinierten Beginn und Anfang ist?
Bei 4.) mit diesem Anspruch?
und 3. kann man eigentlich zusammenfassen, denn es ist nur eine andere Beschilderung des selben Netzes. Bei 3. werden die Knoten mit deren Nummern mitgetaggt und auch dargestellt, bei 2. halt nicht - beides so wie heute praktiziert. Die Knoten können ja auch in die Relation aufgenommen werden.
Wenn man für 2. und 3. ein eigenes ‘route=cycle_network’ definiert, kann man mittels ‘network’ angeben, wie groß das Netz ist. In Sachsen z.B. ist es Sachsenweit einheitlich (rcn), woanders nur ein Landkreis (lcn).
Ich war zunächst etwas verwirrt, wie man diese Info‘ in OSM verarbeiten kann. Ich hatte noch irgendeine Abkürzung in Erinnerung, bis mir dann wieder “lcn” einfiel. Also danach im wiki nachgeschlagen und man kann von lcn=yes zu diesem Abschnitt des vorherigen Verweises gelangen: https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks
So wie ich es dort verstehe, können die betreffenden Wege, auf die sich diese Zwischenwegweiser beziehen, mit lcn=yes versehen werden. Aber nur dann, wenn an diesen Zwischenwegweisern (und nachfolgenden Pfeil- / Tabellenwegweisern) **keine **zusätzlichen Piktogramme oder andere Markierungen - die auf Radwanderwege hindeuten - vorhanden sind. Denn dort wo eine Zusatzinfo für eine spezielle Route vorhanden/erkennbar ist, wird empfohlen eine Radrouten-Relation zu erstellen anstatt lcn=yes zu benutzen?
Es wäre es schön, wenn wir diese Zwischen-, Pfeil- und Tabellenwegweiser zusätzlich als Beispiel unter information=guidpost aufnehmen + zusammen mit der dort sofortigen Info‘, wie damit in Bezug auf []](https://wiki.openstreetmap.org/wiki/DE:Relation:route) / {{Tag| route| bicycle}} & {{Tag| lcn|yes}} umgangen werden sollte.
Ne, lcn=yes hat nur indeirekt mit Zwischenwegweisern zu tun. ‘lcn=yes’ ist meines Wissens gleichbedeutend mit ‘network=lcn’. 'network=lcn ’ heißt, dass eine Fahrradroute ist, die den Landkreis oder die Kommune nicht verlässt. Ob der Tag am Weg oder in eine Relation gesetzt wird, ist für die Karte unwichtig. Es löst damit auch nicht das Problem zur Unterscheidenung zwischen Fahrradroute (1) und Fahrradnetzwerk (2).
lcn an den Weg zu schreiben anstatt in eine Relation macht m.W. heute nahezu keiner mehr. Es ist sehr unpraktisch weil schlecht zu warten. Deswegen steht das meines Wissens auch nicht mehr im deutschen Wiki.
Was wir brauchen ist ein Tag, mit denen wir einzelne Fahrradrouten (Mit Namen, Symbol und/oder Nummer) von einem Fahrradnetz (mit Fahrrad-Wegweisung versehendes Wegenetz) unterscheiden können.
Desto länger ich drüber nachdenke, desto mehr wird mir klar, dass es schlichweg falsch ist, was die Mapper in NRW und in SH getaggt haben. Ebenso wird mir klar, dass es für die Lösung keines neuen Tags bedarf. Ich sah den Wald vor Bäumen nicht.
In NRW und SH wurden ganze Netzwerke als eine Route getaggt (z. B. Relation 2003636) oder aber als viele kleine Routen, die selber kein richtiges Anfang und Ende haben und schon garnicht Namen, Symbole oder Nummern (z. B. Relation 1772270).
Eine Route kann man in einem Stück abfahren, sie ist kein Netzwerk. Eine Route ist maximal Teil eines Netzwerkes. Dementsprechend ist auch mein Vorschlag mit ‘route=cycle_network’ Quatsch.
Um Netzwerke in Relationen zu packen gibt es Netzwerk-Relationen, siehe Relation:network.
Hier wäre also korrekt:
<relation>
<tag k="type" v="network" />
<tag k="network" v="lcn" />
<member type="way"> 'für zum Fahrradnetz gehörende Wege
...
<member type="relation"> 'für zum Fahrradnetz gehörende Routen (type=route) oder Teilnetze (type=network)
...
<member type="node" role="guidepost"> 'ggf. für Wegweiser
...
<member type="node"> 'ggf. für Knotenpunkte, wennn es sich um ein Knotenpunktnetzwerk handelt.
</relation>
Netzwerk-Relationen sind scheinbar unbeliebt, weil diese oft missbraucht wurden, um beliebige Dinge zu sammeln (Alle Telefonzellen in Niedersachsen). Hier sehe ich aber eine Anwendung mit Mehrwert, denn die Information, dass Wege zum Fahrrad-Netzwerk gehören müsste sonst an jeden Weg und Wegweiser geschrieben werden. Zudem kannn eine Weg zu verschiednenen Fahrradnetzwerken/-routen gehören, was sich mittels relatuionen besser abbilden lässt.
Wenn Du dies etwas mehr im Detail bzgl. der Bundesländer anschauen möchtest dann ggf. folgende Verweise benutzen, und eventuell noch andere Bundesländer im Script:
Für Niedersachsen: https://overpass-turbo.eu/s/Jyk
Für Sachsen: https://overpass-turbo.eu/s/Jyl
Es gibt da starke Unterschiede von Bundesland zu Bundesland wie häufig lcn=yes verteilt ist.
Und wie häufig lcn=yes nun tatsächlich ohne Relation verwendet wurde kann ich auf Anhieb nicht sagen, da könnten vielleicht GIS- oder sonstige Datenbank-Softwarespezialisten mal eine geeignete Auswertung erstellen…
Gute Beispiele für den Missbrauch von Routen. Den Mappern mache ich das nicht zum Vorwurf, sie sahen nur keine Alternative. Ich kenne auch keine.
Dein Vorschlag zu „Relation:network“ klingt logisch, aber löst es unser Problem? Ich bin mir da unsicher. Ich versuch mal einen Lösungsweg zu beschreiben. Vielleicht ist er ohnehin in deinem Vorschlag enthalten. Von Anfang an:
Eine Route hat folgende Eigenschaften:
ist durchgehend ausgeschildert bzw. markiert UND
hat einen (Eigen-) Namen, Nummer, Symbol oder Zielbezeichner UND
hat Anfang und Ende oder ist ein Rundkurs. Es ist kein Netzwerk!
Der Zielbezeichner ist der „Start – Ende“-Name bei zielwiederholter Wegweisung (Ausgangspost) bzw. in Knotenpunktnetzwerken.
Mir ist die UND-Bedingung zu den Bezeichnern wichtig, weil sie die Identifizierung vor Ort ermöglicht. Ein erheblicher Mehrwert. Der Bezeichner sollte auch unbedingt im Datensatz aufgenommen werden und nicht optional.
Du hast es ja schon geschrieben: Routen können ein Netzwerk bilden, eine Route kann aber kein Netzwerk sein. Explizit in den Kriterien hingeschrieben macht es aber einiges klarer.
Die Abschnitte zwischen den Knoten im Fahrradknotenpunktnetzwerk sind mit dieser Definition abgedeckt. Die Zusammenfassung in einer (weiteren) Relation hast du angesprochen.
Es bleibt noch der große Rest der Wege mit normaler Wegweisung und die der amorphen Netze, die – weil ohne Alternative – in die Routen gepresst wurden. Beispiele:
Radwegenetze in Städten mit normaler Wegweisung, ohne Routencharakter (Zürich, Ulm, Lübeck …)
Radwegenetze in Regionen mit normaler Wegweisung, ohne Routencharakter (NRW, SH …)
MTB Trails
Die unechten Routen könnte man „Tour“, „Itinerary“ oder was auch immer nennen. Die unechte Route hätte folgende Eigenschaften:
Sie verwenden ‘lcn=yes’ am Weg als Alterative zur Fahrradrouten-Relation und beschreiben das als gleichwertig. Ist es aber nicht. ‘lcn=yes’ am Weg lässt offen, was für ein Teil des Fahrradnetzwerkes der Weg ist.
Es kann aber auch einfach ein mit Wegweisern versehenes Netz ohne Fahrradroute drüber sein. Die Entsprechung als Relation wäre dann die von mir angesprochene Netzwerk-Relation (Relation:network)
Demnach ist ‘lcn=yes’ an den Wegen zwar unkonkreter, aber dadurch nicht falsch, selbst wenn über den Weg keine fahrradroute drüber läuft.
Wenn man konkreter sagen will, ob es eine Fahrradroute oder ein Fahrradnetzwerk ist, dass kommt man um die route bzw. network-Relation nicht herum.
Warum bist du unsicher? Es ist eine Lösung für den real existierenden Bedarf, das ausgeschilderte Radverkehrsnetz über Relationen abzubilden. Es bietet eine Alternative für den real existierenden Missbrauch der Route-Relationen.
Deine Abgrenzungsvorschläge im Wiki für Route-Relatonen finde ich auch gut. Dort sollten wir deutsich machen, was nur “network” ist.
Nur bei einem habe ich Bedenken:
Bei deiner Forderung nach durchgängigem Zielbezeichner sehe ich das von Pajopath geschilderte Problem, dass dies in der Praxis nicht ganz sauber durchgezogen wird/werden kann. Zwei fiktive (!) Beispiele, die mir dabei zusätzlich eingefallen sind:
Eine regionale Route verläuft z. B. von Halle nach Leipzig. Auf den Wegweisern steht bis zum Stadtrand “Leipzig”. Ab dem Stadtrand steht z. B. “Rathaus”, denn "Leipzig wäre innerhalb der Stadt wenig hilfreich.
In A-Stadt starten 3 Fahrradrouten nach B-Stadt, C-Stadt und D-Stadt. Anfangs verlaufen diese zusammen mit anderen Rouen auf dem gleichen Wegen. Da der Platz auf den Wegweisern begrenzt ist, wird anfangs nur “B” und “C” ausgeschildert, nicht jedoch D. Erst nachdem die Route nach B von dem gemeinsamen Weg abzweigt, erscheint auch “D” auf den Wegweisern. In der Gegenrichtung steht jedoch von D-Stadt bis A-Stadt auf den Wegweisern “A”
In beiden Fällen wechseln die Ziele auf den Wegweisern, einmal wird das Ziel konkretisiert, das andere mal ist kein Platz drauf. Beide Routen sind aber m.E. durchgängige Routen in dem Sinne von DE:Fahrradroutentagging.
Ich bin mir aber unsicher, was man tun sollte
Forderung etwas weicher machen, z. B. ein “größtenteils durchgängigen” Zielbezeichner.
konkrete Beispiele benennen, wann Zielbezeichner nicht durchgängig sein müssen
die Definition nicht weiter konkretisieren oder weichmachen
a) hat das Risiko, dass dann wieder beliebige Netzwerk-teile in die Routen-Relationen geschrieben werden.
b) bläht das Wiki weiter auf, irgendwann liest/versteht das keiner mehr
c) provoziert Diskussionen und ggf auch Streit.
Ich habe es nicht als gleichwertig beschrieben, sondern sage, dass man die mit lcn=yes getaggten Wege einer Stadt oder eines Landkreises jederzeit auf einfache Weise in eine Relation überführen kann, wenn dies für sinnvoll und notwendig erachtet wird. Wenn dies jemand machen will, ist das ok für mich. Er sollte dann aber auch die weitere Pflege dieser Daten sicher stellen. Mir ist das Pflegen solcher Monsterrelationen zu aufwändig.
Ich habe mit “sie” die Webseiten gemeint, nicht dich .
Diese Riesen-Relationen finde ich auch gruselig, alleine die Ladezeit im Browser! Besser wäre es, die einzelnen Stränge als Teilnetz in einzelne Relationen zu taggen, so wie das beim Knotenpunktnetzwerk auch gemacht wird. In einer übergeorneten Netzwerk-Relation wird dann nur auf die Relationen der Teilnetze verwiesen. Das macht sie wesentlich schlanker.
Relationenen haben den Vorteil, dass man weitergehende Infomationen nur einmal an zentraler Stelle schreiben kann, das macht das Pflegen wesentlich einfacher. (Z.B. Infos zum Betreiber des Netzwerkes, des Namens und ein Link zu weiterführenden Informationen)
Wenn in einer Relation jeweils nur ein Strang enthalten ist, lässt sich die Vollständigkeit leichter überprüfen, diese Prüfung könnte man sogar automatisieren.
Auch lassen sich so Wege leichter mehreren Netzwerken und Routen zuordnen.
Nachteil ist, dass Relationen v.a. für Anfänger schwerer zu verstehen sind und deren Pflege in den Editoren nicht überall komfortabel ist.
Die riesigen Route-Relationen scheinen eine Spezialität aus NRW zu sein.
Ich habe eben gesehen, dass in Schlesweig-Holstein die Radverkehrsnetze tatsächlich schon als Relation ‘type=network’ mit ‘route=bicycle’ getaggt wurden, siehe DE:Radverkehrsnetz_Schleswig-Holstein#Kreise.
In Stuttgart dagegen hate man 2015 als “proof of concept” ausprobiert, wo jede Strecke zwischen den Wegweisern eine eigene Route-Relation werden sollte, siehe Stuttgart/Radroutennetzwerk. Ergebnis ist es eine Mischung aus Relationen und lcn=yes an den Wegen, gut anzusehen auf cycling.waymarkedtrails.org.
Mir ist unklar, ob die in Stuttgart als ‘ref’ und ‘lcn_ref’ angegebenen Routen-Nummern am OSM-Stammtisch definiert wurden. Wenn ja, wird das m. E. die Radfahrer draußen eher verwirren und der “on-the-ground”-Regel widersprechen.
Ulm empfiehlt das Taggen von lcn=yes an die Wege, schließt aber network-Relationen aber nicht aus, siehe Radverkehrsnetz_Ulm/Neu-Ulm.
Insofern ist die network-Relation für Fahrradnetzwerke eigentlich etabliert, so dass wir sie auch ins Wiki aufnehmen könnten. Nur das Netzwerkrelationen einen tag ‘route=bicycle’ erhalten ist m. E. falsch, wenn dann ‘network=bicycle’, besser jedoch ‘network=lcn/rcn/ncn/icn’.
Die Stuttgarter Routen-Relationen sind m. E. aber eher type=network, auch wenn Sie einen Beginn und Ende haben. Es sei denn, die Nummerrierung findet sich tatsächlich an den Wegweisern wieder. @ Robhubi, wie passt das zu deinem Vorschlag, die durchgehende Zielführung auf den Wegweisern als Kriterium für eine Route stärker hervorzuheben? Demnach würden solche Mini-Strecken Routen-Relationen sein und nicht Netzwerk-Relationen, ähnlcih von Knotenpunktnetzwerken.
Ulm empfiehlt nichts. Ebenso wie die anderen Wiki-Seiten, die du verlinkst, beschreibt die Seite das Tagging, auf das sich einige lokale Mapper in Ermangelung eines global eingeführten und dokumentierten Taggingschemas angesichts der örtlichen Situation geeinigt haben. Dort, wo sich aus der Beschilderung Punkt-zu-Punkt–Routen ablesen lassen, z.B. aufgrund eines durchgängig aufgeführten Ziels oder über eine Nummerierung, hat man sich für das Erfassen als Routen-Relationen entschieden. Dort, wo wie z.B. bei uns in Ulm/Alb-Donau keine Routen erkennbar sind und das Netz zu sehr verästelt ist, um es in Routen aufzudröseln, setzt man ein lcn/rcn=yes an die Wege.
Da beide Methoden von diversen Renderern und Routern ausgewertet werden, halte ich das für ein pragmatisches Vorgehen und sehe keinen Grund, daran etwas zu ändern. Hinzu kommt, dass die Radverkehrsnetze nahezu ausschließlich von Einzelmappern und kleinen lokalen Gruppen mit großem Aufwand erfasst und gepflegt werden. Denen Relationen aufzudrängen, wo es Tagging an den Wegen auch tut, ist kontraproduktiv, weil es zusätzlichen Aufwand ohne signifikanten Nutzen produziert.
Natürlich empfehlen die Wiki-Seiten Tagging-Schemas. Genau das ist das Ziel des Wikis, Orientierung beim Tagging zu geben.
Ich erkenne hier niemanden, der jemanden etwas aufdrängen möchte. Alles hat seine Vor- und Nachteile. Diese aufzulisten bedeutet nicht, jemanden etwas aufzudrängen!
In dieser Diskussion ging es bisher darum,
dass die Wiki-Beschreibung von route-Relationen zwingend Nummer, Symbol oder Namen fordert. Die Intention des Ausgangsposts von Robhubi ist, ob die Formulierung nicht angepasst werden sollte, so dass eine konsistente Zielwegweisung auch ausreicht.
wie hart die Forderung nach konsistenter Zielwegweisung sein muss, da mitunter die Zielbeschreibungen sich auf der Route ändern oder weggelassen werden (Post von Pajopath und von bus-mt).
ob die Taggingschemas statt in lokalen Seiten von diversen Akteuren (Ulm NRW Bayern) besser zentral dokumentiert werden sollten (lcn/rcn=yes und network-Relationen sind im deutschen Wiki gar nicht beschrieben)
ob die Abgrenzung zwischen route-Relationen und network-Relationen klar genug beschrieben ist
ob ein tag ‘route=bicycle’ an einer network-Relation sinnvoll ist
Möchte mich zunächst noch auf den Ausgangspost konzentrieren …
Sehe kein Problem. Die Route „Halle – Leipzig“ geht bis zum Stadtrand Leipzig. Dort beginnt ev. eine neue Route mit Hauptziel Rathaus und wechselnden Unterzielen Stadtteil 1, Stadtteil 2 … Um auszudrücken, dass sie zusammengehören, kann man sie in einer Relation zusammenfassen.
Bei der Namensgebung würde ich elastisch sein. Ergänzungen aus dem Kontext heraus, können für Eindeutigkeit sorgen, sollten aber durch Klammern kenntlich gemacht werden. Beispiele:
für das Ziel: „Rathaus“ oder eindeutig „(Leipzig) Rathaus“
für den eindeutigen Zielbezeichner: „(Halle – Leipzig Stadtrand) – Rathaus“. Davon findet sich „Rathaus“ am eigenen Schild und „Halle“ beim benachbarten Schild für die Gegenrichtung. Das sollte für die Identifikation reichen.
Wenn die umgekehrte Fahrrichtung ähnlich ausgeschildert ist, dann gibt es am Ende 4 Relationen, die man, wie erwähnt, in einer weiteren Relation wieder zusammenfassen kann.
Du meinst so?
(B) (C)
║ ║
(A)=========(X)=====(Y)=====(D)
Lösungsvorschlag
Route A ↔ B: Relation(A-B)
Route A ↔ C: Relation(A-C)
Route A ← D: Relation (A-D)
Teil-Route1 von A → D: Relation(A-X) *)
Teil-Route2 von A → D: Relation(X-D)
Route A → D: Relation(Teil-Route1 + Teil-Route2 )
Route A ↔ D: Relation(Route A ← D + Route A → D )
*) Die Relation(A-X) bezieht sich auf die Route nach B-Stadt! Zielbezeichner: „A – B-Stadt (Teil bis Abzw.)“
Schaut vielleicht kompliziert aus, ist aber im Prinzip einfach:
bilde (Teil-)Routen genauso wie sie ausgeschildert sind. Die gesamte Route wird dabei u.U. in Teilstrecken und in vorwärts/rückwärts Richtung zerlegt
Die Teil-Routen in weiteren Relationen wieder zusammenfassen, analog zu EuroVelo-Routen.
Ja, die Mini-Strecken würde ich auch als Routen-Relation sehen. Was nicht passt sind die Knotenpunkte. In dieser Routen-Relation findet sich bei den Knotenpunkt-Wegweisern die Knotenpunkte **nicht **als Ziel. Ich sehe keinen Grund, diese Wegweiser als Knotenpunkte, im Sinne von Fahrradknotenpunktnetzwerke , zu bezeichnen.
.