Routing / Spurmapping

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=:
via=
to=:

???

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.

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=Werftstra%C3%9Fe%2FL52&daddr=Unbekannte+Stra%C3%9Fe&hl=de&ie=UTF8&ll=54.314458,10.150509&spn=0.010827,0.019526&sll=54.316137,10.151292&sspn=0.001353,0.002441&geocode=FZDMPAMdM-eaAA%3BFdfNPAMdXuSaAA&oq=bremen+seba&mra=mift&mrsp=0&sz=19&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. :wink:

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 :slight_smile:
http://maps.google.de/maps?saddr=Werftstra%C3%9Fe%2FL52&daddr=54.3180137,10.1552064+to:Unbekannte+Stra%C3%9Fe&hl=de&ie=UTF8&ll=54.31601,10.151249&spn=0.00485,0.00883&sll=54.316284,10.151295&sspn=0.001213,0.002207&geocode=FZDMPAMdM-eaAA%3BFb3TPAMdxvSaAClD3cMAVFayRzH7KxWDSX5X5w%3BFbnNPAMdnuSaAA&mra=ls&via=1&t=h&z=17

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.

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.

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.334078&lon=7.826449&zoom=18&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 :confused:

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 :wink:

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 :confused:
http://maps.google.de/maps?saddr=Werftstra%C3%9Fe%2FL52&daddr=Unbekannte+Stra%C3%9Fe&hl=de&ie=UTF8&ll=48.340726,7.886035&spn=0.001528,0.002411&sll=54.316137,10.151292&sspn=0.001353,0.002441&geocode=FZDMPAMdM-eaAA%3BFdfNPAMdXuSaAA&oq=bremen+seba&mra=mift&mrsp=0&sz=19&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.

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.

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

Siehe weiter vorn im Tread. Nochmal der Link: http://wiki.openstreetmap.org/wiki/User:Fkv/lane_mapping_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.

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

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

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

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