1. Home
  2. Cal-ITP
  3. California Transit Data Guidelines Frequently Asked Questions

California Transit Data Guidelines Frequently Asked Questions


What is GTFS?

The General Transit Feed Specification (GTFS) is the global standard for describing transit schedules and operations for use by trip-planning applications. GTFS is used by thousands of agencies worldwide and is by far the most common data standard produced by U.S. transit agencies.

First created in 2006 through a public-private partnership between TriMet—the public transit agency in Portland, Oregon—and Google, the continued development and refinement of the GTFS specification is carried out by a global community of public and private GTFS data producers and consumers. Officially recognized additions and modifications of the spec are reviewed according to the GTFS Extension Process and approval is facilitated by the independent nonprofit organization MobilityData.

GTFS.org is the central platform for the GTFS community to find documentation about the GTFS specification, best practices, resources, and further background information.

How do transit riders and the public "see" this GTFS data?

The most common ways for transit riders to see the data is via:

  • A consumer-facing application such as Google Maps, Apple Maps, or Transit App (through a web browser or phone interface)

  • Transit provider signage

  • Commercial displays (for example at coffee shops, offices, sports and events venues, and apartment buildings) 

 California’s raw GTFS data can be seen:

Why did Caltrans develop these Guidelines?

Caltrans developed the California Transit Data Guidelines to ensure that data for transit providers in California meets the needs of travelers, as well as those who plan, manage, and operate the transportation network, including fare payment and other services contracted by providers. The Guidelines provide an ideal state of data quality to ensure that the transit network is understandable and accessible for people with all levels of ability.

Read more on the Transit Data Guidelines Development Process Page.

Does my organization need to follow the Guidelines?

We recommend that transit providers follow these Guidelines in order to best serve the public by providing accurate, complete, and up-to-date transit information. Research shows that transit riders respond positively to high-quality transit information, both in terms of reducing perceived wait times and increasing ridership. See The Data Transit Riders Want, published by TransitCenter in 2018, for more information.

How do I know if my organization is compliant with these Guidelines?

Encourage the department or vendor providing your organization’s technical services to review the Data Process Checklist. If you need assistance in assessment or have any questions, please contact hello@calitp.org.

How can I comply with these Guidelines if I don't already? How can I get help implementing these?

There are a number of potential pathways toward meeting the Guidelines, depending on the current data pipeline. This can include:

  • Identifying funding for equipment

  • Adding these Guidelines in future vendor contracts and procurements

  • Collecting and maintaining additional data

  • Updating website language

See Tools and Resources for a list of specific offerings to help transit providers meet these Guidelines.

How do I prioritize which Guidelines to focus on?

The Guidelines describe the information that Transit Riders (and Providers) deserve and that is currently feasible within the GTFS specification. That said, providers should first focus on being Compliant for both GTFS Schedule Data and GTFS Realtime Data. Additionally, GTFS Schedule Data must be met first in order to provide any Realtime information to riders. Beyond the “Compliance” level, Guidelines can be prioritized based on provider appetite and resources.

What is a “stable URL”?

A stable (or “static”) URL (or “permalink”) is one that doesn’t change. This is especially important for GTFS Schedule data because it assures data consumers that they can reliably access the latest version of data at all times. When new GTFS data is posted in a different location, it’s not obvious that the data from the old location is now invalid, which can result in transit riders being given out-of-date information, or none at all.

The GTFS Dataset Publishing & General Practices provides guidance on the recommended practice of hosting GTFS data on a transit provider’s website. A consistent link to cloud storage or an FTP location would also satisfy these Guidelines. 

When possible:

  • The stable URL should use the transit provider’s domain rather than a vendor’s, which may change over time. Example: mytransitagency.gov/gtfs-current.zip

  • GTFS data representing future service or planned changes/augmentation to the GTFS data is reflected at another permalink to allow for back-and-forth troubleshooting ahead of time. Example: mytransitagency.gov/gtfs-future.zip

Providing a static URL for the most recent data does not prevent storage of historical GTFS data on websites at different addresses. For example:

  • mytransitagency.gov/gtfs/us-ca-mytransitagency_current.zip

  • mytransitagency.gov/gtfs/us-ca-mytransitagency_2022-01-05_thru_2022-01-31_zip

  • mytransitagency.gov/gtfs/us-ca-mytransitagency_2022-02-01_thru_2022-03-15.zip

Uploading a GTFS file to the Google Transit Partner portal does not satisfy the static URL Guideline, nor does hosting it on the transit provider website with a date or version in the file name or URL structure.

Can a local or regional government impose guidelines that are stricter than these Guidelines?

Yes. Caltrans welcomes the California transit community to provide more information than is specified in these Guidelines, as long as these additional or stricter requirements don’t conflict with or dilute these Guidelines. 

The Metropolitan Transportation Commission (MTC) in the Bay Area is one example of a regional agency that incorporates the state guidelines into their own data requirements used to make transit data consistent across the region. MTC maintains and publishes a regional transit data guidelines document to help Bay Area transit operators with providing the consistency of data expected.

How do I publish GTFS for both present and future service?

There are currently two generally acceptable methods to meet the requirement of describing planned service changes at least one week in advance of them happening:

  1. Publish two services in a single feed using service_ids Feature in the GTFS specification to distinguish them.

  2. Publish the “future” feed to a dedicated permalink; for example, Los Angeles Metro publishes their “future-service” feed to a different Git “branch” enabling a permalink download at https://gitlab.com/LACMTA/gtfs_bus/-/blob/future-service/gtfs_bus.zip

How do I publish my GTFS data to aggregators?

The Mobility Database and Transitland are the two largest and most stable feed repositories. Data consumers rely on these to find GTFS feeds for their applications, and being absent from these aggregators can preclude a transit provider from inclusion in maps and trip-planning applications. Transit providers and vendors can submit their feeds to these aggregators directly by following the instructions below:

How do I publish my GTFS data to trip-planning applications?

Once published, transit providers will want to get their GTFS data into popular trip-planning applications for the general public to discover and use. Each application has its own process, and key applications are listed below:

Contact the Cal-ITP Helpdesk if you need assistance getting your feed into trip planners.

How do I select an open data license?

Agency GTFS data should be explicitly offered under the latest version of the Open Data Commons Attributions (ODC-BY) or Creative Commons Attributions license (currently CC-BY 3.0), which is consistent with the license required by the National Transit Map. These licenses should be adopted as-is, without additional requirements that would add undue complexity down the line.

Other “attribution” licenses are often attractive and are also fine to use; however, “share-alike” type licenses limit the use of the data by some user applications and should be avoided. See Model Website Language for more information.

What are the GTFS and GTFS Realtime Best Practices?

The GTFS Best Practices and GTFS Realtime Best Practices are community-driven sets of requirements above and beyond the base GTFS specification to facilitate a more seamless customer experience. They are managed by MobilityData.

What does it mean to have my data validated?

Data validators can validate if the form and function of the dataset meet the data specification and fall within reasonable bounds (e.g., that a transit trip that arrives at a certain stop at “12:01:10” arrives at subsequent stops after “12:01:10” or it will raise an error). However, validators cannot evaluate if the data is correct (e.g., if the bus is scheduled to stop at “12:01” but the GTFS Schedule instead has “12:17”). 

There are currently three validator programs that may be used to validate GTFS data, all of which Caltrans uses and are open source and available for anyone to use (see note below):

  1. Canonical GTFS Schedule Validator, maintained by MobilityData. This is the same validator used by Google and a number of others. See here for more information about running the validator on your own.  

  2. GTFS Realtime Validator, maintained by MobilityData. This is the validator that Caltrans uses.

  3. GTFS Fares v2 Validator, created by the Transit App.

All of these validators offer useful insights, but each require a high level of comfort running technical applications. While Caltrans is developing user-friendly interfaces to make these both easier to use, any California transit provider can email hello@calitp.org to request that Caltrans run these validators on their data and share the results. 

What is GTFS Fares v2? How can I create Fares v2 data?

GTFS-Fares 2.0 significantly expands the fare-related functionality of GTFS, including rush-hour fares, fare containers (such as physical cards and apps that can store purchased fares), and multiple-fare products (such as weekly and monthly passes). Over the past year, Caltrans has been working with transit providers to help them code and publish their fares. California transit providers that do not yet have their fares coded in the Fares v2 format should aim to do so via:

  • Asking your GTFS vendor, or

  • Emailing hello@calitp.org to request additional assistance. 

Many simple fare structures can be represented with minimal effort.

Key resources:

How can I create Pathways data?

California transit providers that do not yet have stations and key pedestrian corridors coded in pathways format should aim to do so via:

  • Using tools and resources below to code it internally, 

  • Asking your GTFS vendor, or

  • Emailing hello@calitp.org to request additional assistance. 

Key Resources:

How can I create GTFS-Flex data?

Over the past year, Caltrans has been working with Transit Providers to help them code and publish demand-responsive transit using the draft GTFS-Flex specification. California transit providers that do not yet have their demand-responsive coded in GTFS should aim to do so via:

  • Asking your GTFS vendor, or

  • Emailing hello@calitp.org to request additional assistance. Caltrans staff is ready and available to assist with coding GTFS-Flex data. For small agencies, Caltrans may also be able to host their GTFS-Flex data on their behalf.

Many simple demand-responsive service patterns can be represented with minimal effort and can be published within or separate from your fixed-route transit GTFS dataset.

Key resources:

What does a Transit Data Assessment look like?

To see how the Guidelines look in the context of a real transit provider, review this example of a recent assessment. 

Where can I get more support?

Caltrans is here to help transit providers understand and successfully implement the Guidelines. Email hello@calitp.org to get started.

Can I see how my data stacks up against the Guidelines on a regular basis? 

Cal-ITP publishes monthly reports comparing a provider's GTFS Schedule feed to a subset of the Guidelines. New Features are planned to be added to the site that will expand the number of Guidelines the reports cover. 

To get added to the monthly distribution list, please email hello@calitp.org. 

Why are files and fields that are “optional” according to the GTFS Reference included within these Guidelines?

In the context of the GTFS Reference specification, optional means the field or file may be omitted for the dataset. Some fields or files are not applicable to certain transit providers and making these “required” would cause other issues. “Required” is reserved for instances where all feeds must include something regardless of service type, provider size, etc.

Many of these “optional” fields and files enhance data quality and should be included wherever applicable. Additionally, many things classified as “optional” are considered a best practice by the community. Therefore, Caltrans has determined the Guidelines should cover “optional” files and fields.

How do I determine whether or not a stop is “wheelchair accessible”? Is there a threshold by which to evaluate this? 

The decision as to whether or not a stop is wheelchair accessible is ultimately up to the transit provider. We recommend that providers think about whether or not they want to be responsible for publicly acknowledging that a stop is wheelchair accessible. Providers should make this decision with the end user in mind—should wheelchair users trust that they will be able to access a stop or not?

The Cal-ITP team has also put together a resource about wheelchair accessibility within GTFS data to address common questions and provide examples of how this data is used in practice.

Please also see the following official documentation with tips for ADA compliance.

Why should I make my data public?

The GTFS standard is designed for data to be made publicly available so third parties can use the data for both trip planning and research and analysis efforts (e.g., to show coverage of public transit across a geographic area)

Publicly publishing this data allows transit providers’ information to be included in products that riders use everyday. Riders expect and deserve to know where the bus is scheduled to be and where it is in realtime.

Keeping GTFS data private makes it difficult for data consumers to access it and defeats the purpose of having it.

Can I run the validator on my own?

Caltrans strives to make it simple for transit providers to run the validator on their own. At any time, providers can look at their most recent report on reports.calitp.org or reach out to hello@calitp.org to request validation results.

MobilityData and Cal-ITP have worked together to provide a web-based version of the GTFS Schedule validator. Simply open up the validator in your browser, enter the feed you want to validate, and you'll receive an HTML report that's easy to share.

The Schedule validator is also provided as a desktop application. The latest version of the validator (for Windows or Mac) can be downloaded from the GTFS Schedule Validator website.

More detailed information is provided on the MobilityData website.

How are the Feature groups organized?

The Features are organized into 2 broader groups: “Compliance” and “Beyond Compliance.” The reason for the distinction is simply to call out what truly is minimally needed for a GTFS feed to exist and be visible to riders, in order to set a lower threshold for providers to meet. The “Beyond Compliance” group continues to convey the high-quality standards that transit providers should meet in order to give riders the data they deserve.

Why should Compliance be prioritized?

Compliance should be prioritized above other Feature groups because Compliance is the base threshold needed in order for you to have stable GTFS data that your riders can see. It does not matter how well your feed is performing in the “Beyond Compliance” categories if it does not check all the boxes for the Compliance Feature.

What if I provide service in an area with low broadband/WiFi connection?

We recognize that this is a challenge many small and rural operators face that inhibits the adoption of GTFS Realtime data. At Cal-ITP, we have started to better track the areas of the state facing these challenges and make note of them—and we are looking for ways that we can work with you to address this problem, including offering competitively priced cellular data plans with broader regional coverage on our California Mobility Marketplace.

The Guidelines are meant to help articulate where we ALL need to act in order to get riders the info they deserve. In this case, the burden for broadband is not solely on the transit provider.

Is Compliance tied to state funding?

No, Compliance in this context doesn’t have anything to do with state funding. It is simply the Guidelines’ way of setting a level that is truly the minimum to meet to have a viable level of GTFS data that is usable by riders.