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 

Approach:

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: 

Conclusion:
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: 
https://github.com/uofg-cs20 

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:
https://app.swaggerhub.com/apis/open-transport/customer-account/1.0.2
(This is the latest version of this API and should be used from now onwards)

For more information: contact@opentransport.co.uk

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.
http://www.apache.org/licenses/LICENSE-2.0.html

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.

CR005 – Change Request to Custmer-Account API

Open Transport Proposal for Change

Number: Change 005:

To: Customer-account API

Name: Expansion of the “purchase.ticket” entity for additional fare data integration

Breaking change? No

Justification:

Modal is a company who have built mobile app technology that detects a person’s public transport journey in real-time and use this to create rail Delay Repay functionality. As part of a Geospatial Commission & InnovateUK competition Modal won a pitch to investigate the feasibility of integrating location data with transport account data.

The stated aim is to make MaaS easier and to automate Delay Repay rail claims. As part of this, The Open Transport Initiative has a small amount of work, including a review of our “Customer-Account” API, to ensure it can provide enough / correct data to match up with Modal’s data.

During this work, we have identified the need to expand the “Purchase” entity of our “Customer-Account” API to provide more structured data that can be automatically read by technology services such as Modal. (The data fields we have in our spec are sufficient for a customer’s visual inspection, but not sufficient for a system-to-system integration such as this)

More specifically, the API needs to expose not just the rail ticket reference data (which we already have), but also additional structured ticket data, such as: ticket fare type, ticket routing restrictions and possibly even some travel restriction classifications.

Note: Rail Delivery Group (RDG) has a 70 page specification document (RSPS5045) to describe ALL ticket data, which they make available in an Open Data (CSV) feed: https://www.raildeliverygroup.com/files/Publications/services/rsp/RSPS504502-00FaresandAssociatedDataFeedInterfaceSpecification.pdf
We are NOT going to replicate ALL of the RDG specification, just the data needed to meet these sort of rail ticket data integrations. However, we must be aware that more data of this sort may need to be exposed in this way subsequently, so what is required now should not prevent this.

The proposal is to add 3 new “code” data fields to the schema:
Code 1 = fare
Code 2 = route
Code 3 = restriction

Notes:
– Codes can be used for UK rail integration or any other data purpose
– This use of codes data fields also allows other to be added over time, if needed.

For further information and feedback about this change contact@opentransport.co.uk

Open Transport joins the Open Data Institute

The Open Transport Initiative is pleased to announce that it has become a member of the Open Data Institute (most commonly known as the ODI https://theodi.org)

The Open Data Institute was founded in 2012 by the inventor of the web Sir Tim Berners-Lee and Sir Nigel Shadbolt. Its mission is to work with companies and governments to build an open, trustworthy data ecosystem and has a vision of a world where data works for everyone.

This mirrors the role of The Open Transport Initiative to work with all transport & mobility organisations and support the use of Open Standards. It also closely aligns with our founding aim to drive and support the adoption of shared & interoperable data for all transport modes to benefit the travelling customer.

Founder and Chair of The Open Transport Initiative Hayden Sutherland said “Our role is to work with as many reputable companies and individuals across the data spectrum, to support the use of Open Standards in the transport and mobility sector. Joining the ODI was therefore an obvious step and one that will help to communicate and improve the work we have already done”.

For more information: https://opentransport.co.uk

Powering innovation in rail by adopting interoperable smart data standards

Today Hayden, our Founder and Chair , gave a presentation to The Rail Innovation Group on their regular “Munch & Learn” webinar. The session explained the work & future aims of The Open Transport Initiative and was a combination of presentation (titled “Why all transport accounts need to make their data shareable”) and lively Q&A.

Topics covered included:

  • The UK Government has now clearly stated the intention to use legislation to “mandate industry involvement in Smart Data initiatives across the economy” – including transport & mobility
  • Now is the time for Rail to lead by example and commit to adopting interoperable customer account data standards to enable & fuel innovation across our industry

A full copy of the presentation can be found embedded below. And if you would like more information on the topics covered, please contact us: contact@opentransport.co.uk

2021 – the year Transport & Mobility adopts Smart Data initiatives?

Back in September 2020 the Government published the report:
“Next steps for Smart Data. Putting consumers and SMEs in control of their data and enabling innovation”.

In this document it clearly stated the intention to use legislation to “mandate industry involvement in Smart Data initiatives across the economy”. This means that Parliament will make different sectors, including Transport & Mobility, share customer data.

So in the same way that Open Banking delivered Financial Services account interoperability… we can expect the same regulations applied to Mobility-as-a-Service (MaaS) Platforms and Transport Providers across the UK.

The Open Transport initiative was set-up to further the creation & adoption of Open Standards in Transport. In January 2020, after getting the input from over 30 providers, suppliers, and specialists across the industry, we published THE FIRST & ONLY Open Standard API specifications for Transport & Mobility customer account smart data sharing. Learning from what has been successful in other sectors, this work is now known as the “Open Banking for Transport”.

We believe that the adoption of open and consistent smart data sharing standards will help:

  • To put customers back in control of their transportation data
  • To kick-start and enable an ecosystem of MaaS innovation
  • To deliver the UK Government intention of full customer transport account interoperability

2021 is the year that Transport & Mobility needs to shape the future of our industry or be shaped by it.

We therefore have the opportunity to work collectively and together now and adopt Smart Data sharing practices… Before we are legislated and mandated to do so.

Why build a Transport & Mobility Directory Open Standard?

Most people we speak with are surprised to find that a central directory service does not already exist.

The problem of a lack of a technical system-to-system look-up service across the transport and mobility industry was confirmed when we designed & published our Open Standard API for Mobility account interoperability (“The Open Banking for Transport”). We realised that without such a central service there was no way to find other APIs.
E.g. In the same way there was already a working & robust Internet domain name serviced BEFORE people started building websites.

We therefore decided to solve this issue by designing our own directory service and publishing for anyone to use. This specification evolved over time as we spoke with different stakeholders and standards bodies and we now have an Open Standard that also aligns to the Internet-of-Things discovery standard (PAS212)

We saw an opportunity to create a directory service that will be essential digital infrastructure for the entire industry.

And now we spend more of our time explaining the benefits and features of this service.

See also:

The benefits of a Central Operator Directory for Mobility & Transport

Every mature industry has some sort of central directory or look-up service (e.g. the Internet has IP addresses & DNS, telephone have exchanges & directories, the postal service has sorting offices & post offices and banks & financial services have branch / sort codes) with most of these now digitalised. However the transport and mobility sector does not… until now.

We think that the potential for a centralised directory API to be used by data providers and sharers (e.g. transport operators and MaaS Platforms) and data consumer (e.g. any 3rd party value-add service or transport tech innovator) is huge.

The benefits (e.g. time savings) and trust that comes from creating a key piece of modern digital infrastructure that can be used to find the precise digital location of any transport system or API that shares data across our industry is potentially game-changing.

It also (hopefully) supports an entire smart & data-driven transport innovation ecosystem.

More details on our Central Operator directory service are available here
https://opentransport.co.uk/open-standard/

What data entities does the Open Transport “Customer-Account” API expose?

Following various recent enquiries about the data that can be shared consistently between different transport and mobility accounts via our “customer-account” API specification, we thought we would explain each entity here in more detail

Purchase:
The purchase entity covers a product bought or agreed to be used. Such as a pre-paid ticket. e.g. an off-peak single ScotRail Glasgow Queen Street [GLQ] to Edinburgh (Waverley) [EDB] ticket
However, it could also cover the data relating to a contract or permit to travel (e.g. pay-per-use car parking contract or a electric car hire agreement )
https://app.swaggerhub.com/apis/open-transport/customer-account/1.0.1#/purchase

Concession:
The concession entity covers any relevant discount or voucher that the customer may have. Such as a railcard for a route or a person of a particular age.
However, it could also cover data related to free travel promotion for the subway or a staff parking discount scheme in a given area.
https://app.swaggerhub.com/apis/open-transport/customer-account/1.0.1#/concession

Usage:
The usage entity covers any data associated with what the customer has historically done, including travelling on a journey.
Note: Usage/journey data is not always required for billing the customer (e.g. when they already have a pre-paid ticket), it could just be additional data that can be used to VALIDATE their purchase. However, it may be of financial use if the customer’s transport provider or mobility platform needs this usage data for subsequently billing them.
(e.g. to bill them for parking of that pay-per-use car parking contract, or to bill them for energy usage in addition to an electric car hire agreement)
https://app.swaggerhub.com/apis/open-transport/customer-account/1.0.1#/usage

If you have any further questions about the entities covered by our “customer-account” API specification, please contact us: contact@opentransport.co.uk