GTFS

Kurzbeschreibung

General Transit Feed Specification (GTFS) ist ein von Google initiiertes, digitales Austauschformat für Fahrpläne des öffentlichen Personenverkehrs und dazugehörige geografische Informationen, wie z.B. Standorte von Haltestellen. Inzwischen wird es durch die Organisation MobiliyData (https://mobilitydata.org/) weiterentwickelt. Es gibt verschiedene Ausprägungen von GTFS – für unseren Datensatz mit den Fahrplänen verwenden wir GTFS Static (GTFS-S; auch bekannt unter GTFS Schedule).

In einer GTFS-Static-Datei ist der gesamte öffentliche Verkehr der Schweiz eines Fahrplanjahrs des öffentlichen Verkehrs (365 Tage ab Mitte Dezember) enthalten. Im Gegensatz zu GTFS Realtime (GTFS-RT) liefert GTFS Static nur statische Daten und keine Echtzeitdaten. (Fahrplanjahr auf öv-info.ch)

Fachliche Beschreibung

GTFS Static wird mittels einer Reihe von Text-Files im ZIP-Format bereitgestellt. Die enthaltenen Informationen werden aus der zugrundeliegenden HDRF-Datei (https://opentransportdata.swiss/cookbook/timetable-cookbook/hafas-rohdaten-format-hrdf/) generiert. GTFS kann die meisten, aber nicht alle Informationen aus HRDF darstellen. Diese Informationen werden durch die einzelnen Transportunternehmen eingeliefert. Jedes File gibt Informationen zu einem bestimmten Aspekt der Transit-Informationen wie beispielsweise Haltestellen (stops.txt), Linien (routes.txt), Fahrten (trips.txt), Transportunternehmen (agency.txt) und weiteren fahrplanrelevanten Daten. Einige Angaben sind notwendig, um valide GTFS-Daten bereitzustellen, andere sind optional und liefern nützliche Zusatzinformationen (wie z.B. Änderungen des Fahrplans an spezifischen Feiertagen = calendar_dates.txt).

Aufgrund der weiten Verbreitung des Formats gibt es auf GitHub zahlreiche Tools zum Umgang mit GTFS-Daten, welche MobilityData gesammelt hat, bekannt als awesome-transit. Zudem stellt opentransportdata.swiss für die Schweizer Daten spezifische Tools bereit auf Tools-and-more (im Abschnitt “Für den Umgang mit GTFS-Fahrplan- und -Echtzeit-Daten”).

Die folgende Grafik zeigt, wie die verschiedenen in GTFS enthaltenen Dateien zusammenhängen, wobei zurzeit nicht alle für den öV Schweiz erfasst sind:

Nebst GTFS-S werden auf opentransportdata.swiss folgende GTFS-Formate zur Verfügung gestellt:

• GTFS Realtime (GTFS-RT) mit Echtzeitdaten (z.B. Verspätungen)
• GTFS-Realtime Service Alerts (GTFS-SA) mit Ereignisdaten (z.B. Sperrung einer Haltestelle aufgrund eines Unfalls)
• GTFS-Flex für On-Demand-Verkehre (Erweiterung von GTFS-S)

Technische Beschreibung

Struktur der Daten

Jede Datei besteht aus kommagetrennten Text- und Zahlenreihen mit Feldern, welche zusammengesetzt die gesuchten Informationen liefern. Die erste Zeile enthält jeweils die Spaltennamen, wie bei CSV-Dateien üblich. Die einzelnen Felder in den verschiedenen Dateien werden auf der offiziellen Webseite des GTFS-Standards ausführlich erläutert: https://gtfs.org/documentation/schedule/reference/

In unserem Datensatz werden zurzeit die folgenden Dateien bereitgestellt:

• agency.txt
• calendar.txt
• calendar_dates.txt
• feed_info.txt
• routes.txt
• stop_times.txt
• stops.txt
• transfers.txt
• trips.txt

Untenstehend wird eine zusammenfassende Übersicht über die einzelnen Dateien gegeben, weitere Details stehen im Schweizer GTFS-Profil.

agency.txt

Die Datei agency.txt listet alle Transportunternehmen auf, die im Datensatz vorhanden sind. Aus technischen Gründen wird hier immer auf die gleiche URL und Telefonnummer verwiesen, welche jedoch nur für das Transportunernehmen SBB gelten.

Beispiel:

agency_id,agency_name,agency_url,agency_timezone,agency_lang,agency_phone
"11","Schweizerische Bundesbahnen SBB","http://www.sbb.ch/","Europe/Berlin","DE","0848 44 66 88"
"65","THURBO","http://www.sbb.ch/","Europe/Berlin","DE","0848 44 66 88"
"823","Basler Verkehrsbetriebe","http://www.sbb.ch/","Europe/Berlin","DE","0848 44 66 88"
"37","Baselland Transport","http://www.sbb.ch/","Europe/Berlin","DE","0848 44 66 88"
"827","Städtische Verkehrsbetriebe Bern","http://www.sbb.ch/","Europe/Berlin","DE","0848 44 66 88"
"78","Sihltal-Zürich-Uetliberg-Bahn","http://www.sbb.ch/","Europe/Berlin","DE","0848 44 66 88"
"88","Regionalverkehr Bern-Solothurn","http://www.sbb.ch/","Europe/Berlin","DE","0848 44 66 88"

calendar.txt

Die Datei calendar.txt definiert für jede “service_id” die Wochentage, an denen diese “service_id” normalerweise verkehrt (z.B. Mo-Fr). start_date und end_date entsprechen der gesamten Fahrplanperiode vom einen bis zum nächsten Fahrplanwechsel (Dezember bis Dezember). “1” bedeutet, dass die service_id am entsprechenden Tag verkehrt, 0 bedeutet, dass sie nicht verkehrt.

Eine “service_id” gibt in der Datei “trips.txt” zusammen mit einer “route_id” an, an welchen Tagen eine bestimmte Fahrt verkehrt.

Beispiel:

service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date
"TA","1","1","1","1","1","1","1","20251214","20261212"
"TA+00000","1","1","1","1","1","1","1","20251214","20261212"
"TA+00100","1","1","1","1","1","0","0","20251214","20261212"
"TA+01000","0","0","0","0","0","0","1","20251214","20261212"
"TA+01100","0","0","1","0","1","0","0","20251214","20261212"
"TA+02000","1","1","1","1","1","0","0","20251214","20261212"
"TA+02100","0","0","0","0","1","0","0","20251214","20261212"

calendar_dates.txt

Die Datei calendar_dates.txt definiert die Abweichungen/Ausnahmen vom wöchentlichen Muster gemäss calendar.txt. Häufig sind dies Feiertage, es kann aber auch andere Gründe haben wie z.B. geplante Baustellen oder Grossanlässe.

service_id,date,exception_type
"TA+00000","20260213","2"
"TA+00000","20260214","2"
"TA+00000","20260215","2"
"TA+00000","20260216","2"
"TA+00000","20260217","2"
"TA+00000","20260218","2"

feed_info.txt

Die Datei feed_info.txt enthält Metadaten über den Datensatz. Die Spalte “feed_version” gibt die Version des GTFS-Datasets an, welche von den GTFS-Realtime-Feeds referenziert werden kann.

Beispiel:

feed_publisher_name,feed_publisher_url,feed_lang,feed_start_date,feed_end_date,feed_version
"SBB","http://www.sbb.ch/","DE","20251214","20261212","20250529"

routes.txt

Die Datei routes.txt enthält die Informationen über die Linien.

Die Spalte route_id ist folgendermassen aufgebaut: <Betriebszweig>-<Liniennummer>-<Projektkurzbezeichnung>-<Linienversionsnummer>, oft enthält die Liniennummer noch eine Erweiterung mit einem zusätzlichen Bindestrich wie z.B. “-Y”. Der Inhalt der einzelnen Teile der route_id ist jedoch grösstenteils spezifisch für das System, welches die GTFS-Daten generiert und nicht zur Anzeige für Reisende geeignet. Die für die Reisenden relevanten Linenbezeichnungen sind in der Spalte route_short_name enthalten.

Beispiel (S-Bahn-Linien “S10” von verschiedenen Betreibern in Zeilen 2-4):

route_id,agency_id,route_short_name,route_long_name,route_desc,route_type
"91-10-A-j26-1","78","S10","","S","109"
"91-10-B-j26-1","11","S10","","S","109"
"91-10-C-j26-1","65","S10","","S","109"
"91-29-j26-1","11","S29","","S","109"
"91-29-Y-j26-1","11","IC","","IC","102"
"91-46-j26-1","82","IR46","","IR","103"
"91-48-j26-1","11","RE48","","RE","106"

Die Spalten route_desc und route_type enthalten Verkehrsmittel gemäss untenstehender Tabelle. Unser Datensatz benutzt Werte aus dieser weit verbreiteten Liste von route_type in Abweichung von der Liste gemäss Standard (welcher nur zehn Werte für route_type kennt):

stop_times.txt

Die Datei stop_times.txt definiert die Ankunfts- und Abfahrtszeiten an allen Haltestellen für jede einzelne Fahrt; es ist mit Abstand die grösste Datei einer GTFS-S-Lieferung.

Beispiel (eine komplette Fahrt, von Zürich Triemli nach Zürich HB):

trip_id,arrival_time,departure_time,stop_id,stop_sequence,pickup_type,drop_off_type
"1.TA.91-10-A-j26-1.1.H","18:27:00","18:27:00","8503054:0:1","1","0","0"
"1.TA.91-10-A-j26-1.1.H","18:28:00","18:28:00","8503053:0:1","2","0","0"
"1.TA.91-10-A-j26-1.1.H","18:29:00","18:29:00","8503052:0:1","3","0","0"
"1.TA.91-10-A-j26-1.1.H","18:32:00","18:32:00","8503051:0:1","4","0","0"
"1.TA.91-10-A-j26-1.1.H","18:35:00","18:35:00","8503090:0:1","5","0","0"
"1.TA.91-10-A-j26-1.1.H","18:37:00","18:37:00","8503000:0:22","6","0","0"

stops.txt

Die Datei stops.txt enthält alle Haltestellen sowie – falls vorhanden – die genaue Haltekante oder das Gleis mit allfälligen Sektorangaben. Seit Juni 2025 wird zusätzlich die Spalte “platform_code” ausgegeben. Sie enthält das jeweilige Gleis bzw. die Haltekante von Bus oder Tram.

Beispiel:

stop_id,stop_name,stop_lat,stop_lon,location_type,parent_station,platform_code
"1100723","Inzlingen, Zoll","47.58557417","7.67283424","","Parent1100723",""
"1200730:0:A","Feldkirch, Bahnhof","47.24149699","9.60366412","","Parent1200730","A"
"8505094:0:A/B","Schwyz, Bahnhof","47.02680850","8.63213614","","Parent8505094","A/B"
"8507000:0:49","Bern","46.94822398","7.43333440","","Parent8507000","49"
"8509068:0:2CD","Klosters Platz","46.86921071","9.88093812","","Parent8509068","2CD"

transfers.txt

Die Datei transfers.txt definiert Regeln für Umstiege. Üblicherweise sind die betreffenden Haltestellen (from_stop_id und to_stop_id) sowie die für den Umstieg benötige Zeit (min_transfer_time) mit dem transfer_type=2 (“normaler” Umstieg mit minimalem Zeitbedarf gemäss min_transfer_time) angegeben.

Seit Juni 2025 wird bei allen Durchbindungen, welche Flügelungen sind, transfer_type=4 gesetzt. transfer_type = 4 bedeutet gemäss GTFS-Standard, dass die Reisenden nicht umsteigen müssen. Dies trifft z.B. zu bei gekoppelten Zügen, die sich aufteilen (Flügelung) und damit die trip_id wechseln, Reisende jedoch sitzenbleiben können; dies kann mit einem entsprechenden Symbol gekennzeichnet werden.

Beispiel:

from_stop_id,to_stop_id,from_route_id,to_route_id,from_trip_id,to_trip_id,transfer_type,min_transfer_time
"8501120:0:1","8501120:0:3","","","","","2","300"
"8501120:0:1","8501120:0:4","","","","","2","300"
"8501120:0:1","8501120:0:4A-D","","","","","2","300"
"8501120:0:1","8501120:0:4E-G","","","","","2","300"
"8507483:0:3","8507483:0:3","91-1-N-j26-1","91-1-N-j26-1","72.TA.91-1-N-j26-1.22.R","91.TA.91-1-N-j26-1.34.R","4",""
"8507483:0:3","8507483:0:3","91-1-N-j26-1","91-1-N-j26-1","72.TA.91-1-N-j26-1.22.R","100.TA.91-1-N-j26-1.36.R","4",""
"8507483:0:3","8507483:0:3","91-1-N-j26-1","91-11-N-j26-1","72.TA.91-1-N-j26-1.22.R","24.TA.91-11-N-j26-1.7.R","4",""

trips.txt

Die Datei trips.txt enthält die einzelnen Fahrten der in routes.txt definierten Linien. 

• Für Züge beinhaltet “trip_short_name” die Zugnummer.
• Ein “trip” gemäss GTFS repräsentiert in Transmodel (https://en.wikipedia.org/wiki/Transmodel) den Begriff einer “DatedVehicleJourney” (in OJP eine “DatedJourney”). In Transmodel und OJP ist ein Trip eine Reise des Kunden, wie sie vom Trip Planner zurückgegeben wird. Sie besteht aus verschiedenen Teilfahrten, Umsteigen und anderen Wegen, die mit verschiedenen Modi zurückgelegt werden müssen. In HRDF entspricht das “trip” von GTFS der “Fahrt” und in NeTEx der “ServiceJourney”.
• Die Schweizer Implementation nutzt die original_trip_id, wie sie für GTFS Transit definiert ist (https://developers.google.com/transit/gtfs/reference). Das Feld enthält die Swiss Journey ID (SJYID), die eine N:1-Beziehung zwischen trip_id und SJYID herstellt. Die SJYID ist nur auf Tagesbasis eindeutig. Sie wird auch in GTFS-RT benutzt.
• Das Feld “hints” enthält die Verkehrshinweise gemäss Branchenstandard Kundeninformation (https://www.oev-info.ch/de/branchenstandard/uebersicht). Die Tarifcodes sind als TC-<Code> enthalten.

trip_id ist folgendermassen aufgebaut: <fortlaufende Nummer in trips.txt>.<service_id>.<route_id>.<Fahrwegsnummer>.<Fahrtrichtung>

Seit Juni 2025 werden bei Flügelungen (Auftrennung gekoppelter Züge) im Feld “trip_headsign” zusammengesetzte Richtungstexte angezeigt. Beispielsweise könnte bei der Fahrt von Bern nach Spiez “Brig | Zweisimmen” stehen, wenn der eine Zugteil anschliessend nach Brig, der andere nach Zweisimmen weiterfährt.

Beispiel:

route_id,service_id,trip_id,trip_headsign,trip_short_name,direction_id,block_id,original_trip_id,hints
"91-2A-Y-j26-1","TA","10.TA.91-2A-Y-j26-1.3.H","Milano Centrale","23","0","","ch:1:sjyid:100001:23-003",""
"91-46-B-j26-1","TA+3t000","1.TA.91-46-B-j26-1.1.H","Sedrun","426","0","","","2 NF"
"92-5-B-j26-1","TA+d4","10.TA.92-5-B-j26-1.2.H","St. Gallen, Rotmonten","5612","0","","","NF"
"91-1-N-j26-1","TA","57.TA.91-1-N-j26-1.22.R","Brig | Zweisimmen","4185","1","1088","ch:1:sjyid:100015:4185-001","FL"
"91-1-N-j26-1","TA","58.TA.91-1-N-j26-1.22.R","Brig | Zweisimmen","4163","1","1089","ch:1:sjyid:100015:4163-001","FL"
"91-1-N-j26-1","TA","62.TA.91-1-N-j26-1.22.R","Brig | Zweisimmen","4159","1","1094","ch:1:sjyid:100015:4159-001","FL"
"91-1-N-j26-1","TA+c9","65.TA.91-1-N-j26-1.22.R","Brig | Zweisimmen","4179","1","1077","ch:1:sjyid:100015:4179-001","FL"
"91-7C-Y-j25-1","TA+97om0","1.TA.91-7C-Y-j25-1.1.H","Neuchâtel | Fribourg/Freiburg","31110","0","3748","ch:1:sjyid:100034:31110-019","FL TC-005000"
"91-7C-Y-j25-1","TA+oot30","2.TA.91-7C-Y-j25-1.1.H","Neuchâtel | Fribourg/Freiburg","31112","0","3747","ch:1:sjyid:100034:31112-020","FL TC-005000"

Betriebstage und Kalendertage in GTFS-S und GTFS-RT

Der start_day in GTFS-S ist der Start-Betriebstag (“Start service day for the service interval.”) Es können somit Zeitangaben >24:00 vorkommen, weil Fahrten von Verkehrsmitteln, welche nach Mitternacht (also bereits am nächsten Kalendertag) beginnen, immer noch zum gleichen Betriebstag gehören.

Es gibt in GTFS-RT keine spezifische Information für den Betriebstag, das StartDate ist dort immer der Kalendertag. Die gleiche Fahrt kann also im GTFS-S um 24:47:00 abfahren, in GTFS-RT aber eine startTime von 00:47:00 haben.

Stabilität von Identifiern zwischen Versionen des GTFS-Static-Files

GTFS Static wird jede Woche zweimal neu erzeugt. Daher kann es sein, dass die service_id und die trip_id nicht identisch sind.

Bereitstellungszyklus neuer GTFS-Static-Files

Jeweils am Dienstag und Freitag wird eine neue Version der HRDF-Daten (Basis für GTFS-S) publiziert, 1-2 Arbeitstage später zwischen 9 und 10 Uhr jeweils das GTFS-Static, welches darauf basiert (siehe Tabelle unten).

Gleichentags um 15 Uhr wird der dazu passende GTFS-RT Feed aktiviert.

Bitte beachten: An Feiertagen (z. B. Ostermontag, Pfingstmontag u. a.) findet keine Aktualisierung statt.

Im Störungsfall: Der GTFS-Static-Datensatz wird schnellstmöglich veröffentlicht, gefolgt von GTFS Realtime ca. 5–6 Stunden später, spätestens jedoch bis 18:00 Uhr desselben Tages. Sollte dies nicht realisierbar sein, erfolgt die Aktivierung der neuen Daten in GTFS Realtime am Folgetag.

Beispiel: Die neuen GTFS-Static-Daten konnten erst am Nachmittag publiziert werden. Die Aktivierung der GTFS-Realtime-Daten folgt am nächsten Tag um ca. 09:00 Uhr.

Weiterführende Angaben

Matching GTFS – HRDF

Die trip_id hat nichts mit den HRDF-Daten zu tun. Die Zuordnung zwischen HRDF- und GTFS-Fahrten ist nicht ganz 1:1, da die Fahrt ID (= Fahrtnummer) innerhalb eines HRDF-Datensatzes nicht unique sein muss. Es passt immer der einen Tag ältere HRDF-Feed (z. B. 2025-08-13) zum GTFS-Feed (z. B. 2025-08-14)

Unter Zuhilfenahme von Haltestellen und Haltezeiten, lässt sich aber die passende Fahrt wie folgt finden:

In der trips.txt steht der trip_short_name, im folgenden Beispiel 25358:

route_id,service_id,trip_id,trip_headsign,trip_short_name,direction_id,block_id,original_trip_id,hints
"91-30-B-j25-1","TA+7ma70","79.TA.91-30-B-j25-1.32.R","Cadenazzo","25358","1","","ch:1:sjyid:100001:25358-001",""

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

*Z 025358 000011   103                                     % -- 39759342469 --
*G S   8301030 8505404                                     %
*A VE 8301030 8505404 755971                               %
*A X  8505410 8505410 755971                               %
*A X  8505405 8505405 755971                               %
*I JY                        000011968                     %
*I hi 8301030 8505404        000011847                     %
*L 30       8301030 8505404                                %
*R H                                                       %
8301030 Gallarate                    00819                 %
8301145 Besnate               00824  00825                 %
8301144 Mornago-Cimbro        00829  00830                 %
8301143 Ternate-Varano Borgh  00835  00836                 %
8301142 Travedona-Biandronno  00839  00840                 %
8301141 Besozzo               00844  00845                 %
8301140 Sangiano              00850  00851                 %
8301118 Laveno-Mombello       00856  00901                 %
8301113 Luino (I)             00915  00918                 %
8505874 Colmegna              00922  00922                 %
8505861 Maccagno              00925  00925                 %
8505862 Pino-Tronzano         00930  00930                 %
8505408 Ranzo-S. Abbondio     00934  00934                 %
8505410 Gerra (Gambarogno)    00935  00935                 %
8505407 S. Nazzaro            00940  00940                 %
8505406 Magadino-Vira         00946  00946                 %
8505405 Quartino              00949  00949                 %
8505404 Cadenazzo             00956                        %

Da die Fahrtnummer wie erwähnt innerhalb eines HRDF-Feeds nicht unique sein muss, sollten zusätzlich die Haltezeiten und stop_ids der Fahrt aus stop_times.txt zur Zuordnung beigezogen werden. Im Beispiel von HRDF (oben) und GTFS (unten) sind exemplarisch die Zeilen von Abgang und Bestimmung markiert. Wie für ein “Matching” zweier Fahrten nötig, stimmen die Zeiten überein:

trip_id,arrival_time,departure_time,stop_id,stop_sequence,pickup_type,drop_off_type
"79.TA.91-30-B-j25-1.32.R","08:19:00","08:19:00","8301030","1","0","0"
"79.TA.91-30-B-j25-1.32.R","08:24:00","08:25:00","8301145","2","0","0"
"79.TA.91-30-B-j25-1.32.R","08:29:00","08:30:00","8301144","3","0","0"
"79.TA.91-30-B-j25-1.32.R","08:35:00","08:36:00","8301143","4","0","0"
"79.TA.91-30-B-j25-1.32.R","08:39:00","08:40:00","8301142","5","0","0"
"79.TA.91-30-B-j25-1.32.R","08:44:00","08:45:00","8301141","6","0","0"
"79.TA.91-30-B-j25-1.32.R","08:50:00","08:51:00","8301140","7","0","0"
"79.TA.91-30-B-j25-1.32.R","08:56:00","09:01:00","8301118","8","0","0"
"79.TA.91-30-B-j25-1.32.R","09:15:00","09:18:00","8301113","9","0","0"
"79.TA.91-30-B-j25-1.32.R","09:22:00","09:22:00","8505874","10","0","0"
"79.TA.91-30-B-j25-1.32.R","09:25:00","09:25:00","8505861:0:2","11","0","0"
"79.TA.91-30-B-j25-1.32.R","09:30:00","09:30:00","8505862:0:1","12","0","0"
"79.TA.91-30-B-j25-1.32.R","09:34:00","09:34:00","8505408:0:1","13","0","0"
"79.TA.91-30-B-j25-1.32.R","09:35:00","09:35:00","8505410:0:1","14","0","0"
"79.TA.91-30-B-j25-1.32.R","09:40:00","09:40:00","8505407:0:1","15","0","0"
"79.TA.91-30-B-j25-1.32.R","09:46:00","09:46:00","8505406:0:2","16","0","0"
"79.TA.91-30-B-j25-1.32.R","09:49:00","09:49:00","8505405:0:1","17","0","0"
"79.TA.91-30-B-j25-1.32.R","09:56:00","09:56:00","8505404:0:1","18","0","0"

Weiterführende Links

• Offizielle Webseite des GTFS-Standards (auf Englisch)
• Online-Meetup vom 22.05.2025 (auf Deutsch): Fahrplandaten im Check (Vergleich von drei Formaten: GTFS, HRDF und NeTEx)
  • Aufzeichnung
  • Präsentation
• Online-Meetup vom 13.11.2023 (auf Deutsch): Wie GTFS-Datenfeeds zur Verbesserung des öffentlichen Verkehrs nachhaltig beitragen
  • Aufzeichnung
  • Präsentation

#AutoTranslate