Multimodal transportation data formats (& gaps) roundup, December 2017

This is an update to the Multimodal transportation data formats (& gaps) roundup, July 2016.

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 comprehensive map or app for this emerging multi-modal transportation network yet, though applications and APIs such as OpenTripPlanner, OneBusAway, OneClick, GoLA, Citymapper and Transit do show transit with other modes. One of the barriers to comprehensive multimodal journey planners and apps is the lack of standardized formats for all transportation modes.

Further, lack of standardized data formats also means that transportation planners have a less complete picture of the multimodal transportation network and traveler behavior.

Rocky Mountain Institute’s Consortium Approach to Interoperable Transit Data paper 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 December 2017.

Fixed-route transit

GTFS and GTFS-realtime have emerged as de facto standards for fixed-route static and real-time data. There are now Best Practices for GTFS, which were developed by 17 organizations, with facilitation through RMI’s Interoperable Transit Data project. The pace of specification discussion and improvement has picked up considerably for GTFS. Many transit apps —Transit, Citymapper and Apple Maps, for example — show features of transit service that are not described in GTFS, and it would be useful to add these features. 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.

NeTex is a general purpose XML format designed for the exchange of complex static transport data among distributed systems managed by the CEN standards process. NeTex is a derivative of TransModel, the CEN European reference data model for public transport.

Demand-responsive transportation

A draft variant of GTFS called GTFS-flex, backwards-compatible with GTFS, has been implemented in an alpha version of a flexible trip planner (based on OpenTripPlanner).

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.

TCRP G-16 (in-progress) is developing transactional data specifications for demand-responsive transportation.

Bikeshare

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

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 the TNC market — preventing upstart TNCs (such as Get Me or Split) from becoming available to more customers through third-party applications.

SAE Shared and Digital Mobility Committee appears to be working on a data standard for car share and transportation network companies (TNCs) / rideshare.

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, parking), traffic and road incidents

Proposed transportation projects and analysis

The transportation planning and modeling discipline requires that proposed projects (new roadways, bus routes, rail alignments, etc.) are “coded” (described in a machine-readable format) for analysis and simulation. Shapefiles (for ArcGIS), GTFS, GeoJSON, and other formats are all used to encapsulate proposed projects.

The Zephyr Foundation has proposed a General Network Feed Specification which would enable machine-readable descriptions of projects to be much more standardized, portable, and efficient to use. Zephyr outlines goals to leverage existing popular standards and sources [e.g. GTFS and OpenStreetMap] where possible, and to develop capabilities for:

  • Diff-able networks
  • Scenario development
  • Version control/flow standards
  • Projects/master networks

Some other data specifications are in development to enable us to describe traveler behavior and transportation system performance:

  • GTFS-plus – A GTFS-based transit network format for vehicle and capacity data suitable for dynamic transit modeling developed by Puget Sound Regional Council, UrbanLabs LLC, LMZ LLC, and San Francisco County Transportation Authority.
  • Dyno-Demand – A GTFS-based travel demand data format focusing on individual passenger demand suitable for dynamic network modeling developed by San Francisco County Transportation Authority, LMZ LLC, and UrbanLabs LLC.
  • Dyno-Path – (Under development – see this post) Data for individual passenger trajectories.
  • GTFS-stat – An extension to a GTFS transit network with additional files that contain performance data developed by UrbanLabs LLC and San Francisco County Transportation Authority.
  • GTFS-ride – An open, fixed-route transit ridership data standard developed through a partnership between the Oregon Department of Transportation and Oregon State University.

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.

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.