Skipped timepoint predictions, improvements to Ridership

[NJBL]

Added functionality: Handling StopTimeUpdates that have Skipped Schedule Relationships.
Also, handling TripUpdates that have Cancelled Scheduled Relationships more effectively.

Changed the response for Ridership Information to be clearer. Included service date filtering option when using the Ridership Service.

[barbeau]

This is a timely pull request :).

There is a discussion on the google/transit repo debating whether consumers should propagate SKIPPED schedule relationships down the trip if there aren't any more StopTimeUpdates after the SKIPPED one.

Two questions:

1. What's the implemented behavior for OBA?
2. Is the implemented behavior based on any existing real-time feeds?

[sheldonabrown]

Hi Sean,

1. This implementation applies SKIPPED only per stop update. Otherwise it allows the default behaviour of propagating trip arrival times across the trip and block. The special case that you are describing -- that of a SKIPPED status and no further updates -- has not been observed in the implementing feed. I will watch for it however.
2. This implementation will be tested against a future real-time feed for Community Transit in Seattle, WA. Its is not public yet, but should be shortly.

[barbeau]

Thanks @sheldonabrown!

So if you had the following Stops with real-time info:

• A - delay=3
• B - SKIPPED

...and a Stop C following this, but with no real-time data, would delay=3 from Stop A get propagated to Stop C? Or does Stop C have no real-time info in OBA?

[barbeau]

@sheldonabrown Friendly ping on above question on whether delays are propagated through SKIPPED stops - I'd like to get this clarified in the spec.

[barbeau]

@NJBL or @sheldonabrown Could you please clarify on whether delays are propagated through SKIPPED stops? I'd like to call for a vote on GTFS-realtime spec to clarify that delays are propagated through SKIPPED stops (matches Google implementation), but wanted to confirm OBA behavior first.

[barbeau]

@NJBL @sheldonabrown I just called for a vote on google/transit#139, which is an official proposal for the GTFS-realtime spec that clarifies that delays should be propagated over SKIPPED stops, which is Google's implementation. It's been a long time since I've dived into this code in OBA, but I think this may need to be changed to a continue instead of break (and counters properly incremented) to propagate delays past the SKIPPED stop? IIRC this break would result in scheduled times showing up after the SKIPPED stop (i.e., no real-time info).

[barbeau]

@NJBL @sheldonabrown google/transit#139 is now approved and part of the GTFS-rt spec. Can you please confirm whether OBA follows this behavior or not?