Whilst I wholeheartedly support National Rail Enquiries’ aggregation of live train running data and disruption information, sometimes it can be wholly inaccurate and present a misleading picture.
Suppose I am travelling from Highbury and Islington to Shoreditch High Street today. I know these stations are on the same line, so I visit the Live Departure Boards site. I am presented with a warning saying there are no train services from this station on Sunday 3rd April.
What? But there’s a list of trains to West Croydon and Crystal Palace that all stop at Shoreditch. I visit the link in the warning and find that, actually, there are no trains between Stratford and Acton Central. The map linked to is very helpful actually, and it shows the route with the disrupted section in red. But what’s missing? The link from Dalston Junction to Highbury and Islington. So, do I need to go to Dalston Junction to take my train now?
The answer is actually quite straightforward – the website is wrong, and I know this because I’ve looked up the departures from Shoreditch High Street and seen that they’ve all departed Highbury and Islington.
What on earth is Joe Public going to do when presented with conflicting and incorrect information? It’s no wonder a number of people I know get aggravated at the quality of disruption information.
I’ve spent a couple of weeks wrestling with Nokogiri to parse a tonne of DATEX II data in to some usable format. Previously I had a mash of libxml and REXML, and the code was either ‘fast’ or ‘pretty’, but not both.
Nokogiri is good – it’s very good, in my opinion. The only trouble is, documentation and examples are a little thin on the ground, which slows everybody down. Here’s the dilemma – do I spend time writing poor documentation based on my limited understanding of part of Nokogiri, or leave it to somebody else?
I’ve been hacking away at a project called TransportHacker for the last month or two. I’ve only shown it to a few people I know, and the reactions have been largely positive – thanks to Laura, Su, John and Ellis for your feedback.
I am not usually one for giving ‘sneak previews’, but in the spirit of getting feedback and ideas, I present – for your viewing pleasure – a sneak preview of TransportHacker.
TransportHacker takes its data from a variety of sources – currently some of those on the TfL Developers’ Area, although adding new data is straightforward. I’m putting TfL’s live traffic cameras up in the next few days, and experimenting with the Highways Agency’s DATEX II feed to see if I can include other parts of the country.
TubeHorus will be integrated, but also be available standalone – both this and TransportHacker will use geolocation to display only the parts of the world you’re near.
I have plans to make the data richer and more exciting – at present it’s just a mash-up of some data with no value-added logic, and that kinda thing can only go so far before it’s dull. When TfL get around to releasing real-time iBus data, things are really going to start hotting up – imagine being able to compare taking the tube from Highgate to Warren Street versus taking the bus. Colour in the 134’s route in red where it’s congested, and lighter colours where it’s free-flowing. If I included the Journey Planner API – when that’s ready for public consumption – I could augment the information it returns with real-time performance data for different modes of transport.
Now that all my Christmas shopping is sorted, it’s going to be a fun few weeks while I get TransportHacker in to a robust and workable product. Christmas is perfect for that sort of thing, although I better go easy on the mulled wine…
Back in June, Transport for London released their Trackernet API to the public. This is about as close an insight in to how the tube network is performing as you can get without being there in person. Its enormous popularity caused their internal system to collapse, and the service was pulled. What a way to demonstrate the appetite for this data!
Ever since, there’s been frequent talk of whether the API is going to return or not. I, for one, have been particularly looking forward to the day it returns so I can get to work adding more feeds to TransportHacker. In the meantime, I’ve resurrected TubeHorus.
That day was yesterday.
I was invited to a press conference at 55 Broadway, London Underground’s headquarters, where the TfL Developer area was relaunched with additional feeds, and importantly, the Trackernet API. This time, to cope with demand, it’s been placed on the Microsoft Azure platform, although Microsoft’s representative was keen to point out that it’s not just for .NET applications.
Despite having to rush out of the press conference to catch a train out of town, I’ve had a few hours playing with the API, and it differs little from the original service. The biggest changes I can see are:
- URL change – it’s on a different server and the URLs are RESTified
- There’s little server-side filtering of the data, so you may end up pulling more than you actually need
- Data freshness – the data is only pushed out to the cloud every 30 seconds. I know at least one person who was deeply unhappy about this
- You need to register – free – to get the URL for the service, but it’s not locked down with an API key
TfL really haven’t had an easy task to get here, and I salute their efforts. TrackerNet was a system designed to take multiple sources of data from the trackside and other operational systems, and present them internally in a coherent manner, including to drive other internal systems. It was never envisaged that the general public would have access to it, and so architectural decisions were probably made regarding its sizing that precluded making its data available en-masse.
So, TfL have set the standard. If they can build a platform to disseminate their real-time information sensibly, why can’t the likes of National Rail Enquiries? Hopefully NRE will see the benefits of making their real-time data (and whilst we’re at it, static data too) available without onerous contracts and agreements. Heck, NRE already have a scaleable platform for their Live Departure Boards service that can handle train information for the whole country – why are they concerned about scaling?
On a less political note, we’ve also been promised access to the Journey Planner API within the next few months, and there were some murmurs about real-time bus information, but nothing concrete.
A couple of months ago, I bought myself a bike, and catapulted head-first in to cycling to and from work.
It hasn’t been easy – dealing with less courteous road users who try to kill me, pedestrians who walk out from between buses, cars that overtake leaving precious little room for me – it’s a very big learning experience. The benefits are worth it though – the money I’m saving on my Travelcard is going on cycling gear for the first few months, and my body is changing shape in to something rather more pleasant than “chubby”.
Within London, TfL offer free or subsidised cycle training. I took up their offer and had a couple of two-hour sessions with a qualified and knowledgeable instructor. She showed me so many techniques to help me get around safely – a couple I was already doing, others I wasn’t and should, and some – such as roundabouts – that I didn’t dare tackle.
The result is a big increase in my confidence, and the feeling that I am assertive and aware enough on the roads to make the majority of cycling fun. If you have the opportunity to do so, take the cycle training – it may not be there forever.
I have a lot of respect for the folks at the Greater London Assembly, especially those who worked to get the Train Prediction API exposed and available.
Many people have seen Matthew Somerville‘s Live Map of Underground Trains which was whipped up in a frighteningly short time.
I’m working on a Rails interface to the Train Prediction API, with an ‘advanced’ mode for those who grok the tube. It’s a little rusty, and not even beta-quality, but it’s available for you to play with if you so wish.
Here’s hoping that particular box stands up to the load 🙂
I can sit in a club and decide I want to go home. I can pull out my mobile phone from my pocket, visit a certain website and book a taxi home. I receive a text message when my taxi is near, then stand outside and hop in. This clever use of basic-for-2009 technologies impresses me somewhat. This is what technology should be about!
It may cost a bit more than trying to hail a black cab, but I really appreciate the freedom of paying a couple of quid more for a near-enough chauffeur service. And of course, it avoids having to take a night bus.
TfL’s Countdown system for London Buses was a leap forward several years ago. I can now walk up to a bus stop and tell – with reasonable accuracy – how long before my bus arrives.
There is one problem with this – I have to be at the bus stop!
When National Rail introduced Live Departure Boards several years ago, it was a giant leap forward for rail travellers. TfL brought in Live Departure Boards for the Underground some years later, although this is less useful.
Wouldn’t it be absolutely fantastic to have a map of a bus route with the positions of the buses on it? Colour the map in with a deeper shade where the route is more congested, and let people have a visual representation of how long it’s likely to take for their bus to arrive. Before you leave home, have a look to see where the delays are on your route in to work, and re-plan your journey if it’s going to take too long.