Opentransportdata.swiss

Trip forecast - Daten | Open-Data-Plattform öV Schweiz


This is a companion discussion topic for the original entry at https://opentransportdata.swiss/dataset/fahrtprognose

Liebe OTD-Experten,

bei der Nutzung von Echtzeitdaten Eurer Plattform sind mir verschiedene Fragen zu den Ankunfts- und Abfahrtsprognosen gekommen («EstimatedTime») gekommen, für deren Beantwortung ich sehr dankbar wäre.

  1. «EstimatedTime» kann man über drei verschiedene Request-Typen beziehen: TripRequest, TripInfoRequest, StopEvent. Die Struktur von Anfrage und Response sind unterschiedlich und ausführlich im «Cookbook» beschrieben. Was mich interessiert: Gibt es irgendwelche Unterschiede in der Qualität der gelieferten Werte? Sind Herkunft der Daten, Art der Berechnung und Latenzen überall gleich? D.h. kann ich mich darauf verlassen, dass wenn ich zum exakt gleichen Zeitpunkt für die gleiche Fahrt und die gleiche Haltestelle Anfragen in allen drei Request-Typen stellen würde, ich für alle drei Anfragen stets die exakt gleichen «Estimates» geliefert bekomme? Oder gibt es da Unterschiede? Welche Request-Typ wäre ggf. zu bevorzugen?

  2. In den täglichen Ist-Daten-Lieferungen sind ebenfalls «Prognosedaten» enthalten: Wie ebenfalls im Cookbook beschrieben wird, wird häufig die «letzte Prognose» als Näherung für den Ist-Wert verwendet, weil eine echte Ist-Messung oft gar nicht vorhanden ist. Was mir auffällt: die am Folgetag in den Ist-Daten gelieferten Prognose-Werte sind sekundengenau, die in Echtzeit von TripRequest / TripInfoRequest / StopEvent gelieferten Estimates jedoch stets auf Minuten gerundet. Gibt es eine Möglichkeit, auch in Echtzeit sekundengenaue Prognosewerte zu beziehen?

  3. Überall dort, wo für die «Ist-Daten» der letzte Prognosewert verwendet wird, hätte ich erwartet, dass dieser Wert (nach Rundung) identisch ist mit jenem, den ich einige Zeit nach dem Ereignis auch über TripRequest / TripInfoRequest / StopEvent beziehen kann. Nach meinen Beobachtungen ist das vielfach der Fall, aber nicht immer. In ca. 5-10% der Fälle, die ich abgeglichen habe, erhalte ich einige Minuten NACH Ankunft eines Zuges an einer Haltestelle einen «Estimate», der sich mehr als 60 Sekunden von jenem unterscheidet, welcher am Folgetag in den Ist-Daten geliefert wird. Wie kann das sein? Und welcher Wert ist korrekt?

  4. Spezialfall von 3: Ich habe etliche Fälle beobachtet, wo sich der Estimate NACH dem Ereignis noch einmal verändert. Dies bei allen drei Request-Typen, bei unterschiedlichen Betreibern (Zug und auch Bus) und an unterschiedlichen Haltestellen. Hier ein Beispiel: Fahrt der S9 Lenzburg->Luzern am 10.11.17 mit planm. Ankunft Boniswil um 11:16 (Zugnr 21943). Tatsächliche Ankunft war gemäss «Ist-Daten» um 11:17:51. Ich habe wiederholt die Prognosen über StopEvent abgefragt, der jeweilige Abfragezeitpunkt findet sich in der ersten Spalte der folgenden Tabelle:

    Bis mindestens 11:00:23 Uhr wurde eine Ankunft um 11:18 prognostiziert. Spätestens um 11:19:19 wurde diese Prognose auf 11:17 korrigiert. Das ist stimmig, denn gemäss Ist-Daten war zu diesem Abfragezeitpunkt die Ankunft bereits erfolgt und 11:17:51 ergibt abgerundet 11:17:00. Bis hierhin also alles ok. Was mich erstaunt: Ab 11:26:31 wurde dann eine «Prognose» von 11:22 geliefert – warum ändert sich die Prognose NACH dem Ereignis noch einmal? Und warum stimmt sie nicht mit den Ist-Daten überein?

  5. Für die korrekte Interpretation der Daten – und insbesondere die Einordnung solcher «Anomalien» - wäre es sehr hilfreich, mehr über den Weg der Daten vom Sensor bis zum OTD-API zu erfahren. Könntet Ihr mal skizzieren, wie das läuft? An welcher Stelle werden die «Estimates» berechnet (ich vermute, im Leitsystem des jeweiligen Betreibers?)? Wie gelangen sie von dort zur OTDP? Welche Transformationsschritte werden wo gemacht? Wo können grössere Latenzen, «lost updates» und andere «Störungen» auftreten? Wie wird ein API-Request von der OTDP verarbeitet?

Ich wäre wirklich sehr dankbar, wenn Ihr mir bei diesen Fragen weiterhelfen könntet.

Herzliche Grüsse

Andreas Gutweniger

1 Like