[Talk-de] Linienbündel -- Vorschlag lane_group

[Tobias Knerr]

Sven Anders schrieb:
> Können wir dann nicht wenigstens die Anzahl der Relationen begrenzen ala:
> 
> 1. Hauptrelation mit highway member
> 
> 2. Maximal eine weitere Ebene mit einer Relation pro Spur. Im Moment dürfte 
> ich nach dem Vorschlag auch noch Unterrelationen von Unterlationen machen.
>
> Die Spur -Relation könnte dann auch einen anderen Typ bekommen als die
> Haupt-Relation

Kann man zugunsten der Bearbeitbarkeit tun, zugegeben ist sonst eine
Handhabung ohne Sondertools wirklich kaum mehr möglich. Hab das also mal
vereinfacht:

http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group

In dieser Version besser? Die Spur-Relationen sind type=lane, die
einzige gruppierende Relation ist vom Typ lane_group.

>> ist durchaus eine mögliche Lösung. Ich hätte der Einfachheit halber
>> (Sonderfälle...) allerdings bislang daran gedacht, jede Lane nur einem
>> der Highways zuzuordnen -- bei deinem Beispiel erscheint etwa der
>> Grünstreifen in der Mitte als plausible Trennstelle. 
> 
> Auch eine Möglichkeit. Aber wenn dann die Grunfläche eine Area wird, dann wird 
> das ultrakompliziert für Renderer etc.
> 
> Andere Möglichkeit ist zu sagen das es zwei lane_groups mit jeweils einem 
> highway sind wo nur rechts davon je ein Fußweg und ein Radweg angehängt 
> sind...

Das ist die sonderfallfreiste Lösung, also würde ich das für den Moment
empfehlen. (Die Busspur können wir trotzdem noch ranhängen, halt links
in einer der beiden lane_groups.)

> Brauchen wir dann denn überhaupt lane=cycleway oder könnte man dann nicht 
> gleich wieder highway=cycleway machen?

Grund für den Lane-Key ist:
a) nicht jeder Highway-Typ ist auch als Spur sinnvoll. Was ist eine
secondary-Spur? Und kann sie auch in einem highway=motorway vorkommen?
Und so weiter. Eigentlich gibt es eine Überlappung nur bei den highways,
die in der Realität halt i.d.R. nur einspurig vorkommen (Fußweg,
Radweg...), so dass kaum Spur und gesamter, einspuriger Verkehrsweg
unterschieden werden können.
b) Wenn sich ein Renderer entscheidet (sei es in einer Zoomstufe oder
generell), auch als Way gezeichnete lanes nicht separat zu zeichnen,
sondern sich auf die Highways zu beschränken, dann braucht er nicht auf
Mitgliedschaft in irgendwelchen Relationen zu testen. Das vereinfacht
das Schreiben eines "Minimal-Renderers".

> Bei den Straßen machen wir das ja auch nicht, obwohl wir in meinem Beispiel 
> gerade zwei Straßen haben.

Eigentlich(TM) wäre eine Modellierung als ein Highway mit zwei Lanes und
einem Separator dazwischen möglich. Ist aber nicht kompatibel mit
Bestehendem und fehleranfällig, also betrachten wir das halt als 2
Straßen. Bei dieser Betrachtung sind dann auch 2 Lane-Groups konsequent.

> Dein Ansatz hat leider relative viele Fehlerquellen, wo es nicht valide 
> Ergebnisse gibt.
> 
> z.B. mehrere nicht verbundene highway member.
> z.B. zwei Lanes mit der gleicher Nummer (liegen die dann übereinander?) Naja 
> das gibt sich dann mit API 0.6
> z.B. illegale Nummernwerte z.B. "eins" oder "one"

Die lassen sich tendenziell leicht von einem Validator feststellen.
Punkt 2 und 3 haben sich ja hoffentlich bald erledigt.

Es gibt aber zugegeben noch einige kritischere, etwa: tatsächlicher
Verlauf der Ways passt nicht zu ihrer Anordnung in der Relation. So
etwas lässt sich nicht ohne weiteres automatisiert prüfen.

> Auch muß der Highway auf jeden Fall unterteilt werden, wenn sich die Anzahl 
> der Spuren ändert (z.B eine Busspur / ein Fahrradweg dazu kommt).

Das müsste er bei fast allen Lösungen -- insbesondere auch bei
Tag-basierten. Halte ich aber für akzeptabel.

> Weitere Punkte:
> * Joinen von Wegen bei dem nur einer Member der Relation ist.

Nicht trivial, da hast du leider recht. Im Zweifel (beide Wege haben
Lanes oder es sind Way-Lanes dabei) wird man wohl den Benutzer die
Reaktion wählen lassen müssen.

> Programmiertechnisch ist das auch nicht wirklich simpel, um (wie bei 
> opencycleway.org) die Radwege rechts und links einer Straße zu zeichnen muss 
> man:
> 
> 1. Testen ob eine lane_group Relation zum highway vorhanden ist
> 2. Alle Member der lane_group nach lane=cycleway durchsuchen
> 2a Wenn der Member ein Way ist entscheiden ob man den Verlauf vereinfacht oder 
> selbst zeichnet
> 2b Wennn der Member eine Relation ist, anhand der Position in der Relation 
> selbst rechts oder links vom highway zeichnen.

Es wird einfacher, wenn man 2a pauschal entscheidet:
* Wenn man immer nur einen "gefärbten Rand" zeichnen will, ist die
Unterscheidung zwischen Relation und Way nicht nötig.
* Wenn man Ways immer separat zeichnet, kann man das Randzeichnen auf
Relationen beschränken und lane=cycleway wie highway=cycleway behandeln.

Schwierig wirds in der Tat, wenn man Ways nur manchmal nicht separat
zeichnen will. Das liegt aber nicht am Schema, sondern dürfte, so weit
ich das sehe, ein inhärentes Problem beim Verwenden eigener Ways sein.

> BTW Es ist beim Entwurf noch nicht festgelegt  wo  die Mitte  (der Member 
> highway), in der lane_group ist.

Nirgends, es sei denn, er ist nicht nur in der Rolle eines Highway,
sondern auch in der Rolle einer Lane in der Relation. Die Informationen
des Highway sind ja nicht notwendig identisch mit den Informationen
irgendeiner seiner Spuren (man denke etwa an width oder access).

> Hast du mal Probiert das für Osmarender umzusetzen?

Bisher nicht, und das würde vermutlich auch eher an fehlenden
Kenntnissen in Osmarender und den zugehörigen Sprachen meinerseits als
an irgendwas anderem scheitern.

Tobias "Tordanik" Knerr