| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | ID | Feature | Description | Agency comments | Type | Revised Descriptions | ||||||||||||||||||||
2 | 2 | Ability to link with a land use model review and plan and scope | Transport -> Land use model integration is typically achieved by configuring the transport model to generate a set of network based accessibility metrics. These metrics may include direct OD mode-specific travel times, costs and other impedances, multimodal OD logsums, or destination/mode logsums. The specific metrics used vary by land use model tool and implementation. Land use -> transport model integration is typically acheived by incorporating geography-based measures of housing units, households, employment by sector, or other measures. Some models may also generate synthetic populations Key to this feature will be the providing ActivitySim with flexibility in generating and outputting the specific accessibility metrics required, as well as providing ActivitySim with flexibility in accepting new land use and synthetic population inputs | Met Council: Are we talking about providing standard tables to be passed back and forth, or about an internal integration? SEMCOG: Is any full intergration of transportation model and landuse model considered under this feature to test the impacts of a tranportation scenario on landuse or vice versa? ARC: this is important in the spirit of a fully integrated transport / land use model, especially in terms of data exchange and feedback loop between models SANDAG: ActivitySim generates TAZ or MAZ-based accessibilities. I think what we need to do is to aggregate TAZ or MAC based accessibilities to land use zones, which are typicallly a lot larger than TAZ and MAZ. I feel this is useful prodedure that benefits many of us. SFCTA: There are a variety of land use models and associated, and a variety of ways to establish linkages from travel model to land use model. I think this task might be best considered from a more generic perspective, perhaps linked with disaggregate logsum generation. MTC: Not sure what this means without specificity. We would prefer number 13: "Disaggregate accessibilities" for this purpose. | Accessibilities | Additional Description - Purpose: Develop a plan for implementing land use model integration targeted for all agencies - Review and summarize existing land use model integration designs and implementations in practice - Key concepts include 1) creating a series of zonal accessibility measures, creating zonal logsum-based measures, 3) aggregating travel model zone data to land use model zones, 4) aggregate or disggregate measures, 5) etc. - Share and discuss review with PMC - Recommend and discuss a design for activitysim - Draft a work program for implementation in later phases | ||||||||||||||||||||
3 | 3 | Model workers that work in the model, but live outside like DaySim today | 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(?)) | 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. 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. | Refinement | 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 | ||||||||||||||||||||
4 | 4 | Parking capacity (supply) modeling | Historically, parking capacity constraint has either been entirely absent from modeling systems, been used to constrain drive choices to PNR lots, or been used to constrain or redirect parking in dense urban cores. Depending on the level of policy sensitivity desires, and criticially constrained by the amount and detail of available parking data, parking capacity constrain could be extended to be explicitly considered when making drive choices. In an unreleased enhancement to the San Francisco Daysim model, parking capacity constraint was extended to explicitly account for onstreet parking supply (free, free permit required, paid meter) as well as off-street parking supply. | ODOT: If we were to move foward with this, we might want to consider some type of curbside drop-off capacity feedback as well... seems like if we were going to go to this level of inventory detail and modeling complexity we wouldn't want to mis curbside concepts. SFCTA: We need to be cautious about what data is required to drive any of the proposed model enhancements. Data on PNR lot capacities is tractable for all regions. Data on parking lots may be available in some regions but not all. Data on all curb parking capacity is highly unlikely to exist in most regions. We also need to be cognizant of the geographic resolution / granularity of the model. Most models are still operating at relatively aggregate zones and networks, although there is increased movement towards "all streets" networks with the advent of OSM and commercial network data products. I think it might be worth holding off on this until there a clearer need driving it, and more of our modeling systems incorporate an appropriate level of geographic detail. SEMCOG: I like the idea to put all parking related models next to each other to have a full picture of what current ActivitySim can handle and what else should be enhanced or added. PSRC- Perhaps implement the Daysim approach- account for the number of external workers coming to a TAZ, then make that number of jobs unavailable 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 separate step and it would be nice if this could be automated using LEHD, but not sure if that is within AcitivtySim's domain. MTC: Transit station parking capacity seems both more useful (because it affects transit ridership) and tractable (PNR supply vs all parking). Would prioritize that and not the generic version; rank transit PNR as high, general version low. OR-DOT - we (Oregon) are hoping to be able to code car-free districts - no cars allowed - no vehicle travel time options... Similar to not having the ability to access a given zone by transit... | Parking | |||||||||||||||||||||
5 | 5 | More detailed pay for parking model | The current asim free parking model uses household variables such as income, workers, size, and work location to estimate free parking. Later models such as SANDAG's model use more detailed information to estimate free parking - household income, work location, monthly/daily/hourly parking by zone, monthly/daily/hourly parking supply by zone, zonal employment by sector (blue collar, white collar, etc.). A rich set of microzone parking cost and supply data is required. | SFCTA: At what choice level is this made? Prior to destination mode choice so as to condition destination and mode choices? At the trip level? Can / should this be integrated with parking capacity constraint? SANDAG: I believe it is implemented pre mode choice because parking cost affects mode choice. SANDAG's parking inputs are fairly detailed, maybe too detailed, and it makes data preparation very challenging. We are in the process of brainstorming simplify the model in a way to allow more practival parking data preparation. Our parking model is not capacity constrained. I'd prefer a model relies on more realistic parking inputs (think about the challenging effort to predict hourly, weekly, monthly parking cost and spaces by each MAZ for year 2050), I'd like to see a capacity constrained parking model with a simplified and streamlined parking space and cost inputs. MTC: This submodel already exists so this means expanding on the specification of the model? So this is just a configuration/model specification change? | Parking | |||||||||||||||||||||
6 | 6 | Direct linkage with bca4abm benefit cost analysis package | The bca4abm tool is used for cost benefit analysis of a comprehensive set of performance measures generated from an ABM or TBM. It calculates social, environmental, and economic measures and is especially good for equity analysis. It was developed for SANDAG and Oregon Metro. Like PopulationSim, it uses the activitysim framework. It could be contributed to the consortium and incorporated into the offering and directly hooked up and documented (with tutorials, etc.). https://github.com/RSGInc/bca4abm. | SFCTA: What is the relationship between this and the methods that MTC developed to caculate fully disaggregate logsums for benefit cost calculations? This enhancement makes sense to prioritize only if multiple agencies are really interested in using BCA tool. SANDAG: BCA tool is used in genearting SANDAG's RTP performance metrics derived from travel time saving ect which are from ABM. I know some agencies developed logsums based benefit for FTA's Summit program. SANDAG used to hinave a process to preapre inputs for Summit, but it is not used because FTA's Smmit program is inactive. My guess is most agencies need transportation investment cost vs mobility benefit type performance metrics? If so, I think this feature can benefit many of us. MTC: We would prefer number 13: "Disaggregate accessibilities" for this purpose. ODOT: Prior to moving forward on a linkage to a tool like bca4abm, I would push/suggest that ActivitySim have a standard dataset at the end. This is likely largely complete, but BCA4ABM does a lot of measures around link data, which I don't think ActivitySim touches yet. I would advocate that ActivitySim has a standard link data table / structure prior to moving forward with a standard linkage of ActivitySim to bca4abm. Ohio: I'm unclear whether the bca4abm tool is able to be used out-of-the-box for INFRA/BUILD/RAISE project BCA or if it's just a regional tool. If it's the former, then this would be a nice addition. Its parameters would need to be easily accessible for the annual update, as well as regional calibration for things like crash rates. If it is the later, then you can ignore Ohio's rating. | Accessibilities | |||||||||||||||||||||
7 | 7 | AV and TNC routing review, design, data plan and scope | MTC, SANDAG, and others have built AV/TNC supply side / fleet management / routing modules. These modules are similar to transit supply models in that they attempt to model a vehicle fleet to meet travel demand, but build tours to schedule and dispatch service as opposed to using fixed routes. There is not a lot of observed data to estimate these models, in part because TNC operators are secret about their operating plans. TransModeler (and possibly other software providers) have developed related functionality. These features are useful for answering questions related to TNC fleet size, number of drivers, mode share shifts, etc. | SFCTA: I was super impressed by the work done for SANDAG, but given that such capabilites are completely untethered to any empirically observed data I have reservations about this investment, as it is contrary to my own hopes that ActivitySim be truly "data driven". I think we as a community should really get serious about collecting observed TNC fleet behavior. ODOT: In ODOT's testing we have found that it's very easy to get unrealistic results if no constraint or assumptions on the fleet is set. A critical part of routing is knowing the fleet size. I would advocate that if this moved forward that it would have the ability for the user to set a fleet size by time period, as well as an option for the model to calculate the fleet size needed to meet the demand and return that as an output. SANDAG: it seems this is related HH and Fleed vehcile tracking in task 1? MTC: See comment B) on 1 "Vehicle tracking and fleet behavior" Ben: Is this more of supply model like RSG did in FL? | Vehicle Modeling | Additional Description - Purpose: Develop a plan for implementing an AV/TNC fleet routing targeted for all agencies - Review and summarize existing models in practices - Share and discuss review with PMC - Recommend and discuss a design for activitysim - Draft a work program for implementation in later phases | ||||||||||||||||||||
8 | 8 | Explict school escorting / drop-off model | Add an escort child model that predicts whether each child attending school gets picked-up or dropped off, and either links that stop to driver’s existing mandatory tour or generates a new non-mandatory tour for the stop. This model typically accounts for ~35% to 40% of the total shared-ride trips on an average weekday, and is particularly useful for modeling intermediate stop locations and trip occupancy patterns for work tours made by parents with school-age children. Overall, the combination of this model and the joint travel models typically account for ~80% of all ridesharing. The combination of the escort child model and existing joint travel models sufficiently models ridesharing while at the same time avoiding the software complexity (and maintenance difficulties) introduced by other approaches. | ODOT: I don't have a great suggestion, but just the thought that school escorting could be something that changes with new tech (AVs). If we are in that component improving it, we should have an eye to future tech and working to ensure it has the proper hooks for the user to play with future scenarios around changing norms and tech. SFCTA: Can we subsume this task within the vehicle allocation task? I think vehicle allocation (if implemented at the HH level) should address all joint travel, not just school escort. Does this imply changes to other Activitysim joint travel model SANDAG: we have a escort model, borrowed from MAG. School escort is a big market, witht the escort model added, our joint travel performs better than before. Considering school escort is a big travel market everywhere, this might benefit many of us. MTC: Agree this sounds like 1A) "Vehicle tracking and fleet behavior" / 32 "Household vehicle types model" | Refinement | Additional Description - Purpose: Develop a escort child model targeted to all agencies - Assume escort calibration data already developed for MTC or borrow distributions from another region? ODOT? - Implement revisions - Reasonably calibrate/validate results and make adjustments as needed - Add tests and documentation | ||||||||||||||||||||
9 | 9 | Telecommute model in cooperation with SEMCOG | A worker telecommute model could determine whether each worker with an out-of-home workplace participates in a telecommute program and therefore might not travel on the simulation day. As an example, see the binary logit model "work from home" model in the SANDAG ABM. This is run before work location choice. Planned for SEMCOG model. | SFCTA: I have serious reservations about investing in such a model given expected changes in behavior due to current events ODOT: Joe, I don't quite follow the concern. Are you saying that it might be better to have telecommuting be something that the user sets as an input as opposed to the model? Maybe it would be nice for the user to be able to set a percentage of the population they would like to test as telecommuting, then the model would help pick the correct workers to assign the telecommuting too. The input control could be set in calibration and then tweaked in future scenarios. I do think it would be important for the user to have easy access to tweaking the overall number of telecommuters for future scenativity tests. SFCTA: Yes, I think what Alex suggests is more appropriate. Telecommuting has been growing relative slowly over the past decades (in the Bay Area it increased from 4.7% to 6.3% between 1960 and 2016!), despite huge changes in information and communication technology. Yet, I also think the COVID experience has the potenital to significantly change this pattern as organizations and people have been "forced" to adopt working from home. I think any empirical data we have on past telecommuting has a high risk that it won't be relevant for the future forecasting, and our interest in exploring scenarios involving different levels of telecommuting is better addressed through simpler, and appropriately caveated, assertions. SEMCOG: SEMCOG's telecommute model is more for exploring scerios. I would agree a easy setup and flexibiltes for users to define (by occupation?) would be nice. PSRC- Due to COVID-19, the ability to model specific percentages of telecommuters is being discussed as part of our RTP. Daysim has this option, but it requires running a work from home model, which we are currently not using. We are trying to figure out how to do this in the Work Location Model, which always includes the home parcel as an alternative SANDAG: SANDAG has two telework components, work from home (permenant telework) and occational telework (3 alternatives, 1 day a week, 2-3 days a week, and 4+ days a week). We have been asked to do some testing on telework scanrios, mostly likely with a pre-defined % of telework rate. To let model hit a predefiend telework %, we are considering adjusting the constant (not ideal but the best we can do not knowing the dynamics of how the new 'nomal' will affect telework). Still it is a bit challenging, because it is almost a iterative calibration process. I wonder if we can built a process to make hitting a pre defined telework % easier. MTC: It would be useful to have telecommute be an explicit (simple) model for scenario testing as described by other agencies. (But wouldn't work location would affect telecommuting?) Ohio: We are adding this to our 3C CT-RAMP model. Employment is by 2-digit NAICS code. Employees in each of these categories have a specified % of who is eligible for teleworking. (So, waiters have a 0%, whereas FIRE has a much higher %.) Workers who have a job that is telecommuting eligible then are sent to a model to determine how many days a week they telecommute, and then a model to determine whether they are telecommuting that day. If so, then they are sent to the mandatory work pattern model, but their work location is replaced with their home location. They can still make "stops on their way to work" to drop off their children at school. They can also make at-work sub-tours. However, they have that mandatory work activity, so that they are not making discretionary trips during their workday. A single parameter is on the interface that gives the "telecommuting" percentage. This parameter is then changed for future scenarios to increase the share of telecommuters for telecommuting-eligible workers as desired. A 100% in this field will not assign 100% of workers to telecommuting patterns, but rather only those who are telecommuting-eligible. We have changed our HTS this year to distinguish between workers who don't telecommute because they don't want to vs. they aren't eligible. | Refinement | Additional Description - Purpose: Develop a worker telecommute targeted to all agencies - Assume SEMCOG project develops a SEMCOG estimated worker telecommute model - Twice discuss design and coordination with SEMCOG project team - Implement an activitysim example version of the SEMCOG example/design - PMC provide estimation/validation data - Reasonably estimate/calibrate/validate results and make adjustments as needed. For example, revise downstream models to use this new variable. - Add tests and documentation Likely design: runs at the person level before out of home work location choice, and can be thought of as a work from home model. Likely includes variables such as person type, gender, household composition, age, income, education, accessibility, etc. The model includes constants for calibration and what if analysis. What about a school from home model before the school location model? Seems relevant today.... | ||||||||||||||||||||
10 | 10 | Toll Transponder ownership model design, estimate, calibrate/validate | Person level toll transponder ownership model to better address road pricing policies and highway assignment results for tolled/priced corridors. Likely good data on this and this feature is in a few existing models. | ODOT: Just a future tech note. If we do this, we will wan to make it easy for the user to control this with future assumptions, like scenarios where everyone's vehicle has a toll transponder... such as VMT road usage charge replaces the gas tax nationwide... SFCTA: I know some regions like SANDAG have incorporated, but I have reservations about investing in this for the same reasons that Alex articulates. I think the idea that future roadway pricing will be constrained by whether someone has a toll transponder doesn't make sense. How could we be considering incorporating high-technology alternatives such as AVs (which don't yet exist in a form that would work throughout an entire regional transportation network) but then also assume that choices will be constrained by low-tech requirements such as whether someone has a toll transponder? Ohio: We decided that this has limited usefulness as anyone who is likely to be using toll facilities will have a transponder and see the lower fare. Hence, we've decided that everyone living in the region has a transponder and only a percentage of the IE and EE trips will see the higher tolls. Met Council: Our current model does have this. It was a relatively simple model to estimate and implement. It's a good point that this technology might become obsolete, but we can't be sure when, and it could be an important component of road pricing policy modeling for sometime . We agree that it should be flexible to handle future assumptions. As the technology that permits roadway pricing advances, it is possible that access to future devices might still limit some users. Could a transponder model also serve as a knob that could be updated to reflect future constraints for roadway pricing access? PSRC- Most of our future tolling involves a per mile road usage fee that everyone pays. We tried toll/non-toll user classes, but have since moved back to handling this in assignment only. MTC: Agree that is is likely that future scenarios may need to assume 100% toll responder/transit pass holder rates which limits usefulness of this. | Refinement | Additional Description - Purpose: Develop a toll transponder ownership model targeted to all agencies - Likely use the SANDAG model as the starting point - Assume calibration data already developed for MTC or borrow distributions from another region such as SANDAG? - Implement revisions - Reasonably calibrate/validate results and make adjustments as needed - Add tests and documentation | ||||||||||||||||||||
11 | 11 | Micromobility (e-scooters…) | 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. | 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. | Refinement | |||||||||||||||||||||
12 | 12 | University Student model | Generate a synthetic population of university students and run them through a series of travel demand models specific to students. ODOT has a couple university student models that make use of a university student travel survey. | SFCTA: To confirm, is this about unviersity students living on-campus / in GQ? Unviersity students living at home are already captured in the core models, and where appropriate the existing models are segmented to reflect unversity-specific choices (such as destination choice). If this is about GQ university student behavior, I think the default synthetic population for any Activitysim implementation should explicitly include university segment, and potenitally other non-institutional group quarters segments as well. Input data on university GQ is usually pretty easily available, althought survey data on GQ unviersity student travel behavior choices seems like it might be hard to find. SANDAG: we don't have a univ student model and have been considering adding one. The key challenge is we don't have a good estimate where univ students live (many live in GQs on campus, but many others don't). For example, many SDSU students live in North Park and Pacific Beach whch are two hot hip neighbourhoolds that not close to SDSD campus. Most of us have a sizable university populatioon in our regions? If so, this could be a feature benenfit many of us. MTC: Not a priority for us at this time. | Ancillary Models | |||||||||||||||||||||
13 | 13 | Disaggregate accessibilities | Use disaggeragate models to generate logsums, with a dummy synthetic population that covers all segments. Do this instead of creating a separate set of aggregate accessibility models that have a lot of duplication with the disaggregate models in order to save maintenance time and reduce opportunities for error. An example of this setup in activitysim is something like: - Run activitysim with a small intelligent synpop and then run the non-mandatory tour dest choice model to get the destination choice origin logsum and the destination choice sample destination mode choice logsums - User estimates accessibility models and decide what logsums output above to include in the model - The intelligent synpop activitysim run outputs are aggregated and then input to a real model run to get disaggregate accessibility measures (i.e. use disaggregate logsums) - The annotate land use step (or other model) can query the intelligent synpop activitysim outputs to get accessibilities | SFCTA: While this seems like a reasonable "under the hood" improvement in terms of better aligning logsums throughout the model, if I am not mis-understanding these logsums are disaggregate in generation and form, but not unqiue to the travelers in the actual synthetic population. This seems like the main benefit is increased consistency through the model internally. SEMCOG: Is this something similar like the logsum output of sampled destination RSG has developed for SEMCOG? MTC: We need this feature in order to compare accessibilities for benefit-costs analysis. | Accessibilities | Additional Description - Purpose: Add support for disaggregate accessibilities for more consistent models and easier maintenance, which benefits all agencies - The first task is to develop a design in cooperation with the PMC - Revise the existing example to produce either disaggregate accessibilities or aggregate accessibilities. Add a toggle to run either model. - The disaggregate model outputs are summarized into the same format, i.e. a zonal data input file, as the aggregate model outputs so no data structure revisions are required in downstream models - The workflow looks something like 1) run some of the activitysim models for the intelligent synpop sample, 2) aggregate results to zonal inputs, 3) run activitysim using the zonal accessibilities calculated earlier - Develop an example and revise downsteram models to use the new measures - Calibrate/validate the models as needed - Add tests and documentation | ||||||||||||||||||||
14 | 14 | Roadway Topography | Not sure what this is? ARC: This pertains to network coding related to road grade & roadway topography. Currently as you know, most MPOs and state regulatory agencies use the EPA MOVES model in conjunction with vehicle activity data from travel demand models to estimate transportation related emissions. However, the methodology is unable to capture the effect of roadway topography on emission inventories. There’s some research at Georgia Tech where they have developed a methodology that allows to account for road grade impacts in the analysis. The goal of their project is to evaluate the adequacy or inadequacy of current practices in evaluating the impacts of projects in light of the potential impacts of road grade, where road grade is obtained / extracted from the US Digital elevation model, and network links are segmented based on grade and number of lanes, amongst other elements. | Met Council: This seems more like a data issue- do networks incorporate topography? Is the data useful? PSRC- we caculate link uphill slope for our bike modell, but not sure this is in ActivitySim's domain. SFCTA: This is a "supply side" question first MTC: Not a priority for us. | Supply Models | |||||||||||||||||||||
15 | 15 | Standard Freight / Commerical Goods Movement model review and plan and scope | Model the commodity flows throughout the region. This can take several forms, including aggregate, disaggregate, trip-based, tour-based, FAF-based, agent-based, etc. Several DOTs and MPOs have freight models, including some disaggregate models. The disaggregate models tend to be custom / protype-type software and would benefit from a management plan such as the ActivitySim consortium. Developing and maintaining freight modeling components would likely require consensus around methods, which I'm not sure has happened yet in the industry. Just do a review and design plan since implementation is beyond phase resources | SFCTA: Freight and commercial travel typically represents 15%-20% of vehicle travel in most regions. This task would involve transferring an existing, demosntrated successful, disaggregate, tour-based commercial and freight vehicle model from another region and implementing in the Activitysim framework. While this task may be too ambitious, I think the idea of waiting for industry consensus around methods means never doing this, because such consensus is never achieved. Met Council- We'd love to see this PSRC- This would be welcomed addition. We are often asked to implement such a model, but so far it has proven too expensive. SEMCOG: We are currently developing a tour-based commercial and freight vehicle model (RSG as the contractor) in R language. which will be intergrated with the ABM. SANDAG: freight (heavy trucks) and commerical vehicle (amazon delivery and plumbers etc) not only is a significant travel market, but also have the potential to grow quickly. one thing we always wanted to do is to better account for online shopping (and maybe even restaurant delivery) and its impact on commerical vehicle trips. Because there is a dynmaic linkage between CVM trips and shopping and eating out trips in ABM, we should also properly model the linkage. We have been asked many time does our model reflect online shopping impact? Our answer is that it doesn't reflect the rapid online shopping growth in the past few years. The post covid19 may cause even more significant online shopping and restaurant delivery growth. I think this is a featrure may benefit many of us consider the current circumstances. MTC: Interesting... but seems like a different model completely? FreightSim? SEMCOG: SEMCOG's commercial vehilce model under development is designed to provide sensitivity to the impacts of anticipated changes in business operating practices such as increases in per employee productivity and changes in retailing to e-commerce. Ohio: Ohio's Disaggregate Commercial Vehicle Model (DCOM) was developed by Doug Hunt et al and originally implemented in Calgary. You might have seen presentations at TRB and Planning Apps in 2006/2007. Ohio's was presented at the 2007 Planning Apps, but it appears that the presentation is no longer linked. (I can send a copy of the slides upon request.) For certain businesses (industrial, wholesale, retail, transport and service), there is: worker traveler generation, vehicle assignment, and starting time assignment models. After a trip has started, every 5 minutes it pulls a random number to determine if that vehicle stays at its location or moves to a new location. If a new location, then it chooses the next stop purpose and its location. Purposes include: Goods, Service, Meeting, Other, and Back to Establishment. This was based of our (now old) Establishment Survey. This is a completely different model from the Passenger Model. | Ancillary Models | Additional Description - Purpose: Develop a plan for implementing a freight model targeted for all agencies - Review and summarize existing models in practices - Share and discuss review with PMC - Recommend and discuss a design for activitysim - Draft a work program for implementation in later phases | ||||||||||||||||||||
16 | 16 | Air passenger model design | Model additional travel markets such as airport trips, vistors, universities (see other item), freight (see other item), etc. This can take several forms, including aggregate, disaggregate, trip-based, tour-based, etc. Several DOTs and MPOs have additional demand models, including some disaggregate models. The disaggregate models tend to be custom / protype-type software and would benefit from a management plan such as the ActivitySim consortium. Developing and maintaining additional model components would likely require consensus around methods. Build a good starting point model for use in multiple regions (including regions with multiple airports) | ODOT: I wasn't thinking visitor with the term air passenage model. Maybe we should call this a visitor model / treatment. A visitor treatment would have a lot of value to ODOT. Maybe this is just written guidance on how to add visitors to a model as opposed to a model in itself. Example ODOT adds visitors by creating a special sub group of visitor added to the sythetic population. SFCTA: I think an important principle guiding Activitysim development should be that enhancements and features can be used by many / most / all the regions. Visitor models will almost by necessity will be region specific (eg. there's not a Golden Gate Bridge in the Atlanta region). To a lesser extent, the same may be true about airports (ie. airports may have very different time-of-day profiles based on region size, airport function (hub vs non-hub), etc). Met Council: Given the importance of regional airports on the surrounding transportation network, we're concerned that the ancillary models we have been using are too simplistic, and are interested in exploring if bringing into ActivitySim would improve how we model trips to airports. If tying into a visitor model proves too region-specific, we'd advocate for looking to see if there are enough commalities to still pursue an ActivitySim airport model. SANDAG: We have both airpassenger and visitor models. We are considering a GrandCentral hub with potential people mover built to link between the hub and the airport. Our existing airport model has been used in the GrandCentrl project evaluation. It would be nice to have a 'common' airport model that is expandable to allow regional specifics to be added. MTC: Interested in learning more about the options. Ohio: I'm unclear whether this is a special generator model or part of the visitor model. I put comments in the visitor model item. | Ancillary Models | Most regions have least one large airport and would benefit from a disaggregate air passenger trip prediction model. An auxiliary airport model should be flexible enough to accommodate different regions. The auxiliary model design should be integrated with the ActivitySim model and contain feedback between the airport model and ActivitySim between iterations .Airport Model characteristics: • A disaggregate air passenger trip prediction model. • A design that includes components for use in multiple regions (including regions with multiple airports). • A model that is flexible enough to allow regional specific plug-ins: such as mode, time of day, parking, and air passenger travel markets (e.g. business vs residents). Recommended core components: • A trip enumeration model using enplanement input • A trip location choice model. • A mode choice mode that has airport specific modes, such as rental car, TNC, hotel shuttle, parking lot shuttle, etc. • A time of day (or peak, off-peak) choice model (after discussion -- trip times might be better handled as exogenous input based on information such as flight schedules) Possible airport model inputs: • Enplanement excluding transferring passengers • Air passenger characteristics such as distributions for trip enumerations by purpose. household income, and travel party size etc. • Zonal characteristics: population and employment (by type). This data provides sensitivity to land-use forecasts. • Skim data: o Transit, auto, and non-motorized skims o Airport specific skims such as travel time, distance, and cost from parking lots, rental car centers, and people mover hub to airport terminals. o TNC related metrics such as cost and wait time Maybe a task to inventory data available among partners; Maybe use SANDAG as the example because it has an existing airport model and data? | ||||||||||||||||||||
17 | 17 | Transit Pass ownership model in cooperation with SEMCOG | Person level transit pass ownership model to better address parking and transit fare policies. Similar to other mobility models such as auto ownership, telecommute, free parking, etc. Likely good data on this and this feature is in a few existing models. Planned for SEMCOG model. | SFCTA: Daysim incorporates a transit pass model. Also, transit pass provision may be an important policy level to address equity concerns of roadway pricing projects. This is relatively low hanging fruit, and we have data to either transfer or estimate models. Met Council: Met Council's current model has a transit pass ownership model. The ability to estimate is dependent on having survey data that asks about pass ownership. Important for understanding non-work transit markets PSRC- Agree- nice to have and straightforward to implement. SANDAG: we have been discussing adding a transit pass ownership model for a while. it would be nice to have it as part of asim. MTC: Interested in developing this. MWCOG: In the metropolitan Washington area, a large share of workers (especially those in the federal government) receive a monthly transit subsidy. The one for WMATA is known as SmartBenefits. It would be great to track workers who have a transit subsidy versus those who do not. | Refinement | Additional Description - Purpose: Develop a transit pass ownership model targeted to all agencies - Assume SEMCOG project develops a SEMCOG transit pass model - Twice discuss design and coordination with SEMCOG project team - Implement an activitysim example version of the SEMCOG example/design - PMC provide estimate/validation data - Reasonably estimate/calibrate/validate results and make adjustments as needed. For example, revise downstream models to use this new variable. - Add tests and documentation Likely design: runs at the person level - after school/work location and auto ownership so these variables can be used - and is likely segmented by key variables such as person type, income, gender, age, accessibility, etc. | ||||||||||||||||||||
18 | 18 | ITHIM intergration | Integration with ITHIM, a public health active transportation cost benefit analysis toolkit. http://www.mrc-epid.cam.ac.uk/research/research-areas/public-health-modelling/ithim/. Similar ideas were integrated into the bca4abm toolkit using World Health Organization research. | SANDAG: we looked into ITHIM. I think we need to have further proof the methodology used in IHTIM is sound, espeically the statistics between travel metrics and health metrics. Addtionally, if we are to link to a specefict product/tool, is there a concensus that the tool is the industry standard? SFCTA: ITHIM appears to be too aggregate for many of our analysis needs MTC: We wrote scripts to process output for ITHIM last cycle. It was a straightforward exercise but at the time, ITHIM was a spreadsheet and Neil Maizlish worked on the spreadsheet model for us. I think this would only be worth doing when ITHIM moves to something easier to automate (a library or module) and enough agencies have interest. | Accessibilities | |||||||||||||||||||||
19 | 19 | Open source traffic and transit assignment | This feature would be to develop and maintain highway and transit assignment / routing and skimming procedures for use with activity-based models. Important considerations include: - ease-of-use - stability - methods/algorithms - performance (runtime) - features (turn restrictions, transit schedules, etc.) - documentation - user interface for network editing and mapping - select link, zone, line? type analysis - user support - etc There is interest in integrating with an existing open source project as well such as matsim (https://www.matsim.org/), AequilibraE (http://www.aequilibrae.com), fast trips(http://fast-trips.mtc.ca.gov/), etc. | SFCTA: This would be an incredible extension of the ActivitySim package, but is probably too ambitious for next scope MTC: This is as big of a project as ActivitySim -- probably bigger because of UI needs. Integrating with other open source versions could be interesting if they serve the needs of partners, but evaluating that would be a first step. In general, I think this is out of scope. ODOT: Just a note from Oregon's history. We have done this and succeeded with Oregon's statewide model. We failed in that we found that the real benefit of traffice assignment software is the visualization, analysis, and data management tasks - not simply assignment and matrix manipulation. So what makes this so ~impossible is that you need a usable GUI and network editing / spaitial interface... Not the assignment piece... | Supply Models | |||||||||||||||||||||
20 | 20 | Park location choice | - Capacity constrained CBD parking location choice model. Add a stop/trip-level CBD parking location choice model, which is run after destination, time-of-day, and mode. The existing free parking eligibility model uses household and person level information to identify free parking at work by person. The existing TM1 CBD parking location model only runs if the stop destination choice is in user specified CBD zones. The utility of each potential parking zone is based on network skim data and parking costs. Unlike some other parking location models, the TM1 CBD parking location model is not iteratively shadow priced by comparing trips to capacities. The procedure can be iterated, but it increases runtime. - There is also a more comprehensive parking location choice model in DaySim that has been implemented by SFCTA that would inform this task. - Developing and maintaining the detailed input data for these models can be a big lift, especially for future scenarios. | SFCTA: This seems related to parking supply/capacity and pay for parking models referenced earlier ODOT: Agree with JC, it would be nice if similar ideas could be adjacent (maybe idea X.a and X.b) MTC: See comments for 4 "Parking capacity (supply) modeling" | Parking | |||||||||||||||||||||
21 | 21 | Visualization of Results | Related to the activitysim QC visualization feature, out-of-the-box components to (automatically) visualize model results would be quite useful to model users, developers, and consuming of our work in general. As the ActivitySim platform continues to mature and the user base grows, features like this will likely become increasingly important. The visualization software could be Python code or it could be a third party program such as one of the data visualization tools on the market or in the open source community. ActivitySim could include the ability to export data and reports in visualization-ready form. Related, a cloud-based version of activitysim would almost certainly require a reporting/visualization interface. | SANDAG: SFCTA has done good visulation work using model results, can we build on top of what Joe has done? Addtionally, I think this is realted to the data model item 39. It would be great feature benefit all of us. MTC: Interested in examples, technology options. (We have been using Tableau to quickly explore output but it's not free.) | Reporting & Visualization | |||||||||||||||||||||
22 | 22 | PopulationSim QC visualization | Redo the R validation script included with the example as a Python / Jupyter notebook. Include a new report model step as part of a run if desired. The benefit of this feature is to include built-in automated QA/QC procedures for improved usability. https://github.com/ActivitySim/populationsim/issues/92 | Met Council: the R validation scripts have been useful to the Met Council in comparing PopulationSIm to our previous population synthesizer. It might be interesting to explore if adding some additional visualizations might be useful, e.g. allowing users to set criteria for highlighting TAZs and markets segments that don't meet certain control total thresholds. Also interested in tools that might help users evaluate how one sythetic population scenario dffers from another to gain insight into model senstivity to demographic inputs. SANDAG: this relies on a data model as described in item 39? SEMCOG: We rewrote this R validation script in Jupyter notebook in order for us to compare the performance of SEMCOG's Synthpop and PopulationSim. | Reporting & Visualization (significantly complete) | |||||||||||||||||||||
23 | 23 | ActivitySim QC visualization | Several ad hoc reporting, validation, and testing scripts in Python and R have been developed to validate, verify, and debug ActivitySim model results. It would be good to build an ActivitySim QA/QC/reporting framework that is included with the software and can be used by users and developers. This would likely take the form of Python software with support for creating data summaries, maps, charts, etc. as well. With a framework in place, the model builder could implement several QA checks to ensure the model is behaving as expected. As the ActivitySim platform continues to mature and the user base grows, features like this will likely become increasingly important. | ODOT: When ODOT took this on for the Oregon ABM, the intial value was a visualizer (HTML) that did all the comparison of the model to the calibration target data. The idea was that the target data was processed to look just like ABM output, then the visualizer was pointed to both the target dataset and the ABM dataset to do the comparison. This allowed ODOT to have the full set of calibration comparisons instantly at the end of each ABM run. Then after the calibration was completed, ODOT had a visualizer that allowed each future scenario to be compared to other reference ABM runs to quickly understand how the scenarios were different. I recommend that this be approach that way - as an automated calibration visualizer that is than directly usable as a scenario to scenario visualizer. SANDAG: I think this is a very useful feature. A few of the visualization, QAQC, and data modeling items on the list can be comined to form a common data modeling/visulization/reporting/QAQC platform. MTC: Sounds interesting but similar to 21, interested in examples, technology options. | Reporting & Visualization | |||||||||||||||||||||
24 | 24 | ActivitySim input checking and error handling | Make it easier and less error prone to setup a new regional model implementation or scenario. When reading in inputs, the software will perform a series of validation checks such as: - Each person belongs to a household, each household belongs to a microzone or zone, and each microzone belongs to a zone if applicable - Each expression file is well formed and there are no formatting or syntax errors - Each yaml file is well formed and there are no formatting or syntax errors - All attributes referenced in expressions are in the input table or skims ODOT has an input checker for its CT-RAMP model that is quite handy. The input checker library of checks continues to grow, similar to how a test system continues to expand its test coverage. | ODOT: The checks to be completed is an input (configuration file), so all partners could share the checker code, but each partner could still configure their own specific checks (and easily share inbetween given the same approach / format). PSRC- When developing Soudcast/Daysim, most of our issues early on were the result of data input errors. I think this would be useful for the estimation data/inputs as well. SANDAG: good idea. We are adding an input checker (following ODOT's example?). This is like an input QAQC, which could be part of the data modeling/reporting/visulization/QAQC platform? MTC: Yes, please. Seems like it should run at the start of the model but also be easy to run stand-alone. | Refinement | Additional Description - Purpose: Make it easier to stand up a new activitysim model, which will benefit all agencies - Add checking of input data, such as each HH belongs to a zone, each zone can get the network, etc - Add checking of expression formatting - Add checking of settings formatting - Add more error handling and smarter messages, logging, etc. - Add functionality for when no alternative is found to try and figure out why, such as which terms in the utility turn off all alternatives? - Brainstorm list of improvements with PMC - Implement improvements in priority order as budget allows - Add tests and documentation | ||||||||||||||||||||
25 | 25 | Model calibration - partial automation | Develop software to automatically run the model, compare select sub-model results to expected values, and intelligently automatically adjust alternative specific constants based on the differences. For example, run trip mode choice, summarize trips by mode, compare trips by mode to the surveyed trips by mode, and adjust the mode specific constants based on the log of the difference ratio * a dampening factor. Repeat the procedure until difference is minimized and respect min and max adjustment constraints. This has been done before for simpler trip-based models and could be done for ABMs. This feature needs to be used with caution and would require design related to how to specify tracked and expected outputs for each sub-model. | ODOT: might consider tying this idea to 23. They are different, but if we were going to take both of them on, we would want these to be aware of one another. Example, both 25 and 23 should assume that the user has processed the target data into the correct format. Both 23 and 25 should use the same format, which should be activitySim output format. PSRC- Alex, I agree that there is a tie in between the two. If we did both, the visualizer could be used to monitor changes/improvements during the calibration process. But I go back and forth on whether we need a heavy duty visualizer or if we should just use something like Jupyter Notebooks for standard summaries.. SANDAG: good idea. For example, we are asked to test telework with a predefiend telework rate. The automated calibration process could be a very handy feature for any assumption-based scenario testing. SFCTA: Autocalibration makes me nervous. While there are some clear use cases where risks are low (such as Wu's example of calibrate to an exogenous asserted telework share), most use cases will be calibrating component models, and I think there's a high risk of generating unreasonable results if calibration process is not carefully managed. MTC: Sounds worthwhile to implement for a low-risk submodel as a pilot. | Refinement | The purpose of this work element is to develop either a stand-alone software tool or an integrated ActivitySim core capability, that provides the ability to automate the calibration of selected model coefficients and alternative specific constants. This capability must be able to run user selected model components and compare estimated results with the observed (or expected / asserted) values and mathematically adjust one or more parameters and/or alternative specific constants. This capability not intended to replace the value and central importance of more detailed examinations and comparisons between observed and estimated values. Rather, it is to provide a more efficient method for reaching the point where these more detailed comparisons can be made and a wide range of solutions considered where the model under development fails to achieve an acceptable level of calibration. This feature should have the ability to address the entire scope of ActivitySim model component types and component type elements. For example, the feature should be able to address basic calibration use cases where model system component calibration typically involves adjusting one or more alternative specific constants, such as for the auto ownership model, as well as more complex calibration use cases such as where calibration involves adjusting distance polynomial terms in a destination choice model. The features should provide clear, user-friendly summary statistics and displays, including comparative summaries of observed and estimated values (shares or absolute values) for each alternative specific constant in both tabular and graphic forms, by iteration, allowing the user to determine if the value of the constant displays a monotonic pattern or oscillates across the iterations Plan to design and implement for two different types of models: 1) an alternative specific constants model such as auto ownership and 2) a distances terms model such as work location choice. See MTC's specification for more detail. | ||||||||||||||||||||
26 | 26 | Recipe book chapters | Continue to add recipes to our recipe book. Each recipe could focus on a modeling scenario, new feature development, QA/QC, reporting, etc. Maybe plan to add 2 or 3 in each phase of work? | Usability | ||||||||||||||||||||||
27 | 27 | PopulationSim threading | Add parallelization to PopulationSim in order to significantly improve runtimes in the case of multiple seed geographies. The planned parallelization strategy is to use Python’s multiprocessing library to process each seed geography, which is typically a Census PUMA, using a separate processor. | Usability | ||||||||||||||||||||||
28 | 28 | Visitor travel demand model | Some regions have a significant amount of visitor travel. In these regions, there may be value in explicitly representing the travel of visitors, who have quite different behavior than regional residents in terms of trip purpose, travel party size, mode of travel, and value of time. However, visitor travel markets may be quite unique to each individual region, and the data required to build explicit models of traveler behavior is usually quite limited. Ideally, any treatment of visitor model should parallel the disaggregate representation of regional resident travel. | ODOT: this should be linked with the air passenger model concept. MTC: See 16 Ohio: 3 types of visitors should be accommodated: People who travel to the region and stay, People who started their day in the region and left, and people who came into the region and left all in the same day (see item 3). For the first 2, they should end/begin their day at either a hotel or a residence and should begin/end their day at an external or an airport. Visitors should be separated by purpose: business, leisure, medical, and possibly others (see Ohio's LDT survey). They can then be added as a separate list of HHs that are run through the DAP model. Business travelers have an assigned work location and have a mandatory activity pattern. Leisure travelers have a non-mandatory pattern. Destination choice models should have binomial fields in them to attract leisure travelers to special generators (e.g. GGB), and to generate more eating out tours (especially if their "home zone" is a hotel). | Ancillary Models | |||||||||||||||||||||
29 | 29 | Reading multiple OMX skim files | This feature means adding support for the user to be able to specify multiple skim files instead of one big skim file. Since network models typically write several separate skim files, this could make integration easier. This is similar to the DaySim roster and matrix page in the UECs. | SANDAG: agree, and it doesn't seem like a huge effort. | Refinement | Add to maintenance and support under potential improvements based on GitHub issues list | ||||||||||||||||||||
30 | 30 | Time of day modeling restructuring | - Implement the DaySim method of first modeling arrival and departure time at primary activity, then work outwards for intermediate stops, rather than the CT-RAMP method of departure time from home and arrival time back at home, then filling in details. Make more sense and makes handling of time easier. - Intermediate stop enhancements. CT-RAMP (and therefore ActivitySim to-date) uses simple probability lookups for intermediate stop purpose and duration. The former can lead to simulation errors when certain activities aren’t available on non-motorized and/or transit tours. The latter makes stop departure time less sensitive to congestion and very challenging to calibrate. Suggest implementing a smarter model-based representation of stop frequency and purpose and replacing the stop departure time lookup table with a probabilistic model. Similarily, possibly implement the ARC CT-RAMP stop departure time choice model instead of simple lookup table. | SANDAG: agree the enhancement on intermediate stop purpose and time of day choice. The lack of logics built in stop level purpose and time of day choice could lead to model failures and unreasoanble results. MTC: Should also consider CTRAMP2 in addition to DaySim. This would likely be a significant investment of time and resources. Ben: having a good example to test and program against, such as an existing DaySim model(partially) converted, would be super helpful. Some of the trip models process trip on tours in a certain order, have expressions that know things like "first trip inbound", "last trip outbound", etc. that will need to be reviewed and potentially updated. | Refinement | The purpose of this task is to implement a set of changes to the ActivitySim model components to improve the tour scheduling, and intermediate stop frequency and scheduling models. Anticipated changes include implementing a DaySim-style of building tours, from the main activity outwards with recursive stop generation, stop location, trip mode and trip scheduling. In addition, it is desired to transition the trip scheduling models from using fixed distributions to models that are more sensitive to congestion and other effects. It is also desired that the revised model produce reasonable time of day estimates to a minute-level of resolution, to facilitate integration with dynamic traffic assignment tools. This task will first involve working with the partner agencies to inventory and prioritize the complete set of desired improved sensitivities. Subsequently, a set of model modifications necessary to achieve the improved performance will be identified and an updated overall model design will be proposed. To the extent possible, this design will propose methods that have been demonstrated to be practically feasible to implement and which provide appropriate sensitivities. It is anticipated that modifications will likely involve restructuring and respecifying the following models, at minimum: - Mandatory Tour Scheduling - Joint Tour Scheduling - Non-Mandatory Tour Scheduling - Intermediate Stop Purpose and Frequency - Trip Scheduling In addition, Trip Destination, Trip Mode Choice and other component models may also be revised to ensure consistency with the modifications made to other model components. After approval of updated model design, the modifications to the model components will be implemented, model components will be reestimated and calibrated, and the overall model system recalibrated to ensure results reasonably consistent with both observed travel behavior survey data and prior model outputs. Updates to the travel behavior survey data processing may be necessary to support model estimation and calibration, and a set of systematic sensitivity test will be performed to demonstrate the modifed model system is producing resonable results. Finally, particular attention will also be paid to identify and resolve simulation errors when certain activities aren’t available due to available time window and modal constraints. | ||||||||||||||||||||
31 | 31 | Multiple Models Management System | To develop a system for ensuring cooperative management of the shared AB modeling software platform, ActivitySim. When a contribution (i.e. pull request) to ActivitySim is made, the system runs registered models against the code to ensure revisions are desired. Registered models include registered test models and expected results in the core repository, as well as registered test models and expected results in partner repositories. This is included in consortium membership. https://github.com/ActivitySim/activitysim/wiki/Multiple-Models-Management-System | PSRC- we are very happy with how this is implemented for Daysim. It is easier to stay current with the latest version of the software when you are confident it is not going to crash or give different results. | Management | Additional Description - Purpose: Expand the test coverage for activitysim to incorporate all partner models in addition to the existing example. - Develop a plan for the system - Revise the test system to run a couple agency models for now, such as SEMCOG and ARC? - Note this means changes to the codebase may require fixing these regional models as well - Should include reality/regression testing/summaries to QA/QC changes so this overlaps with reporting task - Better define and support versions/releases and compatibility for existing users - Document for developers, contributors, and agency members | ||||||||||||||||||||
32 | 32 | Vehicle types model (Household-level) | Do a better job of estimating household vehicle types. ODOT’s hope is to be able to assign specific operating costs to the vehicles that a household has access to (like different per mile costs for EV vs ICE), and also to better track emissions, by understanding vehicle type and use. This ties nicely with thevehicle tracking and fleet modeling / behavior feature. This could include household AV ownership as well. | ODOT: as is noted in the description - can we move this so it's next to item 1 (they could be considered as a package potentially). SANDAG: i think this is a feature could benefit many of us. I know both SANDAG and MTC have to account for GHG for SB375 analysis. If other regions have similar GHG accouting need, then the vehicle type choice model could be a feature benefit many of us. Additionally, it would beneficial to add vehicle purchase cost as part of the vehicle type model? The cost for EV and AV could be quite different from a regular vehicle. MTC: How does this differ from "Vehicle tracking and fleet behavior - HH level implementation" ? CTRAMP-2 (as we understand it) tracks household vehicles so that those vehicles (HV and AV) explicitly service household member trips, and a consistent household vehicle trip list is also output. This concept seems interesting but it would be helpful to understand a quantification of how this improves modeling results and what the runtime cost would be. It would be nice to include flexibility on how vehicle types are represented so users don't have to forecast EV usage but still take advantage of HV vs AV vehicle types here. | Vehicle Modeling | End Product - The final product would look something like a "vehicle" table returned from a household survey. This would be a seperate table with a household ID and a vehicle ID for each vehicle in the household. The user would have some ability to specify which descriptive variables were available in the end product - Vehicle table. Specifically, the task needs to focus on providing a final vehicle table that provides information on vehicle operating costs and emission rates so that more refined information can be known about the per mile costs to operate vehicles for Household X, and the levels of emissions that would be generated (per mile) by household X. A required feature is the ability to run fleet (vehicle) future scenarios, not just forecast a future fleet based on the estimated model. Therefore a critical design element is the ability to easily re-calibrate the model to achieve certain percentages of features like EV or efficeny in the fleet. This needs to be designed as an easily adjustable input or feature of the final model. Related, the design should allow for the user to provide a vehicle table developed outside of ActivitySim as an input for downstream models - similar to how a household and person table are provided. The option being that a user could comment out the vehicle types model in the run string, but provide the expected output format of the model and have the model sequence work with the vehicle table as an input as have activitySim work without a starting vehicle table, but running the vehicle types model instead to generate the vehicle table. This gives the user full flexibility on how to approach running scenarios around future fleets. Additionally, while this build does not need to estimate AV types and car share/ownership, it needs to anticipate that those scenarios will be features added to ActivitySim, so it needs to be constructed in a way that will allow for that continued development of identifying which households have new tech and new attitudes towards ownership. Approach - Household and environment characteristics would be used to calculate the number of drivers, and the number of vehicles that the household was estimated to own. The significant work in this task is determing the best way use household and environment detail to predict vehicle attributes. A good start at thoughts towards this effort is captured in the VisionEval approach - https://github.com/VisionEval/VisionEval-Dev/tree/development/sources/modules/VEHouseholdVehicles/inst/module_docs. Which approaches this problem with the following steps AssignDrivers AssignVehicleOwnership AssignVehicleType CreateVehicleTable AssignVehicleAge CalculateVehicleOwnCost AdjustVehicleOwnership In the end, it may not be critical to track vehicle type and age. Those are just ways to help explain future fleets and the charaterisics of cost to operate and emission rates for future fleets. Some ideas around what current vehicle features (independent varriables) could be used to predict vehicle characteristics (dependent varriables) are: Vehicle Type (like auto and light truck chassis) Vehicle Capacity (number of people in the vehicle) Power Train Type (ICE / EV) Vehicle age, or something about vehicle efficency (high / low) The user will need to ability to specify the operating costs, efficiency, and other aspects for every dimension in the table or list of vehicle features, example - MPGs for an 5 person, auto, ICE, high efficiency Related, this work may not be able to fully build in ownership / shared representation, but the work should be aware that this would be the next step/phase of the work. The vehicle table / representation will utlimately need to be able to handle whether the household foregoes vehicle ownership because of access to subscription ownership. Again, this might not be possible in this first phase of the work, but the work needs to be aware and create a solution that would allow for this type of representation in future iterations. At some point several years from now, the vehicle table should be able to specify what options a household has access to, and may even go so far as to indicate micro-mobility options, such as electric bikes... | ||||||||||||||||||||
33 | 33 | Bike comfort / level-of-stress person labeling - AB deleting from the Ranking | No longer assume that the whole population is willing to bike on any available link in the network (that is open to biking). Likely involves a fair amount of supply / network side thinking first, as well as a reasonably rich set of observed data. | ODOT - 9-2-21 - quick note, I think this is mine (Alex) and I agree that it's more an estimation thing and not a code development thing, so I good with deleteing. ODOT: If I could build support for this - I don't think it needs to be all in one shot. I think the first step is getting the idea on peoples radar and then in surveys. So I think the first piece is to have a collobrative development of a method of tagging the Syn Populace with a designation of biking comfort. From their (getting it in modelers faces), we could then build questions into surveys and build up the understanding (data) for how different types of bikers make different path decisions. SANDAG: can we add constraints/penalties in mode choice to discourage biking for certain sub groups in the existing popsyn? | Supply Models | |||||||||||||||||||||
34 | 34 | Maintenance and support | General maintenance and support of activitysim, populationsim, the website, etc. Includes keeping up to date with changes in dependent packages, using new features in pandas/numpy/python, documentation/example/test updates, supporting users, reviewing pull requests, etc. | Management | Additional Description - Purpose: Make ActivitySim a really great tool to use for all agencies - Deal with dependent package updates - Maintain test system, example, and documentation. Revisions to the code base often require a test example for verification / proof and this needs to be included in each commit. Management and expansion of the test coverage ensures good quality software. - Assist with pull requests - Make improvements based on user feedback, both to the software and documentation. For example, making improvements based on the SEMCOG project. - Support new users with issues setting up the model, such as the SECOG project. - Implement GitHub issue fxies such as support for multiple skim files | |||||||||||||||||||||
35 | 35 | Complete estimation mode for trip models | Fully implement estimation mode for all submodels. Seem like we are going to get close in phase 5, but may not be totally complete. | Refinement | Additional Description - Purpose: Finish estimation integration which is targeted to all agencies - Create and clean-up example survey files for trips - Add trip models to infer module - Implement estimators for trip models - Implement a larch estimation notebook for trip destination and mode choice - Add tests and documentation - Additional tidying up of estimation integration as budget allows | |||||||||||||||||||||
36 | 36 | Leaner and improved ActivitySim Pipeline | There seems to be room for improvement and use of the ActivitySim pipeline. The primary goal of this task would be to substantially reduce the disk space taken with an ActivitySim run, via reducing the size of the pipeline. One key suggested way to get at this would be to reduce/remove duplicated fields and identical information stored throughout the pipeline. A secondary aspect to this task would be to simplify the design and understanding of the pipeline, to improve the logic for how unique informaiton is stored and to make accessing informaiton from the pipeline easy and intituive. | SANDAG: agreed. Maybe we can think about a data model with storage, effective querying, visualization, reporting and QAQC in mind (see item 39). | Refinement | Partially complete since you can now optionally not save intermediate results to the pipeline for each submodel step. Additional pipeline oriented improvements can be incorporated into the reporting task. | ||||||||||||||||||||
37 | 38 | Improve data model to effectively storage, querying, visualizing, and QAQC core ABM inputs and outputs | Develop a simple data model that allow effectively storage, querying, visualizing, and QAQC core ABM inputs and outputs. The data model should be expandable to allow each agency adding in regional specific inputs and outputs | SANDAG: since most of us can't use ABM resutls as is, a simple data model would make reporting performance metric more efficient. also, it will make QAQC a lot easier, helping us to discover potential holes in ABM. | Refinement | |||||||||||||||||||||
38 | 39 | Cloud deployment | Run activitysim in the cloud with a nice web-based UI, including setup, inputs, outputs/reporting | Usability | ||||||||||||||||||||||
39 | 40 | Performance enhancements | Enhancements to improve runtimes and lower memory usage for multiprocessing. Investigation of optimal default configurations given computing environment | Usability | Additional Description - Purpose: Continued performance enhancements targeted to all agencies - Profile to identify low hanging fruit performance issues - py3 multiprocessing improvements - Likely issues related to string management - Likely improvements to multiply zone system related performance issues - Likely chunksize autocalculation - Implement and test improvements, including potential revisions to example inputs - Add tests and documentation | |||||||||||||||||||||
40 | 41 | Visualization (just reporting) | Implement tools for the reporting and visualization of ActivitySim and PopSim inputs and outputs. The tools are to assist with model development, refinementapplication, and may include standardized tabular summaries, charts, and interactive maps. The tools will be easy to maintain and deploy by all partner agencies. This task will include identifying the core capabilities required, inventorying existing examples, tools and technologies, considering implciation and revisions to the ActivitySim data model and iteratively implementing and refining the reporting and visualization capabilities with guidance from the AMPO partners. | Met Council: the R validation scripts have been useful to the Met Council in comparing PopulationSIm to our previous population synthesizer. It might be interesting to explore if adding some additional visualizations might be useful, e.g. allowing users to set criteria for highlighting TAZs and markets segments that don't meet certain control total thresholds. Also interested in tools that might help users evaluate how one sythetic population scenario dffers from another to gain insight into model senstivity to demographic inputs. SANDAG: this relies on a data model as described in item 39? SEMCOG: We rewrote this R validation script in Jupyter notebook in order for us to compare the performance of SEMCOG's Synthpop and PopulationSim. SANDAG: SFCTA has done good visulation work using model results, can we build on top of what Joe has done? Addtionally, I think this is realted to the data model item 39. It would be great feature benefit all of us. MTC: Interested in examples, technology options. (We have been using Tableau to quickly explore output but it's not free.) ODOT: When ODOT took this on for the Oregon ABM, the intial value was a visualizer (HTML) that did all the comparison of the model to the calibration target data. The idea was that the target data was processed to look just like ABM output, then the visualizer was pointed to both the target dataset and the ABM dataset to do the comparison. This allowed ODOT to have the full set of calibration comparisons instantly at the end of each ABM run. Then after the calibration was completed, ODOT had a visualizer that allowed each future scenario to be compared to other reference ABM runs to quickly understand how the scenarios were different. I recommend that this be approach that way - as an automated calibration visualizer that is than directly usable as a scenario to scenario visualizer. SANDAG: I think this is a very useful feature. A few of the visualization, QAQC, and data modeling items on the list can be comined to form a common data modeling/visulization/reporting/QAQC platform. MTC: Sounds interesting but similar to 21, interested in examples, technology options. SANDAG: since most of us can't use ABM resutls as is, a simple data model would make reporting performance metric more efficient. also, it will make QAQC a lot easier, helping us to discover potential holes in ABM. | Refinement | Objective: • Design and implement a pipeline to improve data organization for streamlined visualization, input and output QAQC, and storage efficiency. Principles: • Develop a conceptual representation of relationships, associations and rules of data tables in the pipeline for a core ActivitySim model. • Ensure consistency in naming conventions, default values, and semantics. • Make certain that data in the pipeline are represented accurately and concisely; avoid redundancy of data in the pipeline. • Avoid hard coded magic numbers in the software; use definition tables to represent key model dimensions, such as trip and tour mode, time of day, simulation time slice, trip/tour purpose, market segmentation, and thresholds. • Define relational tables, primary and foreign keys to allow establishing efficient linkage between tables. For example, tour and trip tables, individual and join trip tables, etc. • Develop procedures to extract and transform model input and output data in the pipeline for standard visualization and QAQC, • Consider flexibility of pipeline design to allow regional specific implementations. | ||||||||||||||||||||
41 | 1A | Vehicle tracking (Household-level) design and scope | HH level implementation: where the vehicles owned / available to a HH are tracked in time and space based on the choices made by HH members | ODOT: can we link with item 32 (bring vehicle type modeling adjacent to this). SFCTA: I can envision vehicle tracking (if at HH level) as tied models of vehicle allocation choice/priority and reflecting joint travel choices, but not necessarily tied to vehicle type, unless certain types of vehicles have constraints on distance, number of drivers+passengers, etc. The vehicle type modeling sounds like its more about propulsion technology, and perhaps operating costs MTC: See comment for "Household vehicle types model". SANDAG: For HH level implementation, the treatemetn of human driven vehicles and AVs are different; this covers both HVs and AVs? Also, is vehicle allocation/tracing in the demand model or in a post processing step after trip lists are generated? SANDAG has a simple AV allocation post processing procedure that allows tracing zombie AV VMT. B) for fleet level implementation, is it a TNC fleet allcocation/optimization procedure similar to Uber/Lyft routing algorithm? Is it in the demand modeling or in the post processing? SANDAG has a simple TNC routing procedrue as a post demand modeling step using a simplified rule-based Lyft Line algorithm. Ohio: Note that this is not trivial. | Vehicle Modeling | The purpose of this task is to explicitly represent household vehicles in the ActivitySim modeling system. Representation of household vehicles means that each vehicle available to every household is explicitly identified and its location in time and space tracked, in a manner consistent with the household activity generation, mode choices, location choices and time-of-day choices. Explicit representation of household vehicles will improve the model system’s realism by reflecting logical real-world constraints and tradeoffs, improve the consistency and coherence of choices across model subcomponents and final outcomes, and improve and extend model system reporting. In addition, an explicit representation of household vehicle allocation and tracking will provide a foundation for subsequent efforts to represent and estimate the effects of future autonomous vehicles, although AVs will not be addressed as part of this scope. It is expected that a significant share of all the existing model system components will be affected by the explicit representation of household vehicles, and the critical first step will be the preparation of a detailed design document to guide model system development. This design document will exhaustively review all model system components to identify where household vehicle availability in time and space as well as vehicle attributes will constrain or influence travel choices. Some of the choices “upstream” in the model system sequence may simply be influenced by vehicle availability such as at the joint activity generation level, while other choices further “downstream” in the model system may impose explicit constraints, such as on trip mode choice. For each model system component potentially affected by the explicit representation of household vehicle allocation, the design document will propose specific modifications to the model specifications and data structures. In coordination with the development of the design document, available household travel diary data will be reviewed to assess the completeness and sufficiency of this observed data to support subsequent model development. Critically, because of the potential broad extent of the models impacted by household vehicle tracking, and because many of these changes will involve both restructuring and re-estimating model system components and data structures, the design document will propose a phased multi-year implementation approach. In the initial phase to be performed as part of the ActivitySim Phase 6 scope, it is anticipated that household vehicles will be "loosely tracked", meaning that simple allocation methods will be implemented to track vehicles in time and space, but that the existing model component specifications and available alternative constraints will not be significantly modified and will not impose hard constraints. This effort may also be coordinated with other Phase 6 scope items, such as the vehicle type model development, and the improved escort model development. | ||||||||||||||||||||
42 | 1B | Vehicle tracking (Fleet-level) design and scope | Vehicles owned / managed as fleets would be tracked in time and space, including how vehicles respond to trip requests, deadheading, etc | MTC: The fleet level implementation sounds very interesting and very relevant to TNCs; It would be helpful to learn more about the usefulness of the SANDAG feature vs the runtime cost, and if the results are consistent (or could be made consistent) with ride-hailing wait times. SANDAG: For fleet level implementation, is it a TNC fleet allcocation/optimization procedure similar to Uber/Lyft routing algorithm? Is it in the demand modeling or in the post processing? SANDAG has a simple TNC routing procedrue as a post demand modeling step using a simplified rule-based Lyft Line algorithm. | ||||||||||||||||||||||
43 | COMBINED TASKS BELOW INTO A SINGLE VISUALIZATION TASK | |||||||||||||||||||||||||
44 | ||||||||||||||||||||||||||
45 | 42 | Estimation Mode Refinement | The current Estimation Mode features of ActivitySim are very much built in the spirit of similar functionality in DaySim: updated observed (survey) data can be fed into the process, and the combination of ActivitySim and Larch can work together somewhat automatically to generate updated parameter estimates. The tools that have been built allow Larch to construct a model that exactly mirrors the defined model in ActivitySim, re-estimate model parameters, and output ActivitySim coefficient files with new parameter estimates that can be used as a drop-in replacement for the existing coefficient files. However, this tight integration breaks down when the user wants to update not only the coefficient values but also the functional form of utility equations. This leaves the user with two choices: (a) returning to ActivitySim for every tiny change to the specification files and re-running the entire estimation mode process, or (b) editing the utility equations in Larch while exploring different functional forms, and then needing to reconstruct matching specification files later in ActivitySim once the desired function form is selected. The former solution is tedious and slow, while the latter solution is error prone and requires fairly expert level understanding of the usage of both ActivitySim and Larch. The goals of this task would be to more tightly integrate Larch and ActivitySim, to achieve (1) allowing users to move between these tools using a common utility specification format, (2) to speed up the generation of data to support revisions to utility functional forms, especially for large data bundles (i.e. destination and scheduling components, possibly by sampling), (3) to extend and enhance the documentation of the estimation process, and (4) improve error handling. | Oregon DOT - Oregon is hoping to do estmiation across regions (for all Oregon modeling agencies) - this will require some refinement as well. It could perhaps lead towards ActivitySim partners bundling their areas' and having joint estimations for consideration or research - so maybe broad benefit. Curious if the partners would support this level of enhancment or if this is something Oregon should pursue outside of the formal collobration. | Usability | |||||||||||||||||||||
46 | ||||||||||||||||||||||||||
47 | 99 | Multi-year Development Roadmap | Document to help identify the major work items for the next X years (2-5 years). | Oregon DOT - it would be my hope that a document like this would also catalog (on an annual basis) the various improvement activities occuring outside the partnership (that the partnership is aware of) and identify which improvements are envisioned to be formally rolled into ActivitySim within the roadmap and pave the way for some level of resources / cooridination to import those improvements. | ||||||||||||||||||||||
48 | ||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 |