I’ve noticed that in the Bus, Coach and River instant API feed bus services working as school extras (due to Covid) there are some routes with a ‘V’ prefix (e.g. V162). But in the Unified API these routes and workings do not exist. Why is this?
According to the Countdown feed documentation…
“LineID” “The identifier of a route. This is an internal identifier and is not equal to the route number displayed on the front of the bus / river bus. It should not be displayed to the public.”
LineName = "This is the route number that is displayed on the front of the bus / river bus and on any publicity advertising the route. "
LineID “V162” is the internal identifier and LineName for these same entries should show “162” which is what should be displayed on the buses. If you look at vehicles working the V routes in the Countdown feed, do you see the same vehicle registration numbers in the unified feed but working route 162?
Right now I see a London Overground replacement bus appearing in the instant feed: http://countdown.api.tfl.gov.uk/interfaces/ura/instant_V1?ReturnList=RegistrationNumber,LineID,LineName,StopPointName,StopPointIndicator,DestinationName,EstimatedTime,StopCode2&LineId=UL7
Now using one example on here, where the vehicle registration of the bus is SN59AWO and the LineName is LO-T:
As I recall (I wrote an app for MTR Crossrail, as was) iBus isn’t programmed to make predictions about replacement bus services. I recall the exact reason, but it’s possibly that it’s a combination of infrequency used routes, limited stop services or lack of funding to input the routes into the system.
iBus isn’t an AI, as you might expect, the code is hard-wired by “timetable people”.
Also, scheduled RRBS services for National Rail services also end up in NRE Darwin, so the likes of Google Maps can see them.
It’s interesting as I see drivers are still able to log into a rail replacement service so passengers can see what route their on and the upcoming bus stops (as with normal bus services). Some bus stops with eta screens also show rail replacement services due at a bus stop. You’d think these would use or contribute to the open data feed but I guess not.
ETAs are available for TfL Rail Replacement Services - as I type this at 22:25 on Sunday 29th November, there is route UL-24 running. LVF is showing predictions for Abellio 2424 (and others) currently on the route.
Countdown won’t provide an ETA, IIRC, if the vehicle is turned off i.e. on a stand between journeys or if the vehicle’s next stop is beyond the 30 minute window that Countdown works in which may be what affected @nathanodong’s original query - That vehicle appears to be at Walthamstow heading for Barking, could it be, for example, that it was due to leave Walthamstow in 29 minutes and therefore the next stop after Walthamstow was beyond that 30 minute limit. It seems here that the Countdown API did provide an ETA but the Unified API didn’t, that one I can’t explain!
@nathanodong, Why do the first query in the Countdown API and then switch to the Unified one?
RRS does indeed appear on the countdown signs. I personally saw the London Overground replacement service appear at a stop near Gospel Oak a few weeks ago. So ETAs must be coming from some feed somewhere (probably the Countdown API rather than the Unified API as @SJCooper mentioned.
I don’t see the point of querying the Countdown API for ETAs, then use the Unified API for everything else. I’d rather do one request than two. In my view, the Unified API should be providing everything as suggested in the name.
I haven’t checked, but do RRS buses appear in the ETAs at tube/train stations in the API rather than bus stops? Maybe I’ve been looking in the wrong place.
They are shown at the bus stops themselves in the screen grab posted above.
If the buses do appear on relevant Countdown screens, do they show the route “UL24”? The buses themselves usually show “A”. “B” or similar on a clipboard in the front of the bus when I have seen them. I have a feeling that “UL24” is meant to be an internal TfL designation but it has clearly escaped into the public domain; I’ve seen it on Google maps info about bus stops. Seems to me it would be sensible to display the same route number everywhere, particularly when (as some do) the service runs for several weekends rather than one.
However, usually the routes are labeled, as you say, with letter when you see the notices in tube stations when there’s a closed notice. Confusingly they usually use a the first letter of the line that’s closed which can clash (DLR/District, Central/Circle) and there are already services starting with “D” too.
I’ve changed my application to only use the Unified API now. I used to use the Legacy feed to get a snapshot of all vehicles in service, but the extra processing I had to do was slow and complicated. I tried to do this via the Unified API but kept receiving errors. Since the dev portal opened back up again it has seemingly gotten better
If you want a feed of data to use, use the Legacy system as you can leave the call open 24/7 and consume the whole data feed. It’s simple httpd digest so it’s very easy to code up if you want everything when it happens.
If you want one-off data to display in direct response to a user input, use the Unified API.
It is possible to to use the Unified API as a streaming input to consume the whole feed, but you have to be using .NET SingalR. Scroll down to “Time on my side” in
I’ve tried using the stream in the Unified API for my Java application, but the available library is incompatible with the version of SignalR they are using (to be fair, this is the fault of Microsoft not providing a proper Java client). And as far as I know you can only use it to stream ETAs for 1 bus stop only, which didn’t meet my use case.
I used to use the legacy instant service because I wasn’t given access to the stream (the Countdown team never replied to my last email explaining why I wanted access). I stopped using this because the Unified API got better, and the legacy responses aren’t in valid JSON format so extra string manipulation was required making things more complicated.
In one of the emails they sent to me, they implied that they’d prefer developers use the Unified API as opposed to anything else. This has been further emphasised with the changes on the dev portal where they have pretty much hidden the legacy feed information from sight. The API is great, but it seemingly doesn’t have all the functionality that would be useful for me. That’s the trade off I guess…
