Hilarious docking station data

Home Forums Data Hilarious docking station data

This topic contains 20 replies, has 15 voices, and was last updated by  dbrb2 7 years, 2 months ago.

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
  • #74825


    Ok. First post and it’s not going to be pretty. What the hell is going on with the data feed that powers the apps? It appears to be linked, not to docking stations, but to either seats on a 319 to Clapham or possibly spaces on a tube on the Northern Line, whatever it is, it’s not the docking stations!

    Every day this week, I’ve enjoyed the fantasy report that any of the cycle apps spew out (I have two installed) about the docking stations I use, namely any at Waterloo or one near Goodge Street. Every time, the reality is nothing like the data the apps suggest. It’s not even close…!

    Any thoughts? Anyone else got round this???



    All the apps take their data from the same source, namely TfL (either from the TfL website via scraping or via the syndicated feed provided by TfL – and both of these feeds are the same)

    The data TfL releases is bad, it is true – but there seems to be some uncertainty as to whether they, or Serco who run the scheme, actually have any better data – it may be a limitation of the system design – which was largely “off the shelf” from yet another company – and these three parties will likely all be linked by contractual obligations which may not necessarily be conducive to fixing things like bad data feeds :-p



    Diabolical. I have just walked past 5 docking stations all with 3 – 8 spaces apparently available according to TFL data (from Kennington Road to Vauxhall) and all with ZERO available spaces available in reality.

    I thought this had been fixed? I am sure a few months ago the data was more accurate. Whether it had or it hadn’t how can this still be happening a year after the scheme started?!

    Amateur, absolutely diabolical, this is a multi-million pound scheme that is supposed to be in place for many more years to come and the software is still like this – this is also not mentioning all the other problems.

    I was lucky that I was walking but I saw about 7/8 boris bikers looking for spaces in vain, they are probably still looking.

    Serco/TFL/Boris/Barclays you should be ashamed. Sort it out!



    the data definitely DID used to be much better quality. It made the Apps indespensible.

    now there data is a MINIMUM of half an hour out of date isnt it?.



    Replying to @jamsandwich‘s post:

    Just to endorse some of the above comments! I have had some very bad experiences recently trying to park my bike in the southern area of the scheme. I spent an hour and a half one evening from about 11pm: after looking to park near Elephant and Castle I ended up at Borough Market, having failed to find a space at more than 10 docking spaces. Each stop had data on other docking station availability that was very wayward compared to reality.



    TFL say in response

    We are working tirelessly to resolve the issues which have from time to time affected the system because it is obviously not in our best interests to disregard them. Please bear in mind that it is a computer based system but as computers are never foolproof our software engineers are working very long hours to improve the reliability of the programs.

    We are also committed to an ongoing service improvement plan designed to constantly upgrade and improve the system.

    With regard to the accuracy of data, w recognize that the information displayed concerning the availability of free docking points can occasionally be inaccurate. The issue is caused by a data transfer delay resulting in the wrong logging of information that should be displayed in real time. We are working to resolve this in conjunction with our software partners 02 but cannot put a timescale on when this will be completely resolved.

    Is SERCO foolproof? sympathies to the tireless software engineers!



    Thanks TFL – its good to know it’s being worked on :-)

    Wrt the data latency, even if it can’t be fixed easily or quickly, it might be interesting to have some insight into what the problems are, and how the data is being gathered. Are GPRS connections to docking stations dropping out? Do the docking points attempt to maintain a connection at all times, or reconnect when needed. What is the expected mode of operation, and how is it failing? Someone here may even be able to make some useful suggestions – but if=ven if they can’t I imagine people would be interested to know what the problems are.

    Thanks for all your hard work :-)



    >>> The issue is caused by a data transfer

    And the solution… is to CHANGE the method of data transfer to a more reliable mechanism rather than soldier on with something that clearly isn’t fit for purpose.

    >>> our software engineers are working very long hours

    Either a sign that there are too few of them or they are rubbish!



    It did say they were working with o2, so I’d imagine other options are being assessed too.



    There’s another known fault that someone in the TfL overflow call centre recently admitted to me. If you miss the green missing light and pull the bike out a fraction too late, when you insert your key again the bike red lights. While you won’t be charged, the bike is unusable (and presumably drops off the data feed). Apparently ‘the system doesn’t know there is a bike there any more’.

    How it manages to forget there’s a bike there, but lock it in, and know to red light it, is a mystery :-)



    Replying to @BermondseyBill‘s post:

    As of 1530 today (Sunday). the TfL syndicated XML feed is running 45 minutes behind real-time, as reported by the timestamp in the XML.

    While this may not be possible to fix if you are having wider system problems, as far as I can tell this data is being used on the live TfL map. A quick spot check certainly suggested this is the case, and your syndicated feeds website says it is so.

    However, the infoWindow popups on the TfL map were reporting the current time (15:26) as the time the data was valid from – which is quite misleading, since the source data was reporting itself as almost an hour old. This at least should be a simple bug to fix.



    Oh. They’re using O2. That explains quite a lot then!



    I suspect the problem is all in the design, and also in the running by Serco.

    The design, I’m told, is that a central machine polls each dock every 2-3 mins, and collects the data, and then pushes it out. Why 2-3 mins? ‘cos it takes that long to process each one.

    Really, the docks should be more intelligent and push their status to the central thing when they change state (or every 30 seconds etc…)

    That said, the data being 15-20 mins out a) is nothing new and b) shouldn’t happen, as, if it’s working, each dock is asked every 2 mins…. I guess this isn’t happening (hence the serco problem)

    I dont see this getting better. the XML feed is fantastic: no more scraping (and it took me all of about an hour to integrate into the backend of London Bike App), but the quality of the data has to go with it, and sadly, it’s not

    All anyone ever gets from TFL is “we are working hard to fix it”. Maybe TFL is, but Serco, who are actually running it, are clearly not.

    This is going to end up a total mess in 2012 with the olympics….



    Well, now that I’ve started using the XML feed, I’ve begun logging:

    * The timestamp of each updated XML update

    * When this updated XML was actually published

    From this I can plot XML latency vs time – might be a pretty plot :-)

    At present (11:15, Mon 1st Aug) the data hasn’t been refreshed since 0913 this morning. The TfL website still claims the data is up-to-date though. Come on TfL!



    …the plot of how stale the data is at any given time of day is now living here:


    This plot comes from taking the initial latency value as diffeerence between the XML timestamp and the time that XML is actually published. After that there will be a linear increase until the next load of data is released.

Viewing 15 posts - 1 through 15 (of 21 total)

You must be logged in to reply to this topic.