Network Rail Open Data

[b0b]

I get the JSON reply now but need to interpret the IDs. Anyone has city ID-Value table....etc

Which IDs? you can map STANOX codes using the ATOC timetable data at data.atoc.org

 

[jamesjefferies]

This site is really useful for working out what a lot of abbreviations and data means: http://deaves47.zxq.net/rail_index.htm including STANOX codes and the like.

 

[Amy]

Which IDs? you can map STANOX codes using the ATOC timetable data at data.atoc.org

Thank you for your reply,


division_code = 60 (What is division code and what does the value 60 stand for?)

train_id = 042H21MH20 (Can this be translated to a train name?)

train_service_code = 13560015 (What does it mean and what does the code/value stand for?)

toc_id = 60 (What does it mean and what does the id/value stand for?)


loc_stanox = 07327 (What does it mean and what does the value stand for?)


auto_expected = true (?)

route= 0 (?)

next_report_stanox = 07329 (?)

line_ind = F (?)

I'm sorry, I have no clue when it comes to trains . I tried to contact support (sent them 3 e-mails already ...no reply )

 

[ralphchadkirk]

The loc_stanox is the code identifying the location where the train is. The be t report stanox is the location where t is expected the train will next report in. I'm guessing here but I think line_id denotes the name of the line the train is on, e.g. F = fast.


Sent from my iPhone 4 using Tapatalk

 

[jamesjefferies]

I'm sorry, I have no clue when it comes to trains . I tried to contact support (sent them 3 e-mails already ...no reply )

I think it is fair to say that making head or tail of the data is a non-trivial task! I'm hoping to write a blog post once I've worked it out myself.

 

[Poggs]

I'm sorry, I have no clue when it comes to trains . I tried to contact support (sent them 3 e-mails already ...no reply )

I need to claw back some time from doing 'other things' and write my "Guide to the Data Feeds". I had to work all this stuff out just over a year ago when I first had access to the feeds, and it's probably time I wrote down what I worked out

 

[greatkingrat]

train_id = 042H21MH20 (Can this be translated to a train name?)

The train_id is composed of several parts -

Digits 1-2 - Origin area (first two digits of the origin STANOX code - 04 is Edinburgh area)
Digits 3-6 - Headcode (2H21)
Digit 7 - M = Mandatory, C = Conditional (runs as required), not sure if there are other options?
Digit 8 - Time train departs origin (H = departs between 1030-1059)
Digits 9-10 - Day of month that train runs on (20th of month)

So that train_id refers to http://www.opentraintimes.com/schedule/G62035/2012/07/20

 

[Amy]

Thanks everyone for your help and valuable information.

This will take more than expected. I will start by collecting stanox + area IDs and their corresponding area names.

Any further information will be very much appreciated

Regards,
Amy

 

[Poggs]

http://wiki.openraildata.info/ - I'll shove some more things up this weekend

 

[DynamicSpirit]

Does anyone know if network rail or ATOC publish any files that describe the topology of the rail network - in other words, something that shows which Tiplocs are directly connected to which other Tiplocs? Something that would - say - if you had a train listed as calling at Guildford then Woking but no other information - could in principle enable a computer program to deduce that the train probably passes through Worplesdon en route?

And on a similar note, I see that the ATOC master station names file gives geographical locations for all stations. Is anything published that gives the locations of TIPLOCs that aren't stations?

 

[The Planner]

The Timetable Planning Rules will tell you what timing points a train passes through on it's journey. TIPLOCs arent associated with each other, they just denote a single location. There is a website somewhere that does list all the TIPLOCS aswell, it was linked to recently.

 

[Paul Kelly]

Does anyone know if network rail or ATOC publish any files that describe the topology of the rail network - in other words, something that shows which Tiplocs are directly connected to which other Tiplocs? Something that would - say - if you had a train listed as calling at Guildford then Woking but no other information - could in principle enable a computer program to deduce that the train probably passes through Worplesdon en route?

The Rules of the Plan has this information - look at Section 2.1, Planning Geography in each regional document. I think to work it out accurately you would need to take account of the running line indications in the schedule data as well as just the TIPLOCs passed through...

Edit: Rules of the Plan and Timetable Planning Rules (as already mentioned above by The Planner) seem to be the same thing. Maybe the direct link is useful anyway...

 

[The Planner]

They are the same thing, the RotP was re-named a while back.

 

[DynamicSpirit]

The Rules of the Plan has this information - look at Section 2.1, Planning Geography in each regional document. I think to work it out accurately you would need to take account of the running line indications in the schedule data as well as just the TIPLOCs passed through...

Thanks Indigo2! Yes those planning geography lists look like the information I wanted regarding tiploc connectivity (albeit in a format that's going to take quite some work to parse electronically!)

 

[Poggs]

Thanks Indigo2! Yes those planning geography lists look like the information I wanted regarding tiploc connectivity (albeit in a format that's going to take quite some work to parse electronically!)

Is it still the case that RoTP still only has mandatory timing points and not every possible TIPLOC-to-TIPLOC move?

 

[Paul Kelly]

Not sure what you mean? It has (since I first started looking at it last Summer anyway) all timing points - mandatory ones for all trains are in bold, those that are only compulsory for trains stopping there have an 'S' against them, and those that are only compulsory for trains crossing from one line to another there have an 'X' against them.

Also shows which stations have platforms on which running lines, although unfortunately that turned out not to be so useful for determining the stations a train passed through for Routeing Guide doubling back purposes - I don't think there is any data source anywhere that defines that precisely...

 

[b0b]

although unfortunately that turned out not to be so useful for determining the stations a train passed through for Routeing Guide doubling back purposes - I don't think there is any data source anywhere that defines that precisely...

That was the conclusion I came to as well, although I'm thinking if you start recording the TD berth data, you could figure out which route a train regularly takes and going through the same berth more than once would be a double back. But then you're still left with figuring out which berths relate to which stations.

But we're a step closer.

 

[Poggs]

That was the conclusion I came to as well, although I'm thinking if you start recording the TD berth data, you could figure out which route a train regularly takes and going through the same berth more than once would be a double back. But then you're still left with figuring out which berths relate to which stations.

But we're a step closer.

Unless a line is reversible, you're unlikely to go through the same berth twice in a journey.

I have a table of berth steps, STANOXes and what they indicate to TRUST. Making that data available and continually updated was one of the things that came up at a meeting with NR last month.

 

[Amy]

Hello everyone,

I'm a bit confused, shouldn't data feeds provide current data why I'm I getting past times (3, 4, 5.... hours ago)?

 

[Poggs]

Hello everyone,

I'm a bit confused, shouldn't data feeds provide current data why I'm I getting past times (3, 4, 5.... hours ago)?

What're you seeing that makes you think you're getting historical data?

 

[Amy]

What're you seeing that makes you think you're getting historical data?

471B63MN26, 1343309610000, 1343309580000

872L10MM26, 1343309670000, 1343309640000

505N26MM26, 1343309640000, 1343309520000

Time received feed: 13:30 BST

I've also been searching for TOC IDs and their corresponding values. I.e TOC ID 60 stands for which Train Company?

The information you have posted thus far have been very helpful thank you

 

[Poggs]

471B63MN26, 1343309610000, 1343309580000
872L10MM26, 1343309670000, 1343309640000
505N26MM26, 1343309640000, 1343309520000

Time received feed: 13:30 BST

Those times look like they're in GMT.

I've also been searching for TOC IDs and their corresponding values. I.e TOC ID 60 stands for which Train Company?

The information you have posted thus far have been very helpful thank you

I'm not actually sure there's a table of TOC IDs and codes released, but I've thrown up a list at http://wiki.openraildata.info/index.php/TOC_Codes for you

 

[Amy]

Those times look like they're in GMT.



I'm not actually sure there's a table of TOC IDs and codes released, but I've thrown up a list at http://wiki.openraildata.info/index.php/TOC_Codes for you

Thanks Poggs

So the received feed timestamps are GMT

 

[gavco98uk]

471B63MN26, 1343309610000, 1343309580000

872L10MM26, 1343309670000, 1343309640000

505N26MM26, 1343309640000, 1343309520000

Time received feed: 13:30 BST

I've also been searching for TOC IDs and their corresponding values. I.e TOC ID 60 stands for which Train Company?

The information you have posted thus far have been very helpful thank you

The timestamps included in the feed are in milliseconds, whereas many conversion routines in PHP/C# etc. will expect them to be in seconds. Try dropping the last 3 zero's if you are getting errors.

Example:
Go to http://www.unixtimestamp.com/index.php and try converting the timestamps:
1343309670000 -> 10 / 15 / 37 @ 9:00:00am EST
1343309670 -> 07 / 26 / 12 @ 8:34:30am EST

http://www.epochconverter.com/ on the other hand manages to get both formats correctly:
1343309670000 -> Thu, 26 Jul 2012 13:34:30 GMT
1343309670 -> Thu, 26 Jul 2012 13:34:30 GMT

So in short, check that whatever conversion function you are using is parsing them correctly, and is also parsing them to the correct timezone.

 

[Amy]

The timestamps included in the feed are in milliseconds, whereas many conversion routines in PHP/C# etc. will expect them to be in seconds. Try dropping the last 3 zero's if you are getting errors.

Example:
Go to http://www.unixtimestamp.com/index.php and try converting the timestamps:
1343309670000 -> 10 / 15 / 37 @ 9:00:00am EST
1343309670 -> 07 / 26 / 12 @ 8:34:30am EST

http://www.epochconverter.com/ on the other hand manages to get both formats correctly:
1343309670000 -> Thu, 26 Jul 2012 13:34:30 GMT
1343309670 -> Thu, 26 Jul 2012 13:34:30 GMT

So in short, check that whatever conversion function you are using is parsing them correctly, and is also parsing them to the correct timezone.

Thanks gavco98uk, you've been a great help! It makes sense now!

 

[BIBBY]

Hi Everyone

Can someone just confirm to me that the data feeds are working ok today
mine seem to have stopped picking up data

many thanks
--- old post above --- --- new post below ---
Hi Anyone there ?

Still not getting any data today ...
Would someone confirm it's working

many thanks

 

[Paul Kelly]

No shortage of train movements coming through here. Even had a few VSTP schedules come through this morning. I'm not looking at anything else. Which feeds are you concerned about?

 

[BIBBY]

I have been looking at TSR_ALL_ROUTE this morning .. but I didn't get any on friday ..just tried TM and managed to get something on that but the one I was using on friday was RTTPM_ALL

thanks
--- old post above --- --- new post below ---

Unless a line is reversible, you're unlikely to go through the same berth twice in a journey.

I have a table of berth steps, STANOXes and what they indicate to TRUST. Making that data available and continually updated was one of the things that came up at a meeting with NR last month.

Is that data available yet --- as it would be really useful to me
--- old post above --- --- new post below ---

Unless a line is reversible, you're unlikely to go through the same berth twice in a journey.

I have a table of berth steps, STANOXes and what they indicate to TRUST. Making that data available and continually updated was one of the things that came up at a meeting with NR last month.

Is that data available yet --- as it would be really useful to me

 

[Poggs]

Here we go!

http://wiki.openraildata.info/index.php/TD_Berth_Steps

 

[b0b]

Here we go!

http://wiki.openraildata.info/index.php/TD_Berth_Steps

very nicely done