In terms of producing customer information in the public transport sector, there are various use cases involving the data.
Technical description
Delay
We talk of a delay if a train is operating n minutes later than the time scheduled in the official timetable. In reports and statistics, 2, 3, 5 and 6 minutes are the limits used in passenger services differentiating between being punctual and late. The 3-minute limit applies in SBB in line with the Group’s objectives. Details of passenger trains and their commercial stops are published via the Open Data Platform Swiss Public Transport. There is no minimum in-house, even if the systems generally do not display delays of under 3 minutes.
Hysteresis is also an important factor with customer information systems: A new delay announcement will only be produced when the delay has changed by a certain value (target is 30 seconds for the Swiss public transport sector).
Where supplied by the business organisations, the VDV 431 services of the Open Data Platform have this Information.
In VDV 431:
|
1 2 3 4 5 6 7 8 |
<ServiceArrival> <TimetabledTime>2017-07-19T16:21:00Z</TimetabledTime> <EstimatedTime>2017-07-19T16:20:00Z</EstimatedTime> </ServiceArrival> <ServiceDeparture> <TimetabledTime>2017-07-19T16:22:00Z</TimetabledTime> <EstimatedTime>2017-07-19T16:25:00Z</EstimatedTime> </ServiceDeparture> |
In VDV 431 delays cannot be differentiated from forecasts and actual times.
In GTFS-RT:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
"stop_time_update": [ { "stop_sequence": 5, "arrival": { "delay": 60 }, "departure": { <strong>"delay": 60</strong> }, "stop_id": "8506000:0:4", "schedule_relationship": "SCHEDULED" }, |
In GTFS-RT delays cannot be differentiated from forecasts and actual times.
Position data
The precise geo-position of the form of transport is analysed by various business organisations (e.g. using GPS).
This data is not available on the Open Data Platform.
Forecast
Forecasts concern a train’s running times in the future, which are calculated from the train’s current location. This also takes into account conflicts and their currently intended settlements in the next x minutes. A less elaborate method is used to calculate the further progress of the forecast. Not all business organisations are able to provide high-quality forecast data. In these cases, delays are used and updated (i.e. it is assumed that the existing delay will remain).
Where supplied by the business organisations, the VDV 431 services of the Open Data Platform have this Information.
In VDV 431:
|
1 2 3 4 5 6 7 8 |
<ServiceArrival> <TimetabledTime>2017-07-19T16:21:00Z</TimetabledTime> <EstimatedTime>2017-07-19T16:20:00Z</EstimatedTime> </ServiceArrival> <ServiceDeparture> <TimetabledTime>2017-07-19T16:22:00Z</TimetabledTime> <EstimatedTime>2017-07-19T16:25:00Z</EstimatedTime> </ServiceDeparture> |
In VDV 431 forecasts cannot be differentiated from actual times and delays.
In GTFS-RT:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
"stop_time_update": [ { "stop_sequence": 5, "arrival": { "delay": 60 }, "departure": { <strong>"delay": 60</strong> }, "stop_id": "8506000:0:4", "schedule_relationship": "SCHEDULED" }, |
In GTFS-RT forecasts cannot be differentiated from actual times and delays.
Change of platform
The change of platform means that a train arrives at and/or departs from a platform which is different from the one that appears on the poster (Arrival = white poster, Departure = yellow poster).
Platform changes can also have a cascading effect, especially in the case of major operational disruption.
The way in which platform changes are announced varies according to the local situation and resources available:
- At stations where platforms are not published (e.g. stations on single-track routes without any underpass), there is no platform announcement made at all. Therefore, in this case, no platform changes are made.
- Only the actual platform number is transmitted on the visual terminals at the station (general displays, monitors) as well as on the connection screen in the feeder vehicle. The same applies for the platform displays.
- In the online timetable, the actual platform appears along with a symbol referring to the platform change.
- An acoustic signal may be used, depending on the situation, to indicate a platform change.
- In the case of platform changes where the platforms used alternate (e.g. Zurich, Platforms 21/22 and 23/24), no announcement is made. When there is a change of platform affecting a specific platform in a pair of platforms, this is only a platform change from a technical data perspective.
- Where platform changes take place on the same platform (e.g. Bern; Target platform 1; Actual platform 2), a limited announcement is made (e.g. reference is made to it while announcing the train’s arrival).
- In the case of other platform changes where both platforms are linked by only an underpass, information about the platform change is provided on a cyclical basis.
Where supplied by the business organisations, the VDV 431 services of the Open Data Platform have this Information.
In VDV 431:
|
1 2 3 4 5 6 7 8 |
<PlannedBay> <Text>2</Text> <Language>DE</Language> </PlannedBay> <EstimatedBay> <!-- Gleis als EstimatedBay --> <Text>3</Text> <Language>DE</Language> </EstimatedBay> |
In GTFS-RT:
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "stop_sequence": 2, "arrival": { "delay": 60 }, "departure": { "delay": 60 }, "stop_id": "8501605:0:5", "schedule_relationship": "SCHEDULED" }, |
Actual times
A VM actual time (VM stands for a transport journey) is the effective time which an operating means of transport has or had at a defined point. We are generally talking about arrival, departure and passage time. Apart from the time, other information is relevant (e.g. ID for the transport journey). Often the VM actual time is just written as “actual time”. There is a differentiation between primary and secondary actual time.
Primary actual time
Primary VM actual time is the time actually measured at a location based on a train passing. The secondary actual time can be calculated from this time.
Secondary actual time
The secondary VM actual time is extrapolated from a primary VM actual time. For example, the passage time is measured at the entry signal of a station (=primary VM actual time), then an additional n seconds is counted from there to obtain the stop time at the platform (secondary VM actual time). This is necessary as a later time is very often much more important for operations, but there is no time measurement carried out there. Strictly speaking, this is a forecast time rather than an actual time as it is not directly recorded but is extrapolated from another time. Therefore, a primary actual time for a point which has been passed is always regarded as a secondary actual time. Once the primary actual time is established, this can be used to calculate the secondary actual time.
Attempts are still made to obtain, to a certain extent, better information to be used for customer information, based on certain events occurring on the vehicles: actual opening and closing of the doors.
More information about actual data on the Open Data Platform is available here.
In VDV 431:
|
1 2 3 4 5 6 7 8 |
<ServiceArrival> <TimetabledTime>2017-07-19T16:21:00Z</TimetabledTime> <EstimatedTime>2017-07-19T16:20:00Z</EstimatedTime> </ServiceArrival> <ServiceDeparture> <TimetabledTime>2017-07-19T16:22:00Z</TimetabledTime> <EstimatedTime>2017-07-19T16:25:00Z</EstimatedTime> </ServiceDeparture> |
In VDV 431 the actual times cannot be differentiated from forecasts and delays.
In GTFS-RT:
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "stop_sequence": 2, "arrival": { "delay": 60 }, "departure": { "delay": 60 }, "stop_id": "8501605:0:5", <strong>"schedule_relationship": "SCHEDULED</strong>" }, |
In GTFS-RT the actual times cannot be differentiated from forecasts and delays.
Event information
An event can be a planned or unplanned action affecting operation, which is reported and which is very likely to be related to installations and vehicle problems and primary deviations. An event is also part of planning actions and is created and closed during the process by the controller. It initially becomes apparent when the infrastructure becomes restricted on the route and at nodal points, as well as in the nodal point itself due to disrupted connections and failures.
An event report contains the information provided to passengers about planned or unplanned events which will affect train and terminal connections.
Examples of planned events include pre-announced events (sporting events or music concerts, exhibitions, celebrations etc.). On the other hand, unplanned events are, for instance, events held at short notice, accidents, natural disasters etc.
The Open Data Platform currently has no information about events.
Failure
The term “failure” is used for when trains break down or stop running.
Where supplied by the business organisations, the VDV 431 services of the Open Data Platform have information about failures.
In VDV 431:
|
1 2 3 4 |
<Service> ... <Cancelled>true</Cancelled> </Service> |
In GTFS-RT:
|
1 2 3 4 5 6 7 8 9 10 |
{ "id": "4.TA.1-28-j17-1.2.H", "trip_update": { "trip": { "trip_id": "4.TA.1-28-j17-1.2.H", "start_time": "18:04:00", "start_date": "20170719", "schedule_relationship": "CANCELED", "route_id": "1-28-j17-1" } |
Partial failure
A partial failure occurs when the form of transport breaks down on a leg of a transport route.
In VDV 431:
|
1 2 3 4 5 6 |
<ThisCall> <CallAtStop> ... <NotServicedStop>true</NotServicedStop> </CallAtStop> </ThisCall> |
In GTFS-RT:
|
1 2 3 4 5 6 7 |
{ "stop_sequence":7, "arrival":{"delay":0}, "departure":{"delay":0}, "stop_id":"8505213:0:2", "schedule_relationship":"SKIPPED"}, ... |
Arrangement
This involves additional journeys which were not provided for in the timetable.
Where supplied by the business organisations, the VDV 431 services of the Open Data Platform have this Information.
In VDV 431:
|
1 2 3 4 |
<Service> ... <Unplanned>true</Unplanned> </Service> |
In GTFS-RT:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "id": "4.TA.1-28-j17-1.2.H", "trip_update": { "trip": { "trip_id": "4.TA.1-28-j17-1.2.H", "start_time": "18:04:00", "start_date": "20170719", <strong> "schedule_relationship": "Added",</strong> "route_id": "1-28-j17-1" } .... } |
Formation change
The formation change involves giving a train a formation which is different to the one in the plan.
Formation: Individual vehicles making up a train, arranged in the train’s direction of travel. A formation also comprises a sequence of wagons facing the direction of travel (therefore, a turning train has a different formation after turning to the formation it had before). Formation also includes special information based on DDA, classes, dining car etc.
The Open Data Platform does not currently have a mechanism for formation changes.
Diversion
Diversions involve the course of the journey being changed (e.g. due to a construction site).
The Open Data Platform currently does not support diversions.
Unscheduled stop
If a train makes a stop which was not included in the timetable, we refer to this as an unscheduled stop. For instance, the InterCity train stops in Olten, even though it should actually pass through.
An unscheduled stop is technically the equivalent of a diversion.
Transit
Transit means that the train does not stop at a planned stop.
A transit is technically equivalent to a partial failure.
Change to offer
An offer, such as a quiet coach, bistro is not available as planned.
This use case is not implemented on the Open Data Platform.
Further information
- Github with OJP test cases: https://github.com/openTdataCH/ojp-soapui-tests