Darwin provides schedule information when a train is activated, or when new schedule, or changes to an existing schedule, are received.
Schedules cover the complete journey of a single train, and are always sent in full. Changes replace any previous version of a schedule that may have been received. Individual schedule locations may also be deleted within Darwin. Locations will not be marked as deleted, other than being absent from a new schedule.
Darwin identifies trains by RID, whereas TRUST identifies trains by a 10-character identity.
As part of an update, Darwin provides schedules when a new schedule or schedule change becomes known to Darwin, or when the schedule is activated by TRUST.
Schedule changes and new schedules are always transmitted in full. Schedule changes replace previous versions of the schedule.
A schedule may be received in two ways:
- Via the Push Port inside inside a uR element, along with a TS element, which initialises the predictions held for this schedule. An association may also be included if this train splits, joins or there is a 'next train' association
- Via the Darwin Timetable (A Darwin push port feed filtered for Schedule and Association data types only)
A schedule message comprises of an origin, zero or more intermediate locations (including both caling and passing locations) and a terminating location.
Cancelled locations are also included in the schedule. If the train is cancelled at the origin, or at the destination, then it will still be identified as an origin/destination but there will be an additional point that represents the live origin/destination. It is possible for cancelled locations to appear before the live origin and/or after the live destination. Locations will be listed in order from origin to destination.
There is no guarantee that locations marked as 'cancelled' will be passed by the train. For example, if a train from Staines to London Waterloo is sent via Richmond instead of via Hounslow, the calling points from Hounslow to Barnes Bridge will be cancelled but the train will never pass these locations.
When a service is re-routed to a path which then re-joins the original path (for example, Staines - Waterloo via Richmond when the schedule has it calling at stations via Hounslow and Brentford)), the location at which the service re-joins may have an 'rdelay' attribute. This attribute provides a delay value that is implied by the change to the service's route. Darwin will add this value to the forecast lateness of the service at the previous schedule location when calculating the expected lateness of arrival at this location. A client that is expecting scheduled times to chronologically increase will need to take this value into account, since the scheduled times may jump back when the service joins its original route. Adding the 'rdelay' value to the scheduled times at the location where it is defined, plus later locations, will maintain chronological order.
It is possible that Working and Public times will be provided at locations where the activity codes indicate that they are not valid. For example, if a train is terminated short of its planned destination, it will have one of its calling points modified to have a 'TF' (Train Finishes) activity to reflect the fact it is now the destination. However, the scheduled departure times will still be published to allow clients to show the planned departure has now been cancelled.
When determining the order of locations when cancelled locations imply an overlapping range of scheduled times, Darwin will sequence the locations based in the working arrival, pass or departure times (as applicable), in that order. For example, given a cancelled location 'A' with a scheduled time of arrival (STA) of 10:00:00 and scheduled time of departure (STD) of 10:05:00, and a second location 'B' with a scheduled passing time (STP) of 10:03:30, location 'A' will be ordered before location 'B'.
There is no absolute guarantee that live times are in chronological order, a client must correctly handle the case where a time goes backwards, or just appears to do so because it has crossed a midnight boundary. Darwin uses the following rules to handle these cases:
|Time difference||Interpret as|
|Less than -6 hours||Crossed midnight|
|Between -6 and 0 hours||Back in time|
|Between 0 and +18 hours||Normal increasing time|
|Greater than +18 hours||Back in time and crossed midnight|
Darwin does not hold data on freight or engineering trains. It does support Empty Coaching Stock (ECS) movements by passenger train operators.
If the train category is one of 'OL', 'OO', 'OW', 'XC', 'XD', 'XI', 'XR', 'XX' or 'XZ', Darwin will mark the train as a passenger train using the 'isPassengerService' value. All other values will result in the train being interpreted as an ECS train.
Darwin may not hold information on charter trains. However, when a charter service is included, it will be identified by a boolean value to indicate that it is a charter.
Non-rail modes of transport
Darwin also provides bus and ferry information. The type of service will be identified by a 'status' attribute within a schedule.
<schedule rid="201411200059826" uid="P63461" trainId="2K33" ssd="2014-11-20" toc="LM"> <sc:OR tpl="DORIDGE" act="TB" ptd="13:09" wtd="13:09" /> <sc:PP tpl="BNHTX" wtp="13:11" /> <sc:IP tpl="WDNYMNR" act="T " pta="13:14" ptd="13:14" wta="13:13:30" wtd="13:14" /> <sc:DT tpl="KDRMNST" act="TF" pta="14:10" wta="14:10" /> </schedule>
Darwin has five types of location, each with a number of attributes:
|IP||Intermediate point (calls for passengers)||Y||Y||Y||Y||Y|
|OPIP||Operational stop (not applicable to passengers)||Y||Y|