Much has been written and debated recently regarding the benefit of common data standards and specifications in shared mobility and public transport. It has been claimed that by simply opening up a platform or application to data standards, then users will be able to seamlessly utilize all modes of mobility and reduce the friction seen between systems. However, this promise comes with risks and a long path to implementation. History has shown that in crisis comes opportunity, so perhaps with COVID maybe we will see a breaking of silos and push towards multi-modality?
GTFS and Public Transit
One of the first moves toward data standardization in the realm of public transport. Starting in Portland, Ore., in 2005, the regional public transit agency, TriMet, contacted Google to begin exploring collaboration on an open data standard that would be published and made available for developers. This was a project being internally developed by Google, and they decided to test it out in the Greater Portland area. By incorporating spatial and temporal data (routes, timetables, etc.) from a centralized public transport database, the open feed came to be called the General Transit Feed Specification (GTFS). The outcome of this small project became a worldwide movement towards public agencies proactively sharing their data for the purpose of greater government transparency and private sector demand in third-party apps and platforms.
GBFS and Bikeshare
Modeled after the General Transit Feed Specification, which has standardized transit schedules and routes for developers and researchers, GBFS was officially adopted in November 2015 by the North American Bike Share Association and is supported by a number of bikeshare operators such as Motivate, which runs Capital Bikeshare in the D.C. region. Over 230 shared bike and scooter operators have now adopted GBFS as a way to share real-time information with mobile apps used by millions of travelers around the world. However, the first version of GBFS did not support deep linking to third-party apps. This has been addressed in 2020 by updating the feed specification to enable a seamless traveler experience by tapping on a bike or scooter in the third-party app, and the provider’s rental app is immediately opened to that particular vehicle or station.
MDS and Micromobility
The Mobility Data Specification (MDS), an open-source project of the Open Mobility Foundation (OMF), is a set of APIs focused on dockless e-scooters, bicycles, mopeds, and carshare. MDS provides a standardized way for municipalities or other regulatory agencies to ingest, compare, and analyze data from mobility service providers, and to give municipalities the ability to express regulation in machine-readable formats. MDS helps cities interact with companies who operate dockless scooters, bicycles, mopeds, and carshare in the public right-of-way. MDS is a key piece of digital infrastructure that supports the effective implementation of mobility policies in cities around the world. However, this has not come with controversy. Last March, Uber launched proceedings to sue LADOT in federal court, alleging the data-sharing requirements for its Jump e-bikes and scooters violated state and federal law. All legal proceedings were recently dropped, but exposed the importance of privacy issues related to the sharing, storage, and protection of personal data.
GOFS and On Demand Mobility
MobilityData, a non-profit organization based in Montreal, has assembled an industry working group looking to develop an open data standard (GOFS) so riders can integrate on-demand services with other mobility options in common platforms. Mobility operators are being encouraged to contribute to the development of open standards, and use them to provide public APIs with high-quality data for riders. MaaS platforms are envisioned to play a role in integrating APIs that use open standards to clear the way for riders looking to get from A to B.
Even nonprofits and governments are being recruited into supporting the future GOFS data specification through the creation and adoption of open standards and encouraging governments to make open APIs and data standards part of their mobility programs and first/last-mile options. Yet, this spirit of openness comes with a set of risks and questions to public and private actors in the shared mobility ecosystem. Such as, is this data driven initiative a means to decide who is “in or out” of a MaaS platform or mobility program? And wouldn’t real openness be better driven by taking a more agnostic approach to data standardization, giving governments more flexibility to best decide their policy outcomes?
TOMP-API and Mobility as a Service
The TOMP-API, being developed by the Transport Operators and Mobility as a service Providers (TOMP) Working Group including public and private stakeholders, is aimed at facilitating the implementation of MaaS and the corresponding exchange of data in Europe. The TOMP-API describes a full MaaS journey, including operator information, planning, booking, support, payments, and trip execution. The goal of this API (and the working group developing it) is to provide a generic and open interface between Transport Operators and MaaS Providers, enabling an open ecosystem. The API facilitates the open ecosystem by lowering entry barriers of new actors on the market as they can connect easily to a wide range of stakeholders. Since the focus lies on sharing asset information, both the asset information from free-floating systems and the information from station or fixed-route systems mobility hubs or station-dependent transportation can be shared through the functional descriptions. The TOMP-API specification holds much promise for creating a common standard for MaaS applications, but similar to GOFS cannot be seen as the sole interface in which to develop and build a shared mobility ecosystem.
It can seem enticing to view openness solely under the lens of data. This has been a recurring theme in mobility for the past two decades. While we have seen much progress in sharing and assembling resources to better connect the public and private sectors with respect to technology, the road has been bumpy. Working groups, coalitions, non-profits, consortiums, pilots, and other organizations have all been formed to analyze and implement data-driven standards that offer the promise of fair, open, transparent, and democratic mobility. However, each and every one of us as an individual has to be careful to realize that standards for the sake of themselves are just that, standards. We have to do a better job of identifying desired outcomes (policy, commercial, environmental, etc.), and work backwards to purpose-fitting standards to ensure success. Otherwise, we will continue to take a tech driven approach that is simply a “solution looking for a problem to solve.”
Scott Shepard is VP Global Public Sector with Iomob
Scott Shepard is CCO & CPO at AsistobeView Bio