Network Rail - next steps

[Peter Hicks]

All,

I'm meeting with Network Rail in early January to discuss ideas for further datasets that could be made open.

So far, my list of points is this:

• Supporting documentation on interpreting RTPPM statistics
  
• A list of Train Service Codes (TSC) and descriptions
  
• Centre-line geometry from http://data.gov.uk/dataset/railway-network-inspire in vector format
  
• Signalling diagrams in whatever format they're available
  
• Regularly updated Sectional Appendix snapshots
  
• Regularly update STANOX and STANME reference data
• Data on Emergency Speed Restrictions (ESRs)
  
• Weekly and Periodical Operating Notice data
  

If you have other ideas, please let me know - ideally on the list so we can discuss and inspire each other!

Peter

[Rob Stearn]

Not sure if your list includes it but my personal request would be to get information on the composition of a train; number of carriages, type of stock perhaps.

It's all grist to the mill of understanding exit alignment, disability access and station layouts.

Rob Stearn

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To post to this group, send an email to openrail...@googlegroups.com.
To unsubscribe from this group, send email to openraildata-t...@googlegroups.com.
 
 

[Gavin Coates]

I am not sure if this is already included in the current streams, I have not done much with the feeds yet, but it would be desirable to display the registration number of the train operating each service. Is this data even available in the systems at network rail?

As per your list, I second the request for making STANOX data available, this would greatly assist developers in making use of the feeds, as would better documentation, although this is partially covered by the community wiki.

regards

Gavin Coates

[Paul Dart]

On 18 December 2012 12:18, Peter Hicks <peter...@poggs.co.uk> wrote:
> If you have other ideas, please let me know - ideally on the list so we can
> discuss and inspire each other!

One thing I was discussing in the pub recently was the relationship
between track circuits (one or many in a), berths (one or many in a),
TIPLOC.

The conversation came up as SouthEastern appear to have changed their
CIS (although I'm not sure they really have) so that it shows a train
'arrived' when it's still a minute or two away.

The conclusion was it would be interesting to know
a) how the statistics are worked out, and from what system it comes
from (regarding late penalties etc) - so some of the above might help
b) where exactly (or at least with more detail) where a train is if possible

http://wiki.openraildata.info/index.php/TD#S.2A_messages This would
help, but you need to know where the beginning/end of each Track
Circuit is, which I guess you can probably reverse engineer from
signalling diagrams - I guess that comes back to what format are you
going to get those in.

I haven't kept quite on top of all of this, so perhaps some of this is
known already, and I think that'll probably do for now :-)

Regards,

Paul

P.S. As I'm on the subject of locationing, the GPS data, or whatever
stream you can get out of the ERTMS trial on the Cambrian coast would
be nice...Good luck!

[Peter Hicks]

Hi Gavin, Rob,

On 18 December 2012 14:27, Gavin Coates <gavin....@gmail.com> wrote:

I am not sure if this is already included in the current streams, I have not done much with the feeds yet, but it would be desirable to display the registration number of the train operating each service. Is this data even available in the systems at network rail?

That data is held, if a TOC uses it, in a system called GEMINI.  There is an interface in to 'mainframe GEMINI' which I think is used by Web Gemini, but I don't know any details.

Several people have asked for this data, it's actually right at the top of my list.  There will be the usual caveats for "It might not be up-to-date" or "It might be wholly inaccurate", especially in times of disruption - but it's worth investigating.

 

As per your list, I second the request for making STANOX data available, this would greatly assist developers in making use of the feeds, as would better documentation, although this is partially covered by the community wiki.

I have a set of data from a system called CORPUS that was sent around a few months ago, which I'll upload to the Wiki tomorrow.  This has NLC, STANOX, TIPLOC, CRS and descriptions, and it's comprehensive - Euston Platform 8-11 cleaners has a NLC!

Peter

[Peter Hicks]

On 18 December 2012 14:35, Paul Dart <paul...@gmail.com> wrote:

 

One thing I was discussing in the pub recently was the relationship
between track circuits (one or many in a), berths (one or many in a),
TIPLOC.

The data linked form http://wiki.openraildata.info/index.php/TD_Berth_Steps is what a system called SMART (Signal Monitoring and Reporting of Trains) sends to TRUST to trigger an automatic train report.  For most locations, it includes an 'arrival' berth step, and a 'departure' berth step.  That's probably the most useful data you can get as to which berths are associated with which TIPLOCs, although being signalling-related, it refers to STANOX (Station Number) rather than TIPLOC.

 

a) how the statistics are worked out, and from what system it comes
from (regarding late penalties etc) - so some of the above might help

TRUST won't do predictions - it can only say that a train is 'overdue' at a location.  CIS at stations is traditionally set up with local berth geography data and information from TRUST to make its own predictions.  The problem with this is that the data you see on Live Departure Boards (NRE/Darwin) can vary from what you see at the station.

Local CIS can feed Darwin to fill in gaps, however the situation now is that Darwin is starting to feed CIS at stations to give consistent data.  This is one of the reasons (see the other thread) that Darwin is such a vital source of data for everyone - it is 'the truth'.

 

b) where exactly (or at least with more detail) where a train is if possible

The lowest level of detail you can get to is track circuit level.  S-Class data, which I believe is in the pipeline, will - in areas that support S-Class data *and* provide the necessary detail - will indicate which track circuits are occupied... but the support in a TD varies.  For example, the Rugby 1 TD (Watford - Milton Keynes-ish) contains very rich track circuit data, although Rugby 2 (Milton Keynes and north) only contains data for Northampton and a couple of other locations.  The NR standard is for a minimum of track circuit data at locations where trains regularly split and join, and there's a maximum of 1,024 elements per train describer.

Moving up a level, the next source of positioning data is signalling berths, but this is only reliable where there are signals.  Block sections can be quite long, some stations don't have signals on the approach and departure (Barnes Bridge, for example, and Luton Airport Parkway) but berth steps are the way TRUST reports arrival and departure times.

I don't know of a current standard for aggregating GPS data from operators.  An article I read a week or two ago in Rail magazine suggested that a significant percentage of rolling stock has GPS devices on-board, which NRE want to use for Darwin, and Network Rail want to use for train positioning information.  There isn't a standard for a GPS aggregation platform yet though, and it whilst it gives you velocity information and positioning data more granular than signalling berths, it doesn't work where there's no data connection to send the data, nor where GPS is unreliable.

http://wiki.openraildata.info/index.php/TD#S.2A_messages This would
help, but you need to know where the beginning/end of each Track
Circuit is, which I guess you can probably reverse engineer from
signalling diagrams - I guess that comes back to what format are you
going to get those in.

That too is on my list of "Things to find out".  There are a variety of sources of data, it's just a case of digging through them to find out which ones are suitable for 'opening up', as I imagine NR's GIS platform has a lot of restrictively licensed data in it.

 

P.S. As I'm on the subject of locationing, the GPS data, or whatever
stream you can get out of the ERTMS trial on the Cambrian coast would
be nice...Good luck!

That isn't on my list, but it will be in five minutes.  The perfect time for a 'beta' :-)

Peter

[acuth]

Is there any more information available about Web GEMINI? or more generally any mechanism that makes it possible to map from vehicle numbers to the real-time information Network Rail make available?

Any pointers gratefully received,

Adrian

[Peter Hicks]

Hi Adrian

On 03/07/13 13:54, acuth wrote:
> Is there any more information available about Web GEMINI? or more
> generally any mechanism that makes it possible to map from vehicle
> numbers to the real-time information Network Rail make available?

I was in a meeting an hour ago talking about this.

Web Gemini is only accessible from the railway network, but contains
headcode to unit number mappings and is "as accurate as the information
people put in it". Not all TOCs appear to use it.

I'm making enquiries - watch this space, but don't hold your breath just
yet!


Peter

[yunshi zhao]

Hi Peter,

Is there any information available to interpret the TD S-class data? Maybe you could also mention that to network rail during the meeting.

Regards,

Yunshi

[Peter Hicks]

Hi Yunshi

On 18 Dec 2013, at 16:02, yunshi zhao <zhys...@gmail.com> wrote:

> Is there any information available to interpret the TD S-class data? Maybe you could also mention that to network rail during the meeting.

There is, but it’s fragmented and there’s no central store of data.

I am working on gathering a big spreadsheet of all the data, which is about 60% complete at the moment. I’ll be having some more discussions in the New Year about how we can distribute this data and keep it up-to-date, so watch this space.


Peter

[Martin Swanson]

Hello Peter,

On the Train Movement wiki page it states "Delay Attribution-related messages are not available". If the meeting is still going ahead please can you add a request to provide delay attribution data to your list? If I am too late perhaps you can add this to your list for the next meeting?

This would be incredibly useful information for passengers and perhaps help them understand the range of issues faced by NR and the TOCs. It might even help to dispel the "wrong type of snow" myth (I could not find that on the list of valid reasons in the Delay Attribution guide!)

Apologies for the tardy request - I have only recently joined the Google group and am steadily reading through the message history.

Kind regards,

Martin

On Tuesday, 18 December 2012 12:18:07 UTC, Peter Hicks wrote:

[Peter Hicks]

Hi Martin

On 11/01/14 12:51, Martin Swanson wrote:

On the Train Movement wiki page it states "Delay Attribution-related messages are not available". If the meeting is still going ahead please can you add a request to provide delay attribution data to your list? If I am too late perhaps you can add this to your list for the next meeting?

This would be incredibly useful information for passengers and perhaps help them understand the range of issues faced by NR and the TOCs. It might even help to dispel the "wrong type of snow" myth (I could not find that on the list of valid reasons in the Delay Attribution guide!)

The Delay Attribution messages aren't quite what you think they are - and I fell in to this trap three years ago when I thought they'd be useful!

The DA messages are from TRUST DA, a separate system to TRUST which generates delay alerts when a train is delayed between two TRUST reporting points, i.e. in a "TRUST section", and deals with attributing the delay to a cause.  They don't say much more than "train X was delayed by Y minutes between reporting points Q and R", or "delay Y has been categorised as QQ, and assigned to Responsible Manager code ABCD" - but these attributions can, and do change.  They're also not input in real-time, so the only use is historically.

On the mainframe on which TRUST and TRUST DA run on, security measures driven by the user sign-on limit which incidents you can see - a Network Rail HQ user can see everything, but a TOC or FOC user can only see incidents where they have a delay to a train involved.

Delay Attribution (Schedule 8) is "hugely contentious", and given the security in place on the mainframe, the short answer is that the DA messages won't be made available.  But look at it this way - the messages are probably of limited use anyway!


Peter

[Martin Swanson]

Hi Peter

An historical report with the DA code would be fine. I can appreciate that there is likely a review process to ensure the attribution is correct hence we'd either need a real time feed with new/amends or just a regular scheduled report of 'approved' DA reasons. At the end of the day, these are just mainframe systems so there should be no technical reason why the data cannot be extracted i.e. what is preventing the accounts used to run reports from being granted permission to see the full set of DAs?

I'm not sure I understand why DA codes would require permissions unless some of them (I assume a small subset?) are sensitive in some way? If that were the case, what is the population of DA codes that can be provided?

In the spirit of 'open data' it seems odd that delay attributions are not available. How else can the public validate that the reasons given by NR/TOCs for delays are accurate? 

If the answer is still no I could always try the ORR or make an application to NR directly under the Freedom of Information Act, given that NR is partially publicly funded.

Appreciate your advice,

Martin

[Peter Hicks]

Hi Martin

On 11 Jan 2014, at 18:00, Martin Swanson <martind...@gmail.com> wrote:

> An historical report with the DA code would be fine. I can appreciate that there is likely a review process to ensure the attribution is correct hence we'd either need a real time feed with new/amends or just a regular scheduled report of 'approved' DA reasons. At the end of the day, these are just mainframe systems so there should be no technical reason why the data cannot be extracted i.e. what is preventing the accounts used to run reports from being granted permission to see the full set of Das?

It’s a bit more complicated than just running some reports.

I’ll have a word with a few people - don’t expect much movement at the moment as it’s coming to the end of CP4, so everyone is in “CP5 planning mode”...



Peter

[Kali Mero]

Hi Peter,

I've registered for an account on the NR open datafeeds server mid Nov 2013, wrote quite a simple Perl script (using Perl v5.12.2, 09 Dec 2010 and the Net::STOMP Perl module from search.cpan.org/~jtang/Net-Stomp-0.45, 14 Mar 2012) to be called on command line to connect, subscribe, receive, decode, log the TD C- and S-class messages thanks to the very good documentation on nrodwiki.

However, I am also very interested in the meaning/interpreting of the S-class message contents, i.e. what a bit on a specific address exactly means, e.g. "signal x set to proceed/hold" or "route y set/not set" or "track z occupied/free" or "point p center/reverse".

I'm especially interested in the bits with signalling data of TD areas Y2 (and Y3 (York IECCs 2 and 3), because I have the track layout (incl. signals, berths, track circuits, points; about 2 years old, from 2012; unfortunately not allowed to share it) of these TD areas. So I would be able to map the S-class message data (see attached logfile with a full scan of Y2 and Y3) somehow to the state of signalling elements. For my purposes it doesn't matter how complete or actual or in which format (csv, xls, pdf etc.) this mapping table (bit no. to meaning) would be, anything of this kind would be very helpful.

Kind regards, Kali

[Peter Hicks]

Hi Kali

On 22/01/14 21:05, Kali Mero wrote:
> However, I am also very interested in the meaning/interpreting of the
> S-class message contents, i.e. what a bit on a specific address
> exactly means, e.g. "signal x set to proceed/hold" or "route y set/not
> set" or "track z occupied/free" or "point p center/reverse".
>
> I'm especially interested in the bits with signalling data of TD areas
> Y2 (and Y3 (York IECCs 2 and 3), because I have the track layout
> (incl. signals, berths, track circuits, points; about 2 years old,
> from 2012; unfortunately not allowed to share it) of these TD areas.
> So I would be able to map the S-class message data (see attached
> logfile with a full scan of Y2 and Y3) somehow to the state of
> signalling elements. For my purposes it doesn't matter how complete or
> actual or in which format (csv, xls, pdf etc.) this mapping table (bit
> no. to meaning) would be, anything of this kind would be very helpful.

The situation with S-Class data is this:

* There is no single repository of data
* The repository I am trying to create (a very considerable number of
hours of my free time has been spent on it!) is "nearly complete",
however there are gaps and I can't validate that all the bit mappings
are 'current'
* The bits are not helpful without knowing the location of signals,
points, track circuits etc. - and there is no public source of this
information at the moment, so releasing the mappings may end up creating
a further problem of "but it's not useful", possibly even wholesale
'leaking' of track and signalling diagrams

I'll have a think and see if I can work out a sensible way forward....


Peter

[Kali Mero]

Hi Peter,

On 22/01/14 22:40, Peter Hicks wrote:

The situation with S-Class data is this:
   * There is no single repository of data
   * The repository I am trying to create (a very considerable number of
hours of my free time has been spent on it!) is "nearly complete",
however there are gaps and I can't validate that all the bit mappings
are 'current'
   * The bits are not helpful without knowing the location of signals,
points, track circuits etc. - and there is no public source of this
information at the moment, so releasing the mappings may end up creating
a further problem of "but it's not useful", possibly even wholesale
'leaking' of track and signalling diagrams
I'll have a think and see if I can work out a sensible way forward....

Thanks for your kind answer.

Browsing the different threads and posts in this group I've seen also some others interested in the S-class bit mappings / translation tables. I would be totally satisfied with not quite actual or not complete data "as is", which you thankfully have already compiled with some considerable effort.

As already mentioned in my previous post, I have already lists and track layouts of track circuits, signals, points, routes of TD areas Y2 and Y3 (York IECCs 2 and 3). It would be great, if I will find the S-class mappings / lookup tables one day somewhere around http://nrodwiki.rockshore.net/index.php/S_Class_Messages .

Cheers, Kali