Bitte, bitte, bitte
lasst die Diskussion nicht ausufern, bleibt beim Thema. Der Kommentar eines Kommentars eines Kommentars allein ist selten zielführend.
Danke, danke, danke
Zwischenstand zum Thema: zielorientierte Wegweisung mit Zielkontinuität – ist das generische Beispiel eine Route im OSM-Sinne?
Prince Kassad: nein
JochenB: gefühlsmäßig ja
Nop: ja, analog zu Wanderwegen
Galbinus: ?
Pajopath: ?
bus-mt: ?
Das gibt noch viel Stoff zum Diskutieren 
Ich sehe nicht, wieso es nicht reichen sollten den Wegweiser als guidepost einzutragen, und fettich. 
Also: nicht als Route eintragen.
Dein Beispiel 1 interpretiere ich gefühlsmäßig als Zustimmung.
Die Widersprüche im Wiki sollten wir beseitigen. Ich arbeite da gerne mit. Erstellen wir zuerst eine Liste von Problempunkten (werden ja nicht so viele sein) und arbeiten sie dann Punkt für Punkt ab.
Der Wegweiser "Detmold 10.5km“ ist eine normale Wegweisung, die mit einer Route nichts zu tun hat. Es fehlt die durchgängige Ausschilderung mit Zielkontinuität. Dasselbe gilt für Wegweisungen zu Nachbarorten an Abzweigungen.
Radnetze mit normaler Wegweisung, die keine routentypische Zielführung haben, sollen m.E. auch nicht in einer Relation erfasst werden. Das möchte ich aber nicht hier diskutieren. Der Archetyp „Radnetz mit normaler Wegweisung“ verdient einen eigenen Thread, genauso wie mein Archetyp hier.
Jedes Fernziel wird irgendwann mal zum Nahziel. Meist am Ortsrand wird das Fernziel gewechselt und das ehem. Fernziel wird zum Nahziel, oft mit dem Zusatz „… Mitte“ oder „… Zentrum“.
Der Routenanfang ist der Pfosten wo das Fernziel zuerst auftaucht, das Routenende ist der Pfosten wo das Fernziel wechselt.
Dasselbe Problem wie mit Lücken in der Ausschilderung. Wie löchrig darf es werden, bevor man sagt, dass ist nun wirklich keine Route mehr? Da gibt es kein einfaches Rezept.
So tagge ich Radfahrwege mit normaler Wegweisung. Ausgeschilderte Radfahrwege mit durchgehender Zielführung haben eine besondere Qualität.
Was genau ist verbesserungswürdig?
Und genau das ist laut Wiki nicht zulässig, den die Route ist weder eine Rundroute noch hat sie ein genau definierten Start oder Ziel.
Ich verstehe den Wunsch, solche Netzerke zu taggen, dann müsste das Wiki angepasst werden.
Ich sehe aus der Diskussion, dass es zwei unterschiedliche Fragen sind, die mit den Fahrrad-Relationen beantwortet werden sollen:
Fahrradrouten: Wo führt die Radroute “Elbradweg” oder “Zentrum - Kulkwitzer See” lang?
und
Fahrradnetz/Fahrradknotennetzwerke: Welche Straßen/Wege sind für Radfahrer besonders gut geeignet und mit Wegweisern versehen?
Parallel läuft hier noch die Diskussion, ob Radschnellwege eine eigene Relationsart oder eine eigene Straßenklasse bekommen. Das würde ich hier mal außen vor lassen und dort diskutieren.
Die Definition im Wiki gilt für 1). Für 2) gilt sie nur bei Fahrradknotennetzwerken. Im Wiki wird zudem das Vorhandensein von eindeutigen Namen, Nummern oder Symbole gefordert.
Angewendet wird die Relation route=bicycle jedoch sehr häufig für 2) auch wenn es keine Fahrradknotennetzwerke sind, siehe NRW oder SH.
Praktisch ist es ja so, dass das Land mit der Definition eines Fahrradnetzes ein Grundnetz an fahrradtauglichen Wegen schafft. Ein Standard dieser Wege ist eine Fahrradwegweisung. Der Wunsch dieses in OSM darzustellen ist verständlich und es wurde schon viel Arbeit geleistet, größtenteils entgegen der Wiki-Definition.
Die Fahrradrouten werden über das Fahrradnetz gelegt, dazu werden i.d.R. Symbole auf Blechschildchen an die Wegweiser des Grundnetzes gehängt. Zielgruppe sind entweder Touristen (“Elbradweg”) oder Alltagsfahrer (Radschnellwege, innerstädtische Routen). Sie werden häufig stark vermarktet und ändern sich auch abundzu. Diese Routen sind i. d. R. alle erfasst.
Wenn man beides mit dem selben Relationstyp abbildet, so ist der Unterschied nicht mehr erkennbar (Es sei denn, sie unterscheiden sich zufällig bei ‘network’).
Hier müsste eigentlich ein neuer Relationstyp her
Fahrradrouten: route=bicycle
Fahrradnetz: route=cycle_network
Was haltet ihr davon?
Unabhängig davon würde ich die harte UND-Verknüpfung:
“Wege müssen Start und Ende haben bzw Rundrouten sein” UND “Wege müssen Symbole, Nummern oder Namen haben”
in eine ODER-Verknüpfung ändern. Damit fallen Fahrradrouten mit durchgehender Zielweisung immer unter 1).
Spricht da etwas grundsätzlich dagegen?
Uhi…die Radler wieder… 
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:
Je nachdem, was wir haben, sollte ein entsprechendes Rendering erfolgen.
Sven
+1
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.
???
Bin verwirrt.
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?
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).
+1
Ich habe jetzt nicht alles durchgelesen, aber vielleicht passt das dazu, falls nicht dann überlest es einfach.
Ich bin letztens an so einen sehr ähnlichen Zwischenwegweiser vorbeigekommen, wie er hier zu sehen ist:
https://wiki.openstreetmap.org/wiki/File:Zwischenwegweiser_Rad.svg
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.
**Was denkt ihr, sollte man Netzwerk-Relationen auch im deutschen Wiki als DE:Relation:network dokumentieren und in DE:Fahrradroutentagging darauf verweisen? **
**Sollten wir als ‘route’ getaggte Netzwerke in Netzwerk-Relationen abändern? **
Also hier gibt es eine grobe Übersicht wie lcn=yes zur Zeit auf der Erde verteilt ist.
https://taginfo.openstreetmap.org/tags/lcn=yes#map
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…
Zu lcn=yes gibt es auch eine andere Auffassung. Siehe z.B.
https://wiki.openstreetmap.org/wiki/Radverkehrsnetz_Ulm/Neu-Ulm
https://forum.openstreetmap.org/viewtopic.php?id=64437 #6
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:
Ist beschildert
ist eine Wegstrecke oder ein Netz
Deckt sich das mit deiner Vorstellung?
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 ein Teil einer Fahrradroute sein im Sinne von DE:Fahrradroutentagging.
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.