20 minutes Author: Shared-Use Mobility Center Date Launched/Enacted: May 11, 2021 Date Published: April 11, 2022
In this digitally-powered, mobile age, transportation providers have to share data across multiple applications and tools and with regulators and other government entities. This is crucial for enabling travelers to plan trips and for cities to understand transportation needs. Moreover, with the widening scope of mobility apps like Google Maps, Apple Maps, Transit, and Moovit, it is increasingly more important to share service information in ways that can be readily interpreted by a variety of platforms.
Specifications and standards are fundamental in this process. They establish reliable, agreed-upon frameworks for communicating and exchanging transportation data. In public transportation and shared mobility, these data carry information like routes, stops, schedules, and fares, and regulatory information like parking rules or operational areas. This case study provides an overview of major transportation data specifications and standards and how they can be useful to professionals across the transit and shared mobility industries. For mobility service providers, in particular, it provides resources that can help you make data more readily available for agencies and the public and allow for integration of services.
Before exploring some of the existing and developing data specifications and standards in the transportation field, it is important to understand some key terms and concepts:
1. What is the difference between a data specification and standard and why do they matter?
A specification is the prescription or outline for how data should be conveyed between parties. For example, the General Transit Feed Specification (GTFS), which will be explored in greater detail later in this case study, suggests that data from a transit agency be delivered in a particular format so that applications like Google Maps or Transit can present easy-to-digest and up-to-date information to the agencies’ customers. When a specification becomes more widely adopted or is endorsed by an industry, it becomes a standard overseen by a governing organization. In other words, if enough entities use a data specification, they become a standard, allowing for the broader adoption of multimodal integration and enhanced awareness of mobility options for travelers. Jana Lynott elaborates on this differentiation between data specifications and standards in Modernizing Demand-Responsive Transportation for the Age of New Mobility (2020). In short, all data standards are specifications but not all specifications are standards. 
2. What types of transportation data specifications exist?
In the transportation field, several specifications exist in various stages of development. It is important to recognize that data for specifications exist in two forms: discovery data and transactional data.
Roger Teal et al. concisely outline this dichotomy in Development of Transactional Data Specifications for Demand-Responsive Transportation (2020): “Discovery data is information about what services exist, their configuration, and possibly their current status, for example, ‘The next bus on Route 12 arrives at Elm Street at 9:35 AM.’ In contrast, transactional data includes all the information travelers need to actually book and schedule a specific trip, including payment information.” (p.32) 
3. What is an open vs. closed data architecture?
Since data specifications and standards serve as templates to stakeholders in the transportation industry, it is important that they have an open architecture so that providers can develop and present data in a common format across platforms. An open architecture is “a technology infrastructure with specifications that are public as opposed to proprietary”.  Many technology companies, such as transportation network or micromobility companies, present their own information to users through a closed and proprietary architecture, which are sometimes referred to as “walled gardens”.
An open data architecture allows, among other things, third parties to interpret and present the data into their own or other platforms. While this will be explored later in greater detail, it is important to note that data are often made publicly available on a transportation provider’s website. This allows developers and members of the public to quickly access an agency’s or company’s information so that they can use it readily in their applications or analysis. On top of this, data specifications should have a governance plan and be flexible and iterative—as needs change and new technologies enhance the ability to exchange information, specifications need to be updated or replaced. Adaptable and iterative specifications help transportation service agencies provide the most useful and current information to developers and ultimately, its users.
4. Who oversees the development and operation of data specifications and standards?
Typically, when data specifications are in the process of being designed, professional communities and industry working groups collaborate and determine the need of said specification. When data specifications become established as standards, they are often adopted by governing organizations that oversee and facilitate their continued development. MobilityData, for example, now stewards the General Transit Feed Specification and General Bikeshare Feed Specification, while the Open Mobility Foundation stewards the Mobility Data Specification. These governing organizations can serve as valuable resources in accessing information about data standards and the people in their respective communities.
5. Why are data specifications relevant for me?
Whether you work at a transportation network company, a micromobility provider, or a transit agency, data specifications can help you to understand and relay accurate information to users, vendors and stakeholders. Much like a coding language, it is an accessible, well documented, and commonly understood tool that creates a connected and efficient mobility network.
6. Can data specifications promote equity?
Data specifications have helped to make public transit and shared mobility more user friendly and transparent. Some data specifications have made information for public transit and shared mobility accessible through our phones and computers. Before these data specifications, people relied on analog modes, like timetables, to determine which buses and trains to use. As a result, people would not know if public transportation was off schedule or if any bikes were available at a nearby docking station.
Data specifications also give transit agencies and mobility companies formats in which to present their information, like regulations, routes, stops, and location of vehicles to customers and policymakers. New tools and technologies have come about alongside the development of these specifications that help agencies and other transportation providers translate complicated information into more outlined formats. With specifications, transportation providers of different sizes and resources have the ability to better communicate information to their customers. Some of these resources are explored in other sections of this paper.
While specifications can help to improve mobility options and promote a more equitable transportation system, there are some potential down sides to their use. Specifications often overlap in their purposes as they are typically governed by volunteer steering committees of transportation professionals. The processes to develop specifications that are adopted by the broader transportation industry can be lengthy and a drain of resources if not successful. On top of this, those who benefit from data specifications, namely customers of transportation providers, need to have access to technologies like smartphones. Individuals and communities cannot benefit from data specifications if they lack access to particular mobility options or infrastructure. Moreover, basing mobility planning decisions solely on data without checks and balances nor understanding how the data are maintained and audited can have implications if the data are biased in nature and do not portray what is really happening on the ground.
7. I’m overwhelmed. I don’t know where to start with data specifications and all of this is new to me. I don’t have the capacity to translate my transportation data into som
e other format.
Good news! Many of the data specifications have budding or strong communities that support them. Currently, there are many low-cost or free tools that can help you translate your data so that it will be more useful to app developers and more importantly, your users. Let’s explore some of these data specifications and the tools and resources that you can access. Often, a good time to begin working with open-data solutions is when an agency procures or renews mobility contracts.
|Specification||What it does
||Resources||Governance Structure||Where it’s deployed
|General Transit Feed Specification (GTFS)||Specifies the format in which transit agencies should present realtime and static data for interpretation by app developers and use by the broader public.||Stewarded by MobilityData with a working group of sixteen organizations. ||Over 1,200 transit agencies internationally. |
|GTFS-Flex*||Accounts for on-demand and responsive transit services as an extension of GTFS.||Stewarded by MobilityData.||Limited amount of pilots in operation.|
|General Bikeshare Feed Specification (GBFS)||Specifies the format in which micromobility providers should publicly present service information, including vehicle and dock location and availability.||Stewarded by MobilityData.||More than 520 micromobility providers internationally. |
|GTFS-OnDemand*||A GTFS extension that outlines how on-demand transportation providers, like taxicabs and ridehails, should present real time information and transactional data, for interpretation by app developers and use by the broader public.||In the working group phase facilitated by MobilityData.||Not yet in use.|
|Mobility Data Specification (MDS)||Outlines a structure for mobility providers and jurisdictions to securely communicate trip, vehicle, service, and regulatory data. In contrast to GBFS (which is included as a public-facing subset of what MDS provides), the raw data is not intended for consumption by the public or mobility apps.||Stewarded by Open Mobility Foundation.||More than 115 cities internationally. |
|Transactional Data Specification (TDS)||Outlines how transactional data should be presented from shared-mobility companies for interpretation by app developers and use by the broader public.||
||In the working group phase.||Several pilots underway. Learn more from AARP.|
|CurbLR||Communicates curb-use regulations from local governments to mobility, delivery, and freight services and the broader public.||Stewarded by SharedStreets.||
Limited number of pilots in operation and more underway.
|Curb Data Specification (CDS)||Also provides a formula for communicating regulations between local governments, mobility, delivery, and freight services and the broader public.||Stewarded by Open Mobility Foundation.||Over two dozen cities and companies. |
|Operational Data Standard (ODS)||Outlines how information like personnel and non-revenue service in transit systems should be expressed between parties.||Stewarded by the California Integrated Travel Project (Cal-ITP) and a working group of over 40 transit agencies and technology vendors. ||Various transit agencies participating in the ODS working group are looking to deploy ODS.|
|GTFS-Capabilities||An extension of GTFS that outlines how to communicate the specifications of specialized transportation providers, like seats, vehicles, or schedules.||In the working group phase at Oregon Department of Tranportation Public Transportation Division ||Not yet in use.|
|GTFS-Eligibilities||An extension of GTFS that outlines how to communicate the requirements of customers for accessing specialized transportation services, such as age, disability status, or income.||In the working group phase at Oregon Department of Tranportation Public Transportation Division ||Not yet in use.|
*Note: GTFS–OnDemand is built on top of GTFS-Flex through the GOFS (General On-Demand Feed Specification) project.
General Transit Feed Specification (GTFS)
The General Transit Feed Specification (GTFS) is the most widely used transportation data specification. Established in 2006 as a collaboration between Google and TriMet in Portland, Oregon, GTFS is a tool for transit agencies to communicate transit service information to the public.  GTFS is “an open data standard that allows transit agencies to produce data describing their transit service in a format that can be commonly understood and consumed by a variety of rider-facing software applications.”  Today, thousands of transit agencies across the globe use GTFS to relay up-to-date information to customers through apps like Google Maps, Moovit, TransitScreen, and Transit.
At its core, GTFS consists of two components. GTFS Schedule, the primary component, consists of a group of comma-delimited text files that together provide static, infrequently changed information on items like stop locations, routes, schedules, and fares. GTFS Realtime, an optional supplement, describes dynamic information like vehicle locations, delays and arrival times, and station closures. 
Today, GTFS has a strong community supporting its continued development, centered on MobilityData, a non-profit organization governed by public- and private-sector members in the transportation field. MobilityData has a resource center for learning more about and implementing GTFS solutions.
Below are some other helpful resources to learn more about GTFS:
Because GTFS is such a widely used tool, there are many resources are available that help transit agency staff to develop their own GTFS feeds intuitively and at a low cost. These tools include:
Beyond GTFS Realtime, there are many existing and proposed extensions to GTFS itself. These extensions are often focused on providing information on more specific aspects of transportation services, such as specialized transportation through GTFS-Eligibilities and GTFS-Capabilities, occupancy and crowding in vehicles through GTFS-RT-OccupancyStatus, or fare and payments through GTFS-FareProducts. MobilityData provides an overview of existing and proposed extensions on their site.
The General Transit Feed Specification was originally designed to provide data on fixed-route public transit; because of this, developers are working on making an extension for flexible, demand-responsive vehicles, appropriately called GTFS-Flex. Specifically, GTFS-Flex, while still under development, describes “on-demand flexible trips and booking rules for transit services which permit actions to suit the particular needs of individual riders, such as: dial-a-ride service, route deviation service, point-to-zone service, and point deviation or checkpoint service.”  It has been most useful in rural and hard-to-reach areas to help coordinate services across transit agency services areas and alternative transportation modes, like wheelchair-accessible vehicles (WAVs).
An example of where GTFS-Flex has been used successfully is with the Vermont Agency of Transportation (VTrans). After receiving a grant from the Federal Transit Administration, VTrans partnered with Trillium and Cambridge Systematics to launch “Go! Vermont” in Spring 2018. “Go! Vermont” is a statewide trip-planning website where users can get up-to-date information on options like carpools, hotel shuttles, ride-hail stops, and wheelchair accessible vehicles (WAVs).
Below are some other helpful resources to learn more about GTFS-Flex:
*Note: Per a recent decision in the working group for GOFS, GTFS-Flex and GOFS will consolidate into a single extension for GTFS.
General Bikeshare Feed Specification (GBFS)
The General Bikeshare Feed Specification (GBFS) is the most established transportation data specification for micromobility services. As reported by the North American Bikeshare Association (NABSA), “[o]ver 520 bikeshare and scooter systems worldwide have adopted the GBFS open data standard since its release in November 2015.” 
The General Bikeshare Feed Specification was founded in 2014 by Mitch Vars of Nice Ride Minnesota, and gained the endorsement of NABSA the following year. [16, 17] It is important to note that GBFS data only includes information on the availability of micromobility vehicles or docks, and not routes, users, or locations during trips. This is intended to protect the privacy of vehicle users, such as their location when borrowing vehicles or their trip history.  Because micromobility vehicles are used by individuals, GBFS has to account for the privacy of individuals in its design, unlike GTFS.
Like GTFS, GBFS has assumed the identity of a transportation data standard and has a strong governance structure. Today, GBFS is also stewarded by MobilityData, in partnership with NABSA. Below are helpful resources for those interested in GBFS and the community that surrounds it:
GTFS-OnDemand is a discovery and transactional data specification under development and is intended for providers in the on-demand transportation industry. Currently, GTFS-OnDemand is in the working group/development phase hosted by MobilityData, with the hopes that it could supplement other standards like GBFS and GTFS. It expands on real time information, transactional data, and functionalities specific to taxicabs, ridehails, and other on-demand services. GTFS-OnDemand is built on top of GTFS-Flex through the GOFS project . Information and resources about GTFS-OnDemand are limited due at this early phase.
*Note: Per a recent decision in the working group for GOFS, GTFS-Flex and GOFS will consolidate into a single extension for GTFS.
Mobility Data Specification (MDS)
Like GBFS, the Mobility Data Specification (MDS) is also intended for use by micromobility providers but is intended to inform policymakers, planners, micromobility providers, and regulators. More specifically, MDS is a two-way conduit of information which includes information from both operator and jurisdiction and that it trades individual vehicles, whereas GBFS helps customers get information on vehicles that are only available for rent. MDS was proposed originally by the Los Angeles Department of Transportation and tested for the first time in 2018.  MDS is currently governed by the Open Mobility Foundation. Micromobility providers and regulators can use MDS to provide and obtain information on issues like ensuring compliance with device caps and seeing what vehicles are in operation. 
Helpful resources on MDS:
Transactional Data Specification (TDS)
The Transactional Data Specification (TDS) sets out to address the transactional details needed to schedule a trip for demand-responsive transportation services like paratransit, microtransit, and ridesharing. TDS complements discovery specification tools by providing information needed for booking and paying for demand-response transportation services, like origin, destination, and trip fare.  TDS is being tested with a limited number of pilot projects in the US.
There is already precedent for how to implement a broadly adopted Transactional Data Specification. In Europe, FlexDanmark, a Danish transportation software company, uses a TDS-like standard known as SUTI (Standardiserat Utbyte av Trafik Information aka the Scandianavian data standard) to create a seamless flexible transit ecosystem across Denmark. Developed in Sweden, SUTI’s formula calls for the collection of “exchangeable data, including recurring trips, individual trip requests made in advance, and real-time trips” (p.19).  Today, FlexDanmark uses SUTI to help operate demand response transit across Denmark in partnership with regional public transportation authorities.
A more widely-adopted TDS could help shared-mobility providers and transit agencies across the United States and elsewhere more easily share trip information and create a more equitable system that serves at-need populations.
While there is no central resource hub for TDS at this time, below are some resources about its place in the Mobility-as-a-Service (MaaS) world:
Compared to the other data specifications featured in this case study, CurbLR is unique in that it outlines how information on curb space and curb regulations should be made available, as opposed to information on networks for transit and shared-mobility services. CurbLR is highly relevant because curb management plays an important role for stakeholders, such as micromobility operators, parking technology companies, ridehailing programs, and municipal agencies. Currently, CurbLR is hosted by SharedStreets and is not yet widely endorsed or adopted as a standard in the transportation planning industry. One example of CurbLR usage is for a Philadelphia pilot that occurred in 2020.  CurbLR is primarily intended for use by city agencies and regulators, like MDS, and is composed of GeoJSON files.
Compiled below are some resources for those seeking to learn more about CurbLR:
Curb Data Specification (CDS)
An increasing demand for sharing information on curb regulations has also resulted in the creation of the Curb Data Specification (CDS). The Open Mobility Foundation first announced the release of the initial candidate for CDS in 2022, which is meant to be a communication tool between municipal agencies and mobility providers like taxi and delivery companies. A CDS feed is composed of three application programming interfaces (APIs): a Curbs API, an Events API, and a Metrics API. 
Existing resources on CDS include:
Operational Data Standard (ODS)
The Operational Data Standard is designed to assist transit providers with conveying real-time information like deadheads, personnel schedules, and service disruptions. The California Integrated Travel Project (Cal-ITP), a division of the California Department of Transportation, serves as the steward for this new specification, with a working group of about 20 transit agencies and 20 transportation technology companies.  An ODS feed consists of five comma-delimited text files. 
To learn more about Operational Data Standard, visit these resources:
GTFS-Capabilities and GTFS-Eligibilities
GTFS-Capabilities and GTFS-Eligibilities are planned extensions geared toward enhancing specialized transportation services like paratransit. Both of these extensions go in hand with one another. The Capabilities extension is geared toward describing the dimensions of the human service transportation provider, such as operating times, seats available, or vehicles. On the other hand, GTFS-Eligibilities describes the eligibility requirements of an individual who can use a specialized transportation service, such as age or income status. The Public Transportation Division at the Oregon Department of Transportation operates as the steward of these upcoming extensions at this time. These extensions can supplement other specifications oriented toward paratransit and specialized transportation services, like GTFS-Flex and TDS.
To learn more about these GTFS extensions, visit:
Other specifications under development
Other specifications and tools do exist on different scales in the transportation industry, such as TNExT for transit providers in Oregon, NeTEx for transit providers in Europe, the Bus Open Data Service (BODS) in England, the General Travel Network Specification for traffic modeling, and the Managed and Tolled Lanes Feed Specification for traffic toll networks. Many of these specifications, while particular to geographies, transportation modes, or industries, can play a valuable role in either supplementing or informing the development of other specifications. For example, SUTI in Europe is informing the development of TDS and TNExT provides data for all transit agencies in Oregon through a central API.
This paper provides an overview of the data specifications and standards that are believed to be the most valuable in the transit and shared-mobility industries. Many of the specifications listed above shape the public’s relationship with transit and shared mobility. Because of GBFS and GTFS, people across the world can readily access information about their transportation options in seconds. Moreover, they have given developers the opportunity to experiment with creative ways to provide new types of information to users of transit and shared mobility, which can promote equity, accessibility, and safety. In this regard, specifications are laying an important foundation for Mobility-as-a-Service (MaaS).
Challenges exist, however, in that specifications for demand-responsive transportation, like TDS, GOFS, and GTFS-Flex, have not been widely accepted by the industry. In addition, learning and technical barriers often prevent the development of feeds depending on the resources, staffing, and institutional knowledge within a transit agency or organization. To address this challenge, states like California compel transit agencies to develop GTFS feeds through offering Minimum GTFS Guidelines, developed by California Integrated Travel Project (CAL-ITP). 
Some mobility providers and transportation network companies have created “walled gardens,” preventing transit agencies and the broader public from accessing their data. This is a widespread obstacle to fully integrating services so they serve the most public good. At this time, some of these proprietary technology platforms are working to figure out how to share or adapt their information. If more widely utilized, TDS, GOFS, or GTFS-Flex have the potential to break down these walled gardens and promote a more seamless transportation experience to users by fostering communication across platforms. This could be a significant breakthrough— especially for marginalized communities, people with disabilities, and older adults.
Broadly implemented data specifications and standards are fundamental in enabling and enhancing the MaaS experience. From creating new specifications to amending existing to further serve changing needs, these tools are vital in creating integrated, accessible, equitable and sustainable transportation networks.
Last updated on November 10, 2022