destination:...-tags

Peter Maiwald · 2016-09-04 19:43:08

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=ph … 10877&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.

Es handelt sich um diesen Straßenabschnitt:
http://www.openstreetmap.org/way/188633782

Last edited by Peter Maiwald (2016-09-21 22:46:59)

Kontinentalverschieber · 2016-09-04 21:22:34

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 deinem Beispiel wäre das dann:

destination:lanes=Friedrichshain|Mitte|Mitte;Wedding;Tegel
destination:ref:lanes=|B 2|B 2;;
destination:symbol:lanes=||;;airport

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.

Last edited by Kontinentalverschieber (2016-09-04 21:25:21)

mueschel · 2016-09-04 21:58:43

Zu den drei Tags würde ich noch eines hinzufügen:

destination:colour:lanes=||;;white

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/rend … &placement
Wirklich genutzt werden die Destination-Details (außer destination und destination:ref) meines Wissens nach aber noch nirgends richtig.

Zum Wiki: Im Englischen gibt es ja noch das Proposal für die erweiterten Tags, deswegen stört das Fehlen auf der destination-Seite nicht so sehr ( http://wiki.openstreetmap.org/wiki/Prop … on_details ).

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.

Peter Maiwald · 2016-09-04 22:51:45

mueschel wrote:

@Peter: Wenn du nichts dagegen hast, werde ich dieses Beispiel im Wiki nochmal überarbeiten, das geht nämlich noch etwas besser.

Ja gerne.
Es gibt übrigens das Beispiel noch einmal: http://wiki.openstreetmap.org/wiki/DE:K … ion:symbol

Kontinentalverschieber · 2016-09-05 08:56:52

mueschel wrote:

Zu den drei Tags würde ich noch eines hinzufügen:
destination:colour:lanes=||;;white

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.

Im angegebenen Beispiel mit:

destination:lanes=Friedrichshain|Mitte|Mitte;Wedding;Tegel
destination:ref:lanes=|B 2|B 2;;
destination:symbol:lanes=||;;airport

wäre das dann:

destination:arrow:lanes=left|through|through;right;right

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.

Last edited by Kontinentalverschieber (2016-09-05 09:11:44)

mueschel · 2016-09-05 10:03:09

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.

Peter Maiwald · 2016-09-05 11:38:16

mueschel wrote:

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.

Bei destination_sign in der Relation steht es im Wiki: http://wiki.openstreetmap.org/wiki/DE:R … ation_sign
und hier im Blog, von dir selber geschrieben:
http://blog.openstreetmap.de/blog/2015/ … wegweiser/

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/3706 … 4/11.62056
Ich wäre froh, wenn Osmand die Gehzeiten irgendwann anzeigen könnte.

mueschel · 2016-09-05 21:40:52

Peter Maiwald wrote:

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.

Hier ist meine Version vom Tagging, inklusive zweier Anmerkungen die auch im Wiki erscheinen sollten:

destination:lanes = Nordhausen;Braunlage;Bad Sachsa;Bad Lauterberg;Papierfabriken|Nordhausen;Braunlage;Bad Sachsa;Bad Lauterberg;Papierfabriken|Göttingen;Duderstadt;Pöhlde
destination:ref:lanes = B 27;B 243|B 27;B 243|B 27
destination:colour:lanes = ;;;;white|;;;;white|   *1
destination:symbol:lanes = ;;;;industrial|;;;;industrial|;;;industrial;train_station   *2
destination:ref:to:lanes = ||A 7
destination:to:lanes = ||Kassel
destination:symbol:to:lanes = ||motorway

*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.

Und das macht mein Tool daraus:

Jojo4u · 2016-09-05 22:27:41

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:

destination = ...
destination:colour = ...
destination:symbol = ...
destination:ref = B 16
destination:ref:to = A 93;B 299
destination:to = München;Landshut
destination:to:colour = blue; 
destination:symbol:to = motorway;

Last edited by Jojo4u (2016-09-05 23:44:39)

mueschel · 2016-09-06 10:02:51

Jojo4u wrote:

Destination:ref gehört also nicht mit zur semikolon-sortierten Liste sondern beschreibt die ref alle Ziele (außer *:to)?

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.

Jojo4u wrote:

Die Keys mit :to definieren einen eigenen Bereich im Schild und machen damit eine eigene sortierte Liste auf?

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.

Jojo4u wrote:

Hier sollte aber das destination:ref zur semikolon-sortierten Liste gehören? Nur so lässt sich ja dieses obere Schild darstellen:

Wenn man es zur Liste zählen würde, dann müsste man das B16 wieder irgendwie ausnehmen, das ist zu kompliziert. Das B299 ist ja eindeutig ein ref:to
Die Reihenfolge der Einträge bekommt dieses Tagging zwar nicht hin, aber alle Einträge sind richtig vorhanden:
http://osm.mueschelsoft.de/lanes/render … 7D&start=1 (Das Fähren-Symbol ist bei mir noch nicht drin...)

Kontinentalverschieber · 2016-09-06 10:14:33

mueschel wrote:

ref sollte ja normalerweise die direkt anschließende Straße beschreiben, kann also eigentlich nicht zu einem der Ziele gehören.

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.

Last edited by Kontinentalverschieber (2016-09-06 10:18:34)

Jojo4u · 2016-09-06 11:39:29

Das *:to kam IMHO durch die USA-Leute weil die an den Schildern oft ein "to" haben.

mueschel · 2016-09-06 11:53:49

Kontinentalverschieber wrote:

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.

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.

Kontinentalverschieber · 2016-09-06 12:19:21

mueschel wrote:

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.

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.

mueschel wrote:

Den Unterschied zwischen X und X:to sehe ich schon als sehr praktisch an, den man auch hierzulande erfassen sollte.

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.

Last edited by Kontinentalverschieber (2016-09-06 12:47:13)

mueschel · 2016-09-06 19:03:27

Kontinentalverschieber wrote:

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.

Ja, und? So ist destination definiert.

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.

Kontinentalverschieber wrote:

destination:ref - wenn ähnliche Keys mal so und mal so belegt werden, führt das nur zu Chaos, weil das dann verwechselt wird.

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?

Kontinentalverschieber · 2016-09-06 19:31:52

mueschel wrote:

Ja, und? So ist destination definiert.
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.

Dann würde sich aber die Frage stellen, wofür destination:to in diesem Schema noch gut sein soll.

mueschel wrote:

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.

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.

mueschel wrote:

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?

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.

mueschel · 2016-09-06 21:41:54

Kontinentalverschieber wrote:

mueschel wrote:
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.
Dann würde sich aber die Frage stellen, wofür destination:to in diesem Schema noch gut sein soll.

Um den Text neben destination:ref:to anzugeben.

Kontinentalverschieber wrote:

mueschel wrote:
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.
Aber das war doch gerade unser Ausgangsbeispiel - nämlich jeder Fall, in dem eine Spur mehrere Abbiegemöglichkeiten hat.

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.

Kontinentalverschieber wrote:

mueschel wrote:
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?
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.

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.

Kontinentalverschieber · 2016-09-06 21:57:47

mueschel wrote:

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

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.

mueschel · 2016-09-06 22:05:45

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.

brogo · 2016-09-07 13:01:04

mueschel wrote:

destination:lanes = Nordhausen;Braunlage;Bad Sachsa;Bad Lauterberg;Papierfabriken|Nordhausen;Braunlage;Bad Sachsa;Bad Lauterberg;Papierfabriken|Göttingen;Duderstadt;Pöhlde
destination:ref:lanes = B 27;B 243|B 27;B 243|B 27
destination:colour:lanes = ;;;;white|;;;;white|   *1
destination:symbol:lanes = ;;;;industrial|;;;;industrial|;;;industrial;train_station   *2
destination:ref:to:lanes = ||A 7
destination:to:lanes = ||Kassel
destination:symbol:to:lanes = ||motorway

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.

Christian

Peter Maiwald · 2016-09-07 23:48:02

brogo wrote:

Wow, WER soll das alles mappen?

Ich würde das schon machen. Oder andersherum: Es ist in meinen Augen nicht sinnvoll, ein Schema zu verwenden, welches man nicht auf ein Schild zurück übertragen könnte. Wenn also unklar bleibt, ob die Angabe für geradeaus oder für rechts gilt, oder welcher Flughafen wohl gemeint sein könnte. Meine Motivation ist also nur da, wenn es korrekt abgebildet werden kann.

brogo wrote:

Wow, WIE soll man das alles mappen. Ich verzweifle schon immer an der Syntax von opening_hours.

Da wird schon jemand ein benutzerfreundliches Plugin für die gängigen Editoren und Apps schreiben. Oder halt so wie jetzt, einfach eintragen.

Außerdem kann man ja anscheinend weiter mappen wie bisher, da die Variante abwärtskompatibel zu sein scheint. Siehe hier:

mueschel wrote:

*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.

Ich glaube allerdings destination:arrow:lanes wird benötigt, wenn die Richtungszuordnung über turn:lanes nicht eindeutig ist, d.h. wenn eine Spur in mehrere Richtungen führt ("through;right").

@mueschel Es wäre sehr praktisch, wenn destination:arrow:lanes von deinem Tool unterstützt werden würde, so dass man an verschiedenen Beispielen sehen könnte ob es funktioniert oder ob bei bestimmten Wegweisern noch weitere Probleme auftauchen.

Ich hab mal hier so ein Beispiel: https://www.openstreetmap.org/way/188542338
Erschwerend kommt hinzu, dass für die Rechtsabbieger kein Reiseziel angegeben ist. Ich hoffe, ich habe das korrekt getaggt.

destination:arrow:lanes	left|left|through;right
destination:lanes	Pankow|Pankow|Bernau;
destination:ref:lanes	||B 2;
destination:ref:to:lanes	||A 10;
destination:symbol:to:lanes	||motorway;

hier das mapillary Bild dazu:

https://www.mapillary.com/app/?focus=ph … 09429&z=17

Und so sieht das in dem Tool von mueschel momentan aus: http://osm.mueschelsoft.de/cgi-bin/rend … &extendway

Last edited by Peter Maiwald (2016-09-07 23:49:37)

mueschel · 2016-09-08 20:11:15

@Peter: colour schreibt sich mit 'u' http://www.openstreetmap.org/way/188633782

Ich kann versuchen das arrow-Tag bei mir einzubauen, mit einem kleinen Pfeil-Symbol neben dem Eintrag. Nehmen wir den verlinkten Weg als Beispiel, würde ich bei den beiden Spuren ohne Ambiguitäten den Eintrag in destination:arrow allerdings weglassen, und würde das auch in der Wiki-Beschreibung empfehlen - "Sollte nur in den Fällen angegeben werden, in denen sich die Richtung nicht eindeutig aus dem Wegverlauf oder dem turn-Tag ergibt"

Peter Maiwald · 2016-09-08 21:22:25

mueschel wrote:

@Peter: colour schreibt sich mit 'u' http://www.openstreetmap.org/way/188633782

Uuups. Hab es korrigiert. Genau dafür ist so ein Kontrolltool gut.

mueschel wrote:

Ich kann versuchen das arrow-Tag bei mir einzubauen, mit einem kleinen Pfeil-Symbol neben dem Eintrag. Nehmen wir den verlinkten Weg als Beispiel, würde ich bei den beiden Spuren ohne Ambiguitäten den Eintrag in destination:arrow allerdings weglassen, und würde das auch in der Wiki-Beschreibung empfehlen - "Sollte nur in den Fällen angegeben werden, in denen sich die Richtung nicht eindeutig aus dem Wegverlauf oder dem turn-Tag ergibt"

Reduziert auf jeden Fall die Schreibfehler ;-) Arrow also nur angeben, wenn es bei einer Spur mehrere Möglichkeiten gibt zu fahren. Und dann wiederum nur bei der Spur angeben, wo es möglich ist in mehrere Richtungen zu fahren. Die anderen Spuren leer lassen. Hab ich das richtig verstanden?
Hab ich nichts dagegen.

Da es beim taggen per Hand tatsächlich leicht zu Fehlern kommen wird, aufgrund der doch etwas komplexen Art der Tags, wäre es wichtig ein Kontrolltool zu haben. Oder noch besser später ein Plugin für die Editoren welches übersichtliches Anlegen und gleichzeitige Kontrolle ermöglicht.

mueschel · 2016-09-08 21:34:12

Peter Maiwald wrote:

Genau dafür ist so ein Kontrolltool gut.

War tatsächlich mein anderes Tool, das erste aus der Signatur, dem es aufgefallen ist ;-)

Peter Maiwald wrote:

Die anderen Spuren leer lassen. Hab ich das richtig verstanden?

So würde ich das normalerweise sehen. Aber alles auszufüllen ist natürlich auch kein Fehler.

Peter Maiwald wrote:

Oder noch besser später ein Plugin für die Editoren

Ja, sowas muss sein. Mit JOSM-Plugins kenne ich mich aber nicht aus. Und die Eingabemaske einigermaßen benutzerfreundlich zu machen wird auch eine Herausforderung.

mueschel · 2016-09-11 16:42:28

Peter Maiwald wrote:

@mueschel Es wäre sehr praktisch, wenn destination:arrow:lanes von deinem Tool unterstützt werden würde, so dass man an verschiedenen Beispielen sehen könnte ob es funktioniert oder ob bei bestimmten Wegweisern noch weitere Probleme auftauchen.

Ist jetzt drin. Dein Beispiel musste ich allerdings anders taggen, da ich die Trennung von destination und destination:to (zur Zeit) nicht aufheben kann - das würde sonst alle anderen Wege die d:to verwenden kaputt machen.

http://osm.mueschelsoft.de/lanes/render … &placement

Die Platzierung der Pfeile ist noch nicht ganz ideal (Pfeile nach links und geradeaus sollten vor dem Symbol liegen, nicht dahinter), aber das ist technisch gerade etwas schwierig.

Announcement

#1 2016-09-04 19:43:08

destination:...-tags

#2 2016-09-04 21:22:34

Re: destination:...-tags

#3 2016-09-04 21:58:43

Re: destination:...-tags

#4 2016-09-04 22:51:45

Re: destination:...-tags

#5 2016-09-05 08:56:52

Re: destination:...-tags

#6 2016-09-05 10:03:09

Re: destination:...-tags

#7 2016-09-05 11:38:16

Re: destination:...-tags

#8 2016-09-05 21:40:52

Re: destination:...-tags

#9 2016-09-05 22:27:41

Re: destination:...-tags

#10 2016-09-06 10:02:51

Re: destination:...-tags

#11 2016-09-06 10:14:33

Re: destination:...-tags

#12 2016-09-06 11:39:29

Re: destination:...-tags

#13 2016-09-06 11:53:49

Re: destination:...-tags

#14 2016-09-06 12:19:21

Re: destination:...-tags

#15 2016-09-06 19:03:27

Re: destination:...-tags

#16 2016-09-06 19:31:52

Re: destination:...-tags

#17 2016-09-06 21:41:54

Re: destination:...-tags

#18 2016-09-06 21:57:47

Re: destination:...-tags

#19 2016-09-06 22:05:45

Re: destination:...-tags

#20 2016-09-07 13:01:04

Re: destination:...-tags

#21 2016-09-07 23:48:02

Re: destination:...-tags

#22 2016-09-08 20:11:15

Re: destination:...-tags

#23 2016-09-08 21:22:25

Re: destination:...-tags

#24 2016-09-08 21:34:12

Re: destination:...-tags

#25 2016-09-11 16:42:28

Re: destination:...-tags

Board footer