Rail Data FAQ
Which feed should I use?
It depends on what you want to do.
- Use the Network Rail feeds if you want very low-level detail, such as train describer berth-level data, line/platform/path data in train schedules, or if you want to receive data for non-passenger TOC trains. The data in these feeds is of a highly technical nature and you will require a fair amount of railway domain knowledge to be able to interpret them correctly.
- Use the National Rail Enquiries feeds if you want industry-wide consistent data on passenger train movements which matches that shown in railway stations and on other sites powered by Darwin.
What data is available from National Rail Enquiries?
|Reference data||XML||Reference Data|
|Timetable data||XML||Push Port Timetable|
|In-day historical log files of real-time data||XML||Accessing non-real time data|
|Train service updates (movements, cancellations, forecasts)||XML||Accessing real-time data|
What data is available from Network Rail?
|Planned train movements (schedules)||JSON||SCHEDULE|
|Planned train movements (schedules)||CIF||SCHEDULE|
|Late notice changes to the train plan||JSON||VSTP|
|Train movement/cancellation-related messages||JSON||Train_Movements|
|Raw train describer feeds||JSON||TD|
|Real-time PPM data every 60 seconds||JSON||RTPPM|
|Temporary Speed Restrictions||JSON||TSR|
Why are you using message queues and Stomp?
Whilst it may seem odd to use a relatively heavy message queueing platform, it gives many advantages over using a raw TCP socket, or a stream of data over HTTP:
- If/when your client disconnects, the server will hold on to several minutes worth of data that you'd otherwise lose if you weren't using a message queue
- Topics, as used in the Network Rail Data Feeds platform, are a scalable and efficient way to distribute the same data to hundreds of subscribers, each of which may consume data at a different rate
- Queues, as used in the National Rail Enquiries Data Feeds platform, are an efficient way to distribute a custom set of data to each user
- There is no need to write a protocol handler to cope with the nuances of HTTP, particularly when using 'chunked' encoding
- Stomp clients are available for many of the most common development platforms
Why are you using XML in the Push Port?
The Push Port uses XML natively, as it was first built for industry/enterprise use. The data is distributed in XML at this stage for a number of reasons:
- Converting it to a different format, such as JSON, will take the focus away from getting the data released quickly and later evolving based on the community's feedback
- A straight XML-to-JSON conversion is difficult, as the Push Port schema makes heavy use of XML namespaces, and some element names are repeated across namespaces and used for different purposes
- The existing documentation for the Push Port refers to XML messages, and it was felt easier to make as few changes to the format, and therefore the documentation, at this early stage
Why are you using XML and SOAP in the Live Departure Board web service?
The Darwin Web Service was built using XML and SOAP as it was first built for industry/enterprise use.
SOAP is not the friendliest of protocols - the Open Source Huxley proxy, which you can run on your own system, may be of use if you want to access the web service using JSON.