Train Movements: Difference between revisions

From Open Rail Data Wiki
Add Note of number of train entries per packet and Data Columns
Line 19: Line 19:


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 ==
Individual STOMP Packets, can contain between 1 and 32 JSON encoded strings. Each representing a single Train Movement Entry.
Each JSON packet can contain any number of the following columns (depending on available data and message type)
- All Timestamp columns are in Milliseconds
* 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
* 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
* 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 19:42, 23 July 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.

Data Format

Individual STOMP Packets, can contain between 1 and 32 JSON encoded strings. Each representing a single Train Movement Entry.

Each JSON packet can contain any number of the following columns (depending on available data and message type) - All Timestamp columns are in Milliseconds

  • 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
  • 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
  • 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