Hi, I’m new to this so forgive me if it’s been asked before. I have searched the forum though, particularly for advice on vehicleIDs that are “000” and the situation on the Met line right now doesn’t seem to fit the answers.
The problem relates to the ‘Arrivals’ API (https://api.tfl.gov.uk/Line/metropolitan/Arrivals) and it affects not just the app I’m tinkering with but all the commercial services, TFL and Citymapper.
Trains start from Aldgate with ‘sensible’ vehicleIDs, a clear destination and direction and send out arrival predictions for stops on their route. When they get to Harrow on the Hill, they disappear, to be replaced by a vehicleID of 000, no destination, no direction and put out predictions for every stop beyond Harrow, on every branch. This set of impossible promises gets sorted out in time, usually about five minutes, and the train will reappear - usually: sometimes with a new vehicleID, sometimes not. In particular the Amersham/Chesham trains may not make their mind up as to where they are going until the last minute, making the Amersham and Chesham arrival predictions quite random.
This obviously doesn’t affect the passengers, the Chesham train goes to Chesham. However if you look at the TFL or Citymapper boards, you’ll see train arrivals appearing and disappearing without warning or explanation and this is part of the reason why.
It might have something to do with driver changes at Harrow. It may just be the way that things are and we have to live with it. It does highlight something that would be useful in the Arrivals API (for a number of reasons) and that is some kind of ‘object permanence’. At the moment there’s no way of identifying a physical train - vehicleIDs could do this, but they change and are often duplicated, hence the problems above.
Would it be possible to add a field that gives a uniqueID for a physical train so it can be tracked (and spurious predictions ignored) over its journey?
hi @grahamwell - welcome!
From what I understand of the Trackernet source system, the setId (which we map to vehicleId in the API) is derived from the signalling systems. A value of 000 is shown where the setId cannot be derived from the signalling feed. Otherwise a 3 digit code relating to the timetabled service is assigned.
You often see a 000 when a line is disrupted and the service controllers adopt a more manual way of routing trains to get service patterns back to normal.
However in the case of the Metropolitan, I’ve been advised that setId cannot always be guaranteed, especially for trains that are located north of Preston Road.
I believe this will improve when the 4LM signalling is fully rolled out but I don’t think there is much that can be done in the current signalling configuration.
Thanks James, that’s helpful. I’m thinking aloud but - might it be possible to just ignore the update to a “000” id if you already have a valid vehicleID - particularly if that update is associated with the absence of a destination, direction etc. By all means indicate that the status has changed, but keep the identifying information?
The problem is that these “000” trains beyond Harrow all look the same. It’s not clear if the arrival predictions are coming from one train or more than one, so it’s a guess whether any particular entry is an update to an earlier prediction - and if so, which one … or a new prediction from a new service.
While writing this there was a signal failure between Wembly Park and Aldgate, which caused all the trains on that section to go “000” for a bit, but unlike the ones in the outer suburbs, they had direction and destination information, so it was possible to tell them apart (they’re back to normal now).
I don’t think we can do a lot with the data without upgrading the signalling & ingest of that.
The vehicleId is not actually the train’s physical number. It relates to a trip in the timetable and not the physical unit assigned to that trip. I think that there are some extra fields that could be consumed from the source data that may help distinguish the trains. e.g. http://cloud.tfl.gov.uk/TrackerNet/PredictionDetailed/N/BNK
I think we looked a while back about bringing these fields into the Unified API, but not sure what happened to this initiative (probably Covid!), but I’ll try to see if that’s still on the backlog.
Thanks again, I appreciate it. On a quick look at that XML file, it looks like ‘LeadingCarNo’ would totally solve the problem. TrainID too, but I’m not so sure what that is.
It’s worth reading this thread …
particularly @shortcut comment - explaining how they use a hybrid of LCID and other data to get a persistent train identifier. That led to @jwithers promising that this data would be exposed in the Unified API … sometime
The Metropolitan Line seems to have particular issues but - hey - it’s outside my window so I’m plugging on. In the TrackerNet detail feed the TrainIDs are very peculiar, flipping between two values every ten seconds or so. It’s almost as if there’s some extra data hidden in there.
Assuming that things on the line aren’t going to change, could I ask that both LeadingCarNo and LCID are exposed in the Unified API … please? TrackID would be really nice too.
In the meantime I’m not sure whether or not it’s worth putting in effort on the TrackerNet feeds (which are quite fun TBH) since they are threatened with retirement. Any timeframe on that?