Technology in the Oregon Public Transportation Plan

What are the functions of transit technology on a statewide basis? Who makes the decisions and implements the system?

Below is the text of a memo, mostly in its original form, provided to the Oregon Department of Transportation with recommendations and input for a statewide technology planning process. I prepared the memo in just a few hours, so it doesn’t pretend to be exhaustive but does provide a useful outline from which to consider transit technologies on a regional (including statewide) scale. The memo focuses on Oregon, but the topics apply in other states and regions.

One question on which the memo does not make strong recommendations is how forceful or involved regional government should be in implementing transit technologies that span multiple transit systems:

  • Centralization — one extreme is the top-down approach where technology is purchased, developed, and managed centrally. This may ensure consistency across the region.
  • 100% locally-focused — another extreme is a laissez-faire approach to allow transit agencies to make decisions according to local needs. This allows experimentation and locally-tailored approaches.
  • Shared decision-making — somewhere in the center is an approach where a regional government provides guidelines, resources, and recommendations to help transit agencies make technology decisions and maintain coordination with the region.

The ideal approach along this continuum might be different for each function.

To: ODOT, Oregon Public Transportation Plan consultants
From: Aaron Antrim, Trillium
Date: 15-Sep-2016
Input for OPTP Technology White Paper


This memo describes high-level knowledge and awareness of information technology projects relevant to transit in Oregon on the statewide level. This is described from the perspective of Trillium Solutions, Inc.’s team based on experience working with transit agencies, ODOT, and some other stakeholders. Relevant out-of-state projects are included based on off-hand knowledge; Trillium has worked or is otherwise associated with some, but not all, of these mentioned projects. This is “medium-formal” input and contains some hypothesis, conjecture, editorial, etc. This is submitted as input for the Oregon Statewide Public Transportation Plan process.

The following areas/technology functions are discussed:

  1. Statewide trip planning
  2. Seamless fare systems
  3. Statewide transit network planning
  4. Collaboration & knowledge sharing across transit agencies
  5. Transit agency websites
  6. Issue & feedback collection
  7. Road & construction information
  8. Ride-matching & rideshare

For each function, this memo identifies some of the current activities and gaps/opportunities. Improvement in the above functions will improve mobility options, operational efficiency, or traveler experiences. This response focuses on the above information technology functions because Trillium’s team believes they offer significant benefits and high-value for mobility in Oregon. Nearly all recommendations or discussion of example/demonstration projects are follow the collaborative, open data, or open source approaches that have emerged recently in public transportation, and demonstrated leveraged benefits.

This draft diagram shows how various parts of information systems fit together in public transportation operations and customer information.

Response / discussion

  1. Statewide trip planning (passenger-facing tools)
    1. Traveler Need: Travelers need easy and familiar systems for getting directions. However, conventional transit timetables and maps confound many unfamiliar transit riders: they involve a multi-step process to find routes, transfer locations, and times. In a National Center for Transit Research study, almost half of participants were unable to correctly identify bus times using the tabular schedules.[1]
      1. Travel planning habits: Over 80% of US adults have used the internet to get maps or directions. On any given day in 2011, about 1 in 6 got directions online. Unlike some uses of the internet, maps and directions are sought by all users across all demographics. While more common among younger users, more than 75% of users 65 and up have sought directions online.
      2. Online access: As of 2012, 74.8% of households in the US had a computer with internet access, and 45.3% of all adults 25 or older were using smartphones. Access is also very diverse. More than 50% of adults 65 and up use the internet at home, and smartphone use is higher among all racial minorities than it is among whites.[2]
    2. Technical solution background: Google Maps and other online mapping and navigation tools simplifies transit schedule information, and immediately answers a prospective rider’s primary question: “How do I get from where I am (or will be) to where I’m going?”.
    3. Data underpinnings
      1. Schedule and geographic data (fixed-route transit): Transit schedule and geographic data is provided to Google Maps using the General Transit Feed Specification (GTFS) format, now a de facto standard for transit data. GTFS describes transit schedules, stops, route alignments, holidays, and fares for transit scheduled fixed-route public transportation services.
      2. Real-time information: GTFS also includes a companion data specification, GTFS-realtime. GTFS-realtime data streams may consist of up to three components, service advisories, trip updates (arrival predictions and re-routes), and vehicle positions.
      3. Other modes: Data for many other modes of transportation such as bikeshare and carshare is available. However, some other transportation modes do not have associated open datasets. See this “Data formats roundup” blog post for a full inventory.
    4. State activities:
      1. Statewide GTFS: To address provide travelers with information, the Oregon Department of Transportation (ODOT) has implemented transit directions in Google Maps and other 3rd party mapping applications such as Apple Maps and Microsoft’s Bing Maps for ~99%+ of the statewide transit network, a project begun in 2009. About 10 transit agencies publish GTFS data without state assistance, and about 50 other transit agencies publish data with state assistance.
        1. GTFS began in Oregon through a collaboration between TriMet and Google
        2. Oregon, with leadership from ODOT, was the first state with a successful statewide GTFS project
      2. Data specifications research: ODOT is researching and prototyping an emerging GTFS-flex format[3], which would describe demand responsive transit (DRT).
      3. Real-time: The State has included publishing GTFS-realtime service advisories in the scope of the GTFS work. This activity has not begun in earnest yet. It will require additional participation from transit agencies.
    5. Additional needs:
      1. Real-time information: While 57 transit agencies openly publish schedule data in the standard GTFS format, only two agencies, TriMet & Rogue Valley Transportation District (RVTD), currently publish GTFS-realtime data. Arrival predictions, service advisories, vehicle positions, and short-term service modifications would need to be published in the GTFS-realtime format to be included in Google Maps and other applications. This would require additional hardware (onboard wirelessly-connected GPS) for some agencies, and software. Relevant example projects/resources:
        1. The open-source OneBusAway is implemented in several regions, including Seattle, New York and Atlanta
        2. Transitime is open-source software developed and hosted by Swiftly for generating arrival predictions: The software produces GTFS-realtime. (Source code on github.)
      2. Broadening multimodal options in trip planning: The multimodal transportation network is greater than the sum of its parts. Abundant mode options — including public transit, bikeshare, carshare, ride hailing (TNC), rideshare, and vanpool — complement each other to serve different travel needs efficiently. But a transportation network with so many dimensions and possible combinations is too complicated to understand without help from software. There is no truly comprehensive map or app for this emerging multi-modal transportation network yet, though many applications do show transit with a limited number of other modes. One of the barriers to comprehensive multimodal journey planners and apps is the lack of standardized formats for all transportation modes.
        1. Relevant potential project: TriMet has applied for funding from the FTA through the Mobility on Demand Sandbox Program to add features to display Shared Use Mobility (SUM) services such as bikeshare and transportation network company (TNC)/ride-hailing to OpenTripPlanner (OTP).
      3. Demand-responsive transit: There are many demand responsive transit services (DRT) which are difficult to identify and plan trips on. Many of these services are specialized human service transportation. Relevant example projects/resources:
        1. Jacksonville Transit Authority (JTA) has planned a project with University of South Florida to add features to display DRT services described in GTFS-flex to OpenTripPlanner (OTP), an open-source multimodal trip planner that is currently used in Portland and Salem.
        2. Vermont Agency of Transportation (VTrans) has applied for funding from the FTA through the Mobility on Demand Sandbox Program to add features to display DRT services described in GTFS-flex to OpenTripPlanner (OTP).
        3. Cambridge Systematics developed an open-source “1-Click” trip planner[4] that shows fixed-route and DRT services, and enables matching based on eligibility criteria. The software is implemented in the Atlanta region, Florida, California’s Inland Empire, and Pennsylvania.
  2. Seamless fare systems
    1. Need: The inconvenience of paying cash fares, understanding fare systems, or purchasing passes can be a barrier to utilizing transit.
    2. Opportunity: TriMet’s Hop Fastpass is designed to allow multiple service providers to participate. ODOT is working with TriMet to explore the practicality of extending seamless fares to surrounding transit agencies & perhaps statewide.
    3. Caution: Many regional transit fare systems (e.g. Bay Area’s Clipper) have proven very costly, difficult, and time-consuming to implement. Fare technology and practice appears to be changing very rapidly right now. There is risk of rapid obsolescence of costly systems.
  3. Statewide transit network planning
    1. ODOT and transit managers’ needs: Local transit managers & planners and ODOT planners need tools to understand traveler needs, opportunities, and the transit network on a broad scale. They also need tools to consider changes to the network.
    2. Current & planned state activities:
      1. Key transit hubs: The state has identified key transit hubs where many services come together as opportunities develop a more integrated transit network through better connection timings and additional connections.
      2. Transit Network Analysis Tool (TNC): The Transit Network Analysis Tool is an open source, web-based application created to improve the visualization and analysis of Oregon’s regional and statewide public transit networks. This tool is being developed through a partnership between the Rail and Public Transit Division and Oregon State University’s Department of Mechanical, Industrial, and Manufacturing Engineering. The project aims to make it easier for those involved in transit planning to make more informed decisions.[5] The software utilizes the same GTFS data used for trip planning to locate routes and stops.
      3. Remix: Remix is a web-based planning application created for public transit agencies with fixed-route service. This tool allows users to quickly draw bus routes on a map and get ideas about how much a new route might cost to operate and who it would serve. The Rail and Public Transit Division has made it possible for all Oregon transit agencies to use the pro version of Remix for free.[6]
      4. Research project: Statewide Data Standards to Support Current and Future Strategic Public Transit [7]: ODOT has commissioned a research project to be completed by Oregon State University. The conclusion of this research project will coincide with the conclusion of the OPTP. “The goal of this research project is to develop a public transit ridership data standard for all Oregon public transit agencies to follow for the purposes of improved data collection, storing, sharing, reporting, and analysis. These core functionalities of the standard will be supported with the development of open-source, web-based tools for use by transit agencies, ODOT, regional planners, modelers, and vendors.”
    3. Additional needs
      1. Holiday schedule coordination: The Northwest Transit Alliance has made progress toward coordinating holiday schedules. Features to automate this coordination might assist seamless connectivity across the state.
      2. Passive travel demand & behavior data collection: Mobile apps that travelers utilize to plan travel, look up real-time information, count calories, track physical activity, track environmental benefits and pay fares can collect travel information by mode for use by planners, transit agencies and transportation options programs. Notes below.
        1. Current state activities:
          • Trip planner queries are logged from many small transit agency websites before the query is passed to Google Maps, however this data has not been utilized for any purpose.
        2. Other technologies & examples:
          • OneBusAway includes features to track the number of times people look up information for individual bus stops.
          • The Swiftly mobile app anonymously collects usage data, which makes it possible to track planned trips and see what trips travelers ultimately completed, and the travel mode they selected.
          • OpenTripPlanner can log all queries and planned trips.
        3. Miscellaneous relevant projects
          1. The Open Transit Indicators project was developed by the World Bank, in partnership with the Chinese Academy of Transport Science and the Haiphong Department of Transportation (Vietnam). The application uses information about a city’s transit system, along with additional data about demographics, to calculate baseline indicators of transit service quality, such as average distance between transit stops and average service frequency. The service quality indicators can then be used to compare one city’s transit system to those of other cities, identify possibilities for service improvement, and evaluate the effect of hypothetical service changes.” (Azavea Journal, Derek Dohler in Vol. 10 Issue 1, March 2015). The software also includes features to prototype and consider future scenarios. The software loads GTFS data.
          2. Transitland is a directory of GTFS data feeds and API for interrogating transit service & infrastructure information. Transitland may support customer-facing systems like trip planning and maps and also planning functions. The project is in active development, led by Mapzen. For a full discussion of project goals and state, see this interview between Aaron Antrim and Drew Dara-Abrams.
  4. Collaboration & knowledge sharing across transit agencies
    1. Need: Transit agencies must fulfill many common functions — operations, planning, scheduling, customer information, human resources, information technology, customer service, various compliance functions, and etc. Much practice knowledge is transferable between services, but our industry could use more optimally-efficient systems to support knowledge sharing.
    2. Current activities:
      1. Important ODOT staff-supported coordination through Regional Transit Coordinators and ODOT HQ
      2. Use of national resources like Transit Cooperative Research Program (TCRP) reports, which are frequently lengthy and, because of the time for project selection and publishing process, lag behind the state of practice, especially for the faster-moving field of technology.
      3. Annual Oregon Public Transportation Conference
    3. Ideas for additional resources:
      1. Private email lists to support communication and collaboration between transit managers (these may already exist and I am unaware of them).
      2. TransitWiki is an online resource to facilitate knowledge sharing in transit running MediaWiki software (the same software as Wikipedia). Users with registered accounts can edit and create content. Created by UCLA and Caltrans, the project is the implementation of a recommendation in the California Statewide Transit Strategic Plan. The project is looking to develop broader participation, including by creating an advisory board which other State DOTs could participate in. As an example of TransitWiki’s potential, Sean Barbeau (University of South Florida) and Aaron Antrim (Trillium) added practical background and how-to on current technology topics; see: GTFS, and GTFS-consuming applications. If some ODOT knowledge dissemination was routed through TransitWiki, and consultants were encouraged or required to deliver research through TransitWiki, this would create a focal point for sharing practice knowledge.
      3. Custom search engine: California also created a custom search engine to search through staff reports and documents across transit agency websites in the state. See California Transit Agencies – Reports and Documents.
  5. Transit agency websites
    1. Need:
      1. Many transit service websites may not represent a rider-focused approach, and instead prioritize administrative information. Granted, this is an an editorial view of Trillium, an interested firm that builds transit websites.
      2. Transit agency websites, associated with the local transit brand and information/marketing efforts, may be useful as gateways through which people can discover options in a larger multimodal/statewide network (e.g. currently through the statewide transit data in Google Maps, and perhaps through other future trip planners).
      1. Resources: Creating accessible transit websites (focuses exclusively on accessibility)
  6. Issue & feedback collection
    1. Need: Transit agencies need to collect and respond to customer feedback and questions. They also need to receive, route, and respond to important compliance-related requests, such as ADA requests for reasonable modification or Title VI complaints. Because transportation is interjurisdictional, systems which can route requests across government organizations can be useful (for example, to refer a complaint about a bus stop facility to a public works department). Online systems can be used:
      1. route requests, including within and between organizations
      2. track customer requests, and make sure they are addressed
      3. maintain correspondence logs to identify recurring issues and support planning activities
    2. Resources & tools
      1. Open311 is an a suite of open-source software and API specifications for civic issue tracking. This is implemented in cities throughout the world. Of note, Open311 has been integrated into the OneBusAway transit application.
      2. TCRP Report 179 “Use of Web-Based Rider Feedback to Improve Public Transit Services” outlines web-based systems that can be used to manage communication with transit customers.
      3. Trillium blog post “Getting real about the utility of social media for public transit” inventories some communication tools (including social media and alternatives) for communication with transit customers.
  7. Road & construction information
    1. Need: Transit operations can benefit from advance knowledge of road closures and detours delivered by convenient tools.
    2. Current activities: ODOT is working to improve internal communication and awareness between highway and transit staff, including building awareness of ODOT GTFS based maps that identify transit stop and routes.
    3. Opportunity:
      1. Open511 is a data specification developed by partners including the SF Bay Area’s Metropolitan Transportation Commission (MTC). From the Open511 website: “The open data movement has demonstrated its value to society on many occasions, particularly with recent efforts to improve information about transit systems. Following the example of other formats like GTFS, Open511 proposes a specification for road incident, construction and much more that matches open data criteria. With Open511, public bodies and citizens can get the most out of your jurisdiction’s data by turning your road events into powerful and innovative software and analysis.”
  8. Ride-matching & rideshare
    1. Need: Ride-matching/carpool can supplement the transit network, offering ride options at times and locations when transit is unavailable or inefficient. However, many regions see low carpool utilization. There are numerous reasons for this. Lack of incentive (low fuel cost) is likely the most significant factor. Lack of convenient information tools is sometimes cited as another factor.
    2. Current state activities:
      1. Drive Less. Connect. is a statewide ride-matching program.
    3. Other ideas & example projects
      1. 3rd party ride-matching/carpool apps.
        1. Similar to how transit agencies have leveraged free 3rd party apps to provide information and support low-cost innovation, the SF Bay Area MTC has created a 3rd party app center that shows innovative ride-matching apps: The original Request for Partnerships suggested that the MTC might also create a Kayak-like site to see ride options across apps in a consolidated search interface. This would require a data specification
      2. Integration with multi-modal trip planning
        1., using OpenTripPlanner, aims to include carpool options alongside transit.
        2. RideAmigos brings carpool and transit together in one trip planning interface.

[1] University of South Florida,

[2] US Census,






Aaron is the founding principal of Trillium Solutions, Inc. He brings experience that includes 12 years of web-development with 8 years in public transportation, with knowledge of fixed-route transportation, paratransit, rural transportation, and active transportation modes. Aaron is a recognized expert in developing data standards, web-application design, digital communications, and online marketing strategy. He originally developed Trillium’s GTFS Manager, and has played a key role in the development of the GTFS data specification since 2007.