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.
…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!
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.
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.
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.
Hast du dir die entsprechende mit JOSM erzeugte OSM-Datei auch mal im Texteditor angeschaut
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?
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.
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.
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.
Interessante Diskussion, die mich bestärkt, weiterzumachen.
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 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.
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.
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.17225100131205~16.327479319036627&lvl=20&dir=0&sty=a&form=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/e/eb/Lane-Tagging-L%C3%B6sungsansatz.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.