That’s cool. Now we have two - at first pass they look compatible although yours seems more comprehensive. Thanks for this.
I’m a little bemused, this information seems so fundamental to making use of BODS that it’s puzzling that it isn’t widely available and supported. Presumably the model for BODS is that of a data ‘wholesaler’, providing information to other servers, rather than directly to the client.
I guess the same is true of the TFL streams too. Having made this information available, how do you actually anticipate it being used? Would I be right in thinking that your model is that this data will be provided to a third-party server which will then handle what could be a very large number of client connections? Is there scope for those client connections coming to you directly?
Thanks
To be honest, I’m not entirely sure how the LineRefs are assigned. I’d be hesitant to assume they’ll remain the same. I wouldn’t be surprised if a new LineRef is assigned when a bus route changes operator, for example.
Please note that the data in the BODS SIRI-VM feed comes from a completely different system to the TransXChange data, so routes may not correspond exactly (particularly in the case of special routes).
I can’t speak for how the DfT intends BODS be used, but I probably wouldn’t have (public) clients making requests to BODS directly if only for the fact that this would compromise my BODS API key.
With regards to the Unified API, it depends a little bit on what you’re doing. But suppose you’re developing a public website or app. You should keep your API key secure, and therefore you’d want to use an intermediary server. Since by default you’re limited to 500 requests per minute, it should ideally not be a simple proxy but rather coordinates requests so you’re not making duplicate or redundant requests.
For example, take an app that displays the status of the Tube network. You might have a server that sends a request to the Unified API every minute to get the latest status information. And then the app makes requests to that server to retrieve the Tube status. So no matter how many people are using the app, you’re only making one direct request to the Unified API per minute.
Note that this is just my thoughts and advice, rather than specific TfL policy. And if you’re developing something as part of a hackathon, for example, it’s going to be quite a different situation to if you’re developing a very popular smartphone app.
1 Like
Something like this works for us…
The filters are for when the Cloudfront has one of it’s occasional moments.
My attempts to get simple bus route and arrivals information for one service (the W30) from BODS have made me appreciate what an brilliant job TFL have done in presenting data sensibly and consistently. It’s chalk and cheese!
2 Likes
Thanks for the good feedback.
We realise it’s not so straightforward to get live location data for particular bus routes, so we’ll see what we can do to address this.
1 Like
Thanks, it’s appreciated. I live on the border of London and Hertfordshire so many of my local routes are not TFL operated. I want to integrate arrivals information for some non-TFL services - like the 508 and W30 - but so far it’s defeating me. I can’t even work out the routes! It really does make me respect what you’ve done here.
As far as location data goes, lat and lon are what we want (so that we can cook our own prediction algorithms) but I understand that there’s been push-back on providing that. Presumably there’s no push back on providing it to BODS because … it’s not that easy to use?
2 Likes
The situation may have been different in the past, but at this time there is no sort of push-back on providing bus locations and we’re actively working to improve our provision of this information.
1 Like
@LeonByford
Ah yes, I recall getting told in no uncertain terms about the pushback at a TfL event in the O2 Centre once. It’s nice to know “those people” have moved on and we can actually get around to actually helping people. 
Here’s an update, still very much work in progress. This shows the tube (and overground) waking up on Wednesday morning, a timelapse from 04:30, when the first Hammersmith train leaves, to 06:00
London wakes up - Youtube
1 Like
That animation is quite mesmerising! Nice work – thanks for sharing. 
My first thought was “dodgem cars” without the collisions (I hope!).
Dodgem cars indeed. It’s given me a whole new level of respect for the Central Line and the Northern Line around Camden. It’s amazing it all works.
