-
Notifications
You must be signed in to change notification settings - Fork 2
Draft ActivitySim Input Instructions
These are working instructions that ODOT has developed to start to communicate that ActivitySim inputs that are desired for the final SimOR design. There is no model framework that currently uses this exact input structure. The idea is that the "donor model" update task would use these instructions as a guide in updating the BAYDAG (donor model) setup to best align with OMSC's direction and vision. It's important to remember that Oregon's final ABM setup, won't have this exact set of inputs or instructions. Oregon's ABM estimation starts with BAYDAG, is then revised to align to something similar to this set, and will ultimately be further changed a revised based on what is learned during the estimation process. These instructions will allow the OMSC members to discuss what they do and do not like about the BAYDAG setup and make changes specific to how the OMSC would like Oregon's ABM platform implemented.
The following lays out the input develop into tables:
- household inputs
- person inputs
- zonal inputs
- skims
- Network inputs (needed to build the skims)
(Note, you can have more fields than this at the household level, but these would be the only fields used by the ABM - as proposed)
| Column Name | Description |
|---|---|
| hhid | Unique Household ID |
| MAZ | MAZ that the household falls in |
| HINC_25 | Household income, “hhincadj” from PopSim ($2024 dollars) |
| HWORKERS | Number of workers in household, “nwrkrs_esr” from PopSim |
| VEH | Number of vehicles in household, “veh” from PopSim |
| NP | Number of persons in household, “np” from PopSim |
| HHT | Household/family type:
|
| GQFLAG | Household unit type: 0 = Non-GQ Household 1 = GQ Household (RSG also references this field as "TYPE" and would be defined as 1 = household, 2 = institutional GQ, 3- noninstitutional GQ) |
| HH_AOC | Average Auto Operating Cost for the household's fleet of vehicles (informed by the vehicle table). For zero auto households, could either populate with the region average or a blank - probably blank is better. |
| Toll Factor | This Factor is multiplied to the toll matrix to create the correct toll that the household will pay. |
The following are fields that were identified by RSG, but don't seem to be needed (marked for further discussion):
| Name | Type | Description |
|---|---|---|
| SERIALNO | Integer | PUMS household number |
| PUMA_GEOID | Integer | Household PUMA Geographic ID |
| TAZ | Integer | Household TAZ ID |
(Note, you can have more fields than this at the person level, but these would be the only fields used by the ABM - as proposed)
| Column Name | Description |
|---|---|
| HHID | Household ID |
| PERID | Person ID (do we need this id, or can we use hhid + "-" + pnum, if it needs to be a sequential integer it should be calculated by the process |
| PNUM | Person Number - “sporder” from PopSim obtained from PUMS seed |
| AGE | Age of Person ("agep") of from PopSim obtained from PUMS seed |
| SEX | Gender of person from PopSim obtained from PUMS seed; 1) Male, 2) Female |
| PTYPE | Person Type:
|
| PEMPLOY | Employment status of person:
|
| EDUC | Educational attainment:
|
| SCHG | School Grade Attending - -8=under 3 years or not enrolled, 1=Nursery school or preschool, 2=Kindergarten, 3=Grade 1 to grade 4, 4=Grade 5 to grade 8, 5=Grade 9 to grade 12, 6=College undergraduate, 7=Graduate or professional school |
| OCCCAT | Person Occupation Category: 1=Management, Business, Science, and Arts, 2=White Collar, 3=Blue Collar, 4=Sales and Office Support, 5=Natural Resources, Construction, and Maintenance 6=Production, Transportation, and Material Moving 999=not a worker. Built from detailed occupation codes defined by the Standard Occupational Classification (SOC) system built on the SOCP from PUMS and PopSim
|
| MAJORUNI | Student of major university; 1=major university student (0 = not a major university student) This is currently just a place holder. The ABM is not envisioned to have a Major University Model when it is first deployed. One the university model is functioning, the user will need to flag/determine which members of the population are students of identified major university - this would also include correctly placing/tagging those students in the correct zones. |
| BIKE_COMFORT | A categorical comfort level 1-4. Obtained from OHAS relationships, OMSC will need to develop an equation(s) for how to estimate the Bike level of comfort from other household / person attributes. We will want to keep this as a user specified field (as opposed to internally calculated in the model), so that the user can run tests with different bike comfort levels for future scenarios. |
| DRIVING_STATUS | Driving Status: 0 = doesn't drive; 1 = drives. Obtained from OHAS relationships, OMSC will need to develop an equation(s) for how to estimate whether the person has a valid driver's license from other household / person attributes. We will want to keep this as a user specified field (as opposed to internally calculated in the model), so that the user can run tests with different levels of license status for future scenarios. |
| TRANSIT_FF | This Factor is multiplied to the transit fare matrix to create the correct fare that the individual sees when riding transit. |
| SchoolLevel | If the OMSC determines they want to have middle school broken out, and middle school differs around the state (some 6-8, some 7-8), we may want to code at the person level which type of school a student goes to (elem, mid, high) - instead of letting the code determine by age. |
The following are fields that were identified by RSG; planned to be in, but marked for further discussion:
| Name | Type | Description |
|---|---|---|
| PUMA_GEOID | Integer | Household PUMA Geographic ID |
| TAZ | Integer | Household TAZ ID |
| MAZ | Integer | Household MAZ ID |
| WKHP | Integer | Usual hours worked per week in past 12 months |
| WKW | Integer | Weeks worked during past 12 months -9: under 16 years old or did not work in past 12 months 1: 50-52 weeks worked 2: 48-49 weeks worked 3: 40-47 weeks worked 4: 27-39 weeks worked 5: 14-26 weeks worked 6: 13 or fewer weeks worked |
| ESR | Integer | Employment Status Recode -9: Under 16 years old 1: Civilian employed, at work 2: Civilian employed, employed but not at work 3: Unemployed 4: Armed forces, at work 5: Armed forces, employed but not at work 6: Not in labor force |
| MIL | Integer | Military Service -9: under 17 years old 1: On active duty 2: Active in past, but not currently 3: Only active for training in Reserves/National Guard 4: Never served in military |
| NAICSP | Integer | NAICS ID of work occupation (Census Code) |
| INDP | Integer | Work industry code (Census code) |
| OCCP | Integer | Work occupation code (Census code) |
| DDRS | Integer | Self-care difficulty (-9: N/A (Less than 5 years old), 1: Yes, 2: No |
| DEAR | Integer | Hearing difficulty (-9: N/A (Less than 5 years old), 1: Yes, 2: No |
| DEYE | Integer | Vision difficulty (-9: N/A (Less than 5 years old), 1: Yes, 2: No |
| DOUT | Integer | Independent living difficulty (-9: N/A (Less than 5 years old), 1: Yes, 2: No |
| DPHY | Integer | Ambulatory difficulty (-9: N/A (Less than 5 years old), 1: Yes, 2: No |
| DREM | Integer | Cognitive difficulty (-9: N/A (Less than 5 years old), 1: Yes, 2: No |
(Note, you can have more fields than this at the MAZ level, but these would be the only fields used by the ABM - as proposed) (Also, also note - there would be many more fields that the model tabulates for the user (like total households by MAZ), but the user would not be expected to double enter those values here - those values would come from the household and person tables)
| Column Name | Description |
|---|---|
| MAZ | MAZ number |
| TAZ | TAZ number |
| 1. EMP_NRM | Natural Resources and Mining (NRM) - NAICS 11 Agriculture, Forestry, Fishing and Hunting - NAICS 21 Mining, Quarry and Oil and Gas Extraction |
| 2. EMP_CON | NAICS 23 Construction |
| 3. EMP_MFG | Manufacturing (MFG) - NAICS 31-33 Manufacturing |
| 4. EMP_WT | NAICS 42 Wholesale Trade |
| 5. EMP_TWU | Transportation, Warehousing, and Utilities (TWU) - NAICS 22 Utilities - NAICS 48 Transportation - NAICS 49 Warehousing and Delivery Service Providers |
| 6. EMP_RET | NAICS 44-45 Retail Trade |
| 7. EMP_IFRPBS | Information, Finance, Real Estate, Professional, Business Service (IFRPBS) - NAICS 51 Information - NAICS 52 Finance and Insurance - NAICS 53 Real Estate and Rental Leasing - NAICS 54 Professional, Scientific, and Technical Services - NAICS 55 Management of Companies and Enterprises - NAICS 56 Administrative and Support and Waste Management |
| 8. EMP_HCS | Health Care and Social Assistance (HCS) - NAICS 62 Health Care and Social Assistance |
| 9. EMP_OSV | Other Service (OSV) - NAICS 81 Other Services, except Public Administration |
| 10. EMP_GOV | Public Administration - NAICS 92 Public Administration (Does not include Education Services) |
| 11. EMP_EDU | NAICS 61 Education Services (Private + Government) |
| 12. EMP_AER | Arts, Entertainment, Recreation (AER) - NAICS 71 Arts, Entertainment, and Recreation |
| 13. EMP_AFS | Accommodations and Food Services employment (ACC) - NAICS 72 Accommodation and Food Services |
| EMP_TOTAL | Total of all Employment |
| ENROLLGRADEKto8 | Grade School K-8 enrollment The code is setup to best represent public schools where proximity to the school helps determine which school a child goes to. The enrollment for private, charter, and similar types of schools aren't as heavily influenced by proximity and therefore the travel to and from these types of schools won't be represented as well as the public schools. However, if private and charter schools aren't included within this enrollment total then those schools won't be represented at all. So it is advised that at least the larger private/charter schools (enrollment of 100 or greater) are captured in this input, along with all public schools. Another important consideration is that these are not hard targets that the model must hit. The enrollment values can be consider "Size Terms". So for future years, a modeler would not need to estimate new future enrollment if the schools the assumption is that school size will stay relatively the same. For future years it would be important to track how many students are in the population and where they are being located, and if "green fields" near the boundary of the model might need additional school locations assumed. The main reason to consider new potential school locations would be to try and keep the distance traveled to school and the mode split reasonably. |
| ENROLLGRADE9to12 | Grade School 9-12 enrollment (same guidance as ENROLLGRADEKto8) |
| DIST_Kto8 | Elementary school district - Used to constrain school location choice for K-8 students. Must have at least 1 MAZ with K-8 enrollment in each district. This field is advised to be numeric integer only. Text description fields can be maintained by each organization outside the ABM. Integers chosen do not need to be sequential. |
| DIST_9to12 | High school district - Used to constrain school location choice for 9-12 students. Must have at least 1 MAZ with 9-12 enrollment in each district. This field is advised to be numeric integer only. Text description fields can be maintained by each organization outside the ABM. Integers chosen do not need to be sequential. |
| COLLEGEENROLL | College enrollment - include enrollment for all community colleges, 2-year and 4-year schools, and trade schools (if they are tracked and desired to be captured). Ideally, the college enrollment should be allocated across the zones that constitute the college campus for campuses that are represented by multiple zones. This can be done according to the amount of classroom space in each zone, or building size, or enrollment by building (or similar) depending on what data is available. Properly spreading the enrollment across the campus zones will ensure that college students (trips) are distributed across the campus (all zones in the campus) as opposed to just one zone. However, note, the model won't represent intra campus trips for larger campuses until major university model is developed (no scope for this at this time). |
| PRKCST_HR | Average cost of parking for one hour in hourly stalls in this zone, $2024 dollars (note BAYDAG also had an expected cost field, should consider if/how to represent expected cost vs posted cost, same for daily and monthly costs below) |
| PRKCST_DAY | Average cost of parking for one day in daily stalls, $2024 dollars (note if parking is free in the zone, but with a time constraint (like 2 hours free), a dollar estimate representing the pressure to move one's vehicle can be approximated, based on the risk of fine and the amount of the fine.) |
| PRKCST_MNTH | Average cost of parking for one day in monthly stalls, amortized over 22 workdays, $2024 dollars. |
| PRKSPACES | Total paid parking spaces in the MAZ. Below there's additional discussion and context on how to approach the number of spaces in a zone, when the price structure for the spaces varies within a zone. In short, the price a traveler sees is not the price of the zone they are traveling to, but a weighted average of a reasonable set of nearby zones. So while coding parking data correctly is important, users should remember that travelers will never see the cost for one specific zone, but an averaging of a multizone region. Therefore, it's more important to try and represent the overall parking limitations for a multizone region, than the details of a specific zone. |
| INTHMI | “INTHMI” (intersections within a half mile) will be pre-calculated by each MPO. This is pre-calculated and input by the user to allow for easy use for future years. For future years we want this input decoupled from the actual network as we plan to use regional averages for types of locations like “city centers” (70) or “town main street” (40) (as examples). For the base year this will be a scripted process, tabulating intersections based on a current all-streets network. For intersection density (within 1/2 mile), intersections will include all intersections that can be used for walking, and will therefore remove interstates, ramps, and dead-ends (cul-de-sac) without a pedestrian cut through at the end, and then tally these intersections within ½ mile of the MAZ centroid. For future year use - Each MAZ will then be associated with a development (or place) type, and then averaged – and those averages will be used to help create new values for future year scenarios where enhancement/development is planned. |
| PARKATTRACT | A three value scale of recreational space, where:
|
| TERMINALTIME | Recommended to assume a value of 1 for all non-CBD zones, and CBD at 2 or more based on parking difficulty. |
| ESCOOACCTIME | E-scooter access time (average number of minutes to walk to a shared e-scooter, 9999 if not available or outside service area). |
| EBIKEACCTIME | E-bike access time (average number of minutes to walk to a shared e-bike, 9999 if not available or outside service area). Note, some model regions may opt to use this as a standard (human powered) bike access time for shared bike service. While the field header specifies "EBIKE", this field could also be used for a standard bike share if no e-bike share services exist in the model region. If there is a mix of e and standard services, the region is advised to just treat all bike shared services as e-bike services. The average speed and max distance traveled on an bike service are specified in the properties (a link will be provided at a later date). The user can adjust these parameters to best reflect the type of bike service available in the region (e or human powered). |
The modeling region can choose how they want to store and manage these fields; whether in the maz file, or in a stand alone external input file (csv). But, however they are managed by the user, prior to inputting to ActivitySim, these external fields must be combined with the maz table above. Therefore the two likely options are that the modeling team keeps and maintains these fields in the maz input file, or a scripting process is built to merge the internal maz fields with the external maz fields. The merging would involve adding the external station numbers/rows, where all internal fields get a value of zero for all external zones, and then all internal zones are set to a value of zero for all external fields (those below).
| Column Name | Description |
|---|---|
| EXTERNAL | 1 if an external MAZ, else 0 |
| EXT_WORK_SIZE | Size term for work tours at external MAZ (total resident work tours from SWIM at the external station) |
| EXT_NWRK_SIZE | Size term for non-work tours at external MAZ (total resident non-work tours from SWIM at the external station) |
The fields in the table just below the following are calculated by the model code. However, to do those calculations a couple other fields not listed above are needed. If the fields above are pulled directly from Visum into model inputs, then these fields can be added by just listing them with the fields above (as they are pulled from the Visum version file). If the user is hand building a csv of zone inputs for ActivitySim, then they need to add these zonal attributes to the zone table for automated processing calculation below.
| Column Name | Description |
|---|---|
| ACRES | The geographic area of the zone in Acres |
| XCOORD | the x coordinate of the zone centroid in feet |
| YCOORD | the y coordinate of the zone centroid in feet |
The following are zone inputs that are likely needed for estimation but it is assumed these will be calculated by a pre-processor from other inputs and not input by the user directly:
| Column Name | Description | Notes |
|---|---|---|
| hhs | household size | hhs=total population/ total number of households (hh) |
| pop | total population | tabulated from household/person inputs |
| totngqhhs | Total non-group quarters households | tabulated from household/person inputs |
| hhp | total household population (exclude gq pop) | tabulated from household/person inputs |
| gqpop | Total group quarters households/population | tabulated from household/person inputs |
| duden | Dwelling unit density | Dwelling over total acres |
| empden | Employment density | Employment over total acres |
| popden | Population density | Population over total acres |
| retempden | Retail employment density | retail employment over total acres |
| PopEmpDenPerMi | Population and employment density per mile | PopEmpDenPerMi is a floating calculation of population plus employment divided by miles and calculated on a ‘floating’ basis for all MAZs within 0.5 miles of the MAZ. It is calculated in a script (run4d) as: (totEmp+totPop)/(totAcres/640. (Empden+ popden)*640= PopEmpDenPerMi |
| WLKTIME_BUS | Walking time to local bus (9999 if not available) | Calculated from all-streets network |
| WLKTIME_BRT | (Calculated from all-streets network) Walking time to bus-rapid transit (9999 if not available) | Calculated from all-streets network |
| WLKTIME_LRT | (Calculated from all-streets network) Walking time to light-rail transit (9999 if not available) | Calculated from all-streets network |
| WLKTIME_CR | (Calculated from all-streets network) Walking time to commuter rail (9999 if not available) | Calculated from all-streets network |
| EXPPRK_MNTH | (Calculated) Expected average monthly parking cost from origin to all destinations ($2024 cents) | Calculated |
| EXPPRK_DAY | (Calculated) Expected average daily parking cost from origin to all destinations ($2024 cents) | Calculated |
| EXPPRK_HR | (Calculated) Expected average hourly parking cost from origin to all destinations ($2024 cents) | Calculated |
| PARKAREA | Parking constrained area code: 1: Constrained parking area (destinations in area have an expected cost and parking location choice model is applied. 2: Buffer area (free parking in area is included in expected cost for destinations in PARKAREA 1, but destinations in area do not have an expected cost and parking location choice model not applied), 3: Not parking constrained or buffer area (free unconstrained parking). | Calculated |
Some additional context can be found in the write-up performed by RSG as part of the design.
The following are zone inputs that can be used in the future, but are not currently required for estimation and initial model development and deployment:
| Column Name | Description | Notes |
|---|---|---|
| HOTELRM | Hotel Rooms | Won't be collected for estimation, not currently used in Oregon's model. Total number of hotel rooms. Note that BAYDAG also has fields; budgetroom, economyroom, luxuryroom, midpriceroom, upscaleroom. From RSG - Hotel rooms are typically not used for resident models. They are used to forecast overnight visitor travel. |
| REMOTEAVPARKING | Remote AV parking available | Remote AV parking available in the zone: 0 = Not available, 1 = Available - For now these can all be set to zero. In the future consider, choosing a zone which is close to PARK and Ride set as 1, everything else set to zero. Applied if AV allocation model is in use. |
These are rough notes for how the OMSC might need to start think about network development and maintenance to develop the required skims
- Highway network - typical highway attributes; speeds, costs, functional class, number of lanes - https://github.com/RSGInc/SOABM/wiki/Networks-and-Zone-Data#link-attributes (note for ODOT, Capacity is currently a look-up table, is the OMSC okay with a look-up table approach, or do we need to plan to have this be a user input. ODOT pushes for look-up table to reduce user error and create consistency. Users can still apply unique location adjustments, with an override factor that's defaulted to zero - "CAPADJ")
- Some newer attributes to consider; Aux lanes, medians, costs/tolls by time of day
- Links need a reference code to pull and push information to connected datasets (LRM, XD, maybe OSM way ids), need to consider how to link to 8 MPO network inventory effort that ODOT has contracted to complete.
- Highway Transport Classes/Users - probably attempt to keep to just the "metro 4" - SOV, HOV, Med Truck, Heavy Truck (although do we need to assign VOTs as their own traveler segmentation)
- Walking will likely assume travel is viable on all non-access controlled FCs along with multi-use paths.
- For multi-use paths, work must be done to ensure that end points of paths are properly linked to the road network (so that walkers/bikers can correctly move from the road network to formal or informal path connections.
- Multi-use paths also need careful review of segment breaks. MAZs may be connected in an automated fashion. Whether computer or human created MAZ connectors, care needs to be taken to ensure that MAZs have proper access to multi-use paths. This typically means reviewing node placement (link splits) and ensuring that each MAZ has a close and correct access point to near-by multi-use paths. Special attention/review should be given to popular (heavily used) paths.
- For Bike accessibility we can start with Metro's fields further detailed below. ODOT is desiring to get to a level of stress variable on the network. The metro variables might be enough to approximate, but further discussion will likely be needed.
These are attributes from Metro's "Bike Cookbook". They serve as the starting point for how to attribute Oregon's ABM networks. For more detail, see file - bike_Cookbook_2018_RTP23updates_v0pt8_clean.pdf.
- BIKEFAC - Bike Facility Present; 0 = none, 1 = a conventional, striped bike lane, 2 = a protected bike lane or street-level cycle track. Requires at least some measure of physical separation from adjacent motor vehicle travel lanes for most of its length (e.g. curbs or other vertical elements such as bollards, posts, parked cars, or planters). 3 = bicycle boulevard/neighborhood greenway. DO NOT include bike routes that have only signage and/or “sharrows”. 4 = off-network, paved, regionally significant multi-use path. DO NOT include localized, discontinuous, or unpaved paths (e.g. park paths) in this designation.
- TRAFFCAT [0, 1, 2, 3] - These attributes are not intended to be updated with auto network assignment results. Despite the specificity implied by their names, they function as a more generic “local/big/bigger/biggest” categorization (where local/big/bigger/biggest roughly map to AADTs of <5k/10k/20k/30k). Value is irrespective of absence or presence of bike facility. Currently calculated based on capacity and speed profiles. [See Appendix B for derivation.] ODOT note - we should revisit the look up table and see if we can ensure a good approximation to BLTS in the look up table. Ideally we would rename, re-define this attribute to BLTS - given how close the description is.
- SLOPE - calculated average slope over the link segment. Suggest calculating automatically from local DEM data.
- Metro's Bike model requests Signalized / stop controlled attribution at nodes. ODOT's current highway assignment also uses intersection control - two reasons to ensure that nodes "controltype" attribute is properly populated. First priority is getting signals identified. Next priority is getting stops properly represented. Roundabouts would also be good to capture given the state's desire to better represent roundabouts, but there's no current use for this coding (just future plans).
Further questions or issues to work through:
- FYI - cleaned up coding / attribution, by combining 0/1 flags into single attributes (like 4 separate flag fields being combined into "BIKEFAC").
- Under BIKEFAC - there's no coding for unpaved / informal park paths. Are these really a 0 (the same as no bike lane), shouldn't they be coded as something different than a non-bike lane highway? Maybe this will be captured in a different way - given that they have no traffic conflicts.
- Bridge spans won't be as meaningful outside of Metro - we will have to find someway to reflect regionally important segments that aren't Metro specific.
OMSC's ABM implementation will want to build on Metro's approach-to-date for transit and park-and-ride network representation. This currently is a place holder, which will be populated by Metro/OMSC to better describe how transit should be coded and stored for proper assignment and skimming. While Metro and the OMSC is populating this section, it is important to capture that the ABM is envisioned to have 4-5 skimming periods; EA, AM, MD, PM, EV. Trip based models likely don't have this level of transit route representation / complexity. While we are drafting a coding representation approach, we need to ensure we are thinking through how to populate each of the 4-5 skim sets with time-of-day appropriate information.
The ABM only indirectly uses network inputs. The ABM's direct inputs are skims. Currently the ABM is spec'd to have the 24 hour day broken into 5 assignment/skimming time periods; EA, AM, MD, PM, EV. The model framework that OMSC is starting from (BAYDAG) has 1760 skims (352 for each of the 5 skimming periods). OMSC will be actively working to reduce the number of skims needed in the ABM. The following is the anticipated list of skims for each time period:
- 15 SOV matrices = 5 skim types (Distance, Reliability, Time, Toll Cost, Distance w/Tolls) x 3 Income VOT sensitivity (High, Medium, Low)
- 18 HOV matrices = 6 skim types (Distance, Reliability, Time, Toll Cost, Distance w/Tolls, Distance w/ HOV lanes) x 3 Income VOT sensitivity (High, Medium, Low) For both SOV and HOV - do we need distance with tolls? Do we really want to carry around all these HOV skims for a couple miles of OHV lanes in the Metro region? I would suggest we fully drop the HOV skim set in estimation and it could just be a specialized assignment treatment only.
- 9 Truck Matrices = 3 skim types (Distance, Time, Toll Cost) x 3 Income VOT sensitivity (High, Medium, Low) We might want to skim trucks differently for aspects like Metro's freight model. But I can't think why we would be feeding truck skims back to ActivitySim, so I don't believe any of these should be in the ActivitySim skim set.
All the skims below still need significant work and thought. Below is just what we are starting from with the BAYDAG setup.
- 4 Active Matrices = Bike Logsum, Bike Time, Bike Distance, Walk Time
- 39 Transit Matrices = 3 vehicle types (Bus, Mix, Premium ~Light Rail) x 14 skim types (Fare, Access, Egress, First Wait Time, Dwell Time, Number of Transfers, Bus In-Vehicle Travel Time (IVTT), Total IVTT, Transfer Wait Time, Transfer Walk Time, Total Walk Time ), where (3 skim types don't apply to Bus, LR IVTT, Exp IVTT, CMR IVTT)) (( 3x14 ) - 3)
- 78 Park and Ride Matrices = 3 vehicle types (Bus, Mix, Premium ~Light Rail) x 2 directions of travel (inbound / outbound) x 14 skim types (Fare, Access, Egress, First Wait Time, Dwell Time, Number of Transfers, Bus In-Vehicle Travel Time (IVTT), Total IVTT, Transfer Wait Time, Transfer Walk Time, Total Walk Time ), where (3 skim types don't apply to Bus, LR IVTT, Exp IVTT, CMR IVTT)) (( 3x14 ) - 3)
- 78 Kiss and Ride Matrices = 3 vehicle types (Bus, Mix, Premium ~Light Rail) x 2 directions of travel (inbound / outbound) x 14 skim types (Fare, Access, Egress, First Wait Time, Dwell Time, Number of Transfers, Bus In-Vehicle Travel Time (IVTT), Total IVTT, Transfer Wait Time, Transfer Walk Time, Total Walk Time ), where (3 skim types don't apply to Bus, LR IVTT, Exp IVTT, CMR IVTT)) (( 3x14 ) - 3)
- 78 Transportation Network Company (TNC) Skims = 3 vehicle types (Bus, Mix, Premium ~Light Rail) x 2 directions of travel (inbound / outbound) x 14 skim types (Fare, Access, Egress, First Wait Time, Dwell Time, Number of Transfers, Bus In-Vehicle Travel Time (IVTT), Total IVTT, Transfer Wait Time, Transfer Walk Time, Total Walk Time ), where (3 skim types don't apply to Bus, LR IVTT, Exp IVTT, CMR IVTT)) (( 3x14 ) - 3)
US EPA and UD4H's Smart Location Database Technical Document has some interesting ways to think about design. I (Alex) propose that we use SLDs definition for Pedestrian-Oriented Facilities for intersection count as opposed to all intersections. Pedestrian-Oriented Facilities are defined as:
- Any link having a speed of 30mph or less and suitable for walking (like having sidewalks).
- Any pathway or trail on which automobile travel is not permitted.
- For all of the above, pedestrians must be permitted on the link
- For all of the above, controlled access highways, tollways, highway ramps, ferries, parking lot roads, tunnels, and facilities having four or more lanes of travel in a single direction (implied eight lanes bi-directional) are excluded.
With that definition I think we would tally up new intersection counts within 1/2 mile for each MAZ, but this time it would be ped friendly links only and not all intersections. Then we could review Metro's Dev Type areas and see if there are nice definable boundaries for the future (similar to how they use the all intersection count - but this one would be more sensitive to ped friendly changes, like reducing speed and adding trails).
It might also be helpful to list out the SLDs definition of walkability, but this is just being listed for knowledge sharing. It's not being proposed to use this calculation
Walkability Index score = (w/3) + (x/3) + (y/6) + (z/6)
Where:
- w = CBG ranked score for intersection density (note - this intersection density has auto-oriented intersections eliminated)
- x = CBG ranked score for proximity to transit stops
- y = CBG ranked score for employment mix
- z = CBG ranked score for employment and household mix
From Joel Freedman (RSG), team call on 10-21-2025 (the question asked was related to how to code parking price for MAZs that have a mix of monthly permit lots and on-street hourly parking - spots that are only one thing, not a mix):
The original design that we used in OR ramp, which came from SANDAG, had different parking quantities (parking space quantities) for different payment periods (hourly, daily, monthly) and it also had some indication of number of hours you could park for free in the zone, although I don't think that was ever handled very well in the code.
SANDAG realized it was too complicated to maintain all these fields, so they strongly encouraged us [RSG] to find simpler ways to do it. So we did, and we slimmed everything down to three parking costs and one parking quantity (which is the approach seen in this implementation - 4 parking related fields).
By way of explanation, what is this data used for? We need to calculate an expected parking cost for every zone. The expected parking cost is essentially an average of the parking options within a reasonable distance of the activity location. The code goes out and finds all those zones that have parking quantities in them (PRKSPACES>0), and calculates an expected average daily, monthly and hourly cost according to the distance to that lot from the activity location. So it's weighted less the further away it is and according to the quantity of parking in that zone, and it's weighted more the more spaces there are. That represents one way the data is used to calculate that expected parking cost.
Example from the office building where Joel works Downtown Portland: For the block (MAZ) I work in, there's no parking garage. So you have to park in a different block and walk very short distance. The parking that people see in this building is an average of the parking in downtown Portland. It's not not the cost of parking in this building, but a weighted average cost from the nearby zones.
A second use of the parking fields, specifically the number of spaces would be in the event the parking location choice model is turned on. That model determines where somebody parks and if capacity constrained is applied, then the model would use the parking quantity to constrain the number of parkers.
Important Note - that this feature has not been implemented. There is no hard constraint right now in ActivitySim for parking, but could be at some point.
In summary - the idea is to keep it simple and deal with the error that is going to happen. Yes, you might have 100 spaces in a zone, and only 20% of them are monthly and 80% of them hourly. And you're weighting them all equally as if there's 100 in the expected parking cost calculation. If you didn't make any adjustments, you would overestimate the number of monthly spaces that were available. You would overweight them in the expected parking cost calculation. How much is it going to matter? I think that there's usually a pretty clear relationship between hourly parking costs and monthly parking costs where hourly costs are higher, monthly parking costs are higher. It's probably not a constant ratio, but there's probably a relationship there. There is error in that representation of the expected parking costs, but given the overall context and use of the model I would be comfortable living with that error.