Cal-ITP GTFS Schedule Metadata

Cal-ITP GTFS-Ingest Pipeline Dataset

Identifies a transit brand which is often synonymous with a transit agency. Note that in some cases, such as when a single agency operates multiple separate services, agencies and brands are distinct. This document uses the term "agency" in place of "brand". A dataset may contain data from multiple agencies. This field is required when the dataset contains data for multiple transit agencies, otherwise it is optional.

https://gtfs.org/schedule/reference/#agencytxt

Timezone where the transit agency is located. If multiple agencies are specified in the dataset, each must have the same agency_timezone.

Primary language used by this transit agency. This field helps GTFS consumers choose capitalization rules and other language-specific settings for the dataset.

A voice telephone number for the specified agency. This field is a string value that presents the telephone number as typical for the agency's service area. It can and should contain punctuation marks to group the digits of the number. Dialable text (for example, TriMet's "503-238-RIDE") is permitted, but the field must not contain any other descriptive text.

URL of a web page that allows a rider to purchase tickets or other fare instruments for that agency online.

Email address actively monitored by the agency's customer service department. This email address should be a direct contact point where transit riders can reach a customer service representative at the agency.

Base 64 encoded URL from which this data was scraped.


https://gtfs.org/schedule/reference/#areastxt

Identifies an area. Must be unique in areas.txt.

The name of the area as displayed to the rider.

https://gtfs.org/schedule/reference/#attributionstxt

Identifies an attribution for the dataset or a subset of it. This is mostly useful for translations.

Agency to which the attribution applies.

If one agency_id, route_id, or trip_id attribution is defined, the other ones must be empty. If none of them is specified, the attribution will apply to the whole dataset.

Functions in the same way as agency_id except the attribution applies to a route. Multiple attributions can apply to the same route.

Functions in the same way as agency_id except the attribution applies to a trip. Multiple attributions can apply to the same trip.

Name of the organization that the dataset is attributed to.

The role of the organization is producer. Valid options are:

0 or empty - Organization doesn't have this role.
1 - Organization does have this role.

At least one of the fields is_producer, is_operator, or is_authority should be set at 1.

Functions in the same way as is_producer except the role of the organization is operator.

Functions in the same way as is_producer except the role of the organization is authority.

https://gtfs.org/schedule/reference/#calendartxt

Uniquely identifies a set of dates when service is available for one or more routes. Each service_id value can appear at most once in a calendar.txt file.

Indicates whether the service operates on all Mondays in the date range specified by the start_date and end_date fields. Note that exceptions for particular dates may be listed in calendar_dates.txt. Valid options are:

1 - Service is available for all Mondays in the date range.
0 - Service is not available for Mondays in the date range.

Functions in the same way as monday except applies to Tuesdays

Functions in the same way as monday except applies to Wednesdays

Functions in the same way as monday except applies to Thursdays

Functions in the same way as monday except applies to Fridays

Functions in the same way as monday except applies to Saturdays.

Functions in the same way as monday except applies to Sundays.

Start service day for the service interval in YYYY-MM-DD format.

End service day for the service interval in YYYY-MM-DD format. This service day is included in the interval.

https://gtfs.org/reference/static#calendar_datestxt

Identifies a set of dates when a service exception occurs for one or more routes. Each (service_id, date) pair can only appear once in calendar_dates.txt if using calendar.txt and calendar_dates.txt in conjunction. If a service_id value appears in both calendar.txt and calendar_dates.txt, the information in calendar_dates.txt modifies the service information specified in calendar.txt.

Date when service exception occurs in YYYY-MM-DD format.

Indicates whether service is available on the date specified in the date field. Valid options are:

 1 - Service has been added for the specified date.
2 - Service has been removed for the specified date.Example: Suppose a route has one set of trips available on holidays and another set of trips available on all other days. One service_id could correspond to the regular service schedule and another service_id could correspond to the holiday schedule. For a particular holiday, the calendar_dates.txt file could be used to add the holiday to the holiday service_id and to remove the holiday from the regular service_id schedule.

https://gtfs.org/reference/static#fare_attributestxt

Fare price, in the unit specified by currency_type.

Indicates when the fare must be paid. Valid options are:

0 - Fare is paid on board.
1 - Fare must be paid before boarding.

Indicates the number of transfers permitted on this fare. The fact that this field can be left empty is an exception to the requirement that a Required field must not be empty. Valid options are:

0 - No transfers permitted on this fare.
1 - Riders may transfer once.
2 - Riders may transfer twice.
empty - Unlimited transfers are permitted.

Identifies the relevant agency for a fare. This field is required for datasets with multiple agencies defined in agency.txt, otherwise it is optional.

Length of time in seconds before a transfer expires. When transfers=0 this field can be used to indicate how long a ticket is valid for or it can can be left empty.

https://gtfs.org/schedule/reference/#fare_leg_rulestxt

Identifies a group of entries in fare_leg_rules.txt.

Used to describe fare transfer rules between fare_transfer_rules.from_leg_group_id and fare_transfer_rules.to_leg_group_id.

Multiple entries in fare_leg_rules.txt may belong to the same fare_leg_rules.leg_group_id.

The same entry in fare_leg_rules.txt (not including fare_leg_rules.leg_group_id) must not belong to multiple fare_leg_rules.leg_group_id.

Identifies a route network that applies for the fare leg rule.

If there are no matching fare_leg_rules.network_id values to the network_id being filtered, empty fare_leg_rules.network_id will be matched by default.

An empty entry in fare_leg_rules.network_id corresponds to all networks defined in routes.txt excluding the ones listed under fare_leg_rules.network_id

Identifies a departure area.

If there are no matching fare_leg_rules.from_area_id values to the area_id being filtered, empty fare_leg_rules.from_area_id will be matched by default.

An empty entry in fare_leg_rules.from_area_id corresponds to all areas defined in areas.area_id excluding the ones listed under fare_leg_rules.from_area_id

Identifies an arrival area.

If there are no matching fare_leg_rules.to_area_id values to the area_id being filtered, empty fare_leg_rules.to_area_id will be matched by default.

An empty entry in fare_leg_rules.to_area_id corresponds to all areas defined in areas.area_id excluding the ones listed under fare_leg_rules.to_area_id

The fare product required to travel the leg.

https://gtfs.org/schedule/reference/#fare_mediatxt

Name of the fare media.

For fare media which are transit cards (fare_media_type =2) or mobile apps (fare_media_type =4), the fare_media_name should be included and should match the rider-facing name used by the organizations delivering them.

The type of fare media. Valid options are:

0 - None. Used when there is no fare media involved in purchasing or validating a fare product, such as paying cash to a driver or conductor with no physical ticket provided.
2 - Physical transit card that has stored tickets, passes or monetary value.
3 - cEMV (contactless Europay, Mastercard and Visa) as an open-loop token container for account-based ticketing.
4 - Mobile app that have stored virtual transit cards, tickets, passes, or monetary value.

https://gtfs.org/schedule/reference/#fare_productstxt

The name of the fare product as displayed to riders.

Identifies a fare media that can be employed to use the fare product during the trip. When fare_media_id is empty, it is considered that the fare media is unknown.

The cost of the fare product. May be negative to represent transfer discounts. May be zero to represent a fare product that is free.

The currency of the cost of the fare product.

https://gtfs.org/reference/static#fare_rulestxt

Identifies a route associated with the fare class. If several routes with the same fare attributes exist, create a record in fare_rules.txt for each route.Example: If fare class "b" is valid on route "TSW" and "TSE", the fare_rules.txt file would contain these records for the fare class:
 fare_id,route_id
b,TSW
 b,TSE

Identifies an origin zone. If a fare class has multiple origin zones, create a record in fare_rules.txt for each origin_id.Example: If fare class "b" is valid for all travel originating from either zone "2" or zone "8", the fare_rules.txt file would contain these records for the fare class:
 fare_id,...,origin_id
 b,...,2
 b,...,8

Identifies a destination zone. If a fare class has multiple destination zones, create a record in fare_rules.txt for each destination_id.Example: The origin_id and destination_id fields could be used together to specify that fare class "b" is valid for travel between zones 3 and 4, and for travel between zones 3 and 5, the fare_rules.txt file would contain these records for the fare class:
fare_id,...,origin_id,destination_id
b,...,3,4
 b,...,3,5

Identifies the zones that a rider will enter while using a given fare class. Used in some systems to calculate correct fare class. Example: If fare class "c" is associated with all travel on the GRT route that passes through zones 5, 6, and 7 the fare_rules.txt would contain these records:
 fare_id,route_id,...,contains_id
  c,GRT,...,5
c,GRT,...,6
c,GRT,...,7
 Because all contains_id zones must be matched for the fare to apply, an itinerary that passes through zones 5 and 6 but not zone 7 would not have fare class "c". For more detail, see https://code.google.com/p/googletransitdatafeed/wiki/FareExamples in the GoogleTransitDataFeed project wiki.

https://gtfs.org/schedule/reference/#fare_transfer_rulestxt

Identifies a group of pre-transfer fare leg rules.

If there are no matching fare_transfer_rules.from_leg_group_id values to the leg_group_id being filtered, empty fare_transfer_rules.from_leg_group_id will be matched by default.

An empty entry in fare_transfer_rules.from_leg_group_id corresponds to all leg groups defined under fare_leg_rules.leg_group_id excluding the ones listed under fare_transfer_rules.from_leg_group_id

Identifies a group of post-transfer fare leg rules.

If there are no matching fare_transfer_rules.to_leg_group_id values to the leg_group_id being filtered, empty fare_transfer_rules.to_leg_group_id will be matched by default.

An empty entry in fare_transfer_rules.to_leg_group_id corresponds to all leg groups defined under fare_leg_rules.leg_group_id excluding the ones listed under fare_transfer_rules.to_leg_group_id

Defines how many consecutive transfers the transfer rule may be applied to.

Valid options are:
-1 - No limit.
1 or more - Defines how many transfers the transfer rule may span.

If a sub-journey matches multiple records with different transfer_counts, then the rule with the minimum transfer_count that is greater than or equal to the current transfer count of the sub-journey is to be selected.

Conditionally Forbidden:
- Forbidden if fare_transfer_rules.from_leg_group_id does not equal fare_transfer_rules.to_leg_group_id.
- Required if fare_transfer_rules.from_leg_group_id equals fare_transfer_rules.to_leg_group_id.

Defines the duration limit of the transfer.

Must be expressed in integer increments of seconds.

If there is no duration limit, fare_transfer_rules.duration_limit must be empty.

Defines the relative start and end of fare_transfer_rules.duration_limit.

Valid options are:
0 - Between the departure fare validation of the current leg and the arrival fare validation of the next leg.
1 - Between the departure fare validation of the current leg and the departure fare validation of the next leg.
2 - Between the arrival fare validation of the current leg and the departure fare validation of the next leg.
3 - Between the arrival fare validation of the current leg and the arrival fare validation of the next leg.

Conditionally Required:
- Required if fare_transfer_rules.duration_limit is defined.
- Forbidden if fare_transfer_rules.duration_limit is empty.

Valid options are:
0 - From-leg fare_leg_rules.fare_product_id plus fare_transfer_rules.fare_product_id; A + AB.
1 - From-leg fare_leg_rules.fare_product_id plus fare_transfer_rules.fare_product_id plus to-leg fare_leg_rules.fare_product_id; A + AB + B.
2 - fare_transfer_rules.fare_product_id; AB.

More details including visual explanations available at https://gtfs.org/schedule/reference/#fare_transfer_rulestxt

The fare product required to transfer between two fare legs. If empty, the cost of the transfer rule is 0.

https://gtfs.org/reference/static#feed_infotxt

Full name of the organization that publishes the dataset. This may be the same as one of the agency.agency_name values.

URL of the dataset publishing organization's website. This may be the same as one of the agency.agency_url values.

Default language used for the text in this dataset. This setting helps GTFS consumers choose capitalization rules and other language-specific settings for the dataset.
The file translations.txt can be used if the text needs to be translated into languages other than the default one.

The default language may be multilingual for datasets with the original text in multiple languages. In such cases, the feed_lang field should contain the language code mul
defined by the norm ISO 639-2. The best practice here would be to provide, in translations.txt, a translation for each language used throughout the dataset. If all the
original text in the dataset is in the same language, then mul should not be used. See https://gtfs.org/reference/static#feed_infotxt for examples.

Defines the language that should be used when the data consumer doesn't know the language of the rider. It will often be en (English).

YYYY-MM-DD format. The dataset provides complete and reliable schedule information for service in the period from the beginning of the feed_start_date day to the end of the feed_end_date day. Both days can be left empty if unavailable. The feed_end_date date must not precede the feed_start_date date if both are given. Dataset providers are encouraged to give schedule data outside this period to advise of likely future service, but dataset consumers should treat it mindful of its non-authoritative status. If feed_start_date or feed_end_date extend beyond the active calendar dates defined in calendar.txt and calendar_dates.txt, the dataset is making an explicit assertion that there is no service for dates within the feed_start_date or feed_end_date range but not included in the active calendar dates.

String that indicates the current version of their GTFS dataset. GTFS-consuming applications can display this value to help dataset publishers determine whether the latest dataset has been incorporated.

Email address for communication regarding the GTFS dataset and data publishing practices. feed_contact_email is a technical contact for GTFS-consuming applications. Provide customer service contact information through agency.txt.

URL for contact information, a web-form, support desk, or other tools for communication regarding the GTFS dataset and data publishing practices. feed_contact_url is a technical contact for GTFS-consuming applications. Provide customer service contact information through agency.txt.

https://gtfs.org/reference/static#frequenciestxt

Identifies a trip to which the specified headway of service applies.

HH:MM:SS format. Time at which the first vehicle departs from the first stop of the trip with the specified headway.

HH:MM:SS format. Time at which service changes to a different headway (or ceases) at the first stop in the trip.

Time, in seconds, between departures from the same stop (headway) for the trip, during the time interval specified by start_time and end_time. Multiple headways for the same trip are allowed, but may not overlap. New headways may start at the exact time the previous headway ends.

Indicates the type of service for a trip. See the file description for more information. Valid options are:

0 or empty - Frequency-based trips.
1 - Schedule-based trips with the exact same headway throughout the day. In this case the end_time value must be greater than the last desired trip start_time but less than the last desired trip start_time + headway_secs.

An arbitrary human-readable title for the GTFS feed in question, usually
referencing the corresponding agency transit agency and feed type.


GTFS data type ("schedule", "trip_updates",
"vehicle_positions", or "service_alerts")


Describes whether this feed is a combined regional feed or has a relation
to a combined regional feed in some manner.
For example for MTC 511, the combined regional feed has type "Combined
Regional Feed", and the MTC-published subfeeds have type "Regional Subfeed".
If you are performing an analysis where using a regional combined feed is
inappropriate (even though that is the customer-facing data), this field can
help you assess other alternative feeds for the same services and organizations.
Not specified (null) for feeds with no relationship to regional feeds.


Base64-encoded URL of the GTFS feed referenced by the row, using
URL-safe base64 as described in
https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#to_base64


Plaintext URL of the GTFS feed referenced by the row, unencoded for
convenience directly from the value of base64_url.


Base64-encoded URL of the GTFS schedule feed associated with the row, only
filled with a value for rows representing non-schedule-type feeds


Plaintext URL of the GTFS schedule feed associated with the row, only
filled with a value for rows representing non-schedule-type feeds,
unencoded for convenience directly from the value of
schedule_to_use_for_rt_validation_base64_url.

cal-itp-gtfs-ingest-pipeline-dataset

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from an agency.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#agencytxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from an areas.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/schedule/reference/#areastxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from an attributions.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#attributionstxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a calendar.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#calendartxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a calendar_dates.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#calendar_datestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a fare_attributes.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#fare_attributestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a fare_leg_rules.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/schedule/reference/#fare_leg_rulestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a fare_media.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/schedule/reference/#fare_mediatxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a fare_products.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/schedule/reference/#fare_productstxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a fare_rules.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#fare_rulestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a fare_transfer_rules.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/schedule/reference/#fare_transfer_rulestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a feed_info.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#feed_infotxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a frequencies.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#frequenciestxt. 

This table is a cut of the cleaned metadata representing GTFS datasets currently active within the Cal-ITP ecosystem. Each record represents a GTFS dataset (feed) that is either a type of GTFS Schedule, Trip Updates, Vehicle Locations or Alerts, and provides base64-encoded URLs used to access that feed. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a levels.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#levelstxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a pathways.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#pathwaystxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a routes.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#routestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a shapes.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#shapestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a stop_areas.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/schedule/reference/#stop_areastxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a stop_times.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#stop_timestxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a stops.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#stopstxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a transfers.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#transferstxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a translations.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#translationstxt. 

This table is a latest-only cut of the cleaned GTFS data. It contains current-only data for agencies we are currently scraping. Each row is a cleaned row from a trips.txt file. Definitions for the original GTFS fields are available at: https://gtfs.org/reference/static#tripstxt. 

Cal-ITP GTFS Schedule Metadata

Preview

Data preview

Data dictionary

API endpoint

Dataset Name