Für Routing optimieren?

MasiMaster · 2012-10-20T11:56:19.000Z

imagic:

MasiMaster:

destination:lanes=|A:A||B:B|

Die Idee mit den unterschiedlichen Zeichen kam schon mehrmals auf, hat nur zwei Nachteile:

Kaum intuitiv, vor allem wenn dann noch so Zeichen wie # dazu kommen. (Kann mich nicht mehr erinnern wofür das gedacht war).

Bei welchen :lanes-Schlüssel sollen sie verwendet werden? Es können beliebige viele sein.

Ok, war von mir nicht bis zu Ende gedacht… Das Schema passt wohl besser zu divider:lanes oder so. (Bin in dem lanes:* Schema nicht richtig drin. Der Beitrag sollte nur eine eingeworfene Idee sein.)
Da “|” der Trenner für die lanes ist, kann er nicht gleichzeitig als Symbol für die Linienart verwendet werden. Außer nimmt für divider:lanes einen anderen Trenner. zB: |4:3|:2|1| oder |x:x|:x|x| oder “L” für lane |L:L|:L|L|

Steht wohl für eine schraffierte Fläche.

Tordanik · 2012-10-20T12:32:00.000Z

aighes:

Ich würde mal davon ausgehen, dass wenn es Anwendungen gibt, die sich um die Darstellung der Straßenlinien geht, diese nicht aus den Ways holen wollen, sondern die exakte Geometrie der Straße aus einer Straßenfläche holen wollen

Da muss man aber auch bedenken, wie realistisch dieses Szenario ist. Wenn ich die Wahl habe zwischen Tags an Ways, die flächendeckend eine korrekte Darstellung der Straßenlinien erlauben, und den hochgenauen Experimenten mit Flächen für einzelne Spuren in der Nachbarschaft einiger weniger Powermapper, dann fällt meine Wahl aus praktischen Gründen auf die Way-Tags.

Davon abgesehen ist es nicht so, dass die Darstellung als Way fürs Rendering ausschließlich Nachteile gegenüber Flächen hätte - z.B. hat man an Ways unter Umständen leichteren Zugang zu gerichteter Information wie der Steigung oder es lassen sich Annahmen zur Krümmung der Straßenoberfläche quer zur Wegrichtung treffen. Und natürlich die leichtere Verknüpfbarkeit mit Routing-Resultaten, die daraus resultieren dürfte, dass beide denselben Datensatz nutzen. Man will ja Rendering und Routing idealerweise nicht als zwei komplett getrennte Welten haben, sondern auch seine spurgenaue Route in ein entsprechendes Rendering einzeichnen können.

Hast du denn ein konkretes Beispiel für die fehlende Möglichkeit einer Übersetzung Aussehen → Funktion? #45 geht da auch nicht so weit ins Detail, dass ich verstehe, an welche Situationen du denkst.

errt:

Tordanik:

Daher halte ich das Eintragen der Art (Aussehen) der Markierung für den einzig gangbaren Weg. Das erspart dem Mapper übrigens auch, alle Details der Bedeutung einer Spurmarkierung zu kennen.

Entspricht aber eigentlich nicht dem, was wir hier sonst so machen.

Das hat aber auch entsprechende Konsequenzen: Es ist unmöglich, auf Grundlage von OSM-Daten Verkehrszeichen zu rendern. Auf das Rendern von Spurtrennern möchte ich für meinen Teil nicht verzichten.

Außerdem sind länderspezifische Sonderregeln, was das Aussehen angeht weniger problematisch, also solche, die die Funktion betreffen, denn da kann eine falsche Interpretation schnell zu groben Fehlern führen, vor allem, wenn der Fahrer (z.B. im Ausland) selbst nicht hundertprozentig die Bedeutung der Linientypen kennt und dann dem Navi vertraut.

Bevor wir hier darüber streiten, welche Anwendung “wichtiger” ist, sollten erst mal alle Anwendungen überhaupt möglich sein

Ich halte das Taggen der Funktion übrigens nicht unbedingt für weniger fehleranfällig, die Fehler sind nur andere: Wenn die Regeln eines Routers für ein ganzes Land fehlerhaft sind, ist das natürlich ein Problem. Es fällt aber auch viel eher auf, als wenn ein einzelner Mapper aufgrund eines Missverständnisses des örtlichen StVO-Äquivalents manche Straßen falsch taggt.

aighes · 2012-10-20T14:27:21.000Z

Spontan fallen mir Busspuren ein. Die sind bei uns meist mit einer dicken durchgezogenen Linie abgegrenzt. Busse dürfen die Linie dennoch überfahren. Oder die Radwegbegrenzung auf der Straße. Wenn ich links abbiegen möchte, darf ich die als Radfahrer überfahren. Die durchgezogene Linie in der Mitte aber nicht.

Sprich durchgezogene Linie heißt nicht immer, dass man diese nicht überfahren darf. Ebenso kann man nicht davon ausgehen, dass wenn man eine Linie überfahren darf, dass diese gestrichelt ist. Wenn man jetzt mal von hiesigen Linienarten aus geht. Evtl. gibt es auch Länder, wo die Linien andere Bedeutungen haben.

Auf manchen Autobahnen gibt es auch Spursperrungen für LKWs. Die Linien sind gestrichelt, dennoch dürfen nicht alle diese Linie überfahren.

Sprich fürs Routing braucht man crossig:=, wobei der komische String aussagen muss, wie man wechseln darf. Für das Rendering möchte ich nur wissen, ob da jetzt eine dicke, durchgezogene Linie ist oder eine dünne, gestrichelte.

marek_kleciak · 2012-10-20T17:39:24.000Z

aighes:

Sprich fürs Routing braucht man crossing:=, wobei der komische String aussagen muss, wie man wechseln darf. Für das Rendering möchte ich nur wissen, ob da jetzt eine dicke, durchgezogene Linie ist oder eine dünne, gestrichelte.

Absolut richtig. Kann jemand daraus einen Taggingvorschlag machen? Ich gebe zu, es ist nicht meine Stärke, viele von Euch machen es deutlich besser als ich.

errt · 2012-10-20T19:03:50.000Z

Tordanik:

errt:

Tordanik:

Daher halte ich das Eintragen der Art (Aussehen) der Markierung für den einzig gangbaren Weg. Das erspart dem Mapper übrigens auch, alle Details der Bedeutung einer Spurmarkierung zu kennen.

Entspricht aber eigentlich nicht dem, was wir hier sonst so machen.

Das hat aber auch entsprechende Konsequenzen: Es ist unmöglich, auf Grundlage von OSM-Daten Verkehrszeichen zu rendern. Auf das Rendern von Spurtrennern möchte ich für meinen Teil nicht verzichten.

Naja, aus den Daten, die wir an die Wege kleben zumindest nicht besonders gut, aber es gibt ja durchaus schon Möglichkeiten, um auch Schilder einzutragen. Ohne die allgemeine Auswertung von Einschränkungen zu stören. Und ansonsten stimme ich dir zu, Spurtrenner gehören gerendert. Wenn die allerdings mal nicht hundertprozentig mit der Realität übereinstimmen, ist das aber auch kein Beinbruch.

Tordanik:

Ich halte das Taggen der Funktion übrigens nicht unbedingt für weniger fehleranfällig, die Fehler sind nur andere: Wenn die Regeln eines Routers für ein ganzes Land fehlerhaft sind, ist das natürlich ein Problem. Es fällt aber auch viel eher auf, als wenn ein einzelner Mapper aufgrund eines Missverständnisses des örtlichen StVO-Äquivalents manche Straßen falsch taggt.

Wenn die Regeln für ein ganzes Land fehlerhaft sind, dann ja. Aber Grenzbereiche, die schlecht ausgeschnitten sind oder Mapper die finden, eine andere Tagkombination entspricht dem Aussehen nach eher dem Zustand auf der Straße (als etwas übertriebenes Beispiel könnte sein, dass jemand durchgehende Linien als unterbrochen taggt, weil sie stellenweise verblasst oder vedreckt sind), sind keine systematischen Fehler.

Tordanik · 2012-10-24T23:51:56.000Z

aighes:

Spontan fallen mir Busspuren ein. […] Oder die Radwegbegrenzung auf der Straße. […]

Sprich durchgezogene Linie heißt nicht immer, dass man diese nicht überfahren darf. Ebenso kann man nicht davon ausgehen, dass wenn man eine Linie überfahren darf, dass diese gestrichelt ist. Wenn man jetzt mal von hiesigen Linienarten aus geht. Evtl. gibt es auch Länder, wo die Linien andere Bedeutungen haben.

Auf manchen Autobahnen gibt es auch Spursperrungen für LKWs. Die Linien sind gestrichelt, dennoch dürfen nicht alle diese Linie überfahren.

Sprich fürs Routing braucht man crossig:=, wobei der komische String aussagen muss, wie man wechseln darf. Für das Rendering möchte ich nur wissen, ob da jetzt eine dicke, durchgezogene Linie ist oder eine dünne, gestrichelte.

Interessante Sammlung! Du hast Recht mit deiner Argumentation: Es reicht oft nicht, nur das Aussehen zu taggen.

Ich habe daher noch mal etwas über das Thema nachgedacht und denke, dass man nichtsdestotrotz mit Default-Werten arbeiten könnte - so ähnlich, wie wir es ja bei highway-Werten tun. Beispielsweise wäre eine gestrichelte Linie standardmäßig für alle Fahrzeuge von beiden Seiten überquerbar. Eine gestrichelte+durchgezogene Trennung nur von links. Und so weiter.

Es sollte also definitiv Tags für “crossable”, “crossable:hgv” und so weiter geben. Allerdings hätte jedes Linienmuster landesabhängige Vorgabewerte, die im “Normalfall” unverändert belassen werden können (aber nicht müssen).

hurdygurdyman · 2012-10-25T03:32:53.000Z

Tordanik:

…
Ich habe daher noch mal etwas über das Thema nachgedacht und denke, dass man nichtsdestotrotz mit Default-Werten arbeiten könnte - so ähnlich, wie wir es ja bei highway-Werten tun. Beispielsweise wäre eine gestrichelte Linie standardmäßig für alle Fahrzeuge von beiden Seiten überquerbar. Eine gestrichelte+durchgezogene Trennung nur von links. Und so weiter.

Es sollte also definitiv Tags für “crossable”, “crossable:hgv” und so weiter geben. Allerdings hätte jedes Linienmuster landesabhängige Vorgabewerte, die im “Normalfall” unverändert belassen werden können (aber nicht müssen).

Siehe auch:
http://forum.openstreetmap.org/viewtopic.php?pid=284554#p284554
Edit Zitat:

imagic:

Zusammen mit einem Kollegen (“It’s so funny” ; Johan) aus den Niederlanden habe ich mal zu Versuchszwecken begonnen einige Stellen mit change:lanes zu taggen. Von den ursprünglichen Werten left, right, … sind wir eher wieder abgekommen. Johan hat richtigerweise bemerkt, dass wir ja nur dann taggen, wenn ein Wechsel nicht erlaubt ist. Daher probieren wir es jetzt einmal mit folgenden Werten:

yes (Wechsel erlaubt; äquivalent zu both)

not_right (nicht nach rechts; äquivalent zu left)

not_left (nicht nach links; äquivalent zu right)

no (kein Wechsel erlaubt; äquivalent zu none)

Wenn wir ein paar Erfahrungswerte haben, melde ich mich wieder.

Ob das jetzt “crossable” oder “change:lanes” heißt… Ich denke, “change:lanes” ist selbsterklärender.

errt · 2012-10-25T07:44:42.000Z

@Tordanik: Und dann taggen wir, die Linie sei durchgezogen (weil die Allgemeinheit sie nicht überqueren darf) und für Busse gestrichelt (weil es eben eine Busspur ist)? Das gibt doch auch nicht das Aussehen wieder, sondern die Funktion, dann könnten wir auch gleich bei der Funktion bleiben. Die braucht auch wenigstens keine landesspezifischen Defaults.

hurdygurdyman · 2012-10-25T07:45:51.000Z

imagic:

hurdygurdyman:

Es wäre dabei zu prüfen, ob die Informationen aus turn:lanes=left|through|right usw. als Alternative oder anstelle von relation=restriction verwertbar sind

Nope - keine gute Idee! Der Schlüssel turn ist wirklich nur dazu gedacht anzuzeigen, was man auf der Straße oder auf einem Schild sieht. Das hat nicht zwangsweise etwas damit zu tun, was man dann machen darf/muß.
…

Ich habe mal in der StVO für Deutschland ( http://www.verkehrsportal.de/stvo/stvo_41.php in verbindung mit http://www.verkehrsportal.de/stvo/anlage_2.php ) und Österreich ( http://www.jusline.at/9_Verhalten_bei_Bodenmarkierungen_StVO.html ) nachgelesen. Fahrbahnmarkierungen wie Richtungspfeile, Haltelinien u.a. sind somit Gebote oder Verbote, die sich auf die Straße, die Fahrbahn oder die Spur beziehen und durchaus entsprechenden verkehrsschildern gleichzusetzen. Also ist das entsprechend dargestellte Gebot oder verbot eine Eigenschaft der Spur für unseren Fall hier. Genauso wie es z.B. bei maxspeed=* auch gehandhabt wird, kann ein entsprechender tag wie turn:lanes=left|through|right die relation=restriction ersetzen oder als Alternative verwendbar sein. Das entsprechende turn:lanes=left|through|right würde sich dann auf den in Fahrtrichtung nächsten gemeinsamen Knoten mit einem anderen highway=* beziehen.

chris66 · 2012-10-25T08:02:39.000Z

slhh:

Die Werte können dem Key turn=* prinzipiell entsprechen, wobei jedem Wert einem Winkel entpricht. Der Router hat dann denjenigen weiterführenden Way zu verwenden, dessen Winkel am besten dazu passt. Diese Vorgehensweise halte ich für deutlich selektiver als jedem Wert einen vordefinierten Winkelbereich zuzuweisen.
Für wenige sehr komplizierte Fälle kann man auch zulassen, bei turn:physical direkt einen Winkel in Grad anzugeben.

Diese Heuristik ist ja der große Nachteil dieser relationslosen Lanes-Lösung. Bei der Relation ist explizit angegeben für
welchen Ziel-Way sie gilt, bei turn:lanes muss der Router den passenden Way anhand der Geometrie bestimmen, was
fehleranfällig ist. Aber erstmal abwarten, vielleicht ist es doch ganz brauchbar.

hurdygurdyman · 2012-10-25T09:05:58.000Z

chris66:

Diese Heuristik ist ja der große Nachteil dieser relationslosen Lanes-Lösung. Bei der Relation ist explizit angegeben für
welchen Ziel-Way sie gilt, bei turn:lanes muss der Router den passenden Way anhand der Geometrie bestimmen, was
fehleranfällig ist. Aber erstmal abwarten, vielleicht ist es doch ganz brauchbar.

Ich denke dass bei Kreuzungen oder Einmündungen mit bis zu vier sich treffenden ways das Problem nicht auftritt und somit die Masse der Fälle problemlos sein dürfte.
Sternkreuzungen ab fünf Straßen werden schwierig, wenn dort kein Kreisverkehr ist. Hat jemand einen solchen Fall mit hochauflösenden Hintergrundbildern für einen Test?

viw · 2012-10-25T09:37:01.000Z

hurdygurdyman:

chris66:

Diese Heuristik ist ja der große Nachteil dieser relationslosen Lanes-Lösung. Bei der Relation ist explizit angegeben für
welchen Ziel-Way sie gilt, bei turn:lanes muss der Router den passenden Way anhand der Geometrie bestimmen, was
fehleranfällig ist. Aber erstmal abwarten, vielleicht ist es doch ganz brauchbar.

Ich denke dass bei Kreuzungen oder Einmündungen mit bis zu vier sich treffenden ways das Problem nicht auftritt und somit die Masse der Fälle problemlos sein dürfte.
Sternkreuzungen ab fünf Straßen werden schwierig, wenn dort kein Kreisverkehr ist. Hat jemand einen solchen Fall mit hochauflösenden Hintergrundbildern für einen Test?

Ich hoffe du irrst nicht. Aber schon der Unterschied bei dieser Kreuzung: http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.033169,13.774641&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20
Im vergleich zu http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.032084,13.777526&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20

Macht doch einige Unterschiede. Während bei der ersten Kreuzung vorgeschrieben ist von welchem Fahrstreifen auf welchen abgebogen werden muss (durchgezogenen Linie beim Abbiegen) ist bei der zweiten Kreuzung alles freigestellt. Ich kann frei wählen zwischen dem ersten oder zweiten Fahrstreifen.

Als Testgelände könnte ich dir vielleicht auch den Schillerplatz empfehlen. Aufgrund der Einbahnstraßen vereifacht sich zwar einiges, aber die nahgelegenen anderen Abzweigungen und insbesondere die Straßenbahnen könnten dich vor Herausforderungen stellen.
Natürlich auch noch mit Link: http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.052062,13.806892&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20

viw · 2012-10-25T10:20:13.000Z

Bitte bedenkt bei allen Konstrukten auch daran was passiert wenn jemand einfach eine Straße hinzufügt oder löscht ohne explizit Abbieger zu berücksichtigen. Da sind Relationen denke ich im Vorteil. Weil die gehen kaput und sind dann unbrauchbar. Eine generische Zuweisung zu Straße 1, 2 oder 3 kann zu falschen Ergebnissen führen.

errt · 2012-10-25T10:54:51.000Z

Hier wäre das Modell mit eigenen Wegen wohl am ehesten im Vorteil, denn die kann man kaum übersehen und wird sich dann wohl drum kümmern. Selbst wenn man das nicht tut, sollte zumindest das, was schon da ist, problemlos weiter funktionieren.

viw · 2012-10-25T11:20:25.000Z

errt:

Hier wäre das Modell mit eigenen Wegen wohl am ehesten im Vorteil, denn die kann man kaum übersehen und wird sich dann wohl drum kümmern. Selbst wenn man das nicht tut, sollte zumindest das, was schon da ist, problemlos weiter funktionieren.

Das Modell mit den eigenen Wegen sieht auf den ersten Blick sehr lukrativ aus. Das Problem ist nur wie macht man dem Router den möglichen Spurwechsel begreifbar? Wie verhält sich ein Router wenn man gerade losfährt? Es gibt ja keine Möglichkeit per GPS zu erkennen auf welcher Spur man sich gerade befindet?

hurdygurdyman · 2012-10-25T11:51:36.000Z

viw:

Ich hoffe du irrst nicht. Aber schon der Unterschied bei dieser Kreuzung: http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.033169,13.774641&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20
Im vergleich zu http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.032084,13.777526&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20

Macht doch einige Unterschiede. Während bei der ersten Kreuzung vorgeschrieben ist von welchem Fahrstreifen auf welchen abgebogen werden muss (durchgezogenen Linie beim Abbiegen) ist bei der zweiten Kreuzung alles freigestellt. Ich kann frei wählen zwischen dem ersten oder zweiten Fahrstreifen.

Als Testgelände könnte ich dir vielleicht auch den Schillerplatz empfehlen. Aufgrund der Einbahnstraßen vereifacht sich zwar einiges, aber die nahgelegenen anderen Abzweigungen und insbesondere die Straßenbahnen könnten dich vor Herausforderungen stellen.
Natürlich auch noch mit Link: http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.052062,13.806892&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20

Zu Fall 1:
Wenndie Karcherallee als way in OSM mit der Richtung nach oben angelegt ist, wäre ein Schlüsselpaar turn:lanes=|through|right_right_lane denkbar, um die linke Spur der Winterbergstraße auszuschließen.
Zu Fall 2:
Nichts besonderes.
Zum Schillerplatz:
Durch Schatten und abgenutzte Markierungen ist die Situation so schwer einschätzbar
Die Straßenbahn sind keine Herausforderung, da sie als separater way in geografisch korrekter Lage gemappt werden könnten. Es geht hier um routing für Straßenverkehrsteilnehmer und deren Verkehrsführung durch Verkehrszeichen oder Markierungen. In der Tolkewitzer Straße sehe ich eine Sperrfläche, weshalb hier die beiden gegenläufigen Fahrbahnen sowieso als separate ways anzulehgen wären.
http://www.openstreetmap.org/?lat=51.0519084334373&lon=13.8068452477455&zoom=18

Tordanik · 2012-10-25T15:05:34.000Z

errt:

@Tordanik: Und dann taggen wir, die Linie sei durchgezogen (weil die Allgemeinheit sie nicht überqueren darf) und für Busse gestrichelt (weil es eben eine Busspur ist)? Das gibt doch auch nicht das Aussehen wieder, sondern die Funktion, dann könnten wir auch gleich bei der Funktion bleiben. Die braucht auch wenigstens keine landesspezifischen Defaults.

Ich verstehe deinen Einwand nicht.

Wenn die Linie dort durchgezogen ist, taggen wir sie als durchgezogene Linie. Damit ist das Aussehen definiert. Außerdem wird erstmal für alle Verkehrsmittel angenommen, dass sie nicht überfahrbar ist.

Da nun Busse doch drüberfahren dürfen, tragen wir diese Ausnahme zusätzlich explizit ein als “überfahrbar”:bus = yes

errt · 2012-10-25T18:48:26.000Z

Dann haben aber crossable und crossable:* völlig unterschiedliche Semantik und auch Syntax, nämlich ersteres Linienarten und letztere Zulässigkeit des Spurwechsels. Scheint mir wirklich keine gute Idee zu sein. Dann doch lieber bei beiden die Funktion getaggt. Oder, wie wäre es denn hiermit: Ein Tag für’s Aussehen und eines (+ Spezifizierungen) für Funktion. Dann haben wir beides und müssen uns für keinen Fall auf irgendwelche Defaults verlassen. Natürlich entsteht dann eine gewisse Redundanz, aber die würde zumindest Fehlersuchtools helfen, potenzielle Fehler zu finden, wenn die Werte nicht zusammenzupassen scheinen.

Tordanik · 2012-10-25T19:28:57.000Z

errt:

Dann haben aber crossable und crossable:* völlig unterschiedliche Semantik und auch Syntax, nämlich ersteres Linienarten und letztere Zulässigkeit des Spurwechsels.

Ich weiß nicht, woher das Missverständnis kommt, ich wolle “crossable” für Linienarten benutzen.

Mein Vorschlag ist ein Tag für Linienarten (für das ich in meinem vorletzten Post keinen Namen vorgeschlagen hatte) einzuführen. Zusätzlich sollte es ein Tag wie “crossable” geben, das bei Bedarf auch mit angehängtem Verkehrsmittel oder sonstigen “Conditional restrictions” verwendet werden kann und einen Teil der Funktion des Spurtrenners abbildet.

Oder, wie wäre es denn hiermit: Ein Tag für’s Aussehen und eines (+ Spezifizierungen) für Funktion. Dann haben wir beides und müssen uns für keinen Fall auf irgendwelche Defaults verlassen. Natürlich entsteht dann eine gewisse Redundanz, aber die würde zumindest Fehlersuchtools helfen, potenzielle Fehler zu finden, wenn die Werte nicht zusammenzupassen scheinen.

Das ist letztlich dasselbe wie ich vorschlage, mit dem einzigen Unterschied, dass bei dir der Mapper immer die ganze Palette an Spurtrenner-Funktionstags angeben muss. Meine Idee wäre, dass er diese nur dort zusätzlich zur Linienart angeben muss, wo die Bedeutung vom Normalfall abweicht - und sie anderswo lediglich “zur Sicherheit” angeben kann.

errt · 2012-10-25T21:16:49.000Z

Naja, ich schließe aus deinen Posts #66, wo du sagtst, das Eintragen des Aussehens sei der einzige gangbare Weg und dass Mapper die Bedeutung dessen nicht kennen müssten (also nicht eintragen könnten), sowie #74, wo du von crossable, Linienmustern und Defaultwerten für selbige sprichst. Von beidem hab ich jetzt nirgends was finden können. Ansonsten ist ja alles schön, wenn alles nur Missverständnisse sind. Ich wäre trotzdem dafür, die Funktion im Allgemeinen und abweichendes Aussehen nur wenn nötig anzugeben und abgesehen davon sowieso dafür, die Spuren über einzelne Wege abzubilden.

@viw: Kein Nachteil zum Modell ohne eigenständige Spuren. Es gibt ja trotzdem noch den normalen highway Weg, also kann der Router zunächst allgemein annehmen, dass man sich auf diesem Weg befindet und dann zum nächstmöglichen Zeitpunkt eine Spur vorschlagen. Mehr bleibt ihm ohne Spurwege ja auch nicht übrig.