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
499835,19:49:00,19:49:00,8500093,7,,3,3,,X
499835,19:51:00,19:51:00,8500094,8,,3,3,,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
499835,19:56:00,19:56:00,8500086,11,,3,3,,X
499835,19:59:00,19:59:00,8500087,12,,3,3,,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.