LTP and STP Processes

From Open Rail Data Wiki

A train schedule is identified by a UID. These identify a group of schedules within a CIF file.

Planning Process

The industry has two planning processes: Long Term Planning, and Short Term Planning.

LTP Process

As far out as D-67 (or 67 weeks before the day the train runs), the LTP timetable starts to be planned. At D-26, Network Rail issue the new LTP timetable electronically - this results in several thousand additional schedules being produced per day. Changes may still occur after D-26, and will usually be variation requests to cope with engineering work or altered train operations.

STP Process

The STP process begins at TW-30 (or 30 weeks before the train runs), and is targeted to be complete by TW-12, the deadline for the Informed Traveller timetable.

Schedule data

Schedules have one of four value in the STP Indicator field:

Indicator Name Abbreviation Description
P Permanent (LTP) WTT A base schedule created as part of the LTP process
O Overlay (LTP) VAR A variation to a schedule created as part of the LTP process
C Cancellation (LTP) CAN A planned cancellation of an LTP schedule - this means the schedules does not apply, not that it is cancelled - see Planned Cancellations
N Short-Term Planned (STP) STP A schedule created as part of the STP process

LTP schedule UIDs should contain one or more records with indicator 'P', and zero or more with indicators 'O' or 'C'. STP schedule UIDs should contain one or more records with indicator 'N'. There are some circumstances where a UID may contain both LTP and STP records - this can be down to an STP schedule being converted in to an LTP schedule in the next timetable period.

Determining which schedule applies

Where there is more than one schedule with a UID valid on a particular day - such as when a WTT schedule is overlaid by a VAR or CAN schedule, the 'O' or 'C' schedule takes priority over the 'P' schedule. A maximum of one overlay should apply on any one particular day.

An easy way to calculate this programatically is to look for all schedules under the selected UID, whose validity covers the date in question. If there is one schedule, this is the schedule that applies. If there are two schedules, the schedule with the 'O' or 'C' indicator is the one that applies.

Let's look at an example for UID A12345. There are two schedules:

  • WTT schedule valid on Monday, Tuesday, Wednesday, Thursday and Friday from Monday 7th January 2013 to Friday 11th January 2013
  • CAN schedule valid on Wednesday and Thursday from Wednesday 9th January 2013 to Thursday 10th January 2013

The result of overlaying these two schedules is that:

  • The WTT schedule is valid on Monday 7th, Tuesday 8th and and Friday 11th January 2013
  • The CAN schedule is valid on Wednesday 9th and Thursday 10th January 2013

If retrieving all the schedules for UID A12345 on Wednesday 9th January 2013, we'll see two schedules - the WTT schedule and the CAN schedule. Picking the schedule with the lower alphabetical STP indicator will select the CAN schedule, which is the schedule that applies on the day.


Network Rail Open Data Feeds
Data Feeds About the Feeds Account States Durable Subscriptions Example Code ( PHP / C# / Java / Ruby / Node.js) • Advanced UsesFAQ Release Notes
RTPPM RTPPM Feed
Train Movements Train Movements Feed Train Activation Train Cancellation Train Movement Train Reinstatement Change of Origin Change of Identity Change of Location TSPEED Field Planned Cancellations Cancellation Codes
TD TD Feed C-Class Messages S-Class Messages Train Describers TD Berths
VSTP VSTP Feed
TSR TSR Feed Route Codes
SCHEDULE SCHEDULE Feed TIPLOC Records Schedule and Location Records Association Records CIF Codes How Scheduling Works Allowances
Reference Data Reference Data Feed TOC Codes CIF Codes Delay Attribution Codes Identifying Locations (STANOX, TIPLOC, NLC and 3-Alpha Codes) STANOX Geographical Areas Train Planning data (BPLAN)