search

OneBusAway / onebusaway-ios

OneBusAway for iOS, written in Swift.
Other
88 stars 34 forks source link

Gracefully handle duplicate or illogical transit data #538

Open ualch9 opened 3 years ago

ualch9 commented 3 years ago

Context: #531 and #537

For these types of GTFS issues (duplicate stops, etc.), OBA iOS will need to be a little more tolerant and not crash. AFAIK there isn't actually anything in the GTFS spec that prevents this specific instance of two stops in a row with the same time. I'll be the first to admit that it's not (typically) logical, but for a variety of reasons (primarily related to transit agency export software) it's historically been allowed. So it won't be an unusual case for these issues to pop up from time-to-time.

Obviously, the data should be fixed server-side if it is indeed a data problem, but iOS should allow the display of the data without crashing.

Originally posted by @barbeau in https://github.com/OneBusAway/onebusaway-ios/issues/537#issuecomment-932564829

In relation to App Store crash reports, OBAListView throwing duplicate identifier exceptions tops the list. Fix requires a rethinking of how to identify items so UIDiffableDataSource does not crash.

aaronbrethorst commented 3 years ago

If they really are duplicates, then why not de-dupe them at the point in time at which they are deserialized from a JSON response?

ualch9 commented 3 years ago

i'm cautious about making assumptions about the data and deleting stuff that might actually be relevant. @barbeau any tips on how android handles duplicate data, does it still show dupes or does it hide it?

barbeau commented 3 years ago

Yes, I was actually just going to say the same - if the GTFS data has made it through agency (and possible industry-standard) GTFS validators and the OBA server pre-screening when it was loaded and the application of real-time data within OBA, it could be legitimate data. So OBA clients shouldn't make a judgement call and filter it. If there is filtering/validation done, it should be done server-side when the data is loaded.

OBA Android will just show whatever is in the API response - so it would show two back-to-back stops with the same arrival/departure time. Android relies on the IDs for entities being unique, and does some upper/lower case conversion for entity names, but other than that will render whatever it gets from the server.

It does highlight that we need a good problem reporting system from the apps and a way to get feedback to agencies. This is an industry-wide issue, not just OBA. We piloted an Open311-based feedback system in OBA Android with Tampa where data issues are directed straight to the agency (bypasses developer entirely), but so far no other region has deployed the same.

barbeau commented 3 years ago

One idea here is to add a sequence ID to each element - the raw GTFS data for this actually has stop_sequence for each of the stoptime records for the trip shown in https://github.com/OneBusAway/onebusaway-ios/issues/537#issuecomment-932542840, but it doesn't show up in this API response (maybe the assumption is that sequence ID is inferred here and the original stop_sequence is irrelevant).

ualch9 commented 3 years ago

I will research further. thanks for the pointers, @barbeau!