Technology Stacks

There are several distinct hardware and software products that a transit agency can incorporate into their planning and service delivery (see Technology Components for a list). These products can have dependencies and overlap, depending on vendor selection and configuration choices.

The technology stack diagrams below illustrate how a selection of transit agencies in California have chosen and arranged these products into their technology stack. Each diagram includes the following.

  • Functions
    • Each function is provided by a component, such as Annunciation, Trip Planning, or Scheduling.
    • Functions can be provided by a vendor or conducted within the agency (in-house).
    • Most agencies support a selection of functions, and some functions are quite rare.
  • Categories
    • Groups of functions with similar operations.
  • Connections
    • Data often flows from one function to another.
    • Some connections require manual intervention, while others are automatic (or "seamless").
  • Data specifications
    • When data is shared, it has to be formatted according to a known format so that the producer and consumer understand each other.
    • Data specifications can be either:
      • Open, meaning anyone can know and apply the format as a producer or consumer, or
      • Closed/proprietary, meaning that a vendor's data can only be understood by products authorized or created by that vendor.

Gold Country Stage

Based in Nevada City, California, Gold Country Stage has eight routes and serves over 200,000 trips in a typical year.

A relational diagram depicting the selection and arrangement of hardware and software to facilitate data and payments. Scheduling begins with in-house scheduling software and vendor-generated GTFS. The CAD/AVL system has two vendors: one produces mobile data terminals and vehicle locations in a non-standard real time format, the other produces vehicle locations and arrival predictions in the standard GTFS-RT format. Schedule data is manually entered into the in-house scheduling system, vendor-generated GTFS data, and vendor-produced Mobile Data Terminals. The CAD/AVL system does not produce real time service alerts. The offboard rider information receives real time information through two channels. The non-standard format, along with a vendor-provided web-trip planner, provides information on the agency website. The standard GTFS-RT is used by third party trip planning applications. The agency does not have automated alerts or offboard signage. For onboard rider information, one vendor provides the annunciators, headsigns, and interior signage. For payments, a vendor provides payment processing. Reporting is conducted in-house, to inform the National Transit Database. The agency does not use automated passenger counting or off-board fare technology.

Distinct features

  • The agency has two vendors providing vehicle locations. One, using a non-standard format, provides data for the agency's own web-based planning tools. The other, using standard GTFS-RT, provides data to third-party trip planners.
  • The agency creates its schedules manually, and keeps this data updated in three separate sources: its reference schedules, its GTFS-generator vendor, and one of its two CAD/AVL vendors.
  • Onboard rider information tools are not integrated with the CAD/AVL information.

Porterville Transit

With nine routes and over 600,000 annual trips, Porterville Transit serves a section of Tuolumne County in the western Central Valley.

A relational diagram depicting the selection and arrangement of hardware and software to facilitate data and payments. Scheduling is handled by a single vendor, which covers both scheduling and GTFS generation, and outputs standard GTFS static data. A single CAD/AVL vendor supports their mobile data terminals, vehicle locations, and arrival predictions. No real-time service alerts are produced. The CAD/AVL system outputs a non-standard, real-time format, which is used by a vendor-specific application on the agency’s website. Another vendor supplies off-board signage. Third-party apps consume the standard static data but not the non-standard real-time data. Onboard rider information is handled by a single vendor, which supports annunciators and interior signage, using the outputs from the CAD/AVL. Headsigns are not automated. A single vendor handles ticket vending machines and mobile ticketing, which are supported by a payment processor. Onboard vares are supported by two different vendors, one for fare cards and another for fare boxes. Fareboxes and the CAD/AVL are manually fed into in-house reporting, which informs the National Transit Database. The agency has automated passenger counting, but this does not connect to their reporting.

Distinct features

  • Real-time transit information is not available for third parties to consume. Riders only get this information through the agency's chosen vendor.
  • Scheduling and CAD/AVL functions are each handled entirely by a single vendor, with no vendor overlap.
  • Reporting requires manual integration with multiple sources, including the Automated Passenger Counting system.

Santa Rosa CityBus

Serving communities just north of San Francisco, the Santa Rosa CityBus has 15 routes and serves over two million trips in a typical year.

A relational diagram depicting the selection and arrangement of hardware and software to facilitate data and payments. Scheduling begins with a vendor tool for scheduling and another vendor tool for GTFS generation. This data is manually fed into the CAD/AVL system. The CAD/AVL is supported by a single vendor, which includes a mobile data terminal, vehicle locations, and arrival predictions. There are no real time service alerts. Offboard rider data is powered by three separate vendors: one for the agency website’s trip planner, another for automated alerts and real time information, and a third for physical offboard signage. The CAD/AVL system produces a JMS real time format, which powers both the agency’s real time alerts and the regional 511 agency’s standard GTFS-RT, which is used by third party applications. The CAD/AVL system also powers the onboard rider information, which is all managed by different vendors: annunciator, headsigns, and interior signage. Offboard fares are handled by a third party vendor who supports paper tickets but not mobile ticketing. These fares are handled by a vendor-led payment processor. Fares are collected on board with the help of two vendors, one for the fare card system and another for fareboxes. Onboard fares, along with a vendor-managed automated passenger counting system, inform an in-house reporting system. These reports can be manually submitted to the National Transit Database.

Distinct Features

  • As part of the San Francisco Bay Area, 511 SF Bay, an external system, consumes Santa Rosa's static GTFS and CAD/AVL outputs to create standard GTFS-RT.
  • Santa Rosa uses automated passenger counting, though data must be manually exported to be published to the National Transit Database.
  • One vendor supports all components of the CAD/AVL system.
  • Real time information viewed through the agency's website may be different than that seen in a third party application
  • The CAD/AVL does not consume static GTFS directly, so in order for data consumers to have matching trip IDs in their static and real time feeds, these must be retroactively matched downstream.

Golden Empire Transit District

Operating in the southern Central Valley, around Bakersfield, GET Bus has 16 routes and serves over five million trips in a typical year.

A relational diagram depicting the selection and arrangement of hardware and software to facilitate data and payments. Scheduling is performed by tools from two separate vendors, and information from the scheduling software must be manually loaded into the GTFS generator. The CAD/AVL system uses a single vendor for its mobile data terminal, vehicle locations, arrival predictions, and real-time service alerts. The CAD/AVL receives static GTFS automatically and informs several other systems automatically. The CAD/AVL outputs GTFS-RT for use by the agency’s own website trip planning tools and third party routing applications. Three vendors support offboard rider information: web trip planner, automated alerts, and real time offboard signage. Onboard rider information has a single vendor, receives GTFS-RT, and powers headsigns, annunciators, and interior signage. Passengers can use mobile ticketing, but not paper tickets, which are processed by merchant services and a farebox system. Passenger counting and the farebox automatically feed into a vendor-supplied reporting system, which can be manually submitted to the National Transit Database.

Distinct Features

  • As the largest agency in this selection, both in terms of routes and ridership, it is not surprising that GET would have technology to provide the greatest number of functionalities.
  • All off-board rider information uses both GTFS and GTFS-RT.