Recently Transport for London opened their data feeds to public access through their Open Data Users initiative. Finally developers can get access to the transport information through official channels and not rely on dubious screen scraping techniques.
Regretfully some of these APIs could have done with a little better design when it comes to the output format and usage scenarios.
Hint: TFL devs, you might need to add one extra coffee break to your design meetings :)
The worst one of the APIs is probably the "Tube departure boards, line status and station status" API. But don't take my word for it, go see it for yourself.
What is wrong with it?
The problems I see with the API and it's output format are the following:
- Excessive amount of element nesting in the XML output make it difficult to parse. To reach the relevant data you have to use information from more than one level (e.g. it is impossible to get the StatusDetails and the LineName at the same level).
- Confusing contradictory information (e.g. LineStatus.ID and Line.ID are documented as the same data but for some lines the values differ).
- Unused and irrelevant data. The StatusType element is always the same and what does
So stop whining and fix it then!
OK, so I spent an hour one evening and re-formatted this Tube API so that it supports a JSON and JSONP interface. A change I believe makes it far more applicable to today's web development. I also simplified the structure of the response and trimmed away all of the unused data points.
Go a head, try it for yourself
The format is now:
"Status" : ""
The service accepts a single optional querystring parameter
&callback= which produces a JSONP compatible return.
...your code here...
Output Format Definitions
|A unique code representing the tube line
|The tube line name
|A short code representing the status of the line
|A description of the status of the line e.g.
|A long description of the status of the line if the status is not normal otherwise this will be blank
|boolean indicating if the line has any disruptions (
|List of disruption points to this line (if any)
|The unique code of the station where the disruption starts
|The name of the station where the disruption starts
|The unique code of the station where the disruption ends
|The name of the station where the disruption ends
|A short code representing the disruption status of the line in the disruption zone
|A description of the status of the line in the disruption zone e.g.
Stay tuned for the rest of them...
Developer & Programmer with +15 years professional experience building software.
Seeking WFH, remoting or freelance opportunities.