Tag motorway_link name

SennaHB · 2013-03-17 11:54:09

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

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.

Last edited by SennaHB (2013-03-18 11:49:12)

tunnelbauer · 2013-03-17 12:32:44

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

MHohmann · 2013-03-17 14:04:41

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 Aber das erinnert mich daran, mir mal die "autobahnähnlich" ausgebauten Teilstrecken und ihre Ausfahrten anzuschauen...

Walter Schlögl · 2013-03-17 14:36:54

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

MHohmann · 2013-03-17 15:30:44

Walter Schlögl wrote:

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

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.

Walter Schlögl · 2013-03-17 17:40:52

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

MHohmann · 2013-03-17 19:42:44

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

Oli-Wan · 2013-03-17 23:13:42

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

MHohmann · 2013-03-18 08:20:06

Oli-Wan wrote:

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.

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.

SennaHB · 2013-03-18 08:54:48

Oli-Wan wrote:

Angesichts der Tatsache, daß der User Anfänger ist [1], [...]
[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).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 [...]

Vielen Dank für dein "Experten-Feedback"
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...

Oli-Wan wrote:

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 [...]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 [...]

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 Es heißt in diesem Kontext "Anschlussstelle" anstatt "Anschlußstelle".

Last edited by SennaHB (2013-03-18 08:57:38)

Garmin-User · 2013-03-18 13:13:26

MHohmann wrote:

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.

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

MHohmann · 2013-03-18 13:23:17

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 Ja, zufrieden bin ich (als fortgeschrittener mkgmap-Nutzer) auch mit den neuen Optionen. Man muss nur wissen, was man tut

Last edited by MHohmann (2013-03-18 13:25:31)

Walter Schlögl · 2013-03-18 19:41:33

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

MHohmann · 2013-03-18 20:21:45

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.

chris66 · 2013-03-18 20:50:52

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

WanMil · 2013-03-26 16:42:44

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 )

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

EvanE · 2013-03-27 03:53:57

WanMil wrote:

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

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)

chris66 · 2013-03-27 10:35:37

EvanE wrote:

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

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

WanMil · 2013-03-27 12:37:51

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

EvanE · 2013-03-28 01:54:43

WanMil wrote:

destination:lanes ist eine spurspezifische Information. Dies kann von mkgmap nicht verwertet werden, da das Format für spurbasierte Informationen nicht entschlüsselt ist. ...
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: ...
Dies hat zur Folge, dass z.B. die A2 dann nicht mehr den Namen A2 sondern A2 (Berlin) bekommt.

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)

WanMil · 2013-03-28 14:06:21

Hallo Edbert,

gut zusammengefasst!
Grundsätzlich gilt natürlich vor allem: Taggen wie im OSM Wiki beschrieben bzw. von der Community beschlossen. Wenn mkgmap das nicht richtig umsetzt, bitte melden :-)

Have fun!
WanMil

Walter Schlögl · 2013-03-28 16:41:48

Ich bin noch nicht restlos überzeugt, dass ich es komplett verstanden habe, daher versuche ich auch einmal, einen Teil zusammenzufassen.

Ausfahrten werden laut Wiki mit folgenden Tags erfasst:

highway=motorway_junction
+ name
+ ref
+ exit_to (in USA)

mkgmap kann mit dem Schalter --process-exits diese 3 Tags auswerten, indem der folgende _link way gesplittet wird, und die Tags übertragen werden.
Leider wird bei den mkgmap help options von einem motorway exit gesprochen, statt der korrekten Bezeichnung: motorway_junction

Die Abfahrt selbst wird laut Wiki mit folgenden Tags erfasst:

highway=motorway_link
+ destination
+ destination:ref

mkgmap kann mit dem Schalter --process-destination das destination Tag auswerten, indem der Wert auf das nächste Straßenstück übertragen wird.

Meine Fragen dazu:
Warum wird bei process-destination nicht der gleiche Trick mit dem Splitten der Abfahrt angewendet?
Stimmt es, dass laut Style File destination:ref nicht ausgewertet wird, dafür aber destination_ref das im Wiki gar nicht beschrieben ist?

Der Highway selbst wird laut Wiki mit folgenden (mkgmap relevanten) Tags erfasst:

highway=motorway
+ name
+ ref
+ destination

Laut mkgmap Style File wird entweder name+ref oder ref+destination angezeigt. Die ref Angabe darf daher nicht fehlen.

Ich muss zugeben, dass ich weder die korrekte Erfassung in OSM noch die Auswertung in mkgmap vollständig durchblicke.
Ev. wäre es ganz hilfreich, den Help Text im mkgmap Wiki etwas ausführlicher zu verfassen, da man derzeit bei einigen Angaben nur raten kann, wie es gemeint ist.

http://wiki.openstreetmap.org/wiki/Mkgmap/help/options

Walter

WanMil · 2013-03-28 17:24:08

Walter Schlögl wrote:

Meine Fragen dazu:
Warum wird bei process-destination nicht der gleiche Trick mit dem Splitten der Abfahrt angewendet?

Historisch bedingt. Zuerst kam die Idee, die destination Tags zu forwarden.
Als zweites kam dann die Idee, die Ausfahrten über ein Splitten der Ausfahrt ankündbar zu machen. Wie ich in einem vorherigen Post in diesem Thread geschrieben habe, plane ich das Splitten auch mal für destination Tags auszuprobieren.

Walter Schlögl wrote:

Stimmt es, dass laut Style File destination:ref nicht ausgewertet wird, dafür aber destination_ref das im Wiki gar nicht beschrieben ist?

Wie kommst Du denn darauf? Ich habe weder destination_ref noch destination:ref in den mkgmap Style Files gefunden.

Walter Schlögl wrote:

Der Highway selbst wird laut Wiki mit folgenden (mkgmap relevanten) Tags erfasst:
highway=motorway
+ name
+ ref
+ destination

Wenn Du auf dem highway destination erfasst, kannst du Dir process-destination sparen, denn dann existiert ja bereits das destination Tag auf dem Highway. Es kann (sollte) also nicht mehr vom motorway_link weiterkopiert werden.

Walter Schlögl wrote:

Ich muss zugeben, dass ich weder die korrekte Erfassung in OSM noch die Auswertung in mkgmap vollständig durchblicke.
Ev. wäre es ganz hilfreich, den Help Text im mkgmap Wiki etwas ausführlicher zu verfassen, da man derzeit bei einigen Angaben nur raten kann, wie es gemeint ist.
http://wiki.openstreetmap.org/wiki/Mkgmap/help/options

Ich denke, Du hast es ziemlich gut verstanden. Falls Du konkrete Verbesserungen für den Hilfetext hast, poste dies bitte auf dem mkgmap Developers Liste oder stells ins Wiki.

WanMil

Walter Schlögl · 2013-03-29 00:30:52

Hallo WanMil,

anhand deiner Erklärungen verstehe ich es immer besser, daher auch vielen Dank dafür.
destination_ref hatte ich von einem anderen Style File, nicht vom default. War wohl dort ein Fehler.

Ich habe auf mehreren highways bereits das destination tag gesehen, dürfte also recht üblich sein, das Ziel nicht nur am Link zu erfassen.
Den Wiki Text von --process-destination habe ich ergänzt um: "If the first non link way is not unique, the tags are not copied."

Walter

chris66 · 2013-03-29 10:05:57

Das "destination" Tag findet man übrigens auch oft bei Umleitungs-Relationen ("U8 Richtung Köln").
Ich nehme aber an, dass das mkgmap-processing davon nicht gestört wird, da nur ways ausgewertet werden...

Chris

Announcement

#1 2013-03-17 11:54:09

Tag motorway_link name

#2 2013-03-17 12:32:44

Re: Tag motorway_link name

#3 2013-03-17 14:04:41

Re: Tag motorway_link name

#4 2013-03-17 14:36:54

Re: Tag motorway_link name

#5 2013-03-17 15:30:44

Re: Tag motorway_link name

#6 2013-03-17 17:40:52

Re: Tag motorway_link name

#7 2013-03-17 19:42:44

Re: Tag motorway_link name

#8 2013-03-17 23:13:42

Re: Tag motorway_link name

#9 2013-03-18 08:20:06

Re: Tag motorway_link name

#10 2013-03-18 08:54:48

Re: Tag motorway_link name

#11 2013-03-18 13:13:26

Re: Tag motorway_link name

#12 2013-03-18 13:23:17

Re: Tag motorway_link name

#13 2013-03-18 19:41:33

Re: Tag motorway_link name

#14 2013-03-18 20:21:45

Re: Tag motorway_link name

#15 2013-03-18 20:50:52

Re: Tag motorway_link name

#16 2013-03-26 16:42:44

Re: Tag motorway_link name

#17 2013-03-27 03:53:57

Re: Tag motorway_link name

#18 2013-03-27 10:35:37

Re: Tag motorway_link name

#19 2013-03-27 12:37:51

Re: Tag motorway_link name

#20 2013-03-28 01:54:43

Re: Tag motorway_link name

#21 2013-03-28 14:06:21

Re: Tag motorway_link name

#22 2013-03-28 16:41:48

Re: Tag motorway_link name

#23 2013-03-28 17:24:08

Re: Tag motorway_link name

#24 2013-03-29 00:30:52

Re: Tag motorway_link name

#25 2013-03-29 10:05:57

Re: Tag motorway_link name

Board footer