Gegenüberstellung von General Transit Feed und Visum-Datenmodell

Beim Export der Daten werden direkt aus dem Visum-Datenmodell die entsprechenden GTFS-Dateien (General Transit Feed Specification) erzeugt. Die Zuordnung der Tabellen und Attribute der Datenmodelle ist im Folgenden beschrieben.

Hinweise: Die Tabellen und Attribute sind in der gleichen Reihenfolge aufgelistet wie in der Netzdatei. Die Bezeichnungen der Visum-Tabellen und -Attribute entsprechen denen, die in der Netzdatei standardmäßig verwendet werden.

Die Bezeichnungen der GTFS-Daten entsprechen denen in der General Transit Feed Specification Reference. Dort finden Sie auch genaue Beschreibungen der Felder:

https://gfts.org/schedule/reference.

Der Export in das General Transit Feed Format erzeugt eine Reihe von Pflicht-Dateien und optionalen Dateien:

Dateiname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
agency.txt	Ja	Ja	Betreiber
stops.txt	Ja	Ja	Haltepunkte / Haltestellenbereiche
routes.txt	Ja	Ja	Linien
trips.txt	Ja	Ja	Linienroute + Fahrzeitprofil + Fahrplanfahrt + Durchbindungen
stop_times.txt	Ja	Ja	Fahrzeitprofil + Fahrplanfahrt
calendar.txt	Nein	Ja	Kalender
calendar_dates.txt	Nein	(Ja)	Kalender bei Nutzung Jahreskalender
fare_attributes.txt	Nein	Nein	-
fare_rules.txt	Nein	Nein	-
shapes.txt	Nein	Ja	Linienroutenverlauf + Fahrplanfahrtabschnitte + Strecke
frequencies.txt	Nein	Nein	-
transfers.txt	Nein	Ja
feed_info.txt	Nein	Nein	-

Agency.txt

In der Datei agency.txt werden die Informationen zum Betreiber gespeichert.

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
agency_id	Nein	Ja	Betreiber.Nr
agency_name	Ja	Ja	Betreiber.Name Betreiber.Nr
agency_url	Ja	Ja	http:// + Leer
agency_timezone	Ja	Ja	Globale Auswahl der Zeitzone im Dialog
agency_lang	Nein	Nein	-
agency_phone	Nein	Nein	-
agency_fare_url	Nein	Nein	-
Weitere		Optional	BDA aus der Tabelle Betreiber

Stops.txt

In GTFS ist eine zweistufige Haltestellenhierarchie aus Haltepunkten und Haltestellen vorgesehen. Die dreistufige Hierarchie aus Visum muss daher reduziert werden. Dazu werden die Haltestellenbereiche aufgelöst. Die obere Ebene (location_type=1) bilden somit die Haltestellen, die untere Ebene (location_type=0) die Haltepunkte.

Liegen die Koordinaten der Haltepunkt nicht in WGS84, vor müssen sie nach WGS84 transformiert werden. Es werden nur Haltepunkte exportiert, auf die man aus dem Fahrzeitprofil- oder Linienroutenverlauf heraus verweisen muss – beim Export betrifft das die Tabelle stop_times und optional shape.

Haltestellen mit nur einem Haltestellenbereich/Haltepunkt werden nur einmal in die Datei stops.txt (mit parent_station = 0) geschrieben, wenn Haltestelle und Haltepunkt die gleiche stop_id haben und in allen GTFS-BDAs übereinstimmen.

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
stop_id	Ja	Ja	HP.Nr bzw. Hst.Nr
stop_code	Nein	Ja	HP.Code bzw. Hst.Code
stop_name	Ja	Ja	HP.Name bzw. Hst.Name oder HP.Code bzw. HST.Code oder HP.Nr bzw. Hst.Nr
stop_desc	Nein	Nein	-
stop_lat	Ja	Ja	YCoord gegebenenfalls transformiert
stop_lon	Ja	Ja	XCoord gegebenenfalls transformiert
zone_id	Nein	Ja	Nr. der ersten zugeordneten Tarifzone
stop_url	Nein	Nein	-
location_type	Nein	Ja	0 für HP, 1 für Hst
parent_station	Nein	Ja	HP.HB\Hst.Nr bzw. leer für Hst
stop_timezone	Nein	Nein	-
wheelchair_boarding	Nein	Nein	-

Routes.txt

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
route_id	Ja	Ja	Linie.Name
agency_id	Nein	Ja	Linie.BetreiberNr
route_short_name	Nein	Nein	Leer
route_long_name	Ja	Ja	Linie.Name
route_desc	Nein	Ja	Gegebenenfalls BDA
route_type	Ja	Ja	GTF Transportation Nummer, die für das entsprechende Verkehrssystem der Linie als BDA in der Verkehrssystemtabelle abgelegt ist
route_url	Nein	(Nein)
route_color	Nein	(Nein)
route_text_color	Nein	(Nein)
Weitere	-	Optional	BDA aus der Tabelle Linie

Trips.txt

Je Fahrtvorkommen wird ein “Trip” angelegt.

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
route_id	Ja	Ja	Linie.Name der dazugehörigen Linie
service_id	Ja	Ja	Fahrplanfahrt.Fahrtabschnitt.VerkehrstagNr
trip_id	Ja	Ja	laufende Nr.
trip_headsign	Ja	Ja	Haltepunkt.Name wenn vorhanden, sonst Haltepunkt.Code, sonst nicht gefüllt
trip_short_name	Nein	Ja	Fahrplanfahrt.Name
direction_id	Nein	Ja	Linienroute.Richtung
block_id	Nein	Nein
shape_id	Nein	Ja	Generiert bei Shape-Export
wheelchair_accessible	Nein	(Nein)	-
bikes_allowed	Nein	(Nein)	-
Weitere	-	Optional	BDAs aus Fahrplanfahrt + Fahrplanfahrtabschnitt (bei mehreren Fahrplanfahrtabschnitts-BDAs das erste nehmen; bei ID-Konflikt nur BDA der Fahrplanfahrt nehmen)

Stoptimes.txt

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
trip_id	Ja	Ja	laufende Nr.
arrival_time	Ja	Ja	Fahrplanfahrtelement.Ankunft
departure_time	Ja	Ja	Fahrplanfahrtelement.Abfahrt
stop_id	Ja	Ja	HP.Nr
stop_sequence	Ja	Ja	Fahrplanfahrtelement.Index oder eigene laufende Nr
stop_headsign	Nein	Nein
pickup_type	Nein	Ja	Fahrzeitprofilverlauf.Ein
drop_off_type	Nein	Ja	Fahrzeitprofilverlauf.Aus
shape_dist_traveled	Ja	Ja	Fahrzeitprofilverlauf.KumLänge Minus Fahrzeitprofilverlauf.KumLänge des ersten Fahrtvorkommen-Elementes
Weitere	-	Optional	BDAs von Fahrplanfahrt-Verlauf und Fahrzeitprofil-Verlauf (bei ID-Konflikt nur von einem)

Calendar.txt und Calendar_dates.txt

GTFS sieht für die Beschreibung der Verkehrstage zwei sich ergänzende Ansätze vor. Regelmäßige Gültigkeiten stehen in Calendar.txt, Abweichungen davon in Calendar_dates.txt. Im Visum-Netz kann der Kalender auf drei Arten definiert sein, die unterschiedliche Vorgehensweisen für den Export bedingen:

Kein Kalender

Es wird nur die Datei Calendar.txt gespeichert. Darin steht nur ein Eintrag für Verkehrstag 1 (tägl.). Die Flags für alle Wochentage auf 1 gesetzt. Die Gültigkeitsperiode wird in zwei Kalenderfelder an der Benutzeroberfläche des Exporters eingegeben.

Wochenkalender

Es wird nur die Datei Calendar.txt gespeichert. Darin werden die Verkehrstage aus dem Visum-Modell 1:1 abgebildet. Die Gültigkeitsperiode wird in zwei Kalenderfelder an der Benutzeroberfläche des Exporters eingegeben.

Jahreskalender

Es werden die Dateien Calendar.txt und Calendar_dates.txt geschrieben. Als Gültigkeitsperiode werden GueltigVon und GueltigBis der Kalenderperiode übernommen. In Calendar.txt wird für alle Wochentage das Flag auf 0 gesetzt. In Calendar_dates.txt wird für jeden Tag der Gültigkeitsperiode anhand des Verkehrstages eine Ausnahme vom exception_type 1, das entspricht „Fahrt findet statt” eingetragen.

Tabelle calendar.txt

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
service_id	Ja	Ja	Verkehrstag.Nr
Monday	Ja	Ja	Bitvektor[0] des Fahrtvorkommens
Tuesday	Ja	Ja	Bitvektor[1] des Fahrtvorkommens
Wednesday	Ja	Ja
Thursday	Ja	Ja
Friday	Ja	Ja
Saturday	Ja	Ja
Sunday	Ja	Ja
start_date	Ja	Ja	Netz\Kalenderperiode\GueltigVon
end_date	Ja	Ja	Netz\Kalenderperiode\GueltigBis
Weitere	-	Optional	BDAs von Verkehrstag sind nicht möglich, da kein Visum-VTag zugrunde liegen muss

Tabelle calendar_dates.txt

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
service_id	Ja	Ja	laufende Nr.
Date	Ja	Ja	Datum eines Eintrags aus dem Bitvektor des Fahrtvorkommens
exception_type	Ja	Ja	Bei Jahreskalender: Wert 1 an den Verkehrstagen

Shapes.txt

Pro auftretender „Fahrtausdehnung“ wird nur ein Shape exportiert. Unter einer Fahrtausdehnung ist die an einem konkreten Tag durch die Kombination der dann gültigen Fahrtabschnitte gebildete Ausdehnung einer Fahrt auf ihrer Linienroute zu verstehen.

Der seltene Sonderfall, dass eine Fahrt an einem Tag in disjunkte Abschnitte zerfällt, wird nicht berücksichtigt. In dem Fall werden die Lücken überdeckt. Beispiel: Das Fahrzeitprofil hat die Elemente 1 bis 10. Eine Fahrplanfahrt fährt an einem Tag d von Index 2 nach 4 und von 5 nach 7. Dann erzeugt der Exporter einen Trip mit Service Tag d und Shape bzw. Stop_Times für das Stück von 2 nach 7.

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
shape_id	Ja	Ja	wird generiert
shape_pt_lat	Ja	Ja	diverse
shape_pt_lon	Ja	Ja	diverse
shape_pt_sequence	Ja	Ja	laufende Nr. innerhalb Shape
shape_dist_traveled	Optional	Nein	bei Export auf Basis von Routenpunkten: LRElem.Länge bei Export auf Basis von Zwischenpunkten der Strecken Aufteilung der LRElem.Länge auf sämtliche Teilstücke proportional zum Abstand
Weitere	-	Optional	BDAs von Linienrouten-Verlauf, gegebenenfalls auf alle Zwischenpunkte übertragen

Transfers.txt

Die Übergangsgehzeiten werden analog zu den Stops für die Hierarchie Haltestelle<>Haltepunkt ausgegeben. Es werden Datensätze für alle Relationen von Haltepunkten in einer Haltestelle erzeugt. Die Daten für transfer_type und min_transfer_time werden dabei aus dem übergeordneten Haltestellenbereich des Haltepunktes bezogen und sind deshalb für alle Haltepunkte desselben Haltepunktes gleich. Ist ein Übergang gesperrt und dadurch die Übergangsgehzeit leer, wird für transfer_type der Wert 3 eingetragen. Liegen Gehzeiten für mehrere ÖVFuß-Verkehrssysteme vor, wird der größte Wert übernommen. Ist der Übergang für einzelne Verkehrssysteme gesperrt, für andere offen, wird er als offen betrachtet.

Feldname GTFS	Pflichtfeld	Export aus Visum	Quelle Feld Visum
from_stop_id	Ja	Ja	VonHP
to_stop_id	Ja	Ja	NachHP
transfer_type	Ja	Ja	2 falls Time < inf, sonst 3
min_transfer_time	Nein	Ja	Time (falls < inf)