Markierung von motorway_link / motorway_junction

Moin,

Was mich etwas “irritiert” ist, daß sehr oft der motorway_link Node identisch ist mit motorway_junction - und immer der letzte mögliche Meter der Ausfahrt beschreibt.

Das führt dann dazu, daß mein Navi sagt “in 400 Metern rechts abbiegen” - mich vorher aber noch nicht auf die Autobahnabfahrtsspur schickt sondern mich ganz am Ende (wo man von der Autobahnspur nicht mehr wechseln kann) erst “rüber schickt”. Mir fehlen also oft 400 Meter, und das kann ziemlich blöde sein wenn da LKW’s sind die ich noch überholen will (weil 400 Meter reicht ja, wenn ich ab da auf die Abfahrtsspur komme aber nicht wenn da dann die Leitplanke vor mir auftacht) :wink:

Nun also meine Frage: Sollte man diese zusätzliche Spur (motorway_link) nicht als solche dort eintragen wo sie beginnt und auch dort mit der motorway_junction Info versehen?

Mein Beispiel: http://www.openstreetmap.org/?lat=49.36234&lon=8.54765&zoom=17&layers=M

Dort habe ich die Abbiegespur auf die B36 (von Nord → Süd, geht nach SSW ab) knapp 300 Meter vorgezogen - auf die Stelle, ab wo sie beginnt - und nicht endet (nicht mehr anfahrbar wegen Leitplanke)…

Und wenn man das so macht - sollte man dann an der letzten Stelle wo der Spurwechsel möglich ist noch einen zusätzlichen Link zwischen der Autobahn und der Abfahrtsspur erstellen? Falls das GPS zu genau ist könnte es ja denken “oops, Du hast den link verpaßt, bist dran vorbei, also route ich den mal 10 km weiter und dann zurück”)? Und wir wollen die Karten ja nur einmal pflegen, falls wir also in Zukunft “zu genau” werden sollte das keine Änderungen erfordern oder :slight_smile: Durch den zweiten Link wäre das dann möglich…

Das Problem entsteht, weil die “Abbiegespur” mit einer gestrichelten Linie von der Autobahn, getrennt ist und deshalb nicht als eigener way angelegt wird, da zwischen den Spuren gewechselt werden kann. Laut Wiki ist das nun mal so definiert. Somit nennt dir das navi immer den Punkt, an dem es kein Zurück mehr gibt

Die 300 m Abbiegespur musst du dir also immer vorher noch denken.

Also müßte die Navi Software das mit der Spur wissen (die gibt es ja i.d.R. immer in DE) und sich dann entsprechend Verhalten korrekt? Dann würde ich mir das Navit Coding mal angucken :wink:

EDIT: Wenn das eine “Spur” ist, wären es dann ab einem bestimmten Node (dort, wo die Abbiegespur beginnt) nicht 2+1 = 3 Spuren statt 2? Und wieder 2 nach dem “motorway_link” Node? Sowas könnte das Navi ja dann besser auswerten: “Ich sehe, daß in einigen hundert Metern vor mir die Abfahrt kommt. Ich sehe, daß die Spuren von 2 auf 3 wachsen und danach wieder auf 2 zurück gehen. Also kann ich davon ausgehen, daß hier die Abbiegespur beginnt und ich schicke den User mal dadrauf…” Das finde ich bei meinem Navigon nämlich sehr nett und hilfreich.

Hallo bjoernchr74,

Problem:
…das Navvgationsprogramm könnte aber auch dann nicht entscheiden bzw. erkennen, ob die zusätzliche 3 Spur zw. Beginn der “Abfahrtsspur” und deren Ende nicht vielleicht auch ein zusätzliche dritte linke Spur ist.

Mir persönlich reicht die Info:

…dann weiß ich, in 100m beginnt (in der Regel) die Abbiegespur. In 400m (gesamt) muß ich abbiegen.
…ich kann damit Entscheidung treffen, ob sich z.B. ein Überholvorgang noch lohnt.

Gruß Jörg

Hi Jörg,

Stimmt - war nur ein Idee :frowning: Ich hatte das gestern beim Mappen gesehen, jedenfalls hatte ich vermutet daß es jemand “dafür” genutzt hat weil es genauso gemapped war.

Das stimmt schon - aber ich mag schon wie Navigon mir das auch optisch darstellt im Navi mit der zusätzlichen Spur und korrekter Ankündigung wann ich “wechseln muß”. Und ich denke dem “normalen Autofahrer” ist sowas dann schon eher klar als wenn er dann überrascht ist “Mist, das wars wohl, Ausfahr verpaßt”. Und ja klar - Navigon nutzt nicht OSM (vermutlich :wink: ) und kann daher das Kartenmaterial “anders” pflegen. Und ja, jede Navi-Software ist anders (oder kann es sein). Aber das heißt ja nicht, daß man sich bei kommerziellem Zeugs nicht auch Anreize holen kann was man in Open-Source aufnehmen könnte (sowas würde ich nämlich bei Navit schon geil finden mit optischer Anzeige wo es nun genau lang geht, hatte ich vor mir bald mal anzugucken und da was zu coden) :slight_smile:

Dann warte ich mal auf den Kommentar “Wir mappen nicht für Navigationssysteme…” :wink:

Hey, das meinte ich doch auch :slight_smile: Da hast Du mich falsch verstanden :slight_smile:

Klar mappen wird nicht für Navi’s. Am Ende muß die Navi Software (irgendwie) basierend auf den OSM Daten die “für sie logischen Schlußfolgerungen” ziehen :slight_smile: Navigon hat’s da leichter, die können das machen wie sie wollen :wink:

Aber nun eine ernsthafte Frage: wenn da so eine dritte Spur “erscheint” auf der Autobahn (die eigentliche Ausfahrt) sollte die doch auch da irgendwie “aufgenommen” werden würde ich denken oder? Schließlich kann man von der ja auch wieder zurück wechseln (hab ich zwar noch nie geschweige denn drüber nachgedacht das zu tun aber stimmt schon). Von daher sind es doch zu dem Zeitpunk n+1 Spuren? Ich hab das gestern irgendwo gesehen, weiß aber nimmer wo grrr… Das wäre doch dann ein “Abbilden der Realität”, und nicht für Navi’s speziell. Aber die “könnten” sich da vielleicht was drauß ableiten :wink:

Der Navigon “Ableger” Skobbler nutzt OSM Daten. Vielleicht ist Euch schon aufgefallen, dass die Ansagestimme von Navion und Skobbler gleich ist. :wink:

Den Beginn der Abbiegespur kann man im Prinzip dadurch erkennen, dass lanes=2 auf lanes=3 wechselt.

Mit Spurassistent meinst Du vermutlich Pictogramme dieser Form:

Ich denke, das könnte man mit einer Relation lösen. Man bräuchte einen Katalog mit zB. 100 Piktogrammen (dadurch
sollten sich 99% aller Konstellationen abbilden lassen), und in die Relation würde man from- und to- Way, sowie
die Nummer des Piktogramms und einen Node packen, an welcher Stelle das Piktogramm eingeblendet werden soll.

Nur sonn’ Gedanke… :wink:

Chris

Oder man würde sich mal zu einer Lösung durchringen, mit der man vernünftig mehrspurige Straßen spurgenau erfassen kann. Dann könnte das Navi nämlich selbst entscheiden.

…oder man erfasst zumindest die Abbiegespur. Für den Rest sollte lanes=* reichen.
da gab es schon mal eine Diskussion:
http://forum.openstreetmap.org/viewtopic.php?id=4481

Abbiegespur? Ich dachte das geht nicht? Wir würde man das denn “korrekt” machen?

Ja - aber leider sehe ich da kein wirkliches “Ergebnis” :slight_smile: Ich würde ja gerne was “mappen” so wie es alle dann tun sollten damit man es später auch in Software einbauen kann (ich weiß, “wir mappen nicht für Navis” :wink: )… Obwohl man ja später, wenn das “entschieden”, ist diese “unterschiedlichen Ansätze” ermitteln kann über Software und abgleichen könnte. Ich meine es gibt da soviele “Vorschläge”:
http://wiki.openstreetmap.org/wiki/DE:User:%C3%96mmes/Wayparts
http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group (da gibt es auch ein JOSM Plugin)
http://wiki.openstreetmap.org/wiki/DE:Lane_Assist

Tja, da liegt das Problem. Bisher hat sich noch niemand dazu entschlossen, dafür ein proposal zu schreiben und eine Abstimmung einzuleiten :frowning:
Da dieser Aspekt “Abbiegespur” wohl nur als “Service für Navis” eine Rolle spielt, fühlte sich wohl noch keiner dazu berufen. Sollte sich in der community die Einsicht durchsetzen, dass wir auch mehr an die Interessen der Daten-Anwender denken sollten, bewegt sich da vielleicht was.

Wenn du dich traust, kannst du ja mal was lostreten. Neues etabliert sich immer nur dann, wenn man eine gewisse Anzahl der Mapper davon überzeugen kann.

Viel Erfolg dabei :roll_eyes:

Hab ich im Prinzip kein Problem mit… Aber da es ja schon verschiedene Ideen gibt würde ich diese User erstmal anschreiben und gucken das man sich mal “unterhält” und man sich dort zumindest auf ein Vorgehen einigen könnte und von da an könnte man das ja dann in ein Proposal erweitern. Aber im Augenblick, wo es eben schon mehrere Versionen gibt, würde bei einem Proposal sicherlich nichts bei rauskommen, da jeder seins für besser hält etc :frowning: Ich werde da mal was anstoßen. Und dann gucken wir mal :slight_smile:

Also ich denke man sollte sich gemeinsam hinsetzen und Ziele formulieren. Dann kann man auch sehen was aus welchem Modell das beste ist.

Das oberste Ziel sollte sein die Daten so einfach wie möglich zu halten.

Mein Ziel einer solchen Anwendung wäre die richtige Spuranzeige im Navi. Ich denke das ist für Autofahrer und Fahrradfahrer sehr hilfreich. Ob der Fahrradweg nun in der Mitte verläuft und ob die Busspur freigeben ist oder nicht.

Andere Verwenden die Spuren nur für eine möglichst realistische Darstellung. Dafür genügt es jede Straße mit den Tags Spur eins Spur zwei Spur drei. Wenn ich jedoch Verbindungen schaffen möchte von Spur eins dieser Straße zur Spur der weiteren Straße, dann denke ich sind Relationen die bessere Wahl.

Hier in dem Thread oder einen neuen aufmachen? Mir ist es gleich “wie” wir uns unterhalten und das alles formulieren. Wenn wir das in dem Thread hier tun wollen würde ich die User aus den o.g. Links anschreiben, daß die sich hier einbringen können und man zu einem “Ergebnis” kommt.

Eine “möglichst realistische Darstellung” kommt vermutlich dem entgegen was “nicht Navi” OSM Mapper sich wünschen. Also wäre es gut denk ich, wenn man das irgendwie hinkriegen könnte das alle happy sind - diejenigen wo sich nicht um Navi’s kümmern wollen und die wo dann “extra Daten” einfüttern und damit Navi’s ein geiles Routing ermöglichen ohne es “optisch zu versauen”.

Ich bin gegen etwas “statisches” wie solche Piktogramme - verbrauchen nur Speicherplatz und sind “fest”. Ein Navi ist ein Computer. Basierend auf den vorhandenen Daten und etwas progammiergeschick ist er sicherlich in der Lage, die Grafik “korrekt” zeichnen zu können - sofern die Daten korrekt gemapped werden. Damit wäre man dann auch (das wäre mein Wunsch) landesunabhängig.

Egal was am Ende rauskommt (Relationen/Spuren/…): Es sollte dafür ein Plugin geben mit welchem man das “komfortabel” mappen kann. Da es kompliziert werden kann wäre das eine gute Möglichkeit für “Korrektheit” zu sorgen.

Nein, Anlaeufe dazu hat es schon mehr als genug gegeben. Das Problem ist eher, dass dieses Thema in den Bereich der Linienbuendel gehoert (wie z.B. auch die Radwegproblematik). Und das ist das reinste Wesepennest mit Null Ausssicht auf irgendeine Einigung.
Deshalb bleibt einem momentan nichts weiter uebrig, als in diesem Bereich eine gewisse Unvollkommenheit zu akzeptieren. Alles andere ist von vornherein zum Scheitern veruteilt und somit pure Zeitverschwendung.

Gruss
Torsten

…und schon sind wir wieder an dem Punkt, wo gute Ideen, welche dem Wertschöpfungsprozess OSM dienlich sein könnten, scheitern, weil wir als Datenerfasser den Endanwender mit seinen Wünschen und Problemen nicht genügend berücksichtigen. :frowning:

Inwiefern “Unvollkommenheit akzeptieren”? So, wie es derzeit ist (mehrere verschiedene Varianten) ist das ja nicht wirklich praktikabel denk ich - wenn man sich auf etwas irgendwie einigen könnte um zumindest “anzufangen” wäre es in der Zukunft ja sicherlich denkbar über Software die “alten” Daten zu korrigieren bzw. anzuzeigen und dann händisch zu ändern? So ähnlich wie ich auch “maxspeed:forward” mappe obwohl es nicht offiziell supported wird bisher - einfach weil man es dann “hat” und später “korrigieren” kann statt dann erst anzufangen und die Daten zu sammeln. Für Navit hab ich da schon eine Korrektur für geschrieben die das “maxspeed:forward” hoffentlich bald aufnimmt - so ähnlich kann man das ja auch mit diesem “Spurassi” machen?

Edit:
Ok, also wäre dann wohl das “Resultat” und “Fazit” von http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel passend denk ich? Die haben sich da ja schon lange mitauseinander gesetzt… Wenn dem so wäre: Hat jemand ein “Beispiel” für sowas für eine Autobahnabfahrt (bzgl. “Betreffs der Abbildung von Sonderwegen durch eigene Ways schlägt die Arbeitsgruppe folgendes Vorgehen vor” in dem obigen Link)? Ich mag sowas nicht angehen da ich mir das so nicht zutraue - ich gucke lieber ab :wink:

Genau die verschiedenen Varianten sind das Problem, und es im Moment nicht davon auszugehen, dass es da in absehbarer Zeit zu einer Einigung kommt. Das hat auch nicht wirklich was mit mangelder Ausrichtung auf den Endanwender zu tun, sondern eher damit, dass es unterschiedliche vorstellungen von den Endanwendung gibt. Ich denke, dass man das im Wesentlcihen in die Kategorien Luftbildmaler, die eine moeglichst schoene Rendererdarstellung anstreben, und automatische Auswerter, die programmgestuetzt die Daten weiterverarbeiten wollen, unterscheiden kann. Was dem einen nuetzt, das schadet haeufig dem anderen. Und beide Moeglichkeiten parallel eintragen schafft ein heilloses Durcheinander, da jede Anwendung/Anzeige ja auch die andere variante Unterstuetzen muss, wenn sie denn funktionieren soll.

In OSM gibt es momentan keine Moeglichkeit solche Mappingkonflikte zu entscheiden. Also muss man sich einfach damit abfinden, dass basierend auf den OSM-Daten in absehbarer Zeit nicht alle Anwendung moeglich sind. Ein freies Massenprojekt hat nun mal seine Staerken aber auch seine Schwaechen.

Gruss
Torsten

PS: Natuerlich kann sich bei solchen Streitfragen jeder fuer die ihm am besten passende Loesung entscheiden. Sobald aber in seiner Naehe ein Mapper auftritt, der den entgegengesetzetn Ansatz favourisiert, erkennt er die Grenzen dieses Vorgehens. Dann gibt es nur noch die Moeglichkeiten Tagging-War oder gegenseitiges Stillhalten, also Aufgeben des Verbreitens des eigenen Ansatzes.

Ich denke, dass im konkreten Fall der Abbiegespuren kein Konflikt zwischen den Luftbildmalern und den automatischen Auswertern besteht. Der erste würde eine schöne weitere Spur sehen, die so auch in der Realität besteht, und der zweite wurde erkennen, dass er jetzt zum Abbiegen schon mal auf eine äußere Spur wechseln kann, damit er nicht am “piont of no return” vorbeirauscht.

Denkbar wäre das ganze über einen Zusatz-tag wie turn_lane=yes bis zum abbiegenden way. Aber das müsste man noch genau erarbeiten, damit Renderer und Navis damit klarkommen können.