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.
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.
Das ist eine naheliegende und sinnvolle Ergänzung.
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…
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.
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.
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?
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.
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.
Danke für das Kompliment. Macht zwar erst mal Arbeit, spart dann aber tausend Erklärungen.
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?
Da kann man sich gleich mehr drunter vorstellen als bei einem ellenlangen Text
