destination:...-tags

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.

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.

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

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.

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.

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.

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:

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;

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

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.

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

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.

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.

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?

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.

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.

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.

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.

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

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

@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"

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.

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.

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.

mueschel wrote:

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.

Bei mir werden keine Pfeile angezeigt. Aber so kleine Kästchen, wo bestimmt die Bilddateien sein sollen.

Das sind keine Bilder, sondern Unicode-Zeichen. Eigentlich bin ich davon ausgegangen, das inzwischen auf jedem System ein halbwegs kompletter Unicode-Zeichensatz vorhanden ist, die Abbiegepfeile scheinst du ja nicht zu vermissen. Eventuell kannst du eine solche Schrift-Datei von Hand installieren? z.B. Arial Unicode.
Diesen Pfeil hier siehst du aber? ➔

Interessanterweise sehe ich im Tool auch die Kästchen und hier den Pfeil. Welche Unicode-Zeichen (Nummern, Hex-Werte) sind das denn? Vielleicht liegt es an den Schriftarten. Hier im Forum sind die per CSS festgelegt, beim Tool dagegen nur generisch als sans-serif.

➔ (0x2794) ist der "Ersatzpfeil", den ich (ab heute abend) nehmen werde, da er anscheinend auf mehr Rechnern verfügbar ist. Allerdings gibt es ihn nur nach rechts, d.h. ich muss ihn in CSS drehen.
Im Tool kommen im Moment ? (0x1f870) und Konsorten zum Einsatz.
Edit: Die Foren-Software scheint diesen Pfeil auch gar nicht zu mögen und ersetzt ihn anscheinend durch ein normales Fragezeichen...

Eine andere Möglichkeit wäre, 0x2190 und 0x2192 zu nehmen. Die entsprechenden weißen Pfeile über dem Wegweiser werden jedenfalls angezeigt.

Ist es jetzt besser?
http://osm.mueschelsoft.de/cgi-bin/rend … 0A&start=1

Der Pfeil neben der A 10 wird jetzt bei mir angezeigt - die anderen nutzen scheinbar immer noch den 0x1F800 Unicode-Block, da erscheinen bei mir nur Kästchen (und ich habe einige Schriftarten auf meinem System (Ubuntu 16.04) durchgetestet, aber in meiner Stichprobe war keine dabei, bei der diese Pfeile angezeigt werden, der zur A 10 dagegen bei allen).

Sorry, das war ein Fehler gestern. Jetzt sollte es aber wirklich besser sein.

Bei mir sind jetzt Pfeile zu sehen, ohne dass ich eine weitere Schriftart installieren musste.
Dein Beispiel sieht ja schon gut aus. Allerdings scheine ich noch Fehler beim taggen zu haben bei der echten Variante der Kreuzung.

Hier noch einmal das Mapillary Bild

Die linken beiden Spuren nach Pankow.
Geradeaus auf B 2 zur A 10 und nach Bernau.
Rechts abbiegen möglich ohne Angabe eines Ziels.

Hier ist die Straße, die ich nochmal versucht habe anzupassen:
https://www.openstreetmap.org/way/188542338

momentan so getaggt:
destination:arrow:lanes=slight_left|slight_left|through;right
destination:arrow:to:lanes=||through
destination:lanes=Pankow|Pankow|Bernau;
destination:ref:lanes=||B 2;
destination:ref:to:lanes=||A 10
destination:symbol:to:lanes=||motorway
destination:to:lanes=|||
highway=primary
lanes=3
maxspeed=50
maxspeed:conditional=30 @ (22:00-06:00)
name=Berliner Allee
oneway=yes
postal_code=13088
ref=B 2
turn:lanes=left|left|through;right

Und so sieht es in mueschels Tool aus:

http://osm.mueschelsoft.de/cgi-bin/rend … &placement

Meiner Meinung nach müsste der Pfeil nach rechts ohne Zielangabe in dem rechten leeren Feld stehen. Und eine Leerzeile unter der blauen Autobahnzeile ist wohl zu viel.
Wo ist der Fehler?

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

Der Eintrag 'right' ist nicht nötig. Es gibt keine destination die in diese Richtung weist. Dass man rechts abbiegen kann ergibt sich ja aus den turn:lanes. destination:arrow sollte nicht dazu da sein, Pfeile auf dem Schild zu taggen, sondern dazu einen Eintrag einer möglichen Fahrtrichtung.
'slight_right' sollte hier auch 'right' sein, zumindest nach turn:lanes und Zeichnung auf dem Schild.

destination:lanes=Pankow|Pankow|Bernau;

Das Semikolon fällt dann auch weg

destination:to:lanes=|||

Ein | zu viel, deswegen siehst du 4 Spuren

Die zusätzliche Leerzeile sehe ich nicht, liegt vielleicht am Browser. Welchen benutzt du?

Ok ich habe die von dir genannten Sachen geändert. Zusätzlich noch ein Semikolon hinter ||B 2 entfernt. Das kann ja dann wohl auch weg.

Dafür sind aber jetzt die Pfeile Richtung Pankow verschwunden. Ist das so korrekt oder hab ich noch etwas übersehen?
http://osm.mueschelsoft.de/cgi-bin/rend … &placement

Ich benutze übrigens den Google Chrome Browser.

Die Pfeile werden nicht angezeigt, wenn sie dem turn:lanes entsprechen. Im Prinzip ist das ja auch Teil des Schildes, auch wenn ich es oberhalb anzeige.

Hab noch eine Besonderheit gefunden, bei der es mehrere Möglichkeiten gäbe.

Hier sind insgesamt 4 Fahrspuren, wobei die 3. von links eine Radfahrerspur ist.
Also links|gerade aus|geradeaus nur für Radfahrer|rechts

Was macht man mit der Radfahrerspur? Gar keine destination angeben? Alle destination in der Richtung angeben incl. Autobahn und deren Endpunkte? Oder nur die Ziele, die nicht mit :to angegeben sind?

Ich habe mich mal für die letzte Möglichkeit entschieden, da ja Hamburg und Prenzlau über die A 114 von Radfahrern nicht erreicht werden können. Nach Prenzlau wäre es im Gegenteil für Radfahrern sehr schlau rechts abzubiegen. (Für Autofahrer eigentlich auch.)

Wenn man allerdings für die Radfahrerspur die selben Werte wie bei der Geradeausspur angeben würde, würde bei Müschels OSM Lane Visualizer ein großes Schild über die beiden Spuren entstehen ohne die Doppelungen Wedding und Flughafen Tegel. Ein bisschen taggen für den Renderer aber näher am originalen Schild.

Was meint ihr?

Hier ist der Way, den es betrifft:
https://www.openstreetmap.org/way/340726951

Das Schild dazu geht nicht weiter auf die Spuren ein:

So sieht es momentan aus in der Variante, nur die Ziele, die nicht mit :to angegeben sind auf dem Radweg:

Auch wenn sich das jetzt etwas von der eigentlichen Frage nach dem Flughafensymbol entfernt, möchte ich folgendes gern ergänzend fragen:
Wie setzt man am besten den destination-Inhalt einen Vorwegweiser in der einspurigen Zufahrt eines Kreisverkehrs um?
Beispiel:

So? :

destination:arrow:lanes=through;left;left;right
destination:colour:lanes=;;;white
destination:lanes=Selmsdorf;Lübeck;Herrnburg;Lüdersdorf

Das Ergebnis wäre dann hier zu sehen.
Ist das schon die (derzeit) bestmögliche Lösung ?

Grüße
Rainer

Der Vorwegweiser gibt die Ziele der ausgehenden Straßen an, und so sollte das auch IMHO gemappt werden. Also ohne lanes.

projecter63 wrote:

So? :

destination:arrow:lanes=through;left;left;right
destination:colour:lanes=;;;white
destination:lanes=Selmsdorf;Lübeck;Herrnburg;Lüdersdorf

Das Ergebnis wäre dann hier zu sehen.
Ist das schon die (derzeit) bestmögliche Lösung ?

Grüße
Rainer

Die Ziele sollten auf jedem Fall hinter dem Kreisel auf den ausgehenden Spuren auch noch erfasst werden, dort ist die Zuordnung dann ja klar. Ob man diesen Wegweiser an sich vor dem Kreisel erfassen sollte - ich würde es eher nicht machen. Falsch ist es aber sicher auch nicht.
@chris66: Ob mit oder ohne ":lanes" ist ziemlich egal, bei einer Spur allerdings auch unnötig.

Ich habe mich mal jetzt daran versucht. Ging aber eigentlich nur mir trial-and-error.

mueschel wrote:

http://osm.mueschelsoft.de/cgi-bin/render.pl

Tolles Tool! Wird es davon auch eine Offline-Version geben, also so, daß man die Tags auf der Webseite eintragen kann und dann ausprobiert, wie das Ergebnis aussieht. In JOSM ändern, hochladen, warten bis Overpass-API aktualisiert ist, Seite neu laden, ändern etc. ist etwas langwierig.

Ist es korrekt, daß das Tool kein Fähr-Symbol anzeigt? Ansonsten habe ich irgendwas verkehrt gemacht. [1]

Christian

[1] http://osm.mueschelsoft.de/cgi-bin/rend … country=de

chris66 wrote:

Der Vorwegweiser gibt die Ziele der ausgehenden Straßen an, und so sollte das auch IMHO gemappt werden. Also ohne lanes.

Oberster Mappinggrundsatz: Die Realität folgt keiner Regel hundertprozentig. https://www.mapillary.com/app/?lat=49.1 … ocus=photo (Vorwegweiser von Nordhausen her schildert für diese Ausfahrt "Heilbronn\nNordheim"). Die Beschilderung hat sich seit Bau des Kreisverkehrs vor ca. fünfzehn Jahren nicht geändert (damals gab es die Baugebiete an den Ausfahrten nach Süden und Westen sowie den Rewe noch nicht).

projecter63 wrote:

Auch wenn sich das jetzt etwas von der eigentlichen Frage nach dem Flughafensymbol entfernt, möchte ich folgendes gern ergänzend fragen:

Soll ich mal Die Überschrift/Thema/Betreff ändern, da es ja jetzt hier um die Etablierung des verbesserten Schemas mit Arrow und Slots für die Zuordnung von Symbolen, Farben und Pfeilen handelt? Quasi eine Diskussionsgrundlage für die Ergänzung im Wiki.

Und wie soll sie denn heißen?

Soll ich mal Die Überschrift/Thema/Betreff ändern, da es ja jetzt hier um die Etablierung des verbesserten Schemas mit Arrow und Slots für die Zuordnung von Symbolen, Farben und Pfeilen handelt? Quasi eine Diskussionsgrundlage für die Ergänzung im Wiki.

Und wie soll sie denn heißen?

Vorschlag: destination:...-tags

Und dann gleich noch 'ne Frage: Was ist denn mit den vielen km-Angaben auf den Wegweisertafeln (Z415, Z418, Z434 und Z453) ?

Gibt es da etwas in der Richtung "destination:distance", das auch ausgewertet wird ? Der OSM Lane Visualizer mag das offenbar (noch ?) nicht so recht ...
Habe dazu nix passendes im wiki gefunden, aber wenn wir schon den Inhalt von Wegweisertafeln erfassen, dann doch bitte auch diese Angaben - völlig losgelöst von den auf OSM-Daten abgeleiteten Routingergebnissen, die sich bisher herzlich wenig um die 'offiziell' ausgeschilderte Routenführung kümmern und mitten durch Egalwasauchimmer routen, Hauptsache der Fahrzeugtyp passt und darf da durch und die Route ist - je nach Belieben - die Kürzeste oder die Schnellste (vielleicht auch noch mit ein paar zusätzlichen Optionen).

brogo wrote:

Tolles Tool! Wird es davon auch eine Offline-Version geben, also so, daß man die Tags auf der Webseite eintragen kann und dann ausprobiert, wie das Ergebnis aussieht. In JOSM ändern, hochladen, warten bis Overpass-API aktualisiert ist, Seite neu laden, ändern etc. ist etwas langwierig.
Ist es korrekt, daß das Tool kein Fähr-Symbol anzeigt? Ansonsten habe ich irgendwas verkehrt gemacht. [1]

Das Tool kann auch mit JSON-Daten direkt im "Query"-Feld umgehen. Die Daten bekommst du indem du auf "Show in Overpass" klickst, dann "Ausführen", "Daten" und dann alles einfach kopieren. Dort kannst du dann nach Belieben lokal editieren und testen. Ist zwar nicht "Offline", da die Berechnungen noch auf dem Server stattfinden, aber die OSM-Datenbank wird nicht belästigt.

Fähren habe ich noch nicht drin, wie auch einige andere Symbole. Siehe https://github.com/mueschel/OsmLaneVisu … signs.scss

projecter63 wrote:

Gibt es da etwas in der Richtung "destination:distance", das auch ausgewertet wird ? Der OSM Lane Visualizer mag das offenbar (noch ?) nicht so recht ...

Nein, sowas gibt es nicht. Dafür müsste dann eine destination_sign Relation herhalten. Ein zentrales Problem ist, dass Entfernungsangaben gemappt an einem Weg wenig Sinn haben - dazu braucht es schon einen Referenzpunkt. Bei 50 km macht das wenig Unterschied, aber was ist mit "Parkplatz - 100 m"?

Moin,

projecter63 wrote:

Und dann gleich noch 'ne Frage: Was ist denn mit den vielen km-Angaben auf den Wegweisertafeln (Z415, Z418, Z434 und Z453) ?
[...]
aber wenn wir schon den Inhalt von Wegweisertafeln erfassen, dann doch bitte auch diese Angaben

ich finde, dass für erfassten Daten auch irgendein sinnvoller Anwendungsfall angedacht sein sollte.
Das der Fahrspurassistent die Schilder 'real' wiedergibt ist für mich jetzt kein sonderlich sinnvoller Anwendungsfall.
Diese Daten bieten keinen Mehrwert, der nicht auch per Auge vom Schild direkt abgelesen werden kann (Bis zum Zentrum des angegeben Ortes sind es ... km) - was auch selten eine Beziehung zur gewählten Route hat.
Auch die Ansage der destination ist nur eine indirekte Hilfe, um auf den realen Schildern die Spurführung ablesen zu können.

Diese Spurführungs-Information ergibt sich aber bereits direkt aus den lane-Daten und kann grafisch wie akustisch auch ohne destination wiedergegeben werden.
Eine überladene Anzeige ist nicht unbedingt einfacher zu lesen - nur 'hübscher' anzuschauen.

Diese km-Angaben sind m. E. rein historisch zu betrachten (ohne GPS und Navi).

Grüße, Georg

mueschel wrote:

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:
http://osm.mueschelsoft.de/destinationwikiexample.png

Wie sieht es denn aus mit der Eintragung ins Wiki?
Ein Beispiel mit destination:arrow:lanes für Spuren, wo man in mehrere Richtungen fahren darf wäre auch toll. Und eine kleine Beschreibung hinzu, wie die Slots funktionieren und an welcher Stelle destination:arrow:lanes erforderlich ist.
Hat einer Lust und kann halbwegs verständlich formulieren?

Wer möchte kann sich hier austoben: https://wiki.openstreetmap.org/wiki/Pro … on_details

Ich hätte diese Dinge am liebsten direkt mit in das Proposal von Imagic aufgenommen. Ich hatte ihn vor einiger Zeit deswegen angeschrieben, aber leider noch keine Antwort bekommen. Noch eine weitere Wiki-Seite aufmachen finde ich nicht gut, am Ende verliert man dann komplett den Überblick, was wo steht. Man könnte natürlich die Infos aus dem bestehenden Proposal kopieren, aber das ist nicht ganz die feine Art und konsistent wird es auf längere Sicht auch nur schwierig bleiben.

mueschel wrote:

Ich hätte diese Dinge am liebsten direkt mit in das Proposal von Imagic aufgenommen.

Imagic möchte das nicht und schlägt vor ein neues Proposal aufzumachen (https://wiki.openstreetmap.org/w/index. … id=1132467)

Mal ne Frage zur Datenmodellierung: Die Ziele eines ways oder einzelner Fahrspuren am way zu taggen ist ja prima, das sind Attribute des ways. Aber warum bitteschön sollten Attribute des Wegweisers (hier: Platzierung/Zuordnung von Piktogrammen zu Zielangaben/Zeilen) am way modelliert werden und nicht an einem Objekt, das den Wegweiser beschreibt?

P.

Peilscheibe wrote:

Mal ne Frage zur Datenmodellierung: Die Ziele eines ways oder einzelner Fahrspuren am way zu taggen ist ja prima, das sind Attribute des ways. Aber warum bitteschön sollten Attribute des Wegweisers (hier: Platzierung/Zuordnung von Piktogrammen zu Zielangaben/Zeilen) am way modelliert werden und nicht an einem Objekt, das den Wegweiser beschreibt?

Ich versuche darauf im Wiki einzugehen:

https://wiki.openstreetmap.org/wiki/Proposed_features/More_destination_details wrote:

Important: The scope of destination=* and it's subkeys is to support routing. A "photo-realistic" rendering of traffic signs, especially the geometry of entries on the sign - is not the scope of destination tags on ways.

Ref, Farbe und Symbole unterstützen meines Erachtens bei der Darstellung von Zielen. Die Pfeile sehe ich auch eher bei der Darstellung von Schildern, also nicht auf dem Way sondern auf dem Schild. Für die Unterstützung beim Abbiegen gibt es die Richtungspfeile auf der Straße, also turn(:lanes)=*

Jojo4u wrote:

mueschel wrote:

Ich hätte diese Dinge am liebsten direkt mit in das Proposal von Imagic aufgenommen.

Imagic möchte das nicht und schlägt vor ein neues Proposal aufzumachen (https://wiki.openstreetmap.org/w/index. … id=1132467)

Ich hatte das eher so verstanden, dass er nicht möchte, dass Änderungen an seinem Proposal einfach eingefügt werden. Aber das kann nur er selbst sagen.

Ein weiteres Proposal aufzumachen halte ich nicht für sinnvoll. Ich versuche gerade, eine Übersicht zu schreiben die beschreibt welche Methoden es gibt und wie sie eingesetzt werden. Also eher eine Beschreibung von "state of the art" als ein weiteres Proposal, das dann wieder jahrelang ohne Abstimmung rumliegt.

Peilscheibe wrote:

Aber warum bitteschön sollten Attribute des Wegweisers (hier: Platzierung/Zuordnung von Piktogrammen zu Zielangaben/Zeilen) am way modelliert werden und nicht an einem Objekt, das den Wegweiser beschreibt?

Genau das wird gemacht mit der Relation type=destination_sign. Auf die eine odere andere Weise muss der Wegweiser ja den einzelnen Wegen / Spuren zugeordnet werden. Nur über Tags am Schild geht es nicht, und für viele sind die Relationen (berechtigterweise) zu aufwendig und komplex. Als Lösung bleibt das Taggen direkt am Weg wie es jetzt gemacht wird.

Im Prinzip ist es ja nicht anderes als maxspeed auch - wir taggen es am Weg, obwohl es ja eigentlich an ein Schild-Objekt gehört und genau wie destinations Auswirkungen auf die Straße hat.

Ich habe hier mal alles was es an destination*=* im Augenblick gibt zusammengefasst.
https://wiki.openstreetmap.org/wiki/Use … ionTagging

Beispiele, die auf den anderen Wikiseiten fehlen braucht es natürlich noch. Anmerkungen & Verbesserungen sind natürlich willkommen.

Ich versuche gerade den Prozess zu verstehen, den wir gehen müssen, um die hier erarbeiteten Vorschläge ins Wiki zu bekommen. Stimmt das so, wie ich das verstehe? Bitte korrigiert mich.

1. Um diese, in diesem Forumsbeitrag überlegten Änderungen ins Wiki zu bekommen, benötigen wir einen Abstimmungsprozess?

2. Es existiert bereits ein Proposal, welches einige Elemente des jetzigen Vorschlags enthält. Der Ersteller (Imagic) möchte aber keine Erweiterung seines Vorschlags und seit Vorschlag existiert seit 2012 und ist immer noch nicht abgestimmt. Siehe hier: https://wiki.openstreetmap.org/w/index. … id=1132467

3. Um unsere jetzigen Vorschläge ins Wiki zu bekommen benötigen wir also einen extra Vorschlag? Jojo4u hat diesen vorbereitet: https://wiki.openstreetmap.org/wiki/Pro … on_details

4. Jetzt müssten doch eigentlich alle noch nicht abgestimmte Elemente, die mueschel hier sehr ausführlich beschreibt: https://wiki.openstreetmap.org/wiki/Use … ionTagging in das neue Proposal hier: https://wiki.openstreetmap.org/wiki/Pro … on_details

5. Wie zeitnah kann so ein Abstimungsprozess umgesetzt werden, damit der Vorschlag nicht auch 4 Jahre rumliegt?

6. Gibt es Alternativen, um diesen Vorschlag zu etablieren und ins Wiki zu bekommen?

Einige Teile des Vorschlags sind anscheinen schon im deutschen Wiki zu finden:
https://wiki.openstreetmap.org/wiki/DE: … ion:symbol
https://wiki.openstreetmap.org/wiki/DE: … nation:ref

Proposal - request for comments - voting (ein halbes Jahr vielleicht) ist der übliche Prozess, allerdings hier etwas schwierig.
Viele "Spezial-Tags", und zu denen zähle ich die destination-Details auch, wurden nicht über Abstimmungen eingeführt und trotzdem benutzt. Das Problem einer Abstimmung ist dabei immer die Zahl derer die mit "nein" stimmen mit Begründungen wie "wer braucht das schon".

Tags die in Benutzung sind, können ja durchaus auch eine eigene Wiki-Seite haben, die dann als Tag-Status draft, proposed, in use, oder de facto haben. Ich würde damit anfangen, für die Tags diese Seiten anzulegen, vorrangig in Englisch, jeweils mit Status = proposed, Link zum Proposal und das auch jeweils in einer der ersten Zeilen zu erwähnen. Bei Keys, die schon weit über 1000 Mal verwendet werden, sehe ich da kein Problem, auch wenn sie nicht "approved" sind.

mueschel wrote:

Proposal - request for comments - voting (ein halbes Jahr vielleicht) ist der übliche Prozess, allerdings hier etwas schwierig.
Viele "Spezial-Tags", und zu denen zähle ich die destination-Details auch, wurden nicht über Abstimmungen eingeführt und trotzdem benutzt. Das Problem einer Abstimmung ist dabei immer die Zahl derer die mit "nein" stimmen mit Begründungen wie "wer braucht das schon".

Tags die in Benutzung sind, können ja durchaus auch eine eigene Wiki-Seite haben, die dann als Tag-Status draft, proposed, in use, oder de facto haben. Ich würde damit anfangen, für die Tags diese Seiten anzulegen, vorrangig in Englisch, jeweils mit Status = proposed, Link zum Proposal und das auch jeweils in einer der ersten Zeilen zu erwähnen. Bei Keys, die schon weit über 1000 Mal verwendet werden, sehe ich da kein Problem, auch wenn sie nicht "approved" sind.

Sehr schön. Die von dir beschriebene Vorgehensweise gefällt mir schon viel besser.
Von den Abstimmungen und den beschriebenen Problemen dabei weiß ich schlichtweg zu wenig, um eine Einschätzung abzugeben. Evtl. sind diese Probleme ja auch dafür verantwortlich, dass die Vorschlagsseite von Imagic in seinem Status verharrt.

Ich habe noch einen Sonderfall gefunden, bei dem noch irgendetwas nicht richtig zu sein scheint:

Hier das Foto vom Schild:
https://www.mapillary.com/app/?focus=ph … 29668&z=17

So ist es getaggt:
https://www.openstreetmap.org/way/24598 … 7/13.43007

Und so sieht es in der Auswertung aus:
http://osm.mueschelsoft.de/cgi-bin/rend … country=de

Das Problem ist die rechte Spur, die geradeaus und rechts fahren erlaubt. Geradeaus ist jedoch keine Ziel angegeben (destination:lanes) aber ein destination:ref:lanes=B 109;; (mal nur diese Spur betrachtet). Damit das ref nicht in dem Slot für das erste Ziel rechts erscheint habe ich bei destination:lanes noch ein ; vor den beiden Zielen für Rechtsabbieger eingefügt (für die Geradeausspur mit destination:ref:lanes=B109;; dieser Spur). Das ref sollte dann mit destination:arrow:lanes=through;right;right in dem Slot von through sein.

In der Auswertung mit mueschels OSM Lane Visualizer landet dann aber der Pfeil für geradeaus nicht neben dem ref B 109, sondern in einer extra leeren Zeile.
http://osm.mueschelsoft.de/cgi-bin/rend … country=de

Wo ist der Fehler?

ref's werden noch nicht "geslottet", die tauchen im Augenblick immer unten auf. Ich werde das demnächst mal ausprobieren, ob das funktioniert oder zuviele falsche Darstellungen bei "normalem" Tagging ohne Slots verursacht.

mueschel wrote:

Ich hatte das eher so verstanden, dass er nicht möchte, dass Änderungen an seinem Proposal einfach eingefügt werden. Aber das kann nur er selbst sagen.

Seine Aussage dazu ist eindeutig: Please write your own proposal if you are not satisfied with this one. I do not propose the colour subkey.

mueschel wrote:

Proposal - request for comments - voting (ein halbes Jahr vielleicht) ist der übliche Prozess, allerdings hier etwas schwierig.
Viele "Spezial-Tags", und zu denen zähle ich die destination-Details auch, wurden nicht über Abstimmungen eingeführt und trotzdem benutzt. Das Problem einer Abstimmung ist dabei immer die Zahl derer die mit "nein" stimmen mit Begründungen wie "wer braucht das schon".

Tags die in Benutzung sind, können ja durchaus auch eine eigene Wiki-Seite haben, die dann als Tag-Status draft, proposed, in use, oder de facto haben. Ich würde damit anfangen, für die Tags diese Seiten anzulegen, vorrangig in Englisch, jeweils mit Status = proposed, Link zum Proposal und das auch jeweils in einer der ersten Zeilen zu erwähnen. Bei Keys, die schon weit über 1000 Mal verwendet werden, sehe ich da kein Problem, auch wenn sie nicht "approved" sind.

Ich stimme zu. Zum Thema destination: Imagic bringt seine Proposals üblicherweise nicht zur Abstimmung (Voting is bullshit). Sie werden erstellt, getestet, überarbeitet und setzen sich dann durch oder nicht. Der Proposal Prozess ist für komplexe Dinge nicht sehr gut passend da diese sich iterativ entwickeln müssen. Dass abgestimmte Proposals Probleme bereiten (natural=water vs. landuse=reservoir; relation type=parking, PTv2) ist durchaus schon vorgekommen.