Kurzbeschreibung
Alle Fahrplanformate kennen Frequenzfahrten. Dabei gibt es verschiedene Muster:
- Kontinuierlicher Betrieb (Skilifte, Sesselbahnen)
- Basisfrequenz (z.B. Seilbahnen)
Es ist möglich, alle Fahrten als einzelne Fahrten aufzuführen, oder mit einer Regel zu versehen.
Frequenzfahrten haben je nach Umsetzung im Fahrplan Auswirkungen für die weiteren Systeme.
Daten und Schnittstellen
Wir haben bewusst hier auf die Links verzichtet und geben nur eine Liste der betroffenen Formate an:
- HRDF
- GTFS
- NeTEx
- SIRI
- OJP
Fachliche Beschreibung
In HRDF sind Frequenzfahrten bereits umgesetzt. Allerdings dürfen KEINE Frequenzfahrten in NeTEx, HRDF und GTFS verwendet werden, wenn Echtzeit verwendet wird (VDV 454 AUS, REF-AUS und SIRI), da sonst das Referenzieren über die sjyid nicht funktionieren würde. Alle Frequenzfahrten ohne Echtzeit, die zu einem «Block» gehören, haben dieselbe sjyid.
D.h. in HRDF darf es nur zwei Typen von Frequenzfahrten geben:
- Typ 1: Frequenzfahrten kompakt: In den HRDF-Daten eine Frequenzfahrt mit Richtung, Anfangszeit, Frequenz und Anzahl zusätzlicher Fahrten. Diese Frequenzfahrt hat eine eindeutige SJYID, keine Echtzeit und nur Störungsmeldungen auf Linien-Ebene, keine auf Fahrt-Ebene (sowohl bei Störungsmeldungen vom EMS als auch von der DDIP).
- Typ 2: Frequenzfahrten aufgeschlüsselt in Einzelfahrten: In den HRDF-Daten keine Frequenzfahrten sondern alles Einzelfahrten mit eindeutiger SJYID, zu denen auch fahrt-spezifische Störungsmeldungen und Echtzeit kommen können, im ganzen System (EMS/EFA/OJP/GTFS) wie bei normalen Fahrten.
Auf Typ 2 gehen wir nicht weiter ein, da dies «normale» Fahrten sind.
Bei kontinuierlichem Betrieb (z.B. Sessellift) gehen wir von einem Frequenz von einer Minute aus.
Die kompakten Frequenzfahrten werden neu in GTFS und NeTEx exportiert:
- Diese Frequenzfahrten werden beim GTFS-Export in die neue Datei frequencies.txt exportiert.
- Diese Frequenzfahrten werden beim NeTEx-Export mit der Struktur
HeadwayJourneyGroupexportiert.
In GTFS in frequencies.txt werden exact_times immer auf 0 gesetzt (frequenzbasierte Fahrten ohne exakte Abfahrtszeiten). In GTFS-RT werden kompakte Frequenzfahrten immer unterdrückt (bzw. sie sollten gar keine Echtzeit haben).
Störungsmeldungen (VDV 736) gibt es bei kompakten Frequenzfahrten nur auf der Linie.
In OJP werden innerhalb der nächsten Wochen folgende Besonderheiten umgesetzt:
- Damit OJPTripInfoRequest normal funktioniert, erzeugt OJP «künstliche» sjyid (mit einem Suffix: sjyid-x) unter
<Service>. - Diese können dann innerhalb OJP normal verwendet werden.
- Wenn die effektive sjyid verwendet werden soll, dann muss der Suffix weggenommen werden.
- OJPTripInfoReqest mit einer originalen sjyid funktioniert bei kompakten Frequenzfahrten nicht, da das System das nicht zuordnen kann (ErrorCondition mit ErrorText “JourneyRef ambiguous.” und TRIPINFO_OTHER).
- Bei kompakten Frequenzfahrten sollte daher immer zuerst ein OJPTripRequest gemacht werden und dann mit dieser sjyid-x eine Anfrage mit OJPTripInfoRequest gemacht werden. Auch wenn bei einem OJPTripRefineRequest eine solche Frequenzfahrt enthalten ist, muss für diese die sjyid-x verwendet werden.
Links
- Beschreibung frequencies.txt: Reference – General Transit Feed Specification
#AutoTranslate
