-
Notifications
You must be signed in to change notification settings - Fork 100
Project Meeting 2022.08.04
mnbina edited this page Aug 4, 2022
·
3 revisions
- How does this approach compare with the TourCast school escorting model? (CS to respond to Guy and group)
- Add to future agenda (August 11 proposed) as to whether or not the downstream models impacted by the school escorting implementation need to be recalibrated.
- No one has sent Caitlin content for the AMPO website, reminder for partners to do so.
- Naming convention propose by Jeff last week was approved by Joe, so he will implement that
Presentation: school_escorting_implementation_pt3.pptx
- Overview of School Drop-off/Pick-up
- Types: pure (tour purpose is escort) and ride-share (tour purpose is work/school)
- Output of the model is “bundles”, which are a driver, with one or more children, by direction and purpose
- Bundle = chauffeur + escortees + direction
- Alternatives file includes 157 possible combinations
- Alt 1 is no one is escorted – happens when there are not children or no available chauffeurs, for example.
- Model Flow implications
- Impacts many downstream components
- School escorting tours created earlier in flow, so need to reduce escorting tours downstream in non-mandatory tour frequency
- Could put a constant in the pull request to reduce by a factor, as a placeholder for someone who would put this in application and be calibrating the model
- Remove destination choice sets out of the flow because the destination is known (school location), remove from computations
- In non-mandatory tour scheduling, need to schedule other half of the tour
- Constrain to school escort start times
- Set availabilities in tour and trip mode choice
- If escortees >= 1, can’t have DA; if escortees >=2, can’t have SR2
- Status – things that still need to be done:
- Test model integration changes
- Logic for new tour and trip IDs to be discussed next week
- Aiming to be publish pull request by August 15
- Implement in SANDAG model, compare to CT-RAMP model results, should be comparable
- If things aren’t matching well, should they lightly recalibrate the model?
- RSG is planning to re-estimate but requires downstream models to be re-estimated. Won’t be completed until summer 2023.
- What does the final deliverable look like?
- Software itself
- Fully consistent versus of UECs likely wouldn’t be ready until next year some time
- Discussion
- Differences between CT-RAMP and ActivitySim implementations because of how ActivitySim works. CT-RAMP has skips in the code, but ActivitySim has a pipeline. For every utility/UEC/annotation that are changed, need to be clear that changes relate to school drop-off/pick-up, for those that don’t want to include school drop-off/pick-up.
- Previous implementation in SANDAG was to plug this in, there was no estimation, just recalibration (design decision at that time). Re-estimation is planned, should make sure the survey data processing reflects this structure.
- Without some re-calibration effort, the model will produce some unreasonable results, more escorting tours at a minimum. The question is whether or not we need to maintain a prototype model that’s calibrated.