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
Connections are now stored per 24h sorted by departure time. Each connection is stored individually, this means that storing 2 days of connections takes 2x the storage. This doesn't scale properly for some of the use cases this library is meant to support:
Planning routes in the future.
Supporting offline routing on the planned schedules.
...
Solution Proposal
We should add a mask to the connections instead of a date. That mask describes the schedule that determines when the connections are active.
The text was updated successfully, but these errors were encountered:
"Connection departs at 10:00, from station A to station B, has tripId 123" * ( DATE0, DATE1, DATE2, ....)
The exposing API (towards the algorithms, that is) would boil down to enumerating all these connections.
Adding realtime info can be done by creating an exceptions-object. This exceptions object would enumerate connections as well, but amend this enumeration: delayed connections should be given on later, earlier departures given earlier.
For this, the 'RealTime' object can keep a list of 'exceptions', sorted by original and new departure time. This way, the enumerator should be able to quickly detect when a connection (from the regular enumerator) should be dropped or when it should be extra included.
Problem
Connections are now stored per 24h sorted by departure time. Each connection is stored individually, this means that storing 2 days of connections takes 2x the storage. This doesn't scale properly for some of the use cases this library is meant to support:
Solution Proposal
We should add a mask to the connections instead of a date. That mask describes the schedule that determines when the connections are active.
The text was updated successfully, but these errors were encountered: