Table of contents

Search on the page

Frequency-based services in the timetables and in our data formats

Brief Description

All timetable formats have frequency-based services. There are different patterns here:

  • Continuous operation (ski lifts, chairlifts)
  • Basic frequency (e.g. cableways)

It is possible to list all trips as individual trips or to add a rule.

Frequency-based services have implications for the other systems, depending on their implementation in the timetable.

Data and interfaces

We have deliberately avoided the links here and are only providing a list of the formats affected:

  • HRDF
  • GTFS
  • NeTEx
  • SIRI
  • OJP

Functional Description

Frequency-based services have already been implemented in HRDF. However, frequency-based services may NOT be used in NeTEx, HRDF and GTFS if real-time is used (VDV 454 AUS, REF-AUS and SIRI), as otherwise referencing via the sjyid would not work. All frequency-based services that belong to a block without real-time have the same sjyid.

I.e. there may only be two types of frequency-based service runs in HRDF:

  • Type 1: Compact frequency-based runs: In the HRDF data, a frequency service with direction, start time, frequency and number of additional runs. This frequency service has a unique SJYID, no real-time and only fault reports at line level, none at trip level (in the case of fault reports from both the EMS and the DDIP).
  • Type 2: Frequency services broken down into individual journeys: No frequency services in the HRDF data but all individual journeys with a unique SJYID, to which trip-specific error messages and real-time may also be submitted, throughout the system (EMS/OJP/GTFS) as in normal journeys.

We will not discuss type 2 further, as these are ‘normal’ journeys.

For continuous operation (e.g. chairlift), we assume a frequency of one minute.

The compact frequency-based services are now exported to GTFS and NeTEx:

  • These frequency-based services are exported to the new frequencies.txt file during the GTFS export.
  • These frequency services are calculated in the NeTEx export with the structure HeadwayJourneyGroup exported.

GTFS in frequencies.txt exact_times always set to 0 (frequency-based journeys without exact departure times). In GTFS-RT, compact frequency-based services are always suppressed (or they should not have real time at all).

Disruption alerts (VDV 736) only give on the line for compact frequency services.

The following specific features will be implemented in OJP over the next few weeks:

  • For OJPTripInfoRequest to work normally, OJP generates ‘artificial’ sjyid (with a suffix: sjyid-x) under <Service>.
  • These can then be used normally within OJP.
  • If the effective sjyid is to be used, the suffix must be removed.
  • OJPTripInfoReqest with an original sjyid does not work for compact frequency services because the system cannot allocate them (ErrorCondition with ErrorText ‘JourneyRef ambiguous.’ and TRIPINFO_OTHER).
  • For compact frequency services, therefore, an OJPTripRequest should always be made first and then a request with this sjyid-x using OJPTripInfoRequest. Even if an OJPTripRefineRequest includes such a frequency service, sjyid-x must be used for it.

Links

#AutoTranslate