The Role of Data Specifications in Creating an Interoperable Transportation System - Mobility Learning Center (2024)

Questions and Answers

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 beconveyed between parties. For example, theGeneral 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. [1]

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) [2]

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”. [3] 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 some 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.

Table: Important Transportation Data Specifications

*Note: GTFS–OnDemand isbuilt on top of GTFS-Flex through theGOFS (General On-Demand Feed Specification) project.

Overview of Specifications

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. [11] 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.” [12] 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. [13]

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:

1. GTFS.org (maintained by MobilityData)
2. MobilityData GTFS Resource Center
3. Google’s GitHub repository for GTFS
4. GTFS Slack Channel

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:

1. National RTAP’s GTFS Builder
2. AddTransit’s GTFS Editor and GTFS Builder
3. TransLoc Architect
4. Moovit Transit Data Manager
5. Trillium GTFS Manager
6. World Bank Group Online Self-Paced Course on GTFS

GTFS Extensions

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.

GTFS-Flex

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.” [14] 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:

1. GitHub repository for GTFS-Flex
2. MobilityData Guide on GTFS-Flex
3. Trillium and the National Center for Applied Transit Technology (N-CATT): “GTFS Flex – What Is It and How Is It Used?”

*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.” [15]

The General Bikeshare Feed Specification was founded in 2014 by Mitch Vars of Nice Ride Minnesota, and gained the endorsem*nt 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. [18] 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:

1. MobilityData GBFS Resource Center
2. NABSA: “GBFS & Open Data”
3. GitHub repository for GBFS
4. GBFS Slack Channel

GTFS-OnDemand

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 [19]. 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. [20] 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. [21]

Helpful resources on MDS:

1. Open Mobility Foundation’s GitHub repository for MDS
2. Shared-Use Mobility Center: “Mobility Data Specification: A Data Standard for Shared Mobility Providers, Los Angeles, California, 2018”

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. [22] 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). [23] 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:

• Jana Lynott and Sharon Feigon: “The Transactional Data Specification: A Building Block for Equitable Mobility-as-a-Service”
• Jana Lynott: “Modernizing Demand-Responsive Transportation for the Age of New Mobility”
• Roger Teal et al: “Development of Transactional Data Specifications for Demand-Responsive Transportation”
• AARP: FlexDanmark Video Series

CurbLR

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. [24] 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:

• CurbLR.org
• SharedStreets: “CurbLR”
• GitHub repository for CurbLR
• SharedStreets: “Towards a Data Standard for Curb Regulations”

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. [25]

Existing resources on CDS include:

• Open Mobility Foundation: “About CDS”
• GitHub repository for CDS

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. [26] An ODS feed consists of five comma-delimited text files. [27]

To learn more about Operational Data Standard, visit these resources:

• Operational Data Standard website
• GitHub repository for ODS

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:

• GTFSpecs.org: “GTFS-capabilities”
• GTFSpecs.org: “GTFS-eligibilities”

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.

Conclusion

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). [28]

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

References

1. Jana Lynott, AARP: “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.
2. Roger Teal et al, Transportation Research Board: “TCRP Research Report 210: Development of Transactional Data Specifications for Demand-Responsive Transportation”, published 2020. https://www.nap.edu/read/25800/chapter/1.
3. Gartner: “Information Technology Glossary”. https://www.gartner.com/en/information-technology/glossary/open-architecture. Accessed April 28, 2021.
4. MobilityData: “GTFS Resource Center”. https://gtfs.mobilitydata.org/about. Accessed April 28, 2021.
5. OpenMobilityData: “About OpenMobilityData”. http://transitfeeds.com/about. Accessed May 6, 2021.
6. North American Bikeshare Association (NABSA): “About GBFS”. https://nabsa.net/resources/gbfs/. Accessed April 28, 2021.
7. Open Mobility Foundation: “Who is Using MDS?”. https://www.openmobilityfoundation.org/mds-users/. Accessed April 28, 2021.
8. Open Mobility Foundation: “CDS Users: Companies and Cities Using the Curb Data Specification”. https://www.openmobilityfoundation.org/cds-users/. Accessed November 10, 2022.
9. California Integrated Travel Project: “Transit Operational Data Standard: Working Group”. https://docs.calitp.org/operational-data-standard/about/working-group/. Accessed November 10, 2022.
10. GTFSpecs.org: “GTFS-eligibilities and GTFS-capabilities”, published August 25, 2021. http://www.gtfspecs.org/gtfs-eligibilities-and-gtfs-capabilities/.
11. Bibiana McHugh, Beyond Transparency: “Chapter 10: Pioneering Open Data Standards, The GTFS Story”, published 2013. https://beyondtransparency.org/chapters/part-2/pioneering-open-data-standards-the-gtfs-story/.
12. MobilityData: “GTFS Resource Center”. https://gtfs.mobilitydata.org/about. Accessed April 28, 2021.
13. MobilityData: “GTFS Resource Center”. https://gtfs.mobilitydata.org/home. Accessed April 28, 2021.
14. MobilityData: “GTFS-Flex v2”. https://portal.productboard.com/y3dqmkhjlmyst65bap8sx9kd/c/33-gtfs-flex-v2. Accessed April 28, 2021.
15. NABSA: “About GBFS”. https://nabsa.net/resources/gbfs/. Accessed April 28, 2021.
16. NABSA: “General Bikeshare Feed Specification”. https://github.com/NABSA/gbfs. Accessed April 28, 2021.
17. NABSA: “About GBFS”. https://nabsa.net/resources/gbfs/. Accessed April 28, 2021.
18. NABSA: “Data Good Practices for Municipalities: Understanding the General Bikeshare Feed Specification (GBFS)”, published January 2021. https://nabsa.net/wp-content/uploads/2021/01/FINAL-Data-Good-Practices-for-Municipalities_-Understanding-the-General-Bikeshare-Feed-Specification-GBFS-1.pdf.
19. MobilityData: “Why MobilityData is Standardizing On-Demand Transportation with the GOFS Project”, published April 23, 2021. https://mobilitydata.org/why-on-demand-transportation-needs-to-be-standardized/.
20. Madeline Kernan, Ride Report: “Introduction to Mobility Data Specification”, published May 18, 2020. https://www.ridereport.com/blog/introduction-mobility-data-specification-mds.
21. Open Mobility Foundation: “Understanding the Relationship between GBFS and MDS”. https://github.com/openmobilityfoundation/governance/blob/main/technical/GBFS_and_MDS.md. Accessed April 28, 2021.
22. Roger Teal et al, Transportation Research Board: “TCRP Research Report 210: Development of Transactional Data Specifications for Demand-Responsive Transportation”, published 2020. https://www.nap.edu/read/25800/chapter/1.
23. Jana Lynott, AARP: “Modernizing Demand-Responsive Transportation for the Age of New Mobility”, published December 2020. https://www.aarp.org/content/dam/aarp/ppi/2020/12/modernizing-demand-responsive-transportation.doi.10.26419-2Fppi.00121.001.pdf.
24. Ross Bernet and Simon Kassel, Azavea: “Maintaining Data on the Curb with CurbLR: A New Open Standard”, published July 7, 2020. https://www.azavea.com/blog/2020/07/07/maintaining-data-on-the-curb-with-curblr-a-new-open-standard/.
25. Shared-Use Mobility Center: “Open Mobility Foundation Releases Candidate for New Curb Data Specification, 2022”, published February 14, 2022. https://learn.sharedusemobilitycenter.org/overview/open-mobility-foundation-releases-candidate-for-new-curb-data-specification-2022/.
26. California Integrated Travel Project: “Transit Operational Data Standard: Working Group”. https://docs.calitp.org/operational-data-standard/about/working-group/. Accessed November 10, 2022.
27. California Integrated Travel Project: “Transit Operational Data Standard: Reference”. https://docs.calitp.org/operational-data-standard/spec/. Accessed November 10, 2022.
28. California Integrated Travel Project: “A Modern and Consistent Transportation Experience throughout California”. https://www.calitp.org/. Accessed April 28, 2021.

Tags