für destination:lanes bräuchte man ein neues Trennzeichen. Semikolon und | sind schon verbraucht. Welches nimmt man da am besten, das nicht auf Wegweisern benutzt wird?
Lange Version:
Bei verschiedenen Kreuzungen lassen sich die anzuzeigenden Richtungshinweise (siehe screenshot unten) nicht richtig auswerten. Beispiel eine zweispurige Straße, beide Spuren geradeaus, links Spur auch zum Linksabbiegen, rechte Spur auch zum Rechtsabbiegen.
turn:lanes=left;through|through;right
destination:lanes=Links1;Links2;Through1;Through2|Through1;Through2;Rechts1
Hier lässt sich zwar noch mittels komplizierter Stringvergleiche ermitteln, was bei welcher Richtung angezeigt werden soll, aber es gibt auch Situationen, wo es gar nicht mehr geht. Bspw wenn sich eine Spur teilt
turn:lanes=slight_left;slight_right
destination:lanes=A;B;C;D
Woher weiß jetzt der Auswerter, was er bei slight_left oder slight_right anzeigen soll?
Daher müsste man das mit einem Trennzeichen aufteilen. Ich grübele, ob es so geht…wobei das schief geht, wenn auf irgendeinem Wegweiser eckige Klammern genutzt werden
destination:lanes=[A;B;C][D]
Hi Thomas,
hilf mir bitte mal beim wach werden: willst du bei A,B,C den Namen des Zieles angeben? Also einen Text, der eventuell Klammern enthalten könnte?
Mir fallen da 2 Wege ein:
a) warum überhaupt Namen? Bei Turn-Restrictions z.B. geben wir ja auch keine benamten Ziele, sondern OSM-Objekte an.
b) Verdoppelung: “[” ist der Trenner und “[[” eine eckige Klammer im Text.
Gruss
walter
edit: (a) würde wohl nur in Relationen gehen. wäre wohl zuviel verlangt.
zu a) naja, beim AK Stuttgart wird u.a. München angezeigt. Wäre recht kompliziert erstmal den City Node von München und weiteren Städten wie Karlsruhe zu suchen
zu b) und Deiner ersten Frage: Ja, A,B,C waren Platzhalter für Orte. Ich habe keine Ahnung, ob irgendwo auf der Welt vielleicht “A-Stadt[am B Fluss]” auf einem Wegweiser geschrieben steht. Die Idee mit der Verdoppelung gefällt mir
Auf der Normaltaststur bieten sich “<>” und “{}” an. Weiter hinten im Unicode-Zeichen-Universum gibt es einen Haufen anderer Klammersymbole, die sind aber blöde einzugeben und werden mglw. nicht überall sauber dargestellt.
Eine alternative Lösung: tausche “[” und “]” in den Namen gleich bei der Eingabe gegen “(” und “)” aus.
Verdoppelung ist die für den Parser maximal lästige Lösung. Spätestens bei der Kombination von Klammerung und Sonderzeichen: “[A,B,[]]”: das schreit geradezu nach Implementierungsfehlern.
Lästig aber auch für den Erfasser. Denn “[” kommt praktisch nie in Namen vor, und wenn es denn mal vorkommt, ist die spezielle Schreibweise vergessen. Das gilt aber natürlich auch für die oben erwähnte Umwandlung in andere Klammern.
Wenn ich das richtig verstehe, werden für destination:lanes 3 verschiedene Trennzeichen benötigt:
Trennung von Ziele der gleichen Spur (bisher “;” verwendet)
Trennung bezüglich der Richtungen von turn:lanes (entspricht “;” bei turn:lanes)
Trennung der Spuren (bisher “|” verwendet)
Da das Semikolon für 2 (wegen der Übereinstimmung mit turn:lanes) eigentlich naheliegend wäre, aus Kompatibilitätsgründen für 1 aber bereits verbraucht ist, könnte man ein doppeltes Semikolon “;;” für 2 verwenden. Dies könnte man auch so argumentieren, dass 2 eigentlich ein Spezialfall von 1 ist, wobei dann das Semikolon aus turn:lanes als zweites Semikolon hinzukommt.
Bei dem “;;” dürfte die Kompatibilität mit vorhandenen Auswertern auch recht gut sein, da diese vermutlich nur ein zusätzliches leeres Ziel erkennen.
Unabhängig vom Trennzeichen, halte ich es aber für fragwürdig, ob man die Information wirklich derartig in destination:lanes erfassen sollte. Wenn man beispielsweise das Problem der Spurverknüpfung vor/nach der Kreuzung lösen würde, könnte sich der Auswerter das richtungsabhängige Ziel aus destination:lanes hinter der Kreuzung nehmen.
Könnten wir dies nicht bei einem Kodifizierungsmeeting entscheiden?
Danke SunCobalt dass Du auf dieses Problem hinweist. Es ist nämlich einer Der Aspekte der uns von der Verwendung der OSM Daten für die hochwertige Navigationssysteme trennt.
Wenn Du sowas realisieren möchtest, müsstest Du jeden möglichen Pfad prüfen (inkl Restriktion, da auf einem Wegweiser nicht erreichbare Ziele eher nicht draufstehen…also große Kruezung wo Linksabbiegen verboten ist, aber von anderen Richtungen erreichbar und daher auch destination:lanes Informationen enthält) und dann die destinantion:lanes einzeln von jedem abgehenden Weg zusammen suchen. Daher halte ich es für besser, wenn man das eher als Erfassen eines Wegweisers sieht und es da erfasst, wo der Wegweiser auch steht.
Ich halte von den blauen Hinweisschildern auf dem Navi gar nichts. Ergonomisch ist das für mich von null Nutzen, denn wer schaut schon auf sein Navi im Bereich von mehrspurigen Autobahnverzweigungen, um dort genau das zu entziffern, was ohnehin groß über den Fahrspuren steht. Für mich sind deutliche Pfeile zur Spurnutzung, die optimalerweise mit einer entsprechenden Ansage kombiniert werden, ausreichend. Alles andere erhöht nur das Unfallrisiko (zumindest solange diese Zeichen nicht im Bereich der Windschutzscheibe vor dem Fahrer bei allen PKW usw. eingeblendet werden).
Da gebe ich Dir Recht, aber statt die Information anzuzeigen, kann man sie ja auch ansagen: „Halten Sie sich rechts Richtung Frankfurt; Hanau“. Das lenkt nicht ab, sondern erleichtert die Orientierung auf Autobahnen ungemein.
Solche Zeichen helfen, wenn sie eingebelndet werden bevor du die großen Blauen auch nur erkennen kannst. dann weißt du wohin du dich begeben musst und kannst dich auch bei Bauarbeiten vernüftig orientieren!
…um dann auf den Vordermann aufzufahren, weil man mehrere Sekunden auf’s Navi stiert
Eine verbale Umsetzung, wie Nadjita sie vorschlägt finde ich besser.
Es fahren ja jeden Tag tausende Autofahrer auf ihren Vordermann auf, weil sie sekundenlang auf die Hinweisschilder in ihren neumodischen Navis starren…
b2t
Also wäre der Vorschlag “;;”, was dann so aussehen würde
Meines Erachtens reicht es im Allgemeinen, die Zielorte an den Wegen nach der Kreuzung zu erfassen. Dann erübrigen sich in vielen Fällen die Erfassung der Spur-Zielorte. Ein Navi kann (sollte können) die Information für die Spuren anhand der möglichen Folgewege recht gut ermitteln.
Dem kann ich nicht zu stimmen. Wie verhält es sich mit Kreuzungen wo kurz darauf die näcshte Kreuzung folgt. Dort muss man sich zwar noch gerade auseinordnen aber in wenigen huntert Metern ist dann die ganz linke Spur nicht mehr richtig. Insbesondere wenn sich Bundesstraßen trennen mit Staugefahr, dann wird um rechtzeitiges einsortieren gebeten. Diese Sachen kannst du mit einer reinen rechts links geradeaus Einteilung nicht abbilden.
Der Vorschlag, ein Doppelsemikolon zu benutzen, kam auch von Mapfactor. Ich bin mir nicht sicher, warum es nicht vorteilhaft wäre. Mir ist es letztendlich egal. Gegen _ und , spricht vielleicht, dass dann ein drittes Zeichen “verbraten” wird und gegen _ vielleicht noch, dass man es nicht unbedingt intuitiv als Trennzeichen interpretiert.
Warum muss man immer alles vom Sonderfall her aufzäunen?
Aber wenn die Leute Zielangaben schon bei den Spuren machen wollen und dabei mehr als einen Zielort haben, dann wäre ich für das Komma als Trennzeichen, da es das übliche Trennzeichen in Aufzählungen ist.
Bei allen anderen Trennzeichen, die man sich so ausdenken könnte, wäre damit zu rechnen, dass abweichend vom gewünschten Trennzeichen Aufzählungen sowieso von vielen Mappern mit Komma erfasst werden (da bereits gewohnt). Diesen Fall müsste/sollte eine Auswertung daher immer berücksichtigen. Warum also nicht direkt zur Regel erklären.
