Tag motorway_link name

Bzgl. des Taggings von Autobahnkreuzen/-dreiecken/-anschlussstellen und deren Rampen sieht es in der OSM wie folgt aus…

Für den Verzweigungsknoten:

highway=motorway_junction

motorway_junction name Bezeichnung des Knotenpunktes ohne AK/AD/AS (in den meisten Fällen identisch mit Bezeichnung auf Vorankündigungstafel)*
motorway_junction ref Nummer des Knotenpunktes

Für den Weg:

highway=motorway_link

motorway_link name streitig, darum geht es jetzt hier!
motorway_link ref streitig**
motorway_link destination Fahrziele laut (Vor-)Wegweiser
motorway_link destination:ref (neues Tag) ref der Zielstraße laut (Vor-)Wegweiser


User Dj_INVA fing kürzlich an, im Berliner Raum die Tags motorway_link name
mit mächtigem Durcheinander zu befüllen. Ich vermute stark, dass die Intention eine
gewünschte Sprachausgabe bzw. Anzeige in einem Navi war.
Ich hatte mal eine ähnliche Erfahrung, als ein User in das Name-Tag “Anschlusstelle XY”
ausgeschrieben hatte, damit es sein Navi hübsch vorliest :roll_eyes:

Hier eine beispielhafte Auswahl, welche die Heterogenität gut darstellt:

name=Ak Schönefelder Kreuz
name=Ad 9 Waltersdorfer
name=As 8 Flughafen Schönefeld
name=As 4 Zehlendorf
name=As Schönefeld
name=As 16Wexstraße
name=A 15 Detmolder Straße
name=As Mecklenburgische Straße

Zum Vergleich die korrekten bestehenden Tags von motorway_junction:

name=Schönefelder Kreuz
ref=10

name=Waltersdorfer Dreieck
ref=9

name=Flughafen Berlin Brandenburg
ref=8

name=Kreuz Zehlendorf
ref=4

name=Schönefeld-Süd
ref=7

name=Wexstraße
ref=16

name=Detmolder Straße
ref=15

Die ehemalige AS Mecklenburgische Straße gab es früher an der ehemaligen A 104.
Da diese nun aber selbst ein Ast der A 100 im Rahmen der AS Schmargendorf (ehemals Kreuz Wilmersdorf) ist,
gibt es keine ausgewiesene AS Mecklenburgische Straße mehr.

Bevor ich den User pers. anschreibe, möchte ich gern motorway_link:name hier diskutieren.


*) Die Ankündigungstafeln (bzw. auch manche Vorwegweiser) weisen nicht immer den korrekten Namen aus
(vergleichbar mit falschen Straßennamenschildern).
Vielfach wird aus Kostengründen eine Aktualisierung der Wegweiser nach “kleineren” Umbenennungen
hinausgezögert.
So gibt es bspw. an der AS Münster-Nord immer noch eine Vorankündigungstafel “Kreuz Münster-Nord”.
Ein weiteres Bsp. sind die Vorankündigungstafeln des Kreuz Rippachtal und der AS Halle.
In beiden Fällen ist das Kreuz-Symbol (zur Kennzeichnung von Knotenpunkten mit übergeordneten Straßen)
vorhanden… ok. Beim Kreuz Rippachtal fehlt aber auch die Bezeichnung “Kreuz”… solch ein Vorgehen
m.E. nicht RWBA-konform, wird vermutlich aber oft angewendet, um die Schildergröße zu minimieren.

**) In Deutschland gehören die Links als Äste mit zu den Autobahnen, daher könnte den ref-Wert der Autobahn eintragen.
Vielerorts stehen dort auch entsprechende Stationszeichen.
Für falsch halte ich das ref der Zielstraße dort einzutragen.

Also aus meiner Sicht gibt es hier nix zu besprechen, da gem. wiki der Name der Autobahn unter “name” geführt wird und nicht der Name der Ausfahrt - wie du richtig schreibst gehört der Name der Ausfahrt an “highway_junction”.

Das erinnert mich an diese Diskussion… Da hatte auch jemand den Ausfahrten seltsame Namen verpasst, damit sein Garmin sie schön vorliest. Generell würde ich name=* und ref=* genau so an motorway_junction setzen, wie du ja auch schon schreibst - da gehören die Daten hin.

Hier im autobahnlosen Estland kommt so ein Fehltagging praktischerweise nicht vor :smiley: Aber das erinnert mich daran, mir mal die “autobahnähnlich” ausgebauten Teilstrecken und ihre Ausfahrten anzuschauen…

Kennt jemand die neue Auswerte-Funktion in mkgmap?
Es gibt dort 2 neue Parameter, die für eine korrekte Anzeige der Ausfahrt im Garmin Plan sorgen sollen.

process-destination
process-exits

Wenn diese beiden Parameter falsch implementiert wurden,
dann sollte besser der mkgmap code korrigiert werden,
und nicht alle Ausfahrten entsprechend falsch getaggt.

Leider ist im Wiki nur unzureichend dokumentiert, welche Tags hier ausgewertet werden.
http://wiki.openstreetmap.org/wiki/Mkgmap/help/options

Walter

Was genau ist denn daran falsch bzw. woraus leitest du das ab? Dann könnte man besser eingrenzen, wo genau der Code korrigiert werden muss.

Es sollte wohl lauten: **Falls **diese Parameter falsch implementiert wurden.
Im Wiki steht es ja leider nicht genau genug erklärt.

Es kann genausogut sein, dass der Umtagger diese Parameter gar nicht verwendet,
und stattdessen mit seinen Workarounds korrekte Abbiegehinweise erhalten möchte.

**Falls **dem so ist, sollte man ihn auf die neuen mkgmap Parameter aufmerksam machen.

Walter

Ich finde die Erklärung im Wiki eigentlich ganz brauchbar und die neuen Parameter klingen so, wie sie im Wiki beschrieben sind, auch ganz sinnvoll. Aber das sagt natürlich nichts über den Code aus - da kann ja durchaus ein Fehler sein, der nicht im Wiki gelandet ist. Ich schau mal, ob / wann ich Zeit habe, die Parameter auszuprobieren - dann sieht man zumindest mal, was bei richtig / falsch getaggten Ausfahrten rauskommt (sofern das falsche Tagging dann noch da ist).

Ich entziehe der mgkmap-Expertenrunde ja ungerne die Diskussionsgrundlage, aber: Ebenso wie es sein kann, daß der (oben namentlich genannte) User versucht hat, bei mkgmap aroundzuworken, ist es auch möglich, daß er von mkgmap noch nie gehört hat und schlicht und einfach etwas falsch eingetragen hat. Möglicherweise hat er auch das Wiki falsch verstanden oder etwas richtig verstanden, was irgendwo im Wiki leider falsch steht. Angesichts der Tatsache, daß der User Anfänger ist [1], halte ich dies sogar für deutlich wahrscheinlicher als einen bewußten mkgmap-Würgaround.

Man könnte den User also einfach freundlich per Mail darauf aufmerksam machen, daß seine Änderungen an den Anschlußstellen gleich in mehrfacher Hinsicht (Tagging am falschen Objekt, ref und name vermischt, Präfixe, Abkürzungen, …) nicht den diesbezüglichen Konventionen entsprechen sowie per Objektlink das Vorhandensein korrekter Tags aufzeigen, nach seinen Motiven hinter diesen Änderungen befragen, ihn auf eine passende Wiki-Fundstelle (sowie ggf. auf die Potlatch 2-Anleitung, falls seine Änderungen noch anderweitig zu beanstanden sind) leiten und ihn bei der Gelegenheit auch noch darauf hinweisen, daß er sich durch Verwendung aussagekräftiger Changeset-Kommentare manche Nachfrage ersparen würde.

[1] nicht aufs Anmeldedatum schauen, sondern auf die Anzahl der Änderungssätze bzw. hdyc: 128 seiner 136 Änderungssätze haben in den letzten zwei Wochen stattgefunden, alle mit Potlatch, hdyc zählt je ein paar hundert angefaßte Knoten und Wege (mit hohem Anteil bearbeiteter Wege, das mag an den motorway_link liegen).

Das bleibt sich natürlich unbenommen.

Die Frage nach mkgmap, den neuen Optionen und deren (in-)korrekter Funktion ist ja auch unabhängig vom konkreten Fall. Mich interessiert es eher deshalb, weil im oben von mir verlinkten Thread genau die Problematik mit der Sprachansage von Autobahnausfahrten auf Garmin-Geräten im gleichen Zusammenhang aufgetaucht ist. Von daher wäre es natürlich schon wichtig zu wissen, ob das nun korrekt funktioniert oder nicht.

Vielen Dank für dein “Experten-Feedback” :slight_smile:
Die in Relation zum Anmeldedatum recht niedrige Anzahl an Änderungssätzen war mir auch aufgefallen, aber ich wollte nicht gleich drauf los reverten
und hier diesen Thread gestartet…

User angeschrieben und eine ganze Menge reverted. Sinnvolle Änderungen (da mal ein maxspeed, dort mal ein name für secondary) habe ich erhalten.

PS: Wall·E war in dir zu gierig :wink: Es heißt in diesem Kontext “Anschlussstelle” anstatt “Anschlußstelle”.

process-exits: Die Ansage bei Autobahn- und Trunk-Abfahrten funktioniert hervorragend. Voraussetzung ist, dass der node “motorway-junction” existiert. Da werden Ref und Name schon im Voraus angesagt und angezeigt, so wie sie dann auf dem Abfahrtsschild zu sehen sind. Sehr hilfreich beim Einleiten des Abfahr-Vorgangs.

process-destination: Da bin ich mir noch nicht sicher. Nach Auffahrten jedenfalls wird in Klammer die Richtung angezeigt, also z.B. “A4 (Dresden)”. Das ist eher eine Überprüfung. Bei Abfahrten funktioniert das offenbar nicht, aber ich möchte sowieso nicht die Liste aller am Link eingetragenen Ziele (bis zu 3?, wovon 2 dann nicht zutreffen) vorgelesen bekommen oder selbst ablesen.

Ich jedenfalls bin mit den beiden Optionen sehr zufrieden.

Grüße
Mario

Ich habe mal Berlin von der Geofabrik runtergeladen und mkgmap mit dem AIO-Style (im wesentlichen) sowie den neuen Optionen drüberlaufen lassen. Meine Feststellung:

  • Zunächst einmal kommt es stark darauf an, die Typen 0x08 bzw. 0x09 für Ausfahrten zu benutzen, sonst bringen besagte Optionen gar nichts. Außerdem muss man im Style beachten, mkgmap:display_name richtig zu setzen.

  • Bei den Ausfahrten, die der Kollege so merkwürdig getaggt hat, kommt tatsächlich nur Murks raus.

Also ist es 1. nicht ganz trivial, diese Optionen richtig zu benutzen und 2. keine sinnvolle Motivation für so ein Tagging. Im Gegenteil: Eher wenn man *ohne* diese Optionen eine schöne Sprachausgabe erzwingen will, könnte man auf die Idee kommen, so zu taggen.

EDIT: Da haben sich unsere Posts überschnitten :wink: Ja, zufrieden bin ich (als fortgeschrittener mkgmap-Nutzer) auch mit den neuen Optionen. Man muss nur wissen, was man tut :wink:

Wie müssen die Typen 0x08 und 0x09 denn verwendet werden, damit die Option funktioniert?
Die Erklärung im Wiki: “When using the Garmin Types 0x08 and 0x09 (Ramp)”
sagt ja nur, dass sie verwendet werden müssen, aber nicht wie.

Walter

Man muss 0x08 oder 0x09 für highway=motorway_link verwenden, d.h. den Style so anpassen, dass highway=motorway_link auf diese Linientypen abgebildet wird. Das war mir als Problem bei der AIO aufgefallen - die nutzt 0x08 für highway=construction, 0x09 für highway=road (glaube ich, bin grad nicht sicher) und stattdessen 0x01 (Autobahn) für highway=motorway_link.

Einfach den default style als Vorlage nehmen, da ist es richtig drin.

Die beiden Optionen process-exits und process-destination sollen es ermöglichen, mit dem in OSM üblichen Tagging eine vernünftige Sprachausgabe auf dem Navi zu ermöglichen. Wenn das nicht klappt, sollte auf keinen Fall das Tagging umgestellt werden (aber das ist wohl allen hier klar :wink: )

Die Optionen sind leider notwendig, da das Garminformat entweder keine vernünftigen Ansagen unterstützt oder der entsprechende Teil des Formats nicht entschlüsselt ist. Daher benötigt man diese beiden Workarounds, um die vorhandenen Informationen über Abfahrten und Destinations so aufzubereiten, dass das Garmin einem mehr als “Left on RAMP” sagt.

Die Optionen sind nicht etwas tricky zu verwenden. Sie sind halt ein Workaround. Falls es Fragen dazu gibt, bitte einfach hier oder auf der mkgmap developers list posten.

Ich plane die process-destination option testhalber mal entsprechend der process-exits Option umzubauen, da viele der Destinations in etwas komplexeren Autobahnkreuzen, also gerade da, wo die Ansagen notwendig wären, verloren gehen. Falls Ihr Ideen dazu habt, wie man das Ganze einfacher gestalten kann, lasst es mich wissen.

WanMil

Hallo WanMil

Erst einmal müssten wir wissen, welches Tagging wo gebraucht wird. Ist das irgendwo dokumentiert? Als Beispiel kannst du das Autobahnkreuz Bonn-Nord verwenden. Das dürfte komplett mit destination-Taggs versehen sein.

Wird “destination:lanes=A-Stadt|A-Stadt;B-Stadt|B-Stadt” ausgewertet?

Edbert (EvanE)

Der Garmin Navi macht eine “Late Evaluation”, es zählt das erste “normale” Straßenstück hinter
einer Folge von motorway_link / trunk_link für die Generierung der Ansage.

Im Wiki wird gesagt, man soll die _link Stücke mit destination=xyz versehen. Damit Garmin
dies auswerten kann sorgt “process_destination” dafür, dass die destination-Information
an das erste “normale” Straßenstück hinter den _links übertragen wird.

destination:lanes hingegen wird ja vorwiegend vor einer Verzweigung gesetzt,
ist also für Garmin nicht so relevant.

Chris

destination:lanes ist eine spurspezifische Information. Dies kann von mkgmap nicht verwertet werden, da das Format für spurbasierte Informationen nicht entschlüsselt ist.
Man könnte dies natürlich auch komplett textuell anzeigen, aber da ist der Test in aller Regel so lang, dass er gar nicht mehr vollständig anzeigt wird. Und das hilft dann auch nicht wirklich weiter…

Wie Chris beschrieben hat, sucht mkgmap alle _link ways (motorway_link und trunk_link) mit einem destination tag. Dann wird das destination tag auf den nachfolgenden Weg weiterkopiert, bis der Hauptweg (motorway oder trunk) erreicht wurde. Dies passiert allerdings nur, wenn der nachfolgende Weg nicht wieder Abzweigungen enthält, da man dann davon ausgehen kann, dass das destination Tag nicht wirklich eindeutig weiterkopierbar ist. Dies ist gerade bei Autobahnkreuzen häufig ein Problem.

Das Garmin zeigt einem als Richtungsempfehlung den Namen des ersten Straßenstücks an (das erste != 0x08 oder 0x09 so weit ich das im Kopf habe). Von daher ist es notwendig das destination tag soweit zu forwarden, dass man den Namen dieses Straßenstücks über das Stylefile anhand des destination tags bilden kann. Dies wird im Defaultstyle direkt als erstes im lines File erledigt:

Set the routing direction

(highway=motorway|highway=trunk ) & ref=* & destination=* { add mkgmap:display_name =
‘${ref|subst: =>}(${destination|subst:;=> |subst:/=> })’ }

Dies hat zur Folge, dass z.B. die A2 dann nicht mehr den Namen A2 sondern A2 (Berlin) bekommt.

WanMil

Hallo WanMil

Dir und Chris Dank für die Erläuterung der Einzelheiten.

Ich fasse das mal für mich zusammen:

  • destination:lanes wird bei mkgmap nicht ausgewertet, da die Entwickler noch nicht wissen, wie das bei Garmin umgesetzt wird.
  • Ein destination-Tagg wird bei mkgmap bis zur ersten nicht Auf-/Abfahrt weitergereicht, da Garmin das so braucht. Das geht natürlich nur soweit, wie das weiterreichen eindeutig zugeordnet werden kann.

Andere Programme mit Routing können andere Vorgaben haben resp. andere Verhalten zeigen.

Meine Schlußfolgerung daraus:

  • An jeden Abschnitt einer Auf-/Abfahrt die jeweils zutreffende Destination taggen.
  • Nach einer Verzweigung die destination-Taggs neu setzen.
    So kann immer sauber weitergreicht werden, auch wenn Verzweigungen innerhalb der Strecke auftreten.

Edbert (EvanE)