Multimodal transportation data formats (& gaps) roundup, July 2016

Update: There is a newer version of this roundup for December 2017.

How do we describe the whole transportation network?

Introduction: towards comprehensive data

The multimodal transportation network is greater than the sum of its parts. Abundant mode options — including public transit, bikeshare, carshare, ride hailing (TNC), rideshare, and vanpool — complement each other to serve different travel needs efficiently. But a transportation network with so many dimensions and possible combinations is too complicated to understand without help from software. There is no truly comprehensive map or app for this emerging multi-modal transportation network yet, though applications and APIs such as OpenTripPlanner, OneClick, Swiftly, Roadify API, RideTap API, GoLA, and Transit App do show transit with a limited number of other modes. One of the barriers to comprehensive multimodal journey planners and apps is the lack of standardized formats for all transportation modes.

Rocky Mountain Institute’s Interoperable Transit Data project and report provides an overview of the benefits of interoperable transportation data, functional needs, and barriers.

We are making progress. Here is the transportation data formats roundup for July 2016.

The “one format approach”: GTFS-SUM

GTFS-SUM (SUM = Shared Use Mobility) was offered in 2015 as concept and draft specification aiming to combine service availability information for many modes, including transit, bikeshare, carshare, and ride-hailing, into one data format. However, GTFS-SUM demonstrates the difficulty and limitations of describing different modes in a single specification; as such, it represents a useful thought experiment. Notably, the draft GTFS-SUM (v1) would break backward compatibility with the current GTFS, which would greatly hinder adoption by transit agencies.

The “family of specifications” approach

The ambitions of GTFS-SUM are being fulfilled by several specifications and projects that are focused around particular needs and stakeholders, below. For many modes, there are presently only draft/proposed specifications, or there are many specifications, including several that are vendor-specific, without any accepted standard.

Fixed-route transit

GTFS and GTFS-realtime have emerged as de facto standards for fixed-route static and real-time data. However, at this time, the GTFS lacks consolidated best practices documentation, and is missing abilities to describe all parts of transit service. CityMapper and Apple Maps, for example, show aspects of transit service that are not described in GTFS. TransModel may be a useful resource to discover aspects of public transit service that would be useful to describe in GTFS.

Trillium’s December 2015 post GTFS Today, and Tomorrow outlines the successes of GTFS and some of the challenges the GTFS community is working on.

Demand-responsive transportation

A draft variant of GTFS called GTFS-flex has emerged, which is backwards-compatible with GTFS. The Oregon Dept of Transportation (ODOT), Vermont Agency of Transportation (VTrans), Jacksonville Transportation Authority, TriMet, Denver RTD, and Anaheim Transportation Network have begun or proposed projects that involve producing prototype GTFS-flex data and building trip planners and maps that consume the data.

The draft GTFS-Flex aims to cover various demand-responsive transit (DRT) service types. It is useful to integrate DRT and fixed-route transit services types in one specification because many public transit routes switch between fixed-schedule/route & DRT operation mid-route.

GTFS-Flex covers the following types of DRT, defined in TCRP Report #140 – A Guide for Planning and Operating Flexible Public Transportation Services:

  • Route Deviation
  • Point Deviation
  • Demand-Responsive Connector
  • Request Stops
  • Flexible-Route Segments
  • Zone Route

TCRP Web-Only Document 62: Standardizing Data for Mobility Management identifies two needs for data specifications with demand-responsive transportation:

  • Discovery (& eligibility) data, which allows transit service areas to be mapped and returned in a trip planner. GTFS-flex fulfills this need for “discovery” data.
  • Transactional data and interfaces, which make it possible to inquire on availability for a particular trip, and book and pay for that trip.

SUTI is a Scandinavian data specification for booking and brokering demand-response trips, including with taxis. It has widespread adoption in Scandinavia. The coalition that formed around TCRP Web-Only Document 62 is interested in SUTI.

There is a lot of shared needs between data specs for TNC, taxi, and public transit DRT modes, so hopefully efforts can be coordinated or, at least, lessons shared.

Bikeshare

The General Bikeshare Feed Specification (GBFS) was created by a bikeshare industry group. It is currently in-use in prototype versions of OpenTripPlanner.

Carshare

Two major carshare companies offer their own APIs:

Ride-hailing

The two dominant transportation network companies (TNC) offer their own APIs:

Unfortunately, both Uber and Lyft currently place restrictions on the use of their APIs to prevent apps from showing competitive services. See Fortune Magazine, “Harvard Professor Suggests Uber Restrictions Stifle Competition” (June 6, 2016). These restrictions prevent apps from showing both Lyft and Uber options, and also effectively strangle alternative TNCs (such as Get Me or Split) from serving the transportation market.

Ridesharing

There have been a number of efforts to create rideshare/carpool APIs, but I do not believe any have caught on. Privacy issues are one of the challenges to rideshare APIs. Here are three example APIs:

Vanpool

I do not know of any standardized formats or interfaces for vanpool. Vanpool has need for both discovery and transactional data formats, and so could use GTFS and GTFS-flex for discovery data.

Streets (motorway, bike, pedestrian network), traffic and road incidents

OpenStreetMap is the world’s open data repository for the street network. Open511 is an open specification to describe road incidents and construction projects.

Roundup summary

“The nice thing about standards is that you have so many to choose from.” – Andrew Tanenbaum

The multimodal transportation network is complicated, as is its emerging landscape of data specifications. I don’t believe that we can expect to define a single standard for all modes. Instead, a suite of data systems and formats that work together (like GTFS, GTFS-realtime, OpenStreetMap, and GBFS already do) will constitute a foundation for more integrated traveler information and transportation network planning. For this collective effort to succeed, each individual effort needs to work in the open and remain aware of the other formats.

I’ll look forward to reporting progress in another “data specs roundup” next year. In the meantime, let me know if I missed anything, and let us know if you want to collaborate with Trillium on moving interoperable transportation data specifications forward.