Launching The Data Spectrum for Transport & Mobility

Today we launched ‘The Data Spectrum for Transport and Mobility’ in partnership with MaaS Scotland. This follows a detailed piece of work to adapt the Data Spectrum from the Open Data Institute specifically to transport and mobility data.

Further details are available on this page:

This diagram is a significant step forward in the data maturity of the sector and it is the first to align transport and mobility to data terminology already used by other sectors such as banking, energy, and smart cities.

The Data Spectrum for Transport and Mobility is published under Creative Commons “by SA” license and is free to use and share by all.

If anyone has any feedback or suggestions, they can contact us via:

Shortlisted for new Transport Ticketing Award

The Open Transport Initiative is delighted to have been shortlisted for the category ‘Ticketing Enabler of the Year’ at the Transport Ticketing Awards.

This is a new category for 2021 and recognises the importance that enabling layers play in the success of transport and mobility services.  

Hayden Sutherland, Founder & Chair of The Open Transport Initiative, stated “I would very much like to thank Transport Ticketing Global for recognising our work in creating and driving forward Open Standards for the sharing of transport & mobility customer data.”

Open, shared and closed data for micro-mobility

Yesterday (27th May 2021) our Founder & Chair Hayden Sutherland gave a talk on “Data standards for micro-mobility providers, authorities & customers” to the Transport Data Initiative.

In this presentation he covered:

  1. The language of data (how terminology is mixed up and confusing)
  2. Definitions for the terms Open Data & Shared Data
  3. The draft Data Spectrum for Transport & Mobility
  4. F.A.I.R Data Principles
  5. A Mobility Data Checklist

The session also had presentations from

  • Innovate UK – UKRI
  • Newcastle University
  • Staffordshire Council

Using data-driven mobility to transform the world

Yesterday (18th May 2021) our Chair & Founder Hayden Sutherland took part in a Shaping Mobility webinar on the topic of “How data-driven mobility transforms the world”. This session, organised and moderated by PTV Group, had input from other respected transport industry specialists from the UK Department of Transport and TomTom.

The topics discussed included:

  • How should authorities use data to optimize mobility?
  • What kind of data fits to which community & transport operator?
  • Can all of us be assured that data of our movements is in safe hands?

Unsurprisingly Hayden mentioned how different types of data from across the Data Spectrum (especially Shared and Open data) can be used to help cities and authorities understand and use mobility data better. But also that data should be made FAIR:
– Findable
– Accessible
– Interoperable
– Reusable

You can watch the entire hour-long video here:

Open Transport & Modal present at Geospatial Data Transport Challenge

Today Open Transport Initiative Founder Hayden Sutherland and Paul Coster, co-founder and CEO of Modal, presented at “Geospatial Data in Transport: A Snapshot of Innovative Projects”. This virtual event showcased innovative projects that were funded through the ‘SBRI: Using Geospatial Data to Solve Transport Challenges Phase 1’ competition. This was the culmination of a £2m fund from the Geospatial Commission, in partnership with Innovate UK, is to support the future of mobility for the UK.

The project we were involved in was a three-month feasibility study, based around the theme of “Enabling Mobility as a Service (MaaS)”, and focused on increasing the number of people that will use MaaS through real-time journey detection and Open Standards.

Here’s what Hayden said:

The Open Transport Initiative has previously worked with a significant number of different transport providers, authorities, MaaS Platforms and software vendors to create the first and only Open Standard API specification for transport & mobility account interoperability.

Based on the same principles as Open Banking, mobility data that is owned by the customer can now be shared across multiple accounts with their permission
(AKA UK Gov “smart data”)

Our standard enables the sharing of purchase data (e.g. tickets), usage (e.g. journeys made) and concessions (e.g. discounts & vouchers) – across any mode of transport – including bus, rail, ferry, taxi, air, parking and micro-mobility.

This project with Modal was the first real-world use of our API specification.

Our joint work on this challenge proved the standard. It also identified an opportunity to update our specification. Leading to a backward compatible change that now allows the richer & more useful exchange of UK Rail ticket data e.g. for better journey detection.

The Open Transport Initiative is now looking forward to the next phase of this challenge. And just today it was announced that up to £4m has been secured to enable the most promising phase 1 projects to progress development & trial solutions.

Make Transport & Mobility Data FAIR

There is a growing awareness of the role and benefits of good data management and usage. Industry, academia, legislators and even day-to-day consumers of digital services now see or receive the advantages of structured, standardised and stewarded information for both humans and machines.

The transport and mobility sector is, like many others, currently going through a huge transformation. Ever-faster technology systems updates & integrations are expected and increasing customer demands for complete and more real-time updates means that data is now a critical business resource for all transport providers, system suppliers and mobility-as-a-service (MaaS) platforms.

But it is no longer good enough to consider structured and stored data as “something the IT Department look after”, every data producer and publisher in a mobility organisation now has a responsibility to ensure that data is F.A.I.R

Data, unlike the Kevin Costner movie is not a Field of Dreams… if you build it (produce / publish data), the don’t come (and find it). Transport data has to be published in such a way that is can be easily discovered by an entire ecosystem.
Many different websites and online lists of mobility data now exist, each describing similar and overlapping data sources and each potentially identifying or describing different versions, potentially with differing timeliness / frequency of data. But websites, although human-readable, are not the best way of helping system-to-system integration of multiple trusted data sources.

What is ideally needed is one directory of data (or more than one, as long as they either cover different data sets or automatically duplicate or reference each other) covering all modes of mobility across an entire transport ecosystem.

In short, what is required is a centralised service, something akin to the Domain Name Service (DNS) used for finding internet websites or the Sort Code system used by the UK banking sector to exclusively identify the persistent location (physical branch and digital address) of each account.

Data is made accessible when the person or system requesting it can do so easily or without unnecessary restrictions. Unfortunately there could be multiple restrictions to getting the data once its location has been found:

  • the data cannot be accessed in a standardised way
  • the technology is restricted (e.g. by propriety protocols and/or licenses)
  • unnecessary authorisation is required (e.g. API keys)

To mitigate this, transport data should be provided via a technology / protocol that is free (no-cost), open (sourced) and thus globally implementable. E.g. HTTP, FTP, REST, etc.
Note: This is not to say that All mobility data should be global and free (perhaps only that data defined as truly Open on the Data Spectrum ), other types of data can and should be limited or monetized as is commercially, ethically, or practically required.

Furthermore, data tends to disappear or degrade over time (typically because there is a cost to hosting and maintaining it). Therefore storing the metadata (e.g. details about the data publisher / owner or the original source location) can be a cheaper or longer-term option

Data works best when it is merged, integrated or used with other data. Making data exchangeable and readable by humans & machines (without needing specialised or clever converters or algorithms) means using common entity definitions, standards or vocabularies across an entire sector or ecosystem, preferably ones also commonly used by the analysts, architects, developers & testers in similar or related sectors.

An obvious example of this for transport & mobility would be to ensure that any technical data interoperability standards created or adopted also take from or align (e.g. easily map) with those used across the location & geospatial sector and the Smart Cities sector.

Open Data initiatives have been gaining pace and acceptance across the mobility sector, with transport organisation and authorities publishing easily findable, accessible and (mainly) interoperable data sets online. (Perhaps less so from MaaS Platforms right now… but this will come into effect eventually either by choice or obligation).
Use of this data by others (e.g. external parties for analysis, objective insight and service improvement) has obvious advantages and promotes trust in the data and the publisher. But unlike technical interoperability, where there is the need to ensure as much data as possible works with other data… often it is legally necessary to restrict data usage or prevent freely published data from being subsequently changed or monetised without permission.
It is therefore important that any transport & mobility data source (whether it is Open or Shared / Smart) defines how it can or cannot be replicated and/or combined in different ways, along with a clear data usage / re-usage license.

University of Glasgow Students release Guidance for Implementation of Open Transport APIs

From October 2020 to March 2021 students from University of Glasgow 3rd Year Computer Science team CS21 have been working with the Open Transport Initiative as part of their Professional Software Development Honours project.

Their agreed goal was to provide a proof of concept, illustrating how the Open Transport Initiative API specifications can be implemented in practice.

CS21 team:
Ans Farooq, David O’Neill, Lewis Tse, Dominykas Meistas and Pragati Mishra

As part of their project handover, their final product and Guidance for Implementation has been published to a GitHub repository here.

During their time implementing the API specifications they took note of certain issues which arose. To help future developers working on The Open Transport Initiative APIs they have collated some general advice here:

University of Glasgow Students (CS20) use Open Transport APIs for successful project

Intro: We are a team of third year Computing Science students at the University of Glasgow. 

Project aims: To use the Open Transport API specifications to demonstrate the sharing of customer data between transport operators. 

Timescale: 14th October 2020 – 31st March 2021 

Names: Torrin McQueen, Tomas Mikus, Paul Traynor, Kameron Eralp, Jamie McKay 


With Django, we created an example Operator lookup and model Operator site “Zebras”. The Open Transport API was implemented within our websites using the Django REST Framework. We populated our database with some sample customer data to demonstrate account linking. We have shown that by deploying two separate instances of Zebras and registering them with the Operator lookup, it is possible to link user accounts and share ticket data. 

We came into the project with prior knowledge on databases and web app development. However, none of us had worked with APIs before, so using Django REST framework was a bit of a learning curve. Listed below is a couple of challenges we faced using Django, and how we overcame them. 

Python does not support hyphens in variable names. We used underscores instead, but this was a problem during serialization. To make this work we passed field names with hyphens as extra keyword arguments in the Meta class of each serializer. If those fields were serializing data themselves, we had to specify the field name and source field in the init function too. For example: 

Another problem with serialization was formatting the dates and times correctly. In order to display datetime objects with milliseconds we had to create a custom encoder class within the JSON renderer. This is our custom encoder: 

Overall, working on this project has been an enjoyable and rewarding experience. The Open Transport API has the potential to make a great impact on the transport industry, and we can really get behind the idea of standardising communication and data sharing in this sector. Our websites mark the first working implementation of the Open Transport API and stand as a taster of what this platform could be used for. 

GitHub library URL: 

CR005 approved and “customer-account” API now v1.0.2

Last week our Board approved Change Request CR005. This change extends the purchase.ticket entity in our “customer-account” API Open Standard to include three new “code” fields, making it easier to integrate UK Rail account data.
The backwards-compatible change also to helps Modal in their recent Innovate UK & Geospatial Commission project to match real-time detection of passenger journeys with transport account data.

This also means we have now updated our “customer-account” API specification to v1.0.2 and published this here:
(This is the latest version of this API and should be used from now onwards)

For more information:

What Open Source license covers our API Specifications?

Everything The Open Transport Initiative publishes on our SwaggerHub API account is automatically covered by the Apache 2.0 Open Source license.

Copyright 2021 The Open Transport Initiative Licensed under the Apache License, Version 2.0 (the

This is one of the most popular licenses for Open Standards and it gives anyone the ability to freely use, modify, distribute and sell software that uses our work. Also, because it explicitly states that anyone using it on an “As Is” basis, there is no warranty and The Open Transport Initiative has no liability.

However, the license clearly mentions that if others make modifications… they must list all the changes they have made to our original API specifications. This is different from other Open Source licenses and helps us understand how our own work can be improved.