Using StopTimeEvent.uncertainty for non-timepoints about transit HOT 4 OPEN

I think the uncertainty is more about the accuracy of the prediction, which sounds like it is high in your case.

It appears that the scheduled times on non-timepoint stops have low certainty (or none at all). I would rather try to improve how to communicate this to passengers, perhaps by not publishing a time or making it otherwise more obvious that times on these stops can vary a bit.

from transit.

Is it common to have non-timepoint trip stops for transit agencies?

For us, it is not possible to designate every stop as a timepoint since not all stops are suitable for the operator to stop and catch up back on schedule. Timepoint locations are selected by Planners and Schedulers to be safe locations for the bus to be able to wait out of traffic. These are also selected by their proximity to major travel generators or near major streets and transfer locations. It is not industry best practice to designate every stop at a timepoint because this also makes the service more difficult for the road supervisors to manage.

Perhaps an uncertainty seconds field inside GTFS-Static stop_times.txt would be a better solution to this. The data would be beneficial to all data consumers.

from transit.

Arrival times at time points can be just as uncertain as at non time points particularly if the bus is running late. The bus can be held to match the scheduled departure time if its running hot. So, it depends on how the data in the GTFS static files is to be used. Since the GTFS static files are used for multiple purposes and not just to provide predicted times to riders, I would much rather the scheduled times for all stops be included in the GTFS static times and the time point boolean filled out to show which stops are timepoints. For non time points the scheduled time can be done as simply as interpolating based on distance travelled or distance traveled and average traffic speed on the road segments traversed, or to improve accuracy by using a more sophisticated method based on the AVL and trip traces to interpolate using the historical patterns of the time between stops by time of day, direction, or even trip.

Jim Bunch

from transit.

You are right in that uncertainty affects both timepoints and non-timepoints alike. Pauses at timepoints for early vehicles can realign schedule adherence while late vehicles have no means for realignment without speeding or off-route shortcuts. As we use the more sophisticated method as you mentioned for setting non-timepoint stop times, they are often limited by number of patterns and the manual creation of turn-by-turn directions (due to base map changes from scheduling to AVL systems).

Having thought about this more, you are right in that historical data can automatically generate the accuracy spread for [non]timepoints, although this takes an algorithm instead of a lookup table. One of the nice things about GTFS-Static is pre-calculating these types of data points so data consumers do not need to also do them. In fact, the arrival/departure times similarly can all be calculated using historical vehicle positioning analysis without need to put them into stop_times.txt, but that is compute inefficient.

My point is that having an accuracy range inside the stop_times.txt can help solve confusion in riders when the schedule is running as designed but the real-time information doesn't exist to explain the early/late-ness built into the system and making transfers less deterministic and thus frustrating.

from transit.