On 19.01.2012 15:37, Andreas Labres wrote:
Aber wenn das jetzt auf Spuren plus Richtungshinweisschilder (IMHO gehört beides
untrennbar zusammen, grade für einen Router) beschränkt,

Grade fürs Routing müsste es egal sein, was auf den Schildern steht, und was für Pfeile auf dem Boden aufgemalt sind. Die Bodenmarkierungen können auf dem Display angezeigt werden, aber fürs Routing selber ist relevant, welche Spur wohin führt. Das muss nicht identisch sein. Auf vielen Kreuzungen und Abfahrten gibts überhaupt keine Pfeile am Boden.

Ich glaube, man sollte die Spurendefinition von der Spurenzuordnung (zur Fortsetzung) trennen.

Beispiel:
lanes=R,B,F,FL||fl,f,b,r für beidseitig Linksabbiegeundgradeausspur, Gradeausspur, Radfahrstreifen, Rechtsabbiegespur und in der Mitte eine doppelte Sperrlinie.
und zusätzlich:
lane_matching=0+1+2.1, 2.2, 2.3, 3

Erklärung:
lane_matching=waynr[.spurnr[-spurnr]] [+ ...] [, ...]
waynr= 0...umkehren, 1...linkeste Straße, 2...zweitlinkeste usw.
spurnr=Spur auf Folge-Way: 1...linkeste in Fahrtrichtung zu befahrende Spur, 2...zweitlinkeste usw.

mit "+" zusammenhängen wenn man von der Spur auf mehrere Ways kommt

erst die Angaben, von wo man von der linkesten in Fahrtrichtung zu befahrenden Spur hinkommt, nach dem Komma die Angaben für die zweitlinkeste usw.

lane_matching=* in Way-Richtung, lane_matching:backward=* gegen die Way-Richtung.

Damit lassen sich, wenn ich nichts übersehen habe, alle Routing- und Darstellungsprobleme ohne Relationen lösen. Auch die Abbiegerelationen sind dann nicht mehr nötig.

Auch die Vereinigung und Verzweigung von Spuren ist damit abbildbar:
3 Spuren, mittlere teilt sich:
lane_matching=1,2-3,4
3 Spuren, linke hört auf:
lane_matching=1,1,2

Vorteile dieser Syntax:
- Spurenassistenten sind möglich (das geht mit dem Proposal, über das grad abgestimmt wird, noch nicht!)
- kurz
- Radfahrstreifen, Mittelstreifen usw. alles abgedeckt
- Spurenassistenten auch für Radfahrer usw. möglich
- keine Relationen mehr nötig

Nachteile:
- wenig Keys, relativ komplexe Werte, daher nicht "osm-like" (viele Keys, einfache Werte)
- ?

--
Friedrich K. Volkmann       http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

_______________________________________________
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Antwort per Email an