Merge develop updates to master #24
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 30 commits
October 5, 2015 17:04
And more verbose reporting of filenames since there are a lot to keep track of.
… in transfers so right join
- number PNRs with stops - add numbering to transfers - add numbering to trip IDs
Capacity loop still not fixed
Also print taz/stop/trip strings in the trace logs rather than numerical ids
Deprecate truncating demand.
Not sure why it's here. It was in here from legacy code: https://github.com/akhani/FAST-TrIPs/blob/7abeda1db001276b62c946edcce918dfed3aa711/ft_TBHP.h#L72 https://github.com/akhani/FAST-TrIPs/blob/7abeda1db001276b62c946edcce918dfed3aa711/ft_TBHP.h#L262
This is what people expect in examples
Tracing through an example, this skips adding critical links. Instead, don't allow the same trip ID to be chosen twice.
They can still be overridden by code (e.g. scripts/runTest.py)
From Dan Tischler, yay. (I'll move test demand files)
Write them in the c++ extension for each process, combine them in python. For now.
Including: - simplify path def - fix prepend_route_id_to_trip_id config requirement - output path set
I was finding that if the latest_dep_earliest_arr trip was also the best one, then I could get a problem because it would get chosen with high probability, and then if it was the only one that was good in the previous link, then that was a problem because it wasn't allowed. MIN_XFER_TIME_ addressed this but only because stops are typically defined with a vehicle arriving and then departing at the same time, so it would prevent this in labeling, but it was a hack, because if the arrival != departure then it's still a problem. This is a more lasting soln: keep that trip id as defining.
Stops might appear multiple times because of no-walk transfers. Use a list rather than an ordered dict
by calculating them for no-walk transfers (inserting a new link in calculatePathCost()
As well as transfer-penalty links in path-finding
…_order Merging stop_order into develop branch
… transit supply Because pathweights can be configured for future modes for example Warn about this instead of raising a fatal exception
Walk transfers shouldn't take an hour
Box: SHRP C-10\6-Software Implementation\RLvsTBHPexample2\EffectsOfStopOrderChange.pptx
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updates in this branch include: