Open bdferris opened 12 years ago
We saw the same strange layover behavior with HART's OrbCAD system here in Tampa as well.
We are pulling delay information from a SQL Server database (instead of an FTP site) and formatting it in GTFS-realtime to feed into OBA, so our setup is a bit different. But, same behavior was observed when pulling the field deviation
from the OrbCAD database table current_performance_status
. In 1.0.8-SNAPSHOT (OBA version deployed in Tampa during initial testing), OBA seems to propagate the delay to the stops following the layover, resulting in an incorrect delay being shown to riders at the upcoming stops until the bus hits the next timepoint and the deviation
field is updated to a correct value. It doesn't appear that the current commit attached to this issue changes this behavior, so I'm leaving this issue open.
We were able to resolve this issue in our GTFS-realtime feed by pulling a different database field predicted_deviation
from the OrbCAD database table vehicle
. This field changes to 0
when a vehicle is in a layover, which is the expected behavior. As a result, a proper 0
delay (i.e., on-time) is shown to riders in OneBusAway for upcoming stops. The predicted_deviation
field also seems to reflect some advanced prediction mechanism, as it was significantly more accurate for customer-facing arrival times than the deviation
field. Exact prediction mechanism is proprietary and unknown.
Full SQL query used with HART's OrbCAD system that resolved this issue by using the predicted_deviation
field, including joining to other tables to get all fields necessary for a GTFS-realtime feed, is at the bottom of this OBA Dev list thread:
https://groups.google.com/d/msg/onebusaway-developers/EF0exI4zoHE/oqtRZICUiPMJ
Given the continued issues I've raised at https://github.com/SoundTransit/soundtransit-rds/issues/3 is there anything that can be done to improve how OBA handles schedule deviations through a layover?
Ben, now that I'm back in Seattle and also super frustrated by the layover bug, I'm working on a fix at the data provider level. Hopefully update soon.
On Thursday, May 1, 2014 3:03:26 PM, Ben Bodenmiller < notifications@github.com> wrote:
Given the continued issues I've raised at SoundTransit/soundtransit-rds#3https://github.com/SoundTransit/soundtransit-rds/issues/3is there anything that can be done to improve how OBA handles schedule deviations through a layover?
— Reply to this email directly or view it on GitHubhttps://github.com/OneBusAway/onebusaway-application-modules/issues/6#issuecomment-41962250 .
Welcome back @bdferris! :)
Hey @bbodenmiller if you are interested in testing the layover fix, try changing your API server to aalborg.cs.washington.edu. The API endpoint running there is using a special GTFS-realtime feed that has some fixes for the layover issue. It's still very experimental, but I'm curious to know how it works for others.
Thanks @bdferris, I'll give it a try next week with the route that I always see issues with.
Update: Route 124 that I normally see weird delays on seems it may still have issues. Stop 31630 was showing a 22 minute delay then all of the sudden jumped to on time
about the time the vehicle would typically be leaving the layover.
When a vehicle has a schedule deviation (running either early or late), we use that information to figure out when a vehicle will arrive at a future stop. In the simplest case, if the vehicle is five minutes now, we guess that it will be five minutes late at a stop further along the route. Things are a bit complicated by layovers. If the transit vehicle has slack in its schedule, we imagine the driver will use that extra time to catch back up if running late, or pause for a bit if running early.
OneBusAway already supports these semantics, but I'm noticing some strange behavior around when a vehicle is actively in a layover. If a bus in a layover and reports being 10 minutes late or 5 minutes early, what does that mean? Through this bug, I'm going to document how the OneBusAway core will strictly interpret such a reading, add unit tests where necessary to verify this behavior, and talk about what to do with other input AVL systems that have slightly different interpretations.