Jana Lynott, AICP
Independent Transportation Consultant ROAM 2025
Connecting Community Transportation through Digital Technology Solutions
Data Standards Define:
Data Standards Define
Interoperability Using Proprietary APIs: The Expensive Approach
With proprietary APIs, each provider needs to
program its software to be compatible with four different message formats and maintain its own API.
Whenever a software update is made, every provider needs to update its software to accommodate it.
Each plug in the network costs thousands of dollars to develop and maintain, making interoperability with proprietary APIs an expensive proposition.
KEY
Provider Software
Provider Software
Source: AARP Public Policy Institute
A
B
C
D
E
Interoperability Using the TDS: The Cost-effective Approach
With the TDS, an open, universal API, providers need only program their software to exchange data using one set of message formats.
If software updates are made compatible with the TDS, interoperability with all providers is maintained. Those other providers need not take any action.
KEY
Provider Software
Open API
Source: AARP Public Policy Institute
A
B
C
D
E
Open and Universal Data Standards
Eligibilities
Capabilities
OnDemand
GTFS
Discovery Data
Flex
transactional data specifications
C
D
Transactional Data
A
E B
King County Mobility Coalition, Seattle, Washington
transportation services to meet the specific needs of people who are transportation disadvantaged
(urban, suburban)
including Washington DOT, human service transportation providers, community members, and other state and local government agencies
Source: Hopelink/King County Mobility Coalition
The Two Extensions, Contrasted
Eligibilities extension
Describes constraints to access for a given service.
Focused on a narrowing of service from the general public standard
Needs to handle service-based or jurisdictional rules and memberships
Capabilities extension
Describes specifically what a service
can do to respond to rider needs.
Focused on an expansion of service
beyond those provided to ambulatory riders
Needs to describe spatial, mechanical, or human resources
Courtesy: Full Path Transit Technology
Transactional Data Spec for DRT
A common data format that allows trip data to be shared electronically
The TDS Opens a New World of Possibility
Where there is a capacity constraint of one provider, another provider can step in and offer a seat.
Fewer empty seats and lower cost per passenger
Financial savings arising from greater efficiency and productivity
Less staff time dedicated to manually coordinating and scheduling trips among different providers
Accurate billing-related data for trips
Better service for the customer, such as same day rides and more reliable and punctual transportation
Photo credit: Via Mobility Services
Community Transportation: Lessons Learned from Transactional Data Specification Demonstration Projects
North Front Range Metropolitan Planning Organization (RideNoCo)
Northern Colorado (rural, suburban and small urban)
customers, particularly older adults
Source: RideNoCo demonstration project. Berthoud Rural Alternative for Transportation (RAFT)
“…the transactional data specification has the potential to not only transform the way transit agencies operate but also the way in which agencies work together as partners to deliver on a shared mission”
-Cory Schmitt, Mobility Director at North Front Range Metropolitan Planning Organization
Minnesota Department of Transportation Regional Trip Planning and Scheduling Platform, Southern and Western Minnesota
communication between trip planning applications and the scheduling software of transit agencies.
Fillmore, Houston, and Winona counties (urban, suburban, rural)
transportation riders and ADA paratransit customers
Source: MnDOT. Note: images are informational. Actual TDS module still under design.
NEORide EZConnect, Northeast and Southwest Ohio
and confirm booked and completed trips by building a TDS-compliant translator (Middleware), resulting in easier client management and booking. The translator will make it possible for data to be sent to and retrieved from the Via and Trapeze platforms with no required coding changes to those platforms, and will ensure that all relevant data is communicated.
Metropolitan Transportation Commission, Bay Area, California
communication between two unique paratransit scheduling software.
Clara counties (urban and suburban)
(BAPAC) (a regional coordination forum for all paratransit service providers)
Source: Metropolitan Transportation Commission
Other TDS Opportunities
Health Care Coordination
NEMT
Source: Capacity Builders, Farmington, NM Photo Resource Gallery | NADTC
Mobility Management
Takeaways from the Demonstration Projects
Takeaways from the Demonstration Projects
Source: Tri-County Action Program Waite Park, MN, Photo Resource Gallery | NADTC
Economy of Scale: 30% savings for each doubling of trips
“It’s not about technology, but cooperation and organization!”
-Jens Peter Langberg: Director of Flextrafik at Movia, 2019
“There is a graveyard of technology-first projects”
- Kevin Chambers, Full Path Transit Technology
A Roadmap for Implementation
Riders are at the center of this process, and should be involved early and throughout.
These steps are not exhaustive, but rather intend to offer a framework for communities to explore the TDS and other developing open-data solutions in their own communities.
Community Transportation: Lessons Learned from Transactional Data Specification Demonstration Projects
Jana Lynott, AICP
Independent Transportation Consultant janalynott@gmail.com
Ongoing Standards Efforts in the Community Transportation Space
Demand-Responsive Transportation Data Specifications Working Group
Convened by the Shared Use Mobility Center Contact: Janalynott@gmail.com
Multimodal and Accessible Travel (MAT) Standards Coordination Committee (SCC) Reservations, Scheduling and Dispatching (RSD) Subcommittee
USDOT Effort
For more information: GitHub - ite-org/MAT-VRU: Multimodal Accessible Transportation (MAT) and Vulnerable Road User (VRU) Standards Support Project