Allow users to keep the same reminders across GTFS updates

[barbeau]

Currently reminders are identified internally by OBA Android by their trip_id and stop_id. When a user creates a reminder for a trip, that trip_id and stop_id are saved to the local database.

Then, for a particular stop_id, OBA will occasionally poll the estimated arrival times for that stop, search the results for an arrival for the saved trip_id, and then alert the user with the estimated arrival info for that trip_id.

The problem with this approach is that GTFS trip_ids typically don't persist across GTFS data updates. So, if the agency releases a new schedule/GTFS dataset, the trip_id for a user's reminder in OBA Android may no longer exist in the new data - instead, the "same" trip has a new trip_id (this trip_id changes because it is tied to a new date range of service, which is different than the old range). As a result, the user would never again be reminded for that trip. To fix this, the user has to delete and re-create all their reminders.

Feedback from a user:

Please somebody get the reminders fixed so we don't have to freaking rename and re-add all of them every stinking time that metro sends out a rider alert or tweaks the bus schedule. This is really a pain in the butt to have to go through the process when you have about 10-15 named reminders. Please help fix this & thank you.

So, it would be nice to come up with a way to match the "same" trip, which has two different trip_ids, across GTFS updates.

The challenges:

1. In OBA Android, we have no way of knowing that the old trip_id is no longer valid - there is no indication that a schedule change has occurred and a particular trip_id is no longer valid. So we'd need to continue looking for the old trip_id.
2. How to determine that two trips across two GTFS datasets are the "same"

One possible solution is to hash the relevant data for a particular trip (e.g., headsign, scheduled arrival time), and then compare trip hashes as well as the trip_id itself. If either the trip_id or the trip hash match, then we would alert the user. This would allow the user to keep the same reminder in OBA Android, and it should match to the "same" trips in the future.

A similar issue for server-side trip hashes is discussed here:
opentripplanner/OpenTripPlanner#1573

We should look at the hashing algorithm implemented in OTP, as well as the one that I commented on, and see what might work for OBA Android.