Errors on TfL's Earls Court live Tube information page

This TfL operated tube information page contains incomplete and/or incorrect information about train arrivals and needs to be fixed:

For example:

  1. On refreshing the page, some trains disappear and then re-appear. The ones I have noticed have been Due but this may be coincidence.
  2. Trains to Richmond and Ealing Broadway (District Line westbound) do not appear to show consistently
  3. Arrivals shown for Earls Court are not consistent with information for (the same) trains arriving at Gloucester Road which then pass through Earls Court a few minutes later. Compare Earls Court page linked above with the equivalent page for Gloucester Road here: https://tfl.gov.uk/tube/stop/940GZZLUGTR/gloucester-road-underground-station?lineId=circle,district
  4. This message shows frequently for the Earls Court page at times when the information on the same trains is shown on the e.g. Gloucester Road equivalent page:
    Live Updates
    Live updates are not available for this location at the moment. Please see [Timetables] to check the frequency of your service.

hi @LDN - welcome to the forum and apologies I seem to have missed this message when it was first posted.

It appears that this relates to a known issue with the consumption of predictions into our API from the source system (TrackerNet).

Thanks for notifying us of this as we weren’t aware it affecting Earl’s Court.

The issue is when the Destination Code is not defined (D=“0”) and we can’t currently map to a destination in the Unified API. We’re expecting a 3 digit code as seen in some predictions on Platform 4 towards Wimbledon.

<S Code="ECT" N="Earls Court.">
<P N="Eastbound - Platform 1" Code="1" Next="0">
<T S="025" T="4" D="0" C="3:00" L="Between Barons Court and West Kensington" DE="Upminster" AT="10:20:46" DT="10:21:07"/>
<T S="001" T="4" D="0" C="7:00" L="Left Ravenscourt Park" DE="Upminster" AT="10:25:14" DT="10:25:57"/>
<T S="026" T="4" D="0" C="13:00" L="At Chiswick Park Platform 2" DE="Upminster" AT="10:30:44" DT="10:31:05"/>
<T S="027" T="7" D="0" C="23:00" L="At Ealing Broadway Platform 9" DE="Upminster" AT="10:40:44" DT="10:41:05"/>
</P>
<P N="Eastbound - Platform 2" Code="1" Next="0">
<T S="077" T="10" D="0" C="0:30" L="Between West Brompton and Earls Court" DE="Edgware Road" AT="10:18:19" DT="10:18:40"/>
</P>
<P N="Westbound - Platform 3" Code="0" Next="0">
<T S="006" T="6" D="0" C="1:00" L="Between Gloucester Road and Earls Court" DE="Richmond" AT="10:18:26" DT="10:21:12"/>
<T S="033" T="3" D="0" C="5:00" L="At Sloane Square Platform 1" DE="Ealing Broadway" AT="10:22:41" DT="10:26:12"/>
<T S="007" T="5" D="0" C="10:00" L="Approaching St James's Park Platform 1" DE="Richmond" AT="10:27:41" DT="10:31:12"/>
<T S="034" T="5" D="0" C="15:00" L="At Temple Platform 1" DE="Ealing Broadway" AT="10:32:55" DT="10:36:12"/>
<T S="125" T="504" D="0" C="20:00" L="Lillie Bridge Depot" DE="Olympia" AT="10:37:34" DT="10:37:55"/>
</P>
<P N="Westbound - Platform 4" Code="0" Next="0">
<T S="074" T="8" D="500" C="-" L="At Platform" DE="Wimbledon" AT="10:18:03" DT="10:21:42"/>
<T S="063" T="5" D="0" C="8:00" L="At Victoria Platform 1" DE="Wimbledon" AT="10:25:35" DT="10:26:42"/>
<T S="075" T="10" D="500" C="11:00" L="At Paddington Platform 1" DE="Wimbledon" AT="10:28:29" DT="10:31:42"/>
<T S="125" T="501" D="0" C="16:00" L="Lillie Bridge Depot" DE="Parsons Green" AT="10:33:33" DT="10:33:56"/>
<T S="054" T="7" D="0" C="18:00" L="Left Mansion House" DE="Wimbledon" AT="10:35:35" DT="10:36:42"/>
</P>

This behaviour seems to be related to the data returned from the new signalling delivered by the 4 Lines Modernisation programme. We are working with our colleagues in the team that supports Trackernet to come up with some options around these cases.

I’ll update here when we have a plan to address this.

Many thanks,
James

Thanks for the feedback, James! Appreciate that.

If it helps prioritise the fix, the information on the TfL web page for Earls Court seems to be wrong, perhaps for the same reason! Citymapper seems to have noticed this problem and have a workaround and show what appears to be more accurate information.

I think they might be using the Trackernet feed directly as the issue is with case that our API importer can’t currently handle.

Many thanks,
James