Since 2021, the Shared-Use Mobility Center (SUMC) has convened a Specs to Standards working group, in partnership with the Federal Transit Administration (FTA). In these meetings for the working group, advocates, planners, and policymakers from the private, public, and nonprofit sectors discussed the need for data standardization across the shared mobility industry. This case study is part of SUMC’s technical assistance work for the FTA that is conducted under the Mobility Innovation Collaborative program.
This tool is a product of the Mobility Innovation Collaborative (MIC) program, a partnership between the Shared-Use Mobility Center and the Federal Transit Administration. The MIC program provides a comprehensive suite of technical assistance resources, promotes knowledge sharing activities, and captures stories and lessons learned from nearly 50 innovative mobility projects across the United States.
The group set out with the following goals:
Conducting organized discussions around issues confronting the adoption of data specifications;
Complementing parallel technical efforts by providing a support structure around policy and other non-technical aspects of data standardization;
Identifying best practices, policies, and other approaches that transit agencies or other local governments can take to accelerate the adoption of data specifications;
Creating an easily digestible roadmap for agencies and the transit industry to systematically incorporate specifications into their service and policy frameworks;
Promoting the benefits of data standardization, especially around mobility integration and complete trips; and
Establishing a network of practitioners to share ongoing challenges and solutions to broader adoption of data specifications.
Through ongoing meetings, participants in the Specs to Standards working group collaborated to develop a Mobility Data Interoperability Logic Model. This Logic Model expresses the value of data standards in shared mobility and outlines the overarching steps the industry needs to address to reach interoperability. Policymakers, transit officials, and mobility providers can use the Logic Model to identify a path toward interoperability and the available resources and tools necessary to address challenges and gaps in the process. For example, Procurement Guidelines is listed as an Activity under the Continue Management and Maintenance category in the Logic Model. Knowing that procurement is a challenge that transportation agencies confront when selecting a private mobility operator or a scheduling software vendor, resources can be developed to navigate relevant challenges.
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”.  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. 
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.  Preceding this, the California Department of Transportation (CalTrans) began requiring all transit agencies in the state to maintain GTFS feeds in 2020.  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.  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.  Data standards like GTFS and GTBS facilitate the creation of these platforms as developers can plug existing open-source feeds into their applications.
All systems creating, modifying, or consuming mobility data should be interoperable.
Interoperability should be achieved through the development, adoption, and widespread implementation of open standards that support the efficient exchange and portability of mobility data.
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.
Transit agencies, other mobility service providers, and travelers should be able to select the transportation technology components that best meet their needs.
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. 
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
Implement data standards and elements; and
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.
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 firstname.lastname@example.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 email@example.com.
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. 
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.
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.
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):
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.
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
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.