VE Best Practices UNDER CONSTRUCTION

Outline of Best Practices

• Household Synthesis
• Best Practices for selected inputs
• Best Practices for VE-State inputs
• Common errors:

ODOT Application, clean us slides 35-45 from Apr2019 VE Training

1. Best Practices for selected inputs

The File_Summary.XLSX lists all the input files (VE-RSPM & VE-State0 with a short description and various attributes. The "Category" field is used to help structure the input process, as discussed below.

Place Types: Something like slide 39 of VE Training Slides.

Set-up Inputs:

Shouldn’t change much from the download, unless you want your own deflators, etc. Will need to identify the years you will be running, etc. ODOT’s VE-State Geographies (geo.csv):

• AZones = Counties; Mareas = MPOs (can be multi-county)
• Location Type (Urbanized, Town, Rural) = MPOs are “Metro”, UGBs smaller than MPOs are “Town”, rest is “Rural”
• (VE-State only) MArea Area Types (Center, Inner, Outer, Fringe) = based on VE-State EAP-SLD-based definition here. ODOT builds TAZ-level place type maps for all MPOs to generate. See below.
• (VE-RSPM only) Marea definition: “Urbanized” portion of a select set of Azones that are associated with a common urbanized area; often separate models are applied for Mareas, so information on road, transit and urban-mixed use variables, only present there can be applied (most notably VMT and other mode usage). Marea is typically equivalent to a “census urbanized area” definition.

Mareas do not include “town” location types within the MArea counties. As such, "towns" in the Marea counties typically fall outside of the continuous urbanized area (i.e. census urbanized area). Some exceptions may be made if the outside areas are contiguous enough with the official urbanized area or will be in the horizon of the modeled scenarios, such that they will use common (high frequency) transit systems, and share the same road/congestion. Some examples of this are Eugene VE model including the city of Coburg as "urbanized" rather than a "town" and Portland including Ridgefield in the urbanized area. The recommendation can be summarized as designating an MArea city outside the census "Urbanized area" definition as “towns” unless: (1) they are continguous to the larger urbanized area, or will be in the planning horizon, or (2) if they have significant transit service, road congestion that the “town” formulas will not account for.

Land Use Inputs:

This would include all the inputs in the attached File_Summary.XLSX with category="LandUse" or "Demog", roughly a dozen files. some sources identified in the attached file summary.

Land use -- land use/demographic input csv files by year, including all the inputs in the VE-RSPM_File_Summary.XLSX (link) with category="LandUse" or "Demog". roughly a dozen files. Building off the local regional travel demand model TAZ data for the RTP years. ODOT has a simple R-script that pulls dwelling unit “household income quartile” data from census.

• Demog: Pop (GQ optional) & demographic input by azone (county);
  ODOT UG: Population Source: Base year totals of households and associated population (base_hh_pop_inc.csv) can be obtained from Census (block or block group data). Future year forecasts (pop_by_age_yyyy.csv) should be consistent with but may need to be extrapolated beyond adopted regional plans (e.g., RTP, County and City TSPs). County-level age distributions from the Oregon Office of Economic Analysis (OEA) long range county population forecasts can be applied to base year district level population totals, if sub-county age information is not available. Some local governments may have detailed age information generated as part of a Housing Needs Analysis completed for the Periodic Review of the local Comprehensive Plan. If not, future population by age can apply ratios from the base year model set-up.

ODOT UG GQ Source: Group quarters population data is best obtained from the university administration, by age if possible (group_pop_by_age_yyyy.csv). Group quarters can be approximated from enrollment data by class year. All other group quarters data (autos owned and income) are difficult to obtain but not of paramount importance to the model, simplifying assumptions are often required (e.g., In CLMPO, income is assumed constant at $10,000 per capita and auto ownership at XX)

ODOT UG HHsize Source: These household size values (pop_targets.csv) can be obtained from the 2010 Census block group data and aggregated into divisions (or districts). HH size should be consistent with the values used in the regional urban travel demand model and assumptions in the local Comprehensive Plan. These two data inputs can be assumed constant in the future, if no other local data is available

ODOT UG PCI Source: District-level per capita income can be obtained from Census Block Group Data. If a district includes multiple block groups, the income should be a weighted average based on the number of households in each. Since the model accounts for inflation, future income can remain the same in future years, or adjusted based on local plans.

ODOT UG DU Source: The base year district level dwelling unit data (du_forecasts/du_yyyy.csv) can be assumed to match the base year household counts from 2010 Census data (stratified by RSPM housing types) developed with RSPM demographic inputs. Future year dwelling units can be obtained from local Comprehensive Plans. Adjustments may be needed to count only occupied units. District occupancy rates can be obtained from Census block group data, as a starting point. Base and future year dwelling unit counts should be consistent with household assumptions in the region’s travel demand model.

When we've used the 2010 EPA SLD data (D4c metric) for Transit and Design D (using the Place Type r-script), we've just used the EPA block group data that the TAZ centroid falls into. To aggregate to the District, we've simply used an average of the TAZs, whose centroids fall in the Bzone. We have discussed that using a population-weighted average of the Distict's TAZ values is probably a better approach.

Note: We are transitioning away from the EPA dataset in the future to allow us to represent multiple years or alternative scenarios. We're trying to pull items that would be consistent with what we use in the regional travel models (JEMnR or ABM). Below is our thinking so far...welcome any ideas:

• Transit D -- Use GTFS file for each year/scenario (can use Remix), summarize to get fixed route visits at transit stops (use TNExT tool), and apply GIS spatial join to sum transit visits at stops within TAZ of BZone. Resulting in PM peak period visit at stops per hour.

• Design D -- We're looking to use intersection density or non-freeway miles per acre as a surrogate. However, this would require keeping up an all streets network, since our travel models typically don't include most local streets, and often don't worry about updating local street changes.

• Land Use: Employment, dwelling unit (& inc quartile), bzone lat-lon, emp, Built Form ‘D’s

• 3 shaded input files are optional/use defaults of all 1s or all NAs

Defining "Location type" & "Area Type"

ODOT develops p: lace type maps from local MPO travel demand model TAZ data for MPO RTP;s base and future year (pop, emp by type, adding acres and 2010 EPA SLD data Built form “D” values). We have a place types R-script we could share if interested that uses TAZ data as input, we are currently adapting the script for the updated VE “D” variables from SLD.

• How do you define “Location Type” (metro, town, rural)? Generally we assume land in MPO boundaries to be Metro, urban areas smaller than MPOs land inside their UGB is a town. Everything else is rural. Note that if you want to further refine within the MPO, place types can identify low density areas that you might consider “rural” and areas that less accessible/more isolated (don’t have access to broader transit service) as “town”) There are official state population forecasts done for each urban area that helps with the population inputs. We did a trick with LEHD where we used the boundaries identified above to designate location types, and then used LEHD to calculate worker flows between county home location-to-work LocType (any county).
• How to define “Area Type” (center, inner, outer, fringe)? What criteria do you use? “Area Type” is based on a mix of activity density levels and destination accessibility levels, as disussed in VE-State EAP-SLD-based documentation here.
  ODOT uses place types by local travel model TAZ within MPOs (MAreas), and generate VE input for these 2 dimensions (see below calculations) from pop & emp data by TAZ. By using local travel model TAZ data which has base and fute pop & emp, we can create a future version of these 2 variables and thus the VE-State area type inputs we calculate cover different areas over time:
• activity density = TAZ-level (HHs+Emp+GQ/2.5)/unprotected acres(parks & water removed) . SLD D1B is roughly the same.
• destination accessibility = TAZ-level as shown below. There’s not an equivalent SLD attribute, but some of the D5* attributes are similar.
• Destination accessibility (D5)Harmonic mean of Employment within 2 mi and Pop within 5mi
  (2 * TotEmp_InDist2mi * Pop_InDist5mi) / (TotEmp_InDist2mi + Pop_InDist5mi). Levels: VL = 0 - 2e3, L = 2e3 - 1e4, M = 1e4 - 5e4, H = 5e4+.

For the design VE-State input, here is the equivalent SLD attribute

• Design... = (d3bpo4)

Transport Inputs:

Transport – ODOT develops input tables of default values for local policy inputs as assumed in VE-State, (word doc tables). MPO works with stakeholders to refine these values and finalize reference scenario inputs that reflect financially constrained adopted plans. These discussions with local staff also start to define more/less ambitious scenarios to include in the multirun sensitivity tests.

State-led action inputs – ODOT develops default input files (CSVs) that apply to all Oregon MPOs (State-led actions like vehicles & fuels, etc as well as context variables like fuel price, etc.). Shared with guidance [add guidance doc?]

V+F:

• ODOT can share our inputs/PowerTrainsAndFuel packages for Oregon legislative policies, they are customized for Oregon (eg packages were built by Brian Gregor here). Based on our discussion, these are not the same in WA (no Zero Emission Vehicle program with 10-CA-led states; no Low Carbon Fuel Standards policy). You can borrow our “Reference” for now, but may want to develop WA-version, could benefit from discussion with your DEQ/DOE peers.
• In general, ODOT has a 5% biodiesel and 11% ethanol (gas additive) requirement statewide that is used by all vehicles including transit. You should find out WA equivalent.

Pricing:

Most of these will be state-led actions, reflecting your own local/state policies.

Actions (Local Actions):

Area type definitions of MArea inputs in VE-State (TDM, parking, CarService)

• Most of these are local actions within MAreas (including transit agencies), reflective of their local plans, and/or sources noted in the file_summary (HPMS road lane-miles, NTD transit service miles). Others are called out below.

• Actions-CarSvc (shaded): Definition of CarService, could borrow from ODOT. WE can provide more background if desired, on the source.

• Actions-ITS (shaded): WA has more advanced ITS operations than OR, so may not want to use ODOT values for “speed smoothing”, “other ops”.

• Building place type land use data from local MPO TAZ data, as noted above, you will be able to develop the more aggregate “area type” place-type inputs needed by VE-State.

• How to develop freeway/arterial lane miles by metro area? ODOT UG Rd lane-miles Source: Freeway and arterial lane miles (fwy_art_growth.csv) should come from the RTP, STIP, or other local and regional plans; financially constrained?

ODOT uses both state and local historic roadways as reported by Functional class to HPMS. We get this information by MPO from ODOT’s HPMS submittal team. We use the lane-length values as lane mile inputs, aggregating as follows:

• Fwys = "Interstate "& "Other Freeways & Expressways"
• Arterials = "Other Principal Arterial" & "Minor Arterial" We ignore Major/Minor collectors and Local streets.

Customized VE packages:

These require rebuilding VE packages with local /extdata/ files)

• VESimHouseholds – Update to use WA PUMS. FHWA/Volpe can help with this, contact Jeremy Raw/Dan Flynn.
• PowertrainsAndFuels – You are welcome to use (with caution), Oregon’s VE-State inputs that are under-development (see link above).

3. Common errors:

MANY FILES HAD DATA FOR YEARS OTHER THAN MODEL RUN YEARS

• This is an error. Files can only have data for model run years.

Check all of the VESimLandUse package module azone input files, have same azone order (future bug fix to resolve)

region_base_year_dvmt.csv

• Replace StateAbbrLookup with NA (was Oregon) This was a warning not an error. Using NA calculates regional truck travel based on urbanized area average per capita. Using OR would calculate using the statewide per capita average.

Input files in different modules need to be consistent.

• zero land area for an Azone-location type when there are non-zero values for households in that Azone-location type
• zero land area for an Azone-location type when there are non-zero values for employmentin that Azone-location type

Input file rules: Something like slide 17 of VE Training Slides. overall pieces to running: Something like slide 15 & 7 of VE Training Slides.

========

CUSTOMiZED USER PACKAGES

• PUMS
• PowertrainsAndFuels VETravelPerformance/LoadDefaultRoadDvmtValues datasets from the 2010 Highway Statistics reports are used to calculate state and urbanized area travel statistics as described below. A data from the Transportation Energy Databook (Edition 31) are used to calculate the ratio of commercial service vehicle DVMT with household DVMT. These datasets are in the "inst/extdata" folder of the package. Documentation for these datasets are included. Advanced users may update the datasets if desired. Various VETravelPerformance default files are included in the inst/extdata directory of the PowertrainsAndFuels package. Each file is documented with a correspondingly named text file. Advanced users may modify these files to create other default scenarios.

PACKAGE MAINTENANCE

• BudgetHouseholdDvmt Ext_data: The CES data used to estimate the BudgetHouseholdDvmt model are included in 'ces_vehicle_op-cost.csv' with documentation in 'ces_vehicle_op-cost.txt'. The 'ces.R' R script file contains the code used to download the raw CES dataset from the BLS website and process it to produce the dataset in the 'ces_vehicle_op-cost.csv' file. CES data for the years 2003 to 2015 are used in model estimation. 2003 being the first year that the BLS included income subcategories for incomes greater than $70,000. 2015 being the last year of complete data when the model was estimated.

• VETravelPerformance\CalculateVehicleOperatingCost Module: vehicle maintenance, repair, and tire cost as a function of the vehicle age is calculated based on data from the American Automobile Association (AAA) and the Bureau of Labor Statistics (BLS). AAA publishes reports yearly on the cost of vehicle use by vehicle type over the first 5 years of the vehicle's life. The 2017 report, a copy of which is included as the '17-0013_Your-Driving-Costs-Brochure-2017-FNL-CX-1.pdf' file in the 'inst/extdata/sources' directory of this package, is used to calculate baseline MRT cost by vehicle type. Data from a BLS report, "Beyond the Numbers, Prices and Spending, Americans' Aging Autos, BLS, May 2014, Vol.3/No.9", are used to establish the relationship between MRT cost and vehicle age. A copy of the report is included as the 'americans-aging-autos.pdf' file in the 'inst/extdata/sources' directory of this package. This report includes estimates of average MRT cost by vehicle age category for all household vehicles. The MRT costs by vehicle type and age are calculated as the outer product of the AAA costs by vehicle type and the BLS ratio of MRT cost by vehicle age. Since the BLS data don't distinguish between vehicle types, it is assumed that the effect of age on MRT expenses is the same for all vehicle types.

• VETravelPerformance\CalculateVehicleOperatingCost Module: Default Carbon Cost values are from "Technical Support Document: Technical Update of the Social Cost of Carbon for Regulatory Impact Analysis Under Executive Order 12866, Interagency Working Group on Social Cost of Greenhouse Gases, United States Government, August 2016". A copy of the report is included as the 'sc_co2_tsd_august_2016.pdf' file in the 'inst/extdata/sources' directory of this package.Carbon costs are estimated by year and assumed discount rate scenarios: 5%, 3%, 2.5%. In addition, they are calculated for a lower probability but higher impact scenario. The default carbon costs used in the model are the values listed for the 3% discount rate.

• VETravelPerformance\CalculateVehicleOperatingCost Module: Non-Carbon Social Costs: Values for other social costs are derived from an white paper prepared for the Oregon Department of Transportation (ODOT) to support the development of ODOT's statewide transportation strategy for reducing greenhouse gas emissions from the transportation sector. This paper is included as the 'STS_White_Paper_on_External_Costs_9-21-2011.pdf' file in the 'inst/extdata/sources' directory of this package. The included social cost categories are air pollution, other resource pollution, energy security, safety, and noise.

• VETravelPerformance\BalanceRoadCostsAndRevenues Module: region_road_cost.csv file includes unit costs for freeway and arterial operation, preservation, modernization, and other costs. Based on values in original GreenSTEP model (ODOT, 2012).

=========