June 6, 2011 at 11:50 am #74730
Some great news below sent to me from the TfL press office. Developers can finally turn off their page scrappers and instead connect directly to a real live data feed! Horray!
So, who’s app will be first to integrate the new feed?
Realtime cycle information available free of charge from Transport for London
The long-awaited feed allowing web developers to access realtime availability data from Barclays Cycle Hire will be made live at noon today. Available free of charge in the TfL Developers’ Area http://www.tfl.gov.uk/developers and the London Data Store data.london.gov.uk this information gives users the capacity to develop enhanced mobile applications (apps) and web applications.
The Barclays Cycle Hire XML feed contains the name, location, co-ordinates and maximum number of docking points for all operational Barclays Cycle Hire docking stations. It also contains the number of available bikes (excluding locked or faulty bikes), and number of available docking points.
The feed comes direct from the Service Provider’s information database and is updated in 3 minute intervals. It contains the same data that is used for the BCH online interactive map.
This has been written by developers for developers making use of feedback from the community to create a source of dynamic data. In keeping with Transport for London’s open data policy this feed is being made available to all at the same time to ensure a level playing field among the developer community.
Key elements of the feed are:
· It is free to use
· Contains information about the availability of bikes in individual docking stations, noting where bikes are not in use
· Updated in 3 minute intervals
· All information is scalable and robust
· Supplied with a data dictionary
Transport for London anticipates a major interest in the feed which will allow developers to innovate greater information applications for the public. The public will be able to choose the application which best suits their needs while remaining assured that the information contained within it is robust and reliable. Members of the testing group include Digital Jigsaw, Fiplab, Big Ted ltd, Google, Malcolm Barclay and Adrian Short.
The Barclays Cycle Hire availability feed is available at http://www.tfl.gov.uk/developers .
· Transport for London’s Developers’ Area http://www.tfl.gov.uk/developers was launched in January 2009 and The London Data Store in January 2010.
· The Area currently contains 18 datasets and six realtime feeds including realtime traffic information. In December 2010, TfL released the Trackernet feed which allows users access to realtime travel information from London Underground. Over 500 developers have registered with us and using TfL data, developers have created over 15 web applications and more than 100 mobile apps.
· All feeds are available free of charge however Transport for London does not endorse individual products. In line with this developers are prohibited from using the Transport for London trademark.
· Barclays Cycle Hire was launched to members in London in July 2010 and to casual users in December 2010. A feed was made available at the time of the July 2010 launch giving developers access to static data including the locations of all docking stations.Don't forget to add your own signature! 1) Click your name in the top left (under Home once logged in) 2) Click Edit link on the left menu 3) Fill in "Your Forum Signature" 4) Click Update ProfileJune 6, 2011 at 12:28 pm #84018
done and done.
London Bike App uses it right this second No need for changes to the app, tho a new version is coming in the next few days (Apple’s approving it, and with WWDC on, they may be a little slower than normal)June 6, 2011 at 1:07 pm #84019
BTW, if anyone is using Adrian’s JSON feed, yell out – I have an almost-drop-in-replacement serving up from google app engine, using the new feed. I’m missing a couple of fields (the date ones mostly), but other than that, the names etc are the same.June 6, 2011 at 2:24 pm #84020
Nice one TfL!
Our cycle journey planner for the scheme now uses the live data, plus StreetView integration:June 6, 2011 at 7:46 pm #84021
Cool – nice to have the feed.
Asking you to register with various bits of info (name, phone number), and then distributing the feed without any kind of token seems rather pointless though!
TfL do this with all their feeds – and once the URL gets out there is no point. I wonder why they bother
Keep up the good work though TfL. Open data = goodJune 7, 2011 at 3:14 am #84022
First,Thanks for your share!
Does Louis Vuitton have an outlet? Who really knows but you can find some really great deals whether you are looking for a LV authentic or replica.
For more information please visit here
guiyichm0607June 7, 2011 at 5:33 pm #84023
Hopefully this is very good news! Although I will hold my breath until it’s determined whether this data is actually accurate.June 7, 2011 at 8:36 pm #84024
I’m told by TFL it’s as up to date as the map or any of their internal systems can be – 3 minutes (according to the website)
Sadly, I dont live near, or go past, any docks so I can’t tell, but I’ve not had any dock issues reported with the app this week…June 8, 2011 at 5:56 pm #84025
Nic. Endleigh gardens, right now. Your app: 20 docks free. Real life: 2 docks free.
Seems that this official feed is still getting things mixed up.June 8, 2011 at 10:16 pm #84026
It would be really interesting to know how the data gets from the stations to the servers.
Is the latency between the terminal and the docks,the terminal and the instation, or the instation and the feed…
I believe from what I have read/been told the docking stations use GPRS to talk to the world. I wonder whether the stations connect x minutes and update a central system, irrespective of station activity, which could account for the delay, or whether they attempt to maintain a persistent connection to an instation and send data as events occur. This latter would seem sensible, since you would get instant updates at the instation as cycles were added removed, and since most charging models for GPRS traffic will bill you on data transferred, not time connected – but if this is what is happening, I wonder where the long lag between reality and the feed…
If, as TfL say, the feed data is as good as that available to Serco, and since from the BBC it looks like Serco are being penalised if they perform “badly” according to the contract, presumably it would be in their and TfLs interest to increase the accuracy of the data. Not only will it make us happier, but it would enable Serco to better manage demand – and so be less likely to be stung by performance related contract clauses…June 8, 2011 at 11:29 pm #84027
malcolmb1963ParticipantJune 9, 2011 at 8:53 am #84028
I’m told it’s cellular polling. ie, each terminal has a cell modem in it, which it talks back to the main server(s) with. Every so often (3 mins or so), the server asks every dock how many bikes/docks/spaces etc it has. I think the docks can also query back to ask for what near ones have.
Personally, I’d do it the other way:
* docks call back when something has changed, at most every 30 seconds
* central system calls into the docks every so often (eg 10 mins), esp if it’s not heard from the dock for 10 mins.
This would mean a lot less traffic – most docks would go 10-15 mins without a substantial change. Even in high use situations, it could be set to only call in every 30 seconds (which might be 5 changes in one hit) – which would be more up to date, but less overall traffic.
GPRS (which is the same as 3G, only a LOT slower – 56k or so vrs 1.5meg – if you have an iPhone, when it changes to the (.) thats GPRS – you have (.), E (EDGE – Enhanced GPRS) and 3G) is packet switched, so while in theory you could open a TCP connection to the server and leave it open, it’s not worth it – just bring it up and down as needed. The overhead is minimal. I doubt Serco/TFL is paying much for the data – it’s a small amount (at a guess, less than 5GB/month for all 400 docks – peanuts in the grand scheme of things), so it’s mostly the cost of 400 sim’s/numbers, which would be cheap at volume….
I believe (from memory, not 100% sure), the data goes like this:
* serco server polls the nodes (takes a while – 1-2 mins all up. I can has threading?)
* serco server collates the data and stores it in it’s database
* serco server pushes the data in XML format to the Azure server (where we all get it from) and TFL (no idea on the format), which is used for the map, customer service and all that.
* wait until the end of the 3 minutes from when you started it all, and do it all again.
I assume Serco got slapped for doing more than just having out of date maps. More the large over-charging of customers, bikes not available, that kinda thing.June 9, 2011 at 8:54 am #84029June 9, 2011 at 8:59 am #84030
From the website in the OP’s post:Quote:
How often we publish a fresh copy of the feed
Maximum time allowed between capturing and displaying the feed
Maximum time information can be displayed before being updated
30 minutes!!??? That would count as completely useless to rely on then.June 9, 2011 at 9:44 am #84031
If, as it would appear, the data is polled – all stations every ~3 minutes, then on the face of it as you say this is very inneficient.
A lot of docks may have no change in this period, while others may have changed a great deal. I have worked in the past with traffic survey units that use a GPRS modem, keep a constant TCP conenction open, and send data as an event occurs (car passes a loop) – similarish situation to the cycle hire requirements.
With this model, you get updates as and when they happen, and when not much is happening, there is no data cost incurred. Seems a much better approach – but there may be some reason TfL haven’t gone down this route – be it technical or contractural…
You must be logged in to reply to this topic.