FAQ

Die Begriffe werden oft in unterschiedlichen Kombinationen analog verwendet. Bei Echtzeitdaten handelt es sich um Daten, die adhoc erstellt und übermittelt werden. Dabei kann es sich um Plan-, Prognose- und/oder Ist-Daten handeln.

Mit Prognosedaten sind die Daten gemeint, die aufgrund der aktuellen Situation berechnet werden, z.B. Ankunfts- und Abfahrtszeit an der nächsten Haltestelle.

Die Ist-Daten umfassen die Information, wann und wo effektiv verkehrt wurde. I.d.R. liegen diese Daten erst im Nachhinein, selten in Echtzeit vor.

Mit der Funktion „Journey Planner“ ist eine Verbindungssuche zwischen zwei Haltestellen gemeint. Diese beiden Haltestellen müssen nicht zwingend in einer Fahrt/Linie liegen, d.h. es kann auch Umsteigevorgänge beinhalten. Synonyme sind „Wegsuche“ und „Routing“.

Einen solchen Service bietet opentransportdata.swiss nicht. Allerdings bietet es die Datengrundlage mit den Fahrplan-Datensätzen, um einen Journey Planner selbst zu entwickeln. Mit der Einbindung einer der beiden Fahrtprognose-API bietet opentransportdata.swiss die Möglichkeit den Journey Planner mit Echtzeitinformation zu ergänzen.

Die CSV-Dateien sind als UTF-8 codiert.  Dies kann beim „regulären“ Öffnen von CSV-Dateien im Excel Probleme bieten, weil Excel von einem anderen Zeichensatz ausgeht.

Hier hilft folgende Vorgehensweise: Leere Tabelle in Excel anlegen und dann im Menü Daten / Externe Daten abrufen / Aus Text wählen. Nach Auswahl der Datei kann dann im nächsten Dialogschritt unter Dateiursprung „Unicode (UTF-8)“ eingegeben werden.

Es wird ein Status 429 zurückgeliefert.

Die Antwort des Services lautet dann :

Weitere Infos dazu finden Sie hier: https://opentransportdata.swiss/de/datenlimit-und-verrechnung/

Die Grenzen beziehen sich auf die folgenden APIs:

• Stop request
• Trip Request
• Trip Info Request

Es stimmt, dass die GTFS Reuqests auf 2 / min begrenzt sind. Es ist nicht notwendig, weitere Anfragen zu senden, da die Daten nicht häufiger aktualisiert werden.

Die Abkürzungen werden nach Verfügbarkeit vergeben. Die aktuellen Regeln dazu lauten:

–           Die Abkürzung beginnt mit demselben Buchstaben wie der Name

–           Maximale Länge vier Zeichen.

–           In der Regel werden keine Zahlen benutzt.

Allfällige Ausfälle würden unter http://status.opentransportdata.swiss/ protokolliert.

Die Open-Data-Plattform öV Schweiz bietet verschiedene API an.

Für den Zugriff auf diese API ist ein API-Key notwendig. Dieser Token kann über das Developer Portal bezogen werden. Dazu registrieren Sie sich bitte auf der open-Data-Plattform öV Schweiz.

Das Token muss im HTTP Header als “Authorization” für jede Anfrage mitgeschickt werden. Die Verwendung unterliegt gewissen Limiten.

Das Developer Portal erlaubt:

• Erstellen von API-Schlüsseln
• Löschen von API-Schlüsseln
• Beobachten, wie viel des Kontingents durch den Schlüssel verbraucht ist.

Welche Verkehrsmittel an diesen Dienststellen anhalten müssten Sie aus dem Fahrplan ableiten. Der Fahrplan umfasst alle Informationen, um sich im öffentlichen Verkehr der Schweiz zurecht zu finden. Der Fahrplan enthält einerseits sämtliche Grundinformationen (Haltestellen, Linien, Topologie etc.) und andererseits alle zeitlich relevanten Informationen (Kalender, Fahr- und Haltezeiten etc.), so dass jegliche Form einer Fahrplanauskunft (zu einer Haltestelle, aber auch eine Wegsuche/Routing/Journey planner) anhand dieser Daten erstellt werden können. Die bereitgestellten Fahrplaninformationen (HRDF und GTFS) sind für die Kundeninformation optimiert.

Allgemeine Infos: https://opentransportdata.swiss/de/cookbook/infoplus/

HRDF

Daten: https://opentransportdata.swiss/de/dataset/timetable-2018-hrdf

Beschreibung: https://opentransportdata.swiss/de/cookbook/hafas-rohdaten-format-hrdf/

GTFS

Daten: https://opentransportdata.swiss/de/dataset/timetable-2018-gtfs

Beschreibung: https://opentransportdata.swiss/de/cookbook/gtfs/

Die Trip ID setzt sich aus unterschiedlichen DIVA-Nummern/Feldern zusammen und hat nichts mit den HRDF-Daten zu tun. (Was ist die GTFS ID? Sagt mir nichts…) 

Hätte der Datennutzer die passenden HRDF-Daten mit den dazugehörigen GTFS-Daten verglichen, hätte er die Übereinstimmung vielleicht selbst gefunden. So konnte das aber nicht klappen, weil die beiden Datensätze nicht zusammenpassen. Hat mich einige Zeit gekostet herauszufinden, dass er Äpfel mit Birnen vergleicht. 😉

Die Zuordnung ist nicht ganz 1:1, da die Fahrt ID (= Fahrtnummer) nicht unique sein muss innerhalb eines HRDF-Datensatzes, aber unter Zuhilfenahme von Haltestellen und Haltezeiten, wie der Datennutzer das gemacht hat, lässt sich die passende Fahrt wie folgt finden:

In der trips.txt steht der trip_short_name:

route_id,service_id,trip_id,trip_headsign,trip_short_name,direction_id

„26-94-j18-1″,“TA+b20xg“,“310.TA.26-94-j18-1.3.R“,“Zürich Oerlikon, Bahnhof“,“13628„,“1“

Dieser entspricht der Fahrtnummer (externe Zugnummer) in der *Z-Zeile der FPLAN-Datei:

Da die Fahrtnummer wie erwähnt nicht unique sein muss innerhalb eines HRDF-Feeds, sollte man zusätzlich die Haltezeiten und stop_ids der Fahrt aus der stop_times.txt zur Zuordnung mit heranziehen:

trip_id,arrival_time,departure_time,stop_id,stop_sequence,pickup_type,drop_off_type

„310.TA.26-94-j18-1.3.R“,“13:37:00″,“13:37:00″,“8587651″,“1″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:38:00″,“13:38:00″,“8587652″,“2″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:39:00″,“13:39:00″,“8591263″,“3″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:41:00″,“13:41:00″,“8591347″,“4″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:42:00″,“13:42:00″,“8591047″,“5″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:43:00″,“13:43:00″,“8591113″,“6″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:44:00″,“13:44:00″,“8591330″,“7″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:45:00″,“13:45:00″,“8591319″,“8″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:46:00″,“13:46:00″,“8591175″,“9″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:46:00″,“13:46:00″,“8591273″,“10″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:48:00″,“13:48:00″,“8591382″,“11″,“0″,“0″

„310.TA.26-94-j18-1.3.R“,“13:49:00″,„13:49:00″,“8580449“,“12″,“0″,“0″

 Es passt immer der zwei Tage jüngere HRDF-Feed (z. B. 05.02.2018) zum GTFS-Feed (z. B. 07.02.2018):

Die drei Arten der Zusatzinformation sind:

• Trip Updates
• Service Alerts
• Vehicle Positions

Trip Updates

Bsp: „Bus 18 hat aktuell 10 Minuten Verspätung“

Hier werden Verspätungen, geänderte Routen, Ersatzfahrzeuge oder Ausfälle für einzelne Linien laufend publiziert, um den Fahrgästen eine möglichst exakte Planung zu ermöglichen.

Service Alerts

Bsp: „Station Bern Weissenbühl ist aufgrund eines Unfalls aktuell geschlossen“

Im Falle von Verschiebung der Haltekante oder allgemein unvorhergesehene Ereignissen, die eine Haltestelle, eine Route oder das gesamte Netzwerk beeinflussen, können kurze Meldungen publiziert werden um die Fahrgäste auf dem Laufenden zu halten und zu erklären, was der Grund für die Änderung ist.

Service Alerts stehen auf der Plattform nicht zur Verfügung.

Vehicle Positions

Bsp: „Dieser Bus befindet sich um 18h23 an der Haltestelle Bern Bahnhof“

Hier können Informationen zum Standort von einzelnen Transit-Fahrzeugen publiziert werden. Zusätzlich können auch die aktuelle Auslastung des Fahrzeugs, der Fahrzeugtyp oder andere, ähnliche Informationen bereitgestellt werden.

Die Vehicle Positions stehen auf der Plattform nicht zur Verfügung.

Die TFS Daten basieren auf den HRDF Daten. Die HRDF-Datei beinhaltet nur den öV-Schweiz. Internationale Züge werden (meist) am ersten kommerziellen Halt im Ausland terminiert. In Wirklichkeit fahren sie natürlich weiter. In einigen Fällen endet die internationale Fahrt bei der letzten Haltestelle in der Schweiz (z.B. Genf) oder enthält noch 1-2 Haltestellen /Betriebspunkte im Ausland.

Die öV-Schweiz-Datei beinhaltet zusätzlich das Streckennetz der SBB GmbH in Deutschland. Dies hat letztendlich historische Gründe.

Das Thema Halt auf Verlangen ist ein komplexes. Weil die ist betrieblich und kommerziell nicht gleich. Stephan Bundi spricht vom kommerziellen Teil. Das ist ein Attribut das dem Kundenfahrplan hinzugefügt wird. INFO+ ist ein kommerziell orientiertes Produkt. Betrieblich gibt es kein ‚vielleicht‘ anhalten. Entweder Halten oder Durchfahren, man muss die Fahrwege planen können. In der Regel wird ein Halt auf Verlangen wie ein normaler Halt einberechnet. Fährt der Zug dann durch, kann er an einem Bahnhof oder Signal warten. Anders herum kann er nicht einfach schneller fahren. Also wird mit dem Halt geplant.

 Hier der Normalfall, z.B. 13.2. oder am Beispiel 18549:

Hier die BLS (bitte bei Rückfragen im Schienennetz immer Zugnummern erwähnen, nicht Linien): Beispiel 15732 Ziegelbrücke

• Man erkennt den Halt auf Verlangen daran dass ZBR dieselbe Ankunft wie Abfahrt hat in der KOMMERZIELLEN Zeit (erste Spalte). Sonst sieht man das den Zeiten nicht an.
• In der BETRIEBLICHEN Planung (zweite Spalte) ist der Halt ganz normal geplant wie der in MEP (Marin) auch. Es gibt kein ‚vielleicht‘
• Dass der Zug nur vielleicht anhält, sieht man (und der LF) am Haltecode, der ist 14 statt 11 wie sonst (im Dienstfahrplan)
• Ob der Zug wirklich angehalten hat oder durchgefahren ist, sieht man an der DIFFERENZ zwischen der ABWEICHUNG (gemessene Zeit), die hier 22 Sekunden Verspätung ist und dann auf einmal 36 Sekunden Vorzeitig. Das heisst der Zug ist dort durchgefahren. Es gibt kein Flag dafür das man einfach abfragen kann!
• Um es noch komplizierter zu machen: Der Zug ist in MEP (Marin) nicht etwa 49 Sekunden zu früh abgefahren. Die Grafik oben zeigt die PROGNOSE. Es gibt dann das Ganze noch einmal mit den IST Werten. Dort wartet der Zug in Marin die geplante Abfahrt ab.

Hier geht es um die (geänderten) Streckenverläufe der Ersatzzüge. Streckenverläufe können in die Datei shapes.txt (https://developers.google.com/transit/gtfs/reference/#shapestxt) exportiert werden.

ABER: Wir verwenden als GIS OpenStreetMap. Diese Daten dürfen wir wegen Copyrightbeschränkungen nicht bei Google hochladen, daher ist der Export der Datei bei uns deaktiviert. Da die Daten auch von Google verwendet werden ist eine Aktivierung leider nicht möglich.

Im HRDF bilden die folgenden Felder einer Fahrt einen eindeutigen Schlüssel:

•„Fahrtnummer“

•„Verwaltung“

•„Variante“

 Diese findet sich in der „*Z-Zeile“ der Datei „FPLAN“.

Im GTFS (und GTFS-RT) ist dies die „Trip_ID“ in der Datei „trips.txt“. Die Routen (in „routes.txt“) und trips werden automatisch nummeriert. D.h. sie sind auch zwischen GTFS-Versionen nicht stabil.

Wenn der eigentliche Fahrplan aus HRDF stammen soll und ihre Algorithmen darauf ausgelegt sind, so müssen sie dennoch das GTFS Static in ihre Datenbank importieren und ein Matching erzeugen.

Wie du dazu am besten vorgehst entnimmst du dieser Cookbook Seite:

https://opentransportdata.swiss/de/cookbook/verwendung-von-hrdf-fahrplaenen-zusammen-mit-gtfs-rt/

Das route_short_name-Thema können wir aufgrund der Datenmodellierung nicht ohne weiteres lösen (imaginäre Liniennummern erhalten das Y als Suffix, damit sie als solche erkennbar sind).

Wir haben uns aber Gedanken gemacht, ob es nicht ein anderes Datenfeld gäbe, welches wir verwenden könnten:

Wir könnten die Namen der Verkehrsmitteltexte, die wir seit neuestem in die route_description schreiben, auch in den route_long_name (oder route_short_name) exportieren. Wenn es diesbezüglich Änderungen gibt erfahren Sie es in den Releasenotes.

Aktuell wird die Formation leider nicht „open“ zur Verfügung gestellt. Die Freigabe dieser Daten ist aktuell nicht geplant. Falls sich dies ändern sollte, erfahren Sie als registrierter Plattformnutzer per Mail als Erster davon. Eine weitere Möglichkeit, immer auf dem Laufenden zu sein, ist unseren Twitterfeed zu abonnieren.

Die Formation der SBB finden Sie hier: data.sbb.ch

Eigentlich lassen sich solche Fälle sehr gut nachvollziehen, wenn man die nötigen Informationen hat. Bitte stellt uns mit dem Kontaktformular folgende Infos zu:

• Anfragezeitpunkt GTFSR
• Antwort GTFSR
• Anfragezeitpung VDV 431
• Anfrage VDV 431
• Antwort VDV 431
• VDV 454 AUS Meldung

Nein, das ist nicht der Fall. Entweder eine Fahrt Echtzeit und es werden auch alle Verspätungen ausgegeben oder Sie hat keine Echtzeit. Delay 0 bedeutet Echtzeit und pünktlich. Entweder haben wir keine Verspätung in VDV 454 AUS erhalten, oder wir konnten die Meldung mit der Prognose nicht verarbeiten.

Bis ins Detail können wir hier nicht gehen, da sich dies auch je nach TU unterscheidet. Im unten stehenden Big Picture werden die groben Gesamtzusammenhänge von den Datenquellen bis zu der Veröffentlichung der Informationen/Daten aufgezeigt:

Die Komplexität und Variabilität bei den Transportunternehmen (TU) wird auf dem Big Picture nicht dargestellt. Es bestehen aber sehr viele Lösungen und unterschiedlichen Ausprägungen, so verwendet ein TU ein Excel, während ein anderes TU ein voll integriertes System für sämtliche Schichten verwendet.

Grundsätzlich kann man aber drei Schichten bei den Transportunternehmen unterscheiden:

1.Haltestellen: Stellen das Fundament des öffentlichen Verkehrs dar und werden deshalb schweizweit durch das nationale System DiDok identifiziert und verwaltet.

2.Fahrplansystem: Jedes Transportunternehmen erstellt die Fahrpläne, die dem Kunden kommuniziert werden sollen. Einerseits wird das TU selbst die Fahrpläne publizieren (z.B. als Aushang an der Haltestelle), andererseits müssen die Fahrplandaten in einen grösseren Pool eingebracht werden.

3.Mit dem (Betriebs-)Leitsystem wird die Adhoc-Disposition vorgenommen, d.h. die Veränderungen gegenüber der ursprünglichen Planung werden entweder aufgezeichnet (z.B. Verspätungen) oder aktiv vorgenommen (z.B. Umleitungen). Diese Schicht beinhaltet aber auch ganz einfache Systeme (z.B. ein Handy), die lediglich die aktuelle Position aufzeichnet und die Prognose rechnet.

Fakt ist, es gibt zahlreiche Systeme bei den zahlreichen Transportunternehmen, die in der Verarbeitung, wie aber auch in der Bereitstellung von Daten sich unterschiedlich verhalten können. Diese Heterogenität wird in Zwischenschritten relativiert und vereinheitlicht.

Zwischenschritte

Bevor die Daten publiziert werden, werden diese gesammelt. Dazu werden die Daten in einem ersten Schritt in einem regionaler Datensammler oder einer regionaler Datendrehscheibe zusammengeführt. Auch hier wurde das Big Picture vereinfacht, denn die regionalen Systeme können voll integrierte Systeme (z.B. Verbundsysteme), Systeme von einem national operierenden Unternehmen (z.B. Postauto) oder eine Drehscheibe die überregional sammelt (z.B. Bernmobil) beinhalten. Auch hier gibt es mehr als ein System pro Schicht (Ausnahme: Haltestellen), jedoch nicht so viele wie bei den Quellsystemen.

Früher oder später landen die Daten aber in den drei nationalen Systemen DiDok (Haltestellen), INFO+ (Fahrplan) oder CUS (Echtzeit). Aktuell kann man nur bei DiDok und INFO+ davon ausgehen, dass sämtliche TU der Schweiz die entsprechenden Daten eingeliefert haben. Bei CUS liefern aktuell nur eine Auswahl der TU Echtzeitdaten ein. Dies hat zwei Gründe:

1.Nicht jedes TU verfügt über ein (Betriebs-)Leitsystem.

2.Nicht jedes TU, das über ein (Betriebs-)Leitsystem verfügt, bzw. nicht jede Datendrehscheibe, stellt Daten im gewünschten Format bereit.

Ziel ist es aber, dass mit der Zeit möglichst sämtliche TU der Schweiz Echtzeit liefern werden.

Publikation

Aus den nationalen Sammelsystemen werden die Daten in zwei Publikationssysteme überführt:

1.Kubus: Kubus bereitet die Daten so auf, dass sie auf fahrplanentwurf.ch (der Jahresfahrplan zur Prüfung bevor er gültig ist) und auf fahrplanfelder.ch (der gültige Jahresfahrplan) sauber publiziert werden können.

2.Open-Data-Plattform: Hier gibt es zwar auch ein vorgelagertes System (analog Kubus), das die Daten aufbereitet und zusammenführt, allerdings ist es voll integriert, so dass alle Daten konsolidiert auf opentransportdata.swiss publiziert werden können. Die Plattform bringt ausserdem die Daten aus den unterschiedlichen Schichten der nationalen Systeme zusammen, so dass der Output entsprechend integriert ist.

Bisher wurde die Verbindungslogik von  transport.opendata.ch bereitgestellt. Dieser Dienst wurde jedoch am 31. 07.2018 abgestellt.

Um den Zugang weiterhin sicherzustellen, den eine grosse und wachsende Zahl innovativer Projekte benötigen, stellt search.ch neu ihr eigenes Backend zur Verfügung, das dank der neuen Echtzeitdaten von opentransportdata.swiss ebenfalls minutengenaue Fahrplanabfragen und Streckenberechnungen leisten kann.

Dadurch ändert sich für Nutzerinnen und Nutzer von transport.opendata.ch so wenig wie absolut möglich, die Schnittstelle ist weitgehend identisch, proprietäre Angaben der SBB wie etwa der Auslastungsindikator sind aber nicht mehr in den Daten enthalten.

Die neue Umsetzung kann ab sofort unter transport-beta.opendata.ch getestet werden, die Umstellung auf die neue Lösung erfolgte am 31.Juli 2017.

Der Dienst wird von search.ch und Opendata.ch als “best-effort” Leistung angeboten, ohne Garantien für die Verfügbarkeit oder die Qualität der Daten und Berechnungen. Je nach Anwendungsfall, einet sich auch die Viadi API: https://viadi-api.ch/

Die trip_id besteht aus den folgenden Teilen: „<fortlaufende Nummer in der trips.txt>.<service_id>.<route_id>.<DIVA Fahrwegsnummer>.<DIVA Fahrtrichtung>“

route_id = <DIVA Betriebszweig>-<DIVA Liniennummer>-<DIVA Projektkurzbezeichnung>-<DIVA Linienversionsnummer>

Ist die Reise, von der Sie sprechen, in der statischen Datei oder nur in GTFSR verschwunden?

Denn wenn ein Trip in der statischen Datei fehlt, ist es normal, dass Sie ihn nicht in der GTFSR-Datei finden können.

Echtzeitmeldungen ohne „stop_time_updates“ sind Auslösungen ohne Echtzeit. Das haben wir geändert. Fahrten ohne Echtzeit werden nicht mehr übertragen.

Wie viele: Aktuell immer so viele wie Sie in der GTFSR-Antwort erhalten.
Folgende Transportunternehmen liefern Echtzeitdaten: https://opentransportdata.swiss/de/dataset/go-realtime

Das ist richtig. Dies ist die Art und Weise, wie Trackänderungen in GTFSR angezeigt werden. Wir haben dies mit dem letzten Release implementiert. GTFS 8507483: 0: 4 und GTFSR 8507483: 0: 3 „bedeutet, dass der geplante Track 4 ist, aber der aktuelle Track aufgrund von Änderungen nun 3 ist. Wir empfehle Ihnen, nur auf der Ebene der Haltestellen zu kartographieren.

Nein wir können diese Daten nicht auf Gemeindeebene veröffentlichen, da wir die Zuordnung auf die Gemeinde nicht kennen. Wir haben diese Liste aufgrund der Adresse des Kunden gemacht und dort gibt er seine Gemeinde nicht an.
Sie können dies jedoch analog SRF machen:
Die Informationen zur interaktiven Karte und den Werten im Artikel stammen aus dem Datensatz des Direkten Verkehrs Schweiz (opentransportdata.swiss) zur Verbreitung von GA und Halbtax zwischen 2012-2016. Der Fokus der vorliegenden Analyse bezieht sich auf die Daten von 2016 (Datenauszug KW 51, 2016). In einem ersten Schritt erfolgte die Zuordnung zu den zu diesem Zeitpunkt gültigen Daten der ständigen Wohnbevölkerung anhand der Postleitzahl (31.12.2015). Für den anschliessenden Abgleich zwischen Postleitzahl und Gemeinde wurde die vom BFS publizierte GWR-Korrespondenztabelle (Stand 01.01.2017) verwendet. Damit konnte ein direkter Bezug zu den durch das BFS publizierten, generalisierten Gemeindegrenzen mit Stand 1.1.2017 sowie der Raumgliederung der Schweiz hergestellt werden. Aufgrund einer Mittelung der Daten bei Postleitzahlen mit weniger als 20 Abonnements kann es bei der Karte insbesondere bei kleinen Gemeinden zu leichten Verzerrungen kommen.
Details dazu https://srfdata.github.io/2017-09-sbb-ga-halbtax/#sbb__bfs_raumgliederungen
lante Track 4 ist, aber der aktuelle Track aufgrund von Änderungen nun 3 ist. Wir empfehle Ihnen, nur auf der Ebene der Haltestellen zu kartographieren.

Alle Request Typen haben dieselbe Datenquelle. Es ist daher keiner der Request Typen zu bevorzugen. Bitte wählen Sie einfach den Request, welcher sich für Ihre Anwendung am besten eignet.

Eine Übersicht finden Sie hier:
https://opentransportdata.swiss/de/dataset/go-realtime
Die Liste enthält alle Transportunternehmen/Geschäftsorganisationen, für die Echtzeit vorliegt.