[Talk-de] ÖPNV-Relationen in OSM

[Christian Müller]

Am 04.04.2012 20:18, schrieb Stephan Wolff:
> Moin!
>
> Am 03.04.2012 16:23, schrieb Christian Müller:
>> Bei der Vielfalt der Linienfahrpläne "in the wild" lässt sich das
>> eigentlich auch nur lösen, wenn die kompletten Fahrpläne erfasst werden
>>
>> bus_stop: collection_times pro Linie pro Richtung
>>
>> Beispiel:
>> 1. Relation (nur Hp-Mitglieder gelistet)
>> Hp1 in der Rolle 07:00, 08:00, 09:00, 12:00, 13:00, 15:00, 18:00, 19:00
>
> Das können wir allgemein nicht erfassen und pflegen.
> Allenfalls für Fernbusse, spezielle Züge oder Fähren mit 1-3 (evtl. bis
> 5) Abfahrten pro Tag wären einzelne Abfahrtszeiten in OSM machbar.
> Ansonsten wären schon die Betriebszeiten und der Takt bzw. die Zahl der
> Fahrten pro Tag sehr hilfreich.

Alle angesprochenen Merkmale sind Aggregate aus dem zugrundeliegenden 
Fahrplan - für Linien, die keine starke Regelmäßigkeit/Struktur 
aufweisen, ist eine Aggregation nutzlos.  Damit lässt sich also auch 
keine allgemeine Empfehlung für die Erfassung solcher Werte aussprechen.

Der Takt z.B. bringt höchstens etwas für innerstädtische Linien - im 
städtischen Randgebiet ist eine Abstraktion der stark variierenden 
Linienvarianten oft nicht sinnvoll.  Ich sehe auch nicht, welchen 
Mehrwert die Zahl der Fahren pro Tag bringen soll.  Bei den 
Betriebszeiten besteht die Möglichkeit, dass für manche Linien z.B. der 
letzte Wagendurchlauf ein verkürzter ist, die Linie aber in OSM komplett 
erfasst ist.  Wer einmal den letzten Bus des Tages aufgrund schlechter 
oder falsch interpretierter Information verpasst hat, kann sich 
vorstellen, welche Verwendung die Informationsquelle zukünftig für 
sie/ihn noch findet.  Ich empfinde es daher als nutzlos, 
nicht-statische, durch Mapper selbst aggregierte Informationen von 
Fahrplänen in OSM zu taggen.  Wem es dennoch Spaß macht, go ahead..

In die Annahme, dass wir das allgemein nicht erfassen und pflegen 
_wollen_, hatte ich schon eingestimmt - "missing manpower".  Wöllten wir 
es, sollten wir uns auf den Fahrplan stürzen, alles andere bliebe so 
unzulänglich, wie die bisherige Varianten, deren Erfassung und Pflege Du 
m.E. zu recht als mühsam und unbefriedigend genau empfindest.


>> - manche Linien machen Abstecher, halten aber nicht notwendigerweise
>> zweimal, während sie den Teil des Pfades durchlaufen
>
> Aber die Abfolge der Haltepunkte wäre doch eindeutig definiert. Wie kann
> es falsche Auswertungen geben?

Indem z.B. nicht auf dem Abstecher zurückgeroutet wird, sondern vom 
Router eine andere Route  zur Folgehaltestelle errechnet wird.

4---------+
|             |
|             |
+---2----3
|
|
1

von 3 nach 4 gibt es mehrere Wege - das Unternehmen, welches den PNV 
betreibt, definiert aber i.d.R. genau eine Route, die der Fahrer nimmt.  
Das Problem ist, dass eine Routing-Engine u.U. nicht nach den gleichen 
Kriterien entscheidet, die das Unternehmen zur Routenplanung verwendet.  
Es ist sogar so, dass die Routenplanung von Unternehmen zu Unternehmen 
unterschiedlich sein wird und verwendete algorithmische Grundlagen nicht 
vorliegen.  Die Identität zum Problem der Bestimmung des kürzesten Weges 
zwischen Haltepunkten ist somit oft nicht gegeben.  Dies trifft 
vermutlich um so mehr zu, je weiter Haltepunkte auf einer Route 
voneinander entfernt liegen.  Via-Knoten können da Abhilfe schaffen, 
aber lägen die dann nicht auch auf den osm-ways die von Veränderung der 
Basisgeometrie betroffen sind?



> In der Praxis werden bei Änderungen an den Straßendaten gerade die
> streckenbasierten Busrelationen viel zu oft unterbrochen oder nicht
> auf die neuen Wege angepasst, entweder weil der Mapper die Relationen
> nicht gut genug kennt, keine Lust zur Anpassung hat oder schlicht
> Fehler macht. Das finde ich schlimmer, als evtl. mögliche Abweichungen
> von der Fahrstrecke.

+1   Ob es besser funktioniert, als die bisherige Mappingpraxis, kann 
nur ein Versuch zeigen.  Solange die Hps angefahren werden, sehe ich 
mögliche Abweichungen vom echten Streckenverlauf auf der ÖPNV-Karte auch 
nur als kosmetisches Problem.  Zumal aufgrund des angesprochenen 
Variantenproblems in den Linienverläufen ohnehin nur die am häufigsten 
verwendete Variante einer Linie in OSM landen wird.

Das beste wäre tatsächlich eine Verknüpfung mit echten Fahrplandaten der 
Verkehrsunternehmen per API.  Wenn sich da in den nächsten Jahren etwas 
öffnet, kann man evtl. auf die Erfassung von ÖPNV-Relationen in OSM ganz 
verzichten.  Ein Mashup enumeriert dann einfach die Linien über das 
angebotene API, holt sich die Haltestellen je Linie, korreliert diese 
mit den bus_stops in OSM, errechnet eine Route und rendert das ganze in 
die ÖPNV-Karte.  Vorstellbar wäre auch, dass man verschiedene Tiles 
(oder Overlay-Tiles) je nach Tageszeit generiert und ausliefert, um die 
Veränderung des Linienverlaufs tageszeitbedingt zu reflektieren.

Ohne API und bei dem momentanen Interesse der Community an ÖPNV bleiben 
wir vermutlich auf dem momentanen Niveau einer eingeschränkt 
genauen/statischen Visualisierung der Linienverläufe stehen.


>
>> -> der Pfad sollte Teil der Relation bleiben, eine Erfassung der
>> Haltepunkte reicht nicht aus
> Ich halte ein Steckenmodell aus Halte- und via-Punkten für einfacher,
> besser wartbar und robuster. Ich habe nur Zweifel, ob eine Änderung
> durchsetzbar wäre, da diverse Tools das Streckenmodell auswerten und
> dann geändert werden müssten.

Ich kenne mich bei den routing engine interna nicht so aus, aber es 
wurde berichtet, dass psv tags selten ausgewertet werden.  Das macht es 
schwer, für Programmier etwa der ÖPNV-Karte auf eine Generierung der 
Routen umzusteigen (statt sie aus der Relation zu lesen).


Gruß
Christian