Wish List

This page contains a wish-list of things the Open Data community would like the industry to release.

Nothing here means the industry will take any action, however it's a useful place to coordinate getting more data released.

Train Describer data

What is the data?

Although the Train Describer (TD) feed is available, there are several sources of information that haven't been released.

• Stepping Tables - these determine the signalling conditions (track section occupied, signal clear and route set) that cause a train describer to 'step' a train's description from one berth to another. They are in text format
• Block Schematic - these show the berths on a train describer, the attributes of the berth (e.g. whether it's a blind berth, a berth from an adjacent TD, a dual berth, etc.) and which other berths can be stepped to from this berth
• Signalling Outputs (SOP) Table and External Communication Subsystem Specification - these show the bytes and bits used in S-Class (SF, SG and SH) messages and which signalling item (e.g. signal, route, points, track section) is assigned to which bit

Where is it held?

Stepping Tables, Block Schematics and SOP data is held within the train describer itself, usually in a text file. Copies of these files are held at the National Records Group within Network Rail, although the wide variation in age and manufacturer of train describers means the data may be held on various media, from EPROMs and 8mm tape through to floppy disks, CD-ROMs and USB sticks.

ECS Specifications are a document which contains details on the configuration of the train describer, and include data such as which other TDs are connected, all berths known to the TD, etc.

What would the data be used for?

Stepping tables and block schematics will help developers understand the relationship between berths and what conditions cause trains to step. Knowing which signalling items the bits in S-Class messages refer to will allow developers to calculate train movements in advance of them happening, e.g. a move from berth A to berth C, given the route is set from signal A to signal C. This could be used to give advance detail of platform changes.

How much effort would it take to release?

First, a current list of all train describers would need to be collated, including those daisy-chained from other train describers. For example, the TD at Upper Holloway sends its stepping data to Cambridge PSB (CA), as it only has a few berths. The TD at Cambridge PSB doesn't perform any stepping for Upper Holloway, it merely 'echoes' the stepping data in to Network Rail's systems.

Next, a search of the records archive for the location of the records would need to take place. Where records are stored as physical documents, they would need to be scanned in and OCR'd to make the data readable. Given the age of some documents, some data may be difficult to read and mis-OCR'd, needing intervention to ensure the data is correct.

Some of the records might not be held by Network Rail and could be held by the maintainer of the train describer, which would mean further work needs to take place to request the data in a suitable format.

Finally, the data will need to be organised and metadata created listing the version and revision history, plus the train describer to which the data relates.

Why might the data not be released?

• Possible concerns over the amount of effort required to keep released versions up-to-date, as they aren't controlled documents, and without publishing a list of current versions, it would be impossible to know whether a version you had is the latest or not. New versions of the data containing alterations may become available, but may not have a concrete 'commissioning date', so notice of commissioning would need to be sent out in advance
• The data is difficult to process without knowing where the locations related to berths are, and this means track and signalling diagrams would need to be released as well
• The cost of releasing the data may outweigh the benefits of releasing the data

National Electronic Sectional Appendix

What is the data?

NESA is a website which has the latest copies of data that is published in the Sectional Appendix, and published several times a year.

Where is it held?

NESA is run by Network Rail.

What would the data be used for?

The data in NESA is largely the same as that in the published Sectional Appendix, although NESA will contain updates around the time the Sectional Appendix pages are updated in the Weekly Operating Notice (WON).

How much effort would it take to release?

A process would need to be put in place for anyone to request a login to NESA. This would have a tangible cost to Network Rail.

Why might the data not be released?

NESA is not the most user-friendly system. It does not work on the latest versions of common web browsers, and relies on a SVG plugin for Internet Explorer 8 and below. Logins to NESA have to be created manually, and the system is not designed to cope with an unknown number of people trying to access it and produce consoliated PDF versions of data at once.

Weekly Operating Notices

What is the data?

The Weekly Operating Notice (WON) contains details of possessions and engineering worksites planned, speed restrictions (TSRs), changes to the railway and changes to procedures and processes.

Where is it held?

It is published once a week in PDF format.

What would the data be used for?

To keep a member of the public up-to-date on operations on the railway.

How much effort would it take to release?

Currently, the WON is emailed out each week. It could be emailed out to an additional mailing list which interested parties could subscribe.

Why might the data not be released?

The WON contains internal telephone numbers, such as emergency numbers to be used when contacting a signaller. Publishing this may result in 'prank' calls. It also contains details of named individuals, which may require redacting before publication, increasing the effort required.