Countdown feed - diverted routes / closed stops

Legacy feeds
1

On the 30th July at approx. 09:00 I noticed that Moorgate was closed between London Wall and Bank of England in both directions. When I looked at bus routes 21, 43 and 141 in our app (which uses the legacy Countdown feed (as it’s better :wink: )) I was surprised to see stops were being omitted on the section of route not being served (Great Swan Alley & Bank Station/Princes Street). Later in the day (lunchtime IIRC) the road closure was over and the omitted stops were being shown again. Is this something new? Is it being done for all diversions?

Thanks in advance,

Simon

2

Hi @SJCooper That’s news to me too! I’ll check on that with the team working on Countdown. In the meantime, it would be good to know why you think the legacy feed is better than the Unified API so we can look at potential improvements in future. Please share your thoughts with us here. Thank you!

3

@SJCooper My colleagues in Surface have advised that if a closure or diversion is planned and lasts over 6 weeks then it should be reflected in the updated bus schedules but if it’s shorter than that it needs to be added to the system manually. The team in our Network Management Control Centre add as many diversions and closures to Countdown as they can but the sheer volume of notice of events they have to deal with means that they are only able to add in those that have the most impact. Given this closure was at peak time in a very busy part of the city, it’s likely it was selected as a priority to add into Countdown. We are working on developing a new system that will automate and digitize the current very manual process for adding notice of events to Countdown and our other data feeds. You should see further improvements to the number of planned disruptions that are represented in Countdown once that system has launched (date TBC!)

4

Hi Theo,

Sorry, I meant to reply a while back and got… sidetracked. :frowning:

Regarding my comments on the Unified API vs the legacy Countdown feed, it’s simple - the former returns too much information which isn’t always needed…

As an example, we want to know the next bus arrivals at a stop and the (basic) data we need to present to our user is route number, destination, bus registration and how long until it arrives.

I’m going to use the stop shown on https://api-portal.tfl.gov.uk/docs under “Arrival predictions (countdown/trackernet) for a stop”, 490005183E and use the example URL given on that page:

<Unified_URL>/StopPoint/490005183E/arrivals

and for the Countdown legacy feed:

<Countdown_URL>/instant_V1?StopCode2=490005183E&returnlist=lineID,linename,registrationnumber,destinationname,estimatedtime

At the time of writing I’ve run both queries (and within a second or two of each other) the former returned 2,664 bytes of data and the latter 197 bytes! Do we really need the stop ID repeated for every bus arrival, the stop name, the ‘platform name’ (stop point indicator in legacy feed talk), towards or mode name?

I’ve tried the same queries against a stop at St Pancras - 490004722A, 11,908 bytes vs 729 bytes. I wonder what the difference is during the peak?

(As a passenger I have a similar complaint about Journey Planner on the TfL Website, say I want to get from one Underground station to another oddly enough by tube, I can de-select every other mode of public transport but you insist on giving me walking information, cycle hire and cycle information. Why? All you’re doing is wasting computing power on travel options I’m (potentially) not interested in)

Regards,

Simon

5

I agree with @SJCooper that the legacy api is better. I was wanting to switch my app to the unified and even use the signalr streaming api, but in order for me to do this the unfied api would have to offer at least the same data set as the legacy countdown api.

The tripid in particular can be used to string journeys together but there is nothing equivalent in the unified api.