Routing / Spurmapping

Und wie machst du ihn in deinem Beispiel? sorry, gar nicht gesehen, dass der Post von wem anders kam…

Wenn man das alles abbilden will, braucht man für die Bahn ein genauso komplexes Tagging-Schema wie fürs Auto. Also zu jedem lanes:xxx= ein lanes:tram:xxx=

EDIT:

Ausserdem bin ich der Meinung, wenn auf einer Straße 2 Bahnspuren getaggt sind, und auf dem nächsten Teilstück die Bahnspuren um eine Spur versetzt sind, dann ist eindeutig, dass beide Bahnspuren geschwenkt haben und so sollte man es dann rendern.

Manchmal muss man ein Proposal erst zur Abstimmung bringen, damit sich die Leute damit beschäftigen. Das ist aktuell bestens gelungen. Die Ereignisse überschlagen sich, immer mehr Vorschläge werden veröffentlicht. Ich hab auch welche.

Den Ansatz für width und maxspeed finde ich gut.

Die starre Trennung nach Fahrtrichtungen ist aber nicht flexibel genug. In den USA gibt es angeblich Abbiegespuren, die in beiden Fahrtrichtungen befahren werden dürfen. Außerdem sind Bus- und Radstreifen auf der “linken” Seite denkbar möglich.

Ich habe in der Mailingliste Talk-AT ein Konzept vorgestellt, das ich hier noch genauer ausführen möchte.

Anforderungen:

  • Es sollen alle Spuren, Trennstreifen usw. abgebildet werden.
  • Es soll Routing in allen Fällen und für alle Verkehrsteilnehmer funktionieren. (Außer Fußgänger, die klammere ich mal aus.)
  • Auf vielfachen Wunsch sollen Spurassistenten möglich sein, d.h. ein Navi soll ansagen können, welche Spur die richtige ist, um mehrere Kreuzungen später richtig abbiegen zu können.
  • Das ganze soll mit möglichst wenig Relationen und möglichst wenig + verständlichen Tags gehen.

Ich bin zur Ansicht gelangt, dass man die Spurendefinition von den Routinginformationen trennen muss. Bisher wurde das oft in einen Topf geworfen, darum waren die Taggingschemas wirr und deckten nicht alle Fälle ab.

1.) lanes=* - Spuren- und Spurentrennerdefinition, für beide Fahrtrichtungen

2.) lane_matching=* - Von welcher Spur kommt man auf welche Anschlussspur auf welchem anschließenden Way. In diesem Tag werden nur die in Fahrtrichtung zu benutzenden Spuren berücksichtigt.

3.) Spureigenschaften:
lanes:maxspeed=*
lanes:width=*
lanes:surface=*
usw.
Wie von Walter vorgeschlagen, aber mit lauter Kommas, keine Strichpunkte. Strichpunkte sind nicht nötig, weil die Fahrtrichtung schon in lanes=* definiert wird. Außerdem werden Strichpunkte üblicherweise benutzt um unabhängige Werte aneinanderzureihen. Hier sind sie nicht unabhängig, sondern sie stehen in einer definierten Reihenfolge.

Die Spuren werden immer von links nach rechts angegeben (in Way-Richtung schauend).

ad 1:
Die Syntax ist von http://wiki.openstreetmap.org/wiki/Proposed_features/Lanes_ex abgeleitet, aber viel ist davon nicht mehr über.

lanes=<Spuren von links nach rechts, jeweils mit mind. 1 Trenner dazwischen>
= [“+” …]
= l | sl | s | sr | r | c | b | t | w … left/slightleft/streight/slightright/right/(bi)cycle/bus/taxi/railway(oder tramway)

  • kann auch uppercase sein, heißt dann engegen der Wayrichtung.
    Beispiele: w+l … Linksabbiegespur mit Schienen; b+c … Bus und Fahrrad; L+l … in beiden Richtungen befahrbare Abbiegespur (s.o.)
    = folgende:
    , … Leitl- oder Warnlinie, Spurwechsel/Überholen erlaubt
    | … Sperrlinie
    ,| … Sperrlinie, Überholen von linker Seite erlaubt
    |, … Sperrlinie, Überholen von rechter Seite erlaubt
    || … doppelte Sperrlinie
    <> … undefinierte bauliche Trennung
    … durch Grasfläche baulich getrennt, die Klammern sind hier Literale, statt grass sind auch alle anderen Werte von barrier=* und surface=* erlaubt

ad 2:
lane_matching=<Spuren von links nach rechts, durch je 1 Komma getrennt>
= [][“.” [“+” …]]
… 0=umkehren, 1=linkester Anschlussway, 2=zweitlinkester usw., Default ist 1
… 1=linkeste Spur, 2=zweitlinkeste usw., Default ist alle

lane_matching:backward=* … genauso, aber Blick entgegen der Wayrichtung, für die Anschlüsse am rückwärtigen Ende des Ways

Beispiel 1:
lanes=R,C,S,SLsl,s,c,r für beidseitig Linksabbiegeundgradaus-Spur, Gradausspur, Radfahrstreifen und Rechtsabbiegespur, in der Mitte eine bauliche Trennung mit Hecke.
dazu zusätzlich:
lane_matching=0+1+2.1, 2.2, 2.3, 3

  • d.h. von der linkesten Spur darf man umkehren (0), links abbiegen auf beliebige Spur (1) und geradeaus fahren auf linke Spur (2.1);
    von der zweitlinkesten Spur darf man geradeaus auf die zweitlinkeste fahren (2.2);
    von der drittlinkesten auf die drittlinkeste (d.h. auf den Radfahrstreifen bleiben);
    von der rechten darf man rechts abbiegen auf eine beliebige Spur (3).

Beispiel 2:
3 Spuren, mittlere teilt sich:
lane_matching=.1, .2+3, .4

Beispiel 3:
3 Spuren, linke hört auf:
lane_matching=.1, .1, .2

Zusammenfassung: Die Syntaxbeschreibung wirkt ein bisschen kompliziert, aber wie die Beispiele zeigen, ist das Tagging sehr kurz und halb so wild. Relationen sind keine nötig, die Abbiegerelationen erübrigen sich auch. Bei Way-Splits muss man aufpassen, aber das gilt für die alternativen Proposals genauso.

Macht es Sinn, die Fussgaenger auszuklammern? Ich wuerde mal behaupten, wenn das Schema fuer Radfahrer taugen soll, dann muss es auch fuer Fussgaenger brauchbar sein. Bei dieser Fragestellung haben beide Gruppen doch sehr aehnliche Anforderungen ans Routing und auch die Kartendarstellung fuer Rad- und fuer Fusswege sollte moeglichst aehnlich aussehen.
Hinzu kommt noch, dass es haeufig genug auch gemeinsame Wege fuer Fussgaenger und Radfahrer gibt. Da kann man die Fussgaenger ja auch nicht einfach so unter den Tisch fallen lassen.

Um so wichtiger wird es dann auch, die Richtungseigenschaft einer Spur zu erfassen, die fuer verschiedene Verkehrsteilnehmer unterschiedlich sein kann. Dass hat man allerdings nicht nur bei Fuss- und Radwegen, sondern auch schon bei einer Einbahnstrasse, die per Rad in der Gegenrichtung befahren werden darf.

Gruss
Torsten

Egal bei welchem Lanes-Ansatz, das Verbinden sollte so aufgebaut sein, dass es im Normalfall nicht getaggt werden muss.

Beispiel:
Von einem Way gehen in Fahrtrichtung 3 Wege ab, links, geradeaus, rechts.
Er hat 4 lanes. left, straight, straight right, right. Es ist eindeutig, das. die linke lanes auf den linken Weg führen usw. Biegt eine Spur nach rechts ab, und die Zielstrasse hat 2 Spuren, führt sie auf die rechteste Spur. Analog links. 90-95% der Verbindungen sollten so abgedeckt sein, ohne irgendwas taggen zu müssen.

Vom Schema her alles kein Problem. Nehmen wir “p” für Pedestrian.
Gemeinsamer Rad- und Fußweg: lanes=c+p
Geteilter Rad- und Fußweg: lanes=c|p
Radfahren gegen die Einbahn: lanes=C,s

Fußgänger wollte ich deshalb ausklammern, weil man da noch viel mehr berücksichtigen muss. Auf manchen Straßen darf man als Fußgänger auf der Fahrbahn herumgehen, auf manchen nicht, auf manchen (schnellstraßenähnlichen) darf man, will aber nicht. Dann die Straßenquerungen: Leitschienen kann man übersteigen, wenn man das kann. Hecken kann man queren, wenn irgendwo ein Loch ist, aber soll man das mappen? Auf Kreuzungen gibts alle möglichen Übergänge (Zebrastreifen), die derzeit überhaupt nicht gemappt werden, soll sich das ändern (also wenn sich 2 Straßen mit Mittelstreifen kreuzen, 8x highway=crossing mit crossing=traffic_signals)? Das ist ein Thema, das den Rahmen hier sprengen würde.

Es gibt Kreuzungen, wo eine Vorrangstraße eine Kurve macht und die Spuren “mitnimmt”, ohne dass sie als Abbiegespuren gekennzeichnet wären. Weiters ist in AT auf Vorrangstraßen das Umkehren im Ortsgebiet verboten, außer auf geregelten Kreuzungen. Was für Pfeile auf den Spuren aufgemalt sind, sagt noch lang nichts drüber aus, wo man hinfahren darf. Darum mein Konzept, die Spuren und die Zuordnung fürs Routing getrennt zu definieren.

Dennoch wird es nicht schwer sein, auf deine 90-95% zu kommen, denn der häufigste Kreuzungsfall ist, dass Kreuzungen von Straßen mit max. 1 Spur in Fahrtrichtung gebildet werden. Hier ist klar, dass man defaultmäßig von überall nach überall darf. Bei mehreren Spuren in Fahrtrichtung wird es schwieriger. Ich würde sagen: Wenn der Way über die Kreuzung hinweggeht, ist es erlaubt auf der Spur zu bleiben oder von der linken Spur beliebig links abzubiegen oder von der rechten Spur beliebig rechts abzubieten. Ob umkehren erlaubt sein soll, müsste man noch definieren.

Alle anderen Fälle sind, fürchte ich, individuell zu verschieden. Wir können nicht tausend Ausnahmeregeln einführen, wann welche Tags eingespart werden können, denn dann sparen sich zwar eine Handvoll belesene Mapper etwas Schreibarbeit, aber alle anderen blicken nicht mehr durch. Und von den Routern können wir uns auch nicht unbegrenzt Heuristik erwarten. Aber du bist eingeladen, dir Regeln zu überlegen, welche einen vernünftigen Kompromiss bilden.

90%+ waren gemeint für gemappte lanes inkl. routing auf die richtige lane.
Klar macht es keinen Sinn, defaults anzunehmen, die keiner versteht.
Aber nehmen wir eine 2-spurige Nebenstrasse, kein oneway getaggt. Radweg links und rechts. Schreib ich lanes=2, ist alles klar. Gegenrichtung, normale Richtung, abbiegen in alle Richtungen. Radweg hat nen eigenen (bereits vorhandenen) Tag.
Will ich die Radwege NEBEN der Strasse mit dem lanes-Tag erfassen, muss ich weitere Eintragungen machen.

Wenn in AT diese Bestimmung für Durchgangsstrassen gilt, kann man das doch global bestimmen und im lanes Tag aussen vor lassen.

Das alles gilt aber doch genauso fuer Radfahrer, in der Praxis ist der Uebergang vom Radfahrer zum Fussgaenger (mit Rad) und zurueck doch staendig gegeben. Ich denke nicht, dass man das eine Thema beruecksichtigen und das andere aussen vor lassen kann.

Natuerlich hat man hier das Dilemma, dass auf der einen Seite das Schema nicht zu kompliziert werden darf auf der anderen Seite aber moeglichst universelll nutzbar sein soll. Zum Beispiel bin ich mir nicht sicher, ob es Sinn macht, Strassenbahnen mit zu beruecksichtigen. Die werden bislang ja auch unabhaengig von den Strassen erfasst. Aber wenn es ohne Probleme mit beruecksichtigt werden kann, um so besser.

Letztendlich gibt es ja auch das generelle Problem der Linienbuendel, wobei die Strassen sicherlich einen Sonderfall darstellen, bei dem es auch auf den Wechsel von Linie zu Linie ankommt.

Gruss
Torsten

Das gibt es in Celle auch. Hier sichtbar: Die komisch gestrichelte Spur in der Mitte ist für beide Richtungen eine Linksabbiegerspur.

Es gibt in Deutschland nicht nur Abbiegespuren, sondern in Berlin auch geradeausspuren, welche Vormittags in die Stadt und abendes wieder aus der Stadt führen. Gekennzeichnet wird das durch sogenannte Dauerlichtzeichen.

Genauso ein Problem wie bei temporären Geschwindigkeitsbeschränkungen, die mit maxspeed=signals getaggt werden, aber dann natürlich keinen Informationsgehalt haben.

Ich würde vorschlagen, alle Anforderungen einmal aufzulisten.
Dann sollten wir verschiedene Proposals bewerten mit Vor-Nachteilen, bzw. ob alle Anforderungen erfüllt sind.

lanes:backward=4 + lanes:forward=4 ist auf jeden Fall zu wenig, da nicht klar ist, welche Spuren vorwärts gehen.

lanes=bbbfff|bf wäre besser, hier ist die Sperrlinie erkennbar und auch die abgesetzten Spuren.
lanes=bbaff könnte für eine Alternate-Spur stehen, die in beiden Richtungen befahrbar ist.
lanes=bbtff wäre dann eine timely-alternate Spur, die zeitabhängig umgeschaltet wird.

lanes:car=bbbfff|xx könnte Autospuren kennzeichnen,
lanes:tram=xxxxxx|bf wäre für die Straßenbahn.

Bevor wir zu viele Sonderzeichen wie \ | / usw definieren,
sollte ein Programmierer eines Renderers sein Statement abgeben,
ob hier Probleme bei der Auswertung zu erwarten sind.

Also fangen wir einfach mal mit den Anforderungen an.

Für jede Spur sollte klar sein:
*) in welche Richtung die Spur führt: forward, backward, Abbiegespur in beide Richtungen benutzbar, zeitabhängige Umschaltung
*) wer die spur benutzen darf (bicycle, car, tram, psv, taxi, …)
*) Abgrenzung zu Nachbarspuren: Sperrlinie, Sperrlinie von links/rechts überfahrbar, …

Walter

Es wäre schön, wenn auch der Seitenstreifen berücksichtigt werden könnte: Zum Einen ist er auf Landstraßen für Fahrradfahrer interessant (bzw. auch das Nichtvorhandensein), zum Anderen wird er machmal auf Autobahnen zur Benutzung freigegeben (temporärer Standstreifen).

Allgemein sollte auch eine Erfassung des Typs der Spur moeglich sein, durch eine Beschreibung der Erlaubten Nutzung alleine ist das nicht gegeben. Neben dem Beispiel des Seitenstreifens (Standspur) faellt mir da spontan auch noch ein Parkstreifen ein.

Gruss
Torsten

Ok, neuer Wert “sig”:
lanes=S,sig,s für 3 Spuren mit mittlerer richtungswechselnd
So eine Spur zählt dann für die anderen Tags als in beiden Richtungen in Fahrtrichtung befahrbar, darf aber von einem Spurenassistenten nicht angeordnet werden.

Was ist das genau?

Ok, kleines p haben wir schon für Fußgänger vergeben, haben wir noch großes P:
lanes=P,s,P60 für Parkstreifen parallel zum Fahrbahnrand, Gradausspur, Parkstreifen für Schrägparken 70° (Winkel von Wayrichtung im Uhrzeigersinn gemessen).

Für Tageszeitenabhängige Parkstreifen könnte man die Syntax weiter erweitern, z.B.:
lanes=s,s,s[7-18:30]+P[18:30-7] für 3-spurige Einbahn mit zeitabhängigem Parkverbot am rechten Streifen.
In den Klammern die Syntax von opening hours.

viw’s Frontalcrashspur könnte man damit bei fixen Zeiten auch so taggen:
lanes=S,S[0-12]+s[12-24],s

Zu den Anforderungen siehe auch meinen Beitrag #82.

Wer die Spur benutzen darf, kann nicht komplett durch Tags definiert werden, sondern da ist eine Mindestintelligenz (bzw. StVO-Kenntnis) der Router gefragt. Siehe Fußgänger, die dürfen auf der Fahrbahn gehen, wenn kein Gehsteig vorhanden ist und die Straße keine Autostraße oder Autobahn ist. Aber auf den inneren Spuren dürfen sie nicht gehen. Außer um die Straße zu queren. Wenn man das alles in Tags berücksichtigen wollte, würde man verrückt werden.

Ich glaub, mit 1 Buchstabe pro Spur kommen wir nicht durch. Darum hab ich die Leitlinien in meinem Vorschlag explizit als Beistriche vorgesehen.

Bin zwar kein Programmierer eines Renderers, aber Programmierer. Nein, keine Probleme zu erwarten. Sogar ausgefallene Zeichen wie ↔, :arrow_up_down:, :arrow_upper_left:, :arrow_upper_right:, :arrow_lower_right:, :arrow_lower_left: usw. sind erlaubt, aber auf die würde ich verzichten, weil die schwerer einzugeben sind und vielleicht noch nicht überall richtig angezeigt werden.

Da stellen sich mir bloß 2 Fragen:

  1. Wir können hier so ein Schema noch 10 Seiten weiter diskutieren, und dann eine Lösung haben, die alles erdenkliche abdeckt. Bloß es versteht dann keiner mehr. Es gab ja anfangs schon den Einwand, keine Abkürzungen zu verwenden. Andererseits sollen die Tags auch nicht zu lang werden…
    lanes=s,s,s[7-18:30]+P[18:30-7] versteht kein Mensch auf den ersten Blick. Alles grafisch in JOSM einzutragen ist ja schön, aber es gibt ja auch noch Potlatch…
    Wenn man so ein Schema zum Proposal bringt, wird jeder, der das liest und nicht hier an der Diskussion teilgenommen hat, dagegen stimmen…

  2. Muss das Tag denn alles abbilden, was andere Tags bereits abbilden/können/könnten? Muss man Parkstreifen längs, quer, 60° in einem lanes Tag unterbringen? Dafür gibts doch ein Tag. Und wenn das noch nicht alles kann, muss man das Tag halt erweitern. Ebenso Fuß- und Radwege. Das in ihren eigenen Tags zu belassen, würde auch Punkt 1 entschärfen. Ausserdem wären das ja auch doppelte Informationen, macht ja auch keinen Sinn.

+1

Schreib den Scheiss aus, von den Abkuerzungen hat niemand etwas. Normalerweise sollte die Eingabe ueber einen passenden Editor stattfinden. Dem ist es egal, ob er abgekuerzte oder ausgeschriebene Tags erzeugt. Aber es wird immer wieder Faelle geben, wo man es mit der XML-Datei zu tun hat (z.B. wenn man einen Fehler sucht), und dann sind solche Abkuerzungen das letzte, was man lesen moechte.

Man sollte sicherlich nicht zu viel in einzelne Tags reinquetschen, aber man sollte sich Gedanken daruerber machen, was in ein Tag mit rein muss und was besser in einem anderen Tag (welchem?) erfasst werden sollte. Insofern ist schon gar nicht schlecht, dass hier von allen Seiten Sonderfaelle eingeworfen werden.

Gruss
Torsten

Wie wollt ihr dann Fahrverbote für Spuren mappen? Da fielen mir zum Beispiel Dinge ein wie Mindesgeschwindigkeiten Lkw Überholverbote und sowas.

Und dann finde ich es auch besser wenn verschiedene Tags verwendet werden. Damit haben wir nämlich die Möglichkeit erst das Allgemeine und später die Details zu erfassen. Wenn alles in einem steht, dann wird das nicht nur ewig lang, was andere Programme vor Herausforderungen, sondern es müssen auch gleich alle Details erfasst werden. Was wiederum sehr abschreckend wird.

Das halte ich für einen berechtigten Einwand. Man verzettelt sich leicht, wenn man alle Probleme auf einmal lösen möchte. Probleme wie zeitabhängige Werte haben wir auch für Attribute von Wegen noch nicht gelöst - das ist letztendlich ein separates Thema und sollte besser erst einmal außen vor bleiben.

Dasselbe gilt für Tramspuren und, obwohl ich es selbst in die Diskussion geworfen habe, wohl auch für Übergänge zwischen Spuren. Ich finde es schon wichtig, dass das Proposal flexibel genug ist, dass solche Dinge in Zukunft dargestellt werden können. Aber die Tags dafür müssen nicht alle schon im ersten Proposal enthalten sein.

Die Probleme mit Monstertags verstehe ich. Daher mal hier meine Variante des Vorschlags:

  1. Spuren

In lanes nur die Basisfunktion reinpacken, was man also auf jeden Fall wird erfassen wollen: Richtungen und Verkehrsmittelart (ohne Angabe generische "Auto"spur). Also etwa so:

lanes = s+r , s | s , bus

Sinnvoll erscheint mir die Verwendung von Trennzeichen (i.d.R. Kommas), weil dadurch problemlos neue Spurarten erfunden werden können, auch mit mehr als einem Buchstaben.

Außerdem finde ich sinnvoll, einen einzigen Richtungstrenner (das |) zu erlauben. Damit spart man sich nämlich bei einem Großteil der Straßen die Angabe der Fahrtrichtungen: Bei Rechtsverkehr gilt für Spuren links vom Richtungstrenner “backward”, rechts vom Richtungstrenner “forward”.

Nur bei ungewöhnlichen Sortierungen, oder Vorhandensein von in beide Richtungen nutzbaren oder alternierenden Spuren, würde man ein lanes:direction mit kommaseparierten Richtungsangaben für die einzelnen Spuren ergänzen.

  1. Spurtrenner

Spurtrenner in ein eigenes Tag, statt die verschiedenen Arten als Symbole abbilden zu wollen. Außerdem als Wörter ausschreiben, weil es da zu viele denkbare Varianten gibt.

Meist sollte hier schon ein einzelnes separator = continuous / dashed / … reichen - das bezeichnet dann die Trennung zwischen den Fahrtrichtungen (das | im lanes-Tag).

Bei Bedarf kann aber hier natürlich auch wieder eine komplette Liste, also ein
lane_separators = guard_rail , dashed , continuous , dased , guard_rail
oder so stehen.

  1. “Any tags you like”

Beliebige sonstige Tags können über

lanes:Schlüssel = Wert1, Wert2, Wert3, …

bzw.

lane_separators:Schlüssel = Wert1, Wert2, Wert3, …

an die Spuren und Spurtrenner gehängt werden. Das können existierende Schlüssel sein - minspeed, surface, width. Es können auch für Spuren neu erfundene sein - “in dieser Spur verläuft eine Tram-Schiene” oder so. Aber diese Neuerfindungen muss man m.E. noch nicht gleich alle fertig mitliefern.

Wichtig finde ich, dass man auch nur das taggen muss, was man will. Den einen interessieren die Spuren, den nächsten die Radwege usw.

Also:
lanes: s+r, s | s, bus… wie tordanik beschrieb.
Beschreibt nur die Strasse selber.

cycleway:…
gibt schon links/rechts der Strasse inkl. Fahrtrichtung her.

footway:… gleiches Schema wie cycleway. (Hier kommen auch die Breiten und andere Eigenschaften rein.)

parkstreifen:… gibts noch nix? Oder hab ich nicht gefunden. Wenn nicht, sollte das geschaffen/erweitert werden, um auch links/rechts der Strasse, längs/quer, 60 Grad; Breite usw. eintragen zu können.

Und dann ein Tag, welches die Reihenfolge der Fahrbahnen festlegt, falls vom Standard abweichend.
Sowas wie:

path:order=footway,cycleway,parking box,street,parking box,cycleway,footway

Was auch default für Strassen innerorts wäre. Allerdings ist das nur die Reihenfolge für getaggte Wege. Gibts kein footway:…-Tag, hat die Strasse keinen Footway, auch wenn path:order eine mögliche Reihenfolge festlegt.

So kann jeder Taggen, was er will, ohne ein anderes Tag anfassen zu müssen, und es muss nix ein 2. mal getaggt werden, was bereits getaggt/tagbar ist.

Bevor aus diesen Ideen hier das nächste Proposal entsteht würde ich vorschlagen, die verschiedenen Ansätze in einer Tabelle zusammenzufassen.
Jede Anforderung oder Spurkonstellation wird in einer eigenen Zeile dargestellt, für jeden der in Frage kommenden Ansätze kann dann eine Spalte ergänzt werden.
Wenn ein Ansatz bestimmte Anforderungen nicht oder nur unzureichend erfüllen kann, dann fällt er heraus oder wird überarbeitet und somit bleibt automatisch der beste übrig.

Walter