Closed mpadge closed 5 years ago
Frankly I only skimmed the code and its design and I don't know anything about the background implementations but I'd suggest cleanly separating filtering and routing. Meaning, gtfs_timetable should only be called on already prepared stop_times, transfers and stops (I guess feed using frequencies.txt are a different case).
Generally, routing can/should only be done for a given day and a given time of a feed. The time aspect is currently considered, what about the day? With the Swiss feed for example specifying the service ids and trips used on a given date is not that trivial but necessary to get a reliable routing result. Same with the modes of transport you mentioned: A well set up feed should use transport modes (routetype) in routes.txt. IMO filtering should be done with these data modes ready and not via grep, like (not that pretty to be honest)
filtered_stop_times <- gtfs$routes_df %>%
filter(route_type == 3) %>%
inner_join(gtfs$trips_df, by="route_id") %>%
inner_join(gtfs$stop_times_df, by="trip_id")
Admittedly, there could be a number of wrapping "preparation functions" or you could do all this within gtfs_timetable. And maybe all this filtering is easier after a timetable has been created.
Thanks @polettif for highlighting the necessity of a day
parameter, which I'd completely overlooked. This commit implements that in gtfs_timetable()
, which defaults to current day. Now just have to filter by route ID ...
Routes generally have identifying patterns distinguishing subway from train from tram from whatever. It would be useful to be able to filter a feed down to only specified forms of transport, and this could be easily done by implementing a
grep
-able parameter in thegtfs_timetable()
function, along the lines of current code used to generate test data.