RealTimeTrains website

[notverydeep]

Apologies if this is the wrong place to ask. I have been trying out the Real Time Trains API to get some data for trains passing through various locations to determine the spread of observed headways.

While the train 'actual' reports on the site are shown resolved to the nearest 15 seconds in many cases, however the data for the same movements from the API are only to the nearest minute (the documentation page indicates this giving the format of realtimeArrival, realtimeDeparture and realtimePass detailed as HHmm). Is anyone able to advise if the values to the nearest 15 seconds or better the nearest second can be obtained as that would significantly improve the accuracy of a capacity calculation / graph? Many thanks for any assistance...

 

[Woolly]

GB Railfreight from last week

Tom, would you happen to know if Caledonian Sleeper locos are included, as they are GBRF locos? They don't seem to be showing up at present on the RTT system.

 

[Muzer]

Tom, would you happen to know if Caledonian Sleeper locos are included, as they are GBRF locos? They don't seem to be showing up at present on the RTT system.

They are not currently available, presumably as Caledonian Sleeper the TOC would need to agree to them being shown. In general, whether or not the locos are shown depends on which operator is down as operating the service, not who owns the locomotives. So GBRf locos on Colas or CS services won't show, but equally other TOCs' or FOCs' locos on GBRf services will show.

 

[Woolly]

They are not currently available, presumably as Caledonian Sleeper the TOC would need to agree to them being shown. In general, whether or not the locos are shown depends on which operator is down as operating the service, not who owns the locomotives. So GBRf locos on Colas or CS services won't show, but equally other TOCs' or FOCs' locos on GBRf services will show.

That makes sense, thanks.

 

[_toommm_]

I've not seen this at any other station so I'm not sure if it's a RTT thing or an area-based thing; but some services terminating at Sheffield in the evening never have an actual arrival time; with the last report often being at Nunnery Main Line Jn.

Here are a few examples:

https://www.realtimetrains.co.uk/train/Y21900/2020-03-12/detailed
https://www.realtimetrains.co.uk/train/Y61558/2020-03-12/detailed

 

[The_Train]

I've not seen this at any other station so I'm not sure if it's a RTT thing or an area-based thing; but some services terminating at Sheffield in the evening never have an actual arrival time; with the last report often being at Nunnery Main Line Jn.

Here are a few examples:

https://www.realtimetrains.co.uk/train/Y21900/2020-03-12/detailed
https://www.realtimetrains.co.uk/train/Y61558/2020-03-12/detailed

I've seen this with some freight/light loco moves and I've just assumed them to have ventured into a different yard/siding or whatever in the same destination area and therefore not reported an arrival on RTT. Never seen it with a passenger service though

 

[greatkingrat]

They were both booked to use platform 6, so possibly some sort of track circuit failure meaning arrivals on that platform weren't being reported?

 

[louis97]

I've not seen this at any other station so I'm not sure if it's a RTT thing or an area-based thing; but some services terminating at Sheffield in the evening never have an actual arrival time; with the last report often being at Nunnery Main Line Jn.

Here are a few examples:

https://www.realtimetrains.co.uk/train/Y21900/2020-03-12/detailed
https://www.realtimetrains.co.uk/train/Y61558/2020-03-12/detailed

These trains stepped into a different TD berth within the station to normal. Looks like they arrived behind something already in platform 6. Unsurprisingly Network Rail have no data for this either, will get it sorted on RTT.

 

[Tom]

Can I add a bug report @Tom
The line "service forms 2E29 to Leeds" is incorrect and should display "service forms from ..."
The service does form 2E29 to Leeds on arrival at Manchester Victoria.
The "forms from" displays correctly prior to the train activity beginning.

This is now, finally, fixed.

It has taken about a year to get to this point so don't expect to see any more operators anytime soon barring a sudden opening of the flood gates from the industry and all operators dropping their allocations suddenly.

When I wrote this post I did actually know ScotRail was coming but wasn't entirely sure of when... I can however confirm now that there are no more arrangements with other TOCs at present.

Is anyone able to advise if the values to the nearest 15 seconds or better the nearest second can be obtained as that would significantly improve the accuracy of a capacity calculation / graph? Many thanks for any assistance...

They are available on a commercial arrangement or for some academic use. Please email [email protected] to provide more information.

Tom, would you happen to know if Caledonian Sleeper locos are included, as they are GBRF locos? They don't seem to be showing up at present on the RTT system.

We have allocations specifically from ScotRail and GB Railfreight for their services. The data feeds will show the appropriate allocations for those services regardless of where the loco originates from. The reverse applies too, as @Muzer said.

 

[ScottDarg]

Caledonian Sleeper have joined ScotRail and GBRf in showing allocations on the site: https://blog.realtimetrains.com/2020/03/caledonian-sleeper-allocations/

I’m pleased to announce that Caledonian Sleeper have become the next operator on the national network to publish their allocations on Realtime Trains.

Caledonian Sleeper are the second passenger operator, and third operator on the national network, to publish their allocations. Locomotive allocations for Caledonian Sleeper services will appear on the detailed pages from today, 15 March.

We wil be rolling their services into Know Your Train in the future

Example being tonights 5S95 empty stock for the Highlander. RTT showing 92028 and 92020 allocated to this: https://www.realtimetrains.co.uk/train/C75054/2020-03-15/detailed

Doesn't seem to be showing the locos for the later Class 1 services yet (e.g. 1M11, 1S25). However, 1M16 from Inverness is showing 66727 and 73969 to Edinburgh: https://www.realtimetrains.co.uk/train/C36781/2020-03-15/detailed

 

[Tom]

Following the government advice earlier, I've taken the decision to not release any further features targeted solely at railway enthusiasts. I feel as if there is a likelihood that releasing further features I have in the works will cause an increase in un-necessary travel which is obviously at an opposition to the current advice.

I'll keep working away at it and have stuff for release when we're in a better place as a country

 

[D6700]

Good man

 

[samuelmorris]

Perfectly reasonable - anyone out 'bashing' or just looking for railway days out at the present time clearly hasn't got the message.

 

[Condor7]

Perfectly reasonable - anyone out 'bashing' or just looking for railway days out at the present time clearly hasn't got the message.

While I don’t disagree in the need to be responsible at the moment, and certainly ‘bashing’ would be unnecessary travel, but for others the railways run through a great many areas of countryside where someone could easily watch or photograph trains without coming into close proximity to others, or other areas where you could simply park up and watch from your car.
Obviously should we go into lock down then we would have to think again, but I am certain then many more will avail themselves of Rail Cam to get their ‘fix’.

 

[Chris217]

I seem to notice when searching through more train information for various freight trains,it shows the actual locomotive number operating the service in question,but only on GBRF services,notably the Drax-Liverpool corridor biomass trains.
Just wondering why DBS or any other operators trains dont show that information?

 

[PG]

Just wondering why DBS or any other operators trains dont show that information?

If you read back a bit in the thread post #318 explains why.

 

[Tw99]

I've a vague memory that this has been discussed before, but if it is, I certainly can't find it, or remember the answer. I've noticed some STP services that aren't displaying all the intermediate reporting points. For example this train:

Realtime Trains - 555S 0736 Ely Mlf Papworth Sidings to Newport Docks (Simsgroup)

Realtime Trains provides live realtime running information for the Great British railway network using open data.

www.realtimetrains.co.uk

which leaps from Reading High Level Jn to Goring&Streatley, missing out Tilehurst, Pangbourne . Any comment or insight from the team ?

 

[pdeaves]

I've a vague memory that this has been discussed before, but if it is, I certainly can't find it, or remember the answer. I've noticed some STP services that aren't displaying all the intermediate reporting points. For example this train:

Realtime Trains - 555S 0736 Ely Mlf Papworth Sidings to Newport Docks (Simsgroup)

Realtime Trains provides live realtime running information for the Great British railway network using open data.

www.realtimetrains.co.uk

which leaps from Reading High Level Jn to Goring&Streatley, missing out Tilehurst, Pangbourne . Any comment or insight from the team ?

It's running main line and the intermediate places are only timed on the relief lines, I believe. At least Pangbourne does not have platforms on the main lines. That doesn't explain Burnham appearing, though.

 

[Tom]

The system decided that the path at that point was somewhat impossible. It's timed 5 minutes to do 8 miles 10 chains which is 97.5mph. The path is timed at 75mph and the metrics it uses to try and verify it still found it doing an average 81.5mph which is outside its tolerances, so it didn't infill between those paths. The assumption is that the timed speed on TPS paths should be validated and 'possible' so if the mileage engine can't work out a route that works within the pathing speed then it must be missing something...so it doesn't infill between those locations. In this case, the path is just crud.

 

[800002]

In this case, the path is just crud.

I was rather hoping to get that in first!

 

[800002]

@Tom
Actualy, ive just had a thought about deleted Timing Points from TPS to enable schedule publishing. IIRC the publication limit is 150 points (nessessitating some of the ultra long AXC schedules to have some of their non-mandatory timing points deleted to enable publication downstream.

Do those deleted Timing Points then reappear in the published schedule after having been effectively reconstituted by the system?
Thanks in advance.

 

[Tw99]

The system decided that the path at that point was somewhat impossible. It's timed 5 minutes to do 8 miles 10 chains which is 97.5mph. The path is timed at 75mph and the metrics it uses to try and verify it still found it doing an average 81.5mph which is outside its tolerances, so it didn't infill between those paths. The assumption is that the timed speed on TPS paths should be validated and 'possible' so if the mileage engine can't work out a route that works within the pathing speed then it must be missing something...so it doesn't infill between those locations. In this case, the path is just crud.

Thanks for the quick reply Tom - that makes sense.

 

[The Planner]

@Tom
Actualy, ive just had a thought about deleted Timing Points from TPS to enable schedule publishing. IIRC the publication limit is 150 points (nessessitating some of the ultra long AXC schedules to have some of their non-mandatory timing points deleted to enable publication downstream.

Been happening for years, unlikely to be solved anytime soon. It used to be worse as the limit was lower.

 

[Tom]

Actualy, ive just had a thought about deleted Timing Points from TPS to enable schedule publishing. IIRC the publication limit is 150 points (nessessitating some of the ultra long AXC schedules to have some of their non-mandatory timing points deleted to enable publication downstream.

Do those deleted Timing Points then reappear in the published schedule after having been effectively reconstituted by the system?
Thanks in advance.

The system that RTT applies is based on an internal geographic model of the network. It will infill anywhere it feels suitable, so if a timing point has been removed upstream it may well get readded by the infill process but potentially with different times as this data does not come down into the CIF I would expect.

I think the longest normal schedule RTT has is somewhere in the region of 450-500 timing points.

 

[800002]

The system that RTT applies is based on an internal geographic model of the network. It will infill anywhere it feels suitable, so if a timing point has been removed upstream it may well get readded by the infill process but potentially with different times as this data does not come down into the CIF I would expect.

I think the longest normal schedule RTT has is somewhere in the region of 450-500 timing points.

Thanks Tom,
Must say I didn't think to go looking for an RTT schedule of such length to confirm my thought.
Your answer certainly sounds intriguing and perfectly sensible.

 

[DavidGrain]

My question is about the collection of data. Are there transponders at the reporting points which pick up a signal from the train? Does the train report its geocoordinates? I am presuming that the driver has to input the train reporting number at the start of every journey.

Not concerning RTT, so this is just a comment. On the maps on Raildar and Tracksy, I have watched trains which have not moved for a while being runover by the following train.

 

[pdeaves]

Are there transponders at the reporting points which pick up a signal from the train?

It's done by trains occupying signalling track circuits.

 

[Belperpete]

My question is about the collection of data. Are there transponders at the reporting points which pick up a signal from the train? Does the train report its geocoordinates? I am presuming that the driver has to input the train reporting number at the start of every journey.

Not concerning RTT, so this is just a comment. On the maps on Raildar and Tracksy, I have watched trains which have not moved for a while being runover by the following train.

These systems all derive their information from the signaller's train describer system, which shows each signaller the train description (aka 4 digit reporting number) of each train under their control. The description is usually entered by the signaller at the start of each train's journey, although sometimes this may be automatic (e.g. at a terminus, the system may automatically convert the incoming description to the outgoing description). The description then steps from signal to signal as the train progresses. The step usually happens when the train occupies the track-circuit immediately beyond each signal, subject to various conditions (such as the signal being off). If for some reason, the conditions are not met, then the description will not step, and the train will effectively leave its description behind. The description will then stay where it is until overwritten by the next train to arrive, or the signaller clears it.

If the train describer system detects a train moving from one signal to another, but there is no description entered for it (e.g. because the train has left its description behind) then it will automatically put in a special "not described" code (such as ****), and alert the signaller. The signaller may also enter descriptions as a reminder, e.g. OOU* or *T3* when a line is blocked.

 

[theironroad]

These systems all derive their information from the signaller's train describer system, which shows each signaller the train description (aka 4 digit reporting number) of each train under their control. The description is usually entered by the signaller at the start of each train's journey, although sometimes this may be automatic (e.g. at a terminus, the system may automatically convert the incoming description to the outgoing description). The description then steps from signal to signal as the train progresses. The step usually happens when the train occupies the track-circuit immediately beyond each signal, subject to various conditions (such as the signal being off). If for some reason, the conditions are not met, then the description will not step, and the train will effectively leave its description behind. The description will then stay where it is until overwritten by the next train to arrive, or the signaller clears it.

If the train describer system detects a train moving from one signal to another, but there is no description entered for it (e.g. because the train has left its description behind) then it will automatically put in a special "not described" code (such as ****), and alert the signaller. The signaller may also enter descriptions as a reminder, e.g. OOU* or *T3* when a line is blocked.

The step usually happens when the train occupies the track-circuit immediately beyond each signal, subject to various conditions (such as the signal being off). If for some reason, the conditions are not met, then the description will not step, and the train will effectively leave its description behind. The description will then stay where it is until overwritten by the next train to arrive, or the signaller clears it.

Very interesting write up. Thanks.

Is this why sometimes on open train time maps and traksy that a tsid stays on the map in a berth long after the train has moved elsewhere, occasionaly with the same tsid appearing in two locations. I've always assumed that a data link has broken or frozen.

 

[takno]

The step usually happens when the train occupies the track-circuit immediately beyond each signal, subject to various conditions (such as the signal being off). If for some reason, the conditions are not met, then the description will not step, and the train will effectively leave its description behind. The description will then stay where it is until overwritten by the next train to arrive, or the signaller clears it.

Very interesting write up. Thanks.

Is this why sometimes on open train time maps and traksy that a tsid stays on the map in a berth long after the train has moved elsewhere, occasionaly with the same tsid appearing in two locations. I've always assumed that a data link has broken or frozen.

The data link itself does come and go in terms of reliability, and we will sometimes lose a few minutes data.

There are also a couple of other issues related to turning the output from a number of different signal-boxes into a single map. A train typically appears in a signal box in an "approaching" berth 2 or 3 signals before it leaves the area controlled by the previous box. This approaching berth often then doubles up as the berth for the first real signal in the box. At the other end, as soon as a train has passed out of the area it tends to go into a "last-sent" berth. For some boxes the last sent berth is a copy of the first berth from the next signalbox, and clears quite quickly, but for other boxes it will stay there until it is passed over by another train.

At Traksy we handle that in one of three different ways. The first is to pretty much just not handle it at all, show the boundary berths and let the user figure it out. The second is to just draw one of the signals on the map and hope for the best - that usually works fine in ROC-controlled areas, but as you can see at the Peterborough-Kings Cross fringe it's sometimes a mess. The third way is to mangle the feed and infer our own "virtual" berth from a combination of the "approaching" and "last-sent" berths and the surrounding signals. The third way is most effective, but tends to be quite bespoke for different areas, and is often more fragile when the feed changes, or when signallers manually interpose a train into their area