Trennzeichen gesucht

SunCobalt wrote:

Ich grübele, ob es so geht...wobei das schief geht, wenn auf irgendeinem Wegweiser eckige Klammern genutzt werden

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.

wambacher wrote:

SunCobalt wrote:

Ich grübele, ob es so geht...wobei das schief geht, wenn auf irgendeinem Wegweiser eckige Klammern genutzt werden

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

Nahmd,

SunCobalt wrote:

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]

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.

wambacher wrote:

Verdoppelung: "[" ist der Trenner und "[[" eine eckige Klammer im Text.

Verdoppelung ist die für den Parser maximal lästige Lösung. Spätestens bei der Kombination von Klammerung und Sonderzeichen: “[A,B,[[X]]]”: 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.

Gruß Wolf

Welches navi zeigt das kam schon so an ?

Gruß Jan

Lübeck wrote:

Welches navi zeigt das kam schon so an ?

Gruß Jan

https://play.google.com/store/apps/deta … .navigator

Wenn ich das richtig verstehe, werden für destination:lanes 3 verschiedene Trennzeichen benötigt:

1. Trennung von Ziele der gleichen Spur (bisher ";" verwendet)
2. Trennung bezüglich der Richtungen von turn:lanes (entspricht ";" bei turn:lanes)
3. 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.

Wenn man ...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.

Beste Grüße,
Marek

slhh wrote:

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.

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.

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.

Machen die "Profis" in der Kartenerfassung auch nicht anders. Ich bin sehr dafür.

marek kleciak wrote:

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.

Machen die "Profis" in der Kartenerfassung auch nicht anders...

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

hurdygurdyman wrote:

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.

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.

hurdygurdyman wrote:

marek kleciak wrote:

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.

Machen die "Profis" in der Kartenerfassung auch nicht anders...

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.

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!

viw wrote:

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.

hurdygurdyman wrote:

...um dann auf den Vordermann aufzufahren, weil man mehrere Sekunden auf's Navi stiert 🙄

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

SunCobalt wrote:

hurdygurdyman wrote:

...um dann auf den Vordermann aufzufahren, weil man mehrere Sekunden auf's Navi stiert 🙄

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

http://img17.imageshack.us/img17/5161/5h9g.jpg

Was spräche gegen "_" oder ","? doppelte Trennezeichen wurden als nicht vorteilhaft angesehen.

SunCobalt wrote:

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.

Edbert (EvanE)

EvanE wrote:

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.

Edbert (EvanE)

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.

viw wrote:

Was spräche gegen "_" oder ","? doppelte Trennezeichen wurden als nicht vorteilhaft angesehen.

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.

viw wrote:

EvanE wrote:

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ächste 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.

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.

Edbert (EvanE)

EvanE wrote:

viw wrote:

EvanE wrote:

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ächste 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.

Warum muss man immer alles vom Sonderfall her aufzäunen?

OSMAND macht es so. Es versucht anhand der abgehenden Spuren zur erraten, wie die Spuren auf der jetzigen Straße aussehen. Ich bin damit eine Weile rumgefahren und habe ich zunehmend darüber geärgert. Man merkt erst wenn man sich damit beschäftigt, wieviele "komplexe" Kreuzungen es gibt. Manche sehen gar nicht so aus und man merkt es erst beim taggen. Ich habe mehrere "Sonderfälle" auf meinem Weg ins Büro.
Und wenn man ein Schema einführt, dann wäre ein zukunftsicheres, was auch komplexe Situationen umfasst, meiner Meinung nach besser.

SunCobalt wrote:

hurdygurdyman wrote:

...um dann auf den Vordermann aufzufahren, weil man mehrere Sekunden auf's Navi stiert 🙄

Es fahren ja jeden Tag tausende Autofahrer auf ihren Vordermann auf, weil sie sekundenlang auf die Hinweisschilder in ihren neumodischen Navis starren.... 🤔
...

Schon einer (Auffahrunfall o.ä.) wäre zuviel, wenn jemand dadurch zu Schaden käme. Pfeile auf dem Navi zu erkennen, geht noch relativ fix, aber mehrere Ortsnamen zu lesen, kann schnell die Zeit eines Sekundenschlafes übersteigen. Ergonomisch ist und bleibt die geschriebene fotoähnliche Übernahme dieser Informationen für mich Blödsinn. Ein akustischer Hinweis wie z.B. "Halten Sie sich links und fahren Sie in Richtung München Augsburg" wäre sinnvoller.

Als Begleiter ist es praktisch, wenn das angezeigt wird: Da kann man das in Ruhe mit den Schildern vergleichen und seinem Fahrer sagen, dass er eine Spur weiter nach rechts müsste.

EvanE wrote:

Warum muss man immer alles vom Sonderfall her aufzäunen?

Weil man nicht für Sonderfälle wieder einen extra Schlüssel/Tag machen sollte. Ein Shema hat nur dann eine Chance wenn es die meisten Fälle auch abdecken kann. Wenn man schon an Autobahnkreuzen scheitertet und nur normale Ausfahrten taggen kann, dann lohnt der Aufwand wohl nicht.

SunCobalt wrote:

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.

http://blob.freent.de/contentblob/59877 … 024118.jpg

Die Ausschilderungen für die gleiche Abgangsrichtung aus verschiedenen Zugangsrichtungen kann unterschiedlich sein. Einen Wegweiser dort zu erfassen, wo er steht, wäre daher schon sinnvoll.
Sofern man sich exakt auf das beschränkt, was auf dem Wegweiser steht, wäre dies sehr hilfreich für eine Ansage im Navi.

Leider scheint mir key:destination aber diesbezüglich nicht eindeutig definiert zu sein. Wenn man darin alle Ziele unterbringt, die der Mapper für sinnvoll hält, kann man diese Info auch aus dem Abgangsweg herausholen.

slhh wrote:

Leider scheint mir key:destination aber diesbezüglich nicht eindeutig definiert zu sein.

https://wiki.openstreetmap.org/w/index.php?title=Key:destination&oldid=883930#User_defined_values wrote:

and which are explicitly indicated

Ich hab's aber auch erst nach mehrmaligem Durchlesen der englischen Version beim zweiten Durchlesen der deutssprachigen Übersetzung entdeckt. Vielleicht sollte man das irgendwie deutlicher schreiben.

/e: codefix

SunCobalt wrote:

Und wenn man ein Schema einführt, dann wäre ein zukunftsicheres, was auch komplexe Situationen umfasst, meiner Meinung nach besser.

+1
Wenn man das Schema zu einfach macht, wird es am Ende nur besonders kompliziert.

Die Sonderfälle sind meistens wohl auch diejenigen Stellen, wo der Fahrer gute Unterstützung vom Navi braucht. Wenn es denn gerade hier nicht funktioniert, ist die Gesamtlösung eher unbrauchbar.

slhh wrote:

Leider scheint mir key:destination aber diesbezüglich nicht eindeutig definiert zu sein. Wenn man darin alle Ziele unterbringt, die der Mapper für sinnvoll hält, kann man diese Info auch aus dem Abgangsweg herausholen.

Ich hatte das hier so verstanden, dass nur das, was auf dem Schild steht, erfasst werden soll.
http://wiki.openstreetmap.org/wiki/Key: … s_per_lane
Am 5. Beispiel sieht mehr sehr schon den Bedarf an einem Trennzeichen

moin, ich wäre ebenfalls für das Komma.

EvanE wrote:

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.

Edbert (EvanE)

mMn ist beides sinnvoll. Je mehr Infos der Router hat desto bessere Anweisungen kann er generieren.

chris66 wrote:

EvanE wrote:

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.

mMn ist beides sinnvoll. Je mehr Infos der Router hat desto bessere Anweisungen kann er generieren.

In der Tat gibt es mehrere unterschiedliche Situationen.
- Einmal die Abzweigung selber, da gehört destination=* an die Wege, nach der Trennung.
- Zum zweiten die Wegweiser am Beginn der Ausfädelspuren.
Bis zum eigentlichen Abzweig sollte man die Richtungen nach Spuren unterscheiden.
- Zum dritten die Vor-Wegweiser typisch 500-800m vor dem Abzweig noch ohne Ausfädelspuren.
Das hängt davon ab, ob das Schild bereits Spurinformationen enthält oder nicht.
Siehe das letzte Beispiel bei Key:destination#Destinations per lane

Edbert (EvanE)

um mal kurz zum eigentlichen Problem zurück zu kommen. Das Komma wird also bevorzugt. Falls jemand Einwände hat, so möge er jetzt sprechen oder für immer schweigen ....oder so ähnlich.

Wenn du dir sicher bist, dass auch in keinem anderen Land Kommas auf Wegweisern vorkommen...

SunCobalt wrote:

Das Komma wird also bevorzugt. Falls jemand Einwände hat, so möge er jetzt sprechen oder für immer schweigen ....oder so ähnlich.

Na gut, hier fürs Protokoll: Mir ist der doppelte Strichpunkt sympathischer. Das Komma ist ein zu wichtiges Zeichen, um es als Trennzeichen zu verbraten. Und bezüglich der Mapping-Ergonomie sind die zwei Strichpunkte schön zu erkennen, während der Unterschied zwischen Strichpunkt und Komma in irgendwelchen mickrigen Eingabefeldern leicht untergeht.

MetiorErgoSum wrote:

SunCobalt wrote:

Das Komma wird also bevorzugt. Falls jemand Einwände hat, so möge er jetzt sprechen oder für immer schweigen ....oder so ähnlich.

Na gut, hier fürs Protokoll: Mir ist der doppelte Strichpunkt sympathischer. Das Komma ist ein zu wichtiges Zeichen, um es als Trennzeichen zu verbraten. Und bezüglich der Mapping-Ergonomie sind die zwei Strichpunkte schön zu erkennen, während der Unterschied zwischen Strichpunkt und Komma in irgendwelchen mickrigen Eingabefeldern leicht untergeht.

+1

Habe gerade die ganze Diskussion durchgelesen und bin der gleichen Meinung.

SunCobalt wrote:

um mal kurz zum eigentlichen Problem zurück zu kommen. Das Komma wird also bevorzugt. Falls jemand Einwände hat, so möge er jetzt sprechen oder für immer schweigen ....oder so ähnlich.

Bilder sagen mehr als ...
Hier mal die Bildersuche aktivieren: https://www.google.de/search?q=direction+signs und 2-3 Seiten blättern. Ich habe bis auf runde Klammern weder "[]", "," oder ";" gefunden. Und die runden Klammern bedeuten wohl ein "via". Also würde ich mir nicht allzu große Sorgen machen.

Ob nun Komma oder Semikolon? Komma trennt Elemente einer Liste, Semikolon trennt Listen.
Daher würde ich ; zur Trennung der Lanes bevorzugen. Wenn auf einer Lane mehrere Ziele angegeben werden, trennt man die durch Kommata.
Ist ja auch bei Opening_hours der Fall: ; trennt Tage und Komma trennt Uhrzeiten.

Gruss
walter

wambacher wrote:

Bilder sagen mehr als ...
Hier mal die Bildersuche aktivieren: https://www.google.de/search?q=direction+signs und 2-3 Seiten blättern. Ich habe bis auf runde Klammern weder "[]", "," oder ";" gefunden. Und die runden Klammern bedeuten wohl ein "via". Also würde ich mir nicht allzu große Sorgen machen.

Hallo Walter

Dein Link hat mich auf die Idee gebracht. Das Plus-Zeichen wäre optimal.
Es symbolisiert genau das, was man ausdrücken möchte:
Auf dieser Spur geht es nach A-Stadt und B-Stadt.

Warum kommt man auf die einfachsten Sachen nur durch Zufall?
Edbert (EvanE)

wambacher wrote:

Ob nun Komma oder Semikolon? Komma trennt Elemente einer Liste, Semikolon trennt Listen.
Daher würde ich ; zur Trennung der Lanes bevorzugen. Wenn auf einer Lane mehrere Ziele angegeben werden, trennt man die durch Kommata.
Ist ja auch bei Opening_hours der Fall: ; trennt Tage und Komma trennt Uhrzeiten.

Wenn man schon ein Komma nimmt, dann ist dies die logische aber leider auch die inkompatible Variante. Diese würde ich nur dann für akzeptabel halten, wenn man sich darauf einigt, per Bot die bisherige Verwendung des Semikolons auf ein Komma bei allen destination Keys konsequent weltweit umzustellen. Entsprechendes wurde auch gelten, wenn man das bisherige Semikolon durch ein Plus-Zeichen ersetzt.

Die Umkehrung von Komma und Semikolon wäre zwar mit der bisherigen Verwendung kompatibel aber auch wieder so unlogisch, dass es häufig zu Verwechslungen kommen dürfte. Daher lehne ich diese ab.

Ich fand von den bisherigen Vorschlägen Doppel-Semikolon und eckige Klammern (in der Reihenfolge) am besten.

EvanE wrote:

Das Plus-Zeichen wäre optimal.
Es symbolisiert genau das, was man ausdrücken möchte:
Auf dieser Spur geht es nach A-Stadt und B-Stadt.

Das "+" Zeichen kommt in Firmennamen vor (Google findet z.B. einige zu "a+b") und Firmennamen können potentiell auch auf Wegweisern auftauchen.

slhh wrote:

EvanE wrote:

Das Plus-Zeichen wäre optimal.
Es symbolisiert genau das, was man ausdrücken möchte:
Auf dieser Spur geht es nach A-Stadt und B-Stadt.

Das "+" Zeichen kommt in Firmennamen vor (Google findet z.B. einige zu "a+b") und Firmennamen können potentiell auch auf Wegweisern auftauchen.

und in P+R (Park and Ride), was auf vielen Schildern steht

SunCobalt wrote:

slhh wrote:

Leider scheint mir key:destination aber diesbezüglich nicht eindeutig definiert zu sein. Wenn man darin alle Ziele unterbringt, die der Mapper für sinnvoll hält, kann man diese Info auch aus dem Abgangsweg herausholen.

Ich hatte das hier so verstanden, dass nur das, was auf dem Schild steht, erfasst werden soll.

Ausser dem abgebildeten Wegweiser gibt es in der Definition im Kopf der Wikiseite keinen Hinweis bezüglich einer Beschränkung auf ausgeschilderte Ziele. Hier im Thread mag man vielleicht anderes für sinnvoll halten, jedoch dürfte insgesamt ein Konsens für eine Beschränkung nicht herbeizuführen sein.

Daher schlage ich vor, ausgeschilderte und nicht ausgeschilderte Ziele dadurch zu unterscheiden, dass man die Einen davon z.B. in eckige Klammern setzt. Einen Konflikt mit der Verwendung eckiger Klammern innerhalb eines Zieles gibt es dabei übrigens nicht, solange nicht das ganze Ziel in eckigen Klammern steht.

slhh wrote:

SunCobalt wrote:

slhh wrote:

Leider scheint mir key:destination aber diesbezüglich nicht eindeutig definiert zu sein. Wenn man darin alle Ziele unterbringt, die der Mapper für sinnvoll hält, kann man diese Info auch aus dem Abgangsweg herausholen.

Ich hatte das hier so verstanden, dass nur das, was auf dem Schild steht, erfasst werden soll.

Ausser dem abgebildeten Wegweiser gibt es in der Definition im Kopf der Wikiseite keinen Hinweis bezüglich einer Beschränkung auf ausgeschilderte Ziele. Hier im Thread mag man vielleicht anderes für sinnvoll halten, jedoch dürfte insgesamt ein Konsens für eine Beschränkung nicht herbeizuführen sein.

Daher schlage ich vor, ausgeschilderte und nicht ausgeschilderte Ziele dadurch zu unterscheiden, dass man die Einen davon z.B. in eckige Klammern setzt. Einen Konflikt mit der Verwendung eckiger Klammern innerhalb eines Zieles gibt es dabei übrigens nicht, solange nicht das ganze Ziel in eckigen Klammern steht.

Blöde Frage.....wirklich ernst gemeint. Welche Anwendung stellst Du Dir vor, die nicht ausgeschilderte Ziele nutzt?

slhh wrote:

Ausser dem abgebildeten Wegweiser gibt es in der Definition im Kopf der Wikiseite keinen Hinweis bezüglich einer Beschränkung auf ausgeschilderte Ziele.

Doch, gibt es. Auf Deutsch: "Mögliche Werte sind jeweils die Namen der Orte zu denen eine Straße führt und welche explizit ausgewiesen sind." (Hervorhebung nicht von mir)

Ansonsten würde ich mir auch die Frage nach der Sinnhaftigkeit davon stellen.

rayquaza wrote:

slhh wrote:

Ausser dem abgebildeten Wegweiser gibt es in der Definition im Kopf der Wikiseite keinen Hinweis bezüglich einer Beschränkung auf ausgeschilderte Ziele.

Doch, gibt es. Auf Deutsch: "Mögliche Werte sind jeweils die Namen der Orte zu denen eine Straße führt und welche explizit ausgewiesen sind." (Hervorhebung nicht von mir)

Auf der zweiten Bildschirmseite gibt es dann tatsächlich diesen Hinweis, aber die einleitende Beschreibung der Seite als auch der Kasten oben rechts führen eher zu einer anderen Interpretation.

SunCobalt wrote:

slhh wrote:

Daher schlage ich vor, ausgeschilderte und nicht ausgeschilderte Ziele dadurch zu unterscheiden, dass man die Einen davon z.B. in eckige Klammern setzt. Einen Konflikt mit der Verwendung eckiger Klammern innerhalb eines Zieles gibt es dabei übrigens nicht, solange nicht das ganze Ziel in eckigen Klammern steht.

Blöde Frage.....wirklich ernst gemeint. Welche Anwendung stellst Du Dir vor, die nicht ausgeschilderte Ziele nutzt?

Ob es eine sinnvolle Anwendung für die nicht ausgeschilderten Ziele gibt, habe ich auch Zweifel. Entscheidend ist jedoch, ob andere Mapper der Meinung sind, dass deren Erfassung sinnvoll ist, oder diese einfach ohne Nachgedanken erfassen.

Klar ist jedoch, dass es eine sinnvolle Verwendung für ausschließlich ausgeschilderte Ziele gibt. Wenn auch andere Ziele erfasst werden, sollte man eine Unterscheidungsmöglichkeit haben.
Wenn es einen Konsens für eine eindeutige Beschränkung auf ausgeschilderte Ziele gibt, ist mir das natürlich auch recht.

Hallo,

mit dem Thema hab ich mich noch nie richtig beschäftigt, aber ich habe den Thread durchgelesen.

Wie macht ihr das eigentlich, wenn auf den Schildern Piktogramme, wie z.B. Flughafen oder Stadion, abgebildet sind? Übersetzt ihr die ins Deutsche?
Man könnte das ja in maschinenlesbarer Form aufnehmen, dann bräuchte man aber wohl noch ein Trennzeichen, wie <airport> oder icon:airport.
Gibt es so etwas schon? Das wäre für die Darstellung, aber vor allem für Ansagen in verschiedenen Sprachen hilfreich.

Grüße
Daniel

Zumindest Flughafen geht ja: "✈" 😉
Das ist aber vermutlich nicht mit allen möglich (Stadion hab' ich schon nicht gefunden). Auch ist es etwas problematisch: Hier gibt es auf einem Wegweiser ein "Piktogramm" (deren Logo) für ein Schwimmbad, dass man nicht einfach so als "Schwimmbad" erkennt; Ein paar Orte weiter kommen auch Firmenlogos vor. Eine "übliche" Lösung dafür wäre darum sicherlich hilfreich, dürfte jedoch nicht so einfach sein.

In Dresden gibt es sogar eine Autobahnabfahrt Dresden-Flughafen. Auf den Schildern steht aber immer auf weißem Grund

✈ Dresden

Gruß Thomas

PS Danke für das Piktogramm 😉