Project Meeting 2023.04.11 - ActivitySim/activitysim GitHub Wiki

Agenda

  • Road Map Update

Action Items

  • WSP to put the slides about the objectives in Google docs
  • Consortium members to provide feedback to Dave Ory on recommendations for additions/subtractions to the objectives. Provide additional comments (such as wording) directly in the file on Google by next Tuesday.

Meeting Notes

1. Deliver software that performs sufficiently well

2. Create and maintain software that is easy to install, use, and update

  • For example, we could check-in with new agencies and ask about their experience starting to use it.
  • This would not necessarily be product-related but more experience-related.

3. Contribute to and support an open-source travel modeling ecosystem

  • For example, deciding whether or not to support/own population sim, omx, etc.
  • Should the ecosystem expand or contract?

4. Manage consortium activities efficiently and inclusively

  • As the consortium has gotten bigger, management of examples is inefficient since there’s a lot of duplication. This may not scale well.

5. Communicate frequently and effectively with consortium members, users, and the broader transportation community.

  • For example, consciously target certain conferences, organize communication, etc.

6. Develop and maintain example implementations that provide feasible, logical, and demonstrably accurate responses to transportation infrastructure, investments, and policies.

  • This is a transportation planning tool. This objective would address whether or not ActivitySim should take ownership of some examples and own the calibration/validation to show the value that the model and demonstrate that it does something useful.
  • If you kept an objective like this, it would point the consortium to take more ownership over the example.
  • For example, the MTC example is not owned by anyone and no plans to update it.
  • Counterpoint – the calibration/validation/value should be on the agencies.
  • Lima Ohio is Ohio’s test case. They use it for a training model, as an example way to go.
  • “Demonstratively accurate” is worth discussion. This can change over time. Some models may become dated (for example, calibrated to pre- or post-COVID conditions).
  • The examples should be good starting points and then agencies can make it regionally-specific.
  • The main objective here is “should we maintain examples," what is the criteria for examples to be chosen, and can (or should) they change over time?

7. Develop and maintain example implementations that provide feasible and plausible responses to not-yet-implement-but-expected transportation infrastructure and policies.

  • One side of the examples is calibration/validation/testing. This objective addresses a separate idea of whether or not the consortium would want to be in the business of owning a model that goes further than what we observe today (for example, autonomous vehicles).

8. Increase Consortium membership.

  • Doesn’t need action items every quarter but could be mindful of this over time.

9. Provide resources – including training, technical support, user forums – that make using the software easier.

  • Doesn’t need action items every quarter but could be mindful of this over time.

10. Contribute to and support a travel modeling software ecosystem in which modeling systems are portable.

  • This objective addresses whether ActivitySim should be very easy to move across software packages. OMX does this, for example.
  • Action item would be to work with vendor systems now so that it’s flexible for integration in the future.
  • Seems like we can’t standardize synthetic populations because agencies may want to make changes to reflect their unique region.
  • What does it mean to make it portable? What would this look like?
    • As an example, take the auto ownership model. Right now, you can export this model. If you wanted to bring that to emme agent, you’d have to manipulate that structure to how they specify their models. The two platforms have different ways to specify, but that might not be necessary – there could be a standard way to spec it.
    • How much of a value add would this bring? Is this a huge barrier? Is there a huge need for this?
  • If we wanted to embrace this objective, we would probably be assuming that the vendor implementations are very attractive and strong; there would be a collective hypothesis that these implementations would be very compelling.
  • This objective is similar to the question about how much should we know what others are doing?
    • We should be aware.
    • We do have a big variety of modelers in the consortium, lots of people kicking the tires on ActivitySim and modeling in general. Suggestion that we keep our eyes on what others are doing - not to jump ship on ActivitySim but to understand how we can do things better.
  • Is there a way to do this without presupposing a particular vendor?
    • Possibly invite vendors to the consortium, they pay in, and then coordinate with them to show them how we are doing things.