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.
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/render.pl?wayid=133390689&start=1&country=de
Oberster Mappinggrundsatz: Die Realität folgt keiner Regel hundertprozentig. https://www.mapillary.com/app/?lat=49.10612735328049&lng=9.121362626596424&z=17&pKey=aO0G8TDZsiYyj7HAKyhNHQ&focus=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).
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).
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/OsmLaneVisualizer/blob/master/_destinationsigns.scss
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,
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
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/Proposed_features/More_destination_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.
Imagic möchte das nicht und schlägt vor ein neues Proposal aufzumachen (https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Destination_details&diff=1132476&oldid=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.
Ich versuche darauf im Wiki einzugehen:
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)=*
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.
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/User:Mueschel/DestinationTagging
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.
-
Um diese, in diesem Forumsbeitrag überlegten Änderungen ins Wiki zu bekommen, benötigen wir einen Abstimmungsprozess?
-
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.php?title=Proposed_features/Destination_details&diff=1132476&oldid=1132467
-
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/Proposed_features/More_destination_details
-
Jetzt müssten doch eigentlich alle noch nicht abgestimmte Elemente, die mueschel hier sehr ausführlich beschreibt: https://wiki.openstreetmap.org/wiki/User:Mueschel/DestinationTagging in das neue Proposal hier: https://wiki.openstreetmap.org/wiki/Proposed_features/More_destination_details
-
Wie zeitnah kann so ein Abstimungsprozess umgesetzt werden, damit der Vorschlag nicht auch 4 Jahre rumliegt?
-
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:Key:destination:symbol
https://wiki.openstreetmap.org/wiki/DE:Key:destination: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.
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=photo&pKey=eRck-L7Wi3Ic60m6iYhoWA&lat=52.549828&lng=13.429668&z=17
So ist es getaggt:
https://www.openstreetmap.org/way/245988699#map=19/52.55057/13.43007
Und so sieht es in der Auswertung aus:
http://osm.mueschelsoft.de/cgi-bin/render.pl?wayid=245988699&start=1&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/render.pl?wayid=245988699&start=1&country=de
Wo ist der Fehler?