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.