Open lmz opened 9 months ago
Comments from prior discussion:
ODOT: I think this is a good example of a feature that the group needs to think about from a network input supply side as well as a modeling side. For all of these we should be thinking about what the inputs and user experince looks like. This feature specifically made me think of that. Example, are we coding the network with e-scooter links or do we assume all e-vehicles can go anywhere that can be biked or walked. Are these new models assumed to use already coded network attributes, or do they assume that new network inventory will be collected and coded. That seems like a critical point to get agreement on upfront. Again, I think this might be true for each feature. Maybe there should be a column added for each feature that covers input / output assumptions... or something like that...
SFCTA: I think regions with recent travel survey data should evaluate the market share of micromobility. It the shares are very small, then we should waste time and money bloating the model with irrelavent choices.
Met Council: recent survey data in our region shows very small shares. Doubt there is enough to meaningfully estimate models, and agree with Joe re: unnecessarily complicating models with irrelevant choices.
MTC: Punt on this until it's more clear if these will be more widely adopted.
This feature is for adding new single and combined modes. Adding single modes (scooter, e-bike, etc.) is more of a data issue than a software issue. Adding new combined modes – kiss and ride, TNC-to-transit, bike to transit, bike on transit, etc. – could be more of a software issue, depending on how they are handled. For example, keeping track of the car / parking lot for park and ride tours and trips. This feature gets more complicated once we support multiple zone systems.
Added from
ActivitySim Budget Phase 9.xslx