BAUSStrategyCodingNotes

Existing Planned Land Use

• Two input files:
  • zoning_parcels.csv is stored on Box because of its size. This file links each parcel to its zoning_id.
    • Versions: 2020_03_04_zoning_parcels.csv (Horizon), 2020_06_22_zoning_parcels_hybrid_pba50.csv (Draft Blueprint), _____ (Final blueprint).
  • zoning_lookup.csv joins with the file above using id and provides the contraints for each zoning_type: maximum allowable intensity (max_far, max_dua, max_height) and allowable development type. Development type is represented by 14 two-letter dummy variables as shown in this lookup file).
    • Versions: zoning_lookup.csv (Horizon), 2020_06_22_zoning_lookup_hybrid_pba50.csv (Draft Blueprint), _____ (Final Blueprint).
• Coding notes:
  • When "zoning_parcels.csv" is updated, update datasources.py in the baus folder.
  • When "zoning_lookup" is updated, update datasources.py.

Scenario Planned Land Use

• Input file: zoning_mods_[scenario].csv, which adjusts allowable development types/intensities and sets development restrictions based on geographies. This is a part of UrbanSim's ScenarioComponents.
• Coding notes:
  • When the field name of the planned land use designation is changed (e.g. PBA40 uses 'zoningmodcat', Horizon uses 'zoninghzcat', Draft Blueprint uses 'pba50zoningmodcat', Final Blueprint uses 'fbpzoningm'), update datasources.py to source the new field.
  • When adding new zoning scenarios, add the associated scenario-specific modfication table (e.g. zoning_mods_4.csv for Scenario 4) into the 'data' folder, and insert a new column representing the new scenario into 'development_projects.csv'.
  • Update scenario handlers to scenario-specific strategies in policy.yaml, e.g. inclusionary zoning.

Strategies

Deed-Restricted Units notes

• Deed-restricted units can now come from many sources. As of Final Blueprint, those sources are:
  • DR = base year DR + pipeline DR + public lands (added via pipeline) + subsidized (production) + preserved + inclusionary
• Pipeline units cannot be redeveloped, other deed-restricted units can if or when the building is more than 20 years old.
• In the household location choice models, only Q1 households can enter DR units. However, if the model can't find enough Q1 households for the DR units (due to modeling reasons or over-supply) non-Q1 households are able to enter.

Affordable Housing Fund- Preservation (Final Blueprint)

• Selects buildings to spend preservation funding on, by marking them as deed restricted units. The selection is not tied to price, and housing cost is calculated off model.
  • The buildings are randomly selected based on the total number of buildings to preserve within a geography which are set here.
  • The "deed restricted" column is updated in the residential units table, which is used to filter units in the household location choice models and assign Q1 households to deed restricted units. The "deed restricted units" and "preserved units" columns are updated in the buildings table. These occur here.
• In some cases, a Q1 household will already occupy a newly preserved unit. If that household moves, only another Q1 will be able to move in. In other cases, a non-Q1 household will occupy a newly preserved unit, and a Q1 household is only able to enter if and when that household moves out.

Inclusionary Zoning (Draft Blueprint, Final Blueprint)

• Inclusionary zoning requirement (x% of new housing development have to be affordable) is set in policy.yalm.
  • The default setting represents the existing requirements without plan strategy interventions.
  • Plan strategies are organized by scenario, with a scenario handler at the top.
  • Inclusionary rate is set at certain geographic level:
    • PBA40 and Horizon: inclusionary percentage by jurisdiction.
    • Draft Blueprint: inclusionary percentage by pba50chcat (i.e. the combination of several growth geography strategies, GG, TRA, PPA, etc.).
    • Final Blueprint: inclusionary percentage by fbpchcat.
• Coding notes:
  • datasources.py reads inclusionary strategy input and maps it to parcels using the corresponding field: PBA40 and Horizon uses 'jurisdiction', Draft Blueprint uses 'pba50chcat', Final Blueprint uses 'fbpchcat'.
  • In subsidies.py, the inclusionary_housing_revenue_reduction function calculates median household AMI, feasible new affordable housing count and revenue_reduction amount of each inclusionary geography. In PBA40 and Horizon, these calculations were conducted at the jurisdiction level. PBA50 uses strategy geographies instead - 'pba50chcat' in Draft Blueprint and 'fbpchcat' in Final Blueprint.
  • The inclusionary statements in summaries.py should be consistent with the inclusionary geography of each plan scenario.

Reduce cost for housing development (Draft Blueprint, Final Blueprint)

• One way to (indirectly) subsidize housing is to reduce housing development cost reduction, for example, SB743 CEQA reform, lowering parking requirements, etc. This is defined in profitability_adjustment_policies. The policies are scenario-based, as noted by "enable_in_scenarios". For each policy, profitabiity_adjustment_formula picks the parcels in a certain category (e.g. a certain type of geography) and then decreases the required profitability level needed for the model to build on those parcels, e.g. multiplying by 2.5% or 0.025 means to LOWER the required profit level by 2.5%. When a policy has an alternative version is different scenarios, may use 'alternative_geography_scenarios' and 'alternative_adjustment_formula' to consolidate the scenarios.
• "Summaries.py" summaries these policies.

Affordable Housing Fund Lump-sum Account (Draft Blueprint, Final Blueprint)

• Lump-sum accounts represent direct housing subsidies.

  • Each county has a lump-sum account to hold all the available affordable housing funding for that county. BAUS assumes a constant annual funding amount (an independent input), for each county during the plan period, doesn't consider inflation or fluctuations in funding availability over time. In each simulation iteration, funding available in each county's account equals the annual amount multiplies by years per iteration (5 years in BAUS).
  • Residential development projects that are not feasible under market conditions are potentially qualified for subsidy. Final Blueprint requires the projects to be also located within the Growth Geography. A qualified project draws money from the corresponding account to fill the feasibility gap. Not all qualified projects will be subsidized.
  • Lum-sum accounts are scenario-based, having scenario-specific fund amount and project qualification criteria.

• Coding notes:

  • Set up the account in policy.yaml
  • Calculate each account's subsidy amount for each iteration and add it to coffer
  • Set up the filter in run_subsidized_developer()
  • Update the config in 'summaries.py'
  • Check subsidized_residential_developer_lump_sum_accts() and make sure it is included in the model list in baus.py

VMT Fees / Transportation Impact Fees (Draft Blueprint)

• Apply fees on new commercial or residential development that reflects transportation impacts associated with such development, focusing primarily on new commercial spaces or residential units anticipated to have high employment-related or residence-related vehicle miles traveled (VMT). The fees could be set at county, jurisdiction, or TAZ level, usually on a $/sqft basis for commercial development and $/unit basis for residential development. Draft Blueprint applies VMT on new office development based on the county and associated VMT per worker associated with the TAZ to incentivize development inside low-VMT job centers.
• This diagram illustrates the modeling steps in BAUS:
  • BAUS has three types of VMT fees - "com_for_res" (apply fees on commercial development to subsidize residential development), "res_for_res" (apply fees on residential development to subsidize residential development), and "com_for_com" (apply fees on commercial development to subsidize commercial development).
  • Each parcel is assigned a "vmt_res_cat" value and a "vmt_nonres_cat" value based on its categorized VMT-level. This is then mapped to the fee table to decide the fee amount for new residential and commercial development on the parcel.
  • During each model iteration period (currently five years), VMT fees collected from new development go into one of the two accounts - "vmt_res_acct" and "vmt_com_acct" - for each geography (regional or sub-regional). Policies that aim to support/incentivize certain types of housing development or commercial activities can draw funding from respective account. In Draft Blueprint, VMT fees revenue is not applied into any job/housing incentive, but is accumulated to help to understand how much revenue is raised to support other economy strategies.

Jobs-housing Balance Fee (Draft Blueprint)

• Apply a regional jobs-housing linkage fee to generate funding for affordable housing when new office development occurs in job-rich places, thereby incentivizing more jobs to locate in housing-rich places. The $/sqft fee assigned to each jurisdiction is a composite fee based on the jobs-housing ratio and jobs-housing fit for both cities and counties.
• Modeling jobs-housing fee in BAUS:
  • Jobs-housing fee is tracked in BAUS under the "jobs_housing_com_for_res" account at the county level, which is similar to the "com_for_res" account of the VMT strategy.
  • In each model interation period, jobs-housing fees applies to new office development in each county based on the $/sqft level of jurisdiction where the development occurs. The fees collected goes to each county's account.
  • The account then acts similarly to the county-level lump-sum account to subsidize affordable housing in that county.

Office Lump Sum Account (Final Blueprint)

• Similar to the residential funding lump sum account, office lump sum account provides funding to subsidize office development in targeted areas.

Base Year GeoDatabase

• 03_04_2020_parcels_geography.csv. When this file is updated, update datasources.py.
• 2015_08_29_costar.csv (to be added)
• 2018_05_23_parcel_to_maz22.csv (to be added)
• 2018_10_17_parcel_to_taz1454sub.csv (to be added)