Consider calendar / calendar dates
Since not all trips are available on all days, we should make sure to only use the available ones. This includes handling calendar.txt/calendar_dates.txt.
In a first step, we should make the algorithm aware of weekdays (calendar.txt).
In a second step, we can add calendar_dates to the mix, which disables some trips on specific dates and adds other trips.
Calendar Support for Timetables
General problem: GTFS format is specified in local times, with the exact timezome specified in the agency fields. Since our service is supposed to run purely on UTC, we need a way to normalise the data and to deal with wrap arounds for multiple days.
Data Normalisation
When parsing a GTFS feed, we need to access the agency.txt and read the timezone. This timezone specifies the local correction we need to apply to all trips. All times need to be shifted to the proper UTC time. The start of the trip should remain the reference point. So a trip starting on Tuesday at 4:00 in UTC - 10 should start on Monday at UTC 18:00. The respective availability flags need to be shifted circular for this.
This should make looking up a trip consistent with what is currently implemented, easing the load on implementation.
Lookup would be able to use utc time of day to search for next available lines. Available would depend on calendar date support.
Data structures
Du support data access, we need a few datastructures:
Weekday support
We need to ensure that all trips only run on their respective dates of the week. GTFS feeds offer calendars that offer seven days and flags for every one of these days. Given that flags can be stored in a single byte, I'd say we should use flags to store accessibility for every line. Otherwise we would have to duplicate lines for different weekdays.
enum Weekday
{
Monday = 1,
Tuesday = 2,
Wednesday = 4,
...
};
struct DailyAvailability
{
std::uint8_t weekday_flags;
bool operator()(Weekday day){ return weekday_flags & day == day; }
}
This adds an overhead of a single byte per line to the line-table. Any other indices wouldn't be smaller in overhead.
Checking availability
With the normalised UTC data, we should be able to use gmtime and local deltas to check availability for lines. This would allow still finding the next line that departs today / at a given UTC time.
Actionables
- [ ] add support for Weekday/Daily availability check
- [ ] basic structures
- [ ] implement shift (helps with data normalisation)
- [ ] Implement normalisation of local times into UTC timestamps while parsing the GTFS files
- [ ] shift trip arrival/departures into UTC format
- [ ] adjust calendar schedule for trip based on UTC delta
- [ ] add DailyAvailability to the line-tables
- [ ] make use of adjusted times/availabilities in navigation algorithms
- [ ] make navigation use UTC over local time
- [ ] add checks for current day/availability when retrieving next departure
- [ ] group trips into lines that are running on different days of the week
- [ ] test everything to the maximum