Einleitung

In diesem Dokument werden die Ziele der HAFAS-Rohdaten-Konvertierung nach GTFS erläutert und das genaue Vorgehen prinzipiell und anhand von Beispielen erklärt. Basis dieses Dokumentes ist die General Transit Feed Specification (Revision 20. Juni 2012) und die Spezifikation der INFO+ HRDF-Exportschnittstelle 5.20.39 vom 2. April 2014. Es wird davon ausgangen, dass der Leser mit der grundlegenden Struktur des Rohdatenformates vertraut ist.

Ziele

Die Konvertierung der Rohdaten macht die Fahrplandaten grundsätzlich einem erweiterten Kreis von Entwicklern zugänglich. GTFS ist besser strukturiert, einfacher zu benutzen, einfacher zu erweitern und besser dokumentiert als HAFAS-Rohdaten. Das zugrundeliegende Dateiformat (CSV) kann sowohl maschinell als auch von Menschen einfach gelesen werden. Darüberhinaus existiert ein umfangreiches Angebot von Tools zur Validierung, Visualisierung, Bearbeitung und Änderung von GTFS-feeds. OpenSource Routenfinder wie OTP unterstützen GTFS bzw. akzeptieren GTFS als einziges Eingabeformat für Fahrplandaten.

Ziel dieser Konvertierung war es, den Verlust an Information so gering wie möglich zu halten, den GTFS-Standard voll zu erfüllen und die Qualität von auf Basis der GTFS-Daten berechneten Verbindungen zu garantieren. Hierzu gehört inbesondere, dass keine Verbindungen mit Fehlern erster Art (Fahrten, die am betreffenden Tag gar nicht stattfinden) und zweiter Art (Verbindungen, bei denen ein Umstieg anhand der Ankunfts-/Abfahrtszeiten möglich, jedoch aufgrund minimaler Umsteigezeiten unrealistisch ist) auftreten. Außerdem sollen spezifische Informationen zur Verkehrsstromlenkung - soweit möglich - übernommen werden.

Zum Informationserhalt gehört zunächst, dass in den Rohdaten enthaltene Attribute so weit wie möglich nach GTFS übersetzt werden. Das GTFS-Format sprengende, jedoch für das Schweizer ÖNV-Netz wichtige Informationen werden als Erweiterung des GTFS-Formates ebenfalls übernommen, wo dies sinnvoll ist. Hierzu gehören beispielsweise die in ATTRIBUT_* definierten Fahrtattribute, die sich nicht direkt nach GTFS abbilden lassen (z.B. 2 für ‘Nur zweite Klasse’, Informationen zu Speisewägen, Reservierungen etc).

Angebotene Feeds und mögliche Erweiterungen

Da der Umgang mit sehr großen Feeds Entwickler vor Herausforderungen stellt (gängige Tools zur Validierung erreichen z.B. schnell die Speichergrenze des Systems), werden mehrere Untermengen des Gesamtfahrplanes angeboten. Als Ausgabe der Konvertierung werden zur Zeit sechs ZIP-komprimierte Feeds erzeugt, die jeweils miteinander kombinierbar sind.

gtfs_train.zip
Enthält sämtliche Züge und S-Bahnen
gtfs_tram.zip
Enthält sämtliche Straßenbahnen
gtfs_bus.zip
Enthält sämtliche Busse
gtfs_ferry.zip
Enthält sämtliche Schiffe
gtfs_gondola.zip
Enthält sämtliche Seilbahnen und Skilifte
gtfs_total.zip
Enthält sämtliche Daten in einem Feed gesamelt.

Denkbar sind außerdem Feeds für spezielle Anbieter (wie in ECKDATEN definiert, z.B. SBB, BVB, RhB, VBZ etc.) oder Feeds für Gruppen ausgewählter Anbieter zur Abdeckung der großen Verkehrsverbünde.

Im folgenden wird davon ausgegangen, dass der Leser mit dem HAFAS-Rohdatenformat vertrauter ist als mit GTFS. Die Konvertierung wird sortiert nach den Ausgangsdateien des Rohdatenformates zunächst schematisch erläutert und dann anhand eines Beispiels dargestellt. Auf Datenverluste bei der Konvertierung wird ebenso hingewiesen wie auf Schwierigkeiten bei der Konvertierung und mögliche Erweiterungen.

Konvertierung

Das GTFS-Format sieht grundsätzlich vier große Objekttypen zur Speicherung von Fahrplandaten vor.

stops
sind Haltepunkte (I) im Netz oder Gruppen von Haltepunkten (II). Eine Fahrt kann immer nur an einem Haltepunkt der ersten Art anhalten, niemals an einer Gruppe von Haltepunkten. Gruppen von Haltepunkten können z.B. große Bahnhöfe sein, die mehrere Haltepunkte (= Gleise, Anlegestellen etc.) anbieten.
routes
sind Gruppen von trips (von Fahrten), die dem Fahrgast als singuläres Angebot präsentiert werden. Das Ausmaß der Fahrtengruppierung ist hierbei nicht genau festgelegt. Gängige Vorgehen sind in absteigender Reihenfolge des Grades der Zusammenfassung z.B. das Gruppieren nach Linie (“M 2”, beide Fahrtrichtungen, sämtliche Fahrten), das Gruppieren nach Linie und Fahrtrichtung (“M 2 nach Lausanne Gare”, sämtliche Fahrten), das Gruppieren nach Fahrt (“IC 2323 nach Basel SBB”, mit sämtlichen abweichenden Fahrten, z.B. Fahrten mit geänderten Gleisinformationen, mit ausgelassenen Stationen, mit geänderten Attributen) oder der vom Standard nicht explizit verbotene Trivialfall eine Route pro Fahrt. Da das Rohdatenformat das Konzept Route / Fahrt nicht kennt, wurde ein geringer Grad der Gruppierung gewählt. Siehe hierzu auch den GTFS Style Guide .
trip
sind tatsächlich stattfindene Fahrten und entsprechen grob den in FPLAN abgebildeten Fahrten.
stop_time
sind Halte- und/oder Abfahrtsereignisse einer Fahrt an einem stops

Weitere GTFS-Objekte werden im Verlauf dieses Abschnittes eingeführt.

ECKDATEN

Sowohl die Gültigkeitsperiode des Fahrplans, die Fahrplanbezeichnung, die Fahrplanversion und der Fahrplanlieferant werden direkt aus ECKDATEN in die feed_info.txt geschrieben.

ECKDATEN feed_info.txt Bedeutung Hinweis
Zeile Spalte      
1 1:10 feed_start_date Begin Gültigkeit Fahrplan  
2 1:10 feed_end_date Ende Gültigkeit Fahrplan  
3 :$ feed_version Version des Fahrplans  
3 :$     Keine Verwendung
3 :$     Keine Verwendung
3 :$     Keine Verwendung
3 :$     Keine Verwendung
3 :$ feed_publisher_name    
feed_publisher_url URL des Veröffentlichers z.Zt. immer http://www.sbb.ch
feed_publisher_lang Feed-Sprache z.Zt. immer de

Beispieldatei ECKDATEN:

15.12.2013
13.12.2014
Fahrplan 2014$2014$85$29.06.2014 06:25:26$5.20.39$INFO+

Erzeugte feed_info.txt:

feed_publisher_name,feed_lang,feed_start_date,feed_end_date,feed_version
INFO+,,20131215,20141213,Fahrplan 2014

BETRIEB_*

Die nach Sprachkürzel abgelegten Dateien BETRIEB_* enthalten Informationen zu den Angebotsbetreibern, die jeweils als agency in die agencies.txt geschrieben werden. Nur die erste Zeile pro Betreiber wird verwendet. Standardmäßig wird zur Zeit BETRIEB_DE gelesen.

BETRIEB_* agencies.txt Bedeutung Hinweis
Zeile Spalte      
1 1:5 agency_id Betreibernummer
1 5:K agency_name Betreiber Kurzname Zusammen mit Betreiber Vollname, s.u.
1 K:L   Betreiber Langname
1 L:V agency_name Betreiber Vollname Zusammen mit Betreiber Kurzname, s.u.
agency_lang Keine Verwendung
agency_phone Keine Verwendung
agency_url Webseite des Betreibers Zur Zeit immer http://www.sbb.ch

Beispielauszug aus BETRIEB_DE:

00013 K "AAG" L "AAGR" V "Auto AG Rothenburg"
00013 : 000812
00014 K "AAG" L "AAGS" V "Auto AG Schwyz"
00014 : 000841
00015 K "AAG" L "AAGU" V "Auto AG Uri"
00015 : 000816

Entsprechender Beispielauszug aus agencies.txt:

agency_id,agency_name,agency_url,agency_timezone,agency_lang,agency_phone
000841,AAGS (Auto AG Schwyz),http://www.sbb.ch,Europe/Berlin,,
000816,AAGU (Auto AG Uri),http://www.sbb.ch,Europe/Berlin,,
000811,AAGL (Autobus AG Liestal),http://www.sbb.ch,Europe/Berlin,,

BITFELD

BITFELD speichert allgemein Gültigkeitstage für eine bestimmte ID in Form einer Bitmap. Hierbei ist zu beachten, dass weder eine 1:1 noch eine n:1 Beziehung zwischen einer Fahrt in FPLAN und einer in BITIELD gespeicherten Gültigkeitstagemap besteht. Fahrten in FPLAN können sowohl mehrere Gültigkeits-Bitfelder für die gesamte Fahrt bekommen, aber auch Bitfelder, die nur für einen bestimmten Fahrtabschnitt (z.B. Station 2 bis Station 4, die nur in der Sommersaison bedient werden) gültig sind. Außerdem können sich bestimmte Attribute einer Fahrt nur auf bestimmte Verkehrstage beziehen. Das genaue Vorgehen des Expandierens von singulären FPLAN-Fahrten zu mehreren GTFS trips wird im Abschnitt FPLAN genauer erläutert.

GTFS kennt zwei Arten, Verkehrstage abzulegen.

calendar_dates.txt
ermöglicht das Abbilden von Verkehrstagen ähnlich wie BITFIELD, jedoch erweitert und anders formatiert. Für jedes Datum kann definiert werden, ob die Fahrt stattfindet oder ob sie hier explizit _nicht_ verkehrt. Letzteres macht Sinn, wenn calendar_dates.txt zusammen mit einer calendar.txt verwendet wird
calendar.txt
ermöglicht das Abbilden von Verkehrstagen als Zeitspanne mit Angabe von Wochentagen, an denen die Fahrt verkehrt.

Leere BITFELD-Referenzen bzw ‘000000’ in den Rohdaten werden grundsätzlich mit einem standarmäßig generierten Eintrag in calendar.txt abgebildet, der die gesamte Fahrplanperiode abdeckt.

Beispiel für einen Eintrag in calendar.txt:

service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date
000000,1,1,1,1,1,1,1,20131215,20141213

Für die calendar_dates.txt ergibt sich folgendes Konvertierungsschema:

BITFELD calendar_dates.txt Bedeutung Hinweis
Zeile Spalte      
* 1:6 service_id ID der Verkehrstage
* 8:103 date Verkehrstage Verteilt auf mehrere Zeilen
exception_type   Zur Zeit immer 1

Beispiel für einen Eintrag in BITFELD:

000001 DF3264F9F3E7CF9F3E7CF9F3E7CF9F3C3CE9F3E7CE9F1E7CF9F3E7CF9E3E7CF9F3E7CF9F3E7CF9F3E7CF9F3E7CFB0000

Auszug aus dem entsprechenden Eintrag in calendar_dates.txt:

...
service_id,date,exception_type
000001,20131230,1
000001,20131231,1
000001,20140103,1
000001,20140106,1
000001,20140107,1
000001,20140108,1
...

BAHNHOF

Die Bahnhofsnamen werden aus der Datei BAHNHOF gelesen. Diese enthält neben dem eigentlichen Namen noch Abkürzungen und Synonyme (z.B. den Namen in anderen Sprachen). Diese Zusatzinformationen werden als sinnvolle Erweiterung mit in das konvertierte GTFS-Feed übernommen und werden nach stops.txt geschrieben.

BAHNHOF stops.txt Bedeutung Hinweis
Zeile Spalte      
* 1:7 stop_id ID der Verkehrstage
* 13:62 stop_name Haltestellenname Rohdateneintrag mit $<1>$
* ch_station_long_name Haltestellenname lang mit $<2>$, Sonderfeld
* stop_code Stationskürzel mit $<3>$
* ch_station_synonym<1-4> Namessynonyme mit $<4>$, maximal 4, Sonderfeld

Beispiel für einen Eintrag in BAHNHOF:

8501008     Genève$<1>$GE$<4>$Geneva$<4>$Genf$<4>$Ginevra$<4>$GE$<3>

Entsprechender Eintrag in stops.txt:

stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,stop_elevation,zone_id,stop_url,location_type,parent_station,platform_code,ch_station_long_name,ch_station_synonym1,ch_station_synonym2,ch_station_synonym3,ch_station_synonym4
8501008,GE,Genève,,46.210203,6.142452,391,,,0,8501008,8,,GE,Geneva,Genf,Ginevra

BFKOORD_GEO

Informationen für die Position eines Bahnhofes werden aus der BFKOORD_GEO extrahiert. BFKOORD_GEO speichert zusätzlich zu X- und Y-Position eine Z-Koordinate in Meter über dem Meeresspiegel. Diese wird als sinnvolle Erweiterung mit in das konvertierte GTFS-Feed übernommen, ist jedoch nicht Teil des GTFS-Kernstandards. Die in BFKOORD_GEO Informationen werden zu den in stops.txt aus BAHNHOF eingelesenen hinzugefügt.

Rohdaten stops.txt Bedeutung Hinweis
Zeile Spalte      
* 1:7 stop_id ID der Verkehrstage Zur Verknüpfung mit BAHNHOF
* 9-18 stop_lat Breitengrad WGS84  
* 20-29 stop_lon Längengrad WGS84  
* 31-36 stop_elevation Höhe ü.M. in Meter, Sonderfeld
* 38: / Wiederholung Stationsname keine Verwendung

Beispiel für einen Eintrag in BFKOORD_GEO:

8507364   7.982085  46.547468 3454   % Jungfraujoch

Entsprecher Eintrag in stops.txt:

stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,stop_elevation,zone_id,stop_url,location_type,parent_station,platform_code,ch_station_long_name,ch_station_synonym1,ch_station_synonym2,ch_station_synonym3,ch_station_synonym4
8507364,JU,Jungfraujoch,,46.547468,7.982085,3454,,,0,,,,JU,Top of Europe,,

METABHF

METABHF speichert minimale Übergangszeiten von Station zu Station. Diese werden wie folgt in transfers.txt übernommen:

METABHF transfers.txt Bedeutung Hinweis
Zeile Spalte      
* 1:7 from_stop_id Station 1  
* 9:15 to_stop_id Station 2  
* 17:19 min_transfer_time Übergangszeit in Sekunden
transfer_type Art der Transferbeziehung hier immer 2

UMSTEIGB

Hält die Umsteigezeit innerhalb eines Bahnhofes. Wird wie folgt in transfers.txt übernommen:

UMSTEIGB transfers.txt Bedeutung Hinweis
Zeile Spalte      
* 1:7 from_stop_id Station 1  
* 1:7 to_stop_id Station 2 hier wie from_stop_id
* 12:13 min_transfer_time Übergangszeit in Sekunden
transfer_type Art der Transferbeziehung hier immer 2

KMINFO

KMINFO definiert die Priorität, die eine Station als Umsteigepunkt erhält. Ist die Priorität 0, soll diese Station nie als Umsteigepunkt gewählt werden. Diese Information wird in transfers.txt übernommen, indem ein Transfer von der Station zu sich selbst mit Typ 3 (kein Transfer möglich) geschrieben wird. Diese Information ist haupsächlich für die Lenkung von Verkehrsströmen relevant.

KMINFO transfers.txt Bedeutung Hinweis
Zeile Spalte      
* 1:7 from_stop_id Station 1  
* 1:7 to_stop_id Station 2 hier wie from_stop_id
* 9:13 transfer_type Art der Transferbeziehung 3 (kein Transfer) wenn 9:13 = 0

GLEIS

Zu der großen Schwierigkeit bei der Konvertierung von HAFAS-Rohdaten nach GTFS gehört das grundsätzlich verschiedene Konzept der Abbildung der Gleisinformationen. Im Rohdatenformat werden Gleise pro Fahrt und Station in GLEIS gespeichert. GLEIS hat die Besonderheit, dass hier erneut eine - von der Fahrt unabhängige - Verkehrstagebitmap angegeben werden kann, um z.B. abweichende Gleise an bestimmten Verkehrstagen zu modellieren. Hierfür kennt GTFS keine unmittelbare Abbildungsmöglichkeit.

Gleise werden in GTFS als explizite Haltestellen behandelt, die in stops.txt abgelegt werden. Um mehrere Haltestellen (Gleise) zu einem Bahnhof zu gruppieren, gibt es die Möglichkeit, Stationen eine parent_station sowie einen location_type zu übergeben, der definiert, ob die Haltestelle ein Mutterstation (hier: “Bahnhof”) oder ein simpler Haltepunkt (hier: “Gleis”) ist.

In einem ersten Konvertierungsschritt wird GLEIS gelesen und sämtliche vorkommenden Gleise als stops mit location_type = 0 in die stops.txt geschrieben. Hierbei wird folgendes Schema verwendet:

stops.txt Bedeutung Hinweis
stop_id Eindeutige ID des Gleises Format: <parent_station_id>:<gleis>
stop_name Haltestellenname Format: <Name Mutterstation>, Gl. <gleis>
stop_desc Haltestellenbeschreibung Name der Mutterstation
parent_station ID der Mutterstation ID der Mutterstation
platform_code Gleis Unverändert aus GLEIS
location_type Art der Haltestelle Hier immer 0
stop_lat Breitengrad WGS84 Zur Zeit noch wie Mutterstation
stop_lon Längengrad WGS84 Zur Zeit noch wie Mutterstation
stop_elevation Höhe ü.M. Zur Zeit noch wie Mutterstation
ch_station_long_name Haltestellenname lang wie Mutterstation
ch_station_synonym<1-4> Namessynonyme wie Mutterstation

Beispiel für einen Gleiseintrag in GLEIS, der für die Fahrt 87865 000011 gültig ist:

8500010 87865 000011 12       2150 474951

Beispiel für das entsprechende Gleis in stops.txt:

8500010:12,BS,Basel SBB,,47.547405,7.589551,277,,,0,8500010,12,,Basilea FFS,Basle SBB,Bâle CFF,

Jede in BAHNHOF vorkommende Station, die irgendwann von einem Fahrzeug mit einer bestimmten Gleisbezeichnung angefahren wird, erhält in stops.txt den location_type 1, um die Station als Gruppe von Haltestellen zu kennzeichnen. Diese Tatsache erzeugt einen Sonderfall. Die Rohdaten sehen problemlos vor, dass eine Station _ohne_ Gleisbezeichnung angefahren wird. Eine Stationsgruppe mit location_type=1 darf laut GTFS-Standard jedoch nicht angefahren werden. Aus diesem Grund werden - nur wenn dieser Fall eintritt - zusätzlich zu den Gleis-Haltestellen in stops.txt ein “leeres” Gleis nach stops.txt geschrieben, das als Sammelgleis für alle Züge dient, die den Bahnhof ohne Gleisbezeichnung anfahren. Diese Sonder-Haltestelle ist wie folgt aufgebaut:

stops.txt Bedeutung Hinweis
stop_id Eindeutige ID des Gleises Format (Doppelpunkt am Ende!): <parent_station_id>:
stop_name Haltestellenname Name Mutterstation
... (wie oben)    

Stationen, die niemals mit Gleisinformation angefahren werden (z.B. kleinere Haltepunkte von Regionalbahnen und S-Bahn-Netzen) werden unverändert wie im Abschnitt BAHNHOF übernommen.

Der Tatsache, dass einzelne Fahrten an verschiedenen Verkehrstagen verschiedene Gleise anfahren können, wird während des im Abschnitt FPLAN erklärten Expandierens der Fahrten Rechnung getragen.

FPLAN

Eine Fahrt (trip) ist in GTFS ein eindeutiger Verlauf von Ankunfts-/Abfahrtsereignissen an eindeutigen Haltepunkten, der an bestimmten Verkehrstagen angeboten wird, zu einer übergeordneten route gehört, bestimmte Merkmale besitzt und sich niemals ändert. Eine Fahrt in FPLAN ist ungleich dynamischer. Sowohl für Gleisinformationen, Attribute und Bedientage bestimmter Stationen können eigene BITFELD-Einträge definiert werden. Aus GTFS-Sicht bedeutet dies, dass in einer einzigen Rohdatenfahrt _mehrere_ GTFS trips enthalten sind. Diese herauszuarbeiten (zu expandieren) benötigt die größte Rechenzeit während des Konvertierens.

Beispiel:
Fahrt X hat in der *A VE-Zeile von FPLAN ein BITFELD zugewiesen bekommen, das X vom 1. März bis zum 1. Oktober durchgehend verkehren lässt. X bedient 3 Stationen, Tannenheim, Steindorf und Vogelsbach.

Der Fahrtverlauf ist wie folgt angegeben, nach dem Doppelpunkt sind Gleise notiert, die Ankunfts-/Abfahrtszeiten wurden ausgelassen:

TannH:1      ->    SteinD:3      ->   VogelB:6      --  von 1. März bis 1. Oktober

In einer weiteren *A Zeile wurde nun das Attribut VR definiert (Reservierung obligatorisch für Velos.) Da die Velo-Beförderung nur an Wochenenden problematisch wird, gilt dieses Attribut nur an Wochenden. Damit ergeben sich bereits 2 mögliche Fahrtvarianten:

TannH:1      ->    SteinD:3      ->   VogelB:6      --  1.3.-1.10, nicht Sa und So
TannH:1:VR   ->    SteinD:3:VR   ->   VogelB:6:VR   --  1.3.-1.10 Sa und So

Außerdem ist bekannt, dass in Vogelsbach in den Sommerferien (1. Juni bis 15. Juli) fast keine Fahrgäste aus- oder zusteigen. Daher gilt an diesen Tagen an dieser Station Halt auf Verlangen, das über das Attribut X in einer weiteren *A-Zeile für die Sommerferien definert wurde. Damit ergeben sich jetzt nicht drei mögliche Fahrtvarianten, sondern vier:

TannH:1    -> SteinD:3    -> VogelB:6      --  1.3.-1.6., 15.7.-1.10., n. Sa+So
TannH:1:VR -> SteinD:3:VR -> VogelB:6:VR   --  1.3.-1.6., 15.7.-1.10., Sa und So
TannH:1    -> SteinD:3    -> VogelB:6:X    --  1.6.-15.7., n. Sa und So
TannH:1:VR -> SteinD:3:VR -> VogelB:6:VR:X --  1.6.-15.7., Sa und So

In GLEIS ist für die Station Steindorf außerdem hinterlegt, dass der Zug an Sonntagen abweichend von Gleis 2 verkehrt. Damit erhöht sich die Zahl der implizit in dieser Fahrt gespeicherten eindeutigen Fahrten erneut:

TannH:1    -> SteinD:3    -> VogelB:6      --  1.3.-1.6., 15.7. - 1.10., n. Sa+So
TannH:1:VR -> SteinD:3:VR -> VogelB:6:VR   --  1.3.-1.6., 15.7. - 1.10., Sa
TannH:1:VR -> SteinD:2:VR -> VogelB:6:VR   --  1.3.-1.6., 15.7. - 1.10., So
TannH:1    -> SteinD:3    -> VogelB:6:X    --  1.6.-15.7., n. Sa+So
TannH:1:VR -> SteinD:3:VR -> VogelB:6:VR:X --  1.6.-15.7., Sa
TannH:1:VR -> SteinD:2:VR -> VogelB:6:VR:X --  1.6.-15.7., So

In einer letzten Definition wird nun über eine weitere *A VE-Zeile festgelegt, dass der Zug wegen Bauarbeiten vom 1.9. bis zum 14.9. erst in Steindorf beginnt:

              SteinD:3    -> VogelB:6      --  1.9 -14.9., n. Sa+So
              SteinD:3:VR -> VogelB:6:VR   --  1.9 -14.9., Sa
              SteinD:2:VR -> VogelB:6:VR   --  1.9 -14.9., So
TannH:1    -> SteinD:3    -> VogelB:6      --  1.3.-1.6., 15.7.-1.10., n, 1.9-14.9., n. Sa+So
TannH:1:VR -> SteinD:3:VR -> VogelB:6:VR   --  1.3.-1.6., 15.7.-1.10., n, 1.9-14.9., Sa
TannH:1:VR -> SteinD:2:VR -> VogelB:6:VR   --  1.3.-1.6., 15.7.-1.10., n, 1.9-14.9., So
TannH:1    -> SteinD:3    -> VogelB:6:X    --  1.6.-15.7., n. Sa und So
TannH:1:VR -> SteinD:3:VR -> VogelB:6:VR:X --  1.6.-15.7., Sa
TannH:1:VR -> SteinD:2:VR -> VogelB:6:VR:X --  1.6.-15.7., So

Vor allem bei langen Zugläufen mit häufig wechselnden Gleisen kann die Zahl der möglichen expliziten Fahrtverläufe noch bedeutend höher sein. Während der Konvertierung wird jede in FPLAN hinterlegte Fahrt - wenn nötig! - expandiert und mehrere trips in die trips.txt geschrieben. Auf diese Weise kann garantiert werden, dass Attribute, Stationsbedienungen und Gleisangaben immer korrekt sind. Die Fahrten bleiben weiterhin über eine gemeinsame in routes.txt gespeicherte Route miteinander verbunden.

Wenn möglich wird versucht, in *A - Zeilen gespeicherte Attribute in GTFS-Attribute umzuwandeln. Wo dies nicht möglich ist, werden die entsprechenden Attribute semikolongetrennt in ein Sonderfeld geschrieben, so dass diese nicht verloren gehen. Attribute, die für die ganze Fahrt gelten, werden per trip gespeichert. Attribute, die nur für bestimmte Stationen gelten, werden per stop_time gespeichert. Es ergeben sich insgesamt folgende Beziehungen:

FPLAN routes.txt Bedeutung Hinweis
Zeile Spalte      
*Z 4:8 route_id Fahrtnummer Zusammen mit Verwaltung, getrennt durch .
*Z 10:15 route_id Verwaltung Zusammen mit Fahrtnummer, getrennt durch .
*Z 10:15 agency_id Verwaltung Verknüpfung zu den Daten aus BETRIEB
*G 4:6 route_long_name Verkehrsmittel Zusammen mit Liniennummer aus *L, *I ZN oder *I RN
*G 4:6 route_short_name Verkehrsmittel Nur bei Zügen
*L 4:11 route_short_name Liniennummer Nur bei Nicht-Zügen, wenn vorhanden
*I RN 4:11 route_short_name Liniennummer Nur bei Nicht-Zügen, wenn vorhanden
*I`ZN 4:11 route_short_name Liniennummer Nur bei Nicht-Zügen, wenn vorhanden
*G 4:6 route_color Linienfarbe der Route Anhand vordefiniertem Mapping Gattung:Farbe für einzelne Gattungen
*G 4:6 route_text_color Textfarbe der Route Anhand vordefiniertem Mapping Gattung:Farbe für einzelne Gattungen

Nach dem Leser einer FPLAN-Fahrt wird diese expandiert und wie folgt abgelegt:

FPLAN trips.txt Bedeutung Hinweis
Zeile Spalte      
*Z 4:8 route_id Fahrtnummer Zusammen mit Verwaltung, getrennt durch Doppelpunkt
*Z 10:15 route_id Verwaltung Zusammen mit Fahrtnummer, getrennt durch Doppelpunkt
agency_id Verkehrstage Verknüpfung mit während des Expandierens generierten Verkehrstagen
trip_id Eindeutige Fahrt-ID Fortlaufend generiert
trip_headsign Fahrtziel Letzte Station
*L 4:11 trip_short_name Liniennummer Wenn vorhanden
*I RN 4:11 trip_short_name Liniennummer Wenn vorhanden
*I ZN 4:11 trip_short_name Liniennummer Wenn vorhanden
block_id Block-ID Zugdurchbindungen, zur Zeit noch nicht unterstützt
*A V* bikes_allowed Velos erlaubt Aus Attributen V* (außer VE)
*A attributes_ch Sonderattribute Fahrtweite Attribute außer VE, getrennt durch Semikolon
shape_id Exakter Geofahrtverlauf Verknüpfung zu shapes.txt. Wird z.Zt. nicht exportiert

Die einzelnen Halte pro Fahrt werden aus den Laufwegzeilen wie folgt in stop_times.txt abgelegt:

FPLAN stop_times.txt Bedeutung Hinweis
1:7 stop_id Stop-ID Zur Verknüpfung mit BAHNHOF
trip_id   Verknüpfung mit trips.txt
30:35 arrival_time Ankunftszeit Nach Konvertierung in GTFS Format
37:42 departure_time Abfahrtszeit Nach Konvertierung in GTFS Format
stop_sequence Stationsfolge Fortlaufend, beginnend bei 0
29 pickup_type Fahrtgastaufnahmeart 0 wenn 29 leer, 1 wenn 29 = - (= kein Einstieg)
36 drop_off_type Fahrtgastausstiegseart 0 wenn 36 leer, 1 wenn 36 = - (= kein Ausstieg)
*A attributes_ch Sonderattribute Haltepunktspezifische Attribute außer VE, getrennt durch Semikolon

Periodische Fahrtwiederholungen (Takte) werden direkt nach frequencies.txt abgebildet.

Folgende Abbildungen der Fahrtattribute direkt nach GTFS existieren zur Zeit:

Rohdaten-Attribut GTFS-Datei Bedeutung GTFS-Feld GTFS-Wert Bemerkung
VL trips.txt VELOS: Selbstverlad eingeschränkt bikes_allowed 1  
VN trips.txt VELOS: Kein Selbstverlad bikes_allowed 1  
VP trips.txt VELOS: Reservierung, siehe www.postauto.ch bikes_allowed 1  
VR trips.txt VELOS: Reservierung obligatorisch bikes_allowed 1  
VX trips.txt VELOS: Beförderung nicht möglich bikes_allowed 0  
X stop_times.txt Halt auf Verlangen drop_off_type 3 “Must coordinate with driver”
X stop_times.txt Halt auf Verlangen pick_up_type 3 “Must coordinate with driver”
XP stop_times.txt Einstieg nur mit Reservierung drop_off_type 2 “Must phone agency”
XR stop_times.txt Einstieg nur nach telefonischer Voranmeldung drop_off_type 2 “Must phone agency”
XT stop_times.txt Einstieg nur mit Reservierung drop_off_type 2 “Must phone agency”

Hier nicht aufgelistete Attribute werden wie oben dargestellt in attributes_ch geschrieben. Auch nach GTFS konvertierte Attribute werden, um die erweiterten Informationen zugänglich zu halten, in attributes_ch geschrieben.

Beispiel für einen route-Eintrag:

route_id,agency_id,route_short_name,route_long_name,route_desc,route_type,route_url,route_color,route_text_color
03188.000094,000094,3188,R 3188,,1,,,

Beispiel für einen trip-Eintrag dieser Route:

route_id,service_id,trip_id,trip_headsign,trip_short_name,direction_id,block_id,shape_id,bikes_allowed,attributes_ch
03188.000094,499835:1:s,499835,Waldenburg,3188,,,,0,2

Beispiel für stop_times Einträge dieser Route:

trip_id,arrival_time,departure_time,stop_id,stop_sequence,stop_headsign,pickup_type,drop_off_type,shape_dist_traveled,attributes_ch
499835,19:35:00,19:35:00,8500023:4,0,,0,0,,
499835,19:37:00,19:37:00,8500081,1,,0,0,,
499835,19:40:00,19:40:00,8500082,2,,0,0,,
499835,19:41:00,19:41:00,8500080,3,,3,3,,X
499835,19:44:00,19:44:00,8500083,4,,3,3,,X
499835,19:47:00,19:47:00,8500084,5,,3,3,,X
499835,19:48:00,19:48:00,8500092,6,,3,3,,X;X
499835,19:49:00,19:49:00,8500093,7,,3,3,,X;X
499835,19:51:00,19:51:00,8500094,8,,3,3,,X;X
499835,19:52:00,19:52:00,8500085,9,,3,3,,X
499835,19:55:00,19:55:00,8500088,10,,3,3,,X;X
499835,19:56:00,19:56:00,8500086,11,,3,3,,X;X
499835,19:59:00,19:59:00,8500087,12,,3,3,,X;X

Hinweise zur Mehrsprachigkeit

Die Mehrsprachigkeit wird in den Rohdaten über verschiedene Dateien mit jeweiliger Sprachcode-Endung erreicht, z.B. ATTRIBUTE_DE, ATTRIBUT_FR etc. Es ist problemlos möglich, die Konvertierung in eine bestimmte Sprache erfolgen zu lassen. Denkbar wäre außerdem, die in den GTFS-Extensions vorgeschlagene (aber noch nicht in den Standard aufgenommene) Variante der Speicherung von Übersetzungen zu nutzen. Weitere Informationen hierzu finden sich in den von Google vorgeschlagenen und bereits verwendeten GTFS Erweiterungen.

Hinweise zu Flügelzügen

Das Abbilden von Flügelzügen ist in GTFS grundsätzlich über die Block-ID möglich, zur Zeit jedoch im Konverter noch nicht umgesetzt. Die jeweiligen Zusammengehörigkeiten dürfen während des Expandierens nicht verloren gehen.

Hinweise zu Shapes

Ein Tool zur automatischen Generierung der Shapes für sämtliche Fahrzeuge liegt vor. Aktuell wird diese Information jedoch noch nicht in den Export übernommen.