Eben. Das lässt sich mit der Stern-Topologie lösen. Und sofern man
jede Spur einzeln mappt, auch noch für jeden Mapper verstehen und
handhaben. Das beste ist, wenn man highway=*_link o.ä. als tag
akzeptiert, muss man kein neues Schema einführen. Es geht dann einfach
nur um eine bestimmte Art, Kreuzungen zu mappen.. Was Renderer mit
diesen Daten machen, ist eigentlich deren Bier - z.B. könnten komplexe
Kreuzungen erkannt werden und entsprechend gerendert werden, anstatt
einfach nur die Linien der DB 1:1 zu übertragen..
Zählt man Fuß und Radwege nicht dazu, und mappt auch die Spuren nicht
einzeln, kann es maximal 4 Knoten mit dem aktuellen Tagging-Schema
geben, wenn beide Wege gerichtet sind und eine bauliche Trennung
zwischen diesen existiert:
^
| |
>>>>>
<<<<<
| |
v
Genau dann lässt sich aber die Realität u.a. mit den aktuellen
turn_restrictions nicht korrekt abbilden - jeder way, der zur Kreuzung
führt, "versteckt" Fahrspuren. Für turn_restrictions ist es aber
relevant, um welche Fahrspur es sich handelt.
Die Verfechter des Nicht-Spur-Mappings wollen dazu dann das
turn_restrictions proposal erweitern - ein Hort für Fehlerquellen: am
way wird mit kryptischen Tags die Fahrspuranordnung getaggt, in der
Relation dann mit "from.1" o.ä. die erste Fahrspur des from-ways
referenziert. Ich sehe schon Websiten wie
"turn-restriction-lane-analyzer" ;-)
Zudem geht es nicht nur um die turn_restrictions, eine Spur kann sich in
vielen weiteren Eigenschaften von anderen Spuren unterscheiden - die
denen von Einzelspurwegen gleichen, z.B.
- kann nur die dritte Fahrspur ein cycleway=lane besitzen, der
Radfahrer über eine extra angelegte Spur mit geradeaus führt (man kann
auch die Fahrradspur einzeln mappen, wenn aber die Autospur gemappt ist,
kann man cycleway=lane verwenden - die Information wäre hingegen ungenau
oder falsch, würde man sie an einen Weg mit "lanes=4" hängen, da dann
unklar ist, wo sich die Fahrradspur befindet)
- kann die x-te Spur gepflastert sein, die anderen nicht
- kann die x-te Spur construction: (mit start_date, end_date)
sein, während die anderen betrieben werden
- kann die x-te Spur andere access=*-values haben, als die
anderen (bus lanes, taxi lanes, etc. pp.)
- all das wäre tagging-technisch der Horror, will man es mit einem
einzigen way erfassen, so etwas wie lane.1.surface= lane.2.access=
etc. pp. entsteht - und in Relationen könnte ich die Einzelspuren des
Weges immer noch nicht vernünftig referenzieren (weil sie eben nicht als
Wegobjekt vorhanden wären)
- eine Lösung mit from.X= in den Relationen wäre auch nicht gut,
weil man dann mindestens die Anzahl Fahrspuren Relationen auf diesem Weg
hat - editing-technisch ein Graus..
Den klassischen Ansatz zu verwenden, also alle Wege mit allen anderen
kreuzen zu lassen, funktioniert aber beim Einzelspurmapping nicht - dann
hätte man bei 6x6 Fahrspuren 36 Schnittpunkte - also auch wieder data
bloat - deshalb der Stern-Ansatz für komplexe Kreuzungen. Es wäre aber
auch mit 36 Schnittpunkten machbar, wenn jemand seine Mapnik-Darstellung
behalten möchte - dann wären in den turn_restrictions viele kleine ways
in den via-Rollen zu finden - nicht schön, aber machbar.
Gruß
Am 06.03.2012 00:32, schrieb Stephan Wolff:
Am 05.03.2012 22:46, schrieb Frederik Ramm:
Wie dem auch sei, "korrektes" Routing ist auch ohne Fahrspur-Tagging
moeglich. Es ist vielleicht weniger praezis, und der Nutzer muss die
Anweisung "an der naechsten Kreuzung links" selbstaendig um "vorher auf
die Abbiegespur wechseln" ergaenzen.
Seltsamerweise hat sich in OSM kein Konzept für Kreuzungen etabliert.
Je nach Komplexität der Straßen (1 oder 2 Fahrbahnen, getrennt erfasste
Fuß- und Radwege) ergeben sich meist 1-16 Schnittpunkte der ways.
Der menschliche Betrachter der Karte kann raten, welche der
Schnittpunkte zur selben Straßenkreuzung gehören. Der Router weiß
nicht, was eine Kreuzung ist, und gibt meist nur "nach 100m links" aus.
Ampeln sind neben dem highway, auf dem highway an der Haltelinie,
am Kreuzungspunkt mit dem ersten querenden way (meist der Radweg) oder
nur auf Kreuzungspunkten der Straßen eingetragen. Aussagen wie "an der
dritten Ampel links" sind mit den aktuellen OSM-Daten kaum zu erzeugen
oder auszuwerten.
Viele Grüße
Stephan
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
