RealTimeTrains website

[samrammstein]

It now appears that CrossCountry allocations are being displayed on RTT.

 

[Scotrail314209]

It now appears that CrossCountry allocations are being displayed on RTT.

As of yet, they don't appear to show the Turbostars.

Looks like that Tweet about XC not giving out allocations didn't age well.

EDIT: Just after I posted this, the Turbostars began showing up on RTT.

 

[ABB125]

Excellent! Great job

 

[XAM2175]

All XC services apparently, including allocations for HST powercars!

CrossCountry now tells you

Don’t tell them, but CrossCountry are the fifth train operator to join Know Your Train. It now covers 31,000 train services covering over 1.5 million miles every week between the five participating operators.

blog.realtimetrains.com

Correct. Just carriage numbers I used https://live-departures.info/rail/dppc/manchester-piccadilly etc for. Glad to see RTT now has carriage numbers and other additional facilities.

For the avoidance of the same type of doubt that occurred when you first posted this - the Live Departures site is showing the number of carriages in the train, while RTT is showing the train formation and unit numbers. Neither are showing the actual TOPS number of each carriage (for which "vehicle number" might be the more generally-understood term).

 

[Trainfan2019]

Love it now northern and cross country train details are now showing. Well done! Just waiting for LNW and EMR now at some point in the future.

 

[TC60054]

Not the EMR 153s hired for the Cleethorpes to Barton-on-Humber services yet though. I'm sure it's on the to do list though and I'm not grumbling as it's a brilliant update

The Barton ones are now showing, complete with diagram in EMT colours.

 

[ainsworth74]

Looks like that Tweet about XC not giving out allocations didn't age well.

It would seem XC appear to have realised this themselves:

https://twitter.com/CrossCountryUK/status/1319563198740205570?s=20

Jan 2020: #DontTellCrossCountry
Oct 2020: #CrossCountryTellsYou

We're excited to team up with @RealtimeTrains to provide you with real-time unit formations and allocations via https://realtimetrains.co.uk

Know how long your train is, and where to find your seat, before you board!

 

[Tom]

As if we weren't going to play that up today. The entire fact that we have train allocations publicly available now, to this degree, is that furore at the beginning of the year. My first discussion with ScotRail was literally the day after.

Know Your Train now covers 5 train operators, including the second and third largest by service and mileage count and two major long distance operators, with a further 2 publishing train allocations. All told, in terms of passenger services it now actually covers over a quarter (it's just over 27%) of passenger service mileage. All that in 7 months - a lot of things have fallen into place at the right time but I think it's pretty damn good.

Anyone noticed the little quirk that Class 331 EMUs seem to come up as " Pathed as Electric locomotive, trailing load 331 tonnes at 100mph "?

The timetable data has started massively disagreeing with the specification that comes out for it, it should be EMU331 really rather than E331, so I've added that to the todo list to add for mappings

Speaking of 331s, some Blackpool North to Hazel Grove are omitted today. Some others are saying 3-car on RTT but not on Journey Check.

The Barton ones are now showing, complete with diagram in EMT colours.

There is an issue, as noted in the Limitations bit on the Know Your Train help page, which results in some units not appearing at all. If a service is allocated with these units in formation then the message to tell me this is not generated. This can cause issues where no allocations are shown all day or, if there is service disruption, then incorrect units can be displayed following diagramming changes.

This is something that we are aware of and decided to proceed anyway as it affects a small number of services overall per day but I am working with industry partners, as the delivery of data for some operators involves multiple industry entities, to resolve this. It is in hand and we are working to solve it... if it was just RTT then it would have been fixed within about 15 minutes of me working out the problem... but we are waiting for a fairly major industry supplier to make a change.

 

[Bletchleyite]

This is all rather good - and I'd hope to see you get some business for providing it for the "new generation" PIS displays...like the likes of DB and SBB have done for 20+ years

 

[43096]

This is all rather good - and I'd hope to see you get some business for providing it for the "new generation" PIS displays...like the likes of DB and SBB have done for 20+ years

I've thought for some time that PIS displays should be linked in with RTT. It would do away with situations like planned diversions where the PIS can't cope because the amended calling pattern isn't in the on-train system, which of course means the PIS is just switched off (and the train is then technically not PRM compliant).

 

[Roger B]

Love RTT. Thanks for all the hard work that's gone (and going!) into it. Really appreciated.

Just one minor point (and I daresay you're already aware - sorry if this has been discussed up-thread):

When the 'Quick Search' can't find anything it displays the following message:

'We cannot find any allocations for that rolling stock.

This system currently has the following constraints:

• It can only search for supported operators that share train allocation data, the full list is available here
• It will only search for services that have departed today'.

That isn't quite accurate, because at 12.30 today it was showing 385041 as allocated for 5N93, leaving Eastfield at 16.18 for Glasgow QS. I've also noticed similar instances, where the train has yet to depart. So perhaps the second bullet point needs revising to state that it will only search services for which an allocation has been made, and that have not already completed their journeys, or some such wording. Hope this is helpful.

 

[Tom]

The expected behaviour is correct, by default the quick search only searches in the simple mode. Searching on any detailed mode page, or adding detailed to the end of a quick search query, shows 385041 on 5N93.

 

[Condor7]

Hi Tom. Now some TOC’s are providing more details, what would be the chances of ‘named trains’ being identified. The Northern Lights, The Highland Chieftain, etc. Thanks.

 

[Roger B]

The expected behaviour is correct, by default the quick search only searches in the simple mode. Searching on any detailed mode page, or adding detailed to the end of a quick search query, shows 385041 on 5N93.

Thanks Tom. I wasn't suggesting that the behaviour is incorrect, rather that the message is inaccurate. Eg using quick search for 195 118 a couple of minutes ago (at 08.14), shows it's on 09.21 BPL - YRK (1B22), which hasn't departed yet. And so the bullet point that 'It will only search for services that have departed today' doesn't seem to be true. Apologies if I'm misunderstanding something.

 

[TT-ONR-NRN]

Hi Tom. Now some TOC’s are providing more details, what would be the chances of ‘named trains’ being identified. The Northern Lights, The Highland Chieftain, etc. Thanks.

Why would RTT do this when not even the TOC uses these names anymore, other than the FS

 

[fishquinn]

Thanks Tom. I wasn't suggesting that the behaviour is incorrect, rather that the message is inaccurate. Eg using quick search for 195 118 a couple of minutes ago (at 08.14), shows it's on 09.21 BPL - YRK (1B22), which hasn't departed yet. And so the bullet point that 'It will only search for services that have departed today' doesn't seem to be true. Apologies if I'm misunderstanding something.

Comes down to this: using detailed mode will show you if it's allocated anything today and if it comes up with nothing then it's not allocated. The 0921 Blackpool-York is of course today so appears when searching as it's the next booked work for that train.

 

[Tom]

Hi Tom. Now some TOC’s are providing more details, what would be the chances of ‘named trains’ being identified. The Northern Lights, The Highland Chieftain, etc. Thanks.

Fairly unlikely I think. I wrote in support for it in a version of RTT that was never released back in 2014 but it actually became somewhat of a pain to track the updates to schedules in doing it.

Thanks Tom. I wasn't suggesting that the behaviour is incorrect, rather that the message is inaccurate. Eg using quick search for 195 118 a couple of minutes ago (at 08.14), shows it's on 09.21 BPL - YRK (1B22), which hasn't departed yet. And so the bullet point that 'It will only search for services that have departed today' doesn't seem to be true. Apologies if I'm misunderstanding something.

Thing is, I think the message is okay - as it won't appear if there is an allocation against a schedule. If a train is allocated to purely an ECS working, then it won't appear on a simple mode search then perhaps it's a bit misleading but if it's not in service then it's not of much use to anyone bar those trying to tick trains off for sight.... but at that point you'd be using detailed mode anyway?

 

[XAM2175]

Thanks Tom. I wasn't suggesting that the behaviour is incorrect, rather that the message is inaccurate. Eg using quick search for 195 118 a couple of minutes ago (at 08.14), shows it's on 09.21 BPL - YRK (1B22), which hasn't departed yet. And so the bullet point that 'It will only search for services that have departed today' doesn't seem to be true. Apologies if I'm misunderstanding something.

Could it be that what you want it to say is "It will only search for services that have departed or are scheduled to depart today"?

 

[Roger B]

Could it be that what you want it to say is "It will only search for services that have departed or are scheduled to depart today"?

Thanks XAM2175 - glad I'm not the only one who thinks there's something slightly amiss here. I like your suggestion - but I'm not sure whether it does search all services scheduled to depart today. It's certainly not the case that a simple search only searches services that have already departed - because it returns some services that have not yet departed. It may be that it will only search those services that have already departed, and those where a loco/unit has been allocated in the system to services, so it may depend on when allocations are input into the system. Most are probably input in the wee hours, and so would be included in searches, but there may be exceptions. It's also worth noting that simple search will return at most one working - ie current / next service, rather than all those allocated for a particular loco/unit that day, but I'm sure most people are aware of that.

 

[peters]

Something didn't work properly this morning, I'm not sure whether that was because Northern fed in inaccurate or incomplete information or whether there's a fault with the RTT system.

150107 left Manchester Piccadilly on the 06:38 service to Sheffield, departing 45 minutes late: https://www.realtimetrains.co.uk/train/C34805/2020-11-09/detailed#allox_id=0
But it also left Manchester Piccadilly with 150115 on the on the 07:09 service to Chester, departing 24 minutes late: https://www.realtimetrains.co.uk/train/C31923/2020-11-09/detailed#allox_id=0
Must have been a magic train.

It also seems 150107 and 150115 were reported as arriving at platform 11: https://www.realtimetrains.co.uk/train/C35585/2020-11-09/detailed#allox_id=1 but the late 07:09 service to Chester reporting as departing from platform 12, where RTT reported that 195122 had just arrived: https://www.realtimetrains.co.uk/train/C36320/2020-11-09/detailed#allox_id=0

 

[Tom]

That is likely a consequence of some units having issues with their allocations being broadcast, it means that set swaps onto them isn't reliable. As noted previously, it's being worked on by suppliers.

In other news, c2c is now available: https://blog.realtimetrains.com/2020/11/c2c-joins-know-your-train/

 

[BRX]

Here is something I see quite often on RTT (and it's usually with test train schedules, which of course are rather different to normal ones.

It's not hard to see what's happened. But in order for RTT to make this interpretation, it has to be OK with the concept that a train can get to a location in the schedule, earlier than it gets to the location before it. If RTT knew this was impossible, it wouldn't make the interpretation below.

I'm curious to know whether there's some kind of programming complexity that means RTT can't "know" about such an impossibility.

 

[alistairlees]

Here is something I see quite often on RTT (and it's usually with test train schedules, which of course are rather different to normal ones.

It's not hard to see what's happened. But in order for RTT to make this interpretation, it has to be OK with the concept that a train can get to a location in the schedule, earlier than it gets to the location before it. If RTT knew this was impossible, it wouldn't make the interpretation below.

I'm curious to know whether there's some kind of programming complexity that means RTT can't "know" about such an impossibility.

View attachment 86045

Just looks like a circular train problem with the front end not knowing how to interpret data in the API (as an educated guess)?

 

[BRX]

Just looks like a circular train problem with the front end not knowing how to interpret data in the API (as an educated guess)?

In this case not a circular route as such - but a reversal en route.

 

[Deepgreen]

In this case not a circular route as such - but a reversal en route.

Yes, but a scheduled reversal, and I do find it odd that the 'system' recognised the train in the return direction at many points where it didn't on the outward leg.

 

[swt_passenger]

Yes, but a scheduled reversal, and I do find it odd that the 'system' recognised the train in the return direction at many points where it didn't on the outward leg.

Those will be the correct times for the passing points in the outward direction, you’ll see the individual times are increasing going UP the list. I’ve seen it happen before when trains go back where they came from without changing IDs.

 

[BRX]

Those will be the correct times for the passing points in the outward direction, you’ll see the individual times are increasing going UP the list. I’ve seen it happen before when trains go back where they came from without changing IDs.

Yes, they quite obviously are - the question is why the system assigns them to the timings in the return direction. You'd think it would be trivial to compute that if you pass a point shortly after passing an adjacent point, it's more likely to correspond to the point immediately after that one in the schedule, rather than one later in the schedule which would require skipping a load of points inbetween and travelling at an implausible speed.

 

[takno]

Yes, they quite obviously are - the question is why the system assigns them to the timings in the return direction. You'd think it would be trivial to compute that if you pass a point shortly after passing an adjacent point, it's more likely to correspond to the point immediately after that one in the schedule, rather than one later in the schedule which would require skipping a load of points inbetween and travelling at an implausible speed.

You'd think it would be trivial, but the matching is done using the "expected time" data which is passed when an event occurs. There are lots of reasons the expected time in the event might not match the published timetable - a variation or short-term plan wasn't sent to the public feed for example, or the data was entered manually and incorrectly. If that's the case you've got to have your systems "guess" which event the update applies to. Here it looks like the rules which make that guess are less smart than your eyeballs, but then computer systems are just dumb rules that do what you tell them to - they can't just glance at the overall data and decide it looks silly. That means when you are coding them that you have to think through (or see) every form of silliness that can appear in the feed and make sure your rule set covers them.

I think my policy on Traksy is to just throw away reports that don't make sense, which is certainly easier to do, and in this case I don't have any reports logged for that train at those locations. That doesn't fit RTT's mission of providing as much detail as possible on each train however. Indeed you were able to get useful output here, even if you did have to stop and think it through a bit before you could correctly interpret it.

 

[Tom]

@takno has it about right. Circular train services or those with multiple reversals that are doing anything more than the very basics are complex. To the human mind, it's quite a straight forward problem and obviously you can read the gobbledegook that the algorithm chucks out and get something meaningful out of it. There's no basic API for this kind of data, it's streamed at you and you do your best to handle what you want to do to handle it.

I could do it the basic way and just, for these services, ingest the TRUST originated data only but there'd be another tree of code just to decide whether that decision should be taken or not.

However, this affects, at its worst, Autumn RHTT runs and test trains which in the grand scheme of things is very few train services. It'll get fixed at some point, but it's barely high up on the list of real problems ... other than for enthusiasts.

 

[nmbenson]

As an enthusiast, I am just so grateful that Real-time Trains provides such a vast amount of information, thank you