trip status lastLocationUpdateTime is 0, even when location has been updated recently

[barbeau]

I'm working on showing real-time vehicle positions in OBA Android (https://github.com/OneBusAway/onebusaway-android/issues/176#issuecomment-148847977), using the trips-for-route API - for example:

http://api.tampa.onebusaway.org/api/where/trips-for-route/Hillsborough%20Area%20Regional%20Transit_5.json?key=TEST&includeStatus=true

I want to include the age of the location data in the marker balloons - however, the lastLocationUpdateTime field that should have this info is always 0 - for example:

status: {
activeTripId: "Hillsborough Area Regional Transit_98712",
blockTripSequence: 10,
closestStop: "Hillsborough Area Regional Transit_4552",
closestStopTimeOffset: -3,
distanceAlongTrip: 3482.2091907523863,
frequency: null,
lastKnownDistanceAlongTrip: 0,
lastKnownLocation: {
lat: 28.05448341369629,
lon: -82.41543579101562
},
lastKnownOrientation: 0,
lastLocationUpdateTime: 0,
lastUpdateTime: 1445033457692,
nextStop: "Hillsborough Area Regional Transit_4553",
nextStopTimeOffset: 38,
orientation: 270,
phase: "in_progress",
position: {
lat: 28.053266455191782,
lon: -82.416329
},
predicted: true,
scheduleDeviation: 180,
scheduledDistanceAlongTrip: 3482.2091907523863,
serviceDate: 1444968000000,
situationIds: [ ],
status: "default",
totalDistanceAlongTrip: 19440.69118417295,
vehicleId: "Hillsborough Area Regional Transit_2507"
},
tripId: "Hillsborough Area Regional Transit_98712"

For now, I'm using lastUpdateTime instead as a workaround.

Here are the source GTFS-rt feeds for HART: http://realtime.prod.obahart.org:8088/trip-updates?debug http://realtime.prod.obahart.org:8088/vehicle-positions?debug

I haven't had a chance to look into this yet, but I wanted to capture the information here for review later. The GTFS-rt feeds don't have timestamps in the vehicle position entities themselves - only the feed itself has a timestamp, which could be why the lastLocationUpdateTime isn't being populated. If that's the case, you could potentially argue that this is working as intended. At any rate, just wanted to document this behavior so we know why its doing this.

[barbeau]

In Puget Sound, it looks like this may depend on the agency, based on a quick look at the data.

For Metro Transit, lastLocationUpdateTime is 0: http://api.pugetsound.onebusaway.org/api/where/trips-for-route/1_100223.json?includeStatus=true&key=TEST

Here's the GTFS-rt for Metro output from OBA: http://api.pugetsound.onebusaway.org/api/gtfs_realtime/vehicle-positions-for-agency/1.pbtext?key=TEST

entity {
  id: "1"
  vehicle {
    position {
      latitude: 47.757553
      longitude: -122.24443
    }
    timestamp: 1445993103
    vehicle {
      id: "6823"
    }
  }
}

But for Pierce Transit, lastLocationUpdateTime is populated: http://api.pugetsound.onebusaway.org/api/where/trips-for-route/3_2.json?includeStatus=true&key=TEST

Here's the GTFS-rt for Pierce Transit output from OBA: http://api.pugetsound.onebusaway.org/api/gtfs_realtime/vehicle-positions-for-agency/3.pbtext?key=TEST

entity {
  id: "1"
  vehicle {
    trip {
      trip_id: "6156535"
      route_id: "57"
    }
    position {
      latitude: 47.21401
      longitude: -122.46944
    }
    timestamp: 1446039499
    vehicle {
      id: "244"
    }
  }
}

We'll need to dig into the code, as both GTFS-rt outputs do include timestamps for vehicle positions. But, OBA could be populating this field internally - it doesn't necessarily match the data coming into OBA for each agency.

[sheldonabrown]

Pierce Transit updates come via OrbCAD integration, not via GTFS-RT as KCM does.

I'm trying this commit out now in the WMATA dev environment. I think its what you are looking for:

https://github.com/camsys/onebusaway-application-modules/commit/d0ccf2488bc21de7517d2004e82523f4ad73366a

[barbeau]

@sheldonabrown Thanks for taking a shot at this! So if I'm reading this right, by design this change wouldn't have any impact on the HART data, because HART's GTFS-rt feed doesn't have a timestamp per vehicle position or per trip update, right?

http://realtime.prod.obahart.org:8088/trip-updates?debug http://realtime.prod.obahart.org:8088/vehicle-positions?debug

Who created that GTFS-realtime feed anyway ;)?

IIRC, in the underlying OrbCAD database view a timestamp record per vehicle update wasn't given to us, although one probably exists somewhere in the database. Would require a change to the view and the GTFS-realtime export code to expose it.

[sheldonabrown]

A very astute observation. I saw the timestamp in the snippet above but only assumed it was relative to the vehicle and not the entire feed. So yes, more work is required here....

[barbeau]

I think that commit is still useful to deploy as is though, right? And if (hopefully when) per vehicle timestamp is added to HART or other feeds it would automatically pick it up?

[sheldonabrown]

Yes agreed. I'll keep the commit for when the data is there.