Update best practices about stop_time_updates

[evansiroky]

Just throwing this out there. It seems like the best practice for producing stop_time_updates for a current trip should be for more than "at least one" and ideally all of the remaining stops on a trip.

[leonardehrenfried]

I wholeheartedly support this and would love even stronger language.

As a GTFS-RT consumer, trip updates that contain partial data cause a never ending stream of problems and the best thing would be if all updates contained information for all stop times.

[skinkie]

Ten years ago we already had this discussion. The difference being is 'raw data', where there might be just one prediction ahead, and 'consumable data' that includes the full propagated prediction. If this is the decision, the ServiceChanges / Detours can be dropped directly, since then everything has to be added to the end of the trip anyway. /cc @gcamp

[gcamp]

You can have a trip update with only one prediction that gets propagated to the rest of the trip with the delay, so I’m not sure this is the best language change. I do agree with the sentiment that data producers should provide all the information they have available when it makes sense.

@skinkie I can see how you’re arriving at that conclusion, but TripModifications/Detours are much more than just a list of stop. Even if we ignore that it would not follow the current requirements of stop_time_update “The updates must be sorted by stop_sequence, and apply for all the following stops of the trip up to the next specified stop_time_update.“, with no ability to change the scheduled trips for a long period of time, no shapes, no explicit stop cancellation, etc.

[evansiroky]

@gcamp if there is an expectation that the one prediction should be propagated, I think it would be helpful to write about that expectation somewhere. It's not necessarily true that a vehicle will continue to remain a constant amount of time late for all future stops.

Consider a schedule with many stops that has potentially multiple stops with different arrival and departure times (ie dwell time) that could be used to help the vehicle get back on time. Perhaps an advanced prediction engine can anticipate whether a vehicle would arrive before the end of the dwell time and thus would get back on schedule. Ideally, the stop time update predictions would be adjusted after these stops with dwell times such that the predicted arrivals would be less late than before.

[stevenmwhite]

It's not necessarily true that a vehicle will continue to remain a constant amount of time late for all future stops.

Absolutely. While this is true due to operational considerations as @evansiroky noted, it's also true simply because many agencies schedules are not realistic. It's very common for us to have agency customers that are consistently early at one stop, late at the next, and early at the third. Of course, there are many software programs (including ours and scheduling software) that help them adjust their schedules to be more realistic, but it's not necessarily a given that they always will be.

[gcamp]

@evansiroky this behaviour is defined here, see the paragraph before the two examples.

This was originally to reduce the size of the gtfs-rt feeds, and it's been there since the original the release of gtfs-rt as far as I know. A lot has changed since then and prediction engines have become way more capable and delay propagation is not as useful as it was in the past.

[evansiroky]

@gcamp thanks for pointing out that specific wording and as such I now no longer see a need for this best practice change. Originally I did not see this wording becasue I was reading the spec as it is on https://gtfs.org/realtime/reference/#message-stoptimeupdate. However from now on, I will consider that website stale and will instead read the GitHub repo as the authoritative source of documentation about the GTFS-RT spec.

[stevenmwhite]

Is that true? I always point people to the gtfs.org website as the authoritative source...

I think GitHub is a bit daunting for less-technical folks (particularly staff at smaller agencies). Should we not consider gtfs.org to be authoritative?

[gcamp]

The same content is in gtfs.org, maybe a bit more hidden : https://gtfs.org/realtime/feed-entities/trip-updates/#stoptimeupdate

[Sergiodero]

Hi @evansiroky, @stevenmwhite! just wanted to point out that the documentation in GTFS.org is set to mirror the content of the Google/Transit repo. There might be some instances in which spec changes might create some problems when updating, but the site is not stale and it should constantly reflect the content from that repo. If you happen to find outdated content we would appreciate if you could point it to us so we can fix it.

As @gcamp points out, the structure for RT documentation is a bit different in GTFS.org, this is because it tries to create a better flow for people navigating the documentation, but if this is problematic we can certainly revise it.

[stevenmwhite]

Thanks! I was just spooked by Evan's comment. I always send people to gtfs.org as the authoritative source.

[evansiroky]

Thanks for clarifying that the site is not stale. I do still accept some responsibility for not reading the documentation thoroughly, but I do agree with @gcamp that this important piece of documentation is hard to discover. I think it would be very helpful if everything in the "Feed Entities" section was moved into the Reference section.