Smart Data & Open Data – definitions for Transport & Mobility

There are many terms relating to data being used in the transport and mobility industry right now, with individuals confusing or mixing them up. This has resulted in stakeholders and external observers misunderstanding the industry’s level of data maturity and its commitment to certain standards and practices.

In other words, transport and mobility organisations are using different terms about data interchangeably and these terms are not the same ones used in other industries. This needs to stop and we all need to agree definitions that align with those used by banking, finance, energy, etc.

Two key definitions that we feel need clarification and definition are Open Data and Smart Data.

Open Data for Transport

Open Data is data which is available to all and free to use for any purpose.
Examples of Open Data in transport include public transit timetables & schedules and some operational mobility information, such as anonymised vehicle locations or arrival times.
The most obvious example of Open Data being implemented in transport right now in the UK is the Bus Open Data Service which provides bus timetable data for every local bus service in England.
https://www.gov.uk/government/collections/bus-open-data-service

Smart Data for Transport

Smart data is data which is owned by a customer and then shared with their permission (note: some industries also call this “shared data”).
A recent report from UK Government department BEIS called “Next steps for Smart Data : Putting consumers and SMEs in control of their data and enabling innovation” defines Smart Data as: the secure and consented sharing of customer data with authorised third party providers.
For transport this would mean a customer giving permission to share their ticket or journey data, typically held in an online account, with another authorised third party. This could be another account that the customer has with a different Transport Provider or alternatively a system such as a ‘Delay Replay’ service (which automatically calculates the refund the customer is entitled to when a train, bus or plane journey they have made is delayed).

Sharing Smart Data between customer accounts with different transport providers and Mobility-as-a-Service (MaaS) platforms needs technical system integration. This integration can either be done in a bespoke way (e.g. every transport provider or their systems vendor integrates with each other potentially using different technologies and different specifications) or in a consistent and standardised way (e.g. all providers and platforms use the same Application Programming Interface / API to interface with each other, ideally conforming to an Open Standard – one that is freely available and can be adopted by anyone else).

A Smart Data standard for transport already exists

The Open Transport Initiative was set-up to develop and promote the use of Open Standards for Transport & Mobility, resulting in us publishing an Open Standard for the sharing of transport account data (tickets/purchases, usage/journeys and discounts/concessions) between different providers and platforms. We have therefore created a freely available standard for Smart Data integration across the transport and mobility industry.

Stop making transport data so difficult for the customer

Why does the transport and mobility industry make it so difficult for the travelling customer to be in control of their data?

There are dozens & dozens of different online accounts – one for each Transport Provider and MaaS Platform. Customers have to log into every account to get a complete view of all their transport tickets and usage.

  • Why is there not a way for the customer to view their data in all disparate accounts in the same way?
  • Why are there no services that can present all tickets, permits and passes across multiple different transport modes in a single dashboard (without them being part of one bespoke platform)?
  • Why are there no innovations in this sector that can help the customer make best use of joined-up journey data to help them made faster, cheaper, or greener transport decisions?

Technology is often cited as the reason. But the biggest inhibitor to these innovations is not technology, but the lack of a framework to securely access, use and share that transport & mobility data. Until now…

The Open Transport Initiative was set-up to develop and promote the use of Open Standards for Transport & Mobility, resulting in us publishing an Open Standard for the sharing of transport account data (tickets/purchases, usage/journeys and discounts/concessions) between different providers and platforms. We have therefore created a standardised way to integrate transport and mobility customer account data.

Open Transport speaking at MaaS Scotland 2020 Conference

This year the MaaS Scotland annual conference is being held as a virtual / online event taking place over two days: 30 September and 1 October 2020.

On Day 1 (30 Sept 2020) there will be a Technical Session from 14:00 – 15:15 on the topic of Data and Security, including a presentation and participation from Hayden Sutherland of The Open Transport Initiative.

For more details: https://maas-scotland.com/maas-scotland-annual-conference-2020/

Open Transport welcomes legislation to mandate transport industry participation in Smart Data initiatives

On 9th September 2020 the UK Government published its response to the Smart Data Review conducted in 2019. The report, titled “Next steps for Smart Data. Putting consumers and SMEs in control of their data and enabling innovation” not only cites the success of Open Banking, with the UK leading the way, it also states that although data portability initiatives are developing in finance, energy, communications, and pensions, this progress lags behind that of banking. Notable is the fact that Open Banking existed for around a decade before it got going, with the key driver being legislation to participate and fund its adoption.

It is worth highlighting the section of the report called “Legislating to mandate participation” as that is where transport gets a specific mention. And it is in this section that the authors (The UK Department for Business, Energy & Industrial Strategy) clearly indicate an intention to use legislation to “mandate industry involvement in Smart Data initiatives across the economy”.

What this means is, at the right time, UK Parliament will introduce primary legislation to make different sectors participate in Smart Data (e.g. portable and interoperable data) initiatives and that this will extend to sectors such as retail and transport.

Also, in another section of the same report there are suggestions put forward for future Smart Data initiatives, including for Transport:
“for example, linking trains, airlines, and vehicle data to enable apps that could automatically claim for redress following delays, or enable consumers to track their carbon footprint”

The Open Transport Initiative welcomes the publication of this report and the recommendations it makes for the transport and mobility sector.

Although it is hoped that a “bottom-up” approach to open and smart transport data adoption would allow the linking of data within different accounts of any transport mode (bus, ferry, train, vehicle hire, scooter, etc.), a “top-down” mandate of obligation for the entire sector to be involved in such initiatives would certainly help to accelerate adoption and in-turn benefit customers.

MaaS 2 MaaS : enabling Mobility-as-a-Service interoperability

There’s a gold rush currently underway in the Mobility-as-a-Service (MaaS) market, as the different providers of MaaS platform vendors look to sign-up cities and regions to use their products rather than those of their competition.

However, for those living, working or travelling near the intersection of two or more geographically different transport regions, this may end up with them having to use multiple MaaS platforms. This will mean customers having to use different Apps and switch between different online accounts to view their balance, usage, etc.

What we have created at The Open Transport Initiative is a way for these different MaaS platforms to share the same sort of transport data (e.g. account credit balance or journeys made) in a consistent and open way. Meaning that a customer can link one MaaS Account with any other participating MaaS Account to view the data in all their accounts in a single App or website of their choice.

As these MaaS platforms increase in number and coverage, this “Maas to MaaS” (or Maas 2 MaaS) connectivity is essential for putting the travelling customer (consumer) in control of their mobility data.

Open Transport Founder shortlisted for Digital Technology Award

Details of the 10th Annual ScotlandIS Digital Technology awards has been released today. So we are please to announce that Hayden Sutherland, our Founder & Chair, has been shortlisted in the category of “Unsung Hero Award” for his work on The Open Transport Initiative. The judging panel included experts, champions, and influencers from across the digital technology industry.

The full list of awards and finalists:
https://www.scotlandis.com/blog/shortlist-revealed-for-10th-annual-scotlandis-digital-technology-awards-2020/

Hayden said “I am proud and slightly surprised to have been shortlisted as one of The Unsung Heroes of the ScotlandIS Digital Technology Awards.”

Why does the Transport & Mobility sector need an Open Standard?

There are various parties who would benefit from the adoption of an Open Standard for transport account integration.

Firstly, the customer. Currently, there is no way for an individual to link their online accounts across the different transport providers. As an example, there are 26 different train operators in the UK alone, most with their own online account. Plus the countless bus, tram, river bus, taxi & ride-sharing operators, all with online accounts or apps. Added together it that can pose a lot for the regular traveller to manage.

Secondly, the solution provider/vendor. When they want to build functionality to integrate their product account to another vendor’s, with an open standard they do not have to start from scratch as at least part of the analysis and interface specification has already been done for them. Plus then, when implemented, the integration of successive accounts is a doddle!

Thirdly, larger MaaS (Mobility as a Service) initiatives. Typically implemented on a city-wide or regional basis, these programmes aim to provide a single technical platform and account for managing many different transport services, usually public ones. However, these MaaS platforms don’t allow the customer to manage every transport mode. So what better way to create a wider account footprint than to allow the customer to integrate to those other providers who have also adopted the open transport account standard?

Comparing Transport & Mobility Mode Definitions

As part of the Open Transport Initiative’s work to create our centralised Operator-Info API specification, we also had to create a definition of transport and mobility modes.

Yes, there are other definitions for some modes of transport in different mobility specifications. However none of them covered all the modes of transport a modern mobility ecosystem needs, including both public transit (e.g. bus, rail, subway, etc.) and private (car, cycling, scooter, etc.).

View our 16 defined modes of transport & mobility

We therefore thought it would be useful to those considering adopting the work of The Open Transport Initiative to compare the mode definitions we provide with those provide by other standards bodies.

What other transport standards define modes?

GTFS:
The General Transit Feed Specification (GTFS) is a common format for public transportation schedules and associated geographic information supported by major transit agencies and Google (e.g. for use within Google Maps).
It defines 12 modes of mobility that are used for mass public transportation.

MDS.
The Mobility Data Specification (MDS) is an open standard originally developed by the Los Angeles Department of Transportation (LADOT) in 2018, it is now governed by the Open Mobility Foundation (OMF). It is a standard for two-way integrations between city / regional agencies and transport & mobility providers.
It defines 4 modes of mobility that are used for micro-mobility or vehicle sharing: bicycle, car, scooter and moped.

Note: Neither of these have a definition for walking or other modes needed for a complete joined-up picture of an individual’s door-to-door journey.

The tables shown below give a side-by-side mapping / comparison of each specification’s mode definition.

If anyone would like to consider any additions or changes to these, please see our published amendment process:
https://opentransport.co.uk/2020/02/03/amendment-process-for-our-open-standards/

Example Use Cases for a Centralised Operator API

We have been asked to provide some example scenarios in which an API designed to our Centralised Operator API Open Standard specification could be used.

Here are a couple:

Example Use Case 1
A transport authority or agency creates an innovation programme and need to provide a definitive list and URLs of all data sources that can be used by 3rd party application developers.
By allowing these developers access to the centralised look-up service, they can:

  1. Find the transport provider (Operator) data source they want
  2. Confirm the mode(s) of transport provided by that provider
  3. Find the URLs of data sources made available by that provider
  4. Find the contact details for that transport provider for access to the data… or
    connect to it straight away (if it is a public source)

Example Use Case 2
A taxi company operating in a region keeps getting requests for vehicle registrations (number plates) for all cars in its fleet – e.g. from developers of local authority systems or Police. So, it publishes this public document as an file on its website, but has been known to move the file location over time (e.g. when it changes its web technology or agency).
By submitting the URL of this file to the centralised look-up service (and updating the URL when they change it), the local authority, police or even any 3rd party developers can find this information without having to contact the taxi company.

If you would like to talk to The Open Transport Initiative about our plans for our Central Operator API, then contact us at: contact@opentransport.co.uk

Plans for our Central Operator-Info API

Back at the beginning of 2020, The Open Transport Initiative launched two different API designs as Open Standards. The first was our Customer-account API: A standard way to facilitate peer-to-peer transport data. This gained a lot of attention and is currently the focus of our drive towards transport data sharing and account interoperability.

The second was our Centralised Operator-info API: A design for a centralised look-up service for all transport providers (Operators), agreed 3rd parties and even Mobility-as-a-Service (MaaS) platforms. This design was updated a few months ago, to aligned it to be a PAS212 (the IoT discoverability standard) reference implementation and be a look-up service for MIPTA (Mobile Interface for Public Transport Assets) asset registry URLs,

We therefore have a plan for turning this API design (and private proof-of-concept that we have been working on – shhhh!!) into a more robust and usable service. This means the development of a fully operational (e.g. populated and reliable) centralised look-up service for the transportation industry.

In simplistic terms, this would a working and scale-able digital equivalent of a reference directory for all modes of transportation and mobility and can be likened to sort codes used for banking or post codes for the Post Office. It could therefore be a complete system-to-system directory that could be used by anyone in the transport and mobility industry who wants to publish or find a source of data, either public or private.

For example – a MaaS Platform developer wants to find key information about the service d by a transport provider (e.g. the number of ticket vending machines they have). The MaaS platform developer will contact the look-up service which will in turn direct them to the correct data location if it was available.