[halLEipzig] Rants on route/line terminology and artificial differentiation between line/line_variant

Mo Okt 11 22:32:16 CEST 2010

  Hi,

ich habe mit Interesse die Fortschritte bei der Anpassung der Tags der 
OSM-ÖPNV-Daten Leipzigs verfolgt und auch selbst mit Hand angelegt.  
Allerdings sind mir beim Studium des Proposals von Oxomoa und den 
Diskussionsseiten dazu mehrere Unstimmigkeiten aufgefallen:

- die Differenzierung von route / line wirkt gekünstelt und ist auch 
nicht die Vereinheitlichung, die sich Oxomoa gewünscht haben dürfte, 
denn im Englischen wird line weit seltener im Sinne vom dt. "Linie" 
gebraucht, als man zunächst denken würde
- tatsächlich ist es so, dass Buslinien im Englischen als bus routes 
(bes. UK) bezeichnet werden

siehe dazu:  [1]

Die Argumente, die Oxomoa bringt, sind bei näherer Überlegung auch nicht 
sonderlich durchdacht.  Er möchte /route/ gern außschließlich als 
Sammlung physischer Wege begreifen, wohingegen eine Linie das 
Konglomerat aus Verkehrsmittel, Haltepositionen, Haltestellen und 
/route/ sein soll.

Warum ist diese Auftrennung unnötig, wenn nicht sogar konterintuitiv?  
Nun, die /route/ entsteht ja gerade durch die Linie - würden wir die 
/route/ erfassen, wenn es keine zugehörige Linie gäbe?  Ganz klar nein.  
Anders gesagt, die Sammlung physischer Wege, die eine bestimmte Linie 
befährt, kommt nur durch sie selbst bzw. eine ihrer Varianten zustande.

Wenn man sich einfach darauf einlässt, zu sagen, dass eine Route (im 
Sinne der Sammlung ihrer physischen Teilwege) zur Linie wird, indem 
beschrieben wird, welches Verkehrsmittel die Route bedient, sind wir 
tatsächlich wieder beim "common usage pattern", den wir vor Oxomoa 
hatten.  Tatsächlich ist es doch so, dass sich bis auf den Ersatz des 
Wortes "route" durch "line" in den Relationen wenig geändert hat - und 
während wir dachten, dass "line" besser ist, weil "line" besser klingt 
(es ist im dt. dem Wort "Linie" sehr ähnlich), ist es in der Tat so, 
dass die vorige Nutzung der termini keine erfassungstechnischen 
Nachteile hatte und außerdem sprachlich exakter am tatsächlichen 
englischen Gerbauch der termini dran war.  Für Übersetzungen gibt es 
immer noch Namensräume, da sollten tags nicht herhalten müssen.

Man könnte argumentieren, dass eine Trennung von Route (als Sammlung der 
Wege) und Linie sinnvoll wäre, für den Fall, dass mehrere Linien die 
gleiche Route bedienen.  Tatsächlich ist es so, dass wenn eine Linie in 
Hin- und Rückweg aufgespalten wird, wir fast immer mindestens zwei 
Linienvarianten pro Route haben.  Das ändert aber nichts daran, dass die 
Route erst aufgrund der Linie(nvarianten) besteht.

Da der Gebrauch des Wortes "line" gegenüber der bisherigen und 
gebräuchlichen Verwendung von "route" keinen Mehrwert bringt und 
zusätzlich dem engl. Sprachgebrauch entgegensteht, schlage ich vor, 
route zu verwenden.  Folgende Dinge sind einleuchtend und werden in der 
Praxis bisher auch so gehandhabt:

type=route   (Relation beschreibt eine Sammlung physischer Wege, ein 
Verkehrsmittel ist nicht angegeben - es ist also offen, wer diese Route 
benutzt und womit sie benutzt wird)

type=route   (und zusätzlich:)
route=bicycle/bus/train/tram    (die Relation beschreibt eine 
Fahrradroute, Buslinie, Zuglinie oder Tramlinie)

Eine Buslinienrelation, die nicht mehr betrieben wird, deren Route der 
Mapper aber aus bestimmten Gründen in der Datenbank aufheben will, 
könnte einfach mit "abandoned=yes" o.ä. getaggt werden.  Fakt ist:  eine 
/Linie/ ist immer an das vorhandensein ihrer Route (Sammlung Wege) 
gebunden.  Umgekehrt macht das Erfassen einer Route fast überhaupt 
keinen Sinn, wenn nicht auch eine Linie auf ihr betrieben wird (bzw. 
wenn sie nicht, wie im Fall von Radrouten, ausgeschildert ist).  Weshalb 
eine Route immer Teil der Linienrelation sein, und nicht extra als 
Routenrelation erfasst werden sollte, die man dann doch nur in die 
Linienrelation aufnimmt, folgt..

Nun, da die Begrifflichkeiten erörtert wurden, bleibt zur Diskussion der 
logische Aspekt des Datenmodells und zwar im Bezug auf die Modellierung 
von "Linienvariante" vs. "Linie".

siehe dazu:  [2]

Gerade im Hinblick auf die Trennung einer Linie in Hin- und Rückweg, 
entsteht der Wunsch die Route (Sammlung physischer Wege) der Linie nur 
einmal erfassen zu müssen.  Weiterhin wäre es möglich, dass auf einer 
Route mehrere Linien verkehren (das ist in der Praxis SELTEN der Fall - 
üblicherweise haben verschiedene Linien auch immer eine verschiedene 
Streckenführung!).

An dieser Stelle gilt es abzuwägen, ob sich die Redundanzvermeidung 
durch eine höhere Komplexität im Relationsbaum lohnt.  Beispiel:

Relation1:  type=route  und way members
Relation2:  type=route route=bus ref=5 from=Dest1 to=Dest2  members:  
Relation1/role=forward + Haltepos + Haltestellen
Relation3:  type=route route=bus ref=5 from=Dest2 to=Dest1  members:  
Relation1/role=backward + Haltepos + Haltestellen
Relation4:  type=route route=bus ref=5 name=Businie5 members:  Relation2 
Relation3

Relation2 und Relation3 wären was Oxomoa als Linienvariante beschreibt, 
Relation1 ist, was Oxomoa als Route beschreibt und Relation4 schließlich 
die Beschreibung der Linie (Aggregation der Varianten der Linie, 
Relation 2 und 3)..

Hier wurde Redundanz vermieden, denn die Sammlung physischer Wege 
existiert nur in Relation1, man erkauft sich das aber mit
- höherer Komplexität (sowohl Mensch als auch Maschine muss mehr Aufwand 
betreiben um sich "zusammenzusuchen", woraus die Linie, betrachtet man 
Rel2/Rel3/Rel4  eigentlich besteht
- Verlust an Dynamik (angenommen die Rück-linie Relation3 folgt zwecks 
Bauarbeiten einer anderen Route:  es wäre eine neue Routenrelation zu 
erstellen, diese Relation3 hinzuzufügen und Relation1 zu entfernen)

Wie man sieht, ist mehr Redundanz in diesem Fall besser, die Route 
(Sammlung physischer Wege) sollte hier Teil der Linie(nvariante) sein, 
um besser auf Änderungen reagieren zu können.  Dies ist auch momentan in 
Leipzig so umgesetzt:  Die Tramlinien z.B. erfassen die Route pro 
Richtung selbst, nicht in einer eigens dafür vorgesehenen Relation (vom 
Beispiel oben abgeleitet wäre das:  member aus Relation1 werden member 
von Relation2 und Relation3, Relation1 verschwindet).

Evtl. ist es beim Zug sinnvoll die Routenrelation extra zu erfassen, 
etwa wann tatsächlich /sehr viele/ verschiedene Linien die Route 
Leipzig-Berlin bedienen.  Selbst dann ist das bestehende tagging 
ausreichend und aussagekräftig.  Die Routenrelation bekäme type=route 
route=railway  und die Linienrelationen würden diese Routenrelation als 
member aufnehmen und (type=route route=train) nutzen.  Analog dazu 
könnte eine Tramroute  route=tramway und eine Busroute route=busway 
nutzen.  Weiterhin wird auch durch die Typen der member deutlich, ob es 
sich exklusiv um eine Routenrelation handelt (nur waymember), eine 
Linienrelation (nodemember in der role=stop vorhanden), bzw. eine 
Linienrelation, die ihre Route selbst verwaltet (waymember vorhanden, 
statt relationmember).

Beim Tagging von Linienvarianten hat sich Oxomoa ebenso die 
Redundanzvermeidung zum Ziel gesetzt, indem er wichtige Attribute der 
Linie in die Aggregation (Linienrelation) hochzieht und nur ein Minimum 
an tags (from=, to=, alternate=) für die Linienrelation empfiehlt, siehe 
[3].  Das hat die gleichen Probleme, die gerade erörtert wurden:  
Software und Mensch müssen mehrere Relationen browsen, um sich ein Bild 
einer Linie bzw. Linienvariante machen zu können.  Es vermeidet 
Redundanz, verliert aber wieder an Dynamik beim Auftreten von 
Änderungen.  Von daher ist es besser die Unterscheidung 
Linienvariante/Linie gänzlich aufzugeben, bzw. zu lockern (siehe [2]) 
und einfach so davon zu sprechen, wie wir das auch erfassen:

- Relation2:  Linie 5 Richtung Dest2
- Relation3:  Linie 5 Richtung Dest1
- Relation4:  Linie 5E Richtung Dest2E
- Relation5:  Linie 5E Richtung Dest1E

- Relation6:  Linie 5     mit Relation2/3/4/5 als member

Die Aggregation der Teillinien ist dabei optional, da jede Variante 
einer Linie auch für sich allein stehen kann (d.h. Relation2/3/4/5 haben 
das komplette Set an Tags (from,to, alternate, operator, network, ref, 
etc.).  Nur Schlüssel die nicht vorhanden sind, werden von einer 
/optional/ vorhandenen aggregierenden Relation (Relation6) geerbt (z.B. 
color= oder text_color=).

Weiterhin ist auch vorstellbar, dass auf diese Weise SEV modelliert 
werden kann:

-Relation17: Linie 5 von Dest1 nach B  type=route route=tram  (mit 
Haltepos/Haltestellen)
-Relation18: Linie 5 SEV von B nach C  type=route route=bus  (mit 
Haltepos/Haltestellen)
-Relation19: Linie 5 von C nach Dest2 type=route route=tram  (mit 
Haltepos/Haltestellen)

- Relation2:  Linie 5 Richtung Dest2  type=route route=tram mit member 
Relationen 17/18/19
- Relation3:  Linie 5 Richtung Dest1  type=route route=tram
- Relation4:  Linie 5E Richtung Dest2E  (tags von Relation6 geerbt, es 
wäre aber kein Fehler, sie anzugeben)
- Relation5:  Linie 5E Richtung Dest1E  type=route route=tram

- Relation6:  Linie 5  type=route route=tram    mit Relation2/3/4/5 als 
member

LG,
Christian (cmuelle8)

[1] 
http://wiki.openstreetmap.org/wiki/User_talk:Oxomoa/Public_transport_schema#line.3D_instead_of_route.3D.3F
[2] 
http://wiki.openstreetmap.org/wiki/User_talk:Oxomoa/%C3%96PNV-Schema#type.3D.3F

> Am 10.10.2010 00:20, Benjamin John:
>> Hallo,
>> es ist vollbracht: alle Tram-Linien in Leipzig sind
>> 1. im neuen Schema
>> 2. bis auf ein paar fehlende Haltestellen vollständig (siehe [1])
>> 3. an den aktuellen Netzplan 2010 angepaßt
>