[Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.

Mario Salvini salvini at t-online.de
Fr Jan 23 12:51:26 UTC 2009


Martin Koppenhoefer schrieb:
>
>
> Am 21. Januar 2009 20:18 schrieb Mario Salvini <salvini at t-online.de 
> <mailto:salvini at t-online.de>>:
>
>     Hi Martin,
>
>     ich wollte dir darauf auch noch antworten, aber hatte irgendwann
>     den Thread nichtmehr gefunden.
>
>     Was im Linienbündel-thread ja noch im Raum stand war die große
>     frage, wie man denn jetzt von einer Lane eines Weges auf die Lane
>     eines anderen Wegstücks kommt.
>
>     Bei Abiegeprozessen, hatten wir die Turnrestriktion-Relation ins
>     auge gefasst.
>
>     Geradeausfahren geht sogar ohne sowas, wenn in der
>     lanegroup-Relation wird ja definiert, wo die einzelnen Lanes liegen.
>
>     z.B.
>
>     Way1 besteht aus den Relations = footway, cycleway, carlane,
>     divider, carlane, cycleway, footway
>
>     lanegroup-Relation zu Way1 hätte also die Positionen = -3; -2; -1;
>     0; 1; 2; 3
>
>     Way2 besteht aus den Relations = footway, carlane, carlane, footway
>
>     lanegroup-Relation zu Way2 hätte also die Positionen =  -2; -1; 1; 2
>
>     wenn also diese beiden Wege direkt aufeinander stoßen würde es
>     also wie folgt aussehen:
>
>     F-B-C-D-C-B-F
>
>     #-F-C-#-C-F-#
>
>     Die Carlanes stimmen z.B. schonmal überein. Jetzt müsste man sich
>     nur noch eine Handhabe ausdenken, was passiert, wenn z.B. eine
>     Spur wegfällt (im Beispiel der cycltrack, weil die Radfahrer z.B.
>     aber dort auf der normalen Straße weiterfahren sollen).
>
>
> das Problem ist hier, dass nicht *hin und wieder* mal ne Spur 
> wegfaellt, weil Radfahrer auf der Strasse weiterfahren sollen, das 
> bekommt man sicher in den Griff. Das Thema ist, dass die Spuren bei 
> grossen Strassen *staendig* variieren, sei es weil 
> Parkerschliessungsspuren hinzukommen und wegfallen, weil Busspuren 
> hinzukommen und wegfallen (auch Buchten fuer Haltestellen), oder weil 
> Abbiegespuren ..., das hast Du gerade bei den grossen Strassen, die ja 
> hauptsaechlich betroffen sind, permanent alle paar Meter. Da verliert 
> man total den Ueberblick, wenn es mehr lanes werden als in Deinem 
> Beispiel (in meinem Beispiel habe ich z.B. fuer bestimmte Stellen 36 
> "lanes" ermittelt), und mit einer schlichten Nummerierung sind die 
> Fehler da vorprogrammiert, das bekommst Du nicht mehr uebersichtlich. 
> Ausserdem werden die ways dadurch extremst zerstueckelt, weil bei 
> dieser Breite in *einer* der Lanes immer was passiert, d.h. alle 10 
> Meter musst Du den way teilen.
>
> Die Folge ist aber auch, dass Restriktionen und damit tags dann 
> staendig wechseln (oneway:lane24=-1 wird dann zu oneway:lane22=-1, 
> etc.). Da bist Du heftig am lanes zaehlen. (und ist extrem unintuitiv 
> zu bearbeiten/kontrollieren).
>
>
>
> Gruss Martin
ich glaube, es hat auch niemand gefordert, dass alle Situationen *nur* 
noch mit lane-Relation+Tags umgesetzt werden sollen.

ich hab mal nen Lösungsversuch von mir als osm-file angehangen. (EDIT: 
is scheinbar zugroß für die Liste, also bei Interesse einfach Mail an mich)

Bei diesem riesigen Verkehrsgepflecht habe ich 4 Ways von oben 4 von 
unten, 2 von links und rechts eine seperate buslane.
Außerdem habe ich die Pseudowege im Kreuzungsbereich entfernt und eine 
Kreuzungsarea angelegt mit der jeder Weg verbunden ist.
Abbiege-Restriktionen lassen sich so sauber über Relations lösen und die 
gerederte Karte sieht nicht so "crazy" aus, wie sie es momentan tut.

Kommentare sind erwünscht

-- 
Mario




Mehr Informationen über die Mailingliste Talk-de