Add a provision for event-based trips (to support modeling of trips departing "x minutes following an event")

[jeffkessler-keolis]

Describe the problem

Many carriers operate special event service to stadiums and other event venues.

This special event service is sometimes the ONLY service available to the stadium, as is most common in the North American Rail Market during off-peak / weekend hours.

While these special-event trips typically operate on a posted schedule en-route to the event, return trips typically operate a less-precise service, departing "x minutes following the conclusion of the event."

This phenomenon is not something that can be modeled natively in GTFS, leading to three possible approaches:

• Omit the trips entirely in the GTFS Schedule, hoping that customers assume there will be some return service based on the special-event service to the event, but risking confusion around the return.

• Schedule the trips in the GTFS Schedule based on an approximate event end time, risking confusion that customers could need to depart prior to the conclusion of the event, or implying the operator should be held to an inflexible schedule.

• Schedule the trips in the GTFS Schedule based on the latest possible end time, dissuading some customers from using the service based upon an artificially-lengthy journey time, or leaving customers to believe they could stay later than possible in the event of extended event durations.

In all cases, the partial lack of data leads to confusion for riders.

Use cases

• Show customers in static information that return service is available from an event location, even when the specific departure time is variable.
• Provide a mechanism for customers to know the latest possible time at which they must leave a special event, where applicable.
• Avoid simply displaying the trip as a static scheduled interval, without the producer also providing detail surrounding the trip's variability.

Proposed solution

1. Trips should be scheduled in GTFS based upon the most-likely departure time, and standardized stop_time entries would be based upon the most-likely departure time.

2. A new file event_based_trips.txt would serve to indicate to consumers and customers that applicable trips are post-event extras, operating based on an expected event end time.

This approach ensures backwards-compatibility in that consumers could still display an approximate trip time based upon the most likely time of operation without modification, while more robust consumers could contextualize the trip as a post-event service, detailing the service span, post-event departure duration, onward connections, etc.

This framework also supports a future basis on which an operator could define a specific event end time in real-time, and have predictions for each trip based upon offsets adjusted from the actual event end time.

N.B. Most North American consumers would NOT publish [1] without also being able to produce [2] to avoid indicating a precise departure time for the event without ALSO having a structured means to represent the special-event structure.

Additional information

This scheduling practice is employed by:

• MBTA Commuter Rail (Boston, MA) — Return trips from Gillette Stadium in Foxborough (for Football and Concerts) is typically provided by a single special-event train per destination that depart x minutes following the conclusion of the event. There is no other public transit to the stadium.

• NJ Transit RiverLINE (Camden, NJ) — Return trips from the Waterfront Entertainment Center operate on a load-and-go basis following the conclusion of events, but only until 9pm Sunday through Friday; after that time, no matter how late the event runs, light rail service will only operate along a portion of the line.

• NJ Transit Rail (Meadowlands, NJ) — Return trips from the Meadowlands have a published schedule that is released as a general guideline, but that is significantly modified on the day of the event to accommodate the actual event. The last return train is guaranteed to not leave before the stated time.

• MSP Metro-Transit's Northstar Line (Minneapolis, MN) — Return trips from U.S. Bank Stadium depart the Target Field station x minutes following the conclusion of the event. There is no other public transit along this corridor on weekend event days.

• Metrolink (Los Angeles, CA) — Return trips from Angel Stadium depart x minutes following the conclusion of the event. There are no other trips on one line besides the special-event service, and the other operates extremely limited service on weekend event days.

• MTA Long Island Rail Road (Long Island, NY) — Return trips from various arens and events are provided x minutes following the conclusion of the event. These trips supplement existing services and relieve crowding on otherwise normal-ridership trains.

• Metra (Chicago, IL) — Return trips from various stadiums depart x minutes following the conclusion of the event. One such supplemental trip is provided on certain lines to fill gaps and address post-event crowding.

• Coaster (San Diego, CA) — Return trips from Petco Park depart x minutes following the conclusion of the event. This trip is typically the only service on the line, operating beyond the normal span of service, with a hard deadline departure time. A future service expansion will extend the line directly to the stadium only for games.

etc.

[leonardehrenfried]

Have you considered using flex to model these trips?

[jeffkessler-keolis]

Somewhat, but the current implementation doesn't meet the need since they target different purposes.

The start_pickup_drop_off_window and end_pickup_drop_off_window values could potentially be reused to reflect a range of times on the trip, but these aren't always defined on the agency side (e.g. "we'll run whenever the event ends").

Reflecting a "most likely" time in the arrival_time and departure_time fields would likewise need to longer be forbidden when a start_pickup_drop_off_window or end_pickup_drop_off_window value is defined.

The workload on producers would likewise go up, as the range would need to be defined for each stop, rather than simply being an offset from a specified time.

But regardless, it doesn't give any clarity around the definition of the relationship to an event time (e.g. "This trip departs 30 minutes following the conclusion of the special event," which could be programmatically derived from the content within the proposal).

[eliasmbd]

@jeffkessler-keolis Thanks for posting your first issue in the GTFS repository. It is contributions like yours that make GTFS what it is today. Feel free to reach out to us on the GTFS Slack if you have any questions.

Also, kudos for articulating your issue in a comprehensive manner. 😄

I really liked the fact that you included many examples of cities with this use case. Would you know of any citites outside the USA that would also use this practice? @leonardehrenfried Would you know of any?

[doconnoronca]

I suggested this could be one of the uses of a demand based frequency option for frequencies.txt.

#522

[leonardehrenfried]

@eliasmbd It does exist to a degree: https://www.s-bahn-stuttgart.de/s-stuttgart/fahrplaene_und_liniennetz/S-Bahn_zum_VfB-7553642

German sports events are generally a lot more predictable so the impression I get is that the trains still follow a schedule and aren't totally flexible.

[sberkley]

We at Sound Transit (Seattle, WA) have this limitation for our Sounder event service (example: https://www.soundtransit.org/get-to-know-us/news-events/calendar/seahawks-vs-minnesota-vikings-2024-12-22). We currently publish the trips to the event, but completely omit the return trips to avoid having to specify an exact time. We could be an initial producer if this proposal gains traction.

[jeffkessler-keolis]

@doconnoronca This makes sense for on-demand post-event services, but I think is a distinct use case from what's modeled here.

In that scenario, the idea is conveying to customers, "we'll boost frequencies on a headway-based line and effectively run on a load-and-go basis as demand warrants."

This scenario is more focused on conveying to customers, "whenever the event ends, we will run x amount of service with y frequency on z schedule, based on when the event ends."

I certainly see the value of the former on high-frequency lines, especially during shuttle operations, special events (e.g. parades), etc. but the use case is a tad different given this is relative "precision" around a flexible trigger.