About the Network Rail feeds: Difference between revisions

From Open Rail Data Wiki
m Added a section on good practice
mNo edit summary
Line 18: Line 18:
Schedule data is available as a separate download.
Schedule data is available as a separate download.


== Good practice ===
== Good practice ==


Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service:
Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service:

Revision as of 13:48, 23 October 2012

What are the feeds?

Five feeds and a resource are available:

  • RTPPM - Real Time Public Performance Measure. This shows the performance of trains against the timetable, measured as the percentage of trains arriving at destination on time. Updated every minute.
  • Train Movements - messaging from the TRUST system, containing reports of train movements past timetabled calling and passing points.
  • TD - data from the Train Describer system, showing raw data with train movements in more detail than the Train Movements feed.
  • VSTP - late-notice train schedules which are not available through the Schedule feed.
  • TSR - Temporary Speed Restrictions
  • SCHEDULE - extracts of train schedules from ITPS.

How do I get the data?

Sign up for an account at http://datafeeds.networkrail.co.uk. You will receive a confirmation email - follow the instructions: log in, change your password, then select the feeds that you wish to access.

You will need to write a Stomp client, available in many languages.

Schedule data is available as a separate download.

Good practice

Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service:

  • Sign up with one account - it gives an accurate reflection of how many people are actually using the service.
  • Connect to the service once - you can receive multiple feeds in a single connection. If you need to access the data more than once, you can do so - but be sensible!
  • Don't leave a failed client running - if you can connect but get an authentication or authorization error, stop your client, don't leave it continually trying.
  • Make sure your client handles failures - if your client fails to connect or is disconnected, use an exponential backoff and wait 1s, 2s, 4s, 8s, 16s etc. before trying to reconnect. Service problems sometimes occur, and if everyone tries to reconnect every second, the service will not recover quickly.
  • Use a durable subscriber - if you want data to be queued in case you disconnect, request a [Durable Subscription|durable subscription] when you connect.

Background reading

It may be useful to understand the background to the sources of some of these data feeds. These links will help:

Examples

Example code is available for several common languages: