arrival-and-departure-for-stop API Call Returns Invalid Predicted Values in OBA 2.0

[devinbraun]

In OBA 2.0, when reviewing responses from arrivals-and-departures-for-stop, we receive invalid values where the predicted field is "true" but the predictedArrival and predictedDeparture are 0. The bus has already passed the stop, indicated by numberOfStopsAway = -1. 0 for those two predicted time fields indicates that there is no prediction available which goes against the "predicted: true" value.

The iOS and Android apps are now showing, for example, as "Scheduled", -1 min, Arrived at
X:XXp. However, in reality it is a real time arrival and the bus already passed.

Here is a major stop where you will see this behavior after a bus passes the stop:
https://realtime.sdmts.com/api/api/where/arrivals-and-departures-for-stop/MTS_10094.json?key=org.onebusaway.iphone

Here's an example:
"code": 200,
"currentTime": 1555016788604,
"data": {
"entry": {
"arrivalsAndDepartures": [
{
"arrivalEnabled": true,
"blockTripSequence": 1,
"departureEnabled": true,
"distanceFromStop": -180.4620820891032,
"frequency": null,
"lastUpdateTime": 1555016716000,
"numberOfStopsAway": -1,
"predicted": true,
"predictedArrivalInterval": null,
"predictedArrivalTime": 0,
"predictedDepartureInterval": null,
"predictedDepartureTime": 0,
"routeId": "MTS_2",
"routeLongName": "Downtown San Diego - 30th & Adams",
"routeShortName": "2",
"scheduledArrivalInterval": null,
"scheduledArrivalTime": 1555016640000,
"scheduledDepartureInterval": null,
"scheduledDepartureTime": 1555016640000,
"serviceDate": 1554966000000,
"situationIds": [
"MTS_RTA:11796647"
],
"status": "default",
"stopId": "MTS_10094",
"stopSequence": 1,
"totalStopsInTrip": 37,
"tripHeadsign": "North Park",
"tripId": "MTS_13672904",
"tripStatus": {
"activeTripId": "MTS_13672904",
"blockTripSequence": 1,
"closestStop": "MTS_10099",
"closestStopTimeOffset": 32,
"distanceAlongTrip": 779.9332478532797,
"frequency": null,
"lastKnownDistanceAlongTrip": 0,
"lastKnownLocation": {
"lat": 32.715626,
"lon": -117.160355
},
"lastKnownOrientation": 0,
"lastLocationUpdateTime": 1555016716000,
"lastUpdateTime": 1555016716000,
"nextStop": "MTS_10099",
"nextStopTimeOffset": 32,
"orientation": 0.24830084847369474,
"phase": "in_progress",
"position": {
"lat": 32.71569992342532,
"lon": -117.16017566960676
},
"predicted": true,
"scheduleDeviation": 60,
"scheduledDistanceAlongTrip": 779.9332478532797,
"serviceDate": 1554966000000,
"situationIds": [
"MTS_RTA:11796647"
],
"status": "default",
"totalDistanceAlongTrip": 9355.078941372018,
"vehicleId": "MTS_912"
},
"vehicleId": "MTS_912"
},

[devinbraun]

@sheldonabrown Have you seen this issue on your other installations? It is causing issues with both apps and our website. Is there a patch for this already that we can apply?

[wkulesza]

@devinbraun we have a fix for this locally done. We will be testing it internally and want to make sure we follow the coding guidelines that Sheldon mentioned in other issue. Will let you know if it’s ready for production early next week. Unless @sheldonabrown can confirm they ‘be been working on it in the meantime?

[sheldonabrown]

Thanks @wkulesza . I've not heard this reported against any of our hosted instances. A quick skim of bug fixes doesn't show anything here. I'll watch for a PR...

[wkulesza]

From our deeper analysis, Issue discussion #162 and fix #160 introduce an option to cut out that kind of data through setting showNegativeScheduledArrivals to false in data-sources.xml, where it's getting GTFS-RT data (onebusaway-transit-data-federation-webapp).
Would that be better than those commits that we did @sheldonabrown ?

[barbeau]

@wkulesza I think these are different problems we were trying so solve. #160 was work-around for a GTFS-rt feed where the AVL provider was dropping TripUpdates from the feed for early arrivals - that is, if the bus passed the stop before the scheduled arrival time the TripUpdate disappeared from the GTFS-rt feed, resulting in users seeing scheduled times for the bus even if we knew the bus already passed (because there was no TripUpdate in the feed for that trip). At the time this behavior wasn't prohibited by the GTFS-rt spec. However, now this behavior is explicitly prohibited by the GTFS-rt spec, so any feeds exhibiting this behavior are out-of-spec and should be fixed (and this workaround may be useful in the interim to avoid a bad customer experience).

What I understand from the above description seems like something different where the internal data model of OBA is out-of-sync, as it seems like some fields are showing a prediction being consumed but others aren't.