UPDATE: Access to the Journey Planner has now been re-enabled, more details here.
On Monday 18th Oct TfL turned off their journey planner XML API. I have been using this successfully for more than 6 months for both London Bus (now called London Travel Deluxe) and London Tube Deluxe Pro for iPad. TfL are well aware of the success & reach my applications have achieved; sometimes I’ll even get a friendly heads up as to status changes coming up to ensure things keep running smoothly (99.98% uptime).
However it seems some areas of TfL are not so amicable. The removal of the API located at http://journeyplanner.tfl.gov.uk/user/XML_TRIP_REQUEST2?sessionID=0&language=en came without any warning whatsoever. Effectively dropping all journey plan requests for London Travel Deluxe & Deluxe Pro, as of this writing they return zero results. London Travel Deluxe has been downloaded 100,000 times & has a solid user base of 35,000 – 40,000 users producing 180,000 journey plans a month. They have been well battle-tested having been through 2 recent tube strikes. Blind & visually impaired people rely on specific features I have implemented for them using VoiceOver on the iPhone. It has got people using the often ignored bus system because they could plan on the run with complete confidence and even TfL’s own staff use the app.
It’s an uncomfortable coincidence that the XML API was closed down a week after the removal of MDV’s release of the ‘My TfL’ app. MDV run the journey planner for TfL and it’s a very impressive system. The My TfL app used a cut down version of the XML API located here http://www.journeyplanner.org:80/ultralite/XML_TRIP_REQUEST2?language=en&sessionID=0 You’ll notice this hasn’t been closed down. Nor has the scraping of the HTML version of the journey planner (as done by another popular, well developed & supported iOS app London Journey Planner).
I have repeatedly sought clarification on access to what was an open API from Transport for London. Emer Coleman from the London Datastore part of Greater London Authority has also done the same to no avail. Yes there are commercial issues around using the journey planner in third party applications and I am not asking for a free ride (I have sub-royalty agreements with the likes of Traveline) and already pay £3,200 a year to licence official TfL maps. MDV should be rewarded for the decades of hard work they’ve put into a commercial product they sell & support. It makes sense for TfL to find a way for this API to be accessed by numerous developers under an open, non-exclusive, authorised & managed arrangement (i.e a developer key). The benefits are enormous for everyone involved. London Travel Deluxe would cost the best part of £100,000 to develop commercially. But the past & prevailing attitude of certain departments and key individuals has amounted to nothing but corporate stone-walling, dodging, ducking, diving & weaving. Why?
Is it control, protectionism, shortsightedness or just plain stupidity? Take your pick.
Some in TfL will allude to the complexity of opening up the API, commercials, DoS attacks, vulnerabilities or making sure the data is 100% correct. These are the very tactics used to stagnate the opening up of any official API, I have witnessed these excuses first hand in several forums.
TfL has just released a mobile version of their site at http://m.tfl.gov.uk (you are automatically redirected to on an iPhone). A good initiative, but no doubt the html mobile version of TfL will be used as yet another excuse to further bury developer & London Datastore requests for open API access. My iPhone apps allow the offline saving of journey plans (very handy considering 45% of the network has no network signal) & have 750 searchable bus routes installed for offline reference as well as high resolution maps. An html mobile version will always cater to the lowest common denominator; a plethora of features in todays native apps is not possible in html, or even html5.
Do I want TfL to pull the html mobile version? No. For some the html version will be very useful, I support it. At the very least, I want TfL not to take away choice & stifle innovation; yet that’s exactly what they’ve done. This effects me & other developers, some have even started documenting the various API’s here http://wiki.opentfl.co.uk/Frontends
Taking away a perfectly functioning API for no reason is ridiculous. Although reasons maybe given after this writing, I can tell you they are certain to be 100% total bullshit. Why am I so sure? Because they haven’t closed down all of them, all of these XML API’s still work on the exactly same server farm the journey planner was removed from…
Find stops near Victoria Underground Station…
Get summary route details by a partial or route number or code search…
Get departure times for a specific stopId & all it’s services…
Go ahead try them yourself. Although it wouldn’t surprise me if these also mysteriously disappeared.
If there were any real problems with the XML API you’d close them all down. Or like most normal IT departments…simply fix them, technical & security problems can be overcome. These API’s have existed for years and taken a hammering by many developers, if TfL check the logs they’ll see just how well this API has flawlessly performed! There are no problems or vulnerabilities with these API’s & I have never done anything to compromise this system. I know how to code against an API.
So where to from here? TfL’s actions go against their own boards digital strategy, see http://www.tfl.gov.uk/assets/downloads/corporate/Item04-Commissioners-report-sept-2010.pdf point 8.2. We are at an impasse. Senior management at TfL could lead the UK in terms of developer engagement & open data. Myself & many others see that as an opportunity that benefits commuters, developers & TfL alike, but they see it as a threat.
Who made this decision to turn off the journey planner API? Why?
If you would like to ask TfL this question you can email them firstname.lastname@example.org
UPDATE 24/10/2010 @ 6pm: I have been informed that the change was part of a security update & that TfL are working on restoring the service ASAP and are also fully committed to open data. TfL have recently released data sets & a developer area.
I sincerly hope ‘we are working to restore’ or ‘ASAP’ is a matter of days, not weeks dragging into months. If I need to change something in my apps, that’s not a problem.
UPDATE 26/10/2010 @ 8am: Late yesterday I had a really positive meeting with senior people at TfL, they explained they fully committed to open data. They are indeed working extremely hard to get the popular TrackerNet feed back online (unrelated to the feeds I mention in this posting) and are actively working out ways to engage further with the development community to deliver more data.
I am told access to the API will be re-enabled. I have no timeframe for this, but given it’s a simple configuration change, sometime today is not unrealistic.