-
Our new ticketing site is now live! Using either this or the original site (both powered by TrainSplit) helps support the running of the forum with every ticket purchase! Find out more and ask any questions/give us feedback in this thread!
Network Rail Open Data
- Thread starter Metroland
- Start date
- Status
Sponsor Post - registered members do not see these adverts; click here to register, or click here to log in
R
RailUK Forums
Oh wow (understatement). Any way to get it in a GIS-friendly format?
Yes - think of berths as a network of nodes, some with a one-to-one mapping, some with a one-to-many. A berth step is when a description moves from one to another, i.e. moves from one node in the network to another.
It certainly is as there will be issues where a train terminates and then runs ECS. No messages will be sent once the train has terminated and so would show as still in the platform (even though the ECS will have departed) on any map until another train arrives.
I wouldn't hold your breath.
From what I understand, FOCs don't want their data made open as it will be trivially easy for somebody competing against them to encourage their customers to shift to road haulage. That puts them at a disadvantage, which isn't a good thing.
The only use case for freight data appears to be the enthusiast community, some of whom think everything should be free and can't see why detailed freight data isn't available. I, on the other hand, agree with the FOCs and unless there's legislation or some steering from the DfT, don't think we'll see freight data being opened up on a detailed level.
Unfortunate if the one empty freight working that runs officially as ECS (due to using Motorail vans) is going to prevent any maps working correctly where trains terminate and then run ECS.
Maybe I'm missing something, but isnt this just a recast of the meridian 2 data?
Well, from what I can see, it's Class 1, 2 and 5 that are included, and every other description excluded (e.g. SHUT, -T3-, **** etc.) - but maybe it should be Class 4, 6, 7 and 8 excluded and everything else included.
I'll make a note to bring this up at the next meeting at NR.
Well Class 5 is currently excluded. Will there not be issues with allowing class 5 to be included due to that Colas Rail service that runs class 5 when empty or would there be a way of filtering that out?
can't we just filter FOC's out by their FOC code?
For the benefit of everyone else (because I know why you suggested that!) - the TD data is just three commands - CA, CB, CC - and a description. There's no hidden metadata such as TOC code, so nothing to filter on other than train class.
Isn't there some additional filtering to keep the Royal Train out even though it runs as class 1? I would have thought it would be possible to filter out individual descriptions. Of course train reporting numbers are not unique so even if the class 5 empty freight working could be filtered that way, it could result in some other class 5 workings getting filtered. Not great but would be better than the current situation where no class 5 information is available.
of course! i'm forgetting the difference between TD and TRUST again
IIRC, the Royal Train runs under a unique headcode wherever it runs, so it's easy to filter out; the Colas train might run under a certain headcode now, but could run under a different on at another time, e.g. if it runs to a VSTP schedule. That presents a problem as you can't guarantee to have the description hidden.
There may be other reason why ECS movements are not shown though - I can't think of any off the top of my head.
The origin of the TD data are the many large and small train describer computer systems in the various signal boxes and control centres around the network, whose primary purpose is to help signallers keep track of train identities as they move around their individual control area mimic diagrams. The name 'berth' derives from the signal berth track circuit, the last train detection section on approach to a signal. Berth steps are triggered when a train passes the signal to which the berth applies on a known locked route towards another signal, which can be derived by the systems' direct connections to the control system. As signals can sometimes be many miles apart, the granularity of the system results in trains stepping a long way ahead of their actual position, if the berths are taken to be at the geographical position of their associated signal. Therefore the presence of a train ID in a berth display represents a train waiting at or moving towards that signal.
I meant that svg is a vector format, so it may be usable. I don't know what format you'd like but there's a SVG to WKT converter here:
http://code.google.com/p/svg-to-wkt-converter/
Would that do?
--- old post above --- --- new post below ---
Thanks Mark and Poggs for the explanations. Could I seek a bit more clarification on the TD feed message type please?
CA: Berth Step, with from and to fields. I think you confirmed this is a transition of a train descriptor from one berth to another, adjacent one.
CB: Berth Cancel with from field only. Does this mean the train descriptor should be removed from that berth?
CC: Berth Interpost with to field only. Is this just an information message saying the TD is still in that berth?
CT: Heartbeat with no to or from. What's the purpose of this one?
Many thanks again.
Pat
Last edited:
All TD messages have an area_id and time in them. This is, I believe, the time that the train describer generates the step message.
There are two ways I can think of using TD data:
- Look for specific berth steps and do something with the data, e.g. say "train X has passed location Y"
- Keep the state of all berths and produce a snapshot at any particular time, or a real-time signalling map
As for the meanings:
CA is a Berth Step, which will have a description, a from and a to field. This message appears when a train has moved from one berth to another. I process these by clearing out the 'from' berth and putting the description in the message in to the 'to' berth'.
CB is a Berth Cancel, which means "clear out the description in this berth".
CC is a Berth Interpose, which means "put this description in the berth"
CT is a Heartbeat, which indicates that the train describer is alive. Overnight, if there are no train movements, you may get no step/cancel/interpose messages.
Think of it as a giant game of chess. Generally, you move pieces (step) from one square to another. But a game of drunk chess - sometimes you remove pieces (cancel), sometimes you add pieces (interpose).
Thanks Poggs, very helpful 
I'm trying to produce a real time graph of the berth nodes, showing which TD is in any berth at a time. Problem is, my schema has the td with a FK to berth, and I'm getting more than one TD in a berth at one time. This isn't suppposed to happen is it?
I'm assuming it's a bug in my code, but can you clarify again please?
Can a berth have more than one TD assigned to it at a time?
Cheers
Pat
I'm trying to produce a real time graph of the berth nodes, showing which TD is in any berth at a time. Problem is, my schema has the td with a FK to berth, and I'm getting more than one TD in a berth at one time. This isn't suppposed to happen is it?
I'm assuming it's a bug in my code, but can you clarify again please?
Can a berth have more than one TD assigned to it at a time?
Cheers
Pat
TD is Train Describer, the system that moves train descriptions (or descriptions, or 'headcodes' if you want to be colloquial!) between berths. Probably best to call them descriptions to avoid confusion.
A berth can only have a single description in it at any time. You can have the same description in more than one berth at a time - for example, where you have 'blind berths' which exist to simplify things, or for 'last sent' or 'approaching' berths, the contents of which are sent to fringe signal boxes.
Berth numbers aren't unique on their own, but the TD area and berth number is unique and can be used as a primary key. You might be better off building a mapping of berths to descriptions rather than the other way around.
A berth can only have a single description in it at any time. You can have the same description in more than one berth at a time - for example, where you have 'blind berths' which exist to simplify things, or for 'last sent' or 'approaching' berths, the contents of which are sent to fringe signal boxes.
Berth numbers aren't unique on their own, but the TD area and berth number is unique and can be used as a primary key. You might be better off building a mapping of berths to descriptions rather than the other way around.
There still seems to be a blackout overnight though so you won't get many messages even if there are train movements.
That blackout is a problem for me - http://www.opentraintimes.com/maps/signalling/WS/1 still says the date is 30th September, and come the morning, some of the previous night's ECSes are 'stuck' in berths.
I tried making berth name and area the PK for a berth and that certainly helped. Good to have that confirmed as the right decision
I'll make the relationship the other way round and see how it goes from there.
The technical barriers seem to be minute compared to understanding the domain knowledge
Thank you for your help.
I'll make the relationship the other way round and see how it goes from there.
The technical barriers seem to be minute compared to understanding the domain knowledge
Thank you for your help.
Last edited:
I requested an account on the wiki (http://wiki.openraildata.info) some time ago but it was never activated, is there someone processing the account requests?
Update on progress handling the TD feed:
I've added the area code to Berth and Descriptor in my schema, and the picture looks a lot better.
However, I am getting Descriptors forcibly removed from their Berths when a Berth Step comes in for a different Descriptor.
Examples I have come across are (Area-Berth): WH-COUT, XZ-COUT, AW-GB18, ML-M145
Are these berths special? COUT sounds like a definite candidate for a special case, but I'm less sure of GB18 and M145.
Just checked the berth step csv reference data: GB18 is RICHMNDNL station, M145 is NEWTON station. Perplexed...
Thanks for any suggestions.
I've added the area code to Berth and Descriptor in my schema, and the picture looks a lot better.
However, I am getting Descriptors forcibly removed from their Berths when a Berth Step comes in for a different Descriptor.
Examples I have come across are (Area-Berth): WH-COUT, XZ-COUT, AW-GB18, ML-M145
Are these berths special? COUT sounds like a definite candidate for a special case, but I'm less sure of GB18 and M145.
Just checked the berth step csv reference data: GB18 is RICHMNDNL station, M145 is NEWTON station. Perplexed...
Thanks for any suggestions.
Last edited:
COUT does seem to be a special case as it doesn't seem to relate to a real berth, I don't know what it represents though. It always seem to be a "to-berth" as if the train is moving to an unknown berth.
Yes, except the wiki appears to have stopped sending approval requests to me.
I've sorted it now.
--- old post above --- --- new post below ---
From what I can work out, COUT is Clear-Out, STIN is Strike-In. COUT usually holds the last description that was stepped out of the area, STIN is a 'train approaching' advance warning.
The berths with letters at the start are generally berths from another TD area. For example, M145 in your example will probably be berth 0145 from an adjacent area.
Is it known for sure that COUT acutally holds anything and isn't just an equivalant of /dev/null? It seems that in IECC areas (although I haven't checked them all) there are no steps to COUT and instead there is a just a CB message for the last berth in the area.
Thanks Poggs and everyone for the additional info on berths. I'm still getting lots of descriptors being overwritten. Some are the special codes mentioned (COUT etc), some have letter prefixes, and some are all numeric.
I'm concentrating on front end visualisation of the TD feed now, so I'm taking a break from this problem. Thanks again.
- Status