barbeau
commented
11 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
bbodenmiller
bdferris
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.