Standardisation in roads open data

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.

Developing a standard 

Throughout the 1990s and 2000s, the European Parliament and various Standards groups recognised the need to develop an agreed framework to exchange roads data. Given the geographical and linguistic diversity of Europe, it was clear that there was a need for protocols and standards to control the way that this data was served and consumed. This led to the introduction of a recognised EU standard, known as DATEX.

For the provision of traffic information, the use of this type of standards-based solution has been proven to work well, and for those consuming the information (such as Sat Nav companies), it means that taking up new sources of data can be done far more easily and efficiently if that data is presented in a standardised way.

The current experience

In the UK and Europe, most transport agencies that collect roads data operate an open data policy, and the type of data that is typically published includes planned closures, changes to road operation, live incidents, planned and current road works, current and historic journey times, VMS locations and settings, as well as static data such as the geography of the road network and its infrastructure.

In the UK, major transport agencies like Highways England, Transport Scotland, Welsh Assembly and TfL all publish roads open data which is used by satellite navigation companies, traffic information providers, academic institutions, app developers and others.

What’s next for roads data?

While consumers of road data generally figure out the best way to collate their data and offer decent products and information to road users, there is still room for improvement and further standardisation will become increasingly important in years to come.

As the number of data sources grow, customers’ expectations of products offering real-time road information also grow, meaning that the provision of accurate, easy to consume data by reliable sources becomes ever more important.

If transport operators are able to meet the challenge of adopting greater standardisation in the exchange of roads data, the result will ultimately be better products in the hands of customers. Those products, the journey-planning apps that drivers will increasingly come to rely on, will benefit from being ever more reliable and accurate.

Standardisation matters then, for at least three reasons:

  1. Transport Operators know their network best. Awareness of an incident, on which a third party can quickly and efficiently add further crowd-sourced data, results in better information reaching the customer.
  2. Precision of geography. Whilst standardisation does not in itself solve the issue of how precisely an incident or event is described or referenced, it can provide a framework that makes details of the incident as clear and accurate as possible.
  3. Richness of data. The greater the volume and extent of data, the greater the challenge of understanding, interpreting and processing it. Standard-based data solutions helps to address these challenges.

We’d love to hear from developers who have worked with roads open data that we, or any other transport operators have provided, to let us know whether you think greater standardisation would be useful. Has a lack of standardised data been a barrier to you when creating apps? How would greater standardisation help you? Please leave us any comments on this subject in the comments section below.

4 Comments

  1. There is a need for a supplememt to roads data – ‘footpath data’ TfL are promoting people walking for instance with the Walking Tube Map and the isochrone walking maps published for the Olympics. I have not looked at the roads data but Journey Planner and Google Maps both ignore walking routes that are ok on foot but not passable by car. There are a lot of places in The City of London, Westminster and Camden where you can walk a lot shorter route that is mostly traffic free than following the roads. I guess cyclists would like to understand if they can ride these routes or push their bikes as well so add Cycle Route Data to the list as well. There are quite a number of footpaths in the outer boroughs as well – there must be a register as the now have PRW (Public Right of Way) numbers.

  2. Author of GraphHopper here, where I can only speak with experience from OpenStreetMap (OSM). A standard for static road data is not necessary as the format used in OSM is already good, useful and extendable. But indeed a standard for traffic information would definitely be interesting as there are currently only very few sources with very different standards mainly ‘datex2’: https://github.com/graphhopper/open-traffic-collection

    And the more formats the higher likely errors or misinterpretations are and the less likely that a new data source gets integrated (fast) from adaptors.

  3. This is really interesting – we’ve recently made good progress with a related aspect with Traveline at a recent hackathon, looking into standardising how highways incidents/disruptions are reported and processed. We’ve worked with multiple transport operators before and looked at standardising the reporting process for operators and started designing an API to be consumed by app developers. We’ve also done some work on crowdsourcing disruption data.

    We’ve written up more details in these blog posts:

    https://wearebase.com/blog/2016/smarter-travel-live-hackathon/
    https://wearebase.com/blog/2016/creating-an-open-disruption-standard/

    We’d be very interested in your feedback. We’re also looking at linking geographical disruptions with bus routes and modelling how disruptions affect a bus network. Standardised roads, disruptions and other data all in open data is a powerful combination!

    1. Hi Jonathan, thanks for getting in touch and letting us know what you’ve been up to, it sounds great. The team here are really interested in the work you’re doing, and the linkage of road disruption to bus routes is of particular interest, and we’d love to hear how this progresses.

      We would also be keen to understand whether our proposed approach and use of standardised data helps with the work you’re doing, and what kind of challenges it helps you overcome.

      Another thing we’d be really keen to understand is what feedback you’d had from developers, and what they thought were the key pieces missing in roads data and how it could be improved.

Leave a Reply to karussell Cancel reply

Your email address will not be published. Required fields are marked *