Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multi day GTFS flattened to 1 day supply leading to overestimating supply #11

Open
AntoineGrapperon opened this issue May 15, 2017 · 0 comments

Comments

@AntoineGrapperon
Copy link

AntoineGrapperon commented May 15, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant