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?

The following data is available from National Rail Enquiries' Data Feeds platform:

Data	Format	Details
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?

The following data is available from Network Rail's Data Feeds platform:

Data	Format	Details
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.