The StatusDetails for some disruptions seem to be missing when checking line statuses in TrackerNet. The current disruption on the District line is properly summarised in the details attribute, but the details for the Circle, H&C, Metropolitan, W&C, and Overground disruptions are empty, as shown below:
District
<LineStatus ID="2" StatusDetails="Severe delays between Earl's Court and Wimbledon due to a track fault earlier at Wimbledon Park. Tickets are being accepted on London Buses. No service between Edgware Road and High Street Kensington due to planned engineering work. GOOD SERVICE on the rest of the line.">
...
<Status ID="PC" CssClass="DisruptedService" Description="Part Closure" IsActive="true">...</Status>
</LineStatus>
That would make sense if the District line status wasn’t present. Especially considering the same bit of track is closed for the Circle and District lines (Edgware Road to High Street Kensington), but it’s only reported for the District line in TrackerNet.
Yes, the section of track including Edware Road, Bayswater, Paddington (Circle) and Notting Hill Gate.
The line statuses have obviously cleared now because the engineering work was limited just to the weekend, but the District line had a TrackerNet status message for this closure (“No service between Edgware Road and High Street Kensington due to planned engineering work.”), whereas the Circle line status was completely empty (see first post for the original TrackerNet responses).
I guess the issue for the Circle Line is that it’s 99% a virtualize service: it has 300 meters of excusive track between Aldgate and Tower Hill and another 400 meters between South and High Street Kensington.
Combined with the fact that 25% of the trains running where it does run perhaps leads TfL to under-represent warnings as they are only echoing messages for the other three lines.
Trackernet is really supposed to have been superseded by the “unified” APIs. Clearly, however, there is data in Trackernet that isn’t in the unified API, especially information about terminals which was a bit of an oversight.
Yeah the unified API did show all the messages. I would have expected both to show the same information when I chose between the two, going with TrackerNet because of the extra information that you’ve mentioned.
The main reason that pushed me over the edge to pick TrackerNet is that they show statuses for different branches of a line rather than just showing one message for the whole line.
Having work on this kind of thing for a while, it’s certainly a challenge for all concerned that it seem clear a user of a service that it can be sub-divided into smaller units, but in fact it’s very, very hard to code these in a way that can be understood by control staff AND the public.
The railway signals people can allow services to run in two sections and they can use the crossovers and sidings to cut trains short. This is annoying to do and safe.
But… how do you communicate this? It turns out to be a challenge because the travelling don’t really pay much attention to their route beyond:
where do I get on?
where do I get off?
how many stops/how long does it take?
Saying “we will run some trains between X and Y and also A and B, use local buses to connect between Y and B” is actually hard to code and even harder to explain.
And this is a simple example on a service without branches.
