Heißt das, dass die Zielkontinuität aufgehoben ist? Wenn nein, wäre nichts einzuwenden. Problematisch ist, wenn man einen Wegweiser “Riegelsberg” oder “Fischbach” hätte, und am Folgewegweiser stände plötzlich nur noch “City”. Und selbst das wäre eigentlich auch nur ein Konsistenzfehler, aber halb so problematisch, solange keine Abzweigung besteht.
(Da das in dann NRW ein Verstoß gegen das Regelwerk wäre, und der Betreiber explizit über Feedback in einem Meldesystem bittet, mappe und melde ich sowas, wenn ich die Zeit habe, markiere das als Ausschilderungsfehler mit fix_guidepost und gebe an, wann ich das gemeldet habe. (S. DE:Key:fix_guidepost - OpenStreetMap Wiki ). So können andere User entscheiden, ob sie den Fehler auch melden wollen, bzw. ob sie noch abwarten wollen.)
Ich mappe solche Routen dann, wenn man sie konsistent benutzen kann, als Relationen mit network:type=basic_network. Als Relation verwende ich dann den Abschnitt von Abzweigung zu Abzweigung, so dass jemand, der 1-2 Jahre später dort mappt, einfach für die Abschnitte das survey:date=xyz hochsetzen kann, so dass man ein Bild von der Aktualität des gemappten Netzwerkes hat. (Das ist beim Taggen nur am Weg mit erheblichem Aufwand ansatzweise möglich, und bei großen Sammelrelationen ebenfalls nicht…)
Zum Wegweiser Dankkapelle 2,3 km; Derlen 1,8 km:
… das ist nicht der Grund. Es gilt einfach die Regel: Oben das Fernziel, unten das Nahziel. Wenn man das Nahziel erreicht hat, rutscht ein anderes Fernziel nach oben.
… man könnte die “nicht-konformen” Routen auch noch differenzieren in Routen, die nur über gelegentlich aufgestellte Landkarten markiert sind - dabei dennoch öffentlich und allgemein zugänglich, und eben die miniaturisierten Aufkleber.
Siehe hierzu z.B. auch die Diskussion um den Stoneman Miriquidi Road (Changeset: 140945165 | OpenStreetMap, Relation: Stoneman Miriquidi Road (16299539) | OpenStreetMap), das ist kein Einzelfall. Ich habe auch von einer Löschung des (nur sehr kurzen) EULE-Radweges in Lemgo (Relation: Radweg EULE (123192) | OpenStreetMap) abgesehen, da er on the ground nachvollziehbar ist - wenn auch die Karten nur sehr vereinzelt stehen.
Problematisch finde ich so etwas in der Anwendung allerdings schon, da auf Karten, die über route-Relationen gerendert werden die Illusion eines ausgeschilderten Radweges erzeugt wird, und bislang keine Chance besteht, diese Routen aus der Darstellung herauszunehmen.
Auch hier wäre ein “conformityxyz=no” hilfreich.
Ich ergänze eine Inkonsistenz bzw. offene Frage: Beim Mappen der Wegweiser der Knotenpunktnetzwerke ist es eine schon seit vielen Jahren ziemlich verbreitete Praxis, die Knotenpunkte unter den Zielen mit KP xy anzugeben (z.B. direction_north=“Spenge 8.7 km; KP 51”). Das ist auch konsistent und leicht mit einem einfachen Algorithmus auszuwerten.
Mit dem neuer eingeführten key direction_nswo:route scheint es auf den ersten Blick naheliegend, die Routeneinschübe für die Knoten mit aufzuführen: “direction_north:route=Mühlenroute;17”.
Hieraus ergeben sich aber Probleme: Es gibt dann keine route, die durch 17 referenzierbar ist. Es ist ohnehin schon nicht einfach, die zugehörigen Relationen zu den Schlüsseln zu identifizieren, die bislang beobachtbaren Einträge müssen mindestens gegen die Keys “name” und “ref” der Relationen abgeglichen werden. Es besteht die Gefahr, dass auch mal unter “ref” lediglich Zahlen stehen können, so dass nicht eindeutig würde, ob Knotenpunkte oder nummerierte Routen gemeint sind. (In Preußisch Oldendorf z.B. wechselt die Auszeichnung der alten lokalen Routen o.t.g. zwischen Einschüben mit “P.O. xy” und Aufklebern nur mit Zahl, so dass genauso gut die Zahl als Referenz verwendet werden könnte in solchen Fällen).
Die Routenrelation, die einmal mit 17 und einmal mit 61 referenziert wird, hat in Wirklichkeit die Tags name=17-61 und ref=17-61 und kann in manchen Ausnahmen auch mal die umgekehrte Reihenfolge haben (Beispiele mit nur einseitiger Ausschilderung existieren, bei denen dann die Fahrtrichtung Vorrang vor der Reihenfolge der Knoten hat).
Ich stelle deshalb an den Stellen, die ich gerade vor Ort abgeradelt bin, das bisherige Schema wieder her, hätte aber auch nichts dagegen, es anders zu machen, wenn man sich auf eine andere Lösung einigen würde, die sowohl gut zu mappen als auch gut auszuwerten wäre.
Die Probleme damit, die Knotenpunkteinschübe in direction_north:route zu erfassen, kommen im Grunde daher, dass diese Einschübe zwar Routen beschreiben, aber dann doch von der Systematik für Themenrouteneinschübe abweichen (HBR NRW: “Die textliche Nennung von Fern- und/oder Nahzielen auf Routeneinschüben ist un-
zulässig”). Andererseits sind es ja auch keine wirklichen Ziele, was sich daran zeigt, dass man künstlich KP davor setzen muss und es keine Entfernungsangaben gibt.
Sowohl direction_north als auch direction_north:route wären leichter automatisch auswertbar, wenn darin nur Zielangaben/Routennamen im engeren Sinne stehen würden.
Welche Art von algorithmischer Auswertung machst du denn? Ich kann mir nicht vorstellen, ob einer der beiden keys das erschwert, habe aber Knotenpunkteinschübe selbst nur manuell erfasst und genutzt.
Ich habe anfangs die Einschieber für die Knotenpunkte auch ignoriert und nur die entsprechenden Relationen erfasst. Seit ich im Landkreis Diepholz das neue KP-Netz erfasse, habe ich aber aich diese Einschieber bei direction_north:route=* erfasst. So ist es nach meinem Verständnis auch im Wiki dokumentiert. Ich sehe allerdings auch die Diskrepanz bei der Bedeutung, weil die Nummer eben nicht für eine bestimmte Route steht.
Im LK Diepholz fand ich es dennoch wichtig, weil dort an vielen Wegweisern manche Einschieber zunächst fehlten, weil die Bauhöfe die einfach nicht geliefert bekommen haben.
Wenn die KP-Einschieber nicht so erfasst werden sollen, dann bitte ich um eine Alternative.
Ich antworte mal vorläufig und kurz, bin gerade wieder unterwegs… Ich kann mit beiden Varianten letztlich leben. Wo im Wiki ist das dokumentiert?
Letztlich muss im Wiki eigentlich auch viel ergänzt, zusammengefasst/vereinheitlicht und aktualisiert werden. Es ist eine Wahnsinnsarbeit. Es wäre super, wenn unter der deutschen Version von cycle node Networks (oder so ähnlich) ein Vorschlag stehen würde, wie man die Wegweiser abbildet, und letztlich bräuchte es auch eine Seite, in der das mapping dieser Art Fahrradnetzwerke einheitlich beschrieben würde. (Das ist das Ziel des ganzen Threads).
Da ist die Frage, was die Seite darstellt. Ich habe den Radroutenplaner Hessen gefragt, ob sein Radnetz ausschließlich ein beschildertes ist oder sogar ausschließlich FGSV-Beschilderung ist?
Die Antwort kam eben rein:
Das lokale Hauptnetz im Radroutenplaner Hessen, das die Grundlage für das Routing im Modus “Fahrradnetz bevorzugen” bildet, setzt sich aus den Radnetzen zusammen, die uns seitens der Kommunen und Kreise zur Verfügung gestellt wurden. In diesem Netz sind beschilderte Abschnitte enthalten. Allerdings können auch Streckenabschnitte inkludiert sein, die vor Ort über keine radwegweisende Beschilderung verfügen, jedoch seitens der lokalen Akteure als für den Radverkehr geeignet eingestuft wurden.
Ich habe gefragt, weil am Samstag knapp 17 Prozent im Landerplaner ausgewiesenen und von mir abgefahrenen Routen unbeschildert waren.
Naja, das Land NRW stellt auf ihrer Karte Katasterdaten mit Fotos der Wegweiser und der “soll”-Beschilderung zur Verfügung. Da gibt es beträchtliche Abweichungen in beide Richtungen: in der Realität zurückgebaute Routen und neue, noch nicht in die Karte aufgenommene Ausschilderungen. Im offiziellen Routenplaner zum Radverkehrsnetz NRW finden sich auch explizit “Routenvorschläge”, die in der Karte angezeigt werden können, aber nicht ausgeschildert sind. Diese werden aber auch ausdrücklich von den ausgeschilderten Routen abgegrenzt und lassen sich zusätzlich optional anzeigen.
[EDIT:]
ich möchte ergänzen… umso mehr macht es in dem Fall Sinn, die ausgeschilderten Routen in OSM klar zu definieren und zu mappen, da es sonst überhaupt keine Quelle und Referenz für die otg-Situation gibt… ich persönlich wüßte immer schon gerne, ob ich mich einigermaßen auf eine Wegweisung verlassen kann, oder nicht. Wenn ich ständig aufs Navi schauen muß, bekomme ich von der Landschaft nur halb so viel mit. (oder vom Verkehr, wenn’s primär darum geht, ein Ziel zu erreichen). Und auf dem Fahrrad sind die Lichtverhältnisse fürs Navi noch viel schwieriger als z.B. im Auto.
Ich bin am Samstag mal wieder rumgefahren und habe versucht als Beifang FGSV-beschilderte Routen mit aufzuzeichnen.
Jetzt bin ich an solchen Wegweisern
vorbeigekommen. Die Grüne Umrandung kann man noch erahnen, aber es gibt und gab kein Pfeildreieck für die Richtung wie bei der momentan üblichen FGSV-Beschilderung. Ist das alte FGSV-BEschilderung oder etwas anderes?
Ich bin gerade auch in Hessen auf sehr viele verschiedene regionale Varianten der Ausschilderung gestoßen, habe das noch kaum auswerten können. Da gibt es Mixturen verschiedener alter Wegweisungen, die Routen sind aber teilweise nicht mehr durchgängig, weil die neue Wegweisung Schritt für Schritt eingeführt wird, alte Routen nicht mehr einbezogen werden und Wegweiser nur an Kreuzungsstellen abgebaut werden, wo dann die querenden oder einmündenden alten Routen nicht mehr auffindbar sind.
Die Situation ist in anderen Bundesländern als NRW komplizierter, wo es eben zumindest eine verbindliche Anweisung gibt, dass alte Routen abgebaut und nach dem neuen Prinzip ausgeschildert werden sollen. (Ohne Fristsetzung, aber immerhin als Vorgabe). Das Bild ist in anderen Ländern bunter, aber man kann immerhin sagen, dass wohl inzwischen in jedem deutschen Bundesland zumindest auch Ausschilderungen wie in NRW nach FGSV-Regeln vorhanden sind - in unterschiedlichen Anteilen.
Zu dem Foto: Ich würde sagen, das ist etwas VOR den FGSV-Regeln, aber vielleicht dennoch halbwegs konform: Die FGSV-Regeln bedeuten zumindest, dass eine Zielwegweisung kontinuierlich fortgeführt wird, und zwischendurch auch Zwischenwegweiser verwendet werden.
Dem Foto kann ich nicht mehr unmittelbar entnehmen, ob es sich überhaupt um eine Fahrradwegweisung handelt, oder auch eine Wanderwegweisung sein könnte. Vermutlich ergibt sich das aber aus den Distanzen.
Ich persönlich handhabe das beim Mappen so, dass ich für tatsächlich abgefahrene Abschnitte, die die Kriterien erfüllen, eine Routenrelation anlege, und in einer note= beschreibe, was ich gesehen habe, und wie die Ausschilderung aussieht. survey:date ist wichtig, weil die Wahrscheinlichkeit, dass so eine Route auch demnächst abgebaut oder aktualisiert wird, durchaus gegeben ist.
Ebenso verfahre ich bei den Wegweisern, dass ich mindestens eine note= einfüge. (Im Kreis Herford gibt es einzelne Beispiele).
Aus Zeitgründen stelle ich das mappen dieser Routen persönlich allerdings eher hintenan und versuche, vorrangig das neue System einzupflegen.
Für diese Zwecke würde mich weiterhin der “conformity”-key interessieren. Um ihn zu nutzen, müßte man aber einen Konsens haben, wie die Werte zu definieren wären…
Das Mapping von Knotenpunkten zusammen mit den Routeneinschüben bleibt allerdings dennoch problematisch. Ich wüßte keinen passablen einfachen Algorithmus, der es einem ermöglicht, Knotenpunktziele von Routen zu unterscheiden. Das Parsen der Ziele mit “KP” ist sehr einfach. Was macht man aber mit Wegweisern wie solchen, wenn man 31, 51 und 8 gleichwertig als Routeneinschübe einträgt?
Man müßte alle in der Nähe liegenden Routenrelationen herunterladen und abgleichen, ob die “31” nun eher einen Knotenpunkt oder einen Routennamen darstellt.
Ich habe auch noch einmal nachgeschaut, das tagging mit “destination_nswo=… KP 123” ist deutlich älter, der Vorschlag im Wiki wird, wie es scheint, erst ab 2022 genutzt. Da hat jemand sich nicht vorher die Taggingpraxis angeschaut und etwas Neues eingeführt und nun gibt es 2 Varianten.
Der Wegweiser spricht deutlich für die Erfassung der Knotenpunkteinschübe in direction_north, dann eben mit vorangestelltem KP, um sie parsen zu können. An diesem System ist ja auch nicht viel auszusetzen, außer dass bei Knotenpunkten als Ziel keine Entfernung angegeben wird.
Als dieses Thema in Beitrag 40 anfing, war allgemein von Routeneinschüben die Rede, sodass ich dann direction_north:route auch für Knotenpunktrouteneinschübe genutzt habe. Soweit ich weiß war das System mit KP in direction_north da noch nicht im Wiki dokumentiert, auch wenn es schon genutzt wurde. Das Beispielbild im Wiki (von hier) kann gerne für das verbreitetere Schema stehen, aber irgendetwas sollte dokumentiert sein.
bzw. im wiki:
“There is also a less often used variant that does tag the 11 under {{Key|direction_northwest:route}}, but this can lead to conflicts with actual ‘‘routes’’ having numbers as their name.”
Ich möchte trotz meiner Zustimmung anmerken, dass inzwischen die Variante der Zahlen unter direction_nswo:route= häufiger ist als die Variante mit KP xy, was allerdings stark auf die hohe Aktivität von GerdP zurückzuführen ist, was ich ausdrücklich wertschätzen möchte.
(für Deutschland aktuell: 522 Nodes mit KP xy-Einträgen overpass turbo und 1648 Nodes mit reinen Zahl-Einträgen unter xx:route overpass turbo wenn ich die Overpass-Abfrage mit der Regex nicht versemmelt habe… )
Es stehen hier halt die Konzepte einer logischen-funktionalen Repräsentation des Objektes “Wegweiser” im Konflikt mit der materiellen Repräsentation in osm. Das ist ist nur lösbar, wenn man ein möglichst eindeutiges Mapping erzeugt, mit dem beide Konzepte möglichst leicht abrufbar sind.
Wenn ich zum Beispiel eine Anwendung habe - mal angenommen als Planer neuer Routen, in der mich die Anzahl der bereits vorhandenen Einschübe interessiert, weil ich wissen will, ob noch ein weiterer darunter paßt, oder der ganze Wegweiser umgebaut werden muß, brauche ich auch die Anzahl der Knotenpunkteinschübe. Mit dem einen Tagging parse ich die Zahl der Elemente, mit dem anderen muß ich die Richtungstags zusätzlich durchsuchen und nach KP [Zahl] zusätzlich schauen. Das ist zumindest gut machbar, ohne zusätzliche Daten außer den Tags des guidepost-nodes zu brauchen.
Wenn ich dagegen eine Routinganwendung benutzen will, die mir auch Informationen gibt, ab wann ich mit einem Verweis auf einen folgenden Knoten rechnen kann, z.B. von außerhalb eines Knotenpunktnetzwerkes, dann muß ich den Knotenpunkteinschub als Ziel identifizieren. Mit dem Tagging in den direction_nswo:route=[Zahl] muß ich zur Überprüfung, ob es sich bei einer Zahl um eine Route oder einen Knotenpunkt handelt, sämtliche lokalen route=bicycle-Relationen herunterladen und abgleichen, ob die Zahl irgendwo als Referenz oder Name einer Route auftaucht - und selbst das muß keine Garantie sein, wenn eine Route noch nicht gemappt ist.
Für NRW gilt immerhin in den Vorgaben, dass andere Ziele als Knotenpunkte unter den Einschüben ganz explizit nicht erlaubt sind, und auch die Routeneinschübe dürfen offiziell keine Hinweise auf Ziele enthalten. So strikt habe ich das bislang anderswo noch nicht gefunden und es wird auch mäßig strikt ausgelegt.
Ein Kompromiß könnte daher durchaus aber auch sein, die Knotenpunkte dennoch unter direction_nswe:route zu mappen, jedoch z.B. durch Klammern zu kennzeichnen. Ich glaube, dass man sinnvollerweise bei einem Namen oder Referenz einer Route nicht mit einer Einklammerung zu rechnen hat. Noch unwahrscheinlicher wäre sicher ein underscore, aber ich finde es attraktiv, Tags für sich intuitiv möglichst verstehbar zu lassen, so dass textbasierte Anwendungen möglichst keine Umstrukturierung der Daten für eine Lesbarkeit vornehmen müßten.
etwas wie:
{direction_north=Alme 6.1 km; Wülfte 2.0 km
direction_north:route=31;Alme-Radweg;(8)
direction_northwest=Büren (Btr) 23 km; Rüthen (Btr) 18 km
direction_northwest:route=Pengel-Anton-Radweg;Möhnetalradweg;(10)
direction_south=Aamühlen 3.8 km
direction_south:route=(51);31
direction_southeast=Brilon (Btr) 2.7 km
direction_southeast:route=(12);Alme-Radweg;Möhnetalradweg;Pengel-Anton-Radweg
[…]}
(Das ist übrigens auch ein gutes Beispiel für andere Probleme: Pengel-Anton-Radweg ist schlichtweg geraten, nur weil bei dem Wegweiser eine Relation dieses Namens angelegt ist. Bei der Relation fehlt aber ein Symbol= tag, so dass unklar ist, ob die stilisierte Dampflok tatsächlich dazugehört… es bestehen ja leider immer noch sehr viele falsche Routenrelationen, die nicht ausgeschildert sind - und die Abgrenzung zu den nicht über Routeneinschübe ausgeschilderten Routen ist eben auch noch nicht über Tags möglich… )
Ich kenne übrigens auch noch die Variante, dass die Knotenpunkt-Einschieber mit direction_nwso:ref=* erfasst werden. Dürfte im Norden von Oldenburg sehr häufig sein.
Ich bilde mir ein, dass ich mal unter https://wiki.openstreetmap.org/wiki/Proposal:Basic_network_(2021)#Proposal_|_Vorschlag gelesen habe, dass aus den Wegen zwischen zwei Wegweisern eine Relation wird. Nachdem ich gestern 108 km mit 86 Wegweisern abgefahren bin, habe ich wegen der in Aussicht stehenden Strafarbeit noch einmal nachgelesen und nichts Derartiges gefunden.
Du siehst aus dem Beispiel, worin der Kern des Problems liegt: Die nicht mehr nachvollziehbaren Sammelrelationen, denen man nicht entnehmen kann, wie aktuell welche Abschnitte überhaupt sind.
Am wichtigsten ist es, nur lineare, also unverzweigte Routenrelationen zu machen (abgesehen von evtl. nötigen Ausfransungen an den Enden wie bei den split-nodes im Knotenpunktsystem), und diese mit dem jeweiligen survey:date zu versehen. Das können, wenn es einheitliche basic-network-Ausschilderung ist, auch gerne die 108 km in einem Stück sein, wenn es denn so sinnvoll ist. Jemand, der in 3 Jahren mal Teilabschnitte überprüft, kann dann die Basic Relation ggf. zerlegen und sein eigenes survey:date ergänzen.
Es ist insgesamt sinnvoll, nicht kleiner zu teilen als von Abzweigung zu Abzweigung. Wo ich angefangen habe zu mappen, gab es nie Wegweiser, wenn es keine Abzweigungen gab, aber schon in den Nachbarkreisen gibt es massig Wegweiser nur in 2 Richtungen ohne Verzweigung. Es gibt keinen Grund, da eine Routenrelation zu trennen.
Also kurz: 85 Relationen anlegen ist nicht nötig, nur praktisch nützliches, keine Strafarbeiten (entsprechend der 2. goldenen josm-osm-Regel Spaß haben ) . (Es ist ja auch nur das Proposal… viel diskutiert, auch international, keine abschließende Lösung).
)