Skip to content

Departure/arrival display

The departure/arrival display is available as an Open Service (API). The departure/arrival display is described in VDV 431 – “StopEvent” service.

(Departure/arrival Display)

Technical description

One of the main applications using customer information is to create station boards/stop displays or display activities at a point or by a point (e.g. when arriving at a stop). Depending on the use case, information about arrivals and departures is of interest.

This platform uses the departure/arrival display to supply the required data.

A stop must be chosen from the station list as a work basis.

It should be noted that no metastations are used in this case. In other words, the following stops should be used, for instance, for the Point of Interest Bern, Wankdorf:

  • 8516161, Bern Wankdorf
  • 8590129, Bern Wankdorf, Bahnhof
  • 8595543, Bern Wankdorf, Bahnhof Nord

Key concepts

  • Stops: DiDok or stop datasets can also be referred to for this.
  • Journeys: A journey involves transporting customers along a particular route, according to a particular timetable connection, by a particular means of transport, at a particular time, in a particular direction.
  • Timetable: A timetable determines the progress of a means of transport in public short- and long-distance passenger traffic and in railway freight traffic. The information required for this includes train numbers, days of operation, routes, arrival, departure and passing times at the stops, as well as permissible speeds in individual sections of the route.
  • Forecasts: 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.
  • Means of transport (VM): Either used synonymously with vehicles (train, boat, tram, bus) from different carriers or in the sense of a “transport system” (public transport etc.).
  • DateTime in Response: This is always based on Zulu time (i.e. UTC). It means adding two hours in summer and one hour in winter.

Technical aspects

API Explorer

Authorisation and Open Services

An API keyword is required to access this API. It can be obtained via the Developer Portal. The token must also be sent in the HTTP header as “Authorization”.

Access URL


(NB: No “/” at the end)

With the Authorization header and Content type= “text/XML” or “application/XML”

Authorization header

Sample request

This request is transferred as body.

Explanatory notes on the elements in the request

The request has two key elements:

Name Mandat? Description Example
StopPointRef Yes(*) A stop code from DiDok or the stop list  8507000
DepArrTime No contains the arrival and departure time (see also the StopEventType parameter). Requests can only be made -1 to +24 hours. If the element is missing, the current time applies. Zulu time is not required in this case.

The seconds must be specified.

Params No The request’s parameters See table below

The other parameters are:

Name Mandat? Description Example
NumberOfResults No Default 40, Maximum 40 20
StopEventType Yes There are two valid values: departure/ arrival. departure
IncludePreviousCalls No The stops before the requested stop should be included: true/false

Default true

IncludeOnwardCalls No The stop after the requested stop should be included: true/false

Default true

IncludeRealtimeData No Real-time data should also be transferred: true/false

Default false


Extracting and explaining a response

The response has the following basic structure

A “StopEvent” contains the following elements:

  • PreviousCall: Stops before the current stop
  • ThisCall: Current stop
  • OnwardCall: Next stop
  • Service: Information about journey.

“MoreData” is always false, as all the data is supplied.

The whole journey is always supplied from the starting stop to the terminus.

PreviousCall / ThisCall / OnwardCall



“EstimatedTime” is currently only available for “ThisCall”. In order to request real-time data for the whole journey, the “TripInfoRequest” service can be used via the “JourneyRef” from the “Service” element.


Name Mandat? Description Example
StopPointRef Yes A stop code  
TimetabledTime Yes  This is the time according to the scheduled timetable. NB: Zulu time. 2016-08-18T02:54:00Z
Estimatedtime No Time based on forecast. NB: “Estimatedtime” is only available for journeys which have real-time data and only for “ThisCall”. “Estimatedtime” can be the same as “TimetabledTime”, if no deviation is expected.

(Coming Soon) In the case of sections of the journey (“PreviousCall”) in the past, the last forecast or actual data applies.

PlannedBay No Contains the planned platform according to the timetable.  
EstimatedBay No Contains the forecast platform.  12A
StopSequenceNumber Yes All stops are numbered consecutively. 3


The “Service” structure is described here: Service (VDV 431)


The response will contain an “ErrorMessage” if there were problems executing the request:



The following information is vital for external developers:

  • Stop in the form of a DiDok number. This means that the DiDok or station file needs to be parsed and processed. The DiDok number can be obtained from a search according to name or also coordinates.
  • Any metastops are ignored.
  • The time and arrival or departure can be provided.
  • A specific request based on a stop (synonym: platform, post, kerb) cannot be submitted.

Special situation Postauto AG

The timetable data for PAG is supplied under business organisation 801, i.e. Postauto Switzerland. It contains lines which, although they are different (from different regions and carriers), have the same line numbers This includes a couple of stops (DiDok numbers) which are called at by two intersecting lines. This situation means that in the TRIAS interfaces (VDV431), all the destination texts are mixed up in the DestinationText data field. This, in turn, results in a false output. As restructuring is being carried out with the implementation of KUBUS (official railway timetable) and the import of HRDF data into the Open Data system, it does not make any economic sense at the moment to make an extensive adjustment to the import process (using the unique line ID from PAG in the *I RN line = PlanBox line number, previously PLADIS number).


When importing the HRDF data, the “train number instead of journey key” flag is disabled in DIVA on the relevant line. This changes the JourneyRef (journey number) on the TRIAS interfaces (GTFS is not affected). The data fields used to represent the line (LineRef or PublishedLineName) are not affected by this and are output as before.

More detailed information