Train Movements: Difference between revisions

From Open Rail Data Wiki
← Older editNewer edit →
m →‎Lifecycle: More link fixing
No edit summary
Line 20: Line 20:
One point to note - the [[Change of Identity]] message type is rarely seen.  This is used when a train running under one class (e.g. a Class 4 freight with a train identity starting 4---) must run under a different class for some reason - usually because it must run at a lower speed due to the type of load it is carrying.
One point to note - the [[Change of Identity]] message type is rarely seen.  This is used when a train running under one class (e.g. a Class 4 freight with a train identity starting 4---) must run under a different class for some reason - usually because it must run at a lower speed due to the type of load it is carrying.


== Data Format ==
== Format ==


Individual STOMP Packets, can contain between 1 and 32 JSON encoded strings. Each representing a single Train Movement Entry.
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 JSON packet can contain any number of the following columns (depending on available data and message type).
All timestamp values are in milliseconds since the UNIX epoch.
Each packet consists of a Header and a Body.
 
- All Timestamp columns are in Milliseconds
 
=== Header ===
* msg_type as above
* source_dev_id
* user_id - for when a message is not added Automatically this represents who initiated the message
* original_data_source - known values
** SDR
** SMART
** TOPS
** TRUST DA
** TSIA
* msg_queue_timestamp,
* source_system_id, normally TRUST
 
=== Body ===
* train_id
* event_type, is the Train Arriving or Departing, blank for Activation/other messages that are not 0003
** ARRIVAL
** DEPARTURE
* gbtt_timestamp
* original_loc_stanox
* planned_timestamp, the timestamp the event is supposed to occur
* timestamp_variation, number of minutes between actual time and reporting time, (always positive, refer to variation_status for early/late)
* original_loc_timestamp,
* current_train_id, used when the the msg_type is 0007, used to link between the old and new train_id
* delay_monitoring_point
* next_report_run_time
* reporting_stanox, the place reporting the update, but STANOX code,
* actual_timestamp, the timestamp the event occurred
* correction_ind
* event_source,
** AUTOMATIC
** MANUAL
* train_file_address
* platform, the platform the train is using, (not always populated)
* division_code
* train_terminated, has the train completed this run meaning the end of the train running under its current train_id, it then deactivates
* offroute_ind, is the train running off schedule
* variation_status, qualifier for timestamp_variation
** EARLY
** LATE
** OFF ROUTE
** ON TIME
* train_service_code, the schedule reference index
* toc_id
* loc_stanox, the Stanox/location of the train
* auto_expected
* direction_ind,
** UP
** DOWN
* route
* planned_event_type, the kind of event that was expected
** ARRIVAL, the train arrived somewhere
** DEPARTURE, the train left somewhere
** DESTINATION, the train has reached the end of the line, All Change
* next_report_stanox, STANOX of the next expecte reporting location
* line_ind

Revision as of 10:06, 1 August 2012

Overview

The train movements feed contains messages produced by TRUST. These messages are one of eight types, all in JSON format:

Lifecycle

Before any action can be taken on a train, the schedule must be activated. An Activation message will be received, which will link a schedule to a 10-character train identity. This identity is referenced in all other message types, and there is no need to calculate it manually.

A train may be cancelled (either entirely or from a particular calling point onwards) through a Train Cancellation message, or start from a location other than the originating location through a [Change of Origin] message. A train may be reinstated after cancellation through a Train Reinstatement message.

One point to note - the Change of Identity message type is rarely seen. This is used when a train running under one class (e.g. a Class 4 freight with a train identity starting 4---) must run under a different class for some reason - usually because it must run at a lower speed due to the type of load it is carrying.

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.

Retrieved from "https://wiki.openraildata.com/index.php?title=Train_Movements&oldid=102"