1. Home
  2. Cal-ITP
  3. Website Model Language

Website Model Language

By adopting model language for GTFS data hosting, explicit GTFS data usage terms, and designated technical contacts, transit providers will accelerate improvements in the quality and coverage of trip planning. 

General Transit Feed Specification (GTFS) data hosting

Issue: Without a stable URL, schedule updates may not be reflected to your customers in a timely fashion—or at all. 

As explained in the “Compliance” Feature of the California Transit Data Guidelines, “Data consumers and their applications rely on the ability to find updated information in a single, regular location.”

Therefore, one of the Guidelines states that “GTFS Schedule data is published at a stable URL (permalink) from which it can be ‘fetched’ automatically by trip-planning applications such as Google Maps, Apple Maps, and Transit App.”  This same Guideline is repeated for GTFS Realtime data as well.

Stable URLs for providers’ GTFS and GTFS Realtime feeds are critical for enabling user-facing applications that provide transit information to the general public. Changing the URL with each GTFS update may cause information to disappear from user-facing applications due to a broken link. Uploading GTFS data directly to the Google Transit Partner portal does not make the raw data available to other trip-planning applications or the general public, so it is insufficient to satisfy this guideline. Providing a stable URL for the most recent data does not prevent a provider from making historical GTFS data available through different addresses. This Guideline can be resolved with the following:

  • A stable URL for static and real-time GTFS feeds, such as:
    • https://www.goldcoasttransit.org/images/GTFS/GTFS.zip
    • https://octa.net/current/google_transit.zip
    • https://gtfs.bigbluebus.com/tripupdates.bin
  • A page on the provider’s website that lists all available GTFS feeds, such as:
    • https://www.bigbluebus.com/About-BBB/For-App-Developers.aspx
    • https://www.bart.gov/schedules/developers/gtfs
    • https://www.kartbus.org/developers/

Explicit GTFS data usage terms

Issue: Without explicit and appropriate usage terms, trip-planning applications may not legally be able to use your data in their trip planners

As explained in the “Compliance” Feature of the California Transit Data Guidelines, “GTFS data should be retrievable without unreasonable legal requirements.” Therefore, the Guidelines state that “GTFS data should be explicitly offered under the latest version of either the Open Data Commons Attributions (ODC-BY) or Creative Commons Attributions license (currently CC-BY 3.0), which are both 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.” 

Other open-source “attribution” licenses are usually fine to use; however, “share-alike” type licenses limit the use of the data by some user applications and should not be used.

Licenses and terms of use should be posted alongside the GTFS data wherever it may be found, including:

Explicit designated technical contact

Issue: Without an explicitly listed and responsive designated technical contact, errors may force trip planners to remove a transit provider from their trip planner or may not be resolved in a way that is consistent with the transit provider’s intentions. 

As explained in the “Data Availability” Feature of the California Transit Data Guidelines, “A transit provider’s website should include a way for any data consumer to report errors they observe or ask questions so that all riders can benefit from these reports” and “A GTFS Schedule feed should ensure that app developers can report inconsistencies or errors they observe, so that all riders can benefit from these reports.” Therefore, the Guidelines state that transit providers should include a technical contact on both their website and in the feed_info.txt file within the static GTFS feed itself. 

The purpose of this Guideline is to ensure that app developers can report inconsistencies or errors they observe, so that all riders can benefit from these reports. This contact information should reassure writers that their feedback will be received and understood. This can be achieved with one of the following.

  • A technical-sounding email address, such as “gtfs@“ or "developers@“

  • A specific individual, assuming this contact is kept up-to-date.

  • A link to the main customer service workflow (be it a form, email, or phone number) with the reassurance that the people monitoring this channel are prepared to handle technical inquiries.