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

%d bloggers like this: