Actual data

The actual data contains the journeys which have actually been completed during the last or relevant day. The actual data is either the effective actual data or last forecast received by the customer information system. If no real-time information was available, the relevant journey is missing.

This data is found in the dataset: Actual Data

Technical description

The actual data concerns the journeys which have actually been completed in terms of customer information. This means, for instance, when the vehicle actually arrived at the stop or at which platform it arrived. Logically speaking, this information is only available after the service has been delivered (e.g. when the door-opening mechanism was triggered), therefore only at that moment or afterwards. In this respect, a forecast cannot be regarded as actual data. But, as actual data is only really available in very few cases (e.g. when the vehicle has actually left the stop, this information is removed from the display at the correct time), this information, as available in the customer information systems, is only of limited quality. Frequently, the last forecast is used as the actual journey.

However, from a statistical perspective, this downstream information is interesting. For example, evaluations can be produced about punctuality, regularity or connection quality. These evaluations should be interpreted from the perspective that this does not involve any real actual data, but tends to involve the last known forecast data or just simply target data. For instance, at some stations, departure times are calculated only on the basis of the arrival time and stop time.

Key concepts

• Forecast: Estimating times in the future using the transport company’s control system. See section “Forecast status“
• Actual journey: The actual times from the transport company’s control system.
• A journey must be assembled using the journey reference itself. A line exists in the file for each stop in every journey.
• Target times: In principle, target times are commercial times. If these are missing, operating times can be used to fill the target data in individual cases. This is the case, for example, with commercial stops only for boarding for the arrival time and with commercial stops only for alighting for the departure time.

Dealing with specific special cases

• Journey failure: If a journey planned in the timetable is not completed, we refer to this as a failure. Failures can be planned or are necessary due to current events.
• Partial journey failure: It is possible that a journey is not fully completed, e.g. because the train had to stay in Olten due to a problem.
• Journey diversion: It is possible for a journey to be partially diverted via another route.
• Additional journey: If a journey is made which was not included in the timetable, we refer to this as an additional journey.

Forecast status

The forecast status can assume various values; according to VDV 454, the following applies:

• Forecast: (default) The time specification is a forecast time for the stop (generally in the future).
• Real: The time given is the actual arrival/departure time at the (already past) stop.
• Estimated: This value is set if the actual arrival/departure time is not available and must be replaced by a plausible estimate.
• Unknown: This value is set if no forecast or actual arrival/departure time is known for this and all previous stops on this journey.

Technical aspects

This section explains the technical structure of the file. It is a CSV file.

Data structure

The CSV contains the following fields:

Field name	Type	Description	Example
BETRIEBSTAG	DD.MM.YYYY	This is the relevant day of operation when the journey took place.	20.8.2016
FAHRT_BEZEICHNER	String	Corresponds to JourneyID Local services: [UIC country code]:[Business organisation number]:[Journey reference] Rail services: [UIC country code]:[Business organisation number]:[Form of transport number]:[Extended reference] In VDV 431 JourneyRef is then used.	85:81:20920:001
BETREIBER_ID	String	Business organisation number (Switzerland) or “Transport company code” (foreign). The country code comes in front.	85:81
BETREIBER_ABK	String	Taken from the BETREIBER_ID information via the transport company’s master data	THURBO
BETREIBER_NAME	String	Taken from the BETREIBER_ID information via the transport company’s master data	Aare Seeland mobil (snb)
PRODUKT_ID	Enum	Product types are used within the interface to classify quality features for journeys. In public transport in Switzerland, the means of transport category (VM-Gattung) is transferred as a Product_ID (e.g. ship, bus, train etc.). When specifying the Product_ID, it must be ensured by the relevant data-generating transport company that the category of means of transport provided tallies with the category of means of transport used in the target timetable summary for public transport in Switzerland (INFO+). A list of the means of transport categories supported in INFO+ may be requested for this purpose from the INFO+ specialist unit.	Train
LINIEN_ID	String	Line_ID is a purely technical key which is not used for the customer display. Local services: [UIC country code]:[Business organisation number]:[Technical line key] Rail services: [Journey number] (Journey number can be take from FAHRT_BEZEICHNER)	85:65:20920 (Local services) or 20920 (Rail services)
LINIEN_TEXT	String	Line_Text is customer-related and is output, if necessary, on the relevant displays.	S29
UMLAUF_ID	String	If the transport company transfers circuits, the circuit ID is completed in this case.	BUS.391 121121
VERKEHRSMITTEL_TEXT	String	Textual description of the form of transport	S
ZUSATZFAHRT_TF	Boolean	true/false (if null=false). Is set to true if it is an additional journey.	false
FAELLT_AUS_TF	Boolean	true/false (if null=false). Is set to true if the journey fails.	false
BPUIC	Numerical	Stop (in BPUIC format). String E.g. from DiDok. Stop’s ID. Basic format UIC country code (2-digit) e.g. 85 UIC stop code (5-digit): e.g. 03000 stop code (optional): e.g. 02 gives: 850300002	8506038 (rail) or also 850300002 (local)
HALTESTELLEN_NAME	String	Textual representation of the stop. This is used in the form supplied in the original data from the transport company and is not extracted from BPUIC via BP master data. This means that there can be no discrepancies with the official name in the DiDok list.	Winterthur Wallrüti
ANKUNFTSZEIT	DD.MM.YYYY HH24:MI	Target arrival time at the stop, rounded up to minutes.	12.10.2016 05:40
AN_PROGNOSE	DD.MM.YYYY HH24:MI:SS	Arrival forecast without any rounding. NB: A transport company has possibly already carried out rounding itself, which is why the seconds are not possibly available.	12.10.2016 05:41:32
AN_PROGNOSE_STATUS	Enum	Possible values: UNKNOWN (No forecast and actual times available for this and all previous stops) Empty (=FORECAST) FORECAST (Arrival forecast) ESTIMATED (estimated actual arrival time) REAL (effective actual arrival time)	FORECAST
ABFAHRTSZEIT	DD.MM.YYYY HH24:MI	Target departure time at the stop, rounded up to minutes.	12.10.2016 05:40
AB_PROGNOSE	DD.MM.YYYY HH24:MI:SS	Departure forecast without any rounding. NB: A transport company has possibly already carried out rounding itself, which is why the seconds are not available.	12.10.2016 05:41:32
AB_PROGNOSE_STATUS	Enum	Possible values: UNKNOWN (No forecast and actual times available for this and all previous stops) Empty (=FORECAST) FORECAST (Departure forecast) ESTIMATED (estimated actual departure time) REAL (effective actual departure time)	UNKNOWN
DURCHFAHRT_TF	Boolean	true/false (null=false). When the means of transport drives straight through, it does not halt at this planned stop.	false

How do you identify that no real-time data has been transferred?

If the forecast status is “UNKNOWN” and the relevant times are empty, the forecast and actual times could not have been transferred at the stop. Other data, such as platform changes etc., cannot contain the data actually generated either.

Special effects and their causes

Because of the special way in which data is generated, some special effects can occur. To provide a better understanding, the reasons for some of these special effects are presented below. These are small matters which arise from the nature of how things are investigated at the relevant transport companies:

• A train has departed from the stop before its arrival: Records with AB_PROGNOSE_STATUS “FORECAST” and/or AN_PROGNOSE_STATUS “FORECAST” receive the actual times based on the forecast times supplied by SBB’s operational planning system if the stops are part of the SBB, BLS and SOB normal-gauge network. Inaccuracies are possible in this situation and are insignificant. Lines with AB_PROGNOSE_STATUS “ESTIMATED” and/or AN_PROGNOSE_STATUS “ESTIMATED” are based on the actual times estimated from the control systems. In addition, the situation may arise if, when a “request stop” is made, the train travels through with stopping, thereby making up valuable time. The control system always uses the technical times for station arrival and departure (e.g. on the axle counter or insulation) and calculates the precise stop and arrival time based on the increases and decreases recorded. If the train now travels at a good speed, as no “request” to stop was made, through the station without stopping, the forecast calculation will be “false” instead. If a train travels through without stopping, what matters to us, rather from a quality perspective, is the calculated time of arrival – for instance, if there is customer feedback about punctuality.
• A train departs from the stop before the departure time specified in the timetable is reached: In this case, a differentiation must be made as to whether such a record has AB_PROGNOSE_STATUS “FORECAST” or “ESTIMATED”. We assign “FORECAST” status to stops where no control system data is available (the train has not yet reached the stop or has carried on through). Consequently, greater inaccuracies can occur here. The control system provides these forecasts for stops on the SBB, BLS and SOB normal-gauge network. The system also includes its calculated actual times in the production plans. But this data is not used. If, in such cases, the difference is fairly small, this is negligible. The status “ESTIMATED” is registered where control system data is available. In this case, the actual departure time is taken from the time stamp of the control system events “ZN_AbfahrtEreignis”. At such stops, the control system should not actually notify us of the train’s departure before the departure time specified in the timetable because the crucial main signal for this (generally the exit signal) is only given after departure. Where this occurs on a chronically frequent basis, the causes are investigated.
  • Arrival: The time stamp for the control system event “ZN_EinfahrtEreignis” has a configured value added for each route (average which is required for the journey from the recording point to the edge of the platform).
  • Departure: The time stamp for the control system event “ZN_AbfahrtEreignis” is adopted.
  • There should be no records with this expression and AB_PROGNOSE_STATUS “ESTIMATED” and AN_PROGNOSE_STATUS “ESTIMATED”. However, this situation cannot be excluded completely for the following reasons:
    • Where the control system notifies us of the departure far too early (Baldegg Kloster), this observation is understandable.
    • The average time saved for each route for covering the route, from the crucial signal to arriving at the edge of the platform, is also used to trigger connection announcements at stations. Therefore, these times are often configured too high beforehand so that connection announcements are not started too early.
    • The actual arrival time is also transferred via VDV to transport companies to enable them to make decisions about and ensure smooth connections. The above practice also applies to these cases.
  • Where the above points do not apply, the time stored for each route has often been checked less, which means that it may be too high in some cases. However, this is not, generally speaking, relevant to backing up customer information and to the above points made.
• The departure time of the train at the stop is earlier than its arrival time The arrival and departure times according to the timetable in the Actual file are supplied by INFO+ (timetable data collection CH) and are forwarded without any changes being made. However, there is a special feature about the arrival times of the IR 2310 in Altdorf and Sisikon. This train only stops at both these stations to let passengers board. Therefore, we automatically adopt the operational arrival time, which is one minute later than the commercial time. The situation is somewhat more complicated with the TGV 9272: INFO+ receives for this train the Swiss part of NeTS and the French part of EuroEVA. While NeTS gives the arrival time as 19:14, EuroEVA gives the departure time as 19:13. It is extremely complicated with the TER 96523: INFO+ receives data from NeTS for this train with the Swiss number 96523 for the Bellegarde – Geneva section and from EuroEVA with the French number 96522 for the entire Lyon-Part-Dieu – Geneva route. NeTS gives on 17.08.2016 a departure time of 21:59 for Bellegard and EuroEVA gives an arrival time of 22:02. In both cases there are implausible times at the border intersection point. The reason for this ultimately is that one of the datasets involved provides a time which is not valid on this day.

Using stops which do not appear in the DiDok list

At present, only Actual data is output for stops in Switzerland. It begins with 85. A couple of stops in the actual journey in the regions on either side of the border may not be available. International journeys are truncated at the border. This creates a situation where the file contains journeys with exactly one stop.

 

Further information

–