The Path to Mobility Interoperability

About Mobility Data Interoperability

Mobility data interoperability is a broad concept but is crucial to enhancing the quality of public transportation and shared mobility. At its simplest, mobility data interoperability can be defined as “[t]he ability for any mobility technology component to exchange at an open standard or schema with other components in that mobility technology system”. [1] Unlike proprietary software platforms that do not allow for the sharing of information on other platforms, interoperable mobility data calls for a common format for sharing information. Mobility data interoperability is platform-agnostic, making for information sharing to be open-source from different software vendors.

The following graphics visualize the role open data plays in promoting interoperability. Overall, the illustrations demonstrate the role of Transactional Data Specification (TDS), a planned specification for demand-response services. Still, its underlying principle as an open-source specification applies to other data specifications in the shared mobility space. The first picture below shows how each provider must program their software to be compatible with four proprietary message formats. Whenever an update occurs in a mobility system, each provider must update its software to accommodate the changes. The example underneath demonstrates the benefit of interoperability across platforms, as multiple mobility providers and software vendors can communicate using one message format, in this example, the open-source TDS. [2]

Description: Image illustrating the difference between proprietary APIs and open data specifications like the Transactional Data Specification.
Click on image for full view.
Credit: AARP Public Policy Institute

Data interoperability benefits shared mobility in manifold ways. The creation of data standards and specifications like the General Transit Feed Specification (GTFS), the Mobility Data Specification (MDS), and the General Bikeshare Feed Specification (GBFS) have created a more democratic and open-source ecosystem that enables shared mobility providers and users to exchange and access information. From these, other specifications and extensions of these specifications have sprouted or are in the working group process, like GTFS-Flex, the Curb Data Specification (CDS), the Transactional Data Specification (TDS), and the Operational Data Standard (ODS). SUMC’s Mobility Learning Center has a guide describing many of these data specification and standards and additional resources are available through the Mobility Data Interoperability Principles (MDIP).

The ever-changing nature of the mobility ecosystem leads to an ongoing process development of new standards and the refinement of existing ones. This ongoing change creates an opportunity to enhance transportation equity by improving booking and payment integration on platforms and expanding the discoverability of paratransit services. Moreover, mobility data interoperability can better ensure the reliability of peoples’ journeys on shared mobility and public transportation; improved data interoperability can draw more people to use shared mobility services, positively impacting the environment through reducing traffic congestion, mitigating air and noise pollution, and reversing the impacts of climate change.

Policymakers at the federal, state, and local levels recognize the benefits of data standardization and mobility data interoperability by issuing regulations and implementing pilots. In 2022, the Federal Transit Administration (FTA) proposed requiring all eligible agencies to post GTFS static feeds in their submissions to the National Transit Database. At the time of proposing this requirement, FTA estimated that only 35% of reporting agencies had adopted the GTFS. [3] Preceding this, the California Department of Transportation (CalTrans) began requiring all transit agencies in the state to maintain GTFS feeds in 2020. [4] Other states and jurisdictions are also piloting other types of mobility integration projects. Since July 2021, the City of Pittsburgh has been piloting Move PGH, a Mobility as a Service (MaaS) program that unifies different shared mobility services, like carshare, bikeshare, scootershare, and public transit, co-locating them at mobility hubs and ensuring (through required use of data standards) that each is discoverable through the Transit app. [5] FTA has also issued small innovation grants to NEORide, a council of governments based in Ohio, and the Minnesota Department of Transportation to pilot integrated trip planning apps for member agencies in Ohio, Kentucky, and Michigan and across southern Minnesota, respectively. [6] Data standards like GTFS and GTBS facilitate the creation of these platforms as developers can plug existing open-source feeds into their applications.

Developing the Logic Model

Outside of formal implementation and policy, partners across the private, public, academic, and non-profit sectors, including the Shared-Use Mobility Center, released the Mobility Data Interoperability Principles in October 2021. Over 70 private and public interests have signed on to the principles along with 16 co-authors. These principles are:

1. All systems creating, modifying, or consuming mobility data should be interoperable.
2. Interoperability should be achieved through the development, adoption, and widespread implementation of open standards that support the efficient exchange and portability of mobility data.
3. Transit agencies and other mobility service providers should have access to tools that present high-quality mobility data accessibly, equitably, and in real time to assist travelers in meeting their mobility needs.
4. Transit agencies, other mobility service providers, and travelers should be able to select the transportation technology components that best meet their needs.
5. All individuals and the public should be empowered through high-quality, well-distributed mobility data to find, access, and utilize high-quality mobility options that meet their needs as they see fit, while maintaining their privacy. [7]

Collaborators across the mobility arena recognize the value of enhancing data interoperability. SUMC has looked to channel this political will through its Specs to Standards working group. When the group formed in 2021, many participants came from groups that signed the Mobility Data Interoperability Principles or were piloting MaaS and payment integration initiatives in their communities. The Specs to Standards group represents another cross-industry approach to solving the problem of improving interoperability.

The Specs to Standards working group, whose members represent big and small transit agencies, FTA technical assistance centers, like SUMC, advocacy groups, and departments of transportation, devised a Logic Model on adopting interoperable mobility. This Logic Model is a tool for policymakers, transit officials, mobility providers, and software vendors looking to evaluate the state of interoperable mobility in their communities, service areas, or regions. Presented across five different stages, the Logic Model provides a detailed overview of what concerns officials should consider when evaluating the infrastructure of their mobility systems. The categories outline needs and gaps that exist toward reaching interoperability. The Logic Model can then be used as a guide to developing these resources and tools that transit agencies can use to implement interoperable mobility solutions in their community. These categories, in order, are

1. Set goals;
2. Identify needs;
3. Fill gaps;
4. Implement data standards and elements; and
5. Continue management and maintenance

Each stage has different components: objectives, activities, deliverables, and barriers. A table of this Logic Model is in the appendix, and readers can use the table as a resource when mapping out their process for achieving mobility data interoperability. Below is an overview of each category:

Description: Image representing each stage in the Mobility Interoperability Logic Model.
Click on image for full view.
Credit: Shared-Use Mobility Center

Set Goals: Users come to the Logic Model recognizing the need to achieve interoperability as a hopeful outcome. Interoperability can carry different meanings depending on several factors, such as the size of the service area, the needs of the community, existing mobility infrastructure and assets, and so on. For a transit agency, mobility data interoperability can mean adopting a data specification, like the General Transit Feed Specification; for a larger geographic area, like a state, interoperability can mean mandating the adoption of data specifications for transit and transportation agencies under its purview.

Identify Needs: Different types of mobility systems benefit from different data specifications and standards when looking to achieve interoperability. For example, a rural transit system could enhance its services through adopting the General Transit Feed Specification while a city looking to regulate freight deliveries, taxis, and e-scooters might want to adopt the Curb Data Specification. On top of this, new data specifications continue to enter the shared mobility space. Depending on their scope, and when fully developed and additional resources are linked to the Logic Model, users can research what information is available and not available to them, what information their customers need, access tools to understand their customers’ mobility needs, how widely adopted (or not) agencies have adopted data specifications, what data specifications are necessary, and more. Users can visit resources like The Role of Data Specifications in Creating an Interoperable Transportation System, SUMC’s guide on different transportation data standards, and what types of systems are best suited for different scenarios.

Fill Gaps: As stated above, the advancement of mobility data interoperability requires the creation of new information and the sharing of data. Many data standards and specifications created recently function as extensions or supplements to existing specifications, such as the General On-Demand Feed Specification, the Transactional Data Specification, and the Operational Data Standard. Users in this stage of the Logic Model can map out and determine their needs before committing to a data standard, whether that means partnering with an external vendor or other agencies, strengthening an existing partnership, funding, working with and understanding a community or regions’ mobility needs, researching performance metrics, or establishing best practices.

Implement Data Standards and Elements: Data standards and specifications require iterative management and maintenance. For this reason, it is important to emphasize that this stage and the next, Continue Management and Maintenance, are cyclical; once Implementation is complete, it is important to revisit Continue Management and Maintenance, then Implementation, and so on. This stage often requires procurement, where the users of the Logic Model release a request for proposal (RFP) for vendors who can help to implement a data standard.

Continue Management and Maintenance: In the Continue Management and Maintenance stage, Logic Model users can also evaluate the successes and failures of implementing a data standard in their service area to improve particular elements through the Implementation stage. Among other steps, governance of the data standards, working with the private sector on adoption, and continuing to understand the mobility customers’ travel patterns and needs are important considerations.

Requesting Feedback

The Logic Model aims to provide an overview of what resources are available and what steps are involved in reaching mobility interoperability. SUMC and members of the Specs to Standards working group intend for it to also be dynamic. As a result, SUMC invites community members to offer their constructive feedback. Readers can e-mail policies@sharedusemobilitycenter.org to provide any feedback or suggestions they might have; we also acknowledge all of the industry efforts and, in particular, the MDIP co-authors.

Achieving mobility data interoperability is a moving target that requires constant re-evaluation. New data standards and specifications will enter the shared mobility space, and shared mobility itself will evolve in response to technological advances, demographic changes, and public policies on the federal, state, and local levels. SUMC and the Specs to Standards working group value mobility data interoperability and hope that the Logic Model can serve as a tool to individuals, agencies, and organizations across the industry. Since this Logic Model is an evolving tool for a rapidly changing industry, it should not be seen as simply a tool that serves those using it, but as a call to action.

SUMC asks users of the Logic Model to:

• Provide input to build on and improve the Logic Model;
• Identify barriers for your service area that can be addressed through mobility data interoperability;
• Identify available resources that address Logic Model steps;
• Provide financial or in-kind support to address identified gaps and pilot mobility interoperability solutions;
• Share lessons learned on mobility interoperability pilots;
• Identify gaps in data interoperability solutions.

Updates to this case study and the Logic Model will be made on a rolling basis.

If you are interested in providing feedback or learning more about SUMC’s work in the mobility data interoperability space, we encourage you to reach out to policies@sharedusemobilitycenter.org.

Appendix: Specs to Standards Working Group Participants

SUMC would like to thank the support and contributions of the Specs to Standards Working Group in developing the Mobility Data Interoperability Logic Model.

• Bonnie Epstein, Director of Mobility Services, Pinellas Suncoast Transit Authority, St. Petersburg, Florida
• AJ Farris, Planning Manager, Kansas City Area Transportation Authority, Kansas City, Missouri
• Sarah Hackett, Public Transportation Network Coordinator (former), Oregon Department of Transportation, Salem, Oregon
• Elliott McFadden, Greater Minnesota Shared Mobility Program Coordinator, Minnesota Department of Transportation, St. Paul, Minnesota
• Bibiana McHugh, Manager of Mobility and Location-Based Services, TriMet, Portland, Oregon
• Elizabeth Sall, President, URBANLABS, Seattle, Washington
• Charlie Stanfield, Planning Project Manager, Regional Transportation District, Denver, Colorado
• Frank Thomas, Regional Transit Coordinator, Oregon Department of Transportation, La Grande, Oregon

We would like to recognize Rik Opstelten from the Federal Transit Administration (FTA), Program Officer for the Shared-Use Mobility Center, who supported our work to develop the toolkit.

Appendix: Mobility Data Interoperability Logic Model

As more tools and resources are available they will be linked directly in the Logic Model. Additional details on the Logic Model processes and available resources can be found below the tables.

Setting Goals

↓

Identifying Needs

↓
Filling Gaps

↓
Implementing Data Standards

↓↑
Continuing Management and Maintenance

Appendix: Further Explanation on the Logic Model Steps

Setting Goals:

• Community building around interoperability as a needed feature
  • Can take place through a variety of public formats, such as open houses, online commenting platforms, 311 submissions, and in partnership with local and regional transportation and shared mobility advocacy organizations and consultancies
• Define requirements for what constitutes “interoperability”
  • Interoperability is a lofty goal and can manifest itself in different ways for mobility systems. What is the desired end result? Partnerships across mobility providers? A new fare payment platform? New data standards? Participants in this process must agree on the goal(s) of the process at the start.
  • Interoperability can involve using proprietary APIs or using open and universal data standards like GTFS or TDS. Mobility providers need to understand these differences and their implications. Proprietary APIs, while often efficient, limit the ability to share data, while using data standards outline how to share data across many platforms. [8]
• Define transit agency vision and outlining the role of specifications in that vision
  • Decision-makers at the transit agency, like board members and executive officers, must endorse this process for an interoperability process to be successful
  • Support needs to be in place to help transit agency staff build technical capacity and work with and understand user mobility needs
• Journey-mapping user needs
  • Journey-mapping is a design thinking exercise that envisions the end product and the types of users who need or can benefit from that product
• Getting buy-in from agencies/agency lack of awareness
  • Many potential partner agencies either lack the resources or political will to enter this type of process alone. If this becomes a cross-agency effort, it is important to convince decision-makers at those agencies of the potential benefits of collaborating on an effort to achieve mobility data interoperability.

Identifying Needs:

• Define systems of interoperable components
  • Interoperability requires the resources and the adoption of new tools. Does interoperability require the installation of GPS units on transit vehicles? Partnerships with app developers or consultants? Hiring of IT staff? Development of feeds or adoption of application programming interfaces? Buy-in from other transit agencies, shared mobility operators, and software vendors? Elements like this must be considered.
• Intergovernmental/private partnership building
  • What other agencies and mobility providers can participate in your planned service area? Other transit agencies? Any community-based organizations?
• Necessary staff skills to use and maintain data specifications and standards
  • Does your existing staff have the skills to navigate an interoperability process? What expertise does your staff carry or lack? Do you need to hire additional staff or contract with a consultant? Are there other transportation agencies your agency partners with that can provide you with staffing resources?
• Catalog of existing/emerging standards and available tools for data collection and processing
  • Many existing standards, like GTFS, its extensions, GTBS, and MDS can address the needs of mobility providers. Other industry partners are also developing new extensions and specifications intended to address gaps in information sharing. Different vendors and other industry partners have also created resources designed to help mobility providers to implement data standards and specifications.

Filling Gaps:

• Establish working groups to develop draft specifications
  • Working groups typically involve staff members from public agencies, private mobility providers, advocacy groups, and technology vendors who can offer unique perspectives and levels of expertise.
• Document diversity of use cases to ensure the standard addresses them comprehensively
  • Mobility providers should envision how adopting a data standard or specification could apply to their needs. This can be done by identifying scenarios and how a data specification can help to address the problem within that scenario.
• Pilot projects to test implementability
  • Beta testing of standards, APIs, and feeds is essential to identifying potential bugs and ensuring the smooth operation of specifications. Pilots can also demonstrate the positive and negative aspects of a data specification before it would be implemented more broadly.
• Funding for backbone organizing/leadership/Assigning leadership duties and matching it with funding
  • Implementing a new data specification requires time, staff, and resources from mobility providers. What existing and potential funding sources can support the governance of the specification? Grants? Membership fees?
  • There should be a funding program that supports the development and implementation of open standards. Costs associated with developing and piloting data specifications can be significant and without financial support, innovation can be stalled. Incentives can help to defray these costs and promote further innovation, particularly for first movers in the industry.

Implementing Data Standards and Elements (Iterative Process):

• Procurement guidelines
  • Requests for proposal and information are a necessary component of implementing a new data specification. RFPs and RFIs allow agencies and mobility providers to clearly outline their needs to potential vendors and consultants.
• Data privacy is a core component to open-source data and must be practiced including an understanding on how to handle and secure sensitive data. Reference Mobility Data Specification (MDS) privacy considerations.

Continuing Management & Maintenance (Iterative Process):

• Research on appropriate organizational homes
  • Many private data governance organizations provide expertise on managing data specifications. Is an existing organization the best resource to host a new standard? Or should a new organization be formed? Would a public agency also be a good steward instead?
• Establish governance and a business model
  • How will the governing organization be financially supported? How will they operate to ensure the ongoing success of the specification? What activities are necessary to support the success of that specification? How will this organizational home collaborate and communicate with other industry partners?
• Work with public agencies to adopt standards
  • Different agencies have different resources, meaning that some will require more convincing and assistance than others
• Vendors do not feel that data standardization is necessary for their customers
  • Procurement processes can incentivize vendors to incorporate data standards and specification in the products they offer to their customers, leading the industry to share more open-source information

Appendix: Resources

This list will be updated regularly to reflect new resources and tools that become available.

Users: Policymaker (DOT, FTA, FHWA, etc) vs. Local (transit agency, DOT, MPO)

The Role of Data Specifications in Creating an Interoperable Transportation System: A case study and guide that provides an overview to data specifications and standards in the shared mobility space.

CPACS Ride Case Study: Provides an overview to different phases of an Atlanta-area community-based microtransit project. Different pieces of this case study review elements like building trust, procurement, planning and implementation, and trip sharing.

Incorporating UX Design into Transportation Solutions: A blog piece that discusses user experience design and journey mapping.

Mobility Data Interoperability Principles: A resource calling for an “industry-agreed upon vision, definition and direction for achieving interoperability with clear roles and responsibilities”.

Modernizing Demand Responsive Transportation for the Age of New Mobility: This paper shows how the Transactional Data Specification can be used to improve the coordination of DRT services.

Mobility Data Specification (MDS) overview highlighting data privacy.

Seamless Payments for Complete Trips: A Guide for Transit Agencies Shared-Use Mobility Center White Paper offering a conceptual framework to help agencies systematically approach payment integration for their community.

Last updated February 2023

References

1. Mobility Data Interoperability Principles: ‘Definitions’. https://www.interoperablemobility.org/definitions/#interoperability. Accessed January 18, 2023.
2. AARP Public Policy Institute: ‘Modernizing Demand-Responsive Transportation for the Age of New Mobility’, published December 15, 2020. https://www.aarp.org/ppi/info-2020/modernizing-demand-responsive-transportation.html.
3. Federal Transit Administration: ‘National Transit Database Reporting Changes and Clarifications’, published July 6, 2022. https://www.regulations.gov/document/FTA-2022-0018-0001.
4. California Department of Transportation: ‘California Transit Data Guidelines’, published December 13, 2022. https://dot.ca.gov/cal-itp/california-transit-data-guidelines.
5. Shared-Use Mobility Center: ‘Shifting the Mobility Paradigm with Move PGH, Pittsburgh, PA’, published October 13, 2021. https://learn.sharedusemobilitycenter.org/casestudy/shifting-the-mobility-paradigm-with-move-pgh-pittsburgh-pa/.
6. Mobility Innovation Collaborative at the Shared-Use Mobility Center: ‘About the Projects’. https://sumcmic.org/about/. Accessed January 18, 2023.
7. Mobility Data Interoperability Principles: ‘Mobility Data Interoperability Principles’. https://www.interoperablemobility.org/. Accessed January 18, 2023.
8. Shared-Use Mobility Center: ‘The Role of Data Specifications in Creating an Interoperable Transportation System’, published November 10, 2022. https://learn.sharedusemobilitycenter.org/casestudy/the-role-of-data-specifications-in-creating-an-integrated-transportation-system/.
9. Mobility Data Specification (MDS) overview highlighting data privacy: MDS & Data Privacy at the OMF | Open Mobility Foundation. Accessed February 17, 2023.