Ich möchte an einer Straße mit mehreren Fahrspuren vor einer Kreuzung die destination Tags hinzufügen, die auf dem Straßenschild angegeben sind.
Für die rechte Fahrspur, auf der man geradeaus und nach rechts fahren kann, wird auf dem gelben Schild an dieser Stelle mit weißem Hintergrund der Flughafen Tegel ausgeschildert. Und zwar erst das Symbol “airport” und dahinter die Schrift “Tegel”.
Hier zu sehen: https://www.mapillary.com/app/?focus=photo&pKey=98v5MkYcCfiZnKMORAMSqQ&lat=52.546375608571694&lng=13.446225924110877&z=17
Wie setze ich dieses in destination tags um, so dass deutlich wird, dass diese beiden Informationen zusammen gehören.
Ich habe mich beim den Tags nach dem Wiki gerichtet (vorletztes Beispiel), jedoch ist dieser Spezialfall dort in keinem Beispiel zu sehen: http://wiki.openstreetmap.org/wiki/DE:Key:destination
Achtung! Das vorletzte Beispiel auf der Seite habe ich selber erst vor kurzem korrigiert, da die letzten 3 Punkte in der Darstellung falsch waren. Im Quelltext sahen sie jedenfalls anders aus, als in der Darstellung der Seite. Ich hoffe, ich habe das richtig korrigiert. Bitte noch einmal draufgucken.
Dafür ist dieses Schema nicht geeignet. Man muss davon ausgehen, dass Namen, Symbole und Bezeichner als ungeordnete Liste hintereinander ausgegeben werden. Eine Zuordnung zwischen diesen Elementen ist dabei nicht vorgesehen.
Wenn man das wöllte, müsste man das Schema anders definieren. Dann bräuchte es Slots, welche jeweils einen Namen (aus destination:lanes), ein Symbol (aus destination:symbol:lanes) und einen Bezeichner (aus destination:ref:lanes) haben können. Die Slots werden durch Semikolon in den einzelnen Keys getrennt - so wie die Lanes selbst durch den senkrechten Strich geteilt werden. Leere Elemente müssen passend mit Semikolons aufegfüllt werden.
In der jetzigen Form ist das aber alles wenig überlegt. Wird das abseits des reinen Destination-Namens momentan überhaupt durch irgendein Programm ausgewertet? In der englischen Version gibt es symbol und ref beispielsweise gar nicht. In meinen Augen sind diese zusätzlichen Keys momentan Taggen für den Papierkorb, weil eben wenig durchdacht.
Die Zuordnung mit Semikolons wie von dir vorgeschlagen benutze ich auch um Schilder dazurstellen, auswerten kann man sie gut - der jetzige Weg: http://osm.mueschelsoft.de/cgi-bin/render.pl?wayid=188633782&start=1&placement
Wirklich genutzt werden die Destination-Details (außer destination und destination:ref) meines Wissens nach aber noch nirgends richtig.
In einem Fall wie diesem ohne eigene Spur für die Rechtsabbieger würde ich die destination am ersten abzweigenden Weg nach der Kreuzung nochmal wiederholen, dann ist auch klar, was auf der rechten Spur für “geradeaus” gilt und was für “rechts abbiegen”.
@Peter: Wenn du nichts dagegen hast, werde ich dieses Beispiel im Wiki nochmal überarbeiten, das geht nämlich noch etwas besser.
Wenn, dann würde ich das aber analog zu Relation:destination_sign destination:colour:back:lanes nennen. Denn colour allein könnte sich auch auf die Textfarbe beziehen (in Deutschland weniger relevant, aber in anderen Ländern geht es eventuell bunter zu).
Aber wenn man sich schon überlegt, was man dort mehr oder weniger sinnvoll alles wie taggen könnte, dann würde ich auch mal zur Disposition stellen, inwieweit man die Richtung des jeweiligen Pfeiles berücksichtigen sollte. Entweder, indem man mit Begriffen wie in Key:turn arbeitet oder indem man eine Gradzahl der Richtung angibt (0 = geradeaus, 90 = rechts, 270 = links). Dann könnte man bei Spuren, die mehrere Richtungen abdecken, dann auch die Zuordnung des Zieles zur Richtung vornehmen.
bzw. wenn man nicht mit Begriffen sondern mit Gradzahlen operieren würde:
destination:arrow:lanes=270|0|0;90;90
Das kann zwar auch nicht alle Szenarien abdecken, beispielsweise wenn auf dem Wegweiser zwei hintereinanderliegende Abzweigungen dargestellt werden. Dort könnte man dann höchstens zu Tricks greifen, wie dass man die zweite Abzweigung beispielsweise nur als “halb rechts” taggt.
destination:colour wird zwar schon 4000 Mal verwendet, aber wirklich definiert im Wiki ist es nicht. Die Unterteilung in colour:back und colour:text wäre wahrscheinlich ganz gut.
destination:arrow - ja, warum eigentlich nicht. Ich würde aber die gängigen Namen verwenden und keine Gradzahlen, das macht es zu unübersichtlich. Ich würde auch explizit dazu schreiben, dass dieses Tagging nur verwendet werden sollte, wenn die Richtungszuordnung über turn:lanes nicht eindeutig ist, d.h. wenn eine Spur in mehrere Richtungen führt (“through;right”).
Eventuell können wir Imagic ja überzeugen, das noch mit in das “große” Proposal aufzunehmen, damit alles an einer Stelle definiert ist.
colour:back eine Farbe yellow Die Grundfarbe des Wegweisers (optional).
colour:text eine Farbe black Die Textfarbe des Wegweisers (optional).
colour:arrow eine Farbe black Die Farbe des Randes oder des Pfeiles (optional).
Destintion_sign nehme ich aber bisher nur für die Beschilderung von Wanderwegen, da die Gehzeiten im Gebirge extrem wichtig sind. Beispiel hier: https://www.openstreetmap.org/node/3706595441#map=19/46.91304/11.62056
Ich wäre froh, wenn Osmand die Gehzeiten irgendwann anzeigen könnte.
*1) Für destination:colour gibt es bis jetzt keine Dokumentation, es beschreibt die Hintergrundfarbe des Schildes und wird bereits 4000 Mal verwendet. Hintergrundfarben, die auf allgemeinen Richtlinien beruhen und sich aus dem Kontext ergeben (z.B. an Bundesstraßen gelbe Schilder, Hinweise auf Autobahnen in blau) sollten nicht angegeben werden.
*2) Die leeren Semikola am Anfang der Einträge sorgen für die richtige Zuordnung der Werte zu denjenigen in destination:lanes. Dies ist optional: Software die diese Art des Taggings unterstützt, kann eine bessere Darstellung liefern; jede andere Software überliest die leeren Einträge und kann die Werte ebenfalls verarbeiten.
Destination:ref gehört also nicht mit zur semikolon-sortierten Liste sondern beschreibt die ref alle Ziele (außer *:to)?
Die Keys mit :to definieren einen eigenen Bereich im Schild und machen damit eine eigene sortierte Liste auf? Hier sollte aber das destination:ref zur semikolon-sortierten Liste gehören? Nur so lässt sich ja dieses obere Schild darstellen:
ref sollte ja normalerweise die direkt anschließende Straße beschreiben, kann also eigentlich nicht zu einem der Ziele gehören.
ref:to hingegen interpretiere ich als sortierte Liste, dort gibt es ja in der Regel einen Zusammenhang mit einem Ziel oder Symbol.
So interpretiere ich die Tags im Augenblick. Damit lässt sich allerdings leider nicht die genaue Reihenfolge von :to’s und nicht-:to’s auf dem Schild ausdrücken. Ohne diese Trennung fand ich das Tagging allerdings zu kompliziert.
Halte ich für problematisch. Denn dann hat man wieder das Problem des Ausgangsbeispiels, dass wenn eine Spur für mehrere Richtungen zuständig ist, man dort, auch wenn man später einen arrow-Key einführt, nicht differenzieren kann. Denn ref wäre dann außerhalb dieses Schemas.
Das ergibt dann schon fast die Folgefrage, ob man ein ref:to und destination:to überhaupt braucht. Denn das könnte man komplett mit den anderen Tags abhandeln.
Da sehe ich kein so großes Problem - ref’s sind (nicht nur bei uns) eigentlich flächendeckend erfasst. Router können einfach herausfinden auf welche Straße man nach dem Abbiegen kommt.
Den Unterschied zwischen X und X:to sehe ich schon als sehr praktisch an, den man auch hierzulande erfassen sollte.
Dann könnte man destination:ref auch gleich weglassen, weil es sich immer automatisch ergibt. Aber um derart automatische Auswertungen geht es ja offenbar nicht. Sondern es geht darum, den Inhalt von Richtungsweisern passend zu erfassen. Zumal man dort mit exotischen Situationen, wie beispielsweise einem gewissen Kreuzungsversatz, auch schnell Probleme beim automatischen Ergänzen bekommen kann.
Nebenbei halte ich es auch aus Konsistenzgründen für besser. Denn wenn ähnliche Keys mal so und mal so belegt werden, führt das nur zu Chaos, weil das dann verwechselt wird. Das verhindert dann jede sinnvolle Auswertbarkeit. Ein einheitliches Schema ist also auf jeden Fall vorzuziehen als irgendwelche falschen Vereinfachungen, die man vielleicht - vielleicht aber auch nicht - mit anderweitigen Daten passend ergänzen könnte.
Bin ich immer noch unschlüssig. Denn ein einfaches destination heißt in vielen Fällen auch nicht, dass es speziell diese Straße oder Route ist, die dann bis zum entsprechenden Ziel führt. Sondern es ist auch einfach nur eine Richtungsweisung, der man zunächst einmal folgen soll, wenn man weiter in Richtung dieses Ziels kommen will. Wenn wir uns das vorletzte Beispiel zum destination-Key im Wiki anschauen, so wird man schnell feststellen, dass Duderstadt und Pöhlde gar nicht direkt erreichbar sind, wenn man in Herzberg auf der B243 aus Richtung Norden kommend rechts auf die B27 abbiegt, sondern dass das nur geht, wenn man wiederum kurz darauf nach links auf die L530 abbiegt.
destination = über diese Straße geht es irgendwann nach X-Stadt
destination:ref = diese Spur / *_link führt zur B1
destination:ref:to = über diese Straße geht es irgendwann zur B1
Im Prinzip entspricht destination genau der Bedeutung von destination:ref:to, nämlich einem “Irgendwann kommt man hin” - nur einmal mit Namen, einmal mit Nummer. destination:ref hingegen bezieht sich immer auf die unmittelbar nächste Straße, z.B. hinter einer Autobahnauffahrt.
Ja, da stimme ich dir zu. Allerdings habe ich da einige Bedenken: Es verkompliziert die allermeisten Fälle. Wie oft kommt es denn vor, dass eine ref nur zu einem Ziel gehört? Ist mir hier im weiteren Umkreis noch nie aufgefallen. Im Gegensatz dazu: Wie oft ist ein Symbol einem bestimmten Eintrag zugeordnet? Fast immer. Wie oft hat ein ref:to auch noch einen Namen? Fast immer.
Wir müssen uns klar sein, mit einem verständlichen Tagging-Schema kann man nicht jedes Schild in jedem Detail beschreiben.
Ich glaube, die meisten User sind bereit destination und destination:ref einzutragen, aber nicht mehr. Findet man jetzt an einem Weg zwei destination und zwei destination:ref - gehört da jetzt eine destination zu einer ref, oder beide refs zur Straße und die destinations sind davon unabhängig?
Dann würde sich aber die Frage stellen, wofür destination:to in diesem Schema noch gut sein soll.
Aber das war doch gerade unser Ausgangsbeispiel - nämlich jeder Fall, in dem eine Spur mehrere Abbiegemöglichkeiten hat. In dem Fall bliebe nur die Möglichkeit, dass man das irgendwie mit Hilfe der Straßenverläufe versucht aufzulösen. Aber das kann bei exotischen Kreuzungsverläufen auch schnell in die Hose gehen - aber gerade bei denen braucht der ortsunkundige Fahrer häufig Hilfe beim Navigieren.
Das ergibt sich doch aus dem jeweiligen Slot. Wenn die destination unabhängig von den ref sind, dann sind die destination meinetwegen im Slot 1,2 und die ref im Slot 3,4 (also mit zwei Semikolon als Leerstellen davor). Wenn sie miteinander verknüpft sind, dann sind die ref entsprechend in den Slots der destination.
In diesem Fall hält man sich an den generellen Hinweis im Wiki - die Destination wird an den ersten Way hinter der Kreuzung geheftet der nur in diese Richtung führt, alternativ als destination:lanes an die Stelle, wo es eine eigene Spur gibt. Der Zusammenhang zwischen den Spuren vor der Kreuzung und hinter der Kreuzung erhält man mit den Angaben aus turn und transit Tags.
Ja, aber nur wenn auch alle Mapper nach genau diesem Schema mappen. Und das ist unmöglich durchzusetzen (weil kaum einer die Notwendigkeit sieht) und außerdem an den bereits vorhandenen 75.000 gemappten destination:ref Keys zu überprüfen. Schau dir nur an wieviele Mapper Semikolons in Tags als großes Übel betrachten und komplizierte Work-arounds erfinden wie name_1, name:1, oder auch cuisine:french=yes (anstelle von cuisine=french;english)
Ein Tagging, das alles beschreiben kann, taugt nichts, wenn nur wenige Mapper es unterstützen. Ein Kompromiss, der nur 98% aller Fälle abdeckt, aber dafür von vielen getragen wird ist wesentlich besser.
Schon wieder so eine Sonderregel, bei der wieder etwas abweichend vom Standardschema zu taggen ist.
Zumal ich diese Ausnahmeregel nicht einmal sehr gelungen finde. Denn sie bedingt, dass aus verschiedenen Richtungen vor der Kreuzung stets auf das gleiche Ziel hinter der Kreuzung gewiesen wird (denn das wäre dann einheitlich für alle Herkunftsrichtungen). Ich bezweifle, dass das immer so sein muss.
Wieso Sonderregel? Das ist die Standard-Anwendung von “destination” schlechthin. Und war auch die einzige, bis Jahre später das :lanes-Suffix eingeführt wurde.
Wenn ich so etwas sehe, denke ich Wow! Eigentlich ein mehrfaches Wow.
Wow, was man nicht alles in OSM-Daten verpacken und nutzen kann.
Wow, WER soll das alles mappen?
Wow, WIE soll man das alles mappen. Ich verzweifle schon immer an der Syntax von opening_hours.
