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
Hi,
The tutorial on Raleigh is actually using a multiday GTFS and assigning the 1 day demand on the multiday supply that is the GTFS. (Liza just confirmed me that)
3 suggestions to fix this:
in the tutorial notebook, possibility to add some GTFS data processing to extract only 1 day (then the burden of processing the GTFS relies on the user)
include a parameter in fast-trip Run method which allows the user to select the day. Then, the data processing to extract the day specific data is included in fast-trip code. This allows you to drop most of the GTFS and focus on the day o f interest.
consider the timestamp (date + time) instead of just the time. This option is probably the most accurate (because it allows you to have trip that start at 11.30pm and finish at 1 am (ok, long trip, but you see what I mean). For big areas, it is also consuming a lot of memory...
The calendar.txt table tells you if your service is active, you also want to look at calendar_dates.txt to make sure the day of study is not some kind of special day.
Hope that helps,
Antoine
The text was updated successfully, but these errors were encountered:
Hi,
The tutorial on Raleigh is actually using a multiday GTFS and assigning the 1 day demand on the multiday supply that is the GTFS. (Liza just confirmed me that)
3 suggestions to fix this:
The calendar.txt table tells you if your service is active, you also want to look at calendar_dates.txt to make sure the day of study is not some kind of special day.
Hope that helps,
Antoine
The text was updated successfully, but these errors were encountered: