Feature: Model workers that work in the model, but live outside like DaySim today

[lmz]

trafficstars

This feature is intended to address regional in-commuting and out-commuting. Some number of jobs in a region are "consumed" by workers who commute into the region. This varies by geography, typically with more jobs close to inter-regional borders taken by in-commuters. In Daysim, when shadow pricing work location choices, the number of jobs "available" to regional employed residents is decremented to reflect that some of the jobs in these edge zones (as well as in many other areas throughout the region) are taken by workers who don't live in the region. Conversely, some regional employed residents commute to outside the region for work, so some number of regional employed residents should be constrained from selecting usual work locations within the region. In Daysim, there's a TAZ-level attribute of shares of jobs taken by in-commuters, and shares of employed residents who out-commute that is used to implement these constraints. These shares are derived from national datasets (LEHD, JTW(?))

Additional description

• Purpose: Account for IE/EI workers flows in shadow pricing which benefits all agencies
• Assume PMC provides data for MTC example based on CTPP worker flows
• Implement revisions
• Reasonably calibrate/validate results and make adjustments as needed
• Add tests and documentation

Added from ActivitySim Budget Phase 9.xslx

[lmz]

Comments from prior discussions:

• ODOT: In oregon we have a statewide model that supplies trips to and from the model boundary. From that larger statewide model, we also have workers traveling in and out, although currently this information is not used. If a model is generated for this task, ODOT's request would be that it generates an input file or field of some kind that could either be user supplied (like from our statewide model or other source), or generated with a module call in the model run steps/series.

• SFCTA: The current Daysim approach isn't so much a model, as a set of input attributes that are used to influence the work location choices for regional residents. This can be accomplished with existing data. A more ambitious effort would be to actually model the behavior of non-residents as they travel within the region (like SANDAG cross-border model), but I doubt we have sufficent data to do so in a meaningful way.

• Met Council- Would this distinguish major/minor metropolitan areas/employment centers located just outside model area as opposed to generalized external attraction of employees from outside?

• SEMCOG: Would this be part of external model, which considers all travels (work, shop, etc.) crossing the boundary of model region?

• PSRC- Perhaps inmplement the Daysim approach- account for the number of external workers comming to a TAZ, then make that number of jobs unavialble for work location model. In the other direction, reduce the number of workers able to make work tours for each taz by the number of workers that work externally. This does require that ixxi trips are handled in a seperate step and it would be nice if this could be automated using LEHD, but not sure if that is within AcitivtySim's domain.

• SANDAG: non-resident workers should be treated properly in shadow pricing. I'd also like to see shadow pricing converges better at MAZ by occupation category. Many time when looking at MAZ level, number of workers sent to the MAZ don't match employment coded at the MAZ.

• MTC: Not sure of the value of this; having employment numbers reflect jobs filled by regional residents seems sufficient. lmz 2023.09.14: Given recent changes in employment, I no longer agree with this! 😉

• Ohio: This model should keep track of the number of external workers by employment category (e.g. 2-digit NAICS) by MAZ or TAZ. These workers should then be added (if appropriate for their employment category) to the Visitor Model so that they can make at work sub-tours.

[jfdman]

A number of ActivitySim implementations (MWCOG, CMAP, maybe others) address the external-internal worker commute issue without any code changes. New employment data vectors are created in the land use data preprocessor by multiplying input employment by a factor derived from Census journey-to-work data that accounts for in-commuting. That factored data is used for calculation of work location choice size terms instead of the input employment data. That way the only affected model is work location choice; other models see the full amount of input employment. The solution is described in https://github.com/ActivitySim/activitysim/issues/609.

The SANDAG ActivitySim model has addressed out-commuting workers (and other external tours) explicitly in the model, There are two components to the model; an external worker identification model and an external workplace location choice model. The former model is based on worker attributes and distance to the closest external station. The latter model selects the external station that the worker uses to travel to their external job. If a work tour is generated by the worker, they are sent to the external station instead of an internal zone. The work tour is scheduled just like any other tour. A similar set of models handles non-work travel.