Fix per-stop predictions (#127, #138, and #139) #142
Conversation
…point predictions, Downstream vehicle deviations are propagated to upstream stops
…sAway#138, and OneBusAway#139) * Current implementation of per-stop predictions keeps the current OBA internal data model of supporting one deviation per stop. As a result, there are two situations (marked by TODO statements in ArrivalAndDepartureServiceImplTest) where OBA can't entirely represent both arrival and departure information correctly. We include two commented-out unit tests for these situations, which can be uncommented if future works overhauls the OBA internal model to fully support arrival and departure deviations for each stop * Change to using TransitInterpolationLibrary, which correctly implements GTFS-rt behavior of only returning real-time information if a prediction is upstream of the stop in question. InterpolationLibrary, which is a generalized interpolation model outside of transit, didn't accurately represent this situation. * Add/fix/clarify documentation throughout code affected by OneBusAway#127, OneBusAway#138, and OneBusAway#139.
|
Can one of the admins verify this patch? |
|
Just added |
|
I'll try look at this in the next week. I'll need these changes myself so I am highly motivated :) |
|
@sheldonabrown Great! I should mention here also that we've been looking at schedule-based trips here - we aren't yet testing for frequency-based trips. But, I believe this implementation can support frequency-based real-time update as well - we'll just have to figure out what needs to be done here, and see if we can borrow any logic/code from the |
|
@sheldonabrown If it helps in your evaluation, the code in this PR is now deployed to: ...with updated GTFS data. GTFS-rt feed is at: (remove "?debug" for protobuf) |
|
@sheldonabrown Also, HART data is in that server instance, and seems to match up against tampa.onebusaway.org nicely (HART is providing only single predictions per trip). |
…t-in-UI-if-no-alerts-are-active-in-admin-console-2 Fix cache invalidation issue related to service alerts
This PR includes several commits that provide targeted fixes for issues #127, #138, and #139, in order to properly support multiple
stop_time_updatesfor a single trip from a GTFS-rt source. This is follow-on work to ad8870b, which enabled the consumption of multiplestop_time_updatesfor a single trip from a GTFS-rt source. This PR focuses on the proper generation of predicted arrival and departure times for each stop, based on the GTFS-rt input. Some of the source code to support per-stop predictions internally in OBA was already in place even prior to the above patch (including the code to figure out which stop deviation should be applied to a given stop), and this PR brings everything together in working order. It also adds a significant amount of documentation via comments and Javadocs to better explain what's happening in plain English.We also include a number of tests for
ArrivalAndDepartureServiceImplinArrivalAndDepartureServiceImplTest(via 1a74a49) to ensure that the predicted arrival and departure times provided byArrivalAndDepartureServiceImplare correct, given a set of input time point predictions for one or more stops. This includes verifying that the behavior of OBA is consistent with the GTFS-rt spec, especially for the propagation of arrival/departure times downstream in a trip. We include multiple commits in this PR because they are interrelated, and all are needed for the tests to pass.It should be noted that this implementation of per-stop predictions is used to produce arrival/departure times even if a GTFS-rt source only provides a single prediction for a trip - in other words, single predictions per trip are just a special case of multiple stop predictions per trip where n is the number of per stop predictions, and n = 1.
One additional item of note - as mentioned above, we built on existing OBA code to support multiple predictions per trip, which was our least invasive option. This code therefore keeps the original OBA internal data model of supporting one deviation per stop. As a result, there are two situations (marked by
TODOstatements inArrivalAndDepartureServiceImplTest) where OBA can't entirely represent both arrival and departure information correctly for the same stop. We include two commented-out unit tests for these situations, which can be uncommented if future works overhauls the OBA internal model to fully support arrival and departure deviations for each stop. Specifically, these situations that aren't supported are:In both cases, the departure prediction deviation (which is predicted_departure - scheduled_departure) would be returned as the arrival prediction deviation. This is because if we can only support one deviation per stop, we should prefer departure deviation so it's propagated downstream. I don't believe the current OBA UIs and apps would even expose this limitation, as they show departure info when its provided (but someone correct me if I'm wrong). So, for us, the risks and amount of work required to overhaul the entire internal OBA data model far surpassed the need to try and fix these two corner cases. We do include the (commented out) unit tests to verify correct behavior for these two cases, though, if this problem is tackled in the future.
Finally, I want to say a huge thanks to @cagryInside, who spent a lot of time debugging OBA so we could better understand what was happening inside OBA. This PR definitely wouldn't have been possible without him!
We'd love to get feedback on this, especially from @bdferris @kurtraschke and @sheldonabrown. We've been testing this with real data in Tampa, and we'll continue to test more heavily in the upcoming weeks. If anyone else has access to real GTFS-rt feeds (or another data source format) that provides multiple stop predictions per trip, it would be great if you could test this out as well, or at least provide us with the feeds so we can take a look.