-
Notifications
You must be signed in to change notification settings - Fork 57
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
Specific Time Point Aggregations #51
Comments
Hi @d-wasserman ,
|
Hi @sablanchard, This echos what I thought I could do based on how headway are computed. The fact they are accessible in a table is very convenient, and thanks for outlining where to check. A potential PR I am thinking might be helpful is an "access_range" calculation where someone could specify a percent range they want to modify the headway tables for "low end" vs. "high end" access values. So 0 and 100 as parameters would yield the min (0 - arrived on time) and the max (equal to the headway), where as a percent passed would be some percentage of that. We are weighing different solutions here, and if we go in this direction I will let you know. A PR is possible, and we have contributed tools as part of transit projects in the past. Thanks for the in depth run down and road map status. I can understand how specific time points would be difficult given Pandana's architecture. This all makes sense. I will come back with clarifying questions. |
Hi @sablanchard,
We are evaluating using Pandana for a project, but getting deeper into the API it seem you use the average headway to identify the appropriate wait times. I have used Pandana before for its speed, and hope to again, but I need to investigate access variability as well as the average (specific time points are helpful here).
The text was updated successfully, but these errors were encountered: