Open Transport presents to Ticketing Card Forum

Today (3 December 2019), Hayden presented the work of the Open Transport initiative to the Ticketing Card Forum (TCF) in London run by Smartex. At the event, he explained how Mobility-as-a-Service (MaaS) is maturing as a concept, that transport start-ups are growin in number & market share and that Maas platforms across cities and regions …

Where else do federated accounts exist?

Open Transport is based upon the idea that that different transport and mobility accounts owned by the same individual can be integrated together in a federated manner. This means that the Transport Provider can still have their own customer account and that is does not need to be merged up into one super account e.g. …

Why we decided to create Open Transport

The Open Transport standard for customer account interoperability facilitates the integration of different transport accounts owned by the same individual. Once accounts are linked, the standard allows a person to view all purchases, usage and even concessions (e.g. discounts and railcards) in another account. This works in the same way that Open Banking does for …

Open Transport and ITSO

Whilst receiving feedback about our evolving customer account API specification, we have also had some people ask us how the Open Transport standard for secure account integration works with ITSO. Therefore we thought this post should clarify things… Open TransportThe Open Transport standard for customer account interoperability facilitates the integration of different transport operator accounts …

Why peer review of a standard is important

The Open Transport initiative currently have two different API specifications our for wider peer review: 1. Customer-accountThis is a standard for the interoperability of transport account data. The current data types described are: Purchase, Usage & Concession 2. Operator-infoThis is a standard for a central look-up service for all transport /mobility. Its main purpose is …

Customer Account API spec update to v0.9.2

We have now updated the ‘Customer Account” API Specification to version 0.9.2 This is available to view on SwaggerHub here: https://app.swaggerhub.com/apis/open-transport For this update we have added to the “usage” entity potentially any number of “services” that are consumed. Each ‘service” each having a “type” and “amount”. So as well as expecting to cover “services” …

Open Transport Customer Account API now available on ProgrammableWeb

We have submitted our “Customer Account” API to ProgrammableWeb, the world’s leading source of news and information about Internet-based APIs and this has been accepted. Details can be found here:https://www.programmableweb.com/api/open-transport-initiative-uk Note: This version submitted (v0.8.1) was the one issued for wider industry peer review and ratification. However it has been updated since, based on some …

The problem with a dis-aggregated transportation network and why one MaaS Platform is not the answer

Residents and visitors of cities, regions and even countries often face a dis-aggregated public transportation network (what we have alternatively called a fragmented transport landscape). Making it more difficult for them to move around without resorting to private transport modes that are typically higher carbon producing than their mass transit competitors. So the idea of …

Benefits of Open Standards in Transport

Open Standards are useful when developing a technical system. They help to ensure that one application can work with another application in a common way. They therefore provide flexibility to the solution, as they enable: Data to be shared Software to be written by different people or organisations Components to be reused and adapted And …

The first API Directory for Transport?

Devising a centralised transport operator look-up service has been an interesting output for the Open Transport initiative (as well as creating the actual customer account integration API). But it wasn’t something that we originally anticipated that we would need to do. It was just something that we identified along-the-way as being necessary for true interoperability …