Within the spec documentation, explicitly call out that holiday information should be included

[evansiroky]

Describe the problem

Caltrans has recently completed a research project on holiday service data quality (see paper). One of the findings of our research indicated a confusion among some agencies on the best ways to include holiday information within GTFS data.

The current GTFS Schedule specification narrative does not affirmatively say that holiday data should be included. There are some places that list examples or suggest that holiday information could be added as follows:

booking_rules.txt:

Example: If empty, prior_notice_start_day=2 will be two calendar days in advance. If defined as a service_id containing only business days (weekdays without holidays), prior_notice_start_day=2 will be two business days in advance.

calendar_dates.txt

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.

best practices on All Fields

Route 2 includes a deviation on Main Street nights, Sundays, and holidays.

Use cases

This applies to major holidays regularly observed each year by transit agencies.

Proposed solution

This proposal seeks to clarify within the GTFS Specification narrative that holiday service known in advance and generally repeating each year should be an explicitly expected element of all GTFS Schedule feeds.

A possible place to insert this expectation would be within the bullet points outlining expectations for current and upcoming service (bold indicates new addition):

• One GTFS dataset should contain current and upcoming service (sometimes called a “merged” dataset). There are multiple merge tools available that can be used to create a merged dataset from two different GTFS feeds.
  • At any time, the published GTFS dataset should be valid for at least the next 7 days, and ideally for as long as the operator is confident that the schedule will continue to be operated.
  • If possible, the GTFS dataset should cover at least the next 30 days of service.
  • All holidays observed within the valid period of the feed should be accounted for with the appropriate service reductions and/or additions.

Additional information

No response