Difference between revisions of "Train Movements"

From Open Rail Data Wiki
Jump to navigation Jump to search
m (Added a link to the TRUST message process)
m
Line 1: Line 1:
== Overview ==
 
 
=== What is this feed? ===
 
 
 
The Train Movements feed contains data from Network Rail's [http://en.wikipedia.org/wiki/TRUST TRUST] system.  This reports on the progress of trains along their journey.
 
The Train Movements feed contains data from Network Rail's [http://en.wikipedia.org/wiki/TRUST TRUST] system.  This reports on the progress of trains along their journey.
  
 
There's a fuller [[TRUST Message Process|description of the process]] available.
 
There's a fuller [[TRUST Message Process|description of the process]] available.
  
=== Topics ===
+
= Message Topics =
  
Messages are available on TOC-specific topics, as well as an 'ALL TOCs' topic.
+
Train movement messages are available through TOC-specific topics, as well as an 'all TOCs' topic.
  
Individual TOC topics are named TRAIN_MVT_XX_TOC, where 'XX' represents the Network Rail 'business code' from the [[TOC Codes]] page.  For example, CrossCountry has business code 'EH', and its topic is TRAIN_MVT_EH_TOC.
+
Individual TOC topics are named TRAIN_MVT_''XX''_TOC, where ''XX'' is the Network Rail business code from the [[TOC Codes]] page.  For example, CrossCountry has business code 'EH', and its topic is TRAIN_MVT_EH_TOC.
  
There are other topics which contain aggregated data from multiple TOCs:  
+
Other topics which contain aggregated data from multiple TOCs:  
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 29: Line 25:
 
|}
 
|}
  
=== Message types ===
+
== Message types ==
  
 
The feed contains eight message types, all in JSON format:
 
The feed contains eight message types, all in JSON format:
Line 46: Line 42:
 
'''NOTE''' - A [[Train Activation]] message will always be the first message to be received for a train, after which any of the other message types may be received.
 
'''NOTE''' - A [[Train Activation]] message will always be the first message to be received for a train, after which any of the other message types may be received.
  
=== Format ===
+
== Format ==
  
 
Each message is represented as a JSON hash with two keys - 'header' and 'body'.  Zero or more of these messages is sent out in a JSON list, either every five seconds or when there are 32 messages to be sent.  It is perfectly legitimate to receive an empty array.
 
Each message is represented as a JSON hash with two keys - 'header' and 'body'.  Zero or more of these messages is sent out in a JSON list, either every five seconds or when there are 32 messages to be sent.  It is perfectly legitimate to receive an empty array.
  
 
All timestamp values are in milliseconds since the UNIX epoch.
 
All timestamp values are in milliseconds since the UNIX epoch.

Revision as of 09:01, 17 May 2013

The Train Movements feed contains data from Network Rail's TRUST system. This reports on the progress of trains along their journey.

There's a fuller description of the process available.

Message Topics

Train movement messages are available through TOC-specific topics, as well as an 'all TOCs' topic.

Individual TOC topics are named TRAIN_MVT_XX_TOC, where XX is the Network Rail business code from the TOC Codes page. For example, CrossCountry has business code 'EH', and its topic is TRAIN_MVT_EH_TOC.

Other topics which contain aggregated data from multiple TOCs:

Topic name Description
TRAIN_MVT_ALL_TOC All train operating companies
TRAIN_MVT_PASSENGER_TOC All passenger train operating companies
TRAIN_MVT_GENERAL Change of Identity messages for freight trains

Message types

The feed contains eight message types, all in JSON format:

Delay Attribution-related messages are not available.

NOTE - A Train Activation message will always be the first message to be received for a train, after which any of the other message types may be received.

Format

Each message is represented as a JSON hash with two keys - 'header' and 'body'. Zero or more of these messages is sent out in a JSON list, either every five seconds or when there are 32 messages to be sent. It is perfectly legitimate to receive an empty array.

All timestamp values are in milliseconds since the UNIX epoch.