Die Ansagen, die mit destination Tags gemacht werden, sind eine ganz andere Sache und typischerweise simpel zu realisieren. Das kann sogar Garmins Uralt-IMG-Format.
Es fehlt dann immer noch das Wissen, welches der Ziele auf dem Wegweiser relevant ist, oft genug ist es gar keines. Wenn ich zum Beispiel auf dem Weg zum nächsten Hotel bin, dann brauche ich keine Ansage, die mir den Bahnhof oder einen Ort in 5 km Entfernung nennt.
Von daher sehe ich keinerlei potentiellen Nutzen bei der Navigation mit einem Navi.
OT: Tatsächlich frage ich mich oft genug, welcher Radler diese Schilder überhaupt sinnvoll nutzen kann. Wenn ich irgendwo an einer Kreuzung vor einem Wegweiser stehe und da stehen ein paar Ortsnamen mit Entfernungsangaben, dann hilft mir das fast nie, weil ich nicht weiß, wo diese Orte sind und ob ich da hinwill, wenn ich zum Beispiel ein Ziel in 50 km Entfernung erreichen will. Ich müsste vor meiner Reise lange Zeit eine Karte studieren und mir sehr viele Ortsnamen und Positionen entlang der geplanten Strecke merken, um dann evtl. zu wissen, dass ich bestimmt besser die Route nach A-Dorf nehmen sollte statt nach B-Stadt oder zum Bahnhof. Als Jugendlicher habe ich noch mit Karte navigiert, ich war dabei sehr schlecht, weil ich mir nie klar gemacht habe, das die Schilder nicht anzeigen, wo die Orte sind oder wie weit weg, sondern nur, dass man an dieser Stelle in der angezeigten Richtung zu dem Ort kommen könnte, wenn man im Folgenden immer genau den Schildern folgt. Das da manchmal riesge Umwege ausgeschildert sind habe ich erst viel später begriffen.
Das Plugin Comfort0 macht diese Arbeit deutlich einfacher und erlaubt sogar undo/redo, muss mal schauen, ob ich mir da mit Notepad++ und Edit–Makros was bastel oder doch ein kleines Java-Programm schreibe. Ich habe ca. 2000 Knoten zu ändern.
Die Ansage hilft auch in diesem Fall bei der Identifizierung des richtigen Weges. Wenn zwei Wege nach rechts abgehen und nicht klar ist welcher mit “rechts abbiegen” gemeint ist, dann kannst du den nehmen an dem der passende Wegweiser steht.
Eine halbwegs sinnvolle Entscheidung zu treffen welcher der Einträge relevant ist, ist auch recht simpel: Entweder er entspricht deinem Ziel, oder es ist ein Eintrag, dem du auch auf den folgenden Schildern wieder folgen sollst (Als Zusatzhinweis “folge der Beschilderung nach A für 10 km”). Oder eben der erste, den man in der Regel am leichtesten findet.
Genau so ist es. Das Navi für das Auto sagt oft Dinge wie “Beschilderung Richtung Düsseldorf/Aachen folgen”. Das ist sehr hilfreich, wenn man “nach Gehör” fährt. Das gilt noch in viel größerem Maße für das Fahrrad, weil die Verkehrsführung für Radfahrer in der Regel viel unübersichtlicher ist, als für Autofahrer und man da mit Ansagen wie “scharf rechts abbiegen” vor Ort selten klar kommt. Außerdem will man als Radfahrer ungerne ständig auf das Handy schauen, weil man es vielleicht in der Tasche hat und nur umständlich während der Fahr rausholen kann oder selbst wenn es am Lenker hängt ist es in der Regel weit aus dem Blickfeld. Ich finde das schon extrem hilfreich.
Sebastian @segubi hat in einer Diskussion vorgeschlagen, für das ausgeschilderte System in einer Relation die Tags network=lcn und network:type=basic_network zu verwenden. Ich habe das erweitert um die Wegweiser und die Wege aufzunehmen. Die Wegweiser bekommen die Tags role=guidepost und die Wege werden ohne Rolle aufgenommen, es sei denn Hin-und Rückweg unterscheiden sich in der Linienführung. Die Reihenfolge in der Relation spielt eine Rolle, es beginnt mit mindestens einem Wegweiser, es folgt mindestens ein Weg ein den Abschluss bildet ein Wegweiser. Die umgekehrte Reihenfolge gilt für den Rückweg.
Durch die Erweiterung des Tags guidepost auf guidepost:direction_north kann an der Abzweigung aus einen zugehörigen Tag des Wegweisers (direction_north=Zielangabe/n) in einer Routing-App die Angabe auf dem Display erscheinen oder über eine Sprachausgabe vorgelsen werden. Ich habe ein solches Netz im südlichen Ostholsstein gemappt. Das Ergebnis lässt sich über Overpass ansehen: overpass turbo. Ich arbeite auch an einer App für Android, die auf diesem Netz ein Routing durchführt.
Ich verfasse einen Blog-Beitrag für die Erläuterung, dessen Link ich hier teilen werde.
Ich habe jetzt ein semi-automatisches Verfahren gebastelt, um die vorhandenen Knoten auf das neue Tagging-Verfahren mit suffix :route für die Routen umzustellen.
Ein paar Stolperfallen gab es zu überwinden, aber jetzt sollte das Ergebnis passen.
Zum Verifizieren: Das Ergebnis meiner Umstellung sieht so aus: Changeset: 140276677 | OpenStreetMap
Es geht erst mal um weitere 1607 Knoten mit information=guidepost, in denen ich der letzte Updater war und die Routen in den direction_ Tags haben.
Edit: Hier meine weiteren Umstellungsänderungen Changeset: 140302105 | OpenStreetMap Changeset: 140302967 | OpenStreetMap
Ich sehe den Vorteil von diesem neuen Schema nicht. Wir haben schon drei verschiedene Arten die Ziele einer Ausschilderung zu erfassen. Dein neues Schema sieht mir nach einer Kombination von guidepost-Nodes mit destination_sign Relationen aus. Dabei verlierst du aber alle erweiterten Möglichkeiten, die destination_sign bietet.
Diese Taggingmethode scheint auch nur bei wenigen Wegweisern zu funktionieren und macht sie damit nicht universell einsetzbar. In allen Fällen wo nicht ein Wegstück in beide Richtungen ausgeschildert ist und keine Verzweigung dazwischen hat scheint es mir nicht verwendbar zu sein.
Hast du von einigen eher komplizierteren Wegweiser Bilder damit man sich vorstellen kann, wie die Schilder hinter dem Tagging aussehen?
Sind die Routenangaben immer unabhängig von den genannten Zielen, oder gibt es auch Fälle, bei denen eine Beziehung zwischen einzelnen Zielen und einzelnen Routen zu erfassen sein könnten?
Destination_sign zielt darauf ab, an einer Kreuzung den die Richtung einer Zielangabe mit dem Beginn eines Weges zu verbinden. Es wirkt nur lokal und nicht bis zum nächsten Wegweiser. Dabei wird nicht der Aufbau des Netzes abgebildet, sondern der Aufbau der Kreuzung.
Das ist bei mir anders, da zwei Wegweiser in Beziehung gesetzt werden, die durch einen Weg verbunden sind. Somit ist das Netz selbst abgebildet.
Ich bin mir nicht sicher ob ich das ohne Beispiele des Auftretens der Rollen in anderen Kontexten beurteilen kann.
Eine Anwendung der Rolle forward/backward, mit denen ich Erfahrung habe, ist die Erfassung von Fahrrad-Routen. Dort dient es dazu, eine Abfolge von Ways so zu erfassen, dass eine unterbrechungfreie Folge von Ways entsteht, d.h. der letzte Node des Vorgängers mit dem ersten Node des Nachfolgers übereinstimmt und damit eine unterbrechungsfreie Abfolge eines gesamten Ways über die Abfolge einzelner Ways zu erzeugen. Dort kann die Rolle forward/backward bedeutsam sein, wenn ich Einbahnstraßen gegen die vorgegebene Richtung befahre.
Wenn ich einen way mappe, ist es völlig willkürlich, an welchem Ende ich anfange. Die Richtung hat keine Bedeutung. Nur wenn ich eine geordnete Abfolge in einer Route anlegen möchte, muss ich aufgrund dieser technischen Lösung bei der Route ob dieses Wegstück entlang seiner Richtung in der Datenbank in der Route vorkommen soll, oder gedreht wird. Das mach ich mit forward/backward.
Ich stimme dir zu, dass die Übertragung einer Lösung für eine technische Gegebenheit auf eine semantische Anwendung zur Verwirrung beitragen kann. Ich bin für eine bessere Namensgebung dankbar. Für meine Anwendung ist die geordnete Abfolge keine Forderung, da sowohl die Darstellung auf einer Karte oder die Berechnung der Entfernung zwischen den Wegweisern aus dem dazwischen liegenden ways keine geordnete Abfolge erfordern. Mit Hilfe der Rollen forward/backward kann ich zwei getrennte Abflogen von ways für den Hin- und den Rückweg erzeugen. Da diese dann bei ausgeschilderten Wegen ohne Verzweigung sind, lassen sie sich auch nachträglich zu einer lückenlosen Abfolge sortieren, sollte das erforderlich sein.
Die Bedeutung der Rollen forward und backward bei type=route Relationen ist im OSM Wiki beschrieben. Ich habe einige Zeit gebraucht, bis ich das verstanden habe, weil ich es auch so erwartet habe, wie Du es im Blog beschreibst.
Ich bin mir jetzt nicht sicher, ob Du das im Blog nur ungeschickt beschrieben hast oder ob Du es wirklich umdefinieren möchtest.
Ich bin mir nicht sicher, ob ich verstanden habe, was du sagst.
Bei mir stehen forward/backward für den Hin- und Rückweg einer in beiden Richtungen befahrbaren Strecke. Sie beziehen sich nicht auf die technische Richtung des ways in der Datenbank. Dies habe ich in der Antwort auf den Beitrag von GerdP etwas ausführlicher beschrieben.
Ich hoffe, dass ich die Seite erwischt habe, auf die du dich beziehst: Relation:route - OpenStreetMap Wiki.
Dort wird in der Tat forward in Bezug auf die technische Richtung des way beschrieben. Aber so wie wir nicht für den Render mappen, sollten wir auch nicht für die Datenbank mappen, denke ich. Ich nehme mit forward Bezug auf die Richtung der Strecke von Ort A nach Ort B und mit backward darauf dass die Richtung von Ort B nach Ort A geht. Vielleicht lassen sich bessere Bezeichnungen finde, die dieses Missverständnis vermeidet. Würde onward/rearward passen?
Alternativ lässt sich alles ohne rolle forward/backward mit etwas Redundanz in zwei getrennten Relationen darstellen. Dem steht entgegen, dass mit der Redundanz die Datenbank etwas aufgebläht wird (ein Argument von Sebastian/@segubi ), aber vor allem, dass für den menschlichen Leserder Relation der unmittelbare Bezug zwischen Hin- und Rückweg verloren ginge.
Ich denke, die bereits vorhandene Festlegung im Wiki ist zwar nicht leicht verständlich, aber sie ist in diversen Tools umgesetzt. Wenn Du eine andere Bedeutung brauchst, dann müsstest Du einen neuen Relations-Typen festlegen. Für type=route sind die nutzbaren Rollen vergeben und ein einzelnes Mitglied kann ja nur eine Rolle haben.
Achtung! Da hängen dicke Mißverständnisse drin: Grundsätzlich: OSM ist eine Datenbank, und genau für die wird gemappt. (Wofür denn dann sonst?)
Natürlich wird auch gemappt, dass nachher gerendert werden kann. Das bleibt eine der Hauptaufgaben einer Geodatenbank wie OSM. Mit “don’t tag for the renderer” ist gemeint, dass man keine tags falsch benutzen darf, nur um eine erwünschte Darstellung in einer bestimmten Karte zu bekommen. Schöne Beispiele gibt es hier im Wiki: Tagging for the renderer - OpenStreetMap Wiki (die berühmten 3d-Hochhäuser …)
Die Rollen forward und backward sind klar definiert und sollten auf keinen Fall zweckentfremdet werden. forward heißt, der Weg wird im Rahmen einer Relation nur in Richtung des OSM-Weges benutzt, backward heißt, der Weg wird im Rahmen einer Relation nur in Gegenrichtung des OSM-Weges benutzt. Ob eine Routenrelation vorwärts und rückwärts ausgeschildert ist, wird mit signed_direction=* ausgedrückt. Default ist, dass die Relation in beide Richtungen befahren wird, und muß daher nicht extra erwähnt werden. signed_direction=* ist nur vernünftig auswertbar, wenn die Relation sortiert ist. Bei einer in beiden Richtungen befahrbaren Route kann man prinzipiell die Wege sortieren, wobei sich die Endpunkte bei Vollständigkeit ergeben.
Bei den Knotenpunktnetzwerken ergeben sich hierbei kompliziertere Strukturen durch aufgespaltene Knoten. Im Detail erklärt im Wiki: Cycle Node Network Tagging - OpenStreetMap Wiki Das Taggingschema bleibt allerdings problematisch, wer sich mehr für die Tücken der Tentakel und deren Interpretation interessiert, kann u.a. hier schauen, z.B. bzgl. dieser Route.