You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trip Updates: trip_id are the best match when in-sync, alternatives can be quite complex
?
how do we know if trip_ids are outdated/out-of-sync between static & real-time data? or if we just don't have any data for the current TripDescriptor (filter)?
should we parse the real-time response and check if the 1st trip ID is inside the local DB to know if trip IDs match or not?
trip_idis quickly outdated/out-of-sync between local static and online real-time data.For non-frequency based schedule (99%):
trip_id(&start_date) (&start_time?)route_id&direction_id(&start_date) &start_timestart_dateis optional because we can guess the "current" trip by picking the closest one.Current MT implementation:
TripDescriptorcontains atrip_id, it must matchTripDescriptorcontains aroute_id, it must matchTripDescriptorcontains adireciton_id(& not ignored), it must matchstop_id,route_type,agency_idif inTripDescriptorCurrent MT fallback for trip IDs mismatch:
Issues:
TripDescriptor'sdirection_iddifferent than 0 or 1trip_id...) & tests #117trip_idshould be optional ifroute_id,direction_idandstop_idare used appropriately.trip_id...) & tests #117trip_idshould be optional ifroute_idanddirection_idare providedtrip_id...) & tests #117trip_idare the best match when in-sync, alternatives can be quite complextrip_idsare outdated/out-of-sync between static & real-time data? or if we just don't have any data for the currentTripDescriptor(filter)?trip_id...) & tests #117TripDescriptor- >start_timeif provided to match with local data? thenStopTimeUpdate.stop_idmust match?Links: