-
Notifications
You must be signed in to change notification settings - Fork 100
Project Meeting 2018.06.21
joecastiglione edited this page Jun 25, 2018
·
26 revisions
- Trip mode choice implemented in branch trip-mode
- Updated trip destination choice to use trip mode choice logsums now as well
- Needed to revise and clean-up mode choice utility specifications to be easier to use / finalize
- @Jeff working on the full scale example run now
- A few trips failing with all zero_probs, and still investigating
- Issue in tour_mode_choice caused by the fact that some WALKDIST and BIKEDIST skims are asymmetrical (O->D vs. D->O) so tour_mode_choice would allow outbound walk (<3mi) but the return was >3mi, so they couldn’t get back
- Remember transit subzones were not implemented in this version
- Once complete, we'll do a pull request and then update documentation and re-release
- Example model design and sub-model designs updated
- Sub-models hyperlinked flow chart integrated
- Updated listing of all sub-model input files
- Updated data schema and built auto-documentation tool based on our data pipelining technology
- Updated getting started steps
- Lots of little clean-up in the docstrings and existing documentation
- Released Friday June 8th
- @Ben will update and re-release for trip mode choice updates
- Updated Progress Report through trip mode choice
- Current scope will be completed in a few days and all funds will be expended by then
- Updated Phase 4 Scope of Work posted for comment
- Moved multiprocessing to the top since it is the next important step
- Updated shadow pricing design to be flexible for use in all regions - allow for specifying classifiers for combinations of persons, land use, and geographies in the form of expression files for example
- Moved continued verification and clean-up to the end since it's an ongoing part of the overall effort
- Moved multiple zone systems to the end and suggested we test with either MTC TM2 or SANDAG instead of TM1 + fake data
- Discussed how best to implement support for multiple zones systems since it is not required for every partner
- No one wants to create fake data for the TM1 example
- @Lisa and @Wu to think about setting up MTC TM2 and SANDAG as the test example for this feature
- @Ben to break out task into sub-tasks
- Setup example/test to implement new features for, including creating all required inputs
- Implement support for multiple zone systems, including updating expressions in all relevant sub-models
- Implement transit virtual path building, including maybe a simple version first and then the more advanced version for TM2 and SANDAG
- See table below for zone systems in use by region
- Should we do something else in the Phase 4 SOW instead of multiple zone systems?
- It might helpful to review the multiple zone system design
- We want to make sure to keep, and test against, both examples - TM1 and the multiple zone system model example
- See you Monday night in Atlanta
Region | TAZs (1) | TAZs + MAZs/parcels (2) | TAZs + MAZs/parcels + transit stops (3) | Notes |
---|---|---|---|---|
PSRC | X | Transit IVT, etc from TAZ-to-TAZ skims. Transit access/egress times looked up by sub-mode in the buffered MAZ/parcel file and represent time to nearest stop. | ||
SFCTA | X | Transit IVT, etc from TAZ-to-TAZ skims. Transit access/egress times looked up by sub-mode in the buffered MAZ/parcel file and represent time to nearest stop. | ||
MTC TM1 | X | |||
MTC TM2 | X | Does transit virtual path building during a model run to build MAZ to MAZ impedance through the best transit access and egress stops | ||
SANDAG | X | Does transit virtual path building during a model run to build MAZ to MAZ impedance through the best transit access and egress stops | ||
SEMCOG | ? | ? | ? | Trip-based model uses TAZs |
ARC | X |
Comments
- ( Joe ) It would be helpful to have estimates of level of effort (hours/dollars) by task (and possibly subtask, for multiple zone system task) as we try to refine scopes and prioritize.