Unknown Destinations of Trains

In many cases within the Arrivals feed for the tube, the destination of the train returned is ‘Check front of Train’ or similar. This is apparent on lines where the signalling system doesn’t return a destination to the Trackernet feed.

A thought occurred to me that this could be overcome by using the destination of the train itself rather than the signalling data. So, for example, on the Uxbridge branch where Met train destinations are unknown to the signalling system, the destination generated by the train itself could be used. This must surely be possible given that the leading car number and train numbers are returned to the system - these are unknown to the signaling and must therefore be taken from the train itself. So why not the destination too? This would be a much improved benefit to end users.

Another added benefit (fairly unique to the Met line) would be to return stopping patterns, where trains can be ‘All Stations’, ‘Semi Fast’ and ‘Fast’, another aspect that the API doesn’t currently factor in.

1 Like

@Weezer

Yes, I posted something similar…

I suspect that “Check front of Train” will continue on the SSR lines until their have been upgraded to the new signalling system.


image

1 Like

Indeed, you’re quite right - Met data in particular is poor and will be much improved when the signalling upgrade is complete.

In the meantime, using the destination generated by the train itself would seem a very quick and easy way to improve information for the end user of which there must be a huge number. And it wouldn’t just benefit the Met, either!

1 Like

From memory, I think the issue is that the provision of the destination information into the customer information systems is being done manually in a TfL control room somewhere.

I suspect the problem is lack of meatware to do the inputting.

1 Like

@briantist, @weezer Our Trackernet specialist advises:

In the example of the Uxbridge Branch there is no destination data received from the train, and the train/car number are only received because we overlay radio data on the signalling data (not 100% reliable, but reasonable in most areas). Only the new signalling is a solution for this, and the Uxbridge Branch is scheduled to be the very last phase of that in 2022/23.
Further, for some areas such as the Bakerloo North of Queens Park and the Wimbledon/Richmond branches of the District line, Network Rail are the primary data source that we rely on even if we try to embellish it in some cases, whilst for the Met line Harrow to Amersham LU is the primary source – that’s why the two will be seen to behave differently.

Hope this helps shed some light on the issues you’ve spotted.

2 Likes

@theochapple Thanks.

So will the issue with the “Amersham to Moor Park” that I highlighted in the other post I made get sorted when the SSR signalling gets done?

It’s just that Amersham, Chalfont & Latimer , Chorleywood, Rickmansworth and Harrow on the Hill have very poor in-station and API-level destination data.

1 Like

Indeed - Chiltern trains aren’t shown in the API but I can’t understand why as Trackernet does see them. Also can’t understand why it’s not possible to get the stopping pattern of a Met train either.

But with thanks for your reply

1 Like