1. Home
  2. Cal-ITP
  3. California Transit Data Guidelines Development Process

California Transit Data Guidelines Development Process

The California Transit Data Guidelines were developed by the California Integrated Travel Project (Cal-ITP) team at Caltrans. Cal-ITP published Version 2.0 of the California Transit Guidelines (formerly the California Minimum GTFS Guidelines) in September 2021 as a continued attempt to put down in writing an achievable, albeit ambitious, target for transit data quality completeness and accuracy that transit customers and providers deserved. Two years later, it is clear that while a steady definition of where we should strive to be (as represented by the Guidelines) is still warranted and needed, a more readily achievable threshold is also needed in order to meet some transit providers where they currently are. 

The draft candidate for Version 3.0 went out for comment in September 2022. After approximately a month and a half of review, Cal-ITP reviewed all comments and created a document summarizing what we heard and how we responded. 

The Guidelines will continue to be updated once a year, at which time Caltrans will evaluate potential changes based on feedback, experience, and additional opportunities consistent with global data standards and/or technology. Please send Guidelines comments with suggested edits to hello@calitp.org. Caltrans may update or simplify the wording of the Guidelines on a more frequent basis for clarity, which would result in a minor update to the version number (e.g., from 3.0 to 3.1).

Referenced documents

The outcomes above are derived from the following resources:

Future GTFS extensions

Caltrans anticipates adding the GTFS extensions listed in this section to the Guidelines once they are adopted in the official GTFS definition. Caltrans encourages transit providers to actively participate in the discussion and development of these proposals by:

  • Commenting on the draft documents themselves.

  • Participating in MobilityData member meetings (base membership is free for public agencies).

  • Discussing issues and proposed incremental changes to the specifications in the GTFS specification repository.

  • Emailing hello@calitp.org to express your priorities so that we can help you navigate the process, advocate on your behalf, and/or evaluate additional information-sharing mechanisms.

Note: All items in this section are not current requirements. This section is purely informational and included so transit providers can get a sense of what is to come regarding GTFS.

GTFS-Fares Additions

While the core components of GTFS-Fares 2.0 have been fully incorporated into GTFS, there are several outstanding items in the full proposal that are on track to be adopted at a later date:

  • Fare capping (the concept of allowing riders to pay fares as they go until they hit a maximum, such as the equivalent of a daily, weekly, or monthly bulk-ride pass)

  • Acceptance of open-loop fare payment (whether a transit provider accepts riders’ contactless debit/credit cards and mobile wallets for tapped-to-pay fares)

See also: How can I create Fares v2 data?

GTFS-Pathways Additions

While the core components of GTFS-Pathways have been fully incorporated into GTFS, there are several outstanding items in the full GTFS-Pathways proposal that are on track to be adopted at a later date and that are critical to creating comprehensive accessibility to transit route planning and wayfinding:

  • Additional fields in pathways.txt, such as text-to-speech instructions, wheelchair assistance information, equipment-failure reporting, tactile strips, etc.

  • GTFS-Pathways Evolutions, which indicates planned or scheduled entrance or exit closures, elevator outages, escalator outages, etc. 

  • GTFS-StationUpdate, the real-time Pathways component that encodes real-time information and alerts about outages to pathways such as elevators and escalators.

See also: How do I create Pathways data?

GTFS-Text-to-Speech Additions

The GTFS-Text-To-Speech specification extension has been adopted for stop_name, and proposals for other fields are awaiting adoption. Those other fields include:

  • Agency name

  • Route name (short name and long name)

  • Trip name

  • Headsign (trip and stop)

Shared Identifiers

When one transit provider overlaps with another—for example, when multiple transit agencies serve the same train or bus station, or when systems offer interagency fare discounts—it would be helpful for the providers to describe that relationship.

MobilityData is developing an approach to create a reference for identifiers. These stable identifiers will serve as aliases and not replace any local transit provider identifiers (such as stop or route IDs). 

GTFS-Flex

GTFS-Flex describes “flexible” or “demand-responsive” transit, meaning any transit service where riders do not get on or off at fixed stops along a fixed route, such as:

  • Dial-a-ride/paratransit services 

  • Transit services where a vehicle can deviate from a fixed route to pick up or drop off riders

  • Transit services where riders can board or alight anywhere within a zone

Transit providers should begin including GTFS-Flex services as part of their GTFS feeds in order to support inclusion in trip-planning applications.

See also: How can I create GTFS-Flex data?

GTFS-Vehicles

GTFS-Vehicles encodes transit vehicle characteristics, such as seating capacity, bike capacity, and various accessibility-related attributes. GTFS-Vehicles, when adopted, will be part of the Guidelines for transit providers with fleets that are not able to represent their accessibility via wheelchair or mobility device at the trip or stop level. In addition, the extension will allow transit providers to describe vehicle propulsion type (diesel, electric, etc.), which will enable statewide aggregation and reporting.