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
This will probably be a quite large restructuring, but very useful in the long run, especially when we get data sources with overlapping geographical areas.
The monitor should then be able to display predictions from all data sources for any given stop (as stops are identified by name, this should not be too hard).
A trip might need the source as an additional identifier (encoded in the URL) to avoid slow performance.
Changes needed for this to work might be:
having to hold more than one parsed schedule in memory at the same time
filtering out duplicates of trips that appear in both sources but with different ids (and deciding which one to keep, maybe based on data quality?)
handling of performance issues when trying to iterate over all trips, stops or stop_times from all schedules (instead of just one schedule like we currently do) when trying to find a matching trip/stop/stop_time, wich occurs in our code in several places.
The text was updated successfully, but these errors were encountered:
This will probably be a quite large restructuring, but very useful in the long run, especially when we get data sources with overlapping geographical areas.
The monitor should then be able to display predictions from all data sources for any given stop (as stops are identified by name, this should not be too hard).
A trip might need the source as an additional identifier (encoded in the URL) to avoid slow performance.
Changes needed for this to work might be:
The text was updated successfully, but these errors were encountered: