Proposal: Recommend providing TripUpdate predictions for the next trip in block

[barbeau]

Previous discussions (1) (2) have raised the question of whether more than one TripUpdate can be included in a GTFS-realtime feed for a vehicle in the case where the vehicle is serving more than one trip in the same block.

These discussions have concluded that multiple TripUpdates per vehicle are clearly beneficial in this case to avoid prediction "pop-in" for riders as the vehicle transitions from one trip to another and also give riders advance notice of delays that impact downstream trips (e.g., when the known delay exceeds planned layover times between trips).

However, this issue currently isn't addressed anywhere in the spec.

This proposal adds language to the spec recommending that multiple TripUpdates are included in a GTFS-realtime feed for vehicles running more than one trip in the same block. It also normalizes trip-updates.md and reference.md language related to blocks (future work may combine these files).

1. GitHub PR proposal - "Define rules for propagating delays across trips in same block" - Define rules for propagating delays across trips in same block #110
2. Google Groups post - "trip is in TripUpdates but not in VehiclePositions feed" - https://groups.google.com/forum/#!topic/gtfs-realtime/lVPOmi9A5vQ

Announced on the GTFS-realtime Google Group at https://groups.google.com/forum/#!topic/gtfs-realtime/69b__hYzKNc.

[barbeau]

This pull request has been open for more than one week, so per the Official Process I'm calling for a vote.

Vote will be closed on Thursday March 19th at 23:59:59 UTC.

[paulswartz]

+1

[darylweinberg]

+1 as long as it is optional
Currently Swiftly only provides predictions for current time +45 minutes. We will need to work closely with consumers if implementing as this will break at least one of my consumers.

[barbeau]

@darylweinberg Yes, including more than on TripUpdate per vehicle is not strictly required by this change, although it is recommended. It's at the discretion of the producer, with the goal of providing predictions in the feed as far ahead as the producer is confident in to provide better information to the rider.

We will need to work closely with consumers if implementing as this will break at least one of my consumers.

Do you mean that existing consumers aren't currently showing information for future trips in a block (i.e., they are only showing information for the trip the vehicle is currently serving)?

[darylweinberg]

Generally speaking, my consumers have worked around this by identifying the block a vehicle is serving and carrying the last prediction, allowing for a layover to “catchup” on any lateness, into the next trip, Block A, Trip 123 is +5 minutes late at the last prediction for the trip There is a 3 minute layover before the next trip on the block, Trip 456. The prediction displayed for the departure from the first stop of Trip 56 is +2 minutes late. One of my concerns, if receiving updates for multiple trips served by the same vehicle, will drop the first update. This would result in losing the information for the current trip. It has ben my experience that many consumers code to what we are producing at the time the contract was signed, not to the specification as it exists at the time let alone future iterations. In future procurements we are trying to change this.

[jrsanbornjr]

+1

[harringtonp]

+!

[skinkie]

I still dislike the fact that the any order is allowed almost encouraged, while this is trivial to get sorted on the producer side.

[barbeau]

I still dislike the fact that the any order is allowed almost encouraged, while this is trivial to get sorted on the producer side.

@skinkie That's fair, although that's not what we're voting on in this PR (that text in the diff shows as green because I combined the two block-related rules into one paragraph). The vote in this PR is only for the first bullet point for the recommendation that TripUpdates for subsequent blocks should be included in feeds - in other words, this PR doesn't change the existing statement that producers aren't required to order TripUpdates within the feed by block-order.

I plan to open another issue to discuss the ordering of TripUpdates by block-order.

[barbeau]

@harringtonp Just to clarify, that +! is +1?

[harringtonp]

Oops sorry +1 From my perspective (I don't propagate predictions to future trips in a block) the change is a no brainer

[ibi-group-team]

+1

[barbeau]

Voting is closed on this proposal and the results are:

• Yes - 5
• No - 0
• Abstain - 0

So it passes! Thanks all!