Different types of schedules

[Thierry Le Boulenge]

Hi all,

What are the different types of static schedules that are published by agencies to their users (and by "published", I don't mean by GTFS, but by any other means: website, printed, displays on stops / at stations etc). I know of 2 standard types, and can think of 2 more, but do you know any other?

1) Time-tables for the whole trip: exact times at all/most stops. Drivers will do their best to adhere to these time-tables (e.g. timepoints: stop and wait).

2) Frequency departures: a number of vehicles on the route translates into a frequency of departure from the depot/first stop (e.g. 4 buses/hour); travel times are best effort / unspecified.

3) Managed Headway: same as frequency departures, but the agency manages "bus benching" at later stops (e.g. by means of adjusting bus speeds, or adding new buses mid-route)
4) No route timing: "service will start at 6am and terminate at 10pm", no information on departure times nor on speeds/travel times.

The context is that for Trip Planner apps it is important to be consistent with timing information published by agencies (e.g. "the train of 4:54pm will arrive at 5:15pm") -- but this is true only if the information is indeed published. In case (2) for instance, the trip planner can simply refer to "the train that will arrive at 5:15pm" without causing any confusion to users, and also doesn't need to refer to services being "on-time" or "late".

In all cases except (1), are GTFS stop_times to be interpreted more as a form of indicative (... or arbitrary in some cases) prediction (e.g. from historical times) rather than a commitment by the agency to respect those times?

How much do Trip planner apps feel they have to absolutely stick to publishing these schedule times as a "truth" (as opposed to completely overriding them with better available predictions, realtime or not)?

Thanks

[Stefan de Konink]

On Tuesday, July 13, 2021 10:34:05 AM CEST, 'Thierry Le Boulenge' via

GTFS-realtime wrote:
> How much do Trip planner apps feel they have to absolutely stick to
> publishing these schedule times as a "truth" (as opposed to completely
> overriding them with better available predictions, realtime or not)?

I only know one approach that actually does something completely different.

<https://github.com/dystonse/dystonse>


Regarding the actual timetable, there are different models to for modelling
the actual timetable;

1) create fixed timetable stops where times are accurate while everything
in between is approached, this solves thing for transfers.

2) The "Delft Method" for planning, which creates a first order prediction
with a certain percentille for a trip, this is implemented as:
How can 85 percentille of the vehicles reach stop 2 in 5 minutes?
How can 85 percentille of the vehicles reach stop 3 in 7 minutes?
How can 85 percentille of the vehicles reach stop N in 30 minutes?

This results in a timetable where the "timinglink" between two stops
for each route is different.

The journey planner has to rethink its predictions in this model, for
example
by estimating minimal drive times.

--
Stefan

[Sean Barbeau]

Thierry,

>In all cases except (1), are GTFS stop_times to be interpreted more as a form of indicative (... or arbitrary in some cases) prediction (e.g. from historical times) rather than a commitment by the agency to respect those times?

This is a very good question that I've had for some time. For #1 trips the answer seems obvious from the spec - timepoint=1 is an indication that the vehicle strongly adheres to the published time in stop_times.txt. This should correspond with times publicly published to riders via other mediums (printed schedules, etc.).*

However, I don't think the spec is currently very clear how timepoint=1 fields in stop_times.txt should be handled currently for exact_times=0 trips, and apparently there are a lot of real-world datasets with these values (see https://github.com/MobilityData/gtfs-validator/pull/887#issuecomment-832326343). This case might be interpreted as #3 in your list above, and exact_times=0 trips with all stop_times.txt fields having timepoint=0 might be interpreted as #2.

>In case (2) for instance, the trip planner can simply refer to "the train that will arrive at 5:15pm" without causing any confusion to users, and also doesn't need to refer to services being "on-time" or "late".

My opinion is that if only static GTFS is available, for #2 (exact_times=0 trips) the trip planner should actually say "The train will arrive every 15 minutes" and not refer to an exact time from stop_times.txt. For planning a trip and transfers, you would need to make some assumptions about how long the rider is going to wait - pessimistically it could be the entire headway, or you could use another approach to estimate wait time. OpenTripPlanner v1 took the pessimistic approach, and OpenTripPlanner v2 likely will as well by default (although it will be configurable by deployers - see https://github.com/opentripplanner/OpenTripPlanner/issues/3262#issuecomment-810884751).

If you have real-time information, then you could give exact time estimates based on TripUpdates like "the train that will arrive at 5:15pm" without any reference to early or late. 

How exact_times=0 trips with timepoint=1 records are handled, though, I think remains something that needs to be clarified in the spec.

I'd certainly love to hear from other producers and consumers about their expectations.

Sean

*A relevant historical aside - the timepoint field actually came into existence because even though the initial spec said to only publish arrival/departure times for timepoints, transit agencies started publishing times for all stops (timepoint and not timepoint) because they wanted to see consistency in how times were represented in 3rd party apps (as opposed to allowing apps to interpolate their own times). So the timepoint field was added primarily to legitimize these data feeds - see https://groups.google.com/g/gtfs-changes/c/Ah-J9JP2rJY/m/o2WEsRgyRdIJ for more details.