Skånetrafiken Deployment Configuration
This is a snapshot of Skånetrafiken deployment configuration. At Skånetrafiken we deploy our OTP instances as microservices to a Kubernetes cluster. Some parts of the config are missing due to confidentiality.
Data input files
NeTEx is used for transport data inside Sweden. Each night the system automatically builds new file based on data from SQL database. At the moment those files are not accessible through any public endpoint.
GTFS data is used for traffic inside Denmark. GTFS for danish public transport can be downloaded here. There is some processing applied to the original data so that unnecessary trips are filtered out and ID structure for journeys and stop point / stop places matches with the NeTEx. The modified GTFS is not accessible through any public endpoint either.
Two different OSM files are used:
OSM data is downloaded from
To reduced graph size, only data for southern part of Sweden is used.
OSM data is downloaded from
To reduce graph size, only data for northern part of Denmark is used.
The Azure Service Bus is used to propagate SIRI SX and ET realtime messages to OTP. This is solved through Siri Azure updaters that Skånetrafiken had implemented in OTP. There are separate updaters for SIRI SX and ET. Those updaters are used to provide data for Swedish traffic (NeTEx). Right now, there is no connection to any realtime source for danish traffic (GTFS data).
Except for receiving messages from Service Bus there are two endpoints through which historical ET and SX messages can be downloaded at OTP startup. The updater will first create new subscription on ServiceBus topic and then send request to the history endpoint. It can take some time get a response from the endpoint, so the timeout is set quite high. Once OTP is done with processing of history messages the updater will start querying messages from the subscription.
Once the updaters are done with processing of history messages they will change their status to primed, and the system will start channeling request to this OTP instance. This ensures that no realtime message is omitted and all OTP instance that ran in the cluster does have exact same realtime data. Thi means that no matter which instance the client is hitting it will always get the same search results.
History endpoint contract
updaters section of
router-config.json file provided in this folder. This is an example
configuration for the updaters. The
history configuration is optional. It can be skipped so that
OTP does not fetch any historical messages on startup.
There are two separate endpoints for respectively SX and ET. They are basic GET endpoints with following query parameters:
Those two parameters are used to define time boundaries for the messages.
Both endpoints generate XML response which is an SIRI object containing SX or ET messages. Messages are formatted according to Siri Nordic Profile. Since in SIRI ET standard each messages contains all necessary data, Skånetrafikens implementation of the endpoint returns only the last message for each DatedServiceJourney ID (sending multiple messages would be pointless since they will override each other). The messages are processed in the same order as they came in (in the list) so it would still work to include multiple messages on same DatedServiceJourney as long as they are sorted in correct order and the newest message is the last one in the list.
Matching on stop arrival-times
Normally ET messages are matched with corresponding trips based on ServiceJourney or DatedServiceJourney id from the message. In case OTP was not able to find corresponding trip additional search will be performed based on arrival-times/stop-patterns from the ET message. This feature turned off by default but can be activated by adding fuzzyTripMatching property to updater configuration.