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.
- 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.
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.
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:
|
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 |
| DURCHFAHRT_TF | Boolean | true/false (null=false). When the means of transport drives straight through, it does not halt at this planned stop. | false |
Example
An extract is taken from the file below.
BETRIEBSTAG;FAHRT_BEZEICHNER;BETREIBER_ID;BETREIBER_ABK;BETREIBER_NAME;PRODUKT_ID;LINIEN_ID;LINIEN_TEXT;UMLAUF_ID;VERKEHRSMITTEL_TEXT;ZUSATZFAHRT_TF;FAELLT_AUS_TF;BPUIC;HALTESTELLEN_NAME;ANKUNFTSZEIT;AN_PROGNOSE;AN_PROGNOSE_STATUS;ABFAHRTSZEIT;AB_PROGNOSE;AB_PROGNOSE_STATUS;DURCHFAHRT_TF 4.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8500285;Flumenthal;04.11.2016 17:26;;UNBEKANNT;04.11.2016 17:26;;UNBEKANNT;false 04.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8500286;Attiswil;04.11.2016 17:28;;UNBEKANNT;04.11.2016 17:28;;UNBEKANNT;false 04.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8500287;Wiedlisbach;04.11.2016 17:31;;UNBEKANNT;04.11.2016 17:31;;UNBEKANNT;false 04.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8500288;Oberbipp;04.11.2016 17:33;;UNBEKANNT;04.11.2016 17:33;;UNBEKANNT;false 04.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8500289;Buchli;04.11.2016 17:34;;UNBEKANNT;04.11.2016 17:34;;UNBEKANNT;false 04.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8500211;Niederbipp;04.11.2016 17:37;;UNBEKANNT;04.11.2016 17:37;;UNBEKANNT;false 04.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8518690;Niederbipp Industrie;04.11.2016 17:38;;UNBEKANNT;04.11.2016 17:38;;UNBEKANNT;false 04.11.2016;85:81:9456:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9456;R;;R;false;false;8500212;Oensingen;04.11.2016 17:41;;UNBEKANNT;;;PROGNOSE;false 04.11.2016;85:81:9457:000;85:81;ASM-snb;Aare Seeland mobil (snb);Zug;9457;R;;R;false;false;8500212;Oensingen;;;PROGNOSE;04.11.2016 18:17;;UNBEKANNT;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.