Routing / Spurmapping

Hallo,

bei "unübersichtlichen" Kreuzungen finde ich das Spurmappen extrem wichtig. Ich kenne da eine Kreuzung, die war als eine einfach Kreuzung zweier Linien gemappt, da hat niemand mit der OSM-Karte das Linksabbiegen hinbekommen. Sowohl die Anzeige wie auch die Ansage kommen da so spät, das, wenn man sich erst noch umschauen und orientieren muß, man schon lange an der richtigen Stelle vorbei ist.

Thorsten

Naja, ist für mich "taggen für den Router". Und ein echter Spurassistent wird dadurch mMn. eher erschwert.

Ich finde es gut, wenn die Kreuzung zumindest so aufgeteilt ist, dass die einzelnen Stellen für die Fußgänger-Ampeln auch stimmen. Sorry aber bin halt kein Autofahrter 🤔

Mal schauen, ob ich die erwähnte PNG Grafik vom Harald bekommen kann.

http://lists.openstreetmap.org/pipermai … 03670.html

Bei den beiden professionellen Datenanbietern hat sich der Weg, so wie ich ihn in der PNG Grafik erläutert habe durchgesetzt. Dieses ist in Guidance Komponenten recht einfach zu implementieren.

Chris

!i! wrote:

Ich finde es gut, wenn die Kreuzung zumindest so aufgeteilt ist, dass die einzelnen Stellen für die Fußgänger-Ampeln auch stimmen. Sorry aber bin halt kein Autofahrter 🤔

Es spricht ja nichts gegen die Aufteilung der Kreuzung, es sollte aber eine Differenzierung stattfinden. Z.B. sollten die Hauptfahrspuren ganz normal als Kreuzung eingetragen sein (vom Typ [highway=crossing; type = tertiary {fiktive Beispielbezeichnung}] inkl. aller restrictions).
Dazu kann man, wenn man will, noch [highway=lane] eintragen (wer auf WYSIWYG steht). Für Mapnik etc sieht es dann schön aus und bei mkgmap z.B. kann man einfach sagen, ich will keine [highway=lane] gerendert haben, benutze nur [highway=crossing] und deren restrictions.
Da aber derzeitig alle Fahrspuren den gleichen Tag, z.B. highway=tertiary, bekommen, ist eine Differenzierung nicht mehr machbar.

Noch zur Info, es gibt aktuell eine Abstimmung zu diesem Thema
http://wiki.openstreetmap.org/wiki/Prop … Turn_Lanes

Ob man damit bereits einen Spurassistenten realisieren kann weiß ich nicht, generell
finde ich ein attributsbasiertes Spurmapping aber besser als Separatmapping, deshalb
von mir ein "+1". 😉

railrun wrote:

Noch zur Info, es gibt aktuell eine Abstimmung zu diesem Thema
http://wiki.openstreetmap.org/wiki/Prop … Turn_Lanes

Dieses Propoastal ist leider nicht ganz ausgereift, da es nur die Anzahl der Spuren angibt. Nicht die Art der Spuren. Das ist schließlich auch für die Wiederstandsberechnung beim Routing interessant.
Interessant ist zum Beispiel diese Einbahnstraße:

lanes=3
lanes:turnleft=1
lanes:through=3

Angegeben ist das die Straße 3 Spuren hat. Aber es werden 3 Spuren für Geradeaus und eine für Links abbiegen angegeben. Statt zwei für Geradeaus und eine für Links und Geradeaus.
Aus dieser einfach Situation kann man das ja noch berechnen.

lanes=4
lanes:turnleft=1
lanes:through=3
lanes:turnright=1

Aber wie ist es hier? Teilt sich eine Spur mit der Geradeausrichtung mit den Rechts- oder Linksabbiegern?

railrun wrote:

lanes=4
lanes:turnleft=1
lanes:through=3
lanes:turnright=1

Aber wie ist es hier? Teilt sich eine Spur mit der Geradeausrichtung mit den Rechts- oder Linksabbiegern?

Ist nicht gerade diese Frage ein zentraler Punkt des Proposals? Im Abschnitt 2.4.3 "Ambiguity" stellt der Ersteller des Proposals ja fest, dass in diesem Fall zusätzliche Angaben notwendig sind und führt daher die "lane positions" ein (Abschnitt 3). Konkret würde dann zusätzlich ein Tag vergeben wie z.B. lanes:turnright:location=1, wobei auch "defaults" gesetzt sind.

Auf den ersten Blick halte ich das Proposal daher auch für gut durchdacht (aber bevor ich abstimme, muss ich mich damit noch etwas befassen - Talk-Seite lesen etc.).

chris66 wrote:

Ob man damit bereits einen Spurassistenten realisieren kann weiß ich nicht, generell finde ich ein attributsbasiertes Spurmapping aber besser als Separatmapping, deshalb von mir ein "+1". 😉

Mit dem Proposal kann man keine Spuren mappen, sondern nur die Anzahl von Spuren. Insbesondere kann man keinerlei Attribute für einzelne Spuren vergeben.

Es handelt sich also sicher nicht um eine Lösung des Spur-Problems. Man kann mit diesem Proposal als Lückenfüller eventuell noch ein Weilchen länger hinausschieben, sich um eine echte Lösung kümmern zu müssen.

@viw:

Der Fall ist auch bedacht, du hast falsch getaggt 😉

lanes:through:location=right

Wenn die Rechtsabbiegerspur auch die Geradeausspur ist, ansonsten =left
Siehe Lane Positions.

Ich find das gut, vor allem wenn es dazu führt, das skobbler nen Spurassistenen bekommt 🙂

things-change wrote:

@viw:

Der Fall ist auch bedacht, du hast falsch getaggt 😉

lanes:through:location=right

Wenn die Rechtsabbiegerspur auch die Geradeausspur ist, ansonsten =left
Siehe Lane Positions.

Ich find das gut, vor allem wenn es dazu führt, das skobbler nen Spurassistenen bekommt 🙂

Ich finde es auch gut wenn jemand unsere Daten weiterverwendet.
Aber was Skobler angeht, schau dir bitte nochmal die E-Mail an. Davor habe ich schlicht Angst. Wenn ich dann auch noch dranschreiben soll Spur 1 führt zu Spur 2 der nächsten Straße. Oder habe ich das mit dem Ziel falsch verstanden?
Absolut sinnvoll finde ich allerdings die Info Spur1 nach Köln Spur 2 und 3 nach Bremen. Wenn dies dann auch noch mit den großen Schildern übereinstimmt ist das wirklich eine Hilfe.

Mmmh,
1) einzelne Spuren will man nicht taggen
2) Relationen will man auch nicht
3) und wenn ich mir diesen thread/schema anschauen, bin gespannt, wie das der "0815"-Mapper in praxi hinkriegt,
wenn selbst viw damit seine Problemchen hat ...

Vielleicht sollte man das ganz auf die "Anwendungssoftwareebene heben" (JOSM/Potlatch) und dort einfach für jedermann "Kreuzungen malen" lassen,
das letzendlich darunterliegende Schema kann dann durchaus komplizierter sein.

kellerma wrote:

Mmmh,
1) einzelne Spuren will man nicht taggen
2) Relationen will man auch nicht
3) und wenn ich mir diesen thread/schema anschauen, bin gespannt, wie das der "0815"-Mapper in praxi hinkriegt,
wenn selbst viw damit seine Problemchen hat ...

Vielleicht sollte man das ganz auf die "Anwendungssoftwareebene heben" (JOSM/Potlatch) und dort einfach für jedermann "Kreuzungen malen" lassen,
das letzendlich darunterliegende Schema kann dann durchaus komplizierter sein.

+1
Das ganze ist mindestens so komplex wie die MP's.
Na ja, OSMI bekommt dann einen neuen Bereich "lane corrector" und die OSM-Müllabfuhr hat eine weiteres Betätigungsfeld. Das immer schlechtere Fernsehprogramm schafft auf jeden Fall schon mal Zeitfenster für solche Aktivitäten.

Nahmd,

Seoman wrote:

railrun wrote:

lanes=4
lanes:turnleft=1
lanes:through=3
lanes:turnright=1

Aber wie ist es hier? Teilt sich eine Spur mit der Geradeausrichtung mit den Rechts- oder Linksabbiegern?

Ist nicht gerade diese Frage ein zentraler Punkt des Proposals? Im Abschnitt 2.4.3 "Ambiguity" stellt der Ersteller des Proposals ja fest, dass in diesem Fall zusätzliche Angaben notwendig sind und führt daher die "lane positions" ein (Abschnitt 3). Konkret würde dann zusätzlich ein Tag vergeben wie z.B. lanes:turnright:location=1, wobei auch "defaults" gesetzt sind.

Warum ein zusätzliches Tag? Man kann doch auch taggen, was man sieht:

lanes=4
lanes:turnleft_and_through=1
lanes:through=2
lanes:turnright=1

Die Tagnamen praktischerweise etwas gekürzt natürlich.

Gruß Wolf

Aber was ist denn unter 4: Building lane directions? Das hab ich nicht ganz verstanden. Wenn man so taggen würde, wärs ja ganz einfach:

lanes: l,s,s,sr

(left, through, through, through and right)

oder halt lanes:ls,s,s,r

fertig! 🙂

hurdygurdyman wrote:

Das immer schlechtere Fernsehprogramm schafft auf jeden Fall schon mal Zeitfenster für solche Aktivitäten.

🤣 🤣 🤣

things-change wrote:

Aber was ist denn unter 4: Building lane directions? Das hab ich nicht ganz verstanden. Wenn man so taggen würde, wärs ja ganz einfach:

lanes: l,s,s,sr

(left, through, through, through and right)

oder halt lanes:ls,s,s,r

fertig! 🙂

Naja das Problem ist halt, wie Spuren weiterführen. Eine Spur die an dieser Kreuzung geradeaus führt kann an der nächsten Kreuzung schon eine Rechtsabbiegespur sein.

Wenn die dann wie auf dem Foto gezeigt auch noch sehr kurz ist, weil die nächste Kreuzung gleich kommt empfielt es sich eben schonmal eine andere Spur zu nehmen oder eben genau diese um dann in der gewünschten Richtung weiter zu fahren.

Aber wenn ichs richtig tagge, ist es doch eindeutig, oder hab ich jetzt nen Denkfehler?

Also...

erste Strasse:

l,s,sr,sr (2 Rechtsabbieger)

Da ich 2 Rechtsabbieger habe, hat die nächste Strasse zwangsläufig 2 Spuren:

s,s

und später z.B.:

ls,rs

Und da willst du dann nach links. Also muss der Router nur soweit schauen bis zur nächsten Kreuzung und dann feststellen, dass die 2. Spur von rechts die richtige wär.

Naja, die Zielstraße muss nicht zwangsläufig gleich viele Spuren haben. Zwar darf man dann zumindest in Deutschland die Spur frei wählen, aber trotzdem wäre eine vernünftige Einordnung frühzeitig natürlich sinnvoll.

Das meinte ich ja mit dem richtig taggen. Die Zielstrasse MUSS soviele Spuren haben, wie auf sie führen. Also entweder biegt eine Spur auf eine einspurige Strasse ab, die dann vielleicht kurz danach zweispurig wird. Oder die 2. Spur entsteht wirklich im Abbiegepunkt, aber dann ist es auch so, dass ich von der 2. Spur von rechts auf die 2. Spur von rechts der Zielstrasse abbiege.
Verlink doch mal ein Gegenbeispiel, am Besten Luftbild. Entweder steh ich total aufm Schlauch oder wir reden einfach aneinander vorbei.

viw wrote:

...
Naja das Problem ist halt, wie Spuren weiterführen. Eine Spur die an dieser Kreuzung geradeaus führt kann an der nächsten Kreuzung schon eine Rechtsabbiegespur sein.

Wenn die dann wie auf dem Foto gezeigt auch noch sehr kurz ist, weil die nächste Kreuzung gleich kommt empfiehlt es sich eben, schon mal eine andere Spur zu nehmen oder eben genau diese um dann in der gewünschten Richtung weiter zu fahren.

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.

things-change wrote:

Also...
erste Strasse:
l,s,sr,sr (2 Rechtsabbieger)

Da ich 2 Rechtsabbieger habe, hat die nächste Strasse zwangsläufig 2 Spuren:
s,s

und später z.B.:
ls,rs

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.

errt wrote:

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)

hurdygurdyman wrote:

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

EvanE wrote:

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

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 🤔
Und jetzt gehe ich Proposal ablehnen.

things-change wrote:

Aber wenn ichs richtig tagge, ist es doch eindeutig, oder hab ich jetzt nen Denkfehler?

Also...

erste Strasse:

l,s,sr,sr (2 Rechtsabbieger)

Da ich 2 Rechtsabbieger habe, hat die nächste Strasse zwangsläufig 2 Spuren:

s,s

und später z.B.:

ls,rs

Und da willst du dann nach links. Also muss der Router nur soweit schauen bis zur nächsten Kreuzung und dann feststellen, dass die 2. Spur von rechts die richtige wär.

Naja schau dir diese Kreuzung an:
http://maps.google.de/maps?q=Dresden.&h … n&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+Ha … n&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

viw wrote:

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

Für die Straßenbahn habe ich gerade keine (edit:)zündende Idee 🤔
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 🤔
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=<number> gibt einen Namensraum von 1 bis <number> 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 😉

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.

hurdygurdyman wrote:

...
Wenn jemand eine bessere Idee als t>turnback hat, könnte man t>tram verwenden. Als kombination "st" wäre das dann eine geradeaus-Spur auf der die Schienen liegen.
...

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

things-change war schneller 🙁 zwei Hirn, ein Denk 🙂

Genau das gleiche schrieb ich auch gerade, siehe oben... 🙂

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.

things-change wrote:

...
Das wäre zwingend nötig, wir kriegen ja noch nicht mal Abbiegebeschränkungen über Tageingabe hin 😉
...

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

hurdygurdyman wrote:

things-change wrote:

...
Das wäre zwingend nötig, wir kriegen ja noch nicht mal Abbiegebeschränkungen über Tageingabe hin 😉
...

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)

things-change wrote:

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.

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.

things-change wrote:

hurdygurdyman wrote:

things-change wrote:

...
Das wäre zwingend nötig, wir kriegen ja noch nicht mal Abbiegebeschränkungen über Tageingabe hin 😉
...

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)

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

things-change wrote:

Ich hatte vorhin schon den Gedanken: Wenn keine Linksabbiegerspur getaggt ist, gibt es keine Linksabbieger.

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.

aighes wrote:

things-change wrote:

Ich hatte vorhin schon den Gedanken: Wenn keine Linksabbiegerspur getaggt ist, gibt es keine Linksabbieger.

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?

things-change wrote:

aighes wrote:

things-change wrote:

Ich hatte vorhin schon den Gedanken: Wenn keine Linksabbiegerspur getaggt ist, gibt es keine Linksabbieger.

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.

things-change wrote:

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

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.

No left würde ich auch ncht schreiben. Einfach straight. Und Abbiegebeschränkungen so lassen. Wer sich mit dem lanes tag nicht befassen will, soll es nicht müssen.

Maxspeed ist bisher wohl wirklich so, dass es nur einen Wert gibt. Höchstens noch die Gegenfahrbahn. Könnte man dann auch erweitern auf z.B. maxspeed=none,120,100,60. EIN getaggter Wert gilt global, bei mehr als einem muss die Anzahl mit den Spuren übereinstimmen.

hmmm...macht mir so auch Bauchschmerzen. maxspeed ist so definiert, dass es einen Wert enthält und darauf sind alle Auswerter getrimmt. Diese nehmen dann einfach none an, weil für sie nur Unsinn drin steht. Daher würde ich lane1:maxspeed=100 besser finden. In dem Namensraum lane1 kann man dann die Spur 1 so detailliert beschreiben, wie man es möchte.

Aber wenn aktuell 2 Spuren verschiedene Geschwindigkeitsbegrenzungen haben, ist vermutlich eh none bzw. nix getaggt. Oder einer der beiden Werte, was aber auch falsch wäre. Wenn der Auswerter dann 120,100 nicht lesen kann und none annimmt, ist es nicht falscher als bisher. Und wenns wer auswerten kann, wärs endlich richtig.

hurdygurdyman wrote:

things-change wrote:

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

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.

Elzer Berg auf der A3 Richtung Süden:
Links und Mitte 100 km/h, Rechts 60 km/h

Edbert (EvanE)

Und, wie ist es getaggt? Mit 100.

http://www.openstreetmap.org/?lat=50.41 … 8&layers=M

@aighes
Mal als Beispiel:

lanes=4
lane1=forward_uturn
lane2=forward_straight,tram
lane3=forward_straight_right
lane4=forward_right
lane1:surface=asphalt
lane2:surface=concrete
lane3:surface=cobblestone
lane4:surface=concrete:lanes
maxspeed:lane1=none
maxspeed:lane2=50
maxspeed:lane3=30
maxspeed:lane4=10

oder

lanes=u,st,sr,r
surface= asphalt, concrete, cobblestone, concrete:lanes
maxspeed=none,50,30,10

things-change wrote:

Und, wie ist es getaggt? Mit 100.

was ja auch für den router eine wichtige information ist, schließlich geht es um "max"speed

EvanE wrote:

...
Elzer Berg auf der A3 Richtung Süden:
Links und Mitte 100 km/h, Rechts 60 km/h

Edbert (EvanE)

Ist aber so noch nicht getaggt, oder?

Allgemein:
Wenn sich das *,*,*-Schema für lanes durchsetzen sollte, müssten natürlich auch spurabhängige andere tags mit unterschiedlichen Werten an dieses Schema halten, somit auch maxspeed 🤔

Aber bevor wir hier weiterspinnen:
Mir wäre jetzt wichtig, dass sich mal render- und routing-Experten von der Auswertungsseite äußern, inwieweit das alles verwertbar ist!
sonst bleibt nur unsere Vision 🙄

Jayjay01 wrote:

things-change wrote:

Und, wie ist es getaggt? Mit 100.

was ja auch für den router eine wichtige information ist, schließlich geht es um "max"speed

Da ist die Frage, was der derzeit bei 100,100,60 lesen würde. Den ersten Wert? Dann wär alles gut. Oder 'kenn ich nicht'=none. Dann wärs ne Verschlechterung. Notfalls müsste man ein neues Tag nehmen, z.B. maxspeed:lanes

things-change wrote:

Und, wie ist es getaggt? Mit 100.
...

Da kein router die genaue Spur erkennen kann, wird er die maxspeed auch nicht anzeigen können, es ei denn, er blendet ein Schild mit den jeweiligen Geschwindigkeiten nebeneinander ein. Eine optisch/akustische Warnung wird er nur beim höchsten Wert können.

Er könnte es immerhin über den Spuren anzeigen und bei der Routenberechnung für die zu verwendenen Spuren mit einbeziehen.

things-change wrote:

Jayjay01 wrote:

things-change wrote:

Und, wie ist es getaggt? Mit 100.

was ja auch für den router eine wichtige information ist, schließlich geht es um "max"speed

Da ist die Frage, was der derzeit bei 100,100,60 lesen würde. Den ersten Wert? Dann wär alles gut. Oder 'kenn ich nicht'=none. Dann wärs ne Verschlechterung. Notfalls müsste man ein neues Tag nehmen, z.B. maxspeed:lanes

momentan würde er bei 100,100,60 wohl sagen kenn ich nicht... daher finde ich es richtig, dass es mit 100 getaggt ist, da dies die maximale geschwindigkeit ist, mit der auf der strecke gefahren werden darf.

things-change wrote:

lanes=4
lane1=forward_uturn
lane2=forward_straight,tram
lane3=forward_straight_right
lane4=forward_right
lane1:surface=asphalt
lane2:surface=concrete
lane3:surface=cobblestone
lane4:surface=concrete:lanes
maxspeed:lane1=none
maxspeed:lane2=50
maxspeed:lane3=30
maxspeed:lane4=10

oder

lanes=u,st,sr,r
surface= asphalt, concrete, cobblestone, concrete:lanes
maxspeed=none,50,30,10

Sicherlich das untere ist kürzer, aber:

• schau dir mal die typische breite eines Editor-Eingabefensters an
  
• es ist meiner Meinung nach inkompatibel zu den bisherigen Bedeutungen von maxspeed und surface (nur ein value)
  
• Tippfehler fallen kaum auf bei Abkürzungen (die bei OSM ohnehin nicht gerne gesehen werden)
  
• deutlich unübersichtlicher (finde mal bei 6 ,-getrennten Werten schnell den richtigen im Editor)
  
• in der Regel ist der surface und maxspeed identisch, sodass dann oben auch nur ein Wert nötig ist
  

things-change wrote:

Mal als Beispiel:

lanes=4
lane1=forward_uturn
lane2=forward_straight,tram
lane3=forward_straight_right
lane4=forward_right
lane1:surface=asphalt
lane2:surface=concrete
lane3:surface=cobblestone
lane4:surface=concrete:lanes
maxspeed:lane1=none
maxspeed:lane2=50
maxspeed:lane3=30
maxspeed:lane4=10

@aighes:
Ich gebe dir recht, was die Kombatibilität und die Anwendbarkeit betrifft. Durch die Nummerierung ist das auch für den Otto-Normal-Mapper durchschaubar. Allerdings sollten wir auf zusätzliche forward/backward verzichten und dafür je Fahrtrichtung auch ohne Trennung (Insel, Doppellinie) einen eigenen way als oneway in Erwägung ziehen, weil sich das sonst wieder als fehleranfälliger Moloch entwickelt und Mapper abschrecken könnte. Mindestens auf Autobahnen und großen primary ist die Trennung ja sowieso vorhanden. Eine durchgezogene Linie als Mittellinie zwischen den gegenläufigen Richtungen oder eine Schraffur dürfte in den anderen Fällen auch ein Überfahren derselben verbieten.

things-change wrote:

@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 😉

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.

So einfach ist es nicht. Die erste Kreuzung ist nämlich aufgeteilt. Da kann der rechtsabbieger nur in die rechte Spur und der Linksabbieger von Norden nur in die linke Spur. Das ist auch durch eine durchgezogene weiße Linie gut erkennbar.
Bei der zweiten Kreuzung sieht es schon anders aus. Wenn ich von der Fritz Reuter straße in die B170 nordwärts einbiege, habe ich drei Spuren zur Auswahl. Wenn man keine Unterscheidung trifft sortiert das Navi auch hier links/rechts und die Mitte bleibt frei.

Die Dritte Kreuzung ist insofern interessant, dass hier aus Westen auf der Schweriner Straße kommend 3 Spuren sind. Die Rechtsabbieger sind am rechten Rand. Danach kommen die Linksabbieger in der Mitte und ganz Links sind wieder die Rechtsabbieger Straßenbahn und Bus.

Wie wollt ihr denn so eine Stele mappen?
http://maps.google.de/maps?q=Kesselsdor … 1,,0,-6.11
Es kommt auf den Pfeil an, welcher dazu auffordert den Überholvorgang abzuschließen. Das ist nicht das Ende der Spur, sondern so war die Straße über längere Abschnitte markiert. Man soll das Gleis also nur zum Überholen benutzen nicht zum im Stau stehen.

Hm. Vielleicht beim Weg, der zu dem Weg mit dieser Spur führt für die rechte Spur 'merge' angeben, und bei dem Weg selbst auch auf der rechten Spur 'merge'. Sprich, wenn merge getaggt ist, die Spur dann aber noch da ist und auch merge hat, heisst es, dass es eine Spur nur zum Überholen ist.
Klingt ziemlich kompliziert, oder?
Oder noch n Tag 'nur zum Überholen'.

Es fehlt auch komplett, welcher Verkehrsteilnehmer welche Spur nutzen darf...

things-change wrote:

Hm. Vielleicht beim Weg, der zu dem Weg mit dieser Spur führt für die rechte Spur 'merge' angeben, und bei dem Weg selbst auch auf der rechten Spur 'merge'. Sprich, wenn merge getaggt ist, die Spur dann aber noch da ist und auch merge hat, heisst es, dass es eine Spur nur zum Überholen ist.
Klingt ziemlich kompliziert, oder?
Oder noch n Tag 'nur zum Überholen'.

Es fehlt auch komplett, welcher Verkehrsteilnehmer welche Spur nutzen darf...

Stimmt die Straßenbahn wird sich nicht rechts einordnen. Aber alle anderen Verkehrsteilnehmer (die auf der Straße unterwegs sein dürfen) dürften schon dort fahren.

Das war nicht auf die Strasse bezogen. Gibt ja auch Strassen, wo LKW nur die rechte Spur benutzen dürfen.

Wie solls denn jetzt weitergehen? Das Proposal wird niedergestimmt, und das wars erstmal mit lanes? BTW, wie ist das eigentlich bei so nem Proposal, wie muss die Abstimmung ausgehen, damits durchkommt? Auf der deuschen Wiki-Seite steht da nix drüber...

Ich denke, Spurentagging MUSS kommen. Die Frage ist nur das wie. Vielleicht sollte man versuchen, hier auf einen Konsens zu kommen, um dann nochmal was zu starten.

Man sollte vielleicht nochmal einen Schritt zurückgehen, und sich nicht in irgendwelchen Tag-Bezeichnungen verlieren.
-Was soll Spurtagging darstellen bzw. wer soll einen Nutzen davon haben?
-Soll es nur Abbiegeregeln beschreiben? Oder auch die Nutzung? Also PKW, LKW, auch Strassenbahn fällt unter Verkehrsteilnehmer. Die Gleise wiederrum... Gehören Gleise in das gleiche Tag wie Linksabbiegen? Oder in ein (evt.) weiteres Tag, das halt die Nutzung beschreibt? Oder vielleicht sogar in surface?
-Soll so etwas nur die Motorvehikel-Spuren beschreiben, oder auch Fuß- und Radwege?
-Wie könnte ein leicht zu verstehendes Tagging-Schema aussehen?
-Wie 'verbindet' man einzelne Spuren von Start- und Zielstrasse?
-Wie muss es aussehen, damit es für einen Router verwertbar ist?
-Wie sehen denn die Daten der 'Profis' aus, mit denen Spurassistenten möglich sind?
...

Vielleicht führt das ja noch mal zu einer Diskussion, oder wir leben halt weiter ohne Spuren...

Kraftfahrzeuge + Radwege: ja
Fußwege: eher nein (bei Fußwegen gibt es selten Abbiegespuren oder ähnliches)
Bus-Spuren usw wieder ja

Hier eine erste (noch sehr unreife) Idee für ein Mapping anhand einer spiegelsym. Straße.

lanes:backward=4
lanes:forward=4
lanes:single=nynn;nnyn
lanes:bicycle=nynn;nnyn
lanes:bus=... + lanes:tram=...
lanes:straight=nyyy;yyyn
lanes:turnleft=nnny;ynnn
lanes:turnright=yynn;nnyy
lanes:maxspeed=30,30,50,30;30,50,30,30
lanes:width=2.8,1.2,2.8,2.8;2.8,2.8,1.2,2.8
u.s.w.

Wenn ich's jetzt erklären muss, ist es bereits zu kompliziert.
Das Schema muss von jedem verstanden werden,
ohne stundenlang die Wiki-Seite studieren zu müssen.

Walter

Von mir aus soll das alles elends kompliziert gemacht werden, ist an und für sich kein Problem. Aber im Endeffekt muss es eine optische Visualisierung in JOSM werden, dann wirds auch genutzt. Spuren kann man per Drag&Drop anordnen und dann LKW-Verbote taggen, Busspuren, Fahrradspuren machen o.ä. und alles optisch sichtbar. Sowas händisch einzugeben wird keine ausreichende Menge an Leuten kapieren oder auf der anderen Seite die Taggingmöglichkeiten stark begrenzen und Fehler geradezu provozieren. Die erste Version wird aber nicht perfekt werden, was auch wieder klar ist und man sollte nicht alles wegen jeder Rollerspur aufhalten.

Zusatzfrage: Brauchen wir noch eine Kennzeichnung für Links-/Rechtsverkehr?
z.B. drive_on=left bzw. drive_on=right
oder ist das über das Land bereits implizit definiert.

Walter

@monotar: Sehe ich ähnlich. Daher sollte man es evtl. so taggen (lassen), dass eine Auswertung einfach ist.

@Walter: gefällt mir ganz gut, is evtl. auch besser als meins, wenn man es mit einer GUI mappt. drive_on=left|right braucht man nicht, dass ergibt sich aus den Grenzen und den darin geltenden Gesetzen.

Walter Schlögl wrote:

Hier eine erste (noch sehr unreife) Idee für ein Mapping anhand einer spiegelsym. Straße.

lanes:backward=4
lanes:forward=4
lanes:single=nynn;nnyn
lanes:bicycle=nynn;nnyn
lanes:bus=... + lanes:tram=...
lanes:straight=nyyy;yyyn
lanes:turnleft=nnny;ynnn
lanes:turnright=yynn;nnyy
lanes:maxspeed=30,30,50,30;30,50,30,30
lanes:width=2.8,1.2,2.8,2.8;2.8,2.8,1.2,2.8
u.s.w.

Wow, das hat mich gerade richtig überrascht. Da dachte ich, ich wäre in den gut 3 Jahren Diskussion zu Spurmapping schon allen denkbaren Konzepten mal begegnet. Aber so eins hatten wir wohl noch nicht.

Wenn ich so darüber nachdenke, vermeidet der Vorschlag wirklich die Probleme der Alternativen:

• Man kann den einzelnen Spuren theoretisch beliebige Tags verpassen.
• Die Anzahl der Schüssel ist fix.
• Man braucht keine Relationen.
• Die Menge der Tags pro Weg ist erträglich.

Die einzige ungelöste Herausforderung, die mir bei dem Vorschlag momentan einfällt, ist der Übergang der Spuren von einem Wegstück aufs nächste. Trotzdem, in diese Richtung sollte man mal weiterdenken!

Und ja, ein wenig hässlich ist es schon - aber es könnte glatt die am wenigsten hässliche Umsetzung von Spuren als Attribute sein, die ich bisher gesehen habe. 🙂

monotar wrote:

Von mir aus soll das alles elends kompliziert gemacht werden, ist an und für sich kein Problem. Aber im Endeffekt muss es eine optische Visualisierung in JOSM werden, dann wirds auch genutzt.

In eine GUI verpacken geht immer, solange das Datenmodell die Informationen prinzipiell aufnehmen kann. Für Walters Vorschlag ein JOSM-Plugin zu schreiben wäre z.B. ziemlich einfach.

Walter Schlögl wrote:

Hier eine erste (noch sehr unreife) Idee für ein Mapping anhand einer spiegelsym. Straße.
lanes:backward=4
lanes:forward=4
lanes:single=nynn;nnyn
lanes:bicycle=nynn;nnyn
lanes:bus=... + lanes:tram=...
lanes:straight=nyyy;yyyn
lanes:turnleft=nnny;ynnn
lanes:turnright=yynn;nnyy
lanes:maxspeed=30,30,50,30;30,50,30,30
lanes:width=2.8,1.2,2.8,2.8;2.8,2.8,1.2,2.8
u.s.w.

Hallo Walter

Gute Arbeit, die meisten Fälle können so abgedeckt werden.

Zwei Bemerkingen von mir dazu:
- Die Zahl der Spuren ist auf zwei Taggs verteilt.
Warum nicht als ein Tagg lanes:direction=4;4
- Verwende nicht das Strichkomma zum Trennen der Richtungen.
Das wird meist für die Trennung von Werten genutzt und ist
entsprechend unbeliebt. Mein Vorschlag wäre der senkrechte
Strich, da der Doppelpunkt ja auch bereits belegt ist.

(Edit) Beides sind Kleinigkeiten, die den Wert der Idee nicht schmälern. (/Edit)

Walter Schlögl wrote:

Wenn ich's jetzt erklären muss, ist es bereits zu kompliziert.
Das Schema muss von jedem verstanden werden,
ohne stundenlang die Wiki-Seite studieren zu müssen.

Für die meisten, die sich mit dem Thema mal beschäftigt haben und sei es nur durch das Lesen dieses Threads, wird das weitgehend selbsterklärend sein. Auch insofern: Gute Arbeit

Edbert (EvanE)

Walter Schlögl wrote:

lanes:backward=4
lanes:forward=4
lanes:single=nynn;nnyn
lanes:bicycle=nynn;nnyn
lanes:bus=... + lanes:tram=...
lanes:straight=nyyy;yyyn
lanes:turnleft=nnny;ynnn
lanes:turnright=yynn;nnyy
lanes:maxspeed=30,30,50,30;30,50,30,30
lanes:width=2.8,1.2,2.8,2.8;2.8,2.8,1.2,2.8
u.s.w.

Rein von der Konsequenz her, muessten bei den yes/no Werten auch jeweils ein Komma dazwischen, dann könnte man sich auch das Abkuerzen sparen.

Was bei diesem Ansatz verloren geht, ist der schnelle Blick, welche Informationen denn nun eigentlich fuer eine bestimmte Spur gelten. Das muss man sich muehsam aus den einzelnen Werten raussuchen, entsprechend fehleranfaellig koennte das Schema dann auch sein. (Wenn ein Komma vergessen oder versehentlich geloescht wird, sind gleich alle Spuren betroffen, da die Zuordnung verlorengegangen ist.)
Auf der anderen Seite wird sowas aber auch keiner mehr von Hand editieren wollen, insofern ist dieser Nachteil vielleicht gar nicht mal so entscheident. (Aber was macht ein Editor, wenn die Anzahl der Werte nicht bei allen Tags gleich ist?)

Was ein Spurmappingschema auch braucht, ist die Information, wie von einer Spur zur nächsten gewechselt werden kann und wie die Trennung zwischen den Spuren aussieht. Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden. In meiner Region gibt es Mapper, die bei jeder Kleinigkeit (z.B. Verkehrsinsel) gleich die Strassen aufspalten. Das ist zwar im Prinzip nicht falsch, sorgt aber dafuer, dass die automatisch generierten Routingansagen kommplett unbrauchbar werden.

Fuers Routing muss der Routing-Graph erstmal so einfach wie moeglich gehalten werden, fuer einen Renderer gelten da leider andere Anforderungen. Vielleicht muss man da dann ueberlegen, ob es ueberhaupt sinnvoll ist, fuer beide Zwecke gemeinsam erfassen zu wollen.

Gruss
Torsten

Walter Schlögl wrote:

...
lanes:backward=4
lanes:forward=4
...

Ich halte -wie oben schon mal erwähnt - gar nichts von forward/backward. Das bezieht sich nicht auf die Realität draußen, sondern nur auf die Abbildung in OSM und zu schnell ist so eine Weg mal versehentlich gedreht 🙄
Die wichtige Masse der in Frage kommenden Fälle für Spurtagging fällt auf motorways und trunks an, wo die gegenläufigen Fahrtrichtungen sowieso getrennt als oneway angelegt sind. In diesen Fällen erübricht sich auch eine Lösung für Rechts- oder Linksverkehr.
Auch wichtige Durchgangsstraßen innerorts haben in der Regel eine räumliche Trennung. Auf Kraftfahrstraßen ist das Wenden gemäß §18 StVO unabhängig von der Trennlinien nicht erlaubt, weshalb hier eigentlich die Fahrtrichtungen auch als einzelne Ways anzulegen wären.

Bleiben fast nur noch innerörtliche Straßen mit Abbiegespuren ohne doppelte Linie aber meist einer Linie zwischen den Fahrtrichtungen. Was spricht eigentlich dagegen, diese auch für die hier in Frage kommenden Fälle auch je Richtung als way anzulegen?

Den Einwand von de_muur "Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden." verstehe ich nicht, da mir Erfahrungswerte fehlen.

Ich gebe dir recht, dass es wohl primär an geteilten Fahrbahnen getaggt werden wird. Aber eben nicht nur. Das drehen von Wegen sehe ich nicht als gravierend an. Editoren können das erkennen und eine Warnung ausgeben.
Was mir bei Walter noch fehlt, ist eine Zuordnung zwischen linker und rechter Seite zu forward und backward. Ebenso fehlt noch eine Darstellung für Einrichtungswege. Und was mir sehr wichtig ist, dass lanes:surface nicht surface ersetzt (etc.). Ein Auswerter soll sich mit dem komplizierten Spurzeug nicht auseinandersetzen müssen, wenn es ihn nicht interessiert.

hurdygurdyman wrote:

Den Einwand von de_muur "Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden." verstehe ich nicht, da mir Erfahrungswerte fehlen.

Router basteln sich aus den Daten einen Routinggraph für eine Straße, der alle Infos enthalten sollte. Daraus kann er dann das Gewicht des Weges ermitteln. Gliedert man Wege zu weit auf, gehen manche Infos unweigerlich verloren, wenn man sie nicht doppelt einträgt. Ebenso verkompliziert sich der Routinggraph natürlich ordentlich.

hurdygurdyman wrote:

Bleiben fast nur noch innerörtliche Straßen mit Abbiegespuren ohne doppelte Linie aber meist einer Linie zwischen den Fahrtrichtungen. Was spricht eigentlich dagegen, diese auch für die hier in Frage kommenden Fälle auch je Richtung als way anzulegen?

Den Einwand von de_muur "Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden." verstehe ich nicht, da mir Erfahrungswerte fehlen.

Nehmen wir mal eine kleine Nebenstrasse, die auf eine Durchgangsstrasse führt. Am Ende hat die Nebenstrasse eine Rechtsabbiegerspur. Dann müsste ich ja ab dem Beginn der Abbiegespur die Fahrtrichtungen aufteilen, um dann für dei Forwardspur geradeaus und rechts zu taggen.

In einer kleiner Zoomstufe, die keine Lanes darstellt würde es dann wohl so aussehen, als hätten wir die Geradeausspuren und eine abzweigende Rechtsabbiegerspur, in Wahrheit ist in dem Abzweig auch die forward Geradeausspur.

hurdygurdyman wrote:

Den Einwand von de_muur "Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden." verstehe ich nicht, da mir Erfahrungswerte fehlen.

Beim Routing kommt es ja nicht nur darauf an, dass eine moeglichst gute Strecke gefunden wird, sondern es geht ja auch darum, durch (automatisch generierte) Ansagen jemanden entlang dieser Strecke zu leiten.

Bei einer einfach erfassten Kreuzung (zwei Strassen kreuzen sich) hat man im Routinggraph einen Knoten, an dem vier Kanten aneinander stossen. Da ist es fuer den Router dann nicht all zu schwer, auf Grund der Geometrie der Kannten zu entscheiden, ob ueberhaupt eine Ansage notwendig ist und wie diese dann zu lauten hat.
Wenn man aber die gleiche Kreuzungen mit getrennten Fahr- und Abbiegespuren erfasst hat, dann hat es der Router mit einer Vielzahl von Knotenpunkten zu tun mit wesentlich komplexeren Geometrien (wobei auch noch die Winkelverhaeltnisse von einzeln erfassten Spuren deutlich ausgepraegter sind, als was man in der Wirklichkeit vorfindet). Da kommt dann ganz schnell nur noch Quark raus, so dass man je nach Router entweder mit unsinnigen Kommandos zugemuellt wird oder wichtige Kommandos nicht mehr generiert werden.

Gruss
Torsten

Walter Schlögl wrote:

lanes:backward=4
lanes:forward=4
lanes:single=nynn;nnyn
lanes:bicycle=nynn;nnyn
lanes:bus=... + lanes:tram=...
lanes:straight=nyyy;yyyn
lanes:turnleft=nnny;ynnn
lanes:turnright=yynn;nnyy
lanes:maxspeed=30,30,50,30;30,50,30,30
lanes:width=2.8,1.2,2.8,2.8;2.8,2.8,1.2,2.8
u.s.w.

Walter

Um so öfter ichs mir anschaue, umso besser gefällts mir.

Hat man keine Strassenbahn, kommt sie nicht vor. ansonsten

lanes:tram=ynnn

Und das mit den Abbegespuren mal weitergedacht: Hab ich eine vielspurige Strasse, ist sie oft eh für die Fahrtrichtungen getrennt getaggt. Dann einfach:

lanes:forward=4
lanes:straight=yyyy
...

Die Nebenstrasse mit Abbieger hat insgesamt auch selten mehr als 4 lanes. Hier taggt an also beide Fahrtrichtungen.

lanes:backward=1
lanes:forward=2
lanes:straight=y;yn
lanes:right=n;ny

Vorteil:
Es müssen keine Strassen anders eingezeichnet werden als bisher, nur um Spuren zu taggen.
Und beide Fälle bleiben übersichtlich. Leider beissen sich jetzt noch die beiden tagging-Schemen für lanes:forward EDIT: lanes:straight, aber da lässt sich bestimmt ne Lösung finden.

Dann noch defaults, um so wenig wie möglich taggen zu müssen.
Z.B. an 3-spurigen Strassen sind alle geradeaus, vor Kreuzungen die rechte auch rechts.

de_muur wrote:

Wenn man aber die gleiche Kreuzungen mit getrennten Fahr- und Abbiegespuren erfasst hat, dann hat es der Router mit einer Vielzahl von Knotenpunkten zu tun mit wesentlich komplexeren Geometrien (wobei auch noch die Winkelverhaeltnisse von einzeln erfassten Spuren deutlich ausgepraegter sind, als was man in der Wirklichkeit vorfindet). Da kommt dann ganz schnell nur noch Quark raus, so dass man je nach Router entweder mit unsinnigen Kommandos zugemuellt wird oder wichtige Kommandos nicht mehr generiert werden.

Wir taggen zwar nicht für Garmin, aber dort kommt hinzu, dass das Garmin-Format nur eine begrenzte
Auflösung hat und somit bei einer engen Punktfolge eine gezackte Linie heraus kommt:

Der Garmin-Routing Algorithmus sieht eine Penalty für spitze Abbiegungen vor, er bevorzugt also
Routen mit wenigen Biegungen.

Chris

@aiges, things-change, de_muur:
danke für die Informationen. Die routing-Geschichte kenne ich bisher nur als Anwender. Aber ich bin lernwillig und werde auf Basis eurer Aussagen mal in mich gehen, erst mal nachdenken und dann meinen frischen Mist dazu hier ausschütten 🙂

Walter Schlögl wrote:

lanes:single=nynn;nnyn

Wenn ich's jetzt erklären muss, ist es bereits zu kompliziert.
Walter

Bis auf das lanes:single ist es eigentlich sehr einleuchtend, ich vermute, dass das mit durchgezogener / gestrichelter Linie zu tun hat? Ist damit auch überholen / nicht überholen und einseitige Fahrstreifenbegrenzung abgedeckt?

de_muur wrote:

Was ein Spurmappingschema auch braucht, ist die Information, wie von einer Spur zur nächsten gewechselt werden kann und wie die Trennung zwischen den Spuren aussieht. Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden. In meiner Region gibt es Mapper, die bei jeder Kleinigkeit (z.B. Verkehrsinsel) gleich die Strassen aufspalten. Das ist zwar im Prinzip nicht falsch, sorgt aber dafuer, dass die automatisch generierten Routingansagen kommplett unbrauchbar werden.

Der Logik des Taggingschemas müssten Spurtrennungen und -markierungen so getaggt werden: (natürlich auf englisch, aber da bin ich dann doch überfordert 🙂 )

lanes:trennungen=Bordsteinkante, durchgezogene Linie, Verkehrsinsel, gestrichelte Linie, Bordsteinkante

Wobei hier zwangsläufig ein tag mehr als Anzahl der Spuren vorhanden ist, und durchgezogene Linien und Inseln usw. Spurwechselverbote implizieren sollten.
EDIT: Vielleicht sogar besser ohne Bordstein, sprich ein tag weniger als Anzahl der Spuren.

Hallo Henning, eine Zuordnung zwischen backward und forward ist implizit gegeben,
da je nach Land bekannt ist, auf welcher Seite gefahren wird,
und die Spuren immer von links nach rechts bezeichnet werden (in Pfeilrichtung des Weges).

Hallo GeoCounter, mit lanes:single sind (einpurige) Radstreifen gemeint, also Spuren, die für's Auto-Routing nicht zur Verfügung stehen.

Hallo Torsten, die Trennung zwischen den Spuren könnte doch genau mit den von dir vorgeschlagenen Trennzeichen erfolgen.
Kein Trennzeichen bedeutet, Spurwechsel möglich, Komma bedeutet, Spurwechsel nicht möglich, und für Spurwechsel in nur einer Richtung
müssen wir uns noch etwas einfallen lassen (z.B. < und > ) also für 4 Spuren dann z.B. y,yy<y
Für die Kante und die Insel könnte man sich ja noch ein Symbol ausdenken, wenn es wirklich notwendig erscheint.
Für's reine Routing ist es eigentlich egal, ob ich die Spur wegen einer Sperrlinie, Kante oder Insel nicht wechseln kann.

Hallo Tordanik, der Übergang von einem Wegstück aufs nächste ist wohl noch eine wichtige Frage.
Was hältst du davon, am Übergang einen Punkt zu setzen, und in diesem zu beschreiben, welche Spuren enden und welche neuen entstehen.

i .. Spur geht weiter
x .. Spur endet
v .. Spur spaltet sich auf (neue Spur entsteht)

Beispiel: eine 4-spurige Straße, bei der die linke Spur endet und rechts eine neue Spur entsteht: lanes:merge=xiiv
Hier muss man aber verdammt aufpassen, dass man die backward-Richtung korrekt erfasst. (schade, dass wir kein Lambda-Zeichen haben)

Irgendwer hat noch geschrieben, dass man die beiden Richtungen besser getrennt erfassen sollte.
Das kann ich natürlich unterschreiben, da dann weniger Fehler passieren. Trotzdem sollte das Schema aber beides beherrschen.

Walter

Walter Schlögl wrote:

Hallo Tordanik, der Übergang von einem Wegstück aufs nächste ist wohl noch eine wichtige Frage.
Was hältst du davon, am Übergang einen Punkt zu setzen, und in diesem zu beschreiben, welche Spuren enden und welche neuen entstehen.

i .. Spur geht weiter
x .. Spur endet
v .. Spur spaltet sich auf (neue Spur entsteht)

Beispiel: eine 4-spurige Straße, bei der die linke Spur endet und rechts eine neue Spur entsteht: lanes:merge=xiiv
Hier muss man aber verdammt aufpassen, dass man die backward-Richtung korrekt erfasst. (schade, dass wir kein Lambda-Zeichen haben)

Walter

Hier fehlt aber die Information, mit welcher Spur die Endene verschmilzt bzw. ob sie sich nach links oder rechts aufteilt. Wie wärs mit:

lanes:merge=/|,|,|,|/

Wenn Abkürzungen und Sonderzeichen vermieden werden sollen, dann halt:

lanes:merge=merge_to_right, no, no, split_to_right

things-change wrote:

Walter Schlögl wrote:

Hallo Tordanik, der Übergang von einem Wegstück aufs nächste ist wohl noch eine wichtige Frage.
Was hältst du davon, am Übergang einen Punkt zu setzen, und in diesem zu beschreiben, welche Spuren enden und welche neuen entstehen.

i .. Spur geht weiter
x .. Spur endet
v .. Spur spaltet sich auf (neue Spur entsteht)

Beispiel: eine 4-spurige Straße, bei der die linke Spur endet und rechts eine neue Spur entsteht: lanes:merge=xiiv
Hier muss man aber verdammt aufpassen, dass man die backward-Richtung korrekt erfasst. (schade, dass wir kein Lambda-Zeichen haben)

Walter

Hier fehlt aber die Information, mit welcher Spur die Endene verschmilzt bzw. ob sie sich nach links oder rechts aufteilt. Wie wärs mit:

lanes:merge=/|,|,|,|/

Wenn Abkürzungen und Sonderzeichen vermieden werden sollen, dann halt:

lanes:merge=merge_to_right, no, no, split_to_right

Naja und jetzt bin ich einfach mal fies. Wie machst du dort den Spurwechsel der Straßenbahn? Wenn die pkw Spuren geradeaus gehen aber die Straßenbahn nach rechts oder links rückt?

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.

Walter Schlögl wrote:

lanes:backward=4
lanes:forward=4
lanes:single=nynn;nnyn
lanes:bicycle=nynn;nnyn
lanes:bus=... + lanes:tram=...
lanes:straight=nyyy;yyyn
lanes:turnleft=nnny;ynnn
lanes:turnright=yynn;nnyy
lanes:maxspeed=30,30,50,30;30,50,30,30
lanes:width=2.8,1.2,2.8,2.8;2.8,2.8,1.2,2.8

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/Prop … s/Lanes_ex abgeleitet, aber viel ist davon nicht mehr über.

lanes=<Spuren von links nach rechts, jeweils mit mind. 1 Trenner dazwischen>
<spur>=<spurwert> ["+" <spurwert> ...]
<spurwert>= 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.)
<trenner>= 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
<grass> ... 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>
<spur> = [<waynr>]["." <lanenr> ["+" <lanenr> ...]]
<waynr> ... 0=umkehren, 1=linkester Anschlussway, 2=zweitlinkester usw., Default ist 1
<lanenr> ... 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,SL<hedge>sl,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.

fkv wrote:

- Es soll Routing in allen Fällen und für alle Verkehrsteilnehmer funktionieren. (Außer Fußgänger, die klammere ich mal aus.)

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

fkv wrote:

ad 2:
lane_matching=<Spuren von links nach rechts, durch je 1 Komma getrennt>
<spur> = [<waynr>]["." <lanenr> ["+" <lanenr> ...]]
<waynr> ... 0=umkehren, 1=linkester Anschlussway, 2=zweitlinkester usw., Default ist 1
<lanenr> ... 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,SL<hedge>sl,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).
...

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.

de_muur wrote:

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.

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.

things-change wrote:

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.

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.

fkv wrote:

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.

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

fkv wrote:

In den USA gibt es angeblich Abbiegespuren, die in beiden Fahrtrichtungen befahren werden dürfen.

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

Geogast wrote:

fkv wrote:

In den USA gibt es angeblich Abbiegespuren, die in beiden Fahrtrichtungen befahren werden dürfen.

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

GeoCounter wrote:

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

viw wrote:

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.

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.

GeoCounter wrote:

Es wäre schön, wenn auch der Seitenstreifen berücksichtigt werden könnte

Was ist das genau?

de_muur wrote:

faellt mir da spontan auch noch ein Parkstreifen ein.

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

Walter Schlögl wrote:

Ich würde vorschlagen, alle Anforderungen einmal aufzulisten.
[...]
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, .....
  

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.

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.

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

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.

Bin zwar kein Programmierer eines Renderers, aber Programmierer. Nein, keine Probleme zu erwarten. Sogar ausgefallene Zeichen wie ↔, ↕, ↖, ↗, ↘, ↙ 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.

things-change wrote:

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

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

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.

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.

things-change wrote:

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.

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.

viw wrote:

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.

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.

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

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

Denk bitte auch einen Schritt weiter.

-- Darstellung in den Karten
-- Integration in JOSM und anderen Editorn
-- Wie können GPS-Geräte von den Daten profitiern
-- Kontakt zu den Autoren von zB MKGMAP bzgl. Umsetzung.

Die schönsten Ideen nutzen sonst leider sehr wenig.

Flacus wrote:

Denk bitte auch einen Schritt weiter.

-- Darstellung in den Karten
-- Integration in JOSM und anderen Editorn
-- Wie können GPS-Geräte von den Daten profitiern
-- Kontakt zu den Autoren von zB MKGMAP bzgl. Umsetzung.

Die schönsten Ideen nutzen sonst leider sehr wenig.

Du hast das sehr schön geschrieben. Aber Umsetzung in der Karte ist gar nicht gewünscht. Sonst könnte man die Spuren ja auch malen und müsste nicht so einen Haufen Tags erfinden.
Integration in Josm ist kein Problem. Dafür gibts ja die Vorlagen. Vielleicht macht das später jemand noch grafisch.
GPS Geräte könnten aus den Daten den Spurassitenten erstellen. Das erfordert aber eine Anpassung der Software nicht des Taggings.
Ich denke MKGMAP entwickelt sich recht schnell, so denn nur bekannt ist wie Garmin das speichert. Inzwischen wurde sogar eine Lösung für den Adressindex gefunden. Also hier ist eher die Vorstufe zu wissen in welcher Art braucht Garmin das Zeugs, nicht wie müssen wir MKGAM füttern.

things-change wrote:

lanes=s,s,s[7-18:30]+P[18:30-7] versteht kein Mensch auf den ersten Blick.

Die Ührzeiten sind ein Ausnahmefall, die kommen normal nicht vor und dann ist es einfacher zu verstehen.

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.

So, welchen? De_muur hat sie sich ins Schema gewünscht, und da sind sie. Ich denke, sie gehören wirklich rein, da sie für grafische Darstellungen nützilch sind.

Natürlich kann man sie aus dem Schema raus halten und einiges andere auch. Aber dann kommt man später drauf, dass man dies und das doch braucht, und so muss man andauernd nachbessern.

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.

Die eigenen Tags für straßenbegleitende Fuß- und Radwege, also v.a. cycleway=*, sind dann halt Altlasten, die aus Kompatibitätsgründen noch eine Weile mitgeschleppt werden müssen. Das lässt sich nicht verhindern. Diese Tags lassen sich nicht vernünftig "aufpäppeln", das fängt schon damit an, dass nicht definiert ist, in welcher Abfolge die Radwege, Fußwege, Leitschienen usw. nebeneinander liegen.

de_muur wrote:

Schreib den Scheiss aus, von den Abkuerzungen hat niemand etwas.

Von Tagwerten, wo man im Eingabefeld herumscrollen muss, hat auch keiner was. Und das auf unzählige verschiedene Tags aufzuteilen ist auch nicht besser. Die Abkürzungen muss man zwar beim ersten Mal nachschlagen, aber von da an sind sie viel übersichtlicher als lange Würste. Ich denke, dass die Regel Großbuchstabe=Gegenverkehr leicht zu merken ist.

Tordanik wrote:

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.

In diesem Fall geht es aber um die Spurendefinition und da sind Zeitabhängigkeiten etwas ganz Wesentliches. In diesem Thread haben wir herausgefunden, dass wir das brauchen, also wieso sollen wir diese Erkenntnis jetzt nicht nutzen? Wenn wir die Lösung auf die lange Bank schieben, wird sie auch nicht einfacher werden. Von selbst hat sich noch nie etwas gelöst.

Ich hab die Lösung vorgeschlagen, die ich für die praktikabelste halte. Andere (wie lanes:opening_hours=* oder lanes:<nr>:opening_hours=*) haben auch ihre Nachteile. Da können wir drüber diskutieren.

lane_separators = guard_rail , dashed , continuous , dased , guard_rail

Ich finde das fehleranfälliger als die gemeinsame Definition mit den Spuren, da man sich leicht um eine Stelle vertun kann. Außerdem ist das ziemlich viel Schreibarbeit. Du hast dich in deinem Beispiel selber vertippt ("dased"), also was meinst du, was für eine Datenqualität dann im Echtbetrieb rauskommt?

Walter Schlögl wrote:

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's eine Tabelle wird, dann vielleicht besser auf einer Wiki-Seite. Bin gern dabei.

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.

Wobei einige hier geäußerte Kriterien (Einfachkeit, Verständlichkeit, Fehleranfälligkeit) schwer messbar sein werden.

Weiter gehts mit dem lustigen Brainstorming zum Thema Spurmapping (aus der Mailing-List):

Stefan wrote:

Moin,

ich habe mal eine Idee zum Einzelspurmapping ausprobiert:

Alle bisherigen highways bleiben erhalten. Die Straßensegmente, für die
eine Einzelspurdarstellung existiert, erhalten zusätzlich das Tag
detail_exists=yes .

Fahrspuren werden einzeln als way mit "detail=lane" erfasst. Sie können
sich aufspalten oder zusammenlaufen, kreuzen sich aber ohne gemeinsamen
Punkt. Abbiegespuren oder Geradeausspuren mit Fahrbahnpfeil erhalten ein Zusatztag (lane=right_turn, lane=straight_on etc.)

Ways mit "detail=lane_change" etwa senkrecht zur Fahrtrichtung beschreiben mögliche Spurwechsel. Sie sind mindestens am Beginn einer
Abbiegespur, an der letzten Wechselmöglichkeit vor einer Verzweigung
(oft die Haltelinie einer Kreuzung), an ersten und letzten Wechselpunkt einer Beschleunigungsspur und dem Übergang vom highway ohne Einzelspur zum way mit "detail=lane" nötig.

Ampeln und Stopschilder werden als Punkt auf den Einzelspuren erfasst.

Zum Test habe ich zwei Stellen mit diesem Schema erstellt:
[1]: eine einfache Einmündung mit Abbiegespuren
[2]: eine große Kreuzung mit komplexem Spurverlauf

Wer Interesse hat, kann sich die Ausschnitte in seinen Lieblingseditor
laden und dort ansehen. Bitte nichts verändern!

Solch ein Modell hat verschiedene Vor- und Nachteile:

+Das Konzept ist kompatibel zu bisherigen Daten und Anwendungen
+Die Regeln sind leicht erlernbar und mit jedem Editor umsetzbar
+Es sind keine zusätzlichen Relationen nötig
+Der Verlauf von Abbiegespuren auf komplexen Kreuzungen ist
geometrisch richtig darstellbar
+Ampeln und Stopschilder, die vor der Kreuzung stehen, lassen sich
korrekt einer Fahrtrichtung zuordnen
+Beschränkungen für einzelne Fahrspuren sind einfach möglich
(Busspur, maxspeed nur für Abbieger, etc.)
+Aus dem Modell lassen sich je nach Anforderung und Zoomlevel
verschiedene Kartendarstellungen erzeugen:
* nur highway (wie bisher)
* Hybriddarstellung mit mit Einzelspuren als Underlay oder Overlay
* nur als Detailkarte
+Ein Fahrspurassistent ist damit einfach möglich. Ein einfacher
Routingalgorithmus muss nur auf ways mit detail=lane und
detail=lane_change arbeiten und highways mit detail_exists=yes
ignorieren

- Die Doppelerfassung von Straßen als Grob- und Detailstruktur passt
nicht zum üblichen OSM-Schema
- Für Einzelspurerfassung sind gute Luftbilder nötig
- Für längere Strecken ist das Modell zu aufwändig, Zusatztags am
highway sind dort besser

Das Modell ist nur grob formuliert, für Sonderfälle (Kreisverkehr, Richtungspfeil halb-rechts, etc.) sind Erweiterungen nötig. Die Tagnamen
sind spontan ausgedacht und nicht ausgereift. Eine Nummerierung der
Abbiegespuren ("left_1/2", "left_2/2", ...) fehlt noch.

Ich sehe dies nur als Konzeptstudie, um die Einzelspurerfassung als
way zu diskutieren. Vielleicht haben einige Interesse sich das Konzept
anzusehen und es weiterzuentwickeln.

Viele Grüße
Stephan

[1] http://osm.org/go/0HsYpFYlR--
[2] http://osm.org/go/0HsPVeHXn-

Edit: http://news.gmane.org/find-root.php?gro … icle=91206

chris66 wrote:

Weiter gehts mit dem lustigen Brainstorming zum Thema Spurmapping (aus der Mailing-List):

Hast du einen Link zum Archiv der Maillist?!

Walter Schlögl wrote:

Bevor aus diesen Ideen hier das nächste Proposal entsteht würde ich vorschlagen, die verschiedenen Ansätze in einer Tabelle zusammenzufassen.

Etwa wie hier?
http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

fkv wrote:

In diesem Fall geht es aber um die Spurendefinition und da sind Zeitabhängigkeiten etwas ganz Wesentliches. In diesem Thread haben wir herausgefunden, dass wir das brauchen, also wieso sollen wir diese Erkenntnis jetzt nicht nutzen? Wenn wir die Lösung auf die lange Bank schieben, wird sie auch nicht einfacher werden. Von selbst hat sich noch nie etwas gelöst.

Warum sollten wir die Erkenntnis jetzt nicht nutzen? Weil wir dann ein Zwanzig-Seiten-Proposal bekommen. Wahrscheinliche Resultate: Während wir noch über die Details diskutieren, hat sich ein Proposal mit weniger Weitblick schon als Standard etabliert und unsere Ideen sind für die Tonne. Oder falls wir unser Rundum-Sorglos-Paket wider Erwarten halbwegs zügig fertig bekommen: Kein Mensch liest es, die Leute setzen ihr "I oppose this proposal. Too complex!" darunter und vergessen die Idee wieder.

Die Lösung wird nicht einfacher, wenn wir sie auf die lange Bank schieben. Wenn das Basis-Proposal entsprechend gestaltet ist, wird sie aber auch nicht schwerer. Und je eher man vorzeigbare Zwischenresultate hat, desto besser.

Ich finde das fehleranfälliger als die gemeinsame Definition mit den Spuren, da man sich leicht um eine Stelle vertun kann. Außerdem ist das ziemlich viel Schreibarbeit. Du hast dich in deinem Beispiel selber vertippt ("dased"), also was meinst du, was für eine Datenqualität dann im Echtbetrieb rauskommt?

Siehst du: Du konntest erkennen, dass ich mich vertippt habe, und könntest es jetzt problemlos korrigieren.

Könntest du ohne Ortskenntnis wissen, dass ich versehentlich statt einem Groß- einen Kleinbuchstaben getippt habe? Ich denke mal nicht.

Hallo Tordanik,

ich denke, auf der Basis von deiner comparison Seite kommen wir rascher weiter, da man die verschiedenen Alternativen optimal vergleichen kann.
Es gilt nun auch abzustimmen, was wir erfassen wollen und was nicht, damit sich die Komplexität erkennen und auch entsprechend begrenzen lässt.

Walter

Tordanik wrote:

Walter Schlögl wrote:

Bevor aus diesen Ideen hier das nächste Proposal entsteht würde ich vorschlagen, die verschiedenen Ansätze in einer Tabelle zusammenzufassen.

Etwa wie hier?
http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

Ja, so in der Art. Aber die Beispiele sind unglücklich gewählt. Im 2.Bsp. sieht man nicht, wie die Spuren in den Anschlusstraßen weitergehen; und im unteren Bildteil steht was auf den roten Spuren, das ich nicht lesen kann. Im 1. Bsp. sieht man überhaupt nur eine Tafel. Im 3. Bsp. ist unklar, welcher Bereich gemeint ist.

Warum sollten wir die Erkenntnis jetzt nicht nutzen? Weil wir dann ein Zwanzig-Seiten-Proposal bekommen.

Na, so lang ist das nicht. Höchstens die Beispiele. Vielleicht sollte man die dann auf eine extra Seite stellen, damit das Proposal nicht so kompliziert aussieht.

Wahrscheinliche Resultate: Während wir noch über die Details diskutieren, hat sich ein Proposal mit weniger Weitblick schon als Standard etabliert und unsere Ideen sind für die Tonne.

Das ist der Grund, warum ich zum Spurmapping überhaupt meinen Senf abgebe. Einen persönlichen Bedarf hab ich nicht.

Oder falls wir unser Rundum-Sorglos-Paket wider Erwarten halbwegs zügig fertig bekommen: Kein Mensch liest es, die Leute setzen ihr "I oppose this proposal. Too complex!" darunter und vergessen die Idee wieder.

Bestimmt nicht alle. Jedes neue Proposal versucht Unzulänglichkeiten der vorigen Proposals zu lösen. Ich finde auch gar nicht so wichtig, dass ein Proposal angenommen wird. Wichtiger ist, dass die Konzepte bekannt werden.

Einen Bedarf für ein approved proposal sehe ich in den nächsten Jahren sowieso nicht. Weder sind die Anwendungen reif dafür, noch der Datenbestand. Es fehlen noch so viele Straßennamen und Hausnummern, wozu sollen wir und bei so einem löchrigen Erfassungsgrad schon mit Spurmapping das Leben schwer machen. Das bringt einstweilen nur einen Wartungsaufwand und noch keinen Nutzen für Anwender.

Könntest du ohne Ortskenntnis wissen, dass ich versehentlich statt einem Groß- einen Kleinbuchstaben getippt habe? Ich denke mal nicht.

Also gehen wir mal davon aus, dass das Gebiet von Bing&Co noch vernachlässigt wird. In meinem Vorschlag macht der Unterschied die Fahrtrichtung aus (ausg. p und P). Die ist bei dir in einem anderen Tag definiert, und zwar dadurch, ob (bei Rechtsverkehr) die Anzahl verbleibender "|" gerade oder ungerade ist. Das kann ich ohne Ortskenntnis genausowenig überprüfen.

fkv wrote:

Tordanik wrote:

http://wiki.openstreetmap.org/wiki/Lane … comparison

Im 2.Bsp. sieht man nicht, wie die Spuren in den Anschlusstraßen weitergehen; und im unteren Bildteil steht was auf den roten Spuren, das ich nicht lesen kann. Im 1. Bsp. sieht man überhaupt nur eine Tafel. Im 3. Bsp. ist unklar, welcher Bereich gemeint ist.

Beim 3. Beispiel werde ich mit einem eigenen Foto abhelfen, sobald ich dort mal vorbeikomme. Die anderen sind nicht auf meinem Mist gewachsen, sondern aus dem aktuell in der Abstimmung befindlichen "Turn Lanes"-Proposal.

Du kannst gerne bessere Beispiele suchen. Die Tafel hat aber den Zweck, dass man zumindest mal die Grundidee der Proposals versteht, ohne dass man gleich mit schecht erkennbaren Luftbildern oder Detailproblemen kämpft.

Einen Bedarf für ein approved proposal sehe ich in den nächsten Jahren sowieso nicht. Weder sind die Anwendungen reif dafür, noch der Datenbestand. Es fehlen noch so viele Straßennamen und Hausnummern, wozu sollen wir und bei so einem löchrigen Erfassungsgrad schon mit Spurmapping das Leben schwer machen. Das bringt einstweilen nur einen Wartungsaufwand und noch keinen Nutzen für Anwender.

Der Bedarf nach einem Taggingschema, das zumindest klarer Favorit ist, entsteht dadurch, dass der Programmieraufwand für Anwendungen und Editor-Tools hoch ist. Wenn ich mir nicht halbwegs sicher bin, dass ich aufs richtige Pferd setze, stecke ich ungern so viel Arbeit in die Entwicklung.

Das ist nicht wie bei einfacheren Tags, wo man eben im Renderstil bla=blubb durch foo=bar ersetzen muss, sobald es sich die Mapper mal wieder anders überlegen. Wenn ich ein Programm für Spurlisten mit Kommatrennern schreibe und es malen plötzlich alle lieber separate Ways für die Spuren, kann ich meinen bis dahin geschriebenen Programmcode wegschmeißen.

Um eine gewisse Basis zu haben, auf der man aufsetzen kann, braucht man halt ein fertiges, möglichst populäres Kern-Proposal. Welche Attribute es genau für einen Parkstreifen gibt, muss man dazu hingegen nicht wissen.

Könntest du ohne Ortskenntnis wissen, dass ich versehentlich statt einem Groß- einen Kleinbuchstaben getippt habe? Ich denke mal nicht.

Also gehen wir mal davon aus, dass das Gebiet von Bing&Co noch vernachlässigt wird. In meinem Vorschlag macht der Unterschied die Fahrtrichtung aus (ausg. p und P). Die ist bei dir in einem anderen Tag definiert, und zwar dadurch, ob (bei Rechtsverkehr) die Anzahl verbleibender "|" gerade oder ungerade ist. Das kann ich ohne Ortskenntnis genausowenig überprüfen.

Ich halte einen Fehler bei Groß- und Kleinschreibung z.B. für einen sehr wahrscheinlichen Tippfehler, und deshalb ist es problematisch, dass er schwer zu finden ist. Auch andere Fehler sind schwer zu finden, nur denke ich, dass die eben nicht ebenso häufig vorkommen werden. Aber ok, das ist teils Spekulation.

Generell finde ich halt die Lesbarkeit wichtiger als schnelles Schreiben, denn für's Schreiben will man sowieso Editorunterstützung.

Moin,

anstatt einzelner Anmerkungen will ich nun mal sehen, ob aus meinen Vorstellungen zum Thema ein halbwegs geschlossenes Konzept wird. Zum Gorssteil werde ich hier der Einfachheit halber deutsche Begriffe benutzen, mir geht es erstmal um die Struktur und nicht um die Bezeichner.

A) Den Ansatz, die verschiedenen Spuren als Liste zu erfassen, finde ich gar nicht schlecht. Als wichtigstes sollte man da dann erstmal erfassen, was da ueberhaupt ist. Das koennte dann z.B. so aussehen:
lanes=Fussweg;Radweg;Fahrbahn;Fahrbahn;Fahrbahn;Fuss_Und_Radweg
In Richtung des Weges werden von links nach rechts die verschiedenen Verkehrsflaechen erfasst, die zu diesem Weg gehoeren.
Im Unterschied zum bisherigen lanes=x werden hier nicht nur die KFZ-Spuren auf der Fahrbahn erfasst, sondern auch Fuss- und Radwege, Parkstreifen, Standspuren usw.
Detailfragen waeren dann noch, ob man Abbiegespuren anders bezeichnen sollte als normale Fahrspuren (ich denke schon, zumindest bei Beschleunigungsstreifen und Ausfaedelspuren scheint mir das angebracht), und ob Fahrspuren fuer besondere Nutzung (Busspur, Fahrradspur) ein eigenen Namen bekommen sollten, oder ob das durch Access-Tags erfasst werden sollte (ich denke, auch hier macht ein eigener Name die Sache uebersichtlicher).
Als Trennzeichen in der Liste habe ich hier das Semikolon gewaehlt. Das Komma schient mir ungeeignet, da es innerhalb eines Listenelementes gebraucht werden kann, wenn da mehrere Werte aufgezaehlt werden muessen (z.B. Fahrbahn und gleichzeitig Strassenbahn).

B) Alle weiteren Eigenschaften werden dann ueber lanes:Bezeichner erfasst. Das koennen einmal die ganz normalen Bezeichner sein, die auch jetzt schon fuer Highways definiert sind (surface, access, maxspeed usw.) oder aber das sind speziell fuer das Spurmapping eingefuehrte Kategorien. (Wir wollen ja einen Mehrwert durch das Spurmapping haben).

C) In der physikalischen Beschreibung der Strasse ist der zweite Schritt dann, die Abgrenzung zwischen den Spuren zu erfassen. Ich hatte erst ueberlegt, ob auch die Trennelemente mit in die Spurliste sollten, aber ich denke, dass man die besser als separate Liste erfasst, z.B.:
lanes:separation=nichts;Bordstein;Durchgezogene_Linie;Gestrichelte_Linie;Bordstein
Diese Liste hat per Definition ein Element weniger als die lanes-Liste, alle anderen Listen dagegen muessen genauso viel Elemente haben.

D) Wenn man das Konzept der von links nach rechts aufgezaehlten, verschiedenen Spuren akzeptiert hat, d.h. es existiert eine lanes=...;...;... Liste, so hat man fuer die weitere, deteillierte Erfassung zwei Moeglichkeiten: Entweder man erfasst auch die anderen Elemente ueber vollstaendige Listen, oder aber man erfasst die Listenpositionen einzeln. Definition: die Spur links hat die Nummer 1, die Spurtrennung hat die gleiche Nummer wie die Spur links von ihr,
So koennte obiges Beispiel z.B. so weiter gehen, dass man die Oberflache der Spuren erfassen will. Angenommen der Fuss- und Radweg waere nicht befestigt, dann koennte man entweder
lanes:surface=paved;paved;paved;paved;paved;unpaved
oder
lanes:surface:6=unpaved
setzen.

E) Die Richtung der Fahrspuren sollte nicht kryptisch irgendwo mit untergeschoben werden, sondern als eigenes Tag erfasst werden. Z.B.:
lanes:direction=beide;beide;rueckwaerts;vorwaerts;vorwaerts;beide
Damit hat man keine Probleme mit Rechts- und links-Verkehr und kann auf die selbe Art auch abweichende Richtungen fuer einzelne Ferkehrsteilnehmer erfassen, z.B.
ueber lanes:direction:bicycle:6=vorwaerts (oder von mir aus auch lanes:bicycle:direction:6=vorwaerts)

F) Das Spurmapping macht ja erst richtig Sinn, wenn man auch erfasst, wohin eine Spur im naechsten Abschnitt weiter fuehrt. Fuer das Beispiel nehmen wir mal an, dass der Weg mit seiner Spitze auf eine Kreuzung zeigt, auf der von links eine Strasse einmuendet. Mit
lanes:continuation:4=links
kann man erfassen, dass man von der mittleren Fahrspur aus nur nach links abbiegen darf.
lanes:continuation:3=links,forwaerts
gibt an, dass man in diese Spur (Gegenrichtung) sowohl von links als auch von vorne (Richtung des OSM-Weges) gelangen kann.
lanes:continuation ist eine Kurzschreibweise fuer lanes:continuation:forward, denn es kann auch notwendig sein, die Fortsetzung in der anderen Richtung mit lanes:continuation:backward zu erfassen. Die Erfassung des Uebergangs von einem Weg zum naechsten ueber continuation:forward oder continuation:backward kann ueberbestimmt sein, man muss ja aber nur so weit die Werte setzen wie noetig (bei Korrekter erfassung sollten sich allerdings keine Widersprueche ergeben.)
Statt der OSM-Wegrichtung koennte man die Fortsetzung auch ueber die Fahrtrichtung einer Spur erfassen. Dann hat man aber das Durcheinander, dass fuer einzelne Spuren des Weges die Fortsetzung sich auf unterschiedliche Wege bezieht. Und bei Spuren, die in beide Richtungen benutzt werden duerfen, haette man ein Definitionsproblem.

G) Wenn auch die angrenzenden Strassen spurgenau erfasst worden sind, dann kann auch die Fortsetzung spurgenau erfasst werden. So beschreibt z.B.
lanes:continuation:3=links:2,forwaerts:3
dass sich die dritte Spur des Weges nach links in die zweite Spur und in Wegrichtung in die dritte Spur fortsetzt.
(Natuerlich kann man alle Fortsetzungen eines Weges auch in einer Liste erfassen
lanes:continuation=links:1,links:4,forwaerts:1;links:1,links:4,forwaerts:2; usw.
Oder Sonderfaelle, wo fuer einzelne Ferkehrsteilnehmer auf einer Spur andere Regeln gelten als fuer den Rest lanes:continuation:foot:6=...)

H) Wenn man die Konzepte aus C) und D) kombiniert, dann kann man auf diese Weise auch Strassenraender erfassen. Z.B. wuerde
lanes:separation:0=Baumreihe
und
lanes:separation:6=Baumreihe
aus obigem Beispiel eine Allee machen.

Das Konzept bietet dem Mapper also jede Menge Freiraum, was und wie genau er alles erfassen will. Hauptsache ist erstmal die Erfassung der einzelnen Spuren unter A), der Rest laesst sich dann in bester OSM-Tradition beliebig verfeinern.

Soweit scheint mir erstmal alles ganz stimmig. Ein Problem habe ich z.Z. noch damit, wie man die Uebergaenge von einem Weg in den anderen an den Kreuzungspunkten weitere Charakterisieren kann. Obiges Konzept beschreibt bislang nur, dass man von einer Spur der einen Strasse in eine Spur einer anderen Strasse wechseln kann. Es fehlt aber noch die Beschreibung, ob man dabei ueber eine Ampel kommt, einen Zebrastreifen hat, indirekt abbiegen muss (Fussgaenger) und ob man z.B. erst geradeaus und dann links oder erst links und dann geradeaus gehen muss.

Ist mein Vorschlag verstaendlich? Was meint ihr dazu?

Gruss
Torsten

de_muur wrote:

Ist mein Vorschlag verstaendlich? Was meint ihr dazu?

Den Vorschlag insgesamt finde ich verständlich, er wäre auch technisch umsetzbar. Zu einigen Aspekten habe ich trotzdem Kritik, teils auch Verbesserungsvorschläge.

lanes:continuation:3=links,forwaerts
gibt an, dass man in diese Spur (Gegenrichtung) sowohl von links als auch von vorne (Richtung des OSM-Weges) gelangen kann.

Ich fange hiermit an, weil das mein größter Kritikpunkt ist: Die Angabe, woher man in diese Spur gelangen kann, finde ich hochgradig verwirrend.

Die Information, dass eine Spur z.B. eine reine Linksabbiegerspur ist, sollte am Way selbst vorliegen. Es wäre unzumutbar, dazu alle Spuren aller anderen Ways einer Kreuzung prüfen zu müssen!

Dein Konzept ließe sich dadurch retten, die continuation bei Spuren mit definierter Fahrtrichtung immer in Fahrtrichtung anzugeben - für die Gegenrichtung also immer mit lanes:continuation:backward zu arbeiten. Dann wäre eine Linksabbiegerspur in Gegenrichtung mit lanes:continuation:backward:1 = left eingetragen, was ich als angemessen verständlich empfinde.

Dann würde ich aber auch die Möglichkeit streichen, das "forward" wegzulassen. Wenn man routinemäßig auch backward verwendet, ergibt der Sonderstatus für forward ja keinen Sinn mehr.

lanes

Du bist nicht der erste in diesem Thread, der lanes=* als Key nutzt. Ich halte das aber für einen unnötigen Konflikt mit der bisherigen Verwendung von lanes=* für die Anzahl der (Fahrbahn-)Spuren. Das lässt sich durch Wahl eines anderen Schlüssels - lanes:layout, lanes:type, lanes:class oder was auch immer - problemlos vermeiden.

lanes:surface:6=unpaved

Mit Schlüsseln wie "lanes:surface:6" wird ohne Not der Vorteil aufgegeben, nur eine feste Anzahl Schlüssel zu haben, was sich Anwender z.B. beim Import in Datenbanken oft wünschen.

Am einfachsten für die Auswertung und auch in Editoren & co fände ich, Leerstellen in der Liste zu erlauben. Als z.B.:
lanes:surface = ;;;;;unpaved
Das würde sich fast von selbst programmieren.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Die Richtung der Fahrspuren sollte nicht kryptisch irgendwo mit untergeschoben werden, sondern als eigenes Tag erfasst werden.

Da muss klar sein, dass diese Verschönerung der Tags (der Verzicht auf ein spezielles Richtungstrennzeichen wie das | in meinem Post) dadurch erkauft wird, dass für die große Mehrheit der "normalen" Straßen ohne ungewöhnliche Verteilung der Fahrtrichtungen ein Zusatztag nötig wird. Dazu kommt noch, dass du die Information über "Linksabbiegerspur" etc. in ein Sondertag auslagerst. Das ist zwar schön aufgeräumt, aber führt insgesamt zu 3 Tags statt 1 Tag als Mindestausstattung einer so getaggten Straße.

Ich verstehe den Reiz einer Lösung ohne Ausnahmen und Abkürzungen, es würde sogar die Auswertung und die Unterstützung in Editoren erleichtern, aber man zahlt einen gewissen Preis dafür.

Tordanik wrote:

lanes:continuation:3=links,forwaerts
gibt an, dass man in diese Spur (Gegenrichtung) sowohl von links als auch von vorne (Richtung des OSM-Weges) gelangen kann.

Ich fange hiermit an, weil das mein größter Kritikpunkt ist: Die Angabe, woher man in diese Spur gelangen kann, finde ich hochgradig verwirrend.

An der Stelle hatte ich auch lange ueberlegt, aber ich denke doch, dass ein Tagging der fahrtrichtungsbezogenen Fortsetzung noch verwirrender ist, da man dann in EINER Liste die Angaben fuer ZWEI raeumlich getrennte Wegenden vermischt.

Die Information, dass eine Spur z.B. eine reine Linksabbiegerspur ist, sollte am Way selbst vorliegen. Es wäre unzumutbar, dazu alle Spuren aller anderen Ways einer Kreuzung prüfen zu müssen!

Laut meinem Vorschlag ist das ja auch nicht zwingend gefordert, dass man das so erfasst. Letztendlich stossen an einem Kreuzungspunkt ja mehrere Wegenden aneinander, und man muss per Tagging erfassen, wie sich die einzelnen Spuren ueber die Kreuzungen hinweg miteinander verbinden. Von der Intuition her ist es sicherlich am einfachsten, wenn man fuer jede auf die Kreuzung hinfuehrende Spur angibt, wie diese hinter der Kreuzung weiter geht. Der Vollstaendigkeit halber muss aber auch definiert sein, wie entsprechenden Tags fuer die anderen Spuren zu setzen sind. Das heisst ja aber nicht, dass man die aber auch mit angeben muss, denn letztendlich wird dadurch ja das System ueberbestimmt.
Spaetestens wenn man die Fusswege mit einbezieht, hat sich das mit der definierten Fahrtrichtung der einzelnen Spuren sowieso erledigt.

Du bist nicht der erste in diesem Thread, der lanes=* als Key nutzt. Ich halte das aber für einen unnötigen Konflikt mit der bisherigen Verwendung von lanes=* für die Anzahl der (Fahrbahn-)Spuren. Das lässt sich durch Wahl eines anderen Schlüssels - lanes:layout, lanes:type, lanes:class oder was auch immer - problemlos vermeiden.

Die Bezeichner sind mir bislang voellig egal, entscheidender ist es, erstmal eine Struktur fuer das Spurmapping auszuarbeiten.

Mit Schlüsseln wie "lanes:surface:6" wird ohne Not der Vorteil aufgegeben, nur eine feste Anzahl Schlüssel zu haben, was sich Anwender z.B. beim Import in Datenbanken oft wünschen.

Am einfachsten für die Auswertung und auch in Editoren & co fände ich, Leerstellen in der Liste zu erlauben. Als z.B.:
lanes:surface = ;;;;;unpaved
Das würde sich fast von selbst programmieren.

Im Prinzip wuerde beides gehen. Die erste Variante waere m.E. einfacher (per Hand) zu editieren und auch besser zu lesen, die zweite Variante waere vielleicht einfacher auszuwerten. Letzteres wuerde ich allerdings nicht ueberbewerten, denn ohne viel Aufwand koennte ein Praeprozessor die eine Notation in die andere umwandeln.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Da muss klar sein, dass diese Verschönerung der Tags (der Verzicht auf ein spezielles Richtungstrennzeichen wie das | in meinem Post) dadurch erkauft wird, dass für die große Mehrheit der "normalen" Straßen ohne ungewöhnliche Verteilung der Fahrtrichtungen ein Zusatztag nötig wird. Dazu kommt noch, dass du die Information über "Linksabbiegerspur" etc. in ein Sondertag auslagerst. Das ist zwar schön aufgeräumt, aber führt insgesamt zu 3 Tags statt 1 Tag als Mindestausstattung einer so getaggten Straße.

Ist der haeufigste Fall wirklich die Linksabbiegespur? Ist nicht der Fall viel haeufiger, wo eine Strasse ohne bauliche Veraenderung fortgefuehrt wird und man einfach nur beschreiben muss, wie die Strasse aussieht? Im Normalfall braucht man sich um das Verbinden der Spuren eigentlich gar nicht kuemmern, ich wuerde mal schaetzen, dass man bei ueber 90% der Verbindungspunkte ohne weitere Angaben allein mit Default-Werten klar kommt. Die Zusatztags sind doch erst in den Sonderfaellen nötig, wo man es mit komplizierteren Kreuzungsstrukturen zu tun hat.

Gruss
Torsten

Tordanik wrote:

Ich halte einen Fehler bei Groß- und Kleinschreibung z.B. für einen sehr wahrscheinlichen Tippfehler, und deshalb ist es problematisch, dass er schwer zu finden ist. Auch andere Fehler sind schwer zu finden, nur denke ich, dass die eben nicht ebenso häufig vorkommen werden. Aber ok, das ist teils Spekulation.

Generell finde ich halt die Lesbarkeit wichtiger als schnelles Schreiben, denn für's Schreiben will man sowieso Editorunterstützung.

Editorunterstützung ist ok, aber ich will auch die Möglichkeit haben, ohne großen Aufwand alles selber einzugeben. Merkaartor unterstützt praktisch nur manuelles Tagging, denn er ist ein Editor für Leute, die verstehen möchten, was sie tun, und gern die volle Kontrolle haben.

Wieso längere Tags lesbarer sein sollen, kann ich nicht nachvollziehen. Klar, unter einem ausgeschriebenen Wort kann man sich leichter was vorstellen als unter einem Buchstaben. Aber sobald die Kette länger wird, ist sie nicht mehr überschaubar. Da spielen dann die Kürzel ihre Stärke aus. Das ist überall so: Wenn ich sage, ich habe zwei Kinder, dann schreibe ich "zwei" aus. Doch kein Mathematiker wird "Quadratwürzel aus fünfhundertsiebenunddreißig" ausschreiben, dafür benutzt man Ziffern und Symbole. Anderes Beispiel: Adenin und Guanin sind kurze Wörter, die kann man leicht ausschreiben. Aber wenn du eine längere DNA-Sequenz angeben willst, wirst du sie mit A und G abkürzen.

Was nun die Groß- und Kleinschreibung betrifft, ja, da passieren viele Fehler, aus Schlampigkeit, weil es meistens nicht nötig ist dabei auzupassen. Wo es aber nötig ist, wird man schon aufpassen. Und wenn man die Fahrtrichtung auf andere Weise taggt, kann sich man genauso irren.

de_muur wrote:

Als Trennzeichen in der Liste habe ich hier das Semikolon gewaehlt. Das Komma schient mir ungeeignet, da es innerhalb eines Listenelementes gebraucht werden kann, wenn da mehrere Werte aufgezaehlt werden muessen (z.B. Fahrbahn und gleichzeitig Strassenbahn).

Die kannst du auch mit anderen Zeichen trennen, z.B. + oder =. Strichpunkt als Trennzeichen sehe ich als Tabu, da der Strichpunkt normalerweise unabhängige Werte trennt (amenity=restaurant;cafe oder information=board;map), deren Reihenfolge nicht definiert ist und wo gilt: key=value1;value=2 <=> key=value1 + key=value2. Würde ich einen Renderer schreiben, dann würde ich im ersten Schritt alle Tags an Strichpunkten zerlegen und alle doppelten Werte wegwerfen. Damit wären die Spurtags schon kaputt, d.h. man müsste extra für die (d.h. hartkodiert) schon in diesem Schritt eine Ausnahme machen.

Tordanik wrote:

Mit Schlüsseln wie "lanes:surface:6" wird ohne Not der Vorteil aufgegeben, nur eine feste Anzahl Schlüssel zu haben, was sich Anwender z.B. beim Import in Datenbanken oft wünschen.

Eine feste Anzahl Schlüssel in OSM kann es nie geben, da täglich neue erfunden werden. Fix ist nur die Anzahl Schlüssel in der Zieldatenbank. Die müssen kein 1:1 Abbild der Schlüssel in OSM sein. Für lanes:surface:<spurnummer>=<wert> kann man die Tabelle in der Zieldatenbank wie folgt designen:
Tabelle Spursurface
Feld Way_ID (PK)
Feld Spurnummer (PK)
Feld Wert

Ich sehe da überhaupt kein Problem. Letztlich muss bei einem Import sowieso diese Tabelle herauskommen, denn mit Trennzeichen zusammengestückelte Werte wird man in einer relationalen Datenbank nach Möglichkeit vermeiden (erste Normalform).

Ich denke, dass wir für spurbezogene Tags 2 Schreibweisen zulassen sollten:
1.) Kurzschreibweise mit Kommas: lanes:minspeed=60,80,100,100,80,60
2.) Schreibweise für einzelne Spuren: lanes:6:surface=unpaved
...damit man sich bei lanes:surface=,,,,,unpaved nicht um ein oder zwei Kommas verzählt.

Die Spurnummer setze ich gleich hinter "lanes:", damit sie an einer fixen Stelle steht. Denn
lanes:6:maxspeed=100
lanes:6:maxspeed:hgv=80
finde ich übersichtlicher als
lanes:maxspeed:6=100
lanes:maxspeed:hgv:6=100

fkv wrote:

Wieso längere Tags lesbarer sein sollen, kann ich nicht nachvollziehen. Klar, unter einem ausgeschriebenen Wort kann man sich leichter was vorstellen als unter einem Buchstaben. Aber sobald die Kette länger wird, ist sie nicht mehr überschaubar. Da spielen dann die Kürzel ihre Stärke aus. Das ist überall so: Wenn ich sage, ich habe zwei Kinder, dann schreibe ich "zwei" aus. Doch kein Mathematiker wird "Quadratwürzel aus fünfhundertsiebenunddreißig" ausschreiben, dafür benutzt man Ziffern und Symbole. Anderes Beispiel: Adenin und Guanin sind kurze Wörter, die kann man leicht ausschreiben. Aber wenn du eine längere DNA-Sequenz angeben willst, wirst du sie mit A und G abkürzen.

Solche "Abkuerzungen" funktionieren aber nur, wenn man fest definierte, abgeschlossene Alphabete hat. Wie du spaeter ja aber selber anfeuhrts, ist OSM so aufgebaut, dass Schluessel und Werte beliebig wachsen koennen. Das vetraegt sich mit Abkuerzungen gar nicht. Und zum Glueck sind Abkuerzungen bei OSM ja auch alles andere als ueblich, selbst die Boolean-Werte yes und no werden ja standardmaesisg ausgeschrieben. Da sollte wir jetzt mit dieser Unsitte bestimmt nicht anfangen.

Die kannst du auch mit anderen Zeichen trennen, z.B. + oder =. Strichpunkt als Trennzeichen sehe ich als Tabu, da der Strichpunkt normalerweise unabhängige Werte trennt (amenity=restaurant;cafe oder information=board;map), deren Reihenfolge nicht definiert ist und wo gilt: key=value1;value=2 <=> key=value1 + key=value2.

Genau das meinte ich, nur hatte ich die Zeichen verwechselt :-(

Um so entscheidender ist es, dass man da nicht noch verschiedene Bedeutungen mit rein kodiert.

Vieleicht waere der Strich | ein guter Kandidat, um die einzelnen Spuren zu trennen?

Ich denke, dass wir für spurbezogene Tags 2 Schreibweisen zulassen sollten:
1.) Kurzschreibweise mit Kommas: lanes:minspeed=60,80,100,100,80,60
2.) Schreibweise für einzelne Spuren: lanes:6:surface=unpaved
...damit man sich bei lanes:surface=,,,,,unpaved nicht um ein oder zwei Kommas verzählt.

Ganz meine Meinung.

Die Spurnummer setze ich gleich hinter "lanes:", damit sie an einer fixen Stelle steht. Denn
lanes:6:maxspeed=100
lanes:6:maxspeed:hgv=80
finde ich übersichtlicher als
lanes:maxspeed:6=100
lanes:maxspeed:hgv:6=100

Im Prinzip koennte ich mit beiden Leben. Bei einer Abstimmung wuerde ich allerdings die zweite Variante bevorzugen, um die Aehnlichkeit von
lanes:maxspeed=10,20,30
und
lanes:maxspeed:3=30
zu betonen.

Aber das sind Syntax-Kleinigkeiten. Interessanter ist erstmal, wie man ein Spur-Mapping ueberhaupt aufziehen will.

Gruss
Torsten

fkv wrote:

Die Spurnummer setze ich gleich hinter "lanes:", damit sie an einer fixen Stelle steht. Denn
lanes:6:maxspeed=100
lanes:6:maxspeed:hgv=80
finde ich übersichtlicher als
lanes:maxspeed:6=100
lanes:maxspeed:hgv:6=100

Ich finde das schreit dann geradezu nach
lanes[6]:maxspeed=100
lanes[6]:maxspeed:hgv=80
Dann wäre sogar
lanes[5;6]:maxspeed=100
lanes[6]:maxspeed:hgv=80
denkbar.

Tordanik wrote:

http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

Ok, meiner ist "Alternative B".

BTW: Was heißt Sperrfläche auf Englisch? (Steht nicht mal im Langenscheidt-Wälzer.)

de_muur wrote:

Solche "Abkuerzungen" funktionieren aber nur, wenn man fest definierte, abgeschlossene Alphabete hat. Wie du spaeter ja aber selber anfeuhrts, ist OSM so aufgebaut, dass Schluessel und Werte beliebig wachsen koennen. Das vetraegt sich mit Abkuerzungen gar nicht.

Ob man "slightleft" abkürzt oder ausschreibt, ein lexikalisches Token ist es so oder so. Entweder der Parser kennt es, dann kann er was damit anfangen, oder er kennt es nicht, dann kann er nichts damit anfangen. Auf die Erweiterbarkeit hat das Abkürzen also keinen Einfluss.

GeoCounter wrote:

Ich finde das schreit dann geradezu nach
lanes[6]:maxspeed=100
lanes[6]:maxspeed:hgv=80
Dann wäre sogar
lanes[5;6]:maxspeed=100
lanes[6]:maxspeed:hgv=80
denkbar.

Mir persönlich wär's recht, aber diese Schreibweise wäre in OSM neu.

fkv wrote:

Ob man "slightleft" abkürzt oder ausschreibt, ein lexikalisches Token ist es so oder so. Entweder der Parser kennt es, dann kann er was damit anfangen, oder er kennt es nicht, dann kann er nichts damit anfangen.

Klar ist das mit den Abkuerzungen dem Parser egal (solange es eindeutig ist). Es geht dabei allein um die Lesbarkeit fuer den Mapper. Schau dir doch mal mit einem Meter Abstand auf der Uebersichtsseite Alternative B Example 2 an. Das versteht doch kein (menschliches) Schwein mehr, einschliesslich des Mappers selber auch nur 3 Minuten nach dem Eintragen.
Und erzaehl mir nicht, dass das Tagging des Beispiel dank der Abkuerzungen schoen uebersichtlich waere ;-)

Gruss
Torsten

Alternative 3 ist auch drinnen.

Hallo fkv,

du solltest bei deiner Alternative nicht lanes=* verwenden, das ist bereits 2249668x anderweitig genutzt.
Es spricht sicher nichts dagegen, lanes:layout nochmals zu nehmen, oder auch einfach etwas anderes.

Walter

@de_muur: Dann lass mal deine Variante sehen.

Im Vergleich zu den linken Spalten sieht Alternative B in Example 2 natürlich kompliziert aus, weil die nur die Hälfte der Informationen enthalten.

@Walter: lanes=* hab ich vom Vorgängerproposal übernommen. Natürlich kann man es auch lanes:layout nennen, aber ich spare mir gern Schreibarbeit. Dass lanes=<Zahl> schon oft vorkommt, stört nicht. Ich nehme an, dass Anwendungen diesen Tag bisher sowieso ignoriert haben, da sich mit der Gesamtspurenzahl nicht viel anfangen lässt. Und zukünftige Anwendungen können leicht erkennen, ob der Wert nur eine Zahl enthält oder was anderes.

de_muur wrote:

Die Information, dass eine Spur z.B. eine reine Linksabbiegerspur ist, sollte am Way selbst vorliegen. Es wäre unzumutbar, dazu alle Spuren aller anderen Ways einer Kreuzung prüfen zu müssen!

Laut meinem Vorschlag ist das ja auch nicht zwingend gefordert, dass man das so erfasst. Letztendlich stossen an einem Kreuzungspunkt ja mehrere Wegenden aneinander, und man muss per Tagging erfassen, wie sich die einzelnen Spuren ueber die Kreuzungen hinweg miteinander verbinden. Von der Intuition her ist es sicherlich am einfachsten, wenn man fuer jede auf die Kreuzung hinfuehrende Spur angibt, wie diese hinter der Kreuzung weiter geht.

Eben, es ist unter Zuhilfenahme der Fahrtrichtung intuitiver. Und ich würde deshalb noch weiter gehen und ein solches Mapping nicht nur erlauben, sondern es direkt zur Vorgabe machen, dass die Fortsetzung in (einer der) Fahrtrichtung(en) anzugeben ist.

Die Regel sähe dann so aus:

• lanes:continuation:forward/backward gibt an, wohin man gelangt, wenn man sich auf der Spur in/entgegen Wegrichtung bewegt
  
• bei Spuren für beide Richtungen kann man eins weglassen, wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt.
  

Dazu auch mal eine Detailfrage: Wie handhabst du mit deinem Vorschlag Spuren, bei denen mein Zusatz "wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt" nicht gilt? Also z.B. eine "two-way left turn lane" für Linksabbieger in beide Richtungen? Skizze siehe unteres Diagramm http://www.mto.gov.on.ca/english/dandv/ … .6.5.shtml hier.

Wenn man sich - wie ich hier vorschlage - darauf festlegt, die Fahrtrichtung als Kriterium ins Tagging einzubeziehen, dann wird man dort einfach ...:forward und ...:backward passend für die jeweilige Fahrtrichtung setzen.

Ist der haeufigste Fall wirklich die Linksabbiegespur? Ist nicht der Fall viel haeufiger, wo eine Strasse ohne bauliche Veraenderung fortgefuehrt wird und man einfach nur beschreiben muss, wie die Strasse aussieht?

Die Linksabbiegespur ist nicht der häufigste Fall, aber insgesamt gesehen doch allgegenwärtig. Es sollte schon eine Möglichkeit geben, eine Spur als Linksabbiegerspur zu markieren. (Das ist nicht dasselbe wie ein "left" bei der Continuation, denn eine Linksabbiegerspur beginnt schon ein ganzes Stück vor der Kreuzung und ist auch dann eine Linksabbiegerspur, wenn man den Way in ihrem Verlauf auftrennen muss.) Das fehlt in deinem Vorschlag leider noch.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Darf man fragen warum? Ich finde es ähnlich gut lesbar wie deinen Vorschlag, aber es vermeidet gleichzeitig das leidige Thema Zahlen in Schlüsseln.

fkv wrote:

Eine feste Anzahl Schlüssel in OSM kann es nie geben, da täglich neue erfunden werden

Es ist normalerweise aber möglich, eine endliche Liste von Schlüsseln zu erstellen, die für die eigene Anwendung relevant sind. Das erleichtert z.B. die Erstellung von Filtern.

Editorunterstützung ist ok, aber ich will auch die Möglichkeit haben, ohne großen Aufwand alles selber einzugeben.

Und dann schlägst du so was vor?

lanes=c.l+s,s,s+r,r||N.N,C<kerb>p

Vielleicht ist das auch wieder eine Geschmacksfrage, aber das finde ich schwer zu lesen, schwer zu schreiben und schwer zu parsen. Ohne Editorunterstützung fasse ich diesen Wert nicht mal mit der Kneifzange an. 😉

Tordanik wrote:

• lanes:continuation:forward/backward gibt an, wohin man gelangt, wenn man sich auf der Spur in/entgegen Wegrichtung bewegt
  

Das ist das, was ich lane_matching genannt habe, weil mir kein besserer Keyname eingefallen ist. Vielleicht ist ...continuation besser, keine Ahnung.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Darf man fragen warum? Ich finde es ähnlich gut lesbar wie deinen Vorschlag, aber es vermeidet gleichzeitig das leidige Thema Zahlen in Schlüsseln.

Indem ein Teil des Schlüssels in den Wert verschoben wird. Genauso könnte man lanes=surface:6:unpaved draus machen.

Es ist normalerweise aber möglich, eine endliche Liste von Schlüsseln zu erstellen, die für die eigene Anwendung relevant sind. Das erleichtert z.B. die Erstellung von Filtern.

Wir leben im 3. Jahrtausend. Heute gibt es regular expressions.

Und dann schlägst du so was vor?

lanes=c.l+s,s,s+r,r||N.N,C<kerb>p

Vielleicht ist das auch wieder eine Geschmacksfrage, aber das finde ich schwer zu lesen, schwer zu schreiben und schwer zu parsen. Ohne Editorunterstützung fasse ich diesen Wert nicht mal mit der Kneifzange an. 😉

Wenn du die Doku (http://wiki.openstreetmap.org/wiki/User … ping_draft) anschaust, geht das schon. Dafür, was in dem Wert alles drinsteckt, ist er doch relativ übersichtlich. Wenn man das anders macht, wird es noch komplizierter.

eine "two-way left turn lane" für Linksabbieger in beide Richtungen? Skizze siehe unteres Diagramm http://www.mto.gov.on.ca/english/dandv/ … .6.5.shtml hier.

Fein, das werde ich gleich in die Vergleichsseite einbauen. EDIT: Doch noch nicht, weil in dem Beispiel keine Kreuzung ist und weil mir die Regeln noch nicht ganz klar sind. Verstehe ich das richtig, dass eine center turn lane für Linksabbieger von beiden Seiten eine Abbiegespur ist, zugleich für Linksabbieger von der Querstraße so eine Art Beschleunigungsstreifen?

Tordanik wrote:

Eben, es ist unter Zuhilfenahme der Fahrtrichtung intuitiver. Und ich würde deshalb noch weiter gehen und ein solches Mapping nicht nur erlauben, sondern es direkt zur Vorgabe machen, dass die Fortsetzung in (einer der) Fahrtrichtung(en) anzugeben ist.

Die Regel sähe dann so aus:

• lanes:continuation:forward/backward gibt an, wohin man gelangt, wenn man sich auf der Spur in/entgegen Wegrichtung bewegt
  
• bei Spuren für beide Richtungen kann man eins weglassen, wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt.
  

Meinst du beim ersten Punkt in der Regel jetzt "Wegrichtung" oder "Fahrtrichtung"?

Das Problem bei der Fahrtrichtung ist halt die vollstaendige Listendarstellung lanes:continutaion:forward=left|straight|straight|right
Bei den Spuren mit lanes:direction=forward wird hier die Kreuzung an dem einen Ende des Weges beschrieben, bei den Spuren mit lanes:direction=backward wird hier eine ganz andere Kreuzung am anderen Ende des Weges beschrieben.
Diese Vermischung halte ich fuer ziemlich verwirrend. Mir schient es da sinnvoller zu sein, dass man unter EINEM Schluessel die Verbindungen der Spuren an EINEM Ende des Weges sammelt.

Vielleicht waere als Schluessel lanes:connection passender, da dieser Begriff bezgl. der Richtung neutraler ist. Es wird einfach angegeben, wie eine Spur an diesem Kreuzungspunkt mit den anderen Richtungen verbunden ist.

Dazu auch mal eine Detailfrage: Wie handhabst du mit deinem Vorschlag Spuren, bei denen mein Zusatz "wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt" nicht gilt? Also z.B. eine "two-way left turn lane" für Linksabbieger in beide Richtungen? Skizze siehe unteres Diagramm http://www.mto.gov.on.ca/english/dandv/ … .6.5.shtml hier.

Ich muss gestehen, dass ich weder deinen Zusatz noch das Beispiel in deinem Link wirklich verstehe.

Nach meinem Konzept sollte in einem Schlüssel erfasst werden, wie die jewielige Spur an einem Knotenpunkt mit den angrenzenden Wegen verbunden ist. Das wird ueber den entsprechenden Wert abgebildet, wobei auch eine Liste von Werten moeglich ist.
Die gaengigsten Werte duerften straight, left und right sein dazu kommt sicherlich noch ein Wert fürs Wenden u_turn oder backward vielleicht sowie Zwischenwerte fuer kompliziertere Kreuzungstopologien wie slight_left oder sharp_right und vielleicht braucht man auch noch ein up oder down, wobei solche vertikalen Wegtrennungen eigentlich immer auch in der Ebene beschrieben werden koennen.

Bei naeheren ueberlegen habe ich deine Frage jetzt, glaube ich, doch verstanden. Meinst du: Wie wuerde mein Konzept es abbilden, wenn die Verbindungen zwischen den Spuren nicht symmetrisch sind? D.h. solche Faelle, wo eine Spur in beide Richtungen befahrbar ist, sie ueber die Kreuzung aber mit Spuren verbunden ist, die nur in eine Richtung befahren werden darf.
Bei meinem Konzept wuerde sich daraus ergeben, dass lanes:connection:forward des eines Weges nicht genau dem lanes:connection:backward entspricht. Da hatte ich bisher noch nicht drueber nachgedacht, scheint mir aber letztendlich kein Problem zu sein, denn am Ende sollte sich ja trotzdem ein widerspruchsfreies Gesamtbild ergeben.

Die Linksabbiegespur ist nicht der häufigste Fall, aber insgesamt gesehen doch allgegenwärtig. Es sollte schon eine Möglichkeit geben, eine Spur als Linksabbiegerspur zu markieren. (Das ist nicht dasselbe wie ein "left" bei der Continuation, denn eine Linksabbiegerspur beginnt schon ein ganzes Stück vor der Kreuzung und ist auch dann eine Linksabbiegerspur, wenn man den Way in ihrem Verlauf auftrennen muss.) Das fehlt in deinem Vorschlag leider noch.

Das ist die von mir noch offen gelassene Frage, ob man bei der Bezeichnung der einzelnen Spuren zwischen Abbiegespur und "normaler" Fahrspur unterscheiden muss oder nicht. Fuer das Routing (im Sinne von: Bestimmung der optimalen Spur) oder für eine schoene Kartendarstellung braucht man das eigentlich nicht. Aber fuer die Sprachausgabe koennte das hilfreich sein. Oder verwirrt diese Zusatzinformation eher? Ich habe weiss es nicht. Ab wann ist eine "normale" Fahrspur eine Abbiegespur? Sobald da Pfeile aufgemalt sind, schaetze ich mal.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Darf man fragen warum? Ich finde es ähnlich gut lesbar wie deinen Vorschlag, aber es vermeidet gleichzeitig das leidige Thema Zahlen in Schlüsseln.

Weil dabei Schluessel und Wert vermischt werden. Bei dieser Loesung muss man auch die rechte Seite der Gleichung auswerten, ehe man entscheiden kann, ob das Tag fuer einen von Belang ist oder nicht.

Bezueglich der Zahlen in Schluesseln sehe ich nicht so das grosse Problem. Klar, die Auswerteprogramme muessen eine Nummer schlauer werden, wenn sie diese Informationen auswerten wollen. Das gilt aber auch fuer die angedachte Listendarstellung auf der rechten Seite des Gleichheitszeichens. Das Spurmapping stellt nun mal hoehere Anforderungen an die Auswertung, liefert aber dafuer zusaetzliche Informationen, die bislang nicht erfasst werden koennen.

Mit dem lanes=* stimme ich mit fkv ueberein. Es besteht keine Gefahr, dass lanes=* und lanes=<Zahl> bei der Auswertung verwechselt werden. Und ich sehe keinen Sinn darin, fuer einen Weg die Beschreibung von lanes=<Zahl> und lanes:layout=* parallel vorzusehen/zuzulassen. Das wuerde nur zusaetzliche Komplikationen mit sich bringen.

@fkv: Ja, ich sollte wohl mein Konzept auch als Variante in die Uebersicht mit aufnehmen. Allerdings habe ich damit zwei Probleme: Zum einen legt das fuer meinen Geschmack den Schwerpunkt zu sehr auf die Syntax, welche ich als eher zweitrangig ansehe. Zum anderen sind die Beispiele so unvollstaendig, dass die konzeptionellen Unterschiede zwischen den einzelnen Varianten gar nicht klar werden. Solange z.B. nicht der OSM-Weg-Graph fuer die Beispiele mit angegeben wird, kann man einen Unterschied zwischen einer Erfassung enstprechend der Wegrichtung und einer Erfassung entsprechend der Fahrtrichung gar nicht erkennen.

Gruss
Torsten

Tordanik wrote:

http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

Ich habe meinen Vorschlag mal praezisiert und dann als Alternative E in die Tabelle aufgenommen. Das faellt bei den Beispielen aber echt schwer. Denn das Verfahren soll ja auch das detailierte Mapping erlauben, nur leider kann man halt die Details auf den Photos nicht erkennen. Entweder man faengt dann an zu raten, oder man kann kaum was als Beispiel erfassen.

Gruss
Torsten

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png

ist genauso kompliziert, dafür aber exakter.

flaimo wrote:

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png

ist genauso kompliziert, dafür aber exakter.

Weil in deinem Beispiel zwei wesentliche Dinge fehlen:
- ca. 30 - 50 turn restrictions müssten noch ergänzt werden.
==> wesentlich komplexer
- wo darf man die Spuren wechseln und wo nicht?
Erhöht ebenfalls die Komplexität.

Ganz nebenbei, wer soll so etwas noch in Ordnung halten?
Edit: Abbiegen auf eine reine Busspur ist irgendwie auch nicht optimal oder so vorgesehen.

Edbert (EvanE)

flaimo wrote:

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png

Nicht im Bild: Die Relationen / Spurwechselstellen / anderen Kleinigkeiten zum Zusammenbinden der Ways, die das Bearbeiten zur Hölle machen. 😉

Es gibt zwei zentrale Gründe, warum das Spurmapping mit eigenständigen Ways ein Problem ist:

Der erste ist die Auswertbarkeit. Während eine Straßenflächen-Darstellung aus Spurtags leicht erstellt werden kann - die einzige Herausforderung für mich wäre dort die Darstellung von Übergängen zwischen zwei Ways - wüsste ich keinen befriedigenden Ansatz, dasselbe Ergebnis aus losen Ways zu errechnen. Eine Kreuzung wie die im Bild ist für einen Menschen noch einigermaßen gut visuell zu interpretieren, vor allem mit dem Luftbild darunter. Für einen Computer ist sie eine größere Herausforderung.

Der zweite Problemkreis ist das Mapping. Es muss irgendein Mechanismus existieren, um zusammengehörige Ways als solche zu identifizieren. Der gängige Vorschlag sind Relationen, aber dann ist das (nur) "genauso kompliziert" nicht einmal mehr ansatzweise wahr. Ein anderer Ansatz wären Straßenflächen um das Linienbündel herum. So etwas fände ich auch nicht unsympathisch, aber der Teufel steckt dort wieder im Detail.

Ich will so etwas nicht fundamental ablehnen, aber ich bleibe sehr skeptisch, solange die Praktikabilität beim Editieren und auch in der Auswertung nicht demonstriert wurde. Mir erscheinen die Vorschläge auf Tag-Basis, die in diesem Thread bisher vorgebracht wurden, allesamt realistischer. Dort habe ich keinen Zweifel an der prinzipiellen Machbarkeit.

flaimo wrote:

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png

ist genauso kompliziert, dafür aber exakter.

Weil der Routinggraph schlicht und einfach falsch ist. Du kannst in der Realität mit Deinem Fahrzeug beliebig die
Spuren wechseln (zumindest bei gestrichelter Linie), der Router kann das nicht, er ist auf der Spur gefangen.

Nun kommt hinzu, dass GPS nur begrenzte Genauigkeit hat, und somit die Gefahr groß ist, dass er die
falsche Spur trifft. Des weiteren wird die Komplexität der Daten und damit die Fehlerquote erhöht.

Also: Für's Routing ist das absoluter Käse.

Chris

Da muss ich an Plätze denken, in die nicht existierende Fußwege eingezeichnet werden, um Fußgängerrouting zu ermöglichen. Auch so ein Missstand. Kann ein Router eigentlich nicht 2 an einen Platz mündende Fußwege miteinander verbinden?

chris66 wrote:

Weil der Routinggraph schlicht und einfach falsch ist. Du kannst in der Realität mit Deinem Fahrzeug beliebig die
Spuren wechseln (zumindest bei gestrichelter Linie), der Router kann das nicht, er ist auf der Spur gefangen.

ja und? dann berechnet er die route halt neu, genauso wie wenn er jetzt schon neu berechnet, wenn du abbiegst obwohl der router sagt du sollst gerade aus fahren.

chris66 wrote:

Nun kommt hinzu, dass GPS nur begrenzte Genauigkeit hat, und somit die Gefahr groß ist, dass er die
falsche Spur trifft. Des weiteren wird die Komplexität der Daten und damit die Fehlerquote erhöht.

wir mappen nicht für die karte/router. nur weil deine aktuelle technologie das nicht kann, heißt das nicht, dass zukünftige (galileo) dass dann nicht schaffen. und komplizierter als krampfhaft so ein komplexes thema wie spuren in einen einzigen way zu quetschen ist es auch nicht.

Ne, aber wir mappen, um Daten zu sammeln, die man nutzen kann...

Abgesehen davon, dass es schlichtweg falsch ist. Es ist eine Strasse, dies mehrere Spuren enthält.
Und Spuren in einen einzigen way zu quetschen ist ziemlich genau so kompliziert und krampfhaft, wie Spuren auf einer einzigen Strasse unterzubringen.

flaimo wrote:

chris66 wrote:

Weil der Routinggraph schlicht und einfach falsch ist. Du kannst in der Realität mit Deinem Fahrzeug beliebig die
Spuren wechseln (zumindest bei gestrichelter Linie), der Router kann das nicht, er ist auf der Spur gefangen.

ja und? dann berechnet er die route halt neu, genauso wie wenn er jetzt schon neu berechnet, wenn du abbiegst obwohl der router sagt du sollst gerade aus fahren.

Man befinde sich in einigem Abstand zu der Kreuzung. Die Route geht an der Kreuzung nach links. Alles ok soweit. Man nähert sich der Kreuzung, ordnet sich brav ein, dummerweise ist der Empfang aber zu schlecht und der Router vermutet einen auf der Rechtsabbiegerspur und kann dann natürlich nicht mehr nach links abbiegen. Folge: Neue Anweisung rechts abiegen. Autofahrer schummelt sich auf die Rechtsabbiegespur biegt ab und wird dann mit bitte wenden in die andere Richtung geschickt.

Eine SUPER Verbesserung für das Routing, kann man nicht anders sagen... 😉

Ebenso fehlt bei dir noch die eine Linie, die die gesamte Straße symbolisiert und die alle die nutzen können, denen Spuren vollkommen egal sind.

Ja, wir mappen nicht für die Router. Aber wenn man schon extra für das Routing Daten sehr komplex erfassen will, dann sollte man es doch auch so erfassen, dass es sinnvoll nutzbar ist, oder? Denn wenn kein Router damit etwas anfangen kann, dann kann man die Eintragung auch lassen. 😉

aighes wrote:

Ebenso fehlt bei dir noch die eine Linie, die die gesamte Straße symbolisiert und die alle die nutzen können, denen Spuren vollkommen egal sind.

wer sagt, dass die lanes die jetzigen ways komplett ersetzen? die bestehenden highways bleiben bestehen und in kreuzungsbereichen werden die lanes separat hinzerfasst um mehr details darzustellen und werden einfach mit dem bestehenden highways verknüpft. alte routingprogramme ignorieren diese dann sowieso, weil sie die neuen tags nicht kennen; somit auch kein kompatibilitätsproblem.

Ich wollte nur Anmerken, dass das Liniengewirr auf deinem Bild noch nicht alles ist, was der Mapper dann im Editor zu sehen bekommt, sondern dass noch der allgemeine highway=* fehlt.

Du glaubst aber nciht ernsthaft, dass ein Neueinsteiger da dann noch durchblickt wo er was eintragen muss und welche Objekte er nun verschieben muss, oder?

turn restriction fehlen auch noch mindestens 20 😉

pssst, keine schlafenden Hunde wecken. 😉

So, der Vorschlag für das Spurmapping wurde abgelehnt... Wie geht's jetzt weiter?!
Die "Jede-Spur-als-eigener-Highway-eintragen-Seuche" greift langsam um sich...
@chris66: Hast du die Grafik die du in Post 5 erwähnt hast organisieren können?

Wie sieht es mit dem Vorschlag von benshu aus? Ich hab gerade mal das PlugIn für JOSM angeschaut (die 2 Videos machen es spielend leicht zu verstehen).
Wäre super, wenn man noch die lanes um Attribute (Radfahrspur, Busfahrspur etc.) erweitern könnte (was aber, da es Relationen sind, machbar sein sollte).

railrun wrote:

So, der Vorschlag für das Spurmapping wurde abgelehnt... Wie geht's jetzt weiter?!

Weitere Proposals erstellen und diskutieren? Rom ist auch nicht an einem Tag erbaut worden.

Die "Jede-Spur-als-eigener-Highway-eintragen-Seuche" greift langsam um sich...

Woodpecks Revert-Script funktioniert bestens.

railrun wrote:

Wie sieht es mit dem Vorschlag von benshu aus? Ich hab gerade mal das PlugIn für JOSM angeschaut (die 2 Videos machen es spielend leicht zu verstehen).
Wäre super, wenn man noch die lanes um Attribute (Radfahrspur, Busfahrspur etc.) erweitern könnte (was aber, da es Relationen sind, machbar sein sollte).

Es ist denke ich sinnvoll zunächst im Wiki die Anforderungen unter einen Hut zu bringen und danach mit einem neuen Proposal zu beginnen, welches die Kritikpunkte ausreichend berücksichtigt.

railrun wrote:

Wie sieht es mit dem Vorschlag von benshu aus?

Das ist mit Fokus auf Abbiegespuren (also unmittelbar vor einer Kreuzung) entwickelt worden, nicht für das Spurlayout (z.B. Radspuren) entlang einer Straße. Und daher ist es in meinen Augen leider einfach zu kurz gedacht.

In dieser Hinsicht ist Lane group von polderrunner m.E. auf einem besseren Weg. Dafür hat allerdings noch niemand ein Plugin geschrieben.

Das ähnelt ja (oder ist?) einem Vorschlag aus diesem Thread, den ich auch sehr gut fand.
Ich finde bloss, das die Vorschläge zum Spurverbinden zu ungenau sind. Zwei z.B. halbrechts und rechts abbiegende Ways sind ein Problem. Und nachträglich angeschlossene Ways werfen u.U. auch alles durcheinander. Um das zu verhindern, würde ich Ziel-Waynummer und -spur angeben, auch auf die Gefahr hin, dass das Tag lang wird. Z.B.:

lane_group:matching= 12345678:1+2, 12345687:2, 12345876:2+3

Ich würde gern die Beispielseite um ein oder zwei Kreuzungen erweitern und meine Alternative eintragen, ich hoffe, dass ich die Tage Zeit dazu finde.

Bevor man eine Weg-ID angibt, machen Relationen aber hundertmal mehr Sinn. Ja, sie sind relativ kompliziert, aber letztendlich genau dafür da. Warum man immer wieder in Vor-Relations-Zeiten-Denkmuster mit Tags für sowas zurückfällt, ist mir unverständlich.

errt wrote:

Bevor man eine Weg-ID angibt, machen Relationen aber hundertmal mehr Sinn. Ja, sie sind relativ kompliziert, aber letztendlich genau dafür da. Warum man immer wieder in Vor-Relations-Zeiten-Denkmuster mit Tags für sowas zurückfällt, ist mir unverständlich.

+1
Relationen sind nicht kompliziert, man muss sich bloß etwas konzentrieren 😉
Und mit einem PlugIn (s.o.) geht es echt schnell/sauber/sicher...
Es ist jetzt die Frage, sind Kreuzungen anders zu behandeln als die "normale" Straße oder will man hier beides in einen Topf werfen. Gehen wir vom Thread-Titel aus, sind fürs Routing alleine die Kreuzungen (detailiert), wenn überhaupt, von Bedeutung.

Tordanik wrote:

railrun wrote:

Wie sieht es mit dem Vorschlag von benshu aus?

Das ist mit Fokus auf Abbiegespuren (also unmittelbar vor einer Kreuzung) entwickelt worden, nicht für das Spurlayout (z.B. Radspuren) entlang einer Straße. Und daher ist es in meinen Augen leider einfach zu kurz gedacht.
...

Für mich wäre das Fehlen einer Idee für Radspuren noch kein KO-Kriterium. Wie weiter oben beschrieben, kann da ja noch erweitert werden, denn Rom wurde...
Insgesamt finde ich den benshu-Ansatz gut, denn incl. plugin sieht das schon mal sehr mapperfrundlich aus. Lediglich bei den Spurlängen vom Abbiegepunkt aus rückwärts gerechnet, weiß ich nicht ob das renderer packen 🤔

Ich were mir das plugin mal daheim hinter meiner Linux-Kiste installieren und an einer Stelle hier testen.

hurdygurdyman wrote:

Tordanik wrote:

railrun wrote:

Wie sieht es mit dem Vorschlag von benshu aus?

Das ist mit Fokus auf Abbiegespuren (also unmittelbar vor einer Kreuzung) entwickelt worden, nicht für das Spurlayout (z.B. Radspuren) entlang einer Straße. Und daher ist es in meinen Augen leider einfach zu kurz gedacht.
...

Für mich wäre das Fehlen einer Idee für Radspuren noch kein KO-Kriterium. Wie weiter oben beschrieben, kann da ja noch erweitert werden, denn Rom wurde...
Insgesamt finde ich den benshu-Ansatz gut, denn incl. plugin sieht das schon mal sehr mapperfrundlich aus. Lediglich bei den Spurlängen vom Abbiegepunkt aus rückwärts gerechnet, weiß ich nicht ob das renderer packen 🤔

Ich were mir das plugin mal daheim hinter meiner Linux-Kiste installieren und an einer Stelle hier testen.

Das klingt gut. Kannst ja mal berichten wie es aussieht 🙂

railrunn wrote:

hurdygurdyman wrote:

...
Ich werde mir das plugin mal daheim hinter meiner Linux-Kiste installieren und an einer Stelle hier testen.

Das klingt gut. Kannst ja mal berichten wie es aussieht 🙂

Ja, ja, probieren geht über studieren diskutieren 😉
Das wird aber nur eine einfache Kreuzung mit maximal einer Abbiegespur rechts und links je Einmündung.

railrun wrote:

errt wrote:

Bevor man eine Weg-ID angibt, machen Relationen aber hundertmal mehr Sinn. Ja, sie sind relativ kompliziert, aber letztendlich genau dafür da. Warum man immer wieder in Vor-Relations-Zeiten-Denkmuster mit Tags für sowas zurückfällt, ist mir unverständlich.

+1
Relationen sind nicht kompliziert, man muss sich bloß etwas konzentrieren 😉
Und mit einem PlugIn (s.o.) geht es echt schnell/sauber/sicher...
Es ist jetzt die Frage, sind Kreuzungen anders zu behandeln als die "normale" Straße oder will man hier beides in einen Topf werfen. Gehen wir vom Thread-Titel aus, sind fürs Routing alleine die Kreuzungen (detailiert), wenn überhaupt, von Bedeutung.

Hier wage ich dir zu widersprechen. Es ist derzeit noch so, dass alle Straßen höchstens nach Kategorie gewichtet werden, wenn es um die Aufwandsbeurteilung beim Routing geht. Sprich versuche Hauptstraßen/Autobahnen zu bevorzugen etc.

Später wären aber andere Dinge vielleicht auch sehr wichtig. Habe ich zwei Spuren je Richtung, wie oft darf/kann ich Lkw auf der Landstraße überholen und manchmal gehen Überholverbote auch weit über Kreuzungen hinaus. Aber das sind nur Ideen für die Zukunft und warum ich denke, dass es auch sinnvoll sein kann den Rest der Straße in Spuren zu erfassen. Außerdem geht dann auch nicht die Information verloren welche Spur jetzt die geeignetere ist.

Was aber nichts an der Grundaussage ändert, dass es Quatsch ist, Relationstags statt Relationen zu verwenden, unabhängig davon ob man das vielleicht insgesamt besser sein lassen sollte.

viw wrote:

railrun wrote:

Gehen wir vom Thread-Titel aus, sind fürs Routing alleine die Kreuzungen (detailiert), wenn überhaupt, von Bedeutung.

Hier wage ich dir zu widersprechen. Es ist derzeit noch so, dass alle Straßen höchstens nach Kategorie gewichtet werden, wenn es um die Aufwandsbeurteilung beim Routing geht. Sprich versuche Hauptstraßen/Autobahnen zu bevorzugen etc.

Deswegen auch das "wenn überhaupt". Beim Routing wird primär nach dem Straßentyp gegangen, dann nach der Anzahl des Abbiegens und/oder Ampeln etc. Dabei können Linksabbiege-Vorgänge auch berücksichtigt werden, die ja länger dauern (und da kommt schon wieder das Problem mit den 5 Abbiegevorgänge für einen realen Abbiegevorgang an manchen Freiburger Kreuzungen).

viw wrote:

Später wären aber andere Dinge vielleicht auch sehr wichtig.

Wie lange wollen wir aber warten?! Wird es jemals ein Proposal für Einzelspurmapping geben, welches angenommen wird? Vor Relationen haben viele Leute angst, vor normalen Tags auch. Einzeln eingezeichnete Spuren sind nicht Routingfähig und ebenfalls kompliziert...

viw wrote:

Habe ich zwei Spuren je Richtung, wie oft darf/kann ich Lkw auf der Landstraße überholen und manchmal gehen Überholverbote auch weit über Kreuzungen hinaus. Aber das sind nur Ideen für die Zukunft und warum ich denke, dass es auch sinnvoll sein kann den Rest der Straße in Spuren zu erfassen. Außerdem geht dann auch nicht die Information verloren welche Spur jetzt die geeignetere ist.

Aber weniger Sinnvoll wäre dann eine 2 spurige Strecke (je Fahrrichtung) als eigenen Highway zu nehmen, oder?!

railrun wrote:

viw wrote:

Habe ich zwei Spuren je Richtung, wie oft darf/kann ich Lkw auf der Landstraße überholen und manchmal gehen Überholverbote auch weit über Kreuzungen hinaus. Aber das sind nur Ideen für die Zukunft und warum ich denke, dass es auch sinnvoll sein kann den Rest der Straße in Spuren zu erfassen. Außerdem geht dann auch nicht die Information verloren welche Spur jetzt die geeignetere ist.

Aber weniger Sinnvoll wäre dann eine 2 spurige Strecke (je Fahrrichtung) als eigenen Highway zu nehmen, oder?!

Das habe ich noch nicht ganz verstanden. Dem Routinggraph wäre es doch egal. Nur das mit dem überholen und der Darstellung der Straße sähe dann sicher komisch aus. Hier ist also eher die optische Fraktion daran interessiert das als einen Weg/Fläche zu erfassen.

viw wrote:

railrun wrote:

viw wrote:

Habe ich zwei Spuren je Richtung, wie oft darf/kann ich Lkw auf der Landstraße überholen und manchmal gehen Überholverbote auch weit über Kreuzungen hinaus. Aber das sind nur Ideen für die Zukunft und warum ich denke, dass es auch sinnvoll sein kann den Rest der Straße in Spuren zu erfassen. Außerdem geht dann auch nicht die Information verloren welche Spur jetzt die geeignetere ist.

Aber weniger Sinnvoll wäre dann eine 2 spurige Strecke (je Fahrrichtung) als eigenen Highway zu nehmen, oder?!

Das habe ich noch nicht ganz verstanden. Dem Routinggraph wäre es doch egal. Nur das mit dem überholen und der Darstellung der Straße sähe dann sicher komisch aus. Hier ist also eher die optische Fraktion daran interessiert das als einen Weg/Fläche zu erfassen.

Würde aber auch weitere Berechnung bedeuten => langsameres Routing.

Auch das verstehe ich wieder nicht.
Ein Routinggraph kennt doch nur gerichtete Kanten. Das heißt, wenn ich in beiden Richtungen fahren darf, wird aus einem Weg zwei gemacht. Das ist bei Spurmapping wahrscheinlich ohnehin notwendig, wenn in der einen Richtung nämlich 2 und in der Gegenrichtung nur eien Fahrspur existiert.

viw wrote:

Auch das verstehe ich wieder nicht.
Ein Routinggraph kennt doch nur gerichtete Kanten. Das heißt, wenn ich in beiden Richtungen fahren darf, wird aus einem Weg zwei gemacht. Das ist bei Spurmapping wahrscheinlich ohnehin notwendig, wenn in der einen Richtung nämlich 2 und in der Gegenrichtung nur eien Fahrspur existiert.

Sind 2 Städte zum Beispiel über eine Schnellstraße mit jeweils 2 Spuren in jeder Richtung verbunden (also sind 4 Straßen eingetragen). Beim Routen würde dann versucht werden, die kürzeste Verbindung zwischen beiden Städten zu finden. Somit wird erst geprüft, wie weit die Strecke über die eine Spur ist und dann die andere. Die Kürzere der beiden Spuren wäre dann die Strecke, über die du geführt wirst. (Die anderen 2 Spuren werden nicht beachtet, da sie ja in die Gegenrichtung führen)
=> Es müssen 2 statt einer Berechnung angestellt werden. Ich hoffe wir reden hier nicht aneinander vorbei 😉

Ich hab mal gerade im Netz nach einem schönen Programm gesucht, womit man gut sieht, was ich meine.
Es heißt DijkstraVis
Beispiel mit 2 einzelnen Spuren
Beispiel mit nur einer Spur
Einfach runterladen und in dem Programm öffnen.

Aber wenn doch Einigkeit besteht, zum Spurenverbinden Relations zu verwenden, worüber sprechen wir denn dann? In Bezug auf Routing, nicht auf Spurmagging...
Es gibt dann ja nicht viel Gestaltungsspielraum

from=<way>:<lane>
via=<node>
to=<way>:<lane>

railrun wrote:

=> Es müssen 2 statt einer Berechnung angestellt werden. Ich hoffe wir reden hier nicht aneinander vorbei 😉

Ich denke doch das wir gerade aneinander vorbeigeredet haben. Denn meine Intention war nicht jede Spur als Highway zu erfassen, sondern nur jede Richtung.
Das wenn jede Spur erfasst ist, eine Vergrößerung des Routinggrafen zur Folge hat, ist mir klar.
Auch waren meine Bedenken, dass wenn man trotz 2 Streifigkeit je Richtung über die Mittellinie fahren dürfte, bekommen wir dann ein Problem mit den "zwei Wegen" So dass ich denke wenn man die Linie zum Überholen überfahren darf, dann ist ein Weg besser als zwei. Ist die Linie durchgezogen, dann haben zwei Wege nur noch einen "optischen" Nachteil.

viw wrote:

Ich denke doch das wir gerade aneinander vorbeigeredet haben. Denn meine Intention war nicht jede Spur als Highway zu erfassen, sondern nur jede Richtung.
Das wenn jede Spur erfasst ist, eine Vergrößerung des Routinggrafen zur Folge hat, ist mir klar.
Auch waren meine Bedenken, dass wenn man trotz 2 Streifigkeit je Richtung über die Mittellinie fahren dürfte, bekommen wir dann ein Problem mit den "zwei Wegen" So dass ich denke wenn man die Linie zum Überholen überfahren darf, dann ist ein Weg besser als zwei. Ist die Linie durchgezogen, dann haben zwei Wege nur noch einen "optischen" Nachteil.

Nein, das ist nicht nur ein optischer Nachteil. Ein paar Seiten weiter vorne in der Diskussion hier ist ausgiebig dargelegt, dass das mehrspurige Erfassen grundsätzlich die Kreuzungsgeometrien verkompliziert und somit die automatische Erzeugung von sinnvollen Routing-Anweisungen erschwert oder sogar nahezu unmöglich macht.

Nebenbei bemerkt: Das Erfassen als getrennte Wege bringt auch optisch Nachteile. Denn die einzelnen Wege sehen nur schoen aus, wenn man sehr stark in die Kartzenansicht hinein zoomt. Bei Uebersichtskarten werden Strassen aber deutlich breiter dargestellt, als sie es in Wirklichkeit sind. Wenn man die Spuren als getrennte Wege erfasst, sorgt das dann in der Darstellung zu einem gegenseitigen Verdecken. Wenn man das aber als einen Wege mit entsprechenden Tags erfasst, kann das der Renderer unabhaengig von der Zoomstufe sauber darstellen.

Gruss
Torsten

Entschuldigung das ich an die Routinganweisungen nicht gedacht habe. Aber auf den Routinggraph hat das keine Auswirkungen.
Was die Optik angeht, so kann man da geteilter Meinung sein. Wenn ich mir die Autobahnen auf der ÖPNV Karte ansehe, dann scheint das dort durchauslösbar zu sein. Auch bei Mapnik und den Eisenbahnlinien wird man in großen Zoomstufen das zweite Gleis nicht erkennen und das macht der von ganz alleine.

railrun wrote:

@chris66: Hast du die Grafik die du in Post 5 erwähnt hast organisieren können?

Ja, die bringt aber keine neue Erkenntnisse, im Prinzip ist dort nur ein Routinggraph als Beispiel
dargestellt.

Nur mal so als abschreckendes Beispiel:

Selbst grosse Firmen bekommen das Routing nicht mehr hin, wenn sie unnötig getrennte Wege fuer die Spuren benutzen:

http://maps.google.de/maps?saddr=Werfts … 9&t=m&z=16

Gruss
Torsten

Ist mir auch schon aufgefallen, wobei das GMaps Car-Routing seit deren Update generell
schlechter geworden ist, mMn.

Oft sind die Spuren ja so dicht zusammen, dass man bei der Start/Zieleingabe per Mausklick
die richtige Spur nur per Zufall trifft. 😉

de_muur wrote:

Nur mal so als abschreckendes Beispiel:

Selbst grosse Firmen bekommen das Routing nicht mehr hin, wenn sie unnötig getrennte Wege fuer die Spuren benutzen:

http://maps.google.de/maps?saddr=Werfts … 9&t=m&z=16

Gruss
Torsten

ohne das jetzt vor ort zu kennen, kann das doch durchaus sinn machen? je nachdem wo eben u-turn/abbiegeverbote sind.

//edit: wobei diese route wirklich toll ist 🙂
http://maps.google.de/maps?saddr=Werfts … 1&t=h&z=17

Jayjay01 wrote:

ohne das jetzt vor ort zu kennen, kann das doch durchaus sinn machen? je nachdem wo eben u-turn/abbiegeverbote sind.

Ich kennen es vor Ort, und das macht ueberhaupt keinen Sinn. Das kann man uebrigens auch in der Luftbildansicht klar erkennen, wenn man ordentlich rein zoomt. Die Verwendung von getrennten Wegen ist an dieser Stelle voellig unnoetig und offensichtlich alles andere als hilfreich.

In diesem speziellen Fall ist die von Google bestimmte Route uebrigens nicht nur ein fuerchterlicher Umweg, zusaetzlich fuehrt sie auch noch ueber Wege, die der Oeffentlichkeit gar nicht zugaenglich sind und zwar ueber das Marinearsenal.

wobei diese route wirklich toll ist 🙂
http://maps.google.de/maps?saddr=Werfts … 1&t=h&z=17

Ja, die ist noch schoener. Die andere hatte ich gestern leider am eigenen Leib erfahren muessen, als mich ein Android-Handy da hin lotsen sollte.

Gruss
Torsten

Für wie wichtig erachtet ihr das Abbilden der eigentlichen Strasse, sprich der geschlossenen Fahrbahndecke?

Zur Erklärung:

Eine Durchgangsstrasse geht durch einen Ort. Sie hat praktisch durchgehend die gleiche Breite. Lediglich die Markierung ändert sich.
Zunächst hat sie je eine Spur für beide Richtungen und rechts sind Parkplätze auf der Strasse markiert.
Dann enden die Parkplätze, die Vorwärtspur verschwenkt nach rechts und macht Platz für eine Verkehrsinsel in der Mitte.
Nach der Insel verschwenkt die Spur wieder zur Mitte und rechts sind wieder Parkbuchten.
Am Ende enden die Parkbuchten, die Geradeausspur schwenkt nach rechts und in der Mitte entsteht eine Linksabbiegerspur.
An allen Stellen hat die Strasse an sich die gleiche Breite.

Warum ich das als wichtig erachte?

Zum einen gibt es vielleicht mal einen Import amtlicher Daten, dort ist u.U. nur die Strasse(nbreite) angegeben, aber nicht die Markierung.
Ausserdem werden Ummarkierungen schneller mal gemacht, als die geschlossene Fahrbahndecke zu verändern.

Und zum anderen, wenn ich diese Strasse tagge, und die ist in der Realität schnurgerade, und ich gebe meine oben genannten Spuren an, wird sie wohl Schlangenlinien machen.

Das bringt mich wieder zu meinem Gedanken, nur die geschlossene Fahrbahndecke im Lanes-Tag zu beschreiben, und Fuss- und Radweg in den vorhandenen eigenen Tags (die dafür evt. noch erweitert werden müssten), aber im Way, zu belassen.

Ein Nachteil: Parkbuchten rechts auf der Strasse müsste ich woanders angeben als die links neben der Strasse.

railrun wrote:

hurdygurdyman wrote:

Tordanik wrote:

Das ist mit Fokus auf Abbiegespuren (also unmittelbar vor einer Kreuzung) entwickelt worden, nicht für das Spurlayout (z.B. Radspuren) entlang einer Straße. Und daher ist es in meinen Augen leider einfach zu kurz gedacht.
...

Für mich wäre das Fehlen einer Idee für Radspuren noch kein KO-Kriterium. Wie weiter oben beschrieben, kann da ja noch erweitert werden, denn Rom wurde...
Insgesamt finde ich den benshu-Ansatz gut, denn incl. plugin sieht das schon mal sehr mapperfrundlich aus. Lediglich bei den Spurlängen vom Abbiegepunkt aus rückwärts gerechnet, weiß ich nicht ob das renderer packen 🤔

Ich were mir das plugin mal daheim hinter meiner Linux-Kiste installieren und an einer Stelle hier testen.

Das klingt gut. Kannst ja mal berichten wie es aussieht 🙂

Dann berichte ich mal:
Die Installation des plugins war vollkommen problemlos über das in JOSM integrierte tool.
Ich habe mir bewusst erst einmal einen Bereich ausgesucht, in dem jeweils nur eine Abbiegespur vorhanden ist. Es handelt sich um diese kreuzungsfreie Auf-/Abfahrt
http://www.openstreetmap.org/?lat=48.33 … 8&layers=M
Folgende Abbiegevorgänge wurden bearbeitet:
1. http://www.openstreetmap.org/browse/node/258045671
2. http://www.openstreetmap.org/browse/node/258045658
3. http://www.openstreetmap.org/browse/node/265549774

Leider ist bing hier nicht sehr hoch aufgelöst, sodass ich erst einmal vor Ort (bei der Saukälte) die ungefähre Länge der Abbiegespuren anhand markanter Punkte ermitteln musste. Hierzu habe ich einen Bildschirmausdruck verwendet. (Für eine komplexere Kreuzung, die ich als nächstes angehe, habe ich mir schon einen Ausdruck mit WalkingPapers gemacht. Da werde ich dann die Längen abschreiten oder die Steine der einen Meter langen Bordsteinkanten zählen.)

Nach Anklicken des Abbiegepunktes fordert das plugin grundsätzlich, die Anzahl der lanes für alle sich dort treffenden ways anzugeben. Bei (z.B. wegen einer Brücke) gesplitteten ways, auf denen eine längere Abbiegespur verläuft, muss dies für alle betroffenen ways erfolgen. Danach erscheint dann die zu bearbeitende Kreuzung im Plugin-Fenster und man kann mit dem Zeichnen der Abbiegespuren und dann mit den Verbindungen zwischen den Spuren beginnen. Das ist einfach und intuitiv machbar. Die Relationen entstehen im Hintergrund automatisch. Allerdings meckert JOSM beim Abspeichern, dass es die Relationen „turnlanes:lengths" und „turnlanes:turns" nicht kennt.

Zu 1.
Hier habe ich die zwei restriction–Relationen testweise entfernt, da ja nun identische Informationen als positive Werte vorliegen. Bei 2. und 3. habe ich sie allerdings belassen, um die restriction auswertenden router nicht komplett aus dem Tritt zu bringen. Auf Dauer sollte man aber auf diese Doppelerfassung von Informationen verzichten.

Verwundert hat mich, dass turnlanes an diesem Punkt
http://www.openstreetmap.org/browse/node/259716674
und diesem
http://www.openstreetmap.org/browse/node/262197688
nicht „ansprang". Auch hier gibt es Abbiegespuren 🤔

Ob es Möglichkeiten gibt, das Plugin auf Linksverkehr umzustellen, ist mir nicht bekannt.

Wünschen würde ich mir noch eine Möglichkeit, über einen weiteren Relationstyp (turnlanes:direction) die Richtungsbezeichnungen z.B. über Autobahnspuren erfassen zu können, wodurch Renderer/Router weitere Details anzeigen könnten.

Mein einziger „Wermutstropfen" ist, dass beim Herauszoomem, um etwa sehr lange Abbiegespuren anzulegen, die Längenbeschriftung zu klein und unlesbar wird.

Mein Fazit:
Ein tolles Plugin und eine gute Möglichkeit, Abbiegespuren zu erfassen, die man weiter verfolgen sollte. Danke benshu. Ob Auswertungen damit umgehen können, muss aber noch getestet werden. Für weitere Überlegungen in diese Richtung ist es nun erforderlich, dass die Auswertungsfraktion beteiligt wird und deren Bedürfnisse einfließen.

P.S.:
Einigen wird auffallen, dass bei 1. und 2. die Wege
http://www.openstreetmap.org/browse/way/46821460
und
http://www.openstreetmap.org/browse/way/46518705
eigentlich jeweils als zwei oneways wegen der dazwischen befindlichen Insel anzulegen sind. Ich habe das bewusst erst einmal so belassen, um in einem weiteren Schritt zu prüfen, was bei derartigen späteren Änderungen im turnlanes-plugin zu beachten ist 😉

de_muur wrote:

Nur mal so als abschreckendes Beispiel:

Selbst grosse Firmen bekommen das Routing nicht mehr hin, wenn sie unnötig getrennte Wege fuer die Spuren benutzen:

http://maps.google.de/maps?saddr=Werfts … 9&t=m&z=16

Gruss
Torsten

Ich habe mir das im Rahmen meiner Spur-Recherchen in meiner Gegend mal genauer angeschaut. Es scheint so , als ob Google die Fahrtrichtungen überwiegend getrennt anlegt, sobald Abbiegespuren vorhanden sind.

Ich fand aber auch einzelne Stellen, an denen dies nicht der Fall ist 🤔
http://maps.google.de/maps?saddr=Werfts … 9&t=h&z=19

Grundsätzlich zu Plugins: Ich finde es gefährlich, dass hier schon Implementierungen entwickelt werden, obwohl das Taggingschema noch gar nicht ausgereift ist. Sobald es ein Plugin gibt, finden sich Leute, die es benutzen, und dann kommt gerade beim Spurtagging ein Wildwuchs im Datenbestand heraus.

Naja, zumindest führt es zu einem klar definierten Ergebnis, dass sich bei einer Entscheidung leicht (halb-)automatisch anpassen ließe. Dagegen kann man nicht jede von irgendjemandem privat beschlossene Variante aufspüren.

fkv wrote:

Grundsätzlich zu Plugins: Ich finde es gefährlich, dass hier schon Implementierungen entwickelt werden, obwohl das Taggingschema noch gar nicht ausgereift ist. Sobald es ein Plugin gibt, finden sich Leute, die es benutzen, und dann kommt gerade beim Spurtagging ein Wildwuchs im Datenbestand heraus.

Dann sag doch mal, was du von diesem Lösungsansatz hältst. Oder hast du vielleicht sogar einen viel besseren Vorschlag. Für mich ist dieses proposal und plugin erst einmal ein guter Ansatz mit Entwicklungspotential. Was daraus wird, entscheidet die Masse auch durch Akzeptanz.

hurdygurdyman wrote:

Dann sag doch mal, was du von diesem Lösungsansatz hältst.

Nichts. Es deckt nur einen kleinen Teil der Anforderungen ab, benötigt trotzdem Relationen, und Spurlängen in m anzugeben ist albern. Soll man mit dem Maßband auf der Straße herumgehen? Was ist, wenn der Way geteilt wird (z.B. Brücke, Geschwindigkeitsbeschränkung)?

Oder hast du vielleicht sogar einen viel besseren Vorschlag.

Siehe weiter vorn im Tread. Nochmal der Link: http://wiki.openstreetmap.org/wiki/User … ping_draft.

fkv wrote:

hurdygurdyman wrote:

Dann sag doch mal, was du von diesem Lösungsansatz hältst.

Nichts. Es deckt nur einen kleinen Teil der Anforderungen ab, benötigt trotzdem Relationen, und Spurlängen in m anzugeben ist albern. Soll man mit dem Maßband auf der Straße herumgehen? Was ist, wenn der Way geteilt wird (z.B. Brücke, Geschwindigkeitsbeschränkung)?

Oder hast du vielleicht sogar einen viel besseren Vorschlag.

Siehe weiter vorn im Tread. Nochmal der Link: http://wiki.openstreetmap.org/wiki/User … ping_draft.

Ich habe mir die verschiedenen Ansätze in diesem Thread und den verschiedenen Proposals zum Thema genauer angeschaut. Dazu gehört auch deins.

Im Wesentlichen besteht Einigkeit, dass die lanes als Bestandteil der ways abgebildet werden sollen. Es existieren jedoch verschiedene Vorschläge über die Gestaltung der key-value-Paare. Bevorzugt wird nach meiner Beobachtung der Ansatz, welcher die betroffenen lanes mit Trennzeichen dazwischen einem Key entsprechender Eigenschaft zugeordnet.
Dies gilt auch für den Vorschlag von benshu. Zusätzlich werden darin aber Relationen eingesetzt, wodurch erkennbar und auswertbar wird, wie es bei Verwendung der entsprechenden Spur nach dem Kreuzungs- bzw. Abzweigpunkt weitergeht. Außerdem hat dies den Vorteil, dass die lanes unabhängig von der way-Richtung abgebildet sind, was die Konstruktion robust gegen zufällige oder gewollte Drehungen der way-Richtung macht.

Zu deinem Einwand wegen der Spurlängen in Metern vom Kreuzungspunkt aus:
Bei hinreichender Auflösung von bing/Aerowest etc. brauchst du kein Maßband, denn in JOSM kann man messen. Wenn der Weg geteilt ist wie z.B. in meinem Fall 3 http://www.openstreetmap.org/browse/node/265549774 , kann das plugin vom Abbiege-/Kreuzungspunkt rückwärts über mehrere Wegteile arbeiten, sofern diese angaben zu lanes=* haben, was man auch im ersten Video des Proposals gut sieht.

Für mich ist diese anwenderfreundliche Erfassung von Straßenspuren kein „nur kleiner Teil der Anforderungen", auch wenn Radfahrer und Fußgänger noch nicht berücksichtigt sind. Mir stellt sich die Frage, ob es nicht besser ist, ein Tool zu haben mit dem wir zumindest Spuren für motorisierten Verkehr einfach erfassen können, oder ob wir weiter nur von einer eierlegenden Wollmilchsau träumen wollen.

Gerne bin ich bereit, auch andere Lösungsansätze auszuprobieren, wenn sie ein Mindestmaß an Anwenderfreundlichkeit bei der Eingabe erfüllen, was ich leider bei der Masse der vorliegenden Proposals noch nicht erkenne.

Außeerdem bewegen wir uns solange im spekulativen Bereich, wie wir nicht wissen, ob Auswertungen wie Renderer oder Router überhaupt mit diesen Daten etwas vernünftiges anfangen können. Bei einem derartig komplexen Bereich müssen wir dies in unsere Überlegungen einbeziehen.

things-change wrote:

Für wie wichtig erachtet ihr das Abbilden der eigentlichen Strasse, sprich der geschlossenen Fahrbahndecke?

Zur Erklärung:

Eine Durchgangsstrasse geht durch einen Ort. Sie hat praktisch durchgehend die gleiche Breite. Lediglich die Markierung ändert sich.
Zunächst hat sie je eine Spur für beide Richtungen und rechts sind Parkplätze auf der Strasse markiert.
Dann enden die Parkplätze, die Vorwärtspur verschwenkt nach rechts und macht Platz für eine Verkehrsinsel in der Mitte.
Nach der Insel verschwenkt die Spur wieder zur Mitte und rechts sind wieder Parkbuchten.
Am Ende enden die Parkbuchten, die Geradeausspur schwenkt nach rechts und in der Mitte entsteht eine Linksabbiegerspur.
An allen Stellen hat die Strasse an sich die gleiche Breite.

Warum ich das als wichtig erachte?

Zum einen gibt es vielleicht mal einen Import amtlicher Daten, dort ist u.U. nur die Strasse(nbreite) angegeben, aber nicht die Markierung.
Ausserdem werden Ummarkierungen schneller mal gemacht, als die geschlossene Fahrbahndecke zu verändern.

Und zum anderen, wenn ich diese Strasse tagge, und die ist in der Realität schnurgerade, und ich gebe meine oben genannten Spuren an, wird sie wohl Schlangenlinien machen.

Das bringt mich wieder zu meinem Gedanken, nur die geschlossene Fahrbahndecke im Lanes-Tag zu beschreiben, und Fuss- und Radweg in den vorhandenen eigenen Tags (die dafür evt. noch erweitert werden müssten), aber im Way, zu belassen.

Ich denke, dass laesst sich mit den verschiedenen Lanes-Vorschlaegen schon ganz gut beschreiben (mit einigen besser, mit anderen weniger). Aber man darf hier nicht aus den Augen verlieren, dass die Lanes in erster Linie eine funktionelle Beschreibung sein sollen. Die koennen und sollen keinen Ersatz fuer das hochaufloesende Luftbildabmalen sein. Umgekehrt kann letzteres aber auch nicht die funktionelle Beschreibung ersetzen.

Mit den Lanes-Vorschlaegen kannst du im Prinzip ja fuer jeden Abschnitt angeben, welche Spuren sich dort befinden, wie breit diese Spuren sind und wie die Trennung zwischen den Spuren aussieht. Der stationaere Zustand ist damit eigentlich hinreichend beschrieben. Beim Uebergang von einem Abschnitt zum anderen sehen die Vorschlaege zwar vor, dass man erfasst, welche Spur vom ersten Abschnitt zu welcher Spur im zweiten Abschnitt fuehrt, daraus wird ein Renderer aber sicherlich kein Pseudo-Luftbild konstruieren koennen.

Gruss
Torsten

hurdygurdyman wrote:

Zusätzlich werden darin aber Relationen eingesetzt, wodurch erkennbar und auswertbar wird, wie es bei Verwendung der entsprechenden Spur nach dem Kreuzungs- bzw. Abzweigpunkt weitergeht. Außerdem hat dies den Vorteil, dass die lanes unabhängig von der way-Richtung abgebildet sind, was die Konstruktion robust gegen zufällige oder gewollte Drehungen der way-Richtung macht.

Sicher, dass dadurch die Werte richtungsinvariant werden? Eigentlich haengt die Abfolge der Lane-Erfassung immer von der Richtung des Weges ab. (Hast du noch mal einen Link zu benshus Vorschlag?)

Für mich ist diese anwenderfreundliche Erfassung von Straßenspuren kein „nur kleiner Teil der Anforderungen"

Das bestimmt nicht. Aber nur, weil es fuer einen Vorschlag schon mal ein JOSM-Plugin gibt, ist der Vorschlag damit bestimmt nicht automatisch anwenderfreundlicher als andere. Oder soll das hier mal wieder das JOSM-Diktat fuer eine suboptimale Entscheidung sorgen?

Außeerdem bewegen wir uns solange im spekulativen Bereich, wie wir nicht wissen, ob Auswertungen wie Renderer oder Router überhaupt mit diesen Daten etwas vernünftiges anfangen können. Bei einem derartig komplexen Bereich müssen wir dies in unsere Überlegungen einbeziehen.

Sprach der Mensch, der nicht mal ohne spezielles Eingabe-Tool ueber die Moeglichkeiten der Datenerfassung werten kann :-)

Scherz beiseite: Niemand wird fuer die verschiedenen Vorschlaege mal eben so einen Beispielrouter mit Spurrouting zaubern. Das gibt es zur Zeit nicht fertig und das wird auch erst irgendwann in der Zukunft entstehen, wenn dafuer geeignete Daten als Grundlage existieren.

Fuer die automatische Auswertung waere es sicherlich einfacher, wenn die Verbindungen der Spuren zu den anderen Wegen ueber Relationen erfasst wuerden, als ueber Tags wie left, right oder so. Letztendlich muss sich die Auswertung daraus naemlich die Relation selber zusammen basteln, indem sie sucht, welche Weg jeweils gemeint ist. Das ist nicht unmoeglich, erhoeht aber den Aufwand fuer die Auswertung. Auf der anderen Seite erleichtert das aber die Erfassung, verlagert die Arbeit also vom Mapper zur Auswertung.

Eigentlich denke ich nicht, dass das ein geschickter Ansatz ist. Auf der anderen Seite halte ich den massiven Einsatz von Relationen auch fuer suboptimal. Und ich denke auch nicht, dass ein auf Relationen basierender Vorschlag mehrheitsfaehig ist. Denn aufgrund der Anzahl wird OSM doch von den Mappern getrieben.

Aber mal was anderes:
Wie kommen wir bei dem Thema weiter voran? Bisher haben wie nur Ideen und Vorschlaege gesammelt.

Gruss
Torsten

de_muur wrote:

Fuer die automatische Auswertung waere es sicherlich einfacher, wenn die Verbindungen der Spuren zu den anderen Wegen ueber Relationen erfasst wuerden, als ueber Tags wie left, right oder so. Letztendlich muss sich die Auswertung daraus naemlich die Relation selber zusammen basteln, indem sie sucht, welche Weg jeweils gemeint ist. Das ist nicht unmoeglich, erhoeht aber den Aufwand fuer die Auswertung. Auf der anderen Seite erleichtert das aber die Erfassung, verlagert die Arbeit also vom Mapper zur Auswertung.

Eigentlich denke ich nicht, dass das ein geschickter Ansatz ist. Auf der anderen Seite halte ich den massiven Einsatz von Relationen auch fuer suboptimal. Und ich denke auch nicht, dass ein auf Relationen basierender Vorschlag mehrheitsfaehig ist. Denn aufgrund der Anzahl wird OSM doch von den Mappern getrieben.

Da muss ich mich nochmal wiederholen: Ich behaupte mal, dass in 90%+ die Verbindung der Spuren eindeutig ist. Vielleicht sogar 95 oder noch mehr. Z.B. wenn die Spuren der Zielstrasse gleich der Ursprungsstrasse sind. Oder wenn 2 Rechtsabbiegerspuren in die beiden rechtesten Spuren der mehrspurigen Zielstrasse münden. Es macht keinen Sinn Relationen zwingend zu erfordern, wenn es nicht nötig ist.
Verbleibt die Minderheit der Kreuzungen, die wohl nicht ohne Relationen auskommen. Z.B. bei Abbiegung rechts und halbrechts.

Wenn ein Router damit nicht umgehen kann, können wir es gleich ganz lassen.

de_muur wrote:

Sicher, dass dadurch die Werte richtungsinvariant werden? Eigentlich haengt die Abfolge der Lane-Erfassung immer von der Richtung des Weges ab. (Hast du noch mal einen Link zu benshus Vorschlag?)

Das Plugin legt Relationen genau wie bei restrictions als from-via-to an. Hier der link zum proposal:
http://wiki.openstreetmap.org/wiki/Rela … turn_lanes

... Aber nur, weil es fuer einen Vorschlag schon mal ein JOSM-Plugin gibt, ist der Vorschlag damit bestimmt nicht automatisch anwenderfreundlicher als andere. Oder soll das hier mal wieder das JOSM-Diktat fuer eine suboptimale Entscheidung sorgen?

Sicher nicht. Weiter oben habe ich gesagt:
Mein Fazit:
Ein tolles Plugin und eine gute Möglichkeit, Abbiegespuren zu erfassen, die man weiter verfolgen sollte. Danke benshu. Ob Auswertungen damit umgehen können, muss aber noch getestet werden. Für weitere Überlegungen in diese Richtung ist es nun erforderlich, dass die Auswertungsfraktion beteiligt wird und deren Bedürfnisse einfließen.

Sprach der Mensch, der nicht mal ohne spezielles Eingabe-Tool ueber die Moeglichkeiten der Datenerfassung werten kann :-)

Mir gefällt die für diesen Fall bewusst gewählte Rolle als DAU. 😉 http://de.wiktionary.org/wiki/DAU
http://www.sprueche-ueber-sprueche.de/i … ueche-id=1 (die ersten drei 🙂 )

Scherz beiseite: Niemand wird fuer die verschiedenen Vorschlaege mal eben so einen Beispielrouter mit Spurrouting zaubern. Das gibt es zur Zeit nicht fertig und das wird auch erst irgendwann in der Zukunft entstehen, wenn dafuer geeignete Daten als Grundlage existieren.

An der Grundlage arbeiten wir.

Fuer die automatische Auswertung waere es sicherlich einfacher, wenn die Verbindungen der Spuren zu den anderen Wegen ueber Relationen erfasst wuerden, als ueber Tags wie left, right oder so. Letztendlich muss sich die Auswertung daraus naemlich die Relation selber zusammen basteln, indem sie sucht, welche Weg jeweils gemeint ist. Das ist nicht unmoeglich, erhoeht aber den Aufwand fuer die Auswertung. Auf der anderen Seite erleichtert das aber die Erfassung, verlagert die Arbeit also vom Mapper zur Auswertung.

Das Thema ist nicht trivial zu lösen. Die Frage für mich ist generell, wie wir - trotz und entgegen dem Mantra - den Spagat zwischen anwenderfreundlicher Erfassung und einem auswertungsfreundlichem Datenschema schaffen.

Eigentlich denke ich nicht, dass das ein geschickter Ansatz ist. Auf der anderen Seite halte ich den massiven Einsatz von Relationen auch fuer suboptimal. Und ich denke auch nicht, dass ein auf Relationen basierender Vorschlag mehrheitsfaehig ist. Denn aufgrund der Anzahl wird OSM doch von den Mappern getrieben.

http://www.sprueche-ueber-sprueche.de/i … ueche-id=1 (zweiter Spruch)
Wir haben soviel subopimales in OSM, über das wir hier wiederholt ergebnislos raufen. Ich bin offen für jede überzeugende Alternative.

fkv wrote:

Grundsätzlich zu Plugins: Ich finde es gefährlich, dass hier schon Implementierungen entwickelt werden, obwohl das Taggingschema noch gar nicht ausgereift ist. Sobald es ein Plugin gibt, finden sich Leute, die es benutzen, und dann kommt gerade beim Spurtagging ein Wildwuchs im Datenbestand heraus.

Das sehe ich auch so, die Leute hier, die meinen Spurrouting zu brauchen sollen erst einmal ein vom Menschen benutzbares Taggingschema entwickeln und es eine Weile testen, bevor man über Tools oder Plugins nachdenkt. Man darf nämlich nicht vergessen, das die Daten letztendlich vom Menschen verwaltet werden müssen!

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist? Es ist ja nicht so, das die Naviansage im Moment wie folgt ist:
"Wenn sie jetzt beim Autofahren aufmerksam aus dem Fenster sehen und auf den Verkehr achten sollten, werden sie erkennen, das da vorne im 200 m eine Ampelkreuung ist. Da sie sich auf einer mehrspurigen Straße befinden, sollten sie, wenn sie links abbiegen wollen, davon ausgehen, das sie sich evtl. in die Linksabbiegespur einordnen müssen." 😉

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht... ...ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Fabi2 wrote:

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist?
...

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht... ...ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Ich weiss nicht, ob ich dich jetzt missverstehe. Denn die Vorschlaege fuers Spur-Mapping hier zielen ja gerade darauf ab, dass man NICHT eigenstaendige Wege fuer die einzelnen Spuren eintraegt, weil genau das auch das Routing mit den bereits existierenden Navis verschlechtert/unbrauchbar macht.

Man kann die Flaechen bei OSM so detailliert erfassen, wie man lustig ist. Aber beim Routinggraphen ist es nun mal so, dass uebertriebene Details echt schaedlich sind. In meinen Augen geht es bei dieser Diskussion also darum, wie man den Mappern eine Loesung fuer die Detailerfassung bieten kann, die A) fuer eine automatische Auswertung (Spurrouting) in Zukunft vorbereitet und B) die bestehenden Navigationsloesungen nicht behindert sondern so gut wie moeglich unterstuetzt.

hurdygurdyman wrote:

Das Plugin legt Relationen genau wie bei restrictions als from-via-to an. Hier der link zum proposal:
http://wiki.openstreetmap.org/wiki/Rela … turn_lanes

Wie ich es schon vermutet hatte: Die Reihenfolge bei der Spurnummerierung haengt natuerlich von den Richtung des Weges ab, also kann man auch hier nicht beliebig die Wegrichtung aendern.

Ob man die Verbindungen der Spuren von einem Weg zum naechsten besser per Tags oder besser per Relation erfasst, bin ich mir nicht sicher. Aber der Vorschlag von benschu, die Laengen der Spuren in eine Relation zu packen, ist echt ganz schoen daneben.

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Gruss
Torsten

Fabi2 wrote:

...die Leute hier, die meinen Spurrouting zu brauchen sollen erst einmal ein vom Menschen benutzbares Taggingschema entwickeln und es eine Weile testen, bevor man über Tools oder Plugins nachdenkt. Man darf nämlich nicht vergessen, das die Daten letztendlich vom Menschen verwaltet werden müssen!

Neben dem turnlane-plugin gibt es noch zwei weitere, die in den Weiten der Wiki schlummern:
http://wiki.openstreetmap.org/wiki/User … s/Wayparts
zeigt einen Ansatz am Beispiel einer kreuzungsfreien Autobahn-Auf-/Abfahrt.
http://wiki.openstreetmap.org/wiki/Prop … lane_group
ist ein Versuch, Straßenspuren mit Rad- und Fußwegen unter einen Hut zu bringen.

Auch sie entstanden aus der Erkenntnis, dass mapping von Spuren für den normalen OSM-Mapper nicht ohne Eingabehilfe attraktiv wird bzw. überhaupt umsetzbar ist. Ich habe beide noch nicht getestet und kann sie deshalb auch nicht beurteilen. Aber deshalb muss man die Plugins ja nicht gleich verurteilen. Schließlich haben da Menschen Hirnschmalz und Zeit investiert um OSM voran zu bringen.
Eine Vision wäre, die Vorteile der verschiedenen Erfassungshilfen zu kombinieren, um dann ein anwenderfreundliches Tool für die Erfassung von Spuren bzw. Linienbündeln zu haben, welches die Daten robust und auswertungsfähig speichert.
Hier noch einige weitere links zum Thema:
http://wiki.openstreetmap.org/wiki/Rela … posed/Lane
http://wiki.openstreetmap.org/wiki/Prop … _Relations
http://wiki.openstreetmap.org/wiki/User … e_geometry
http://wiki.openstreetmap.org/wiki/Vors … enbereiche
http://wiki.openstreetmap.org/wiki/DE:Lane_Assist
Vielleicht bieten die auch noch ein paar gute Ideen 🤔

Fabi2 wrote:

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist? Es ist ja nicht so, das die Naviansage im Moment wie folgt ist:
"Wenn sie jetzt beim Autofahren aufmerksam aus dem Fenster sehen und auf den Verkehr achten sollten, werden sie erkennen, das da vorne im 200 m eine Ampelkreuung ist. Da sie sich auf einer mehrspurigen Straße befinden, sollten sie, wenn sie links abbiegen wollen, davon ausgehen, das sie sich evtl. in die Linksabbiegespur einordnen müssen." 😉

Aber es wäre doch z.B. hier
http://maps.google.de/maps?saddr=St%C3% … 9&t=h&z=18
hilfreich, wenn ich als Ortsfremder im tosenden Verkehr folgende Ansage bekäme:
„In hundert Metern auf die zweite Spur von links einordnen, dann nach hundert Metern links abbiegen und der zweiten Spur von links geradeaus bis zum Kreisverkehr folgen."

Fabi2 wrote:

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht... ...ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Richtungsabhängige Fahrspuren sind genauso Realität wie footways oder Hundekottütenspender, weshalb deren exklusive Erfassung in OSM durchaus berechtigt ist. Solange Spurwechsel möglich ist, sollten sie aber nicht als eigenständiger way angelegt werden, denn sie sind dann Bestandteil des highway.
Auch dieser thread enthält einige interessante Ansätze zur Problemlösung. Lasst uns doch die „best of" bündeln und daraus etwas Vernünftiges machen.
Unser Problem entsteht auch durch Linienbündel. Da wurde schon vor vier Jahren in einem Workshop dran gearbeitet.
http://wiki.openstreetmap.org/wiki/Wiki … %C3%BCndel
Die Erkenntnisse treffen heute noch zu. Leider sind wir immer noch nicht weiter. Das lanetool-plugin entstand übrigens infolge dieses Workshops.

de_muur wrote:

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Genau, denn es gilt:
„Wo kämen wir hin, wenn jeder sagte, wo kämen wir hin und keiner ginge, um zu sehen, wohin wir kämen, wenn wir gingen." (Kurt Marti)

de_muur wrote:

...
Wie ich es schon vermutet hatte: Die Reihenfolge bei der Spurnummerierung haengt natuerlich von den Richtung des Weges ab, also kann man auch hier nicht beliebig die Wegrichtung aendern.

Sehe ich nicht so 🤔
Schau dir mal diese Test-Relation an: http://www.openstreetmap.org/browse/relation/2006310
Die Information zur zusätzlichen Abbiegespur nach links steckt in der Relation als "lanes:extra" und bezieht sich nur auf die Fahrt in Richtung zum Abbiegepunkt "via". Siehe auch http://wiki.openstreetmap.org/wiki/Rela … owed_Turns
und im Beispiel http://wiki.openstreetmap.org/wiki/Rela … #Example_2 mit einer Rechtsabbiegespur.
Das ganze ist genauso robust wie die turn-restrictions , da from-via-to die Richtung bestimmt.

de_muur wrote:

Aber der Vorschlag von benschu, die Laengen der Spuren in eine Relation zu packen, ist echt ganz schoen daneben.

Hast du einen besseren? Diese Ansatz hat den "Vorteil", dass man ways nicht für Abbiegespuren zusätzlich teilen muss und dass bei ways, die wegen bridge, embankment usw schon geteilt sind, die zusätzlichen lanes nicht über alle Wegteile anlegen muss, wenn man die Spurlänge will, was aber aus Sicht des routing sinnvoll ist. ich sehe den Vorteil darin, dass man mit Ausnahme der "Standard-lanes" an den beteiligten ways selbst nicht weiter herumbasteln muss.
edit: Dreckfuhlerberüchtigung

Ist zwar neben der "Spur" - aber trifft auch hierzu.

hurdygurdyman wrote:

de_muur wrote:

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Genau, denn es gilt:
„Wo kämen wir hin, wenn jeder sagte, wo kämen wir hin und keiner ginge, um zu sehen, wohin wir kämen, wenn wir gingen." (Kurt Marti)

Ich hatte als Neuling vor einem Jahr schon einmal einen Vorschlag zu den vielen, viel zu vielen "Eigenständigkeiten des Taggen".

Es gibt ein "TEAM". Besetzt mit den "Urgesteinen von OSM". Diese treffen nach Diskussionen auch eine "Entscheidung". Und warum soll eine "Entscheidung" nicht auch noch einmal diskutiert werden, wenn neue Erkenntnisse es erfordern.

Etwas "Demokratie" unter die "Anarchie".

geri-oc wrote:

Etwas "Demokratie" unter die "Anarchie".

So wie bei der Lizenzdiskussion? "Sag ja oder verschwinde!"

weissnich,
ajoessen

ajoessen wrote:

geri-oc wrote:

Etwas "Demokratie" unter die "Anarchie".

So wie bei der Lizenzdiskussion? "Sag ja oder verschwinde!"

weissnich,
ajoessen

OT on:
Unter http://forum.openstreetmap.org/viewtopi … 19#p209019
habe ich mich unter anderem auch schon mal darüber ausgelassen 🙄
OT off:
Mindestens dieses Thema hier erfordert einfach die Zusammenarbeit von Mappern, Datenbank-Gurus und Entwicklern von Routern und ein gesundes Maß an Kompromissbereitschaft mit Fokus auf eine für alle praktikable Lösung.

hurdygurdyman wrote:

Sehe ich nicht so 🤔
...
Die Information zur zusätzlichen Abbiegespur nach links steckt in der Relation als "lanes:extra" und bezieht sich nur auf die Fahrt in Richtung zum Abbiegepunkt "via".

Sollst auch mal recht haben, das hatte ich nicht ordentlich gelesen.

Hast du einen besseren? Diese Ansatz hat den "Vorteil", dass man ways nicht für Abbiegespuren zusätzlich teilen muss und dass bei ways, die wegen bridge, embankment usw schon geteilt sind

Wenn wir aus allen anderen Gruenden jeweils die Wege teilen, dann halte ich es fuer eine ziemlich dumme Idee, bei einer weiteren Wegeigenschaft dieses Verfahren aufzugeben und ploetzlich etwas voellig neues einzufuehren. Alle anderen Tags koennte man auch per Relation an die Wege haengen. Aber wuerde dann da noch irgend jemand durchblicken?

Das ganze soll ja auch nicht nur per JOSM-Plugin bedienbar sein, sondern muss auch ohne spezielle Benutzeroberflaeche noch verstanden werden koennen.

=> Ein Grund mehr, warum man nicht ein Beispiel-JOSM-Plugin fuer die Bewertung eines Tagging-Schemas heranziehen sollte.

Gruss
Torsten

de_muur wrote:

...
Wenn wir aus allen anderen Gruenden jeweils die Wege teilen, dann halte ich es fuer eine ziemlich dumme Idee, bei einer weiteren Wegeigenschaft dieses Verfahren aufzugeben und ploetzlich etwas voellig neues einzufuehren.

Die Idee, Menschen und Güter mit Hilfe von damp- oder motorbetriebenen Fahrzeugen zu befördern , wurde anfangs auch als dumme Idee abgetan und hat sich doch durchgesetzt 😉

de_muur wrote:

Alle anderen Tags koennte man auch per Relation an die Wege haengen. Aber wuerde dann da noch irgend jemand durchblicken?
Das ganze soll ja auch nicht nur per JOSM-Plugin bedienbar sein, sondern muss auch ohne spezielle Benutzeroberflaeche noch verstanden werden koennen.

Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?

de_muur wrote:

=> Ein Grund mehr, warum man nicht ein Beispiel-JOSM-Plugin fuer die Bewertung eines Tagging-Schemas heranziehen sollte.

Das Tagging-Schema ergibt sich aus dem proposal und wird anhand dessen bewertet. Das Plugin setzt das Tagging-Schema anwenderfreundlich um. Beides ist sicher ausbaufähig, kann aber auch in Folge einer genaueren Betrachtung verworfen werden. Kommen wir zu dem Ergebnis, dass das Proposal unbrauchbar ist, macht das Plugin auch so keinen Sinn mehr.
Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).

hurdygurdyman wrote:

Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?

...

Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).

Und fuer mich zeigt das, dass diese Vorschlage einfach schon von sich aus zu kompliziert sind. Wenn die Laenge der Spuren nicht in einer Relation versteckt werden, dann braucht man dafuer auch kein extra Hilfswerkzeug.

Die exakte Beschreibung einer Kreuzung mit 7 Strassen mit jeweils 9 Spuren wird zwar immer kompliziert werden, ist zum Glueck ja aber nicht der Normalfall. Wenn in 99% der Faelle ein Konstrukt von einem durchschnittlichen Mapper nicht mehr ohne Hilfsmittel ueberblickt werden kann, dann ist das fuer OSM kein brauchbarer Ansatz.

Gruss
Torsten

de_muur wrote:

hurdygurdyman wrote:

Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?

...

Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).

Und fuer mich zeigt das, dass diese Vorschlage einfach schon von sich aus zu kompliziert sind. Wenn die Laenge der Spuren nicht in einer Relation versteckt werden, dann braucht man dafuer auch kein extra Hilfswerkzeug.

Die exakte Beschreibung einer Kreuzung mit 7 Strassen mit jeweils 9 Spuren wird zwar immer kompliziert werden, ist zum Glueck ja aber nicht der Normalfall. Wenn in 99% der Faelle ein Konstrukt von einem durchschnittlichen Mapper nicht mehr ohne Hilfsmittel ueberblickt werden kann, dann ist das fuer OSM kein brauchbarer Ansatz.

Gruss
Torsten

Die Welt ist nun einmal kompliziert. Nur weil dein Gehirn ständig vereinfacht und filtert kannst du dich überhaupt auf das wesentliche konzentieren. Das andere Personen andere Dinge wesentlich finden unterscheidet die Menschen. Damit wird das Modell dann aber leider auch kompliziert. Wenn es aber ein Hilfsmittel gibt mit dem man das ganze visuell drastellen kann, so kann man wie bei OSM 3D entweder probieren oder besser gleich noch wysiwyg zusammenklicken. Wer sagt denn das ÖPNV Relationen mit den ganzen Metarelationen einfach sind? Dennoch gibt es eine Gruppe von Mappern die sich damit beschäftigen und das auch auswerten.
Gleiches gilt übrigens für TMC.

Somit belasse ich es bei dem bisherigen Meinungsaustausch zu diversen plugins und proposals, der wohl in diesem Stadium keine Lösung erkennen lässt, und bringe deine berechtigte Frage wieder nach oben:

de_muur wrote:

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Also vielleicht nochmal die Probleme zusammenfassen!
Wir wollen gerne Spuren erfassen. Die einen für den ästetischen Aspekt (visuell) die anderen für gezieltes Routing.
Die Praxis bisher jede Straße eine Linie wenn keine bauliche Trennung (Sperrflächen doppelte Linie etc.)
Sie wird durch gute Luftbilder teilweise unterlaufen in dem jede Spur zu einer Linie wird.
Dies ist für alle Seiten unbefriedigend denn:
- Routinganweisungen werden so gut wie unmöglich
- Routing wird durch einen riesengroßen Routinggrafen unnötig erschwert (Rechenzeit)
- Spurwechsel Spurerkennung nach heutigem Stand nicht abbildbar.

- optisch sieht die Sache auch nicht besser aus. Da mehrer Straßen übereinander gezeichnet werden.

Lösungsversuche?
Straßen als Flächen erfassen. Damit wäre die Optik jedenfalls stark verbessert. Außerdem könnte Fuß- und Radwege sowie Parkstreifen einfach dargestellt werden.

Für das Routing ist das aber keine Lösung. Hier gabs den Vorschlag von Tags am Weg Relationen am Weg und schließlich auch Linie je Richtung (rechts mitte geradeaus) oder gar für jede Spur aber nicht als highway=*

Vielleicht können die einzelnen Verfechter Ihrer Lösung in zwei bis 4 Zeilen nochmal die Vorteile ihres Ansatzes herausstellen.

viw wrote:

Lösungsversuche?
Straßen als Flächen erfassen. Damit wäre die Optik jedenfalls stark verbessert. Außerdem könnte Fuß- und Radwege sowie Parkstreifen einfach dargestellt werden.

Für das Routing ist das aber keine Lösung.

Auch aus Flächen lässt sich ein Routinggraph errechnen und der muss nicht zwangsweise viel komplexer sein als jetzt. Auch könnte man ja beides (also Linie und Fläche erfassen). Aber beides löst wieder nicht das Spurenproblem beim Routing. Ich befürchte fast, dass das, was wir wollen, mit aktueller Navisoftware nicht machbar ist. Zumindest für Onlinerouter könnten aber Relationen, die die Spuren (sei es nun als Fläche oder Linie) zusammenfassen, helfen.

Ich würd gern für die Beispiele ein Foto einer etwas komplexeren Kreuzung einfügen, was darf denn als Quelle benutzt werden?

EDIT:

Hab grade gesehen, jemand hat ein weiteres Beispiel eingefügt. Vielleicht können die Ersteller der Alternativen dort vervollständigen?

things-change wrote:

Hab grade gesehen, jemand hat ein weiteres Beispiel eingefügt.

Ich kann halt Gedanken lesen.

Aber es ist klar, dass in diesem Beispiel mein Schema (Alternative B) abschreckend wirkt, da die Werte für lane_matching so lang sind. Da hilft es nichts, dass sie viel genauer sind als die Alternativen und im Ggs. zu diesen ein zuverlässiges Routing (auch für Fußgänger) ermöglichen. Vielleicht sollte man die Routinginfos für Fußgänger in ein anderes Tag auslagern bzw. auf eine gewisse Intelligenz des Routers vertrauen (der z.B. wissen muss, dass man auf einem Gehsteig oder Radweg umkehren kann, und als Normalfall annehmen kann, dass man an einer Ampel von jedem Gehsteig auf jeden anderen wechseln kann).

fkv wrote:

Aber es ist klar, dass in diesem Beispiel mein Schema (Alternative B) abschreckend wirkt, da die Werte für lane_matching so lang sind. Da hilft es nichts, dass sie viel genauer sind als die Alternativen und im Ggs. zu diesen ein zuverlässiges Routing (auch für Fußgänger) ermöglichen.

Ich denke, dass das die eigentlich entscheidende Frage ist: Was will man alles in einem Spurschema erfassen?

Ich denke (z.Z.), dass ein Schema um so besser ist, je mehr Informationen man damit kartieren kann. Das sieht natuerlich weniger uebersichtlich aus als ein Schema, dass nur ein Bruchteil der Informationen darstellen kann.

Insofern kann man die verschiedene Vorschlaege eigentlich nur sehr schwer vergleichen. Statt einfach ein Bild einer Kreuzung als Vorlage zu nehmen, bei dem jeder Vorschlag was anderes mapped, muesste man vielleicht besser klar definierte Einzelfaelle zur Unterscheidung nehmen, wo der Rest gezielt ausgeblendet wird.

Gruss
Torsten

de_muur wrote:

Fabi2 wrote:

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist?
...

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht... ...ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Ich weiss nicht, ob ich dich jetzt missverstehe. Denn die Vorschlaege fuers Spur-Mapping hier zielen ja gerade darauf ab, dass man NICHT eigenstaendige Wege fuer die einzelnen Spuren eintraegt, weil genau das auch das Routing mit den bereits existierenden Navis verschlechtert/unbrauchbar macht.

Generell ist es so, das man die Realität doch das getrennte Einreichnen eines Mapfeatures am besten beschreiben kann. Weil irgendwann kommt dann früher oder später eine ungewöhnliche Abbiegespur und das war es dann mit grobschlächtigen Tags wie "links" und "halb rechts", etc. Eben genau aus diesem Grund gibt es ja auch die "ein Objekt - ein Mapfeature"-Regel. Das gilt übrigens genauso für die straßenbegleitenden Fuß-/Radwege, usw. Damit sollte dann klar sein, das wenn man Abbiegespuren haben möchte, diese dann auch getrennte Objekte sein sollten.

Jetzt kann man darüber diskutieren, ob man die (Abbbiege)spuren nun als Linienbündel oder als Flächen in OSM abbildet. Wenn man aber bedenkt, das man die Vereinfachung von Flächen auf Linen bisher ja nur gemacht hat, weil die Genauigkeit des GPS/Luftbildes zum genauen Einzeichnen als Fläche nicht ausreicht, sollte man die Spuren auf Grund der beseren Realitätswiedergabe aus Flächen einzeichen, weil offenbar reicht ja die genauigkeit jetzt aus, sonst würde man sich doch nicht überhaupt mit dem Tagging der Spuren abgeben. oder man zeichnet doch nur Linienbündel, weil man zwar grob die Spuren, aber nicht genau deren Grenzen erkennen kann. Das wäre dann der alte Kompromiß, dismal eben nur eine Ebene (Spur statt Straßenabstraktion) tiefer. Wenn man die als Flächen an eine linienförmige Straße hängt, dann bräuchte man zusätzlich noch eine Relation die den Anschluß and die linienförmige Straße beschreibt.

de_muur wrote:

Man kann die Flaechen bei OSM so detailliert erfassen, wie man lustig ist. Aber beim Routinggraphen ist es nun mal so, dass uebertriebene Details echt schaedlich sind. In meinen Augen geht es bei dieser Diskussion also darum, wie man den Mappern eine Loesung fuer die Detailerfassung bieten kann, die A) fuer eine automatische Auswertung (Spurrouting) in Zukunft vorbereitet und B) die bestehenden Navigationsloesungen nicht behindert sondern so gut wie moeglich unterstuetzt.

Das ist doch alles nur eine Frage der Datenvorverarbeitung für das Routingprogramm. Wenn die Spuren alle mit von der Straße (highway=*) unterscheidbaren Tags versehen sind, kann man die in der Vorverarbietung doch leicht so zurechtfiltern, das von z.B. mehr als einer Abgiegespuren in die gleiche Richtung einfach nur noch eine Verbindung für den Routingraphen übrig behalten wird, womit sich das Komplexitätsproblem dann mehrheitlich in Luft auflösen dürfte.

Hallo allerseits,

hurdygurdyman hat mich auf die hier tobende Diskussion aufmerksam gemacht und gefragt, ob ich meine (hoffentlich vielen und tiefgehenden 😛) Überlegungen beisteuern möchte, die ich während der Entwicklung der turn-lanes-Proposal angestellt habe. Wie ich ihm bereits mitgeteilt habe, kann ich als einfacher Informatiker mit begrenztem Einblick ins Verkehrsingenieurswesen keine neuen Erkenntnisse beisteuern. Was ich beisteuern kann sind ein paar banale Feststellungen.

Bei OpenStreetMap handelt es sich um eine kollaborative Anstrengung Geodaten unserer Welt zu erfassen und der Allgemeinheit zur Verfügung zu stellen. Die Hoffnung ist, dass alle durch das gegenseitiges Geben und Nehmen profitieren. Auch wenn Vollständigkeit, Richtigkeit und Präzision das ultimative Ziel sind, so sind diese noch einen weiten Weg entfernt. Heute ist das Ziel die Diskrepanz zwischen den erfassten Daten und der Wirklichkeit soweit und schnell es geht zu minimieren. Um 1990 geisterte ein Paper mit dem Titel "Worse is Better" durch die Software-Engineering Welt. Es verbreitete die Idee, dass es besser ist jetzt etwas suboptimales zu haben, als auf ewig dem Heiligen Gral hinterherzujagen.

In der Einleitung meines Vorschlags schreibe ich "[a]t some point lanes will (hopefully) [be] mapped as individual ways or areas [...]". Einen Weg oder gar eine Fläche pro Spur zu haben ist der Heilige Gral, ein fantastischer Traum. Meiner Einschätzung nach sollte die erste Priorität sein den Detailgrad auf Teufel komm raus zu steigern. Wenn es später strikt mächtigere Modelle gibt um Spuren zu erfassen, so kann man Daten aus dem Modell von heute in das neue übertragen. Eines Tages wird es sich dabei vielleicht auch um eine Fläche pro Fahrstreifen handeln.

Ein paar Dinge zu meinem Proposal und dem zugehörigen Plugin: (Mein) Ziel war es, das Einpflegen der Spurinformationen so einfach wie möglich zu gestalten. In diesen Aspekt ist wirklich viel Arbeit geflossen. Dafür wurde aber ein wesentlicher Kompromiss gemacht, der hier zurecht angeprangert wurde: Längenangaben in Tags.
Da man die Länge einer Spur relativ bequem durch eine Art Drag-n-Drop manipulieren kann, ist eine andere Lösung nicht ohne weiteres möglich. Theoretisch könnte man jedes mal einen Knoten erzeugen um den Anfang der Spur zu beschreiben, aber man könnte den alten nicht ohne Weiteres löschen.

Ebenfalls zurecht kritisiert wurde die Tatsache, dass nur Abbiegespuren abgebildet werden können. Natürlich war das genau das angepeilte Ziel, aber hier wird ja nach einem mächtigeren Modell gesucht.

Ich erkenne die genannten Schwächen meines Vorschlags im Rahmen dieser Diskussion an. Nichtsdestotrotz finde ich, dass es zusammen mit dem bestehenden lanes-Tag eine fürs erste akzeptable Lösung ist. Nichtzuletzt weil das Erfassen der Daten durch das Plugin so einfach ist. Der Quellcode des Plugins ist Open-Source unter der GPL, wobei ich ihn bei guter Begründung auch gerne unter einer liberaleren Lizenz weitergeben würde. Ich für meinen Teil würde mich freuen, wenn jemand ein benutzerfreundliches Plugin für ein komplexeres Fahrstreifenmodell schreiben würde.

Abschließend möchte ich unterstreichen, dass es sich bei obigen Feststellungen um meine bescheidene Meinung handelt. Die hier zu fällende Entscheidung sollte von Leuten getroffen werden, die tiefer mit dem OSM-Projekt verstrickt sind als ich. In diesem Sinne werde ich mich aus der weiteren Disussion heraushalten, sofern es keine rein technischen Fragen gibt.

@benshu:

Das was du vor hast, ist in etwa so, als wenn du deinen Heimatort auf Grund der "Einfachheit" als Punkt mappst und dann ein Plugin schreibts, um passende Tags für die Repräsentation der Häuser, Straßen, etc. hinzuzufügen.

Einfach ist ein Modell, dann, wenn man es, egal mit welchem Editor, als Mensch nachvollziehen und bearbeiten kann. OSM setzt ja auf die manuelle menschliche Pflege von XML-Tags, wenn man nicht wollen würde, das menschen die Berabeiten, dürften wir nur noch irgendwelche Frontends zur Bearbeitung der Geodaten benutzen.

Was ist denn das Problem dabei, wenigstens die Spuren als Linien zu mappen? Weil wenn man die dieses Detail der Realität drin haben möchte, kann man es ja auch gleich richtig machen. Spätestens bei der Datenverarbeitung muß man ja sonst eh künstlich die Spuren erzeugen, wobei dann solche Krämpfe dabei herauskommen wie z.B. die --make-cycleways-Option von mkgmap. Da gibts dann schöne gerade Linien neben der Straße, die mit der Realität meist genau Nichts zu tun haben.

Fabi2 wrote:

@benshu:

Das was du vor hast, ist in etwa so, als wenn du deinen Heimatort auf Grund der "Einfachheit" als Punkt mappst und dann ein Plugin schreibts, um passende Tags für die Repräsentation der Häuser, Straßen, etc. hinzuzufügen.

Äh, du hast dir das Plugin und die Videos einmal angeschaut? Den Vergleich versteh ich jetzt nicht...

Fabi2 wrote:

Einfach ist ein Modell, dann, wenn man es, egal mit welchem Editor, als Mensch nachvollziehen und bearbeiten kann. OSM setzt ja auf die manuelle menschliche Pflege von XML-Tags, wenn man nicht wollen würde, das menschen die Berabeiten, dürften wir nur noch irgendwelche Frontends zur Bearbeitung der Geodaten benutzen.

[IRONIE]Ich hab meinen Mechaniker gefragt, ob man nicht einen Motor bauen könnte, der nur aus einem Teil besteht, damit ich ohne Probleme daran rumschrauben kann...[/IRONIE]
Komplizierte Sachverhalte lassen sich nun einmal nicht einfach darstellen.

Fabi2 wrote:

Was ist denn das Problem dabei, wenigstens die Spuren als Linien zu mappen?

Wegen dem Routinggraphen vielleicht?!

Fabi2 wrote:

Weil wenn man die dieses Detail der Realität drin haben möchte, kann man es ja auch gleich richtig machen. Spätestens bei der Datenverarbeitung muß man ja sonst eh künstlich die Spuren erzeugen, wobei dann solche Krämpfe dabei herauskommen wie z.B. die --make-cycleways-Option von mkgmap. Da gibts dann schöne gerade Linien neben der Straße, die mit der Realität meist genau Nichts zu tun haben.

Hauptsache es sieht schön aus... Aber Navigation kannst du dann auch vergessen... Ziel verfehlt... Meine Meinung...

railrun wrote:

Fabi2 wrote:

@benshu:

Das was du vor hast, ist in etwa so, als wenn du deinen Heimatort auf Grund der "Einfachheit" als Punkt mappst und dann ein Plugin schreibts, um passende Tags für die Repräsentation der Häuser, Straßen, etc. hinzuzufügen.

Äh, du hast dir das Plugin und die Videos einmal angeschaut? Den Vergleich versteh ich jetzt nicht...

Wieso, das hast du doch halbwegs verstanden, siehe deine Aussage:

railrun wrote:

[IRONIE]Ich hab meinen Mechaniker gefragt, ob man nicht einen Motor bauen könnte, der nur aus einem Teil besteht, damit ich ohne Probleme daran rumschrauben kann...[/IRONIE]

Halbwegs deshalb, weil ein Modell eine begrenzte und überschaubare Menge an Varianten ohne Probleme abbilden kann. Oder überschaust du alle Varianten die in der Realität vorkommen, um ein für alle passendes Modell bauen zu können? Außerdem sammeln wie geographische Objekte in einer Datenbank und da läßt sich ein linienförmiges Objekt mit einem bestimmten Verlauf und einer bestimmten Länge nun mal am besten als Weg erfassen.

Extra für dich wiederhole ich hier noch mal meine Argumentation von oben:

Einfach ist ein Modell, dann, wenn man es, egal mit welchem Editor, als Mensch nachvollziehen und bearbeiten kann. OSM setzt ja auf die manuelle menschliche Pflege von XML-Tags, wenn man nicht wollen würde, das Menschen die bearbeiten, dürften wir nur noch irgendwelche Frontends zur Bearbeitung der Geodaten benutzen.

Fazit: Man muß es auch mit z.B. Potlatch, Merkaartor, usw. bearbeiten können.

railrun wrote:

Komplizierte Sachverhalte lassen sich nun einmal nicht einfach darstellen.

Was ist an einer Linie mit passenden Tags denn so kompliziert? Das stellt doch eine wie auch immer geartete Spur ausreichend genau da!

railrun wrote:

Fabi2 wrote:

Was ist denn das Problem dabei, wenigstens die Spuren als Linien zu mappen?

Wegen dem Routinggraphen vielleicht?!

[ ] Ich habe das obige Posting zum Thema Routinggraph gelesen.
[ ] Ich habe die Argumentation versucht zu verstehen.

railrun wrote:

Fabi2 wrote:

Weil wenn man die dieses Detail der Realität drin haben möchte, kann man es ja auch gleich richtig machen. Spätestens bei der Datenverarbeitung muß man ja sonst eh künstlich die Spuren erzeugen, wobei dann solche Krämpfe dabei herauskommen wie z.B. die --make-cycleways-Option von mkgmap. Da gibts dann schöne gerade Linien neben der Straße, die mit der Realität meist genau Nichts zu tun haben.

Hauptsache es sieht schön aus... Aber Navigation kannst du dann auch vergessen... Ziel verfehlt... Meine Meinung...

Wieso soll man da die Navigation vergessen können? Meine Argumente hab ich ja schon in den Vorpostings angeführt.

Fabi2 wrote:

Wieso soll man da die Navigation vergessen können? Meine Argumente hab ich ja schon in den Vorpostings angeführt.

Die Antwort auf deine Frage steht auf den vorangehenden 7 Seiten dieser Diskussion. Da hat man wenig Lust, sich nochmal mit deinen Argumenten auseinanderzusetzen.

Bzgl. der geforderten Einfachheit stimme ich allerdings mit dir ueberein. Nur weil es halt sehr komplizierte Faelle gibt, bei denen zwangslaeufig auch das Mapping kompliziert wird, heisst das nicht, dass das Mapping von einfachen Faellen auch kompliziert sein muss.

Gruss
Torsten

de_muur wrote:

Fabi2 wrote:

Wieso soll man da die Navigation vergessen können? Meine Argumente hab ich ja schon in den Vorpostings angeführt.

Die Antwort auf deine Frage steht auf den vorangehenden 7 Seiten dieser Diskussion. Da hat man wenig Lust, sich nochmal mit deinen Argumenten auseinanderzusetzen.

Bzgl. der geforderten Einfachheit stimme ich allerdings mit dir ueberein. Nur weil es halt sehr komplizierte Faelle gibt, bei denen zwangslaeufig auch das Mapping kompliziert wird, heisst das nicht, dass das Mapping von einfachen Faellen auch kompliziert sein muss.

Ja, ich geb ja zu, ich hab die vorherigen Seiten nur mal schnell durchgesehen und leider habe ich beim Überfliegen der so mal geschätzt 90% Diskussion über wenig taugliche Vorschläge in Form von Zusatztags, übersehen, das es auch schon min. einen zum Einzelmapping gab. Das ist definitiv der bessere Ansatz für das Problem, weil wenn man es sich eine Weile überlegt, ist doch schon alles da:

highway=*
lanes=*
oneway=yes
maxspeed=*

damit kann man fast alles taggen. Für die Spur mit Doppelnutzung und Sperrlinien habe ich dann noch:

barrier=other_direction oder barrier=contraflow (abstrakte Barriere in Form des Gegenverkehrs in der Mitte der doppelt genutzten Spur)
barrier=street_marking (Barriere in Form von Markierungen, kurz vor dem Ende der Spur)

Naturlich kann man die Spuren die mit Sperrlinien enden in die entsprechenden Richtungen optional auch ganz weglassen.
Das war es erst mal was ich gerade so schnell gesehen habe, ich seh das noch mal genau durch ob noch fehlen sollte.

Fabi2 wrote:

...
Ja, ich geb ja zu, ich hab die vorherigen Seiten nur mal schnell durchgesehen und leider habe ich beim Überfliegen der so mal geschätzt 90% Diskussion über wenig taugliche Vorschläge in Form von Zusatztags, übersehen, das es auch schon min. einen zum Einzelmapping gab. Das ist definitiv der bessere Ansatz für das Problem, weil wenn man es sich eine Weile überlegt, ist doch schon alles da:

highway=*
lanes=*
oneway=yes
maxspeed=*

damit kann man fast alles taggen.
...

Ich denke, wir müssen hier unterscheiden nach
1. Verwendbarkeit der Daten für Renderer als geografische Information
2. Auswertbarkeit zum (vorausschauenden) Routing
An diesem Spagat scheitern wohl die meisten Ansätze, zumal auch noch der Anspruch besteht, in dem Schema das gesamte Linienbündel incl. bus, tram, footway und cycleway sowie aller möglichen Trennungen dazwischen erschlagen zu wollen. Und dann soll das alles auch noch für den Mapper transparent und ohne Tools erfassbar sein 🙄
Warum konzentrieren wir uns nicht auf das Thema dieses threads "Routing und Spurmapping", welches in der Masse der Fälle nur Straßen (und selten auch Radwege) betrifft. Mir ist eine Lösung für 80-95 % der Fälle lieber als für 100 % keine Lösung.

P.S. In diesem Sinne möchte ich auch benshu danken, dass er sich hier gemeldet hat

hurdygurdyman wrote:

Warum konzentrieren wir uns nicht auf das Thema dieses threads "Routing und Spurmapping", welches in der Masse der Fälle nur Straßen (und selten auch Radwege) betrifft. Mir ist eine Lösung für 80-95 % der Fälle lieber als für 100 % keine Lösung.

Warum? Weil sonst immer andere Dinge passieren werden:
http://www.openstreetmap.org/?lat=48.14 … 8&layers=M

Das hat mich doch echt gewundert wie hier in der Dachauer Straße zwei Straßenbahngleise gezeichnet werden konnten. Und genau das wird dir nachher dein schönes Schema zerstören. Denke ich jedenfalls. Im Gegensatz zu einem reinen Autonavi ist OSM eben für alle da. Sogar Fahrradfahrer und Straßenbahnbenutzer. Der Anspruch geht sogar noch weiter. Auch blinde Menschen sollen alle relevanten Informationen finden. Wie bitte soll das bewerkstelligt werden?

Ich möchte gerne noch diese schon ältere Wikiseite ins Rennen werfen:
http://wiki.openstreetmap.org/wiki/DE:W … ir_routing

Ich hoffe ihr könnt erahnen was diese Spezifikation für Auswirkungen auf die Daten haben würde, wenn sie wirklich konsequent umgesetzt werden würden. Aber das rede ich ja auch schon viel zu lange.

viw wrote:

Warum? Weil sonst immer andere Dinge passieren werden:
http://www.openstreetmap.org/?lat=48.14 … 8&layers=M

Das hat mich doch echt gewundert wie hier in der Dachauer Straße zwei Straßenbahngleise gezeichnet werden konnten. Und genau das wird dir nachher dein schönes Schema zerstören. Denke ich jedenfalls. Im Gegensatz zu einem reinen Autonavi ist OSM eben für alle da. Sogar Fahrradfahrer und Straßenbahnbenutzer. Der Anspruch geht sogar noch weiter. Auch blinde Menschen sollen alle relevanten Informationen finden. Wie bitte soll das bewerkstelligt werden?

Ich möchte gerne noch diese schon ältere Wikiseite ins Rennen werfen:
http://wiki.openstreetmap.org/wiki/DE:W … ir_routing

Ich hoffe ihr könnt erahnen was diese Spezifikation für Auswirkungen auf die Daten haben würde, wenn sie wirklich konsequent umgesetzt werden würden. Aber das rede ich ja auch schon viel zu lange.

Also geht es doch um die eierlegende Wollmilchsau für den dümmsten anzunehmenden Mapper.
Fange ich mal hinten an:
Renderer setzen Informationen optisch um und suchen sich je nach Zielsetzung und Genauigkeit die passenden Daten in OSM dazu. Je nach Zoom-Level wird generalisiert. Router hingegen können ohne grafische Darstellung anhand der Daten den geeigneten Weg berechnen und darstellen.
Nach umfangreichem Studium vieler Vorschläge und Überlegungen in der Wiki denke ich über eine Lösung nach, die durch
http://wiki.openstreetmap.org/wiki/Wiki … %C3%BCndel
und hier speziell das Fazit von Tordanik angeregt wurde.
Es wird ein neuer key lane=* eingeführt. Sobald mehrere Spuren mit verschiedenen Eigenschaften eines highway=* vorhanden sind und der Wechsel zwischen diesen für Verkehrsteilnehmer physisch möglich ist, werden entsprechende lane=* parallel zum highway angelegt, was bei hochauflösenden Bildern als Grundlage möglich wird. Diese lane=* können mit entsprechenden Zusatz-tags genau wie highway=* versehen werden, um weitere Eigenschaften zu definieren.

Somit steht es den Renderern frei, je nach Zielsetzung oder Generalisierung die für sie wichtigen Informationen aus highway und/oder lane herauszulesen. Router können Informationen aus highway und lane je nach Bedürfnis und Verkehrsmittel verwenden.

Dies ist momentan noch ein Gedankenspiel, das ich noch an Beispielen testen und verfeinern muss. Die Straßenbahn auf der Dachauer Straße wäre außen vor, weil kein physischer Spurwechsel möglich/erlaubt ist 😉 Aber ich bin gespannt auf eure Argumente, weshalb das nicht gehen soll 🤔

hurdygurdyman wrote:

Dies ist momentan noch ein Gedankenspiel, das ich noch an Beispielen testen und verfeinern muss. Die Straßenbahn auf der Dachauer Straße wäre außen vor, weil kein physischer Spurwechsel möglich/erlaubt ist 😉

Das musst du mir jetzt nochmal genauer erläutern. Wie würdest du die Straßenbahn auf der Dachauerstraße in deinem System erfassen? Als zwei Spuren oder als zwei Highways?

Falls du zu einer Linie tendierst mag ich dir kurz das Problem erläutern:
http://www.openstreetmap.org/?lat=51.03 … 8&layers=M

http://maps.google.de/?ll=51.03529,13.8 … 9,,0,31.33

Wie willst du also kenntlich machen aus welchem Gleis man hier abzweigen darf. Die Idee mit Einbahnstraßen kannst du gleich verwerfen. Dies sind keine Einbahnstraßen. Sie werden in beiden Richtungen befahren mal vorwärts mal rückwärts. Sowie es der Betrieb erfordert. Früher noch häufiger als heute.

Auch diese Stelle kann man nach deinem Modell nur schwer nachbilden: http://maps.google.de/?ll=51.038477,13. … .19,,0,2.3

Bedenke insbesondere die Abgrenzung zu diesem Beispiel hier:
http://maps.google.de/?ll=51.113357,13. … 3,,0,-3.34

Beim ersten ist nämlich mit der Straßenbahn im Gegenverkehr zu rechnen, während beim zweiten die Straßenbahn in Mittellage von beiden Fahrspuren recht unabhängig fährt und die Gleise zum überholen verwendet werden können.

viw wrote:

Das musst du mir jetzt nochmal genauer erläutern. Wie würdest du die Straßenbahn auf der Dachauerstraße in deinem System erfassen? Als zwei Spuren oder als zwei Highways?
...

Das ist doch einfach. Solltest du meine Idee genau gelesen haben geht es um Spuren als Bestandteil von highway=*. Straßenbahn ist railway=tram. In den von dir gezeigten Beispielen handelt es sich um konkurrierende Verkehrssysteme auf der gleichen Fläche. Die ways überlagern sich. Den railway=tram zeichne ich somit als selbstständigen way über die Straße. Das hat mit den lane=* des highway nichts zu tun.

Weiterhin gehe ich davon aus, dass Straßenbahnen als Schienensystem keine routing-Informationen aus OSM beziehen und niemals beziehen werden, da die Weichen durch andere technische Eingriffe gestellt werden. Sollte es um die Abbildung von Straßenbahnlinien gehen, kann man das über die bekannten Relationen lösen.

Edit:
Ich habe mir mal die Königsbrücker Landstraße angeschaut:
http://www.openstreetmap.org/?lat=51.11 … 8&layers=M
Dort sind highway=secondary und railway=tram auf dem gleichen way gemappt und somit auch konkurrierend.

hurdygurdyman wrote:

viw wrote:

Das musst du mir jetzt nochmal genauer erläutern. Wie würdest du die Straßenbahn auf der Dachauerstraße in deinem System erfassen? Als zwei Spuren oder als zwei Highways?
...

Das ist doch einfach. Solltest du meine Idee genau gelesen haben geht es um Spuren als Bestandteil von highway=*. Straßenbahn ist railway=tram. In den von dir gezeigten Beispielen handelt es sich um konkurrierende Verkehrssysteme auf der gleichen Fläche. Die ways überlagern sich. Den railway=tram zeichne ich somit als selbstständigen way über die Straße. Das hat mit den lane=* des highway nichts zu tun.

Weiterhin gehe ich davon aus, dass Straßenbahnen als Schienensystem keine routing-Informationen aus OSM beziehen und niemals beziehen werden, da die Weichen durch andere technische Eingriffe gestellt werden. Sollte es um die Abbildung von Straßenbahnlinien gehen, kann man das über die bekannten Relationen lösen.

Edit:
Ich habe mir mal die Königsbrücker Landstraße angeschaut:
http://www.openstreetmap.org/?lat=51.11 … 8&layers=M
Dort sind highway=secondary und railway=tram auf dem gleichen way gemappt und somit auch konkurrierend.

Es geht mir nicht darum, wie es jetzt gemacht ist, sondern wie es in Zukunft gemacht werden soll. Du würdest also mit deinem Beispiel sagen, dass obwohl die Straßenbahn auf der Straße fährt lieber zwei Gleise einzeichnen und dann die Straße als highway in die Mitte legen. Gerade das Beispiel zwei an der Ludwig-Hartmann-Straße ist denke ich nicht unrelevant fürs Routing. Denn Ob mir auf meiner Fahrspur eine Straßenbahn entgegenkommt oder ob die wie in Nürnberg neben der Straße fährt ist denke ich ein entscheidender Unterschied. Oder nicht?

Auch habe ich noch nicht verstanden, wie du dann die vielen Linien lane=* dann einem highway=* zuordnen möchtest. Eventuell könnte das aber notwendig sein. Wenn wir uns an die Anfänge von navis erinnern, wo die nicht unterscheiden konnten ob man auf der Autobahn oder der Straße daneben fährt.
Das zweite interessante Kriterium ist bei dir dass hier Lanes angelegt werden solange man physisch dazwischen hin und her wechseln kann. Wie willst du damit dies hier abbilden:
http://maps.google.de/?ll=51.060083,13. … .58,,0,4.1

Aber auch die Stelle scheint mir interessant zu sein: http://maps.google.de/?ll=51.041718,13. … 6.89,,0,-4
Vor allem in Hinblick auf die Fußwege. Kann man hier nun die Straße überqueren oder nicht der Autofahrer kann jedenfalls die Spur nicht wechseln.

@viw:
Bevor ich mir jetzt hier die Finger wund tippe, werde ich deine Fragen in Ruhe bedenken.
Ich sagte, es sei ein Denkansatz, und danke dir für deine Problemkandidaten zur Anregung meines Hirnschmalzes.

Lasst mich jetzt erst mal basteln. Ich melde mich dann wieder, bin aber für weitere Anregungen und Kritiken offen.

Hier habe ich doch noch was für dich. Wie möchtest du das http://maps.google.de/?ll=52.441773,13. … 6,,0,12.31

von dem http://maps.google.de/?ll=48.143315,11. … =12,0,,0,0 unterscheiden.

Du malst den highway in die Mitte und dann links und rechts die Straßenbahn. Die hat aber keinen Bezug zum highway.
Solltest du die Straßenbahn auf die Fahrspur legen, dann bedenke die Königsbrücker Straße ab dem 30er Schild. Dort sind dann plötzlich zwei Gleise in der Mitte. Es gibt dann also keine Mittelspur mehr und nur noch halbe Spuren neben den Straßenbahngleisen.

Ich würde dazu tendieren, im Falle der Königsbrücker Landstraße drei parallele Wege zu erfassen, einmal den Highway (+ eventuell Lane für die Mittelspur) in der Mitte und dann zwei Lanes rechts und links davon. Vor dem 30er Schild die Straßenbahn auf dem mittleren Weg (ob nun als eigener Weg mit den gleichen Knoten oder direkt am Weg sei dahingestellt) und danach auf den seitlichen Lanes. Ich denke, das gibt die Situation am ehesten wieder.

Zu den beiden letztgenannten Beispielen: Beim ersten 5 Ways: Ein Highway in der Mitte, dann rechts und links je eine Lane, dann rechts und links je ein Railway. Beim zweiten nur 3 Ways, ein Highway in der Mitte und zwei Lanes rechts und links davon, die auch die Straßenbahn enthalten.

hurdygurdyman wrote:

Ich denke, wir müssen hier unterscheiden nach
1. Verwendbarkeit der Daten für Renderer als geografische Information
2. Auswertbarkeit zum (vorausschauenden) Routing
An diesem Spagat scheitern wohl die meisten Ansätze, zumal auch noch der Anspruch besteht, in dem Schema das gesamte Linienbündel incl. bus, tram, footway und cycleway sowie aller möglichen Trennungen dazwischen erschlagen zu wollen. Und dann soll das alles auch noch für den Mapper transparent und ohne Tools erfassbar sein 🙄

Man muß da sagen, das für das Routing die Daten doch eh, je nach Gerät passend aufbereitet werrden müssen, gerade wenn man solche Sachen wie Anweisungen auf Spurebene realisieren will, also kommt man um um die Vorverarbeitung nicht drum herum. Die Frage ist da eher, wie mancht man das Tagging so, das der Router leichter das Zug was ihn nicht interessiert ausortiern kann.

Spätestens jetzt für das Mapping auf Spurebene braucht man eine type=street-Relation, für die Straße, wo alles an Wegen/Spuren drin ist, was die Straße mit Namen x darstellt. Das ist immer noch besser/handhabbarer als nur mit Hilftools bearbeitbare Tags.

Dann muß man klar per Tag (z.B. lane=yes) zwischen "das die Straße als ein Weg" und "ab hier wurde sie in Einzelspuren aufgesplittet" unterscheiden können. Das ist wichtig, damit das auch der Router kann und dann z.B. bei 5 Einzelspuren (1x links, 1x links+geradeaus, 2x geradeaus, 1x rechts), doppelte Richtungen nach folgenden Schema rauswerfen kann: Ah, da kann man rechts fahren, OK rechts zum Routingsgraphen hinzugefügt. Ah, dann kann man rechts und geradeaus fahren, rechts hab ich für die Richtung schon, wird in die Tonne getreten, geradeaus noch nicht: wird zum Routingsgraphen hinzugefügt. usw. Damit kann man dann die Daten der Einzelwege auch passend fürs Routing vereinfachen.

errt wrote:

Ich würde dazu tendieren, im Falle der Königsbrücker Landstraße drei parallele Wege zu erfassen, einmal den Highway (+ eventuell Lane für die Mittelspur) in der Mitte und dann zwei Lanes rechts und links davon. Vor dem 30er Schild die Straßenbahn auf dem mittleren Weg (ob nun als eigener Weg mit den gleichen Knoten oder direkt am Weg sei dahingestellt) und danach auf den seitlichen Lanes. Ich denke, das gibt die Situation am ehesten wieder.

Die Frage ist ob du vor dem 30er Schild die Mittlere Spur zum überholen ignorierst oder ob nach dem 30er Schild eine Spur in der Mitte zu viel ist. Aber um es noch mal platisch zu machen. Das Problem ist das hier wieder von Pkws ausgegangen wird. Denn ein Zweirad (motorrad oder Fahrrad) können auch nach dem 30er Schild die Straßenbahn rechts überholen. Pkws können das nur davor.
Das gleiche Problem tritt übrigens bei überbreiten Fahrspuren auf.
http://maps.google.de/?ll=51.0583,13.72 … 8,,0,11.09
die Rechte Spur ist breit genug für zwei Pkw aber nur für einen Lkw, welcher dann eben nicht überholte werden kann. Für den Ausbau der Königsbrücker Straße war so ein Modell im übrigen für einen ganzen Straßenzug im Gespräch.

Wie gesagt, ich würde vor dem 30er Schild wohl auf dem mittleren Weg eine Lane zusätzlich erfassen, danach nicht. Dann ist da weder eine Spur zuviel noch zu wenig. Dass Zweiräder etwas anders überholen, wird sich nie korrekt darstellen lassen, da das Spurenkonzept nunmal (schon in der Realität) auf zweispurige Fahrzeuge ausgelegt ist. Allerdings kann man vielleicht mit einer gewissen Berechtigung annehmen, dass Zweiräder überall überholen können. Ist auch für meinen Geschmack nicht ganz so wichtig, denn Überholen ist aktuell ja noch kein Feature von Navigationsgeräten, oder?

errt wrote:

Wie gesagt, ich würde vor dem 30er Schild wohl auf dem mittleren Weg eine Lane zusätzlich erfassen, danach nicht. Dann ist da weder eine Spur zuviel noch zu wenig. Dass Zweiräder etwas anders überholen, wird sich nie korrekt darstellen lassen, da das Spurenkonzept nunmal (schon in der Realität) auf zweispurige Fahrzeuge ausgelegt ist. Allerdings kann man vielleicht mit einer gewissen Berechtigung annehmen, dass Zweiräder überall überholen können. Ist auch für meinen Geschmack nicht ganz so wichtig, denn Überholen ist aktuell ja noch kein Feature von Navigationsgeräten, oder?

Ich weiß nicht so genau. Ich denke dieser Umstand ist für eine Aufwandsberechnung sicher nicht unerheblich. In Verkehrssimulationen sieht man ja immer wieder das der ÖPNV als Pulkführer auftritt.
Mir fällt gerade keine Stelle ein wo es die Spuren bei Radwegen auch gibt. Aber auch dort gibt es Abbieger und ähnliches. Wahrscheinlich in Fahrradstädten noch mehr als hier in Dresden.
Außerdem zeigt das Beispiel wieder unser eigentliches Problem. Wenn wir nur die Straßenmitte angeben, sagt das nichts über die Fahrspuren aus. wenn wir jetzt die Fahrspurenmitte auswählen dann sagt das nichts über die Gleislage in der Fahrspur aus.
Daher wäre schon die Frage ob man das optische nicht von dem Routing teilt. Eine flächige Erfassung des Straßenraumes.

hurdygurdyman wrote:

...
Es wird ein neuer key lane=* eingeführt. Sobald mehrere Spuren mit verschiedenen Eigenschaften eines highway=* vorhanden sind und der Wechsel zwischen diesen für Verkehrsteilnehmer physisch möglich ist, werden entsprechende lane=* parallel zum highway angelegt, was bei hochauflösenden Bildern als Grundlage möglich wird. Diese lane=* können mit entsprechenden Zusatz-tags genau wie highway=* versehen werden, um weitere Eigenschaften zu definieren.
...

Nach weiteren Überlegungen habe ich mal einige Punkte zu meiner Vorgehensweise festgelegt. Es macht für mich noch wenig Sinn, jetzt schon über 1%-5%-Probleme nachzudenken, wenn das Grundschema noch nicht transparent ist. Dies heißt aber nicht, dass diese Probleme ignoriert werden. Leider ist aber nicht alles Denkbare auch in OSM machbar 🙁

Grundsätze:
• lane=* wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen.
• lane=* impliziert immer oneway=yes. Einzige Ausnahme ist lane=footway.
• Da highway=* in der Regel richtungsunabhängig verwendet wird und als way auf der Straßenmitte liegt, ist lane=* immer zusätzlich als way zu erfassen.
(Ausnahmen könnten bei „divided highway" denkbar sein)
• Der Spurwechsel zwischen Spuren gleicher Klassifizierung ist für entsprechend berechtigte Verkehrsteilnehmer generell möglich.
• Der Spurwechsel auf eine Spur mit anderer Klassifizierung ist generell möglich, wenn der Verkehrsteilnehmer zur Nutzung der Spur berechtigt ist.
• Das separate umfängliche Erfassen der highway=* nach den bekannten Kriterien ist weiterhin erforderlich, um die etablierten Auswertungen nicht zu gefährden. Die hierdurch bestehende Gefahr von Redundanzen zwischen highway=* und lane=* bedarf besonderer Beachtung beim Erfassen.
• Es ist denkbar, später eine relation=highway einzuführen, welche dann highway=* für die als lane=* vollständig erfassten Bereiche ersetzt und die gemeinsam für alle beteiligten lane=* geltenden Attribute auf der Ebene der Relation zusammenfasst.

Im ersten Schritt liegt der Fokus auf der Spurführung für motorisierten Verkehr. Cycleway und footway bleiben hier vorerst noch unberücksichtigt. Für diese wird das Schema im zweiten Schritt erweitert. In einem dritten Schritt wird geprüft, ob die Einbindung z.B. von railway=tram als „konkurrierender" Verkehrsteilnehmer möglich ist.
Dies wird meine Testkreuzung für erste Schritte zum Tagging-Schema:
http://wiki.openstreetmap.org/wiki/File:Kreuzung.png

hurdygurdyman wrote:

Grundsätze:
• lane=* wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen.
• lane=* impliziert immer oneway=yes. Einzige Ausnahme ist lane=footway.
• Da highway=* in der Regel richtungsunabhängig verwendet wird und als way auf der Straßenmitte liegt, ist lane=* immer zusätzlich als way zu erfassen.
(Ausnahmen könnten bei „divided highway" denkbar sein)
• Der Spurwechsel zwischen Spuren gleicher Klassifizierung ist für entsprechend berechtigte Verkehrsteilnehmer generell möglich.
• Der Spurwechsel auf eine Spur mit anderer Klassifizierung ist generell möglich, wenn der Verkehrsteilnehmer zur Nutzung der Spur berechtigt ist.
• Das separate umfängliche Erfassen der highway=* nach den bekannten Kriterien ist weiterhin erforderlich, um die etablierten Auswertungen nicht zu gefährden. Die hierdurch bestehende Gefahr von Redundanzen zwischen highway=* und lane=* bedarf besonderer Beachtung beim Erfassen.
• Es ist denkbar, später eine relation=highway einzuführen, welche dann highway=* für die als lane=* vollständig erfassten Bereiche ersetzt und die gemeinsam für alle beteiligten lane=* geltenden Attribute auf der Ebene der Relation zusammenfasst.

Also bei Zwei Dingen sehe ich ein Problem.
1. lane impliziert oneway= yes Das solltest du nicht zu festlegen, bzw. solltest du die Möglichkeit schaffen dies aufzuweichen. Es gibt nicht nur wie auf der Königsbrücker Straße Fahrspuren für beie Richtungen, sondern insbesondere auch mit dauerlichtszeichen markierte Spuren, welche die Richtung jeweils in Hauptverkehrsrichtung wechseln können. Das sollte wenn schon oneway angenommen wird auch abbildbar sein.
2. der Wechsel zwischen den Spuren. Insbesondere bei Autbahnkreuzen und vor Kreuzungen kommt es oft vor, dass die Spuren nicht oder nur in einer Richtung gewechselt werden können. Diesen Umstand würde dein Modell komplett ignorieren. Auch das Überholen nicht überholen ist damit einfach ausgeblendet.

viw wrote:

...
Also bei Zwei Dingen sehe ich ein Problem.
1. lane impliziert oneway= yes Das solltest du nicht zu festlegen, bzw. solltest du die Möglichkeit schaffen dies aufzuweichen. Es gibt nicht nur wie auf der Königsbrücker Straße Fahrspuren für beie Richtungen, sondern insbesondere auch mit dauerlichtszeichen markierte Spuren, welche die Richtung jeweils in Hauptverkehrsrichtung wechseln können. Das sollte wenn schon oneway angenommen wird auch abbildbar sein.
2. der Wechsel zwischen den Spuren. Insbesondere bei Autbahnkreuzen und vor Kreuzungen kommt es oft vor, dass die Spuren nicht oder nur in einer Richtung gewechselt werden können. Diesen Umstand würde dein Modell komplett ignorieren. Auch das Überholen nicht überholen ist damit einfach ausgeblendet.

Danke für deine Anmerkungen.
zu 1:
Ich denke, dass in 99% der Fälle oneway=yes zutreffen würde. Beim Rest könnte man dann ja oneway=no oder lane_restriction=bidirectional und ggf. weitere Zusatztags verwenden. lane_restriction habe ich analog zur restrictions-Relation sowieso mit en values left_only, no_left_turn usw. eingeplant.
zu 2:
Für den Fall der durchgezogenen Linie zwischen Spuren plane ich einen key lane_changing mit den values no, no_left und no_right.
Damit dürfte auch die Überholmöglichkeit abgebildet sein. Sobald lane_changing fehlt, ist Spurwechsel möglich.

Ich denke bei den Grundsätzen sollte ich noch ergänzen, dass Spurwechsel in die Gegenfahrbahn grundsätzlich ausgeschlossen ist. Für u_turn müsste explizit lane_changing=u_turn oder lane_restriction=u_turn (bei separater Spur) anzugeben sein.

Naja mit diesen Ergänzungen zu deinen Grundgeanken kann ich durchaus leben.
Mal schauen was die anderen dazu meinen.

Nahmd,

hurdygurdyman wrote:

• Es ist denkbar, später eine relation=highway einzuführen, welche dann highway=* für die als lane=* vollständig erfassten Bereiche ersetzt und die gemeinsam für alle beteiligten lane=* geltenden Attribute auf der Ebene der Relation zusammenfasst.

Meines Wissens gehen die "Großen" so vor wie von Dir beschrieben. Allerdings ist die Relation dann Pflicht. Von den Mitgliedern der Relation werden entweder die highways oder die Lanes gezeichnet. Zu versuchen, die gleiche Geometrie für abstrakten und konkreten Weg zu benutzen, macht die Konstruktion unübersichtlicher.

Gruß Wolf

Eventuell brauchen wir auch noch Übergangslösungen. Wie kann man aus Straßen Spuren machen, so lange nicht alle Straßen detailiert erfasst sind sollte ja dennoch die Erreichbarkeit der Lanes sichergestellt sein. Außerdem ist es fragglich ob bei gleichbelibenden Spuren auf Landstraßen wirklich viele Menschen dazu neigen werden dort noch je Richtung einen weiteren Way als lane anzulegen.

hurdygurdyman wrote:

Sobald lane_changing fehlt, ist Spurwechsel möglich.

Und von wo nach wo????

Fuers Routing braucht man einen Graphen aus Knoten und Kanten. Wie willst du aus deinen einzeln erfassten Lanes ableiten, von welchem Knoten der einen Lane man nun zu welchem Knoten der anderen Lane wechseln kann? Ohne weitere Relation weiss die eine Lane ja nicht mal was von der anderen.

Gruss
Torsten

Vielleicht ist es interessant, warum ich die Beispiel-Kreuzung so angelegt habe:
http://wiki.openstreetmap.org/wiki/File:Kreuzung.png
Die orange durchgezogene und die blau gestrichelte Linie sowie die roten Punkte und die Ampel repräsentieren das bisherige tagging als highway=*, highway=crossing und traffic-signals. Sie dienen dazu, eventuell erforderliche Änderungen an diesen als Voraussetzung oder Folge des lane-taggings darzustellen.

Südstraße:
Ein einfacher highway, um zu testen, ob der sich ohne weiteres tagging in das Schema intgrieren lässt.

Weststraße:
Hier ist ein auftrennen in zwei highways (divided highway) mit jeweils zwei lanes wegen der baulichen Trennung erforderlich. Die obere Autospur nach Westen könnte noch ein „only_right_turn" erhalten, um von Osten her das vorausschauende routing zu testen (einordnen in der nördlichen Spur der Oststraße, um Spurwechsel zu vermeiden)

Nordstraße:
„Standard" für exklusive Abbiegespuren von Norden her. (Die Spur Richtung Norden wird höchstens ein lane=residential oder benötigt kein lane=* ??)

Oststraße:
„Standard" wie Nordstraße ohne Abbiegemöglichkeit nach Süden. Sie muss wie die Weststraße auch in zwei highways aufgetrennt werden. Da könnte man zu Testzwecken noch eine Parkspur oder eine Bus-Haltebucht einbauen.

Rot uni ist ein cycleway, grau mit Muster sind footways und blass rotgrau mit Muster ist ein path mit Zeichen DE:240 für Fußgänger und Radfahrer. Diese und die Fußgängerübergänge wurden später für das entsprechende tagging und routing angelegt.

Ich werde auch noch eine typische Beispielzeichnung für einen motorway_link oder primary_link anfertigen und das Schema dafür testen. Dann dürften gefühlt über 80% der Standard-Fälle ins Schema eingeflossen sein. Momentan entwickle ich die key/value tags, die ich dann als pdf zur Diskussion hochlade.

Aber da nun hier im Südwesten die ernstzunehmende närrische Zeit auf Hochtouren anläuft, werde ich die nächsten Tage etwas ruhiger mit dem Thema umgehen. Aber ich werde alle Bedenken und Einwände – gerne aber auch Lösungsansätze - zur Kenntnis nehmen und versuchen, eine Antwort zu finden 😉

@viw:
Schön, dass du mit meinen Grundgedanken jetzt leben kannst 🙂
Ich bin mir nicht sicher, ob wir Übergangslösungen brauchen, da highway=* ja erstmal bleibt. Wenn lane=* oder die relation=highway vorhanden ist, kann der Renderer/Router je nach Willen und Können ja darauf zurückgreifen. Gibts die nicht, muss er die highway-infos nehmen.

@Netzwolf:
Die relation=highway muss also kommen, wenn highway=* an entsprechender Stelle komplett durch lane=* und relation=highway ersetzt werden kann?

@de_muur:
Ich denke über das Graphen/Knoten/Kanten-Problem nach 🤔 Macht aber vielleicht erst Sinn, wenn das tagging-Schema ansatzweise steht. Da muss ich mich aber noch etwas schlauer machen. Hat jemand einen Vorschlag, wie das ohne weitere relation zu lösen ist? Ich möchte eigentlich mit Relationen so sparsam wie möglich umgehen.

de_muur wrote:

hurdygurdyman wrote:

Sobald lane_changing fehlt, ist Spurwechsel möglich.

Und von wo nach wo????

Fuers Routing braucht man einen Graphen aus Knoten und Kanten. Wie willst du aus deinen einzeln erfassten Lanes ableiten, von welchem Knoten der einen Lane man nun zu welchem Knoten der anderen Lane wechseln kann? Ohne weitere Relation weiss die eine Lane ja nicht mal was von der anderen.

Gruss
Torsten

Ich unterscheide jetzt im Interesse einer Lösung mal für routing und rendering:
Für routing beziehungsweise die Ansage besteht die Lösung darin, dass ja am Beginn der entsprechenden Spur ein gemeinsamer Knoten mit mindestens einer Nachbarspur besteht. Somit kann sich der router ja den hier befindlichen frühesten Punkt zum Spurwechsel wählen und auch entsprechend ansagen/anzeigen.
lane-changing wäre somit eher für den Renderer, um optisch die "durchgezogene Linie" oder "gestrichelte Linie" auf der entsprechenden Seite abzubilden. Sollte die gestrichelte irgendwann zur durchgezogenen Linie werden, müsste man den lane dort auftrennen und den tag fur den folgenden Rest setzen.

Kannst du damit leben, Torsten?

hurdygurdyman wrote:

Für routing beziehungsweise die Ansage besteht die Lösung darin, dass ja am Beginn der entsprechenden Spur ein gemeinsamer Knoten mit mindestens einer Nachbarspur besteht. Somit kann sich der router ja den hier befindlichen frühesten Punkt zum Spurwechsel wählen und auch entsprechend ansagen/anzeigen.

...

Kannst du damit leben, Torsten?

Nein, denn das funktioniert nur, wenn zusaetzlich eine Abbiegespur hinzu kommt. wenn aber eine Strasse ueber eine Kreuzung hinweg mehrspurig ist, dann klappt das nicht mehr.
Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.

Ausserdem ist einige Seiten weiter vorne ausgiebig dargelegt worden, dass durch die mehrfachen Wege die Kreuzungstopologien fuer die automatische Auswertung nicht mehr verstaendlich sind. So kann ein Router zwar noch eine optimale Strecke finden, er kann aber kaum noch brauchbare Abbiegeanweisungen erzeugen.

=> Mit dem Ansatz verrennst du dich in eine Sackgasse. Dass kann mir im Prinzip egal sein, es ist ja deine Zeit, die dabei rauf geht. Das Problem ist nur, dass andere dir in die Sackgasse folgen moegen, und OSM ist nun mal herdengetrieben.

Gruss
Torsten

de_muur wrote:

hurdygurdyman wrote:

Für routing beziehungsweise die Ansage besteht die Lösung darin, dass ja am Beginn der entsprechenden Spur ein gemeinsamer Knoten mit mindestens einer Nachbarspur besteht. Somit kann sich der router ja den hier befindlichen frühesten Punkt zum Spurwechsel wählen und auch entsprechend ansagen/anzeigen.

...

Kannst du damit leben, Torsten?

Nein, denn das funktioniert nur, wenn zusaetzlich eine Abbiegespur hinzu kommt. wenn aber eine Strasse ueber eine Kreuzung hinweg mehrspurig ist, dann klappt das nicht mehr.
Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.

Ausserdem ist einige Seiten weiter vorne ausgiebig dargelegt worden, dass durch die mehrfachen Wege die Kreuzungstopologien fuer die automatische Auswertung nicht mehr verstaendlich sind. So kann ein Router zwar noch eine optimale Strecke finden, er kann aber kaum noch brauchbare Abbiegeanweisungen erzeugen.

=> Mit dem Ansatz verrennst du dich in eine Sackgasse. Dass kann mir im Prinzip egal sein, es ist ja deine Zeit, die dabei rauf geht. Das Problem ist nur, dass andere dir in die Sackgasse folgen moegen, und OSM ist nun mal herdengetrieben.

Gruss
Torsten

Hast du alles richtig gelesen? Die bisherige Strucktur highway=* bleibt erhalten. Dein schlaues navi erzeugt also wie bisher die Abbiegehinweise aus den Grundtopologien und kann bei Bedarf die Spuren anzeigen und wenn die dann eine direction haben sagt er dir dann sogar ordnen sie sich in der Spur geradeaus nach Berlin ein. Das findest du bei den heutigen Daten sicher noch nicht.

viw wrote:

Hast du alles richtig gelesen? Die bisherige Strucktur highway=* bleibt erhalten. Dein schlaues navi erzeugt also wie bisher die Abbiegehinweise aus den Grundtopologien und kann bei Bedarf die Spuren anzeigen und wenn die dann eine direction haben sagt er dir dann sogar ordnen sie sich in der Spur geradeaus nach Berlin ein.

Das schlaue Navi will ich haben.

Fuer den Fall, dass die meisten Navis nicht so schlau sind, koennten wir ja vielleicht auch ein einfacher auszuwertendes Taggingschema benutzen.

Gruss
Torsten

Flächenmehrfachnutzung (korrekte Abbildung des Straßenbahn auf der Straße) geht soweit ich das übersehen kann, nur wenn man die Spuren/Objekte als Fläche mappt.

Ansonsten kann man in etwa so etwas als Spumodell nehmen:
ein Way mit:

width=*
maxspeed=*
surface=*
forward=yes/no (die entsprechende Fahrtrichtung ist (nicht) erlaubt)
backward=yes/no
left=yes/no (man darf (nicht) nach links fahren (Sperrlinien/-flächen, Fußweg, Straßengraben, Überholverbot, etc.))
right=yes/no

x-Stück dieser Segmente sind dann der highway=* als Relation mit zugehörigem name=*.
Wenn sich die Eigenschaften ändern, muß man ein neues highway-Segment einzeichnen.

Das erst mal nur so als Idee zur Vereinfachung des Problems, sonst muß man mit Flächen operieren, wenn man das Straßenbahnproblem auch noch gelöst haben möcht, ist aber dann entsprechend aufwendig zu mappen, da mkann man dann nicht mal so eben nur 'ne Linie malen.

Ich fange mal hinten an:

de_muur wrote:

=> Mit dem Ansatz verrennst du dich in eine Sackgasse. Dass kann mir im Prinzip egal sein, es ist ja deine Zeit, die dabei rauf geht. Das Problem ist nur, dass andere dir in die Sackgasse folgen moegen, und OSM ist nun mal herdengetrieben.

Für mich läuft das auch unter Gehirn-Jogging, was ja für einen mittlerweile fast 57-jährigen wie mich durchaus empfehlenswert sein soll und somit eine sinnvolle Zeitverschwendung darstellt 😉
Selbst wenn nichts dabei rauskommt, ist es gut, dass wir darüber gesprochen haben. Ich habe mir dann aber erspart, im stillen Kämmerlein mühsam ein englisches proposal zu basteln, das dann keiner beachtet oder das heillos zerrissen wird. 😎
Ich halte den Weg für sinnvoller, hier im Vertrauen auf die „german croud intelligence" gemeinsam mit euch erst einmal eine mögliche Lösung zu entwickeln, woraus dann ein proposal entstehen kann. Leider ist talk-de (noch) nicht mein Ding. Da sind wohl eher die Techniker unterwegs, deren Meinung zu diesem Thema auch interessant wäre. Da muss ich dann wohl noch ran 🤔
Solange es noch kein unausgegorenes proposal gibt, das manche Mapper dann auch noch umsetzen, sehe ich die Gefahr, dass man mir in eine Sackgasse folgt, noch nicht.

de_muur wrote:

Ausserdem ist einige Seiten weiter vorne ausgiebig dargelegt worden, dass durch die mehrfachen Wege die Kreuzungstopologien fuer die automatische Auswertung nicht mehr verstaendlich sind. So kann ein Router zwar noch eine optimale Strecke finden, er kann aber kaum noch brauchbare Abbiegeanweisungen erzeugen.

Das muss durch das tagging-Schema verhindert werden. Über Relationen wäre da wohl eine Lösung möglich, aber die sind ja nicht unbedingt erwünscht und ich will sie auch möglichst vermeiden. Ich denke darüber nach.

de_muur wrote:

Nein, denn das funktioniert nur, wenn zusaetzlich eine Abbiegespur hinzu kommt. wenn aber eine Strasse ueber eine Kreuzung hinweg mehrspurig ist, dann klappt das nicht mehr.

Da können doch die router eine Logik entwickeln die ungefähr so aussieht, dass bei mehreren Spuren mit derselben Richtung über die Kreuzung hinaus z.B. immer die rechte Spur bei Rechtsverkehr verwendet wird, was ja in Deutschland auch den geltenden Regeln entspricht. Für vorausschauendes routing wäre eine Regel im router denkbar, die z.B. für ein Abbiegen an der dann folgenden Kreuzung oder Abzweigung eine Spurempfehlung wählt, die ohne oder mit möglichst wenig Spurwechseln bis dorthin auskommt.

de_muur wrote:

Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.

Da verstehe ich leider nicht, wie du das im Zusammenhang mit dem Vorschlag meinst 🤔

hurdygurdyman wrote:

Selbst wenn nichts dabei rauskommt, ist es gut, dass wir darüber gesprochen haben. Ich habe mir dann aber erspart, im stillen Kämmerlein mühsam ein englisches proposal zu basteln, das dann keiner beachtet oder das heillos zerrissen wird.

Aber ich verschwende meine Zeit, indem ich dir antworte. Selbst schuld.

de_muur wrote:

Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.

Da verstehe ich leider nicht, wie du das im Zusammenhang mit dem Vorschlag meinst 🤔

Du hattest als Ansatz vorgeschlagen, dass es furs Routing reichen wuerde, wenn nur an den Verbindungspunkten zwischen den Spuren gewechselt wird. Und das funktioniert halt nicht, wenn man auf den anderen Strassenseite ein Ziel ansteuern will, bei dem es gerade halt keinen Verbindungspunkt zwischen den Spuren gibt. Dein Routing wird dich dann immer bis zur naechsten Kreuzung schicken und dort wenden lassen. Und wenn dort das Wenden seiner Meinung nach nicht geht, dann kommen da sehr interessante Umwege bei raus. Aber auch das ist schon weiter oben in dieser Diskussion hinreichend aufgezeigt worden.

Gruss
Torsten

de_muur wrote:

Du hattest als Ansatz vorgeschlagen, dass es furs Routing reichen wuerde, wenn nur an den Verbindungspunkten zwischen den Spuren gewechselt wird. Und das funktioniert halt nicht, wenn man auf den anderen Strassenseite ein Ziel ansteuern will, bei dem es gerade halt keinen Verbindungspunkt zwischen den Spuren gibt. Dein Routing wird dich dann immer bis zur naechsten Kreuzung schicken und dort wenden lassen. Und wenn dort das Wenden seiner Meinung nach nicht geht, dann kommen da sehr interessante Umwege bei raus. Aber auch das ist schon weiter oben in dieser Diskussion hinreichend aufgezeigt worden.

Gruss
Torsten

Diese Aussage ist ja nun schon besser beschrieben wo dein Problem ist. Machen wir das anders.
Das Konzept ist zweigleisig. Zum einen gibt es die Grundstruktur so wie heute mit highway=*
Damit kann der Router auch weiterhin seine Routen berechnen und dort gibt es keine Probleme mit der Straßenseite. Und dann gibt es für Details Spuren. Diese kann der Router bei Bedarf grafisch auswerten(Spurassitent anzeigen) oder wenn Lust und Zeit hat sogar über mehrere Kreuzung hinweg die günstigste Spur berechnen.
Das Problem ist, dass man mit Tags den Spurverlauf nicht richtig darstellen kann und es würde zu riesigen Tagmonstern führen. Außerdem gibt es schon heute eine gewisse Anzahl von Mappern, welche die Spuren zeichnet und mit den altbewährten Tags (highway=*) das Routing zerstört.

de_muur wrote:

Aber ich verschwende meine Zeit, indem ich dir antworte. Selbst schuld.

Danke für die Zeit, die du diesem Thema und mir opferst. Ich unterstelle jetzt einfach mal, dass diese deine Zeit auch einem gewissen Interesse am Thema geschuldet ist.

de_muur wrote:

Du hattest als Ansatz vorgeschlagen, dass es furs Routing reichen wuerde, wenn nur an den Verbindungspunkten zwischen den Spuren gewechselt wird. Und das funktioniert halt nicht, wenn man auf den anderen Strassenseite ein Ziel ansteuern will, bei dem es gerade halt keinen Verbindungspunkt zwischen den Spuren gibt. Dein Routing wird dich dann immer bis zur naechsten Kreuzung schicken und dort wenden lassen. Und wenn dort das Wenden seiner Meinung nach nicht geht, dann kommen da sehr interessante Umwege bei raus. Aber auch das ist schon weiter oben in dieser Diskussion hinreichend aufgezeigt worden.

Dann geht es bei dem Problem wohl primär um's Routing für Fußgänger und Radfahrer, die ja je nach Belieben und Risikobereitschaft überall kreuzen könnten. Dafür gibt es soweit ich weiß auch im etablierten tagging keine Lösung. Ich kann mir momentan auch keine vorstellen, solange der "Zwang" zum routing über Knoten und Kanten besteht. Ich erinnere mich da an einen ergebnislosen thread im Zusammenhang mit dem Kreuzen von flächigen Fußgängerzonen irgendwann im letzten Jahr. Und wegen dieser Problematik schrieb ich in meine "Grundsätze":
Im ersten Schritt liegt der Fokus auf der Spurführung für motorisierten Verkehr. Cycleway und footway bleiben hier vorerst noch unberücksichtigt.
Momentan kann ich mir auch nicht vorstellen, dass irgendein Router bereit ist, derartige Empfehlungen zum beliebigen Überqueren einer Straße abzugeben. Wir reden hier ja nicht von irgendwelchen zweispurigen Straßen mit geringem Verkehrsaufkommen. Mehrere Spuren und Abbiegespuren sind eher an Verkehrsadern mit manchmal auch von der Tageszeit abhängigem erhöhtem Aufkommen zu finden, wo die Möglichkeit zum und die Gefahr beim Kreuzen nicht kalkulierbar ist. Die Benutzung eines Routers, bedeutet ja nicht, dass man dabei den gesunden Menschenverstand ausschalten darf. Jeder mir bekannte Router spuckt nach dem Einschalten einen entsprechenden Warnhinweis aus, um der Gefahr einer Haftungsklage zu entgehen.

hurdygurdyman wrote:

Dann geht es bei dem Problem wohl primär um's Routing für Fußgänger und Radfahrer, die ja je nach Belieben und Risikobereitschaft überall kreuzen könnten.

Nein, wie kommst du jetzt darauf? Die letzten Aeusserungen von mir bezogen sich rein auf den KFZ-Verkehr. Auch hier kann beim Routing aus den bereits dargelegten Gruenden nicht auf den freien Wechsel von einer Spur zur anderen verzichtet werden.

(Um die Aussage zu praezisieren: Natuerlich kann man auch ein Routing auf Basis deines Vorschlages realissieren. Nur waere das kein Fortschritt gegenueber dem bisherigen Stand sondern schafft nur neue Probleme.)

Gruss
Torsten

de_muur wrote:

hurdygurdyman wrote:

Dann geht es bei dem Problem wohl primär um's Routing für Fußgänger und Radfahrer, die ja je nach Belieben und Risikobereitschaft überall kreuzen könnten.

Nein, wie kommst du jetzt darauf? Die letzten Aeusserungen von mir bezogen sich rein auf den KFZ-Verkehr. Auch hier kann beim Routing aus den bereits dargelegten Gruenden nicht auf den freien Wechsel von einer Spur zur anderen verzichtet werden.

(Um die Aussage zu praezisieren: Natuerlich kann man auch ein Routing auf Basis deines Vorschlages realissieren. Nur waere das kein Fortschritt gegenueber dem bisherigen Stand sondern schafft nur neue Probleme.)

Gruss
Torsten

Welche Probleme schafft das Modell? Der Vorteil ist das jeder der möchte mit lane=* jetzt detail informationen finden kann, welche vorher nicht da waren. Und wo siehst du den Nachteil?

de_muur wrote:

hurdygurdyman wrote:

Dann geht es bei dem Problem wohl primär um's Routing für Fußgänger und Radfahrer, die ja je nach Belieben und Risikobereitschaft überall kreuzen könnten.

Nein, wie kommst du jetzt darauf?
...

Deine Aussage

de_muur wrote:

Und das funktioniert halt nicht, wenn man auf den anderen Strassenseite ein Ziel ansteuern will,

heißt für mich, dass auch die Gegenfahrbahn als Bestandteil der Straße gekreuzt werden soll, was bei Straßen, von denen wir hier reden, in der Regel nicht möglich ist.
Aber auch für den von dir gemeinten Fall kenne ich keine etablierte Lösung mit OSM-Daten.

hurdygurdyman wrote:

heißt für mich, dass auch die Gegenfahrbahn als Bestandteil der Straße gekreuzt werden soll, was bei Straßen, von denen wir hier reden, in der Regel nicht möglich ist.
Aber auch für den von dir gemeinten Fall kenne ich keine etablierte Lösung mit OSM-Daten.

Ich rede hier von einer ganz normalen Strasse mit in jeder Richtung eine Fahrspur. Wenn du entsprechend deines Vorschlages die eine Spur als highway erfasst (welche von beiden auch immer) und die andere Spur als lane erfasst, dann kommst du auf die andere Strassenseite nur, indem du bis zum naechsten Verbindungsknoten zwischen den beiden Spuren faehrst und dort wendest => absoluter Murks. In Wirklicheit wirst du einfach auf der Fahrspur in deiner Richtung bis zum Erreichen des Zieles fahren und dort die Gegenfahrbahn queren.
Statt mit der Gegenfahrbahn greift die Argumentation auch genauso, wenn zwei Fahrspuren in die selbe Richtung verlaufen.

Ich praesentiere hier nicht irgendwelche ausgefuchsten Sonderfaelle, die Probleme deines Ansatzes (wie kann der Router zwischen getrennt erfassten Spuren wechseln) werden auch in den einfachsten Beispielen ersichtlich. Falls du es noch nicht gemacht hast, dann liess dir noch mal von Anfang an diese Diskussion hier durch. Wenn du dann immer noch nicht die Probleme verstehst, dann kann ich auch nicht weiter helfen.

Gruss
Torsten

de_muur wrote:

hurdygurdyman wrote:

heißt für mich, dass auch die Gegenfahrbahn als Bestandteil der Straße gekreuzt werden soll, was bei Straßen, von denen wir hier reden, in der Regel nicht möglich ist.
Aber auch für den von dir gemeinten Fall kenne ich keine etablierte Lösung mit OSM-Daten.

Ich rede hier von einer ganz normalen Strasse mit in jeder Richtung eine Fahrspur. Wenn du entsprechend deines Vorschlages die eine Spur als highway erfasst (welche von beiden auch immer) und die andere Spur als lane erfasst, dann kommst du auf die andere Strassenseite nur, indem du bis zum naechsten Verbindungsknoten zwischen den beiden Spuren faehrst und dort wendest => absoluter Murks. In Wirklicheit wirst du einfach auf der Fahrspur in deiner Richtung bis zum Erreichen des Zieles fahren und dort die Gegenfahrbahn queren.
Statt mit der Gegenfahrbahn greift die Argumentation auch genauso, wenn zwei Fahrspuren in die selbe Richtung verlaufen.

Ich praesentiere hier nicht irgendwelche ausgefuchsten Sonderfaelle, die Probleme deines Ansatzes (wie kann der Router zwischen getrennt erfassten Spuren wechseln) werden auch in den einfachsten Beispielen ersichtlich. Falls du es noch nicht gemacht hast, dann liess dir noch mal von Anfang an diese Diskussion hier durch. Wenn du dann immer noch nicht die Probleme verstehst, dann kann ich auch nicht weiter helfen.

Gruss
Torsten

In deinem Beispiel würde ein highway=* in der Mitte laufen und rechts und links davon je Richtung ein lane=* Der Route kann ganz normal rechts oder links von dem highway runtergehen.
Lediglich neuere Router können sehen, dass hier zwei Fahrspuren sind. Allen anderen bleibt das neue Modell eh verborgen und die machen das so wie bisher.
Wenn also jetzt neue Router entstehen dann müssen die entsprechend lernen, dass alle lanes der Straße beliebig austauschbar sind, so lange das nicht durch Tags verboten wird. Diese Tags sind dann an den jeweiligen lanes zu finden.

viw wrote:

Wenn also jetzt neue Router entstehen dann müssen die entsprechend lernen, dass alle lanes der Straße beliebig austauschbar sind, so lange das nicht durch Tags verboten wird. Diese Tags sind dann an den jeweiligen lanes zu finden.

Welche Lane ist mit welcher austauschbar???? Der Router hat Millionen von lanes in seiner Datenbank. Solange du da nicht spezielle Relationen fuer spendierst, kann eine automatische Auswertung damit ueberhaupt nichts anfangen.

Fuer dich als Mensch ist es auf den ersten Blick erkennbar, dass der highway und die direkt daneben paralellel verlaufenden lanes zusammengehoeren. Aber probiere mal, dieses Erkennen einem Computer beizubringen. Genau mit solchen Sachen, die fuer uns Menschen trivial erscheinen, haben Computer die groessten Schwierigkeiten. Und entsprechend unsinnig ist ein Taggingschema, dass genau solche Faehigkeiten voraussetzt.

Gruss
Torsten

aighes wrote:

hurdygurdyman wrote:

Den Einwand von de_muur "Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden." verstehe ich nicht, da mir Erfahrungswerte fehlen.

Router basteln sich aus den Daten einen Routinggraph für eine Straße, der alle Infos enthalten sollte. Daraus kann er dann das Gewicht des Weges ermitteln. Gliedert man Wege zu weit auf, gehen manche Infos unweigerlich verloren, wenn man sie nicht doppelt einträgt. Ebenso verkompliziert sich der Routinggraph natürlich ordentlich.

Ist mir ja neu, das der Router sich nicht, die Infos von allen Spuren, die ihn interessieren, mit als Metrik an eine Linie/Kante hängen könnte.

Man sollte eben nicht versuchen, alles als eine Linie darstellen zu wollen, die "Straße" als abstakte Ansammlung von verschiedenen Spuren, besteht nun mal aus min. einer Spur, auf der, an der jeweiligen Stelle in der Realität, unterschiedliche Verkehrsteilnnehmer entweder in einer der vier möglichen Richtungen fahren dürfen oder eben nicht. Damit kann man in Bezug aufs Spurrouting alles abbilden, was keine relative Lageinformation in Bezug auf die Fläche der Spur beinhaltet. Reicht also locker für ein Model die bei den komerziellen Autoroutern. Gut, wäre aber eine Erweiterung des Schemas für Flächendarstellungen zu haben, weil wie ja eben auch den ÖPNV haben. Es reicht aber, entweder die Straße als highway=* zu mappen, oder statt dessen alle Einzelspuren + abstrakte Straßenrelation. Da können Anfänger das alte highway-Schema nehmen.

Die Leute, die hier behaupten, da kommen bei passend reduzierten Einzelspurdaten, dann nur noch Müllansagen, mögen das doch mal belegen. Daten wegwerfen kann man immer, passende dazuerfinden ist schwiieriger. 😉 Wenn die Spur an der Kreuzung (heißt ja nicht ohne Grund so!) senkrecht gemeinsame Knotenpunkte mit allen Spuren hat, auf die man einbiegen darf, wo ist denn dann das Problem?
Außerdem muß man natürlich unterscheiden zwischen dem, was man beim Router an Daten auf der Karte sieht und dem was er intern zur Routenberechnung benutzt.

de_muur wrote:

viw wrote:

Wenn also jetzt neue Router entstehen dann müssen die entsprechend lernen, dass alle lanes der Straße beliebig austauschbar sind, so lange das nicht durch Tags verboten wird. Diese Tags sind dann an den jeweiligen lanes zu finden.

[...]

Fuer dich als Mensch ist es auf den ersten Blick erkennbar, dass der highway und die direkt daneben paralellel verlaufenden lanes zusammengehoeren. Aber probiere mal, dieses Erkennen einem Computer beizubringen. Genau mit solchen Sachen, die fuer uns Menschen trivial erscheinen, haben Computer die groessten Schwierigkeiten. Und entsprechend unsinnig ist ein Taggingschema, dass genau solche Faehigkeiten voraussetzt.

Da ist beides richtig, der Router braucht eine Relation, um zu wissen, welche Spuren denn jetzt die Straße im sinnes des alten highway-Taggings darstellen und neue Router müssen und können die lernen, sich hie metainfos für ihre Ansagen aus den Einzelspuren heraus zu suchen.

flaimo wrote:

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png

ist genauso kompliziert, dafür aber exakter.

+1
Problem verstanden!

chris66 wrote:

Weil der Routinggraph schlicht und einfach falsch ist. Du kannst in der Realität mit Deinem Fahrzeug beliebig die
Spuren wechseln (zumindest bei gestrichelter Linie), der Router kann das nicht, er ist auf der Spur gefangen.

Der Router kann aus den Daten auch garantiert nicht die Anzahl der ingesamt vorhandenen Spuren auf der Straße ermitteln oder was? 😉

chris66 wrote:

Nun kommt hinzu, dass GPS nur begrenzte Genauigkeit hat, und somit die Gefahr groß ist, dass er die
falsche Spur trifft. Des weiteren wird die Komplexität der Daten und damit die Fehlerquote erhöht.

Mehr als "es gibts auf der Straße x Spuren, die in diese Richtungen gehen ... und von ... unter folgenden Bedingungen ... befahren werden dürfen" kann man doch eh auf Grund der GPS-Ungenauigkeit nicht abbilden.

EvanE wrote:

flaimo wrote:

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png

ist genauso kompliziert, dafür aber exakter.

Weil in deinem Beispiel zwei wesentliche Dinge fehlen:
- ca. 30 - 50 turn restrictions müssten noch ergänzt werden.
==> wesentlich komplexer
- wo darf man die Spuren wechseln und wo nicht?
Erhöht ebenfalls die Komplexität.

Die Spur hat nur einen gemeinsamen Knoten mit der anderen Spur, wenn man auch auf sie einbiegen darf.
Turn restrictions sollten dann nur noch die Ausnahme sein, wenn man die erlaubten Richtungebn pro Verkehrsteilnehmer an sie Spur getaggt hat. Müßte man mal noch exemplarisch durchnudeln, die hoch der Aufwand beim mappen da wirklich ist.

Ach, ja, die alten highway=* braucht man aus Rückwärtkompatibilitätsgründen doch noch, aber die sind dann doch nur eine weitere Spur in der abstrakten Straßenrelation.
Die Spuren nur an Kreuzungsbreichen erfassen zu wollen funktioniert nicht, weil die hängen sonst in der Luft und haben keinen Startanknüpfungspunkt ans Straßennetz. Dieser kann wahlweise ein highway=* sein oder, wo schon gemappt, die passenden anderen Spuren.

railrun wrote:

Die "Jede-Spur-als-eigener-Highway-eintragen-Seuche" greift langsam um sich...

Hilfe die Welt geht unter... 😉

railrun wrote:

Sind 2 Städte zum Beispiel über eine Schnellstraße mit jeweils 2 Spuren in jeder Richtung verbunden (also sind 4 Straßen eingetragen). Beim Routen würde dann versucht werden, die kürzeste Verbindung zwischen beiden Städten zu finden. Somit wird erst geprüft, wie weit die Strecke über die eine Spur ist und dann die andere. Die Kürzere der beiden Spuren wäre dann die Strecke, über die du geführt wirst. (Die anderen 2 Spuren werden nicht beachtet, da sie ja in die Gegenrichtung führen)
=> Es müssen 2 statt einer Berechnung angestellt werden. Ich hoffe wir reden hier nicht aneinander vorbei 😉

Wenn der Router aber auf Grund einer Relation weiß, das die zweite Spur in die gleiche Richtung zur gleichen Fahrbahn gehört, wird er sich da seine Berechnung sinnvollerweise verkneifen.

de_muur wrote:

hurdygurdyman wrote:

heißt für mich, dass auch die Gegenfahrbahn als Bestandteil der Straße gekreuzt werden soll, was bei Straßen, von denen wir hier reden, in der Regel nicht möglich ist.
Aber auch für den von dir gemeinten Fall kenne ich keine etablierte Lösung mit OSM-Daten.

Ich rede hier von einer ganz normalen Strasse mit in jeder Richtung eine Fahrspur.

Unter http://forum.openstreetmap.org/viewtopi … 89#p220989
habe ich die modifizierten Grundsätze definiert. Dort steht:
• lane=* wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen.
Ich präzisiere das hier weiter, um unnötige Diskussionen wie die letzten sechs posts zu vermeiden:
• lane=* wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen, und mehrere mit verschiedenen Richtungsbeschränkungen versehene Spuren je Fahrtrichtung vorhanden sind.

@ de_muur, viw, Fabi2:
Es geht mir nicht darum, kilometerlange Strecken mit parallelen Spuren ohne Abzweigungen zusätzlich mit lanes zu versehen. Hier reicht das vorhandene Model aus. Der Router nimmt sich die als way abgebildete Straßenmitte und der Anwender ist zufrieden.
Der key lane dient zur Unterscheidung und Detaillierung von highway-Informationen, um Missbrauch des highway-keys in Fällen wie diesem Erwähnten zu verhindern. http://wiki.openstreetmap.org/w/images/ … _lanes.png
Der Sinn ist es, dadurch dem router die Möglichkeit zu geben, auf die Auswertung der highway zu verzichten, sobald von einem Knoten an die detaillierten lane-Informationen vorhanden sind. Der Router wertet dann entweder lane oder highway für den Streckenabschnitt , auf dem diese Informationen parallel vorliegen.

Ich mache jetzt mal mein erstes Tagging-Schema fertig und stelle es als als pdf ein. Dann gibt es wieder eine Diskussionsgrundlage und ihr müsst euch nicht im spekulativen Bereich zerfleischen. Ich gebe zu, dass ich durch eventuelle Unklarheiten in Formulierungen Anlass zu den Spekulationen gab und bitte um Verständnis, das noch nicht alles ausgegoren und kristallklar formuliert ist.

Und da Bilder mehr als tausend Worte sagen, kommt dann noch eine grafische Erläuterung auf Basis der bekannten Musterkreuzung. Das dauert aber noch, denn Inkscape ist noch nicht so ganz mein Ding (aber ich mache ja hier auch Gehirn-Jogging 🙂 )

Also bitte:
Cool bleiben, abwarten und die Pappnasen-Zeit genießen 😉

Mein Lösungsansatz zum lane-tagging ist fertig und hier abgelegt:
http://wiki.openstreetmap.org/wiki/File … ansatz.pdf
Gedanken,Vorschläge und Wünsche dazu nehme ich gern entgegen.

Also: Feuer frei (aber bitte nichts verbrennen)

hurdygurdyman wrote:

um Missbrauch des highway-keys in Fällen wie diesem Erwähnten zu verhindern. http://wiki.openstreetmap.org/w/images/ … _lanes.png

Das ist übrigens eine super Beispiel-Kreuzung.

Nehmen wir einen Autofahrer, der von "unten-links" geradeaus nach "oben-rechts" will und sich auf der rechten
Spur befindet. Wenn ich's richtig sehe, dürfen Busse auf der Spur gerade fahren, während Autos
rechts abbiegen müssen. Der Autofahrer muss also eine Spur nach links. Im Routinggraph geht dass nur wenn
er im Bereich der Kreuzungsfläche einmal 90 Grad links und dann 90 Grad rechts abbiegt. 😉

chris66 wrote:

Das ist übrigens eine super Beispiel-Kreuzung.
...

Das habe ich mir auch schon gedacht. Ich würde die gerne mal als Beispiel für lane-tagging verwenden, wenn die Grundsätze dafür klar sind.
Es wäre aber sehr aufwändig, diese grafisch nachzubilden 🤔
Wo ist diese Stelle und kann ich bing einfach als Hintergrund für eine Foliensammlung zum Thema verwenden, wenn ich die Quelle angebe?

hurdygurdyman wrote:

Mein Lösungsansatz zum lane-tagging ist fertig und hier abgelegt:
http://wiki.openstreetmap.org/wiki/File … ansatz.pdf
Gedanken,Vorschläge und Wünsche dazu nehme ich gern entgegen.

Also: Feuer frei (aber bitte nichts verbrennen)

Unten steht, footway und cycleway bleiben unberücksichtigt, oben gibt es aber einen Ausnahme von oneway=yes für lane=footway. Passt finde ich nicht ganz zusammen. Außerdem frage ich mich, ob es mehr straßenbegleitende Fahrradwege (solche würde man ja dann wohl mit lane=cycleway darstellen) gibt, die oneway=yes sind oder oneway no. Da sollte man einen vernünftigen Standard wählen.

Die Beschränkung auf Kreuzungssituationen ist zwar nett gedacht, aber IMO unrealistisch. Wenn es ein vernünftiges Schema gibt, wird es auch an gerader Strecke eingesetzt werden. Aber ich sehe da auch kein Problem, da ja die bisherige highway Struktur erhalten bleibt, ist es doch auch nicht schädlich, wenn die lane Informationen auch an gerader Strecke vorliegen.

Ansonsten erstmal Zustimmung, gefällt mir.

errt wrote:

Unten steht, footway und cycleway bleiben unberücksichtigt, oben gibt es aber einen Ausnahme von oneway=yes für lane=footway. Passt finde ich nicht ganz zusammen. Außerdem frage ich mich, ob es mehr straßenbegleitende Fahrradwege (solche würde man ja dann wohl mit lane=cycleway darstellen) gibt, die oneway=yes sind oder oneway no. Da sollte man einen vernünftigen Standard wählen.

Die Beschränkung auf Kreuzungssituationen ist zwar nett gedacht, aber IMO unrealistisch. Wenn es ein vernünftiges Schema gibt, wird es auch an gerader Strecke eingesetzt werden. Aber ich sehe da auch kein Problem, da ja die bisherige highway Struktur erhalten bleibt, ist es doch auch nicht schädlich, wenn die lane Informationen auch an gerader Strecke vorliegen.

Ansonsten erstmal Zustimmung, gefällt mir.

Beim footway habe ich schon weiter gedacht. Taggen sol ja schon möglich sein. ich werde das konkreter fassen, indem ich den Fokus im ersten Schritt auf "spurabhängiges routing für motorisierten Verkehr" ändere.
cycleway werde ich im Auge behalten und deine Bemerkungen berücksichtigen.
Das Schema wird imo primär an komplexen Kreuzungen benötigt. Natürlich können Mikromapper das dann auch woanders verwenden. Dazu muss es nur entsprechend angelegt werden.

Deine Zustimmung ermutigt mich zum Weitermachen. Danke.

Ich habe mittlerweile hier eine Version 0.2 hochgeladen.
http://wiki.openstreetmap.org/wiki/File … ansatz.pdf
direkt ins Dokument:
http://wiki.openstreetmap.org/w/images/ … ansatz.pdf
Einige Textverbesserungen und genauere Formulierungen wurden eingefügt und das Dokument bekommt jetzt eine Versionsnummer mit Datum, damit alle, die lieber Ausdrucke lesen, die Aktualität ihres Papiers vergleichen können.

Hilfääh!!
Irgendwie hat das Aktualisieren in einigen Versuchen nicht nach meinen Wünschen geklappt, weshalb einiges an Müll unter dem Link liegt. Wie kriege ich alte Uploads gelöscht ? 🤔 Eigentlich will ich auch im interesse des Speicherplatzes dort nur die aktuellste Variante vorhalten.

hurdygurdyman wrote:

Wie kriege ich alte Uploads gelöscht ? 🤔 Eigentlich will ich auch im interesse des Speicherplatzes dort nur die aktuellste Variante vorhalten.

Gar nicht. In einem Wiki kann man keine Versionen löschen, das ist Teil des Konzepts.

Man kann die ganze Datei mit allen Versionen von einem Admin "löschen" lassen und dann mit einer neuen Versionsgeschichte neu anfangen. Speicherplatz spart man aber auch so nicht - die Versionen bleiben für Admins trotzdem einsehbar.

Wenn du Dateien sowieso nur selber bearbeiten willst und Wert darauf legst, selbst entscheiden zu können, was gespeichert bleibt, dann ist eigener Webspace, ein öffentlicher Dropbox-Ordner o.ä. wohl die bessere Wahl.

Mein Lösungsansatz zum lane-tagging ist fertig und hier abgelegt

Zum Thema selbst. Dein Lösungsansatz leidet unter demselben Dilemma wie alle Spuren-Als-Ways-Ansätze:

Wenn man die Ways einfach nur ohne Relationen nebeneinander liegen hat, sind die Daten für die maschinelle Auswertung schwer zu nutzen. Wenn man hinggen fordert, dass die Spur-Ways mit Relationen zusammengefasst werden, ist das Bearbeiten nicht mehr so einfach.

Ich befürchte, die Attraktivität dieses Ansatzes beruht zu einem großen Teil darauf, dass die Bedeutung von nebeneinander verlaufenden lane-Ways für den menschlichen Betrachter intuitiv verständlich ist, was über die mangelnde Auswertbarkeit hinwegtäuscht.

Tordanik wrote:

Wenn man die Ways einfach nur ohne Relationen nebeneinander liegen hat, sind die Daten für die maschinelle Auswertung schwer zu nutzen. Wenn man hinggen fordert, dass die Spur-Ways mit Relationen zusammengefasst werden, ist das Bearbeiten nicht mehr so einfach.

Ich befürchte, die Attraktivität dieses Ansatzes beruht zu einem großen Teil darauf, dass die Bedeutung von nebeneinander verlaufenden lane-Ways für den menschlichen Betrachter intuitiv verständlich ist, was über die mangelnde Auswertbarkeit hinwegtäuscht.

Wie gesagt da erstellt man dann eine abstrakte Straßenrelation über die Einzelspuren und das Problem ist auch nicht mehr größer, als das Problem der nicht per gemeinsamen Knotenpunkt verbundenen Wege jetzt schon. Wichtig aus dem Vorschlag ist eigentlich nur die Information, das die Art des Gesamtweges mit an die Einzelspuren muß, was dann auf Kosten von mehr Redundanz und evtl. Widersprüchen eine Relation für den highway=* einspart, so dam man nur noch die für die Gesamtstraße (highway + sidewalks, etc.) braucht.

Fabi2 wrote:

Tordanik wrote:

Wenn man die Ways einfach nur ohne Relationen nebeneinander liegen hat, sind die Daten für die maschinelle Auswertung schwer zu nutzen. Wenn man hinggen fordert, dass die Spur-Ways mit Relationen zusammengefasst werden, ist das Bearbeiten nicht mehr so einfach.

Ich befürchte, die Attraktivität dieses Ansatzes beruht zu einem großen Teil darauf, dass die Bedeutung von nebeneinander verlaufenden lane-Ways für den menschlichen Betrachter intuitiv verständlich ist, was über die mangelnde Auswertbarkeit hinwegtäuscht.

Wie gesagt da erstellt man dann eine abstrakte Straßenrelation über die Einzelspuren und das Problem ist auch nicht mehr größer, als das Problem der nicht per gemeinsamen Knotenpunkt verbundenen Wege jetzt schon. Wichtig aus dem Vorschlag ist eigentlich nur die Information, das die Art des Gesamtweges mit an die Einzelspuren muß, was dann auf Kosten von mehr Redundanz und evtl. Widersprüchen eine Relation für den highway=* einspart, so dam man nur noch die für die Gesamtstraße (highway + sidewalks, etc.) braucht.

Somit sind wir wieder beim Grundproblem angelangt 🤔
- Einerseits soll das Schema ohne Tools umsetzbar und für den Mapper einfach und nachvollziehbar sein.
- Andereseits bietet die Relation eine bessere Maschinenlesbarkeit und mindert die Gefahr von Redundanzen, fordert aber vom Mapper ein gewisses Maß an Abstraktionsvermögen oder ein Eingabetool.
- Was beim rendern schön aussieht, muss für den router nicht unbedingt sinnvoll sein und umgekehrt.

Die bisherigen Ansätze scheiterten auch in dieser Diskussionrunde genau an diesen Problemen. Das kann auch meinem Ansatz passieren, der eher auf die optischen Fähigkeiten des Mappers aufbaut.
Wir können nicht das eine wollen ohne auf das andere zu verzichten. Ich sehe da wenigstens keinen Weg.
Wir brauchen den engagierten Laien zum Erfassen mit einfachen Mitteln. Aber wir brauchen auch eine Datenbank zur professionellen Auswertung. Beides gleichzeitig wird mit dem OSM-Datenmodell immer schwieriger, wenn nicht sogar unmöglich 🙄

Ich will noch gar nicht daran denken, was mit meinem Ansatz passiert, wenn Brücken ins Spiel kommen. Bei railway und separated cycleway ist da die renderer-Fraktion schon höchst unzufrieden. Wie wollen wir die Realität darstellen, wenn wir in diesen Fällen viele Brücken statt einer real existierenden zeigen ?
Aber jetzt hier bitte keine OT-Brückendiskussion einbauen.

Nahmd,

hurdygurdyman wrote:

Aber jetzt hier bitte keine OT-Brückendiskussion einbauen.

Ich bin ja artig.

Gruß Wolf

hurdygurdyman wrote:

Wir können nicht das eine wollen ohne auf das andere zu verzichten. Ich sehe da wenigstens keinen Weg.
Wir brauchen den engagierten Laien zum Erfassen mit einfachen Mitteln. Aber wir brauchen auch eine Datenbank zur professionellen Auswertung. Beides gleichzeitig wird mit dem OSM-Datenmodell immer schwieriger, wenn nicht sogar unmöglich 🙄

Ich will noch gar nicht daran denken, was mit meinem Ansatz passiert, wenn Brücken ins Spiel kommen. Bei railway und separated cycleway ist da die renderer-Fraktion schon höchst unzufrieden. Wie wollen wir die Realität darstellen, wenn wir in diesen Fällen viele Brücken statt einer real existierenden zeigen ?

Da habe ich noch den Ansatz eines abgerüsteten Schemas für Anfänger anzubieten, das ist zwar dann nicht semantisch korrekt, aber da kommt dann hoffentlich ein erfahrenerer Mapper vorbei und setzt die passende Relation auf die Einzelobjekte. Gut, eine wirkliche Lösung ist das auch nicht, eher eine Übergangslösung, außerdem entstehen da evtl. widersprüchliche Redundanzen bzw. muß extra Aufwand zur Löschung an den Einzelobjekten betrieben werden.

Das funktioniert dann so, das der Anfänger-Mapper z.B. eine Brücke mit bridge=yes + layer=1 an jedem Weg mappt und dann mal jemand hoffentlich die betroffenen einzelnen Brückenteilwege in eine gemeinsame Relation, für die Darstellung, das das nur eine Brücke ist, packt.

Da die letzten Abschweifungen in Richtung Spuren-Als-Einzelne-Wege-Erfassen nichts neues zum Thema Routing erbracht haben, moechte ich noch mal die Variante Spuren-Als-Tags-Des-Weges-Erfassen hervorbringen.

Ein Punkt ist dabei, wie man die Verbindung der Spuren ueber eine Kreuzung hinweg am besten erfassen kann. Die meisten der letzten Vorschlaege (auch meiner) sehen vor, dass das ueber Tags geschehen soll aehnlich wie die Spurerfassung selber. Inzwischen bin ich der Meinung, dass dafuer doch Relationen das geeigentere Mittel sind:
- Letztendlich will man diese Informationen ja erfassen, damit ein Router die auch verwenden kann. Und fuer die automatische Auswertung ist es halt deutlich einfacher, wenn direkt in den Daten drin steht, welche Wege betroffen sind, als dass die Auswertung sich das erst ueber irgendwelche Lagedaten selber heraussuchen muesste. (Eine Kreuzung wird eigentlich nur ein mal erfasst, aber die Daten werden dann wieder und wieder ausgewertet.)
- Wirklich komplizierter ist die betreffende Relation ja auch nicht, vom Aufbau her entspricht sie ja einer Turn-Restriction., und da funktioniert es ja auch.
- Wenn man die Verbindungen ueber Relationen erfasst, dann erledigt man an dieser Stelle auch die interpretationsmoeglichkeit, ob die Verbindung in Weg-Richtung oder in Fahrt-Richtung zu erfassen sind.

Die meisten der letzten Vorschlaege sehen fuer die Erfassung eine Listennotation vor, bei der die Spuren mittels eines definierten Trennzeichens aufgezahelt werden. Daneben gab es haeufig auch eine Notation, mit der man auch einzelen Werte nur fuer eine bestimmte Spur setzen konnte. Aufgrund meiner Erfahrung mit den Beispielen auf der Uebersichtseite denke ich nun, dass man dazwischen auch noch teilweise gefuellte Listen zulassen sollte. D.h., wenn man fuer eine Spur keinen entsprechenden Wert setzen will, dann folgt da einfach Trennzeichen auf Trennzeichen. (Dieser Vorschlag ist auch schon von anderen gekommen, nur habe ich das bislang noch nie irgendwo ausformuliert/angewendet gesehen).

Die meisten der letzten Vorschlaege sehen fuer die Listennotation ein einfaches Aufzaehlen der Spuren von links nach rechts vor. Im Moment denke ich, dass es besser waere, wenn man die (logische) Strassenmitte dabei besonders hervorhebt. Bei den allermeisten Strassen trennt diese logische Mitte die Fahrtrichtungen oder wird von einer Spur gebildet die die Fahrt in beide Richtungen erlaubt (z.B. auf einspurigen Strassen). Wenn man diese Mitte besonders betont, erleichtert sich erstens die Erfassung der Fahrtrichtung der einzelnen Spuren (fast alle Faelle sind per Default erledigt). Zum anderen duerfte das die Auswertung erleichtern, wenn man z.B. wissen will, ob eine Strasse einen rechtsseitigen Radweg hat. realisieren liesse sich so eine Betonung, indem man in der Listennotation ein weiteres Trennzeichen einfuehrt und bei der einzelnen Identifikation der Spuren mit Vorzeichen arbeitet: Spuren mit negativem Vorzeichen sind links der Mitte, Spuren mit positiven Vorzeichen sind rechts der Mitte.

Gruss
Torsten

de_muur wrote:

Da die letzten Abschweifungen in Richtung Spuren-Als-Einzelne-Wege-Erfassen nichts neues zum Thema Routing erbracht haben, moechte ich noch mal die Variante Spuren-Als-Tags-Des-Weges-Erfassen hervorbringen.

Gut, ich halte diesen Ansatz derzeit mindestens kurz- bis mittelfristig für aussichtsreicher. Dass unter den tag-basierten Ansätzen die Listenvarianten am meisten versprechen, zeichnet sich allmählich auch ab.

Aufgrund meiner Erfahrung mit den Beispielen auf der Uebersichtseite denke ich nun, dass man dazwischen auch noch teilweise gefuellte Listen zulassen sollte. D.h., wenn man fuer eine Spur keinen entsprechenden Wert setzen will, dann folgt da einfach Trennzeichen auf Trennzeichen.

Das ist eine naheliegende und sinnvolle Ergänzung.

Die meisten der letzten Vorschlaege sehen fuer die Listennotation ein einfaches Aufzaehlen der Spuren von links nach rechts vor. Im Moment denke ich, dass es besser waere, wenn man die (logische) Strassenmitte dabei besonders hervorhebt. Bei den allermeisten Strassen trennt diese logische Mitte die Fahrtrichtungen oder wird von einer Spur gebildet die die Fahrt in beide Richtungen erlaubt (z.B. auf einspurigen Strassen). Wenn man diese Mitte besonders betont, erleichtert sich erstens die Erfassung der Fahrtrichtung der einzelnen Spuren (fast alle Faelle sind per Default erledigt). Zum anderen duerfte das die Auswertung erleichtern, wenn man z.B. wissen will, ob eine Strasse einen rechtsseitigen Radweg hat.

Ja, es könnte wirklich vorteilhaft sein, die Straßenmitte gesondert zu betonen. Die Defaults für die Fahrtrichtungen und die bessere Auswertbarkeit für Datennutzer, die z.B. nur an Radwegen interessiert sind, sind sehr gute Argumente.

Ich möchte allerdings auf einen alternativen Vorschlag für die praktische Umsetzung hinweisen. In Mailinglisten-Diskussionen wurde vorgeschlagen, man könnte für die beiden Straßen"hälften" zwei getrennte Listen anlegen (also so etwas wie lanes:direction:right = ... , ... , ...). Dadurch hätte man weiterhin nur eine Art von Trennzeichen und der Bedarf für "Vorzeichen" von Spuren würde ebenfalls wegfallen. Allerdings hat man dann doppelt so viele, wenn auch kürzere, Tags.

Das mit denn Zusatztags wird bestimmt interessant, bei teilweise markierten Radspuren zum Beispiel, wie dem separated=yes-Radweg, der dann als Radspur auf die Straße mündet und an der nächsten Einengung der Straße ganz aufhört... 😉

Tordanik wrote:

Ich möchte allerdings auf einen alternativen Vorschlag für die praktische Umsetzung hinweisen. In Mailinglisten-Diskussionen wurde vorgeschlagen, man könnte für die beiden Straßen"hälften" zwei getrennte Listen anlegen (also so etwas wie lanes:direction:right = ... , ... , ...). Dadurch hätte man weiterhin nur eine Art von Trennzeichen und der Bedarf für "Vorzeichen" von Spuren würde ebenfalls wegfallen. Allerdings hat man dann doppelt so viele, wenn auch kürzere, Tags.

Da hatte ich auch dran gedacht, auf die Art ist das auch machbar. Im Moment scheint mir das aber die schlechterer Loesung zu sein, da es ja doch genug Faelle gibt, wo die Aufteilung in Rechts und Links alleine nicht ausreichend ist (z.B. alle Strassen mit nur einer Fahrspur). Das koennte man dann allerdings ueber eine dritte Kategorie (wie in etwa lanes:direction:middle=...) erfassen, was aber zu einer noch groessere Zergliederung führt. Ich denke, da wäre eine einzelne Liste uebersichtlicher. Wobei uebersichtlich da allgemein sehr relativ ist, a schoensten ist natuerlich eine graphische Eingabehilfe, so dass der Mapper von den daunter liegenden Datenstrukturen gar nichts mitbekommt.

Fabi2 wrote:

Das mit denn Zusatztags wird bestimmt interessant, bei teilweise markierten Radspuren zum Beispiel, wie dem separated=yes-Radweg, der dann als Radspur auf die Straße mündet und an der nächsten Einengung der Straße ganz aufhört...

Das Thema, wie detailliert man mappen will, hat man immer, unabhaengig vom gewaehlten Tagging-Schema. Oben genanntes Beispiel wird bei kleinlichem Tagging zu einer extremen Zerstueckelung der Strasse fuehren. Aber was waere die Alternative? Wenn man das als einzelne Wege erfassen wuerde, dann muesste man das doch genauso zerstueckeln und dann die Einzelteile jedes Abschnittes jeweils in einer Relation wieder zusammen fassen.

Gruss
Torsten

Da Bilder mehr als 1000 Worte sagen habe ich zu meinem Lösungsansatz aus post http://forum.openstreetmap.org/viewtopi … 52#p221552, den ich hier http://wiki.openstreetmap.org/w/images/ … ansatz.pdf als Text beschrieben habe noch eine grafische Darstellung gebastelt:

http://wiki.openstreetmap.org/w/images/ … afisch.pdf

Vielleicht wird zu meinem Ansatz so einiges klarer im Bezug auf die Verwendung/Auswertung zum routen. Ich halte nichts vom Aufzählungen/Listen in values wegen der Intransparenz und Nachbearbeitung. Nach wie vor ist mir nicht klar, wie das ein router verarbeiten soll.

Da der Mensch ein optisch orientiertes Wesen ist, halte ich das mappen einzelner Spuren für die bessere Lösung. Ich habe vesucht, ein Schema zu entwickeln, dass ähnlich arbeitet wie Relationen, aber noch ohne diese auskommt. Das Problem dabei sind die Linienbündel, für die man dann aber den (ungeliebten) Weg über Relationen verwenden könnte :/

Ich bitte um Meinungen zur Verwendbarkeit als Mapper und zum routing. Auch Änderungsvorschläge sind willkommen. Sollte sich herausstellen, dass das schon im Ansatz alles nur Mist ist, werde ich mich wohl von der Idee verabschieden.

wozu sind die lane_restrictions auf Seite 5 in der graphischen Darstellung, wenn Du auf Seite 6 das gleiche mit dem Spinnennetz im Kreuzungsbereich darstellst?

SunCobalt wrote:

wozu sind die lane_restrictions auf Seite 5 in der graphischen Darstellung, wenn Du auf Seite 6 das gleiche mit dem Spinnennetz im Kreuzungsbereich darstellst?

Ich weiß, dass ist doppelt gemoppelt. Aber einerseits dient es dem Renderer, um für das entsprechende lane die Richtungspfeile oder das entsprechende Verkehrschild einzublenden, andererseits denke ich, dass es für vorausschauendes routing Sinn macht. Weiterhin könnte eine automatisierte Qualitätskontrolle checken, ob die vom entsprechenden lane ausgehenden lane=junction vollständig und richtig sind. Ich befürchte nämlich, dass von den lane=junction je nach Komplexität schnell mal eins vergessen wird, weil die ja in der Realität nicht sichtbar sind und nur benötigt werden, weil routing über Flächen nicht möglich ist.
Ich hatte auch mal kurz daran gedacht, die lane=junction wegzulassen und dann dem router die Aufgabe zu überlassen, automatisiert die Möglichkeiten der Verbindungen über die lane_junction-Fläche zu generieren, was mapping natürlich vereinfachen würde. Aber dann habe ich mich entschlossen, dem router die Arbeit zu erleichtern.

ich sag mal so. Das ganze sieht ziemlich unübersichtlich aus, was aber wohl nicht zu vermeiden ist. Daher würde ich es gut finden, wenn alle nur für diesen Zweck benötigten Objekte einen identischen Tag haben. Damit kann man das auf Knopfdruck ausblenden wenns einen stört.

Als Extrembeispiel könntest Du ja das hier nehmen
https://maps.google.de/maps?q=Gro%C3%9F … n&t=k&z=17

Mir gefällt Deine Art, die Dinge zu visualisieren 🙂 Da kann man sich gleich mehr drunter vorstellen als bei einem ellenlangen Text

SunCobalt wrote:

ich sag mal so. Das ganze sieht ziemlich unübersichtlich aus, was aber wohl nicht zu vermeiden ist. Daher würde ich es gut finden, wenn alle nur für diesen Zweck benötigten Objekte einen identischen Tag haben. Damit kann man das auf Knopfdruck ausblenden wenns einen stört.

Deswegen habe ich für alle expliziten ways oder nodes als key "lane" gewählt ( siehe http://wiki.openstreetmap.org/w/images/ … ansatz.pdf , Seite 3). Ausnahme ist lane_junction für die Kreuzungsfläche. Das dürfte aber auch kein Problem geben.

Als Extrembeispiel könntest Du ja das hier nehmen
https://maps.google.de/maps?q=Gro%C3%9F … n&t=k&z=17

Gute Idee. Da lege ich dann aber ein bing-Bild in den Hintergrund. Irgendwo habe ich auch mal eine recht komplexe Kreuzung in Wien gesehen, die sich eignen könnte. Und ein Autobahnkreuz oder so will ich mir auch noch vornehmen, an dem man mit lane_direction probieren könnte.

Mir gefällt Deine Art, die Dinge zu visualisieren 🙂 Da kann man sich gleich mehr drunter vorstellen als bei einem ellenlangen Text

Danke für das Kompliment. Macht zwar erst mal Arbeit, spart dann aber tausend Erklärungen.

hurdygurdyman wrote:

Als Extrembeispiel könntest Du ja das hier nehmen
https://maps.google.de/maps?q=Gro%C3%9F … n&t=k&z=17

Gute Idee. Da lege ich dann aber ein bing-Bild in den Hintergrund. Irgendwo habe ich auch mal eine recht komplexe Kreuzung in Wien gesehen, die sich eignen könnte.

die hier?
https://maps.google.de/maps?q=Praterste … h&t=k&z=17
bzw bei Bing
http://binged.it/yUyLUy

Da sieht man die Pfeile auf der Straße nicht so gut

SunCobalt wrote:

die hier?
https://maps.google.de/maps?q=Praterste … h&t=k&z=17
bzw bei Bing
http://binged.it/yUyLUy

Da sieht man die Pfeile auf der Straße nicht so gut

In Wien dachte ich an :
http://www.bing.com/maps/?v=2&cp=48.212 … ich&obox=1
Da könnte man dann sogar die westlichen Brücken zu einem Rundkurs zusammenflicken. Dein Vorschlag ist auch eher ein Kreisverkehr 🤔
Wie gesagt: ich würde das Luftbild hinterlegen, was Arbeit spart, und da ist Google ja wohl außen vor 🤔

Die Lösung sieht einleuchtend aus. Auf die komplizierteren Beispiele bin ich gespannt, ich hoffe "dein" System schafft das.

Der vorgeschlagene Wiener Praterstern, sieht komplizierter aus, als er ist. Sind meistens 3-4 Fahrstreifen und 1-2 gehen davon seitlich ab, glaube ich ist nicht viel komplexer, als der Berliner Vorschlag. Die Frage ist nur, was man mit Busspuren und Bimgleisen macht? Vom System komplett ausnehmen, solange sie nicht parallel zur Straße verlaufen?

Das wäre bei unseren britischen Freunden doch schön 🙂
http://www.bing.com/maps/?v=2&where1=Br … &encType=1
und nebenan:
http://www.bing.com/maps/?v=2&cp=48.218 … Q1NzI0NQ==

Jimmy_K wrote:

Die Lösung sieht einleuchtend aus. Auf die komplizierteren Beispiele bin ich gespannt, ich hoffe "dein" System schafft das.

Der vorgeschlagene Wiener Praterstern, sieht komplizierter aus, als er ist. Sind meistens 3-4 Fahrstreifen und 1-2 gehen davon seitlich ab, glaube ich ist nicht viel komplexer, als der Berliner Vorschlag. Die Frage ist nur, was man mit Busspuren und Bimgleisen macht? Vom System komplett ausnehmen, solange sie nicht parallel zur Straße verlaufen?

Separate Busspuren bekommen lane=psv. Bimgleise (Hochdeutsch=Straßenbahngleise) laufen unter "konkurrierender Verkehr", den ich nicht mit lane=xy taggen will, da dies nichts mit dem ersten Ziel, das spurabhängige routing zu ermöglichen, zu tun hat. Straßenbahnen laufen als railway=tram wie bisher weiter. Wichtig erscheint mir dabei aber, die höhengleichen Kreuzungen auch auf lane=* zu markieren, damit sie als Hindernis ausgewertet werden können.

hurdygurdyman wrote:

http://wiki.openstreetmap.org/w/images/ … afisch.pdf

Vielleicht wird zu meinem Ansatz so einiges klarer im Bezug auf die Verwendung/Auswertung zum routen. Ich halte nichts vom Aufzählungen/Listen in values wegen der Intransparenz und Nachbearbeitung. Nach wie vor ist mir nicht klar, wie das ein router verarbeiten soll.

Da der Mensch ein optisch orientiertes Wesen ist, halte ich das mappen einzelner Spuren für die bessere Lösung. Ich habe vesucht, ein Schema zu entwickeln, dass ähnlich arbeitet wie Relationen, aber noch ohne diese auskommt. Das Problem dabei sind die Linienbündel, für die man dann aber den (ungeliebten) Weg über Relationen verwenden könnte 🤔

Ich bitte um Meinungen zur Verwendbarkeit als Mapper und zum routing. Auch Änderungsvorschläge sind willkommen. Sollte sich herausstellen, dass das schon im Ansatz alles nur Mist ist, werde ich mich wohl von der Idee verabschieden.

Der Ansatz ist absolut nicht Mist, sieht fast aus wie eine unötig komplizierte Version von meiner Grobidee, die ich schon hier und heute noch mal unter http://wiki.openstreetmap.org/wiki/Talk … s_features beschrieben habe.

Weil wenn man an Spuren die wie in deinem Schema mit dem alten Highways verbunden sind und dann z.B. wie folgt getaggt werden:

lane=yes
foot:all=yes
bicycle:all=yes
motor_vehicle:forward=yes
motor_vehicle:backward=no
motor_vehicle:left=yes
motor_vehicle:right=no

...und die Lanes dann nur dort gemeinsame Knotenpunkte haben, wo auch ein Einbiegen auf die andere Spur möglich ist, hat sich das Abbiegebeschränkungsproblem und auch access-Problem dann hoffentlich in den meisten Fällen ganz schnell erledigt. 🙂

Dann will der Autorouter ja bestimmt "seine Straße" haben, weshalb ich dann eine Relation für die Lanes machen würde, wo der alte highway=* mit passender Rolle, der Straßentyp entsprechend dem highway=* für die Lanes und die lane=yes-Objekte, die die Fahrbahn bilden, drin sind.

Dann braucht man ja noch die "Straße" für die "der Sidewalk gehört aber mit zur Straße"-Fraktion, wo dann alles drin sein kann, was zur "Straße" (im Sinne der Fahrbahn bzw. des jetzigen highway-Weges) gehört ("straßenbegleitende" Fuß-/Radwege (die auch nur lane=yes-Objekte mit anderem "access"-Tags nach obigem Schema sind), Laternen, Ampeln oder sonstwas...) und wo dann auch der name=* mit rein kommt.

Alte Anwendungen interessieren sich für die lane=yes-Wege und die Relationen dann hoffentlich nicht weiter und benutzen nur den (anfänglich redundanten) alten highway=*, womit das Rückwärtskompatibilitätsproblem gelöst wäre.

Noch 'ne Anmerkung: Es ist im Endeffekt doch egal, ob man als Autfahrer nicht nach links fahren kann, weil da eine Sperrlinie oder -fläche ist oder man sich bei einer einspurigen Straße dann im Straßengraben wiederfindet. Dann sollte man für bestimmte Objektypen evtl. noch sillvolle Defasultwerde definieren, damit man nicht so viel taggen muß und fertig!

hurdygurdyman wrote:

Da Bilder mehr als 1000 Worte sagen

Das ist dein Denkfehler: Dir als Mensch sagen die Bilder mehr, ein Router hat aber kein solches Sehverstaendnis. Fuer ihn sind solche visuellen Darstellungen komplett unbrauchbar. Wenn du nachvollziehen willst, mit welchen Daten ein Router zurechtkommen muss, dann mal deine Beispielkreuzung mal in JOSM auf, speicher die als OSM-Datei ab und schau dir dann diese OSM-Datei im Texteditor an. Du wirst sehen, dass du nichts siehst, und das wird einem Router genauso gehen.

Wenn man entsprechend deinem Vorschlag fleissig einzelne Wege fuer die Spuren eintraegt, und ist das eine reine Beschaeftigungstherapie fuer die Mapper (als ob du zuhause ein Puzzle machst): Du verbringst deine Freizeit damit und kannst es dir angucken und dich freuen, wie viel du geschafft hast. Aber irgendein Nutzen (Routing) wird daraus nicht erwachsen.

Ich halte nichts vom Aufzählungen/Listen in values wegen der Intransparenz und Nachbearbeitung. Nach wie vor ist mir nicht klar, wie das ein router verarbeiten soll.

Solche Listen lassen sich ganz einfach visualisiseren, damit du als Mapper (als Mensch) sie leichter nachvollziehen kannst: Momentan zeichnet ein Mapping-Editor (z.B. JOSM) eine Linien fuer einen Weg und faerbt diese entsprechend der in den Tags enthaltenen Werte ein. Genauso wie das Einfaerben funktioeniert, kann entsprechend irgendwelcher Lane-Listen auch das Aussehen der Linie angepasst werden: Wenn da eine Lane enthalten ist, wird eine einfache Linie gemalt, bei zwei Lanes dann zwei Linien nebeneinender usw.
Aus den Tag-Listen eine Visualisierung zu bauen ist trivial. Aus einer visuellen Darstellung aber umgekehrt eine Tag-Liste zu generieren ist extrem aufwendig, in aller Allgemeinheit praktisch unmoeglich.

Gruss
Torsten

de_muur wrote:

hurdygurdyman wrote:

Da Bilder mehr als 1000 Worte sagen

Das ist dein Denkfehler: Dir als Mensch sagen die Bilder mehr, ein Router hat aber kein solches Sehverstaendnis.

Da drehst du meine Aussage um. Die Bilder http://wiki.openstreetmap.org/w/images/ … afisch.pdf dienen dazu, das von mir vorgeschlagene Schema für den Menschen verständlich optisch umzusetzen.

Fuer ihn sind solche visuellen Darstellungen komplett unbrauchbar. Wenn du nachvollziehen willst, mit welchen Daten ein Router zurechtkommen muss, dann mal deine Beispielkreuzung mal in JOSM auf, speicher die als OSM-Datei ab und schau dir dann diese OSM-Datei im Texteditor an. Du wirst sehen, dass du nichts siehst, und das wird einem Router genauso gehen.

Meines Wissens bilden Router gerichtete Graphen über Knoten und Kanten. Diese stellt ihnen mein Vorschlag in den lane=* genau wie ansonsten highway=* zur Verfügung. Wo ist das Problem? Der Router muss doch lediglich eine Regel befolgen, die lane=* priorisiert, wenn als Alternative highway=* besteht.

Solche Listen lassen sich ganz einfach visualisiseren, damit du als Mapper (als Mensch) sie leichter nachvollziehen kannst: Momentan zeichnet ein Mapping-Editor (z.B. JOSM) eine Linien fuer einen Weg und faerbt diese entsprechend der in den Tags enthaltenen Werte ein. Genauso wie das Einfaerben funktioeniert, kann entsprechend irgendwelcher Lane-Listen auch das Aussehen der Linie angepasst werden: Wenn da eine Lane enthalten ist, wird eine einfache Linie gemalt, bei zwei Lanes dann zwei Linien nebeneinender usw.
Aus den Tag-Listen eine Visualisierung zu bauen ist trivial. Aus einer visuellen Darstellung aber umgekehrt eine Tag-Liste zu generieren ist extrem aufwendig, in aller Allgemeinheit praktisch unmoeglich.

Hast du dir die entsprechende mit JOSM erzeugte OSM-Datei auch mal im Texteditor angeschaut 😉

Da es auf der Mailingliste gerade halbwegs aktiv ist das Thema, hier ein Link:
http://rfmtc.no-ip.org/osm/austrox/?zoo … 4&layers=B

Irgendwie fehlt bei vielen Schemen, wie man es tagged, wenn sich von 3 Spuren die mittlere teilt und dann jeweils 2 Fahrstreifen in eine andere Richtung gehen. (siehe oben)
Ich fürchte, man kommt ohne gezeichnete Lanes auf einer Autobahn und bei größeren Kreuzungen nicht weiter.

@hurdygurdyman
Hast du schon erfolgreich versucht, dein Schema auf die großen Kreuzungen anzuwenden?

Eine einfache Lösung ist noch nicht in Sicht. 😉
http://comments.gmane.org/gmane.comp.gi … n.de/92732

Jimmy_K wrote:

Irgendwie fehlt bei vielen Schemen, wie man es tagged, wenn sich von 3 Spuren die mittlere teilt und dann jeweils 2 Fahrstreifen in eine andere Richtung gehen. (siehe oben)
Ich fürchte, man kommt ohne gezeichnete Lanes auf einer Autobahn und bei größeren Kreuzungen nicht weiter.

Kommt man sowieso nicht, weil dieser Fall den du hier anführst wird nicht der Einzige bleiben, einfach schon prinzipbedingt! Bin mal gespannt, wann man zu der Einsicht kommen wird, das man eine Spur als Abstraktion nur in vier Richtungen befahren kann (vor, zurück, links, rechts) und das es egal ist, ob man den logischen oder physischen (Asphalt)streifen jetzt Radweg, Fußweg oder Fahrspur nennt. Genug Hinweise wie man es besser machen kann, hab ich ja hier und in den Proposal'n gepostet, also kann ich mir jetzt Popcorn holen gehen. Ausarbeiten tue ich das nicht weiter, da habe ich einfach zu wenig Interesse an den Spuren. Den Routern kann man sinvvolle Datenreduktions- und Abstraktionsmechanismen beibringen, was das Schema naurlich durch passende Infos unterstützen sollte.

Jimmy_K wrote:

...
@hurdygurdyman
Hast du schon erfolgreich versucht, dein Schema auf die großen Kreuzungen anzuwenden?

Ich war leider in letzter Zeit mit anderen Dingen stark ausgelastet, sodass ich da nicht viel machen konnte 🙁
Aber kurz zu meinem Stand:
Ich habe versucht, mir Wissen zu dem Thema aus Sicht des routings anzueignen. Bin da aber noch nicht ganz fertig.
Als Testgegend habe ich Freiburg (Brsg) ausgeguckt. Die Gründe dafür:
- Hochauflösende Bilder von Aerowest aus 2009 sind vorhanden.
- Das "Freiburgschema" zeichnet dort schon umfangreich Spuren unter großzügiger Auslegung von highway=*
http://www.openstreetmap.org/edit?lat=4 … 49&zoom=18
http://www.openstreetmap.org/edit?lat=4 … 42&zoom=18
- Ich kenne mich da einigermaßen aus.

Ich werde mir da ein paar Ecken für JOSM zum offline-bearbeiten herunterladen und die Aerowest-Bilder dazupacken, um meinen täglichen Zugfahrten zur Arbeit mit sinnvollen Dingen zu füllen.
Ziel des ganzen sollte dann eine Testumgebung sein, in der dann erfahrene Renderer und Router mit den Daten spielen können. Deren feedback anhand konkreter Beispiele ist mir wichtig. Anschließend sollten die Erfahrungen in das Schema einfließen.

Bitte habt noch etwas Geduld. Ich will hier nichts über's Knie brechen.

chris66 wrote:

Eine einfache Lösung ist noch nicht in Sicht.
http://comments.gmane.org/gmane.comp.gi … n.de/92732

Interessante Diskussion, die mich bestärkt, weiterzumachen.

Jimmy_K wrote:

...
Irgendwie fehlt bei vielen Schemen, wie man es tagged, wenn sich von 3 Spuren die mittlere teilt und dann jeweils 2 Fahrstreifen in eine andere Richtung gehen. (siehe oben)
Ich fürchte, man kommt ohne gezeichnete Lanes auf einer Autobahn und bei größeren Kreuzungen nicht weiter.

Dazu habe ich eine vage Idee 🤔
linke Spur: lane_restriction=left_ahead
mittlere Spur: lane_restriction=split_ahead
rechte Spur: lane_restriction=right_ahead

Das entspräche für die äußeren Spuren etwa dem:
http://de.wikipedia.org/w/index.php?tit … 0126153005

Für das Teilen der mittleren Spur habe ich keinen Markierungspfeil gefunden.

Das sich die mittlere Spur aufteilt hab ich noch nie gesehen...gibts sowas in der Realität? Entweder kommt doch links oder rechts eine Spur hinzu bzw. fällt weg.

aighes wrote:

Das sich die mittlere Spur aufteilt hab ich noch nie gesehen...gibts sowas in der Realität? Entweder kommt doch links oder rechts eine Spur hinzu bzw. fällt weg.

Habe ein Beispiel aus den Staaten gefunden:
http://mutcd.fhwa.dot.gov/htm/2009/images/fig2e_06.gif
Edit:
Und hier das Beispiel bei Wiener Neustadt mit recht gutem bing-Hintergrund:
http://www.openstreetmap.org/edit?lat=4 … 09&zoom=18
Tu felix Austria 😎
Aber wenn man genau hinsieht, teilt sich nur die obere Spur in zwei 🤔

hurdygurdyman wrote:

aighes wrote:

Das sich die mittlere Spur aufteilt hab ich noch nie gesehen...gibts sowas in der Realität? Entweder kommt doch links oder rechts eine Spur hinzu bzw. fällt weg.

Habe ein Beispiel aus den Staaten gefunden:
http://mutcd.fhwa.dot.gov/htm/2009/images/fig2e_06.gif
Edit:
Und hier das Beispiel bei Wiener Neustadt mit recht gutem bing-Hintergrund:
http://www.openstreetmap.org/edit?lat=4 … 09&zoom=18
Tu felix Austria 😎

Gibts auch in DE:
http://maps.google.de/maps?ll=51.234087 … 5&t=k&z=19

Gruß,
ajoessen

ajoessen wrote:

...
Gibts auch in DE:
http://maps.google.de/maps?ll=51.234087 … 5&t=k&z=19

Danke für den Hinweis. Aber den geteilten Vorankündigungspfeil finde ich als Verkehrszeichen bei uns nirgendwo. Na ja, muss ja nicht alles geregelt sein, was sinnvoll ist.

Edit:
Richtig gute bing-Bilder habt ihr da http://www.openstreetmap.org/edit?lat=5 … 06&zoom=18

Fabi2 wrote:

Bin mal gespannt, wann man zu der Einsicht kommen wird, das man eine Spur als Abstraktion nur in vier Richtungen befahren kann (vor, zurück, links, rechts)

Nie, denn es gibt Kreuzungen, wo sich 5 Straßen treffen, und da gibt es halblinks, scharflinks, halbrechts, scharfrechts. Beispiel: http://www.bing.com/maps/?v=2&cp=48.172 … orm=LMLTCC Vor allem aber kann ein Router hier nicht von selber erkennen, wo die Gradeausspuren hinführen. Das wird in allen Proposals übersehen, und deshalb werde ich wahrscheinlich auch gegen beide jetzt zum Voting freiegebene Proposals stimmen.

fkv wrote:

Nie, denn es gibt Kreuzungen, wo sich 5 Straßen treffen, und da gibt es halblinks, scharflinks, halbrechts, scharfrechts. Beispiel: http://www.bing.com/maps/?v=2&cp=48.172 … orm=LMLTCC Vor allem aber kann ein Router hier nicht von selber erkennen, wo die Gradeausspuren hinführen. Das wird in allen Proposals übersehen, und deshalb werde ich wahrscheinlich auch gegen beide jetzt zum Voting freiegebene Proposals stimmen.

Wenn ich mir das genauer anschaue, sollte es doch eine mögliche Lösung geben 🤔
Die Straße von "unten rechts" teilt sich zuerst in zwei Spuren. Die obere wäre "no_left_turn". Die untere "no_right_turn".
Die obere bleibt eine Spur, bis sie sich bei der Fußgängerinsel für "geradeaus" und "rechts" teilt.
Die untere Spur teilt sich in eine "geradeaus" und eine für "links/halblinks". Mit restriction ist da wohl nichts zu machen, aber mit lane=junction aus meinem Vorschlag http://wiki.openstreetmap.org/w/images/ … ansatz.pdf auf Seite 3 hätten wir Kanten zwischen Knoten über die Kreuzung, welche dem Router Möglichkeiten zur Wegfindung bieten.

Die anderen Einmündungen wären ähnlich umsetzbar. Vielleicht finde ich die Zeit, dass mal grafisch aufzuarbeiten.

Wie findet man die beiden?

hurdygurdyman wrote:

Danke für den Hinweis. Aber den geteilten Vorankündigungspfeil finde ich als Verkehrszeichen bei uns nirgendwo. Na ja, muss ja nicht alles geregelt sein, was sinnvoll ist.

Hierfür haste wahrscheinlich auch nichts im Angebot:
http://www.amazon.de/gp/product/images/ … 80&s=music

<duckundwech>
ajoessen

ajoessen wrote:

...
Hierfür haste wahrscheinlich auch nichts im Angebot:
http://www.amazon.de/gp/product/images/ … 80&s=music

<duckundwech>
ajoessen

Nö. Aber vielleicht findet sich ein Kölner Stammtisch, der ein proposal im regionalen Dialekt aufsetzt 😄

Jimmy_K wrote:

Wie findet man die beiden?

Welche beiden meinst du? Ein quote (Zitat) der Stelle wäre nicht schlecht.

Edit: <verspätet Groschen gefallen>
Die proposals zum voting findest du hier:
http://wiki.openstreetmap.org/wiki/Cate … 2Voting%22

Nahmd,

ajoessen wrote:

Hierfür haste wahrscheinlich auch nichts im Angebot:
http://www.amazon.de/gp/product/images/ … 80&s=music

Ist auch nicht nötig.

Wegen §1 und §3 reicht das bekannte Tagging, und wegen §6 und §9 hätte ein neues Taggingschema ohnehin keine Chance.

Gruß Wolf (§11)

fkv wrote:

Fabi2 wrote:

Bin mal gespannt, wann man zu der Einsicht kommen wird, das man eine Spur als Abstraktion nur in vier Richtungen befahren kann (vor, zurück, links, rechts)

Nie, denn es gibt Kreuzungen, wo sich 5 Straßen treffen, und da gibt es halblinks, scharflinks, halbrechts, scharfrechts. Beispiel: http://www.bing.com/maps/?v=2&cp=48.172 … orm=LMLTCC Vor allem aber kann ein Router hier nicht von selber erkennen, wo die Gradeausspuren hinführen. Das wird in allen Proposals übersehen, und deshalb werde ich wahrscheinlich auch gegen beide jetzt zum Voting freiegebene Proposals stimmen.

Die Kreuzung ist ja echt ein guter sehr komplexer Testfall, ist ja echt böse, müßte aber mit meinem Schema funktionieren, auch wenn ich nicht durchgeklingelt habe.

Was du oben übersiehst, und darauf beziehen sich die vier Richtungen, ist die Tatsache, daß das komplexe Gebilde "Kreuzung" doch in der Praxis nichts weiter ist, als eine Ansammlung von logischen oder realen Einzelspuren! Jetzt nimm mal so eine Einzelspur her: da kann man man pro Verkehrsteilnehmer doch nur vorwärts, rückwärts, links oder rechts fahren. In der Realität kann man natülich in alle Richtungen fahren, aber nur die vier sind relevant für den Fall den man hier modellieren will und die Spuren sind ja normalerweise auch nur relativ schmal, so daß man dien Fall das man auf den 3 m theoretisch auch noch schräg fahren kann, vernachlässigen kann. Dieses generische Spurmodell deck dann dank der eh notwendigen Verkehrsmittelunterscheidung für die vier Richtungen (siehe z.B. die Busspur) gleich auch noch nebenbei die Fuß-/Radwege sowie den access=* und zumindest auch den größten Teil der turn restrictions mit ab. Was man aber braucht ist dann eine Reklation, weleche Spuren die Fahrbahn bzw. Straße sind, damit die Router ausortieren können, was sie stört, bzw. man die Straße al komplexes Objekt mit Fuß-/Radwegen, Lampen, etc. zur Verfügung hat.

Das aktuell zur Abstimmung stehende Proposal (http://wiki.openstreetmap.org/wiki/Prop … _Extension) ist ja nur eine verkürzte Version des ursprünglichen Drafts.
Mich würde mal interessieren, was ihr von der Idee haltet, die im ursprünglichen Proposal (http://wiki.openstreetmap.org/wiki/Prop … lPreVoting) unter Punkt 3.5 - "Lane Connectivity" - beschrieben ist.

Übrigens wird dort unter Punkt 4.3 - "Bifurcation" - auch das Problem der sich aufspaltenden Spur betrachtet.

Seoman

Seoman wrote:

Mich würde mal interessieren, was ihr von der Idee haltet, die im ursprünglichen Proposal (http://wiki.openstreetmap.org/wiki/Prop … lPreVoting) unter Punkt 3.5 - "Lane Connectivity" - beschrieben ist.

Nichts. Aufzählungen im value und dazu noch Relationen 😬 Willst du das anlegen, auswerten oder nachbearbeiten?

Übrigens wird dort unter Punkt 4.3 - "Bifurcation" - auch das Problem der sich aufspaltenden Spur betrachtet.

Seoman

Das Ergebnis der Betrachtung kann mich nicht überzeugen. Wieder Relation mit Aufzählung. Da wäre das separate Spurmapping auch im Vorteil, denn die Info zur Fahrmöglichkeit liegt auf der Spur vor der Verzweigung, da die aufgezeichneten Pfeile gemappt werden.

Gerade die zwei für mich recht wichtigen Punkte (die du erwähnst) fehlen mir bei der Abstimmung. 🙁

Fabi2 wrote:

Die Kreuzung ist ja echt ein guter sehr komplexer Testfall, ist ja echt böse, ...

Stimmt, aber richtig interessant wird die Ecke, wenn man die Breitenfurter Straße, die Edelsinnstraße und die Wienerbergbrücke mit den vier Kreuzungen betrachtet:
http://www.openstreetmap.org/?lat=48.17 … 8&layers=M
da haben wir dann noch das Linienbündel/Brücken-Problem inklusive "Bim-Schienen" (Hochdeutsch: Straßenbahngleise), wobei die Spuren wegen der Brücken noch geteilt werden müssten. Hier:
http://forum.openstreetmap.org/viewtopic.php?id=15547
sind wir wie in den anderen Diskussionen zu Brücken ja nicht wirklich voran gekommen.
Streng genommen müsste "für die Renderer" jede lane=* noch bridge=yes und layer=1 bekommen und schon wird Wien zur 1000-Brücken-Stadt.
Ich sehe da eigentlich nur eine vernünftige Chance, wenn wir endlich mit Relationen für Linienbündel (type=collection oder sowas) arbeiten, auf die dann die Brücken/Tunnel-tags gelegt werden. Mit der area-Lösung klapt's ja nicht beim rendern http://www.openstreetmap.org/?lat=48.17 … 8&layers=M

Trotzdem reizt mich diese Wiener Ecke, um meinen lane-mapping-Vorschlag mal mit JOSM an einer Datenkopie zu testen.
Freiburg muss dann warten.
Edit:
Oder bleibe ich doch vor der Haustür 🤔
http://maps.google.de/maps?q=Freiburg&h … g&t=h&z=18
http://maps.google.de/maps?q=Freiburg&h … g&t=h&z=18

Garmin macht nen großen Bogen um spurgemappte Kreuzungen: 😉

Wer Langeweile hat kann ja mal den Fehler suchen. Hier der Link:
http://www.openstreetmap.org/?lat=51.69 … 85&zoom=16

Chris

chris66 wrote:

Wer Langeweile hat kann ja mal den Fehler suchen. Hier der Link:
http://www.openstreetmap.org/?lat=51.69 … 85&zoom=16

Chris

Moin

Falscher oneway 🙂 Waren also nicht die Spuren 😉
http://www.openstreetmap.org/browse/way/132071715
habs noch drin gelassen.

Ich habe der Kreuzung mal eine Runde turn restrictions spendiert. Den falschen oneway habe ich als Anschauungsobjekt aber mal stehen lassen ...

Schön, dh. statt die Kreuzung zu verbessern wird sie weiter verkompliziert. 🙂

Edit: Fehler ist korrigiert.

Zartbitter wrote:

Ich habe der Kreuzung mal eine Runde turn restrictions spendiert. Den falschen oneway habe ich als Anschauungsobjekt aber mal stehen lassen ...

Drei "no_u_turn", von denen eigentlich nur der südwestliche gerechtfertigt ist, weil da die durchgezogene Linie die gegenläufigen Spuren trennt. Die beiden anderen sind unnötig, denn Wenden ist dort möglich (wenn es der Verkehr zulässt).

Das muss sich doch nicht widersprechen 😉

Bei genauer Betrachtung der bing-Fotos, sind die drei "only_straight_on" mitten auf der Abzweigung auch unnötig. Ich sehe nichts, weshalb ich da nicht auch wenden dürfte, wenn ich entsprechend risikobereit bin. Und durch die oneway schließen sich alle weiteren Möglichkeiten aus.

Edit:
gerade als Anleitung gefunden:
http://trolug.de/lib/exe/fetch.php?medi … trolug.pdf

Bei genauer Betrachtung der bing-Fotos, sind die drei "only_straight_on" mitten auf der Abzweigung auch unnötig. Ich sehe nichts, weshalb ich da nicht auch wenden dürfte, wenn ich entsprechend risikobereit bin. Und durch die oneway schließen sich alle weiteren Möglichkeiten aus.

Du übersiehst vielleicht, dass hier Spuren als Wege gemappt wurden. Egal, ob man vom Norden kommend links oder rechts abbiegen will, man befindet sich auf ein und derselben Straße. Natürlich kannst du dich links einordnen und im letzten Moment umentscheiden und dann doch rechts abbiegen. Aber von den Daten muss klar sein: Eine Linksabbiegespur geht nach links, oder man kann sie gleich weglassen. Die Abbiegespuren trennt auf den letzten Metern jedenfalls noch eine durchgezogene Linie und die Fahrspuren sind mit Richtungspfeilen versehen, so dass das auch in RL klar ist. Logisch, du kannst das im Auto einfach ignorieren, wenn kein anderes Fahrzeug neben dir steht ... wer macht das nicht ab und zu.

Die no-u-turns sind gerechtfertigt, weil nach Zusammenführung der Spuren zuerst noch eine durchgezogene Linie vorhanden ist, bis sie später in eine gestrichelte übergeht. Wer unbedingt mitten auf der Straße wenden will, kann das ja 5m später machen, so wie es sonst überall mitten auf "normalen" Straßen erlaubt und (oft) auch möglich ist 😉 Der Cloudmade-Router arbeitet je nach Einstellung z.B. so, um Abbiegebeschränkungen zu umgehen: http://maps.cloudmade.com/?lat=54.67405 … travel=car

Für das Routing, eine der wichtigen Anwendungen der OSM-Daten (eine, nicht unbedingt die alleinseligmachende, um Missverständnisse zu vermeiden *g*) sind turn restrictions grundlegend. Sonst lässt dich ein Navigationssystem an jeder beliebigen derartig gemappten Kreuzung mitten drin wenden, statt dich in einem Bogen herumzuführen, falls du dich mal verfahren hast. Und das Navi meint es nicht mal böse, sondern sieht nur kreuzende Ways, die (mangels turn restriction) beliebig genutzt werden können. Da hilft es auch nicht, im Navi das Wenden auszuschalten, denn laut Daten wird ja nur abgebogen, nicht gewendet. Grob vereinfacht gesagt: Lässt man die turn restrictions weg bzw hält man sie für unnötig, kann man auch gleich die Spuren weglassen und die ganze Kreuzung wieder auf die Form "2 ways, T-förmig aufeinandertreffend" zurückführen.

Zartbitter wrote:

kann man auch gleich die Spuren weglassen und die ganze Kreuzung wieder auf die Form "2 ways, T-förmig aufeinandertreffend" zurückführen.

+10, dann wäre die Kreuzung wieder im KISS-Prinzip[1]. 🙂

Chris

[1] Keep It Simpel, ihr lieben Spurmapper

Naja, der richtige Spurmapper würde die Kreuzung wahrscheinlich auch auf die T-Kreuzung reduzieren und den Rest mit Wegen mit lane-Tag machen. Leider ist das noch nicht standardisiert und deshalb kommt's halt zu sowas.

hurdygurdyman wrote:

Fabi2 wrote:

Die Kreuzung ist ja echt ein guter sehr komplexer Testfall, ist ja echt böse, ...

Stimmt, aber richtig interessant wird die Ecke, wenn man die Breitenfurter Straße, die Edelsinnstraße und die Wienerbergbrücke mit den vier Kreuzungen betrachtet:
http://www.openstreetmap.org/?lat=48.17 … 8&layers=M
da haben wir dann noch das Linienbündel/Brücken-Problem inklusive "Bim-Schienen" (Hochdeutsch: Straßenbahngleise), wobei die Spuren wegen der Brücken noch geteilt werden müssten.

Das geht sogar noch, was schwieriger ist, und was Leute hier ja schon mit abbilden wollten, ist es, wenn die Straßenbahn teilweise die Spuren mitbenutzt. Da kommt man um das Erfassen aller Spuren als Flächen nicht mehr herum, denn wie will man sonst genau releativ zu einer Linie angeben, wo jetzt die Straßenbahn gleise liegen?

Das Spurproblem ist, zumindest theoretisch, gar nicht so kompliziert:
Da sind zuerst die, noch zu mappenden, Pflastersteine, die bilden dann die Spur als logisches Gebiklde. Mehrere Spuren sind die Fahrbahn, was, soweit ich weiß, die urspründliche Bedeutung von highway=* ist. Zuletzt kommt dann evtl. noch die Straße als abstraktes Gebilde aus Fahrbahnen, Fuß- und Radwegen, Lampen, etc. Was mas man in dieser Struktur nicht aus liegt_in ermitteln kann, muß man mit Relationen abbilden.

Das Problem ist, das highway=* urspünglich als Fahrbahn definiert wurde und das auch bleiben sollte, und man damit wirklich nur echt baulich abgetrennte Fahrbahnen mappen sollte. Für Spuren sollte man zumindest Wege oder besser gleich Flächen (das wäre besser für die spätere Erfassung der Plastersteine und Staßenbahngleise) nehmen. Damit man nicht noch mehr schreit wegen dem Routing das ja dann über Flächen funktionieren müsste, nimmt man vielleicht doch erst mal Wege und akzeptiert, das man die genaue Lage der Straßenbahngleise dann nicht erfassen kann, aber dann muß man später alles umständlich ändern und umtaggen, wenn man das doch Erfassen will, was ja absehbar, nur eine Frage der Zeit und an sich auch gut und möglich sein sollte.

Wenn man als Kompromiß daraus erst mal die Spuren als Wege und weitere zusätzliche Detailstufe unterhalb der, dann durch eine Relation dargestellten Fahrbahn (wo zusätzlich noch der Weg des alten highway=* aus Rückwärtskompatibilitätsgründen mit drin ist), mit rein nimmt, dann braucht man natürlich die zusätzlichen Sachen, die auf der alten fahrbahnebene die Deatils der spuren darstellen sollten, wie z.B. Abbiegebeschränkungen, nicht mehr.

Im Grunde ist das, was jetzt ja schon mit dem highway=* + oneway=yes mapping gemacht wird, genau der Ansatz den ich erweitert, eben um alle vier (Fahr)richtungen pro Verkehrsteilnehmer, hier schon als Vorschlag gepostet habe. Nur das es schlecht ist, dafür highway=* Zweckzuentfremden und man da besser eben lane=yes + vehicle:forward=yes macht, was dem alten highway=* + oneway=yes entsprciht.