Routing / Spurmapping

Das Problem können doch dann die router lösen, indem Sie in Richtung Zielpunkt, die Spurauswahl optimieren nach dem Motto: “So früh wie möglich auf eine Spur, die man nicht mehr in Zielrichtung wechseln muss.”
Ob die GPS-Genauigkeit allerdings ausreicht, um auch entsprechend anzusagen, wenn man falsch ist (“Wechseln Sie eine Spur nach rechts”) wage ich zu bezweifeln.

Das bringt mich auf eine Idee:
Genau so könnte man doch mappen: lanes=l,s,r usw.
Der Renderer/Router baut dann das Bild zusammen. Die Bedeutung der Kürzel ist dann
t>turnback
l>left
s>straight
r>right
So könnte man auch im Feld zur Erfassung schnell mitschreiben.

So würde das ganze vorgeschlagene unterschiedliche Gedöns für den key auf einen “lanes” reduziert, wenn man sich dazu entschließen könnte, auf forward und backward zu verzichten, indem man in entsprechenden Bereichen akzeptiert, dass auch mit einer Linie getrennte, gegenläufige Spuren auch getrennt und mit oneway angelegt werden können. Auf Autobahnen und den meisten mehrspurigen Bundesstraßen außerorts wäre die Spurtrennung sowieso schon gegeben. Im innerstädtischen Bereich und den anderen Fällen könnte so das durch versehentliche Richtungsänderung eines unbedarften Mappers entstehende Chaos verhindert werden.

Zumindest könnte man damit auch gleich die Spurwechselmöglichkeit erfassen, wie es in der oben genannten Mail vorkam: “s|s” sind zwei Spuren mit durchgezogener Trennlinien, “s,s” zwei mit gestrichelter Linie. Auch Sonderspäßchen wie doppelte Linien ließen sich machen “s||s” oder “s|,s”. Wenn man dem Leerzeichen noch Bedeutung gibt, wird aus “s s” zwei Spuren ohne Linie als Trennung. Und Konstruktionen wie “s#s” = Trennung durch Verkehrsinsel/Mittelstreifen/echte bauliche Trennung sind auch gemütlich drin. Trotzdem, ich sehe langfristig keinen Weg vorbei an getrennt gemappten Spuren.

Nicht zu vergessen “b” für die Spuren in Gegenrichtung.
Ärgerlich ist, dass man Straßen mit Gegenverkehr zwischen zwei wesentlichen Kreuzungen teilen müsste.

Wenn ihr mir den Spass an OSM vermiesen wollt, müst ihr nur mit Spurmapping anfangen. Damit wäre für mich die Schmerzgrenze erreicht. Die Lösung mit den l,s,r je Spur in einem Tagg an einem Weg kann ich mittragen. Aber jede einzelne Spur zu mappen, da graust es mir.

Ich muss nur an die Mühe denken, die es bereitet, an einer Kreuzung die verschiedenen baulich getrennten Abbiegespuren zu erfassen. Nein das muss man durch Spurmapping nicht noch vervielfachen.

JM2C
Edbert (EvanE)

Das muss das navi auch nicht. Es reicht wenn das Navi die vorhandenen Spuren anzeigt und die dazugehörige Empfehlung. Ich denke jedoch das es nicht ganz einfach ist, vor allem weil die Arten der Spuren auf 3 Richtungen zu begrenzen meiner Meinung nach nicht ausreicht.
Man sollte unterscheiden zwischen Spuren mit und ohne Straßenbahngleis. Außerdem kommt dann noch das ungelöste Problem mit den Fahrrad und Fußwegen dazu. Wir sind ja kein ausschließlicher Autoroutingdatenanbieter. Dann sollte man vielleicht auch unterscheiden wo die Parkspur ist.
Und spätestens jetzt sollte klar sein, dass Tordanik und Marek fordern Straßen nicht als Linien zu erfassen, sondern flächig.

Auch die Idee von errt ist sehr gut. Sie führt aber zwangsläufig dazu, dass die Straßen an jeder Änderung der Fahrspuren und/oder Wechsel der Markierung geändert werden müssen.

So JM2C ist das gar nicht. Von mir ein +1. Und sicher geht es anderen Mappern genauso. Mir graust schon seit einer Weile vor diesen ganzen :-keys als Zusatztags, die sich nur darauf spezialisierte Mapper merken können, und ich gehe ihnen aus dem Weg.

Würde mich nur mal interessieren, was ein Fachmann für Renderer oder Router von der Idee l,s,r hält :confused:
Und jetzt gehe ich Proposal ablehnen.

Naja schau dir diese Kreuzung an:
http://maps.google.de/maps?q=Dresden.&hl=de&ll=51.033153,13.774718&spn=0.000351,0.000603&sll=51.151786,10.415039&sspn=23.032053,39.506836&vpsrc=6&hnear=Dresden,+Sachsen&t=h&z=21
und vergleiche mit einer belibigen anderen Krezung. wo ein Rechtsabbieger in eine zweispurige Straße münden. Mal ist es geregelt mal ist es nicht geregelt.
Wie würde die Spuraufteilung hier sein? http://maps.google.de/maps?q=Dresden+Hansastra%C3%9Fe&hl=de&ie=UTF8&ll=51.073884,13.739174&spn=0.000351,0.000603&sll=51.033153,13.774718&sspn=0.000351,0.000603&vpsrc=6&hnear=Hansastra%C3%9Fe,+01097+Dresden&t=h&z=21 wenn man aus der Fritz Reuter straße links oder rechts nach Norden abbiegt? Hier sind 3 Spuren zur Wahl.

Auch diese Kreuzung ist sicher sehr interessant: http://binged.it/w9W5oN

Für die Straßenbahn habe ich gerade keine (edit:)zündende Idee :confused:
c>Fahrrad (cycle)
f>Fußgänger (foot)
cf> Fahrad und Fußgänger gemeinsam
p> Parkspur (parking)
oder einfach wie bisher z.B zusätzlich "cycleway=track
Wenn jemand eine bessere Idee als t>turnback hat, könnte man t>tram verwenden. Als kombination “st” wäre das dann eine geraedeaus-Spur auf der die Schienen liegen.

Das Auftrennen der Straßen bei Änderungen ist sicher z.B. bei Relationen nicht unkritisch, aber jetzt schon tägliches Brot z.B. bei Brücken.

Noch eine Idee :confused:
Man könnte doch auch über die betroffenen nodes/Wegteile des entsprechenden highway=* eine überlagernde linie highway=lanes legen, welche dann zusätzlich den tag "lanes=,,* bekommt.

Feuer frei, denn Denken ist ja nicht verboten.

Hmmm…ich würde es schon so offen halten, ähnlich dem proposal.
lanes= gibt einen Namensraum von 1 bis vor.

lane<1…number>=forward_left|forward_straight|forward_straight_left|backward_…

Bisher ist der Informationsgehalt noch gleich. Allerdings kann man nun je nach Lust und Laune auch noch spurspezifisches taggen. Bspw. lane1:surface=… Meinentwegen auch lane1:direction=

Eine bauliche Trennung würde ich weiterhin auch als 2 Straßen mappen.

@viw: Naja wenn ein Rechtsabbieger in eine zweispurige Strasse mündet, ist es doch irrelevant. Es gibt nur eine Abbiegespur, die dir beim Spurassistenten dann auch angezeigt wird. Wenn du danach auf die linke Spur sollst, weil du bald links musst, wäre die Anzeige/Ansage von der Rechtsabbiegespur AUF die linke Spur.
Gilt für deine ersten Beiden Beispiele. Auf dem Dritten kann ichs nicht so recht erkennen.

Zum Thema tagging, wie es hurdygurdyman und errt weitergesponnen haben, hört sich doch gut an.
Baulich getrennte Strassen mit einem Weg je Richtung. So ist es meistens sowieso gemacht. Und dann EIN Tag für alles, was AUF der Strasse ist. Fuss- und Radwege würde ich in eigene Tags tun mit left/right, wie es bei Parkspuren gemacht ist. Für Gleise auf der Strasse müsste noch ein Buchstabe gefunden werden und z.B. ‘B’ für Fahrradspuren auf der Strasse. Und die Zeichen für die verschiedenen Markierungen. Das wäre Taggen was man sieht, von links nach rechts.
Und eingeben könnte man das ganze in JOSM grafisch aufbereitet mit Verkehrszeichen und Icons für die Verkehrsteilnehmer. Das gilt aber auch für das Taggingschema des Proposals. Das wäre zwingend nötig, wir kriegen ja noch nicht mal Abbiegebeschränkungen über Tageingabe hin :wink:

EDIT:
Hm, u wie u-turn und t wie tram?
Ein extra Tag für Anzahl der lanes würde ich nicht machen, ergibt sich doch zwangläufig.

Manchmal sollte man doch ein Lexikon bemühen:
Wenn wir u>U-Turn für “Umkehrspur” nehmen, wäre t=Tram für “Straßenbahn” frei. :slight_smile:

things-change war schneller :frowning: zwei Hirn, ein Denk :slight_smile:

Genau das gleiche schrieb ich auch gerade, siehe oben… :slight_smile:

Surface würde ich erstmal aussen vor lassen. Bzw. von lanes unabhängig machen. Beide sollten ohne das jeweils andere funktionieren. surface ohne getaggte lanes gilt global, ansonsten durch Kommas getrennt für die Spuren. Müsste natürlich ne Gültigkeitsprüfung eingebaut werden, ob gleich viele Spuren getaggt.

Ich spinne mal weiter:
lanes=nl >no left usw…

Ich hatte vorhin schon den Gedanken: Wenn keine Linksabbiegerspur getaggt ist, gibt es keine Linksabbieger. Das Abbiegeverbot müsste gar nicht mehr getaggt werden. Also ist ‘no left’ gar nicht nötig, wenn s ganz links steht.(Bzw l nicht vorkommt)

Es war so gedacht, dass es logischerweise einen allgemeinen surface-Tagg etc. gibt. Ich befürchte aber, dass es über kurz oder lang Mapper geben wird, denen dies nicht ausreicht, weil bspw. die Abbiegespur anders ist, als der Rest. Oder weil der maxspeed da anders ist oder die Spurbreite oder weiß der Geier ;). Von daher finde ich es sinnvoller, ein Schema zu wählen, das einfach weiter detailliert werden kann, sollte dies nötig sein.

Abkürzungen erschweren meiner Meinung das “Textmappen” (Eingabe des Values per Tastatur) und erhöht die Gefahr für Tippfehler und dessen Entdeckung.

Stimmt. Manchmal hat man doch einen (alterbedingten?) Denkknoten. Aber wir schaffen das :wink:

Das halte ich für recht gefährlich. Lass mal das Schema auf eine normale Straße los, die eine Busspur hat, die man damit mappen möchte. In der Realität wirst du keine Abbiegespur haben und dennoch ist Abbiegen erlaubt.

Stimmt. Widerspricht auch meiner Idee, mit lanes wirklich nur die Spuren zu beschreiben. Das Abbiegeverbot gilt ja für die Strasse.

Wie ist denn bisher auf einer Autobahn eine Geschwindigkeitsbeschränkung nur für die rechte Spur getaggt?

Dann geht aber auch sowas wie “lanes=nl” nicht, weil es sich mit den wirklichen Möglichkeiten beißt.
Könnte dann so etwas wie “turn_restriction=nl” sein, was in Straßenrichtung am nächsten Knoten gilt und wir sparen uns die Relationen…
… oder lassen die Relationen???

Ich würde die restriction-relationen auf jeden Fall lassen. Die sind “sehr verbreitet” und man hat mit ihnen bisher alles taggen können, was einem so vor die Flinte kam.

Zum anderen halte ich nicht viel davon, dass sich unterschiedliche Sachen beeinflussen. Das verwirrt Router, Mapper und Editoren.

@things-change: Ich bin auf Autobahnen nicht so zuhause, die wollen mich als Radler immer nicht, aber ich vermute, dass dies gar nicht abgebildet ist.

An so einen Fall kann ich mich nicht erinnern. Wenn mich meine grauen Zellen nicht arg täuschen, fangen Geschwindigkeitsbeschränkungen erst da an, wo die Abbiegespur in die Ausfahrt übergeht. Das wäre dann aber schon highway=trunk_link.