I get the honour of the final blog post of 2015, and it’s a pleasing one to be able to write as we look back on what the team in TfL Online have achieved during this year.
We started off the year accomplishing one deployment of new code to the website every two weeks, and that’s increased to the point where we’ve now managed our 57th release to the site in 2015. There are a lot of variables and moving parts that we monitor and co-ordinate simultaneously to deliver a safe, quality assured, zero defect, zero outage deployment to the website every single week.
For more detail, see my posts on Blue/Green deployments and Agile continuous delivery in the cloud (in 3 parts).
While we’ve successfully made these 57 separate releases of code, optimisations, reference data refresh, bug fixes, enhancements and new features to tfl.gov.uk, we’ve managed to do all this seamlessly without a single planned maintenance window, so our customers haven’t experienced any down-time at all while we’ve been making these improvements.
So, here’s how we believe we’ve fed into the ‘Every Journey Matters’ ethos:
It matters that you have access to new features and enhancements on the website quickly – WebCAT, Roads VMS, Unified API, Live Bus Arrivals, Integration of TfL Rail & West Anglia, to name but a few
This week we have a guest post from Duncan Elder, an Associate with IBI Group and a specialist in transport data, spatial information and customer information systems.
In Part 4 of the series on the Unified API on this blog, Tim discussed TfL’s roads open data and gave guidance on how to build apps using this data. Having worked closely with TfL for some time now, this prompted me to expand upon Tim’s post with a look at a long-standing issue around this kind of data – standardisation.
Whilst it is widely agreed that data held by transport agencies should be made open, there remains a question over how easily this open data can be exchanged and used by various parties. UK public transport agencies have been rather ahead of the curve here, as the exchange of train, bus and tube information is underpinned by the use of standard approaches for describing data, such as exists with NAPTAN and TransXchange, and the equivalents in Europe; Transmodel, IFOPT and NeTex.
This means that in the UK we are used to seeing widely available public transport journey planners and information from a range of different providers, all of which would be unlikely to exist without a standardised approach from the various sources of open data which power these tools.
However, when it comes to roads open data things are much more complex, with the data held by public bodies less centralised, the number of miles of roads much greater than rail, and the number of possible sources of roads data far greater. This includes an increase in the use of crowd-sourced data, in addition to existing sources of road information, which adds to the difficulty in establishing a standardised approach to data provision.
Open data for roads is a complex proposition, with many more miles of road than rail and a far greater number of possible sources
With a real focus on our Unified API and open data policy in recent months, both on this blog and through the Hackathons and events (such as the Urban Traffic Hackathon a few weeks ago) that TfL staff have been involved with, we’ve received lots of great feedback and questions from the developer community, just as we’d hoped we would.
One such question that has cropped up many times is one around customer volume and flow data, i.e. how can we help developers create apps that take into account how busy certain lines, stations, platforms, etc are likely to be when customers are planning a journey.
To provide an update on where we are with this data, TfL’s Data Services Manager Ryan Sweeney offers this summary, and asks for your feedback to help us ensure we’re providing data that is both relevant and useful:
Participants at TfL’s Urban Traffic Data Hackathon, held at Queen Mary University in November.
In Part 3 of this series, I gave examples of finding the Routes of Things using the Unified API. This article focusses on the “Arrivals of Things” – how to find out when services are going to arrive on those routes.
As before, all of the API examples in this page are live, however they do not include API authentication tokens. This means that if you follow the link as is, you will be using anonymous access, which is throttled for fair use, so you may get a 403 response. We recommend for your own development that you obtain an “app_key” and “app_id” by registering here. The data in these examples will be in JSON format, so installing a JSON formatter plugin in your browser will help you read the data returned.
Ride on time
Let’s start with the most prominent example of arrivals, shown when viewing a nearby stop:
At this bus stop we can see the time-to-stop of the next services that are due to arrive.
Back in July, Yaron gave an overview of WebCat – a unique TfL tool designed primarily for developers and town planners, giving them information on transport connectivity when deciding what to build where.
We also knew that WebCAT could be a great tool for Londoners to compare between places to live or work, or even just to play with those beautifully coloured maps that tell them new things about places they know.
You can check it out for yourself here.
This week, at the Association for Geogrpahical Information (AGI), we were delighted that WebCat was named as a winner in the AGI Awards for Geospatial Excellence 2015. WebCat won The AGI Award for Excellence in Research & Development.
As AGI describe it; ‘This award acknowledges those projects that have advanced best practice, technology or tools to the benefit of the geospatial industry.’
WebCat is primarily aimed at urban planners and developers, but appeals to a much wider group
Roland Major, Enterprise Architect within TfL’s Information Management team, reports on the Urban Traffic Data Hackathon.
In the last post on this blog, Tim introduced the roads data available in our unified API, describing its importance as we encourage road users to check before travelling while we carry out our Road Modernisation Plan.
We continue to engage with developers to help us in making driving in London better, with innovative solutions to traffic, road disruption and planned works information through apps created from our open data. As part of our engagement with the developer community we held an Urban Traffic Data Hackathon on 14-15 November.
Supported by our Roads Space Management team, the event was planned in order to give us the opportunity to engage directly with developers to work on creative and innovative solutions to the challenges on London’s roads. In putting the Hackathon together, we worked with Data Science London (DSL), the largest data science community in Europe, and arranged for data scientists and innovators who are members of DSL to take part in the event.
Queen Mary University hosted our Urban Traffic Data Hackathon on 14-15 November