[Talk-de] ÖPNV-Relationen in OSM

[Martin Koppenhoefer]

Am 2. April 2012 03:13 schrieb Stephan Wolff <s.wolff at web.de>:
> Die Relationen beschreiben entweder nur eine Richtung einer Linie,
> beide Fahrtrichtungen oder sogar verschiedene Linienvarianten in
> einer Relation.


ja, das ist so, und erstmal kein Problem (verschiedene Varianten in
einer Relation sollte man allerdings ausgliedern)


> Die Straßensegmente sind (teilweise falsch) mit
> "role"-Tag "forward"/"backward", manchmal mit "route", "default",
> "alternate" etc. versehen. "stop_position"- und "platform"-Punkte
> haben "role"-Tags "", "stop", "platform" aber auch "stop:22" oder
> "platform:60:alternate:1". Die Haltestellen sind teils zwischen
> den ways, oft auch unsortiert am Ende.


auch hier gibt es doch durch die unterschiedlichen Mapping-Varianten
nicht grundsätzlich ein Problem, Fehler wie falsche Rollen sollte man
natürlich korrigieren.


> "name"-Tags sind fast immer
> willkürliche Textfolgen aus ref/operator/network/direction.

solange man weiss, welche Linie es ist (ref), ist das doch egal. Den
name-Tag könnte man i.d.R. auch einfach weglassen bzw. beim
Interpretieren nicht weiter berücksichtigen,  da verstehe ich das
Problem ebenfalls nicht.


> "from" und "to" fehlen teilweise oder sind uneinheitlich gebildet.
> Einzig die Liniennummer ist eindeutig im "ref"-Tag enthalten.


Es kommt halt darauf an, was man haben will. Mit der Zeit sind auch
unsere Ansprüche gestiegen, während man früher zufrieden war wenn man
aus der Karte erraten konnte, wo der Bus der Linie 23 langfährt, so
wollen manche Mapper heute auch noch zusätzlich festhalten, dass dort
jeder zweite Bus ein Bus mit erhöhter Kapazität ist, mit einem
durchschnittlichen Fahrzeugsalter von 3.4 Jahren, Behindertenrampe an
Bord, und statistischer Verspätung von 1.2 Minuten um die Mittagszeit
an Haltestelle XY (mal etwas übertrieben dargestellt).


> Viele Relationen sind durch spätere Bearbeitung der ways beschädigt.


kann man schnell richten, wenn man weiss, wo der Bus langfährt.
Üblicherweise kenne ich das von Stellen, die zunächst noch grob
gemappt waren (also z.B. nur ein Way trotz mehrerer Fahrbahnen), wo
aber schonmal jemand eine Buslinie draufgelegt hat. Danach hat beim
Aufsplitten der Richtungen jemand nicht aufgepasst.


> Die Daten reichen aus, um eine Karte mit Liniennummern an Straßen und
> Haltestellen zu erzeugen. Unsortierte Relationselemente, unsinnige
> "role"-Angaben und kleine Lücken erzeugen allenfalls kleine
> Kartenfehler, die der menschliche Betrachter meist ignorieren kann.


stimmt. Wahrscheinlich könnte man mit nicht zu großem Aufwand auch
automatische Auswertungen soweit fehlertolerant gestalten, dass sie
z.B. kleine Lücken ohne menschliche Intervention schließen können oder
unsinnige Role-Angaben ignorieren. Relationselemente zu sortieren ist
normalerweise trivial.


> Für andere Anwendungen sind die Daten ungenügend. Die vielen Tagging-
> Varianten machen es unmöglich, die Daten korrekt zu interpretieren.


s/unmöglich/schwieriger bzw. aufwendiger


> Selbst wenn eine Relationen eine unverzweigte Strecke abbildet und
> keine Fehler hat, kann man die Angaben nicht zur Fahrtplanung nutzen,
> da keine Informationen zu Betriebszeiten, Takt oder Fahrzeiten bietet.
> Viele gedruckte Reiseführer enthalten dagegen grobe Informationen wie
> "bis <Ziel> ca. 70 Min., Mo-Sa 6-22Uhr, So 8-20Uhr, tagsüber alle 15
> Minuten, nach 18Uhr alle 30 Min.", die auch Jahre nach dem Druckdatum
> noch nützlich sind. Solche Informationen wären auch in OSM möglich.


+1, wenn der Mapper es für sinnvoll hält, dann sollte er durchaus
diese Dinge eintragen können, wobei sich das je nach Gegend auch
schnell und häufig ändern kann, so dass jahrealte Informationen
prinzipiell mit Vorsicht zu genießen sind. In meinem Umfeld hier gibt
es z.B. gar keine Fahrpläne (für Busse tagsüber), sondern nur
Informationen wie von Dir genannt (d.h. z.B. "Bus verkehrt Mo-Fr von
6:00-24:00h", jeweils Abfahrt Starthaltestelle).


> Leider können sich die relativ großen Relationen des ÖPNV auch
> unmittelbar störend auswirken.


jede Zusatzinformation macht natürlich die weitere Bearbeitung
komplexer, das gilt auch hier.


> Wenn man etwas an Relationen geändert hat, ist immer ein Konflikt beim
> Upload möglich, der von vielen Mappern nicht korrekt gelöst werden kann.


die Konflikte treten viel eher bei den anderen Route-Relationen auf,
die sich oft übers ganze Land oder sogar international durch die
Landschaft ziehen (Fernstraßen, Fernwanderwege, etc.). Bei einer
normalen Buslinie sollte das nicht allzu oft vorkommen. Klar, je mehr
Leute editieren, und je größer ein Objekt ist, um so eher kommt es
auch zu Konflikten.


> Die Qualität der ÖPNV-Relationen hat sich nach meiner Einschätzung in
> den letzten zwei Jahren nicht gebessert.


Das kommt sicher darauf an, wo man mappt. Hier ist der Fortschritt
unglaublich groß verglichen zum Stand vor 2 Jahren.


> - ein Bot, der jede Nacht die unterbrochenen Relationen repariert, die
> "role"-Tags richtig setzt und nicht automatisch korrigierbare Relationen
> meldet (auch sehr schwierig umzusetzen). Die Mapper könnten unbelastet
> editieren :-)


könnte man machen, wobei ich automatischen Edits ziemlich kritisch
gegenüberstehe: oft ist es besser, einen offenkundigen Fehler in den
Daten zu haben (weil den irgendwann jemand reparieren wird), als
automatisch etwas hinzuraten, was dann nicht mehr auffällt, aber
falsch ist.


> Beide Varianten wären mit einer Vereinheitlichung des Relationsschemas
> auf das vom Programm unterstützte Format verbunden.
> - Umstellung auf ein stark vereinfachtes Relationsschema, bei dem nur die
> Haltepunkte, aber nicht die Stecken Elemente der Relation sind.


-1, die Routen sollten eindeutig beschrieben sein, dass wäre mit
diesem Vorschlag nicht der Fall. Man müsste mindestens noch
Zwischenpunkte (Via-Punkte, die es so nicht gibt in der Realität)
erfinden, um halbwegs verlässliche Daten zu haben, die aber trotzdem
nie ganz eindeutig sein könnten (da auch wenn sie es scheinbar jetzt
sind, der Straßengraph jederzeit erweitert werden kann) .


> Bei allen Varianten könnte man Tags für Betriebszeiten
> (operating_hours), Takt(frequency?), Fahrzeiten (duration) und wenn
> möglich eine URL des Fahrplans (url:timetable?) hinzufügen.


+1, diese neuen Tags kann man an die Linien hängen, unabhängig von
Deinen anderen Vorschlägen.


> oder
> - Verzicht auf gerichtete ÖPNV-Linien in OSM. Dann genügt eine leicht
> zu pflegende Tag-basierte Lösung um Liniennummern mit Haltestellen und
> Fahrstrecken zu verbinden.


Gerichtete Linien hat man ja nur deshalb eingeführt, weil es viele
Linien gibt, die hin- und rückwärts nicht die genau gleiche Strecke
abfahren. AFAIK sind getrennte Relationen für hin- und rück die beste
Lösung, um komplizierte Relationen zu vermeiden.

Gruß Martin