UrbanSim\OPUS Real Estate Development model Notes prepared by: Jesse Ayers Maricopa Association of Governments Last revised: 1/29/2009.

UrbanSim\OPUS Real Estate Development model

Notes prepared by:Jesse Ayers

Maricopa Association of GovernmentsLast revised: 1/29/2009

Real Estate Developer Model

• The “Developer Model” is really a series of 3 OPUS models that run in sequence. Each model depends upon the previous model’s outputs:– The Development Project Proposal

Regression Model– The Development Project Proposal Sampling

Model– The Building Construction Model

Some important terms• ‘development proposal’ or simply ‘proposal’

– at its most basic level: a record in the development_project_proposals dataset representing active, proposed, planned, tentative, or ‘id_with_velocity’ development

• A proposal can be:– ‘active’ = this status only informs the BCM as to what to do during a single

simulation year, this status is only written by the DPPSM– ‘proposed’ = a proposal placed in the development_project_proposals dataset

manually (by us) that we want to take precedence over tentative proposals– ‘planned’ = a proposal placed in the development_project_proposals dataset

manually (by us) that we definitely want to build– ‘tentative’ = a proposal placed in the development_project_proposals dataset by

the DPPRM, aka a simulated proposal– ‘id_with_velocity’ = a proposal that is developing across simulation years

• ‘dataset’ = an OPUS table, it could reside on disk (cache) or in memory, its columns (attributes) can be:

– primary = a column on a dataset written to disk (in the cache), the data model diagram shows primary columns

– computed = a column on a dataset that is calculated from an expression, often these only reside in memory and are not written to the cache unless we ask OPUS to do it in the model code, or using an indicator

Development Project Proposal Regression Model (aka DPPRM or

Expected Sale Price Model)

• General description:– 1st step

• Produces a dataset containing proposals (development_project_proposals) that conform to development_constraints

• development_project_proposals contains all proposals that are possible for each developable parcel, regardless of whether they will actually get built

– 2nd step• Predicts the expected sale price for the proposals produced

by the 1st step

DPPRM Dependencies• Models required prior to DPPRM:

– None known, but requires an estimated REPM (uses REPM specification and coefficients datasets)

• Datasets required:– parcels– development_templates– development_template_components– development_constraints– real_estate_price_model_coefficients– real_estate_price_model_specification

What is in the development_project_proposals

dataset in the base year?

• Nothing, if you want all development to be simulated from templates subject to development_constraints. In this case, this dataset is created and populated by the DPPRM.

• However, it can be pre-populated with records if there is information known about development that will happen on a particular parcel in a future year

DPPRM 1st step1. Determine if there is already a development_project_proposals

dataset, if so, add any new proposals to it, if not, create a new one2. Create proposals for new development

– Filter parcels: parcel_filter_for_new_development expression (currently the parcel must have some vacant land)

– Check these parcels against development_constraints and determine which templates can be built on each parcel (see next slide)

3. Create proposals for re-development– Filter parcels: parcel_filter_for_redevelopment expression (currently

the parcel must have a low improvement value to total value ratio)– Check these parcels against development_constraints and determine

which templates can be built on each parcel (see next slide)4. Turn over the development_project_proposals dataset to the 2nd

stage of the model

development_constraints dataset

• Notes:– Responsible for limiting proposals on parcels– Each record is a rule that states what type and density of proposal is

allowed– Matching column names in the parcels and development_constraints

datasets determine which constraints apply to which parcels (in seattle_parcel only ‘plan_type_id’)

– Knowing information about the parcel, applicable development constraints, and available development templates the DPPRM can determine which templates are allowed on which parcels

• Column information:– ‘generic_land_use_type_id’ is the type of proposal that this constraint

allows– ‘constraint_type’ combined with ‘minimum’ and ‘maximum’ set limits on

FAR or units_per_acre– The value ‘-1’ in minimum or maximum is interpreted as unconstrained

DPPRM 2nd step

1. Predicts expected sale price of each proposal (proposed and tentative) using the Real Estate Price Model specification and parameter estimates

2. Adds the expected sale price (unit_price_expected) to the development_project_proposals dataset, marks the status_id as ‘4’ (‘tentative’ or possible) and writes the dataset to the cache

Recap DPPRM

• Populates the development_project_proposals dataset with proposals that are possible on parcels subject to the development_constraints and assigns them a status_id of ‘4’ (‘tentative’ or possible)

• Predicts their expected_sale_price based on the REPM• There could also be records in this dataset from past

simulation years that have a status_id of ‘7’ which means ‘id_with_velocity.’ They will remain there until they are built out according to their velocity curve

• There could also be records here that have a status_id of ‘3’ which means ‘planned.’ Planned proposals are definitely going to happen when the start_year comes up regardless of development_constraints that apply to the parcel or existing buildings on the parcel.

Development Project Proposal Sampling Model (aka DPPSM or

development_proposal_choice_model)

• General description:– Takes the development_project_proposals dataset

and calculates an expected return on investment for proposals where status_id = 2 (proposed) or 4 (tentative)

– Evaluates overall demand for new housing units and job space (via vacancy rates)

– Chooses which proposals get built to satisfy the demand (via sampling weighted by ROI)

– Marks the proposals to be built (sets their status_id = 1)

DPPSM Dependencies

• Models required prior to DPPSM:– DPPRM

• Datasets required:– development_project_proposals– development_project_proposal_components– development_templates– development_template_components– buildings– parcels– target_vacancies– building_sqft_per_job– demolition_cost_per_sqft

Calculating ROI

• Calculated for proposals as:– (expected sale price - expected

costs)/(expected costs)

• Expected costs takes into account:– Assumptions on construction costs (per “unit”

from the project proposal)– Assumptions on demolition costs for

redevelopment (aggregated from the parcel>buildings>demolition_cost_per_sqft dataset)

Evaluate demand for new proposals

• Determine which building_types are accepting new proposals by calculating the vacancy rate

• If the vacancy rate is less than the target vacancy rate set in the target_vacancies dataset (by building_type and year), then mark that building_type as accepting new proposals

Determine which proposals are built

• For building types accepting new proposals, select a weighted sample (weighted by ROI) of eligible proposals

• Go through sampled proposals and “build” them (set status_id = 1, active), building ‘proposed’ (status 2) proposals first, and ‘tentative’ proposals next, until:– target_vacancy rate is met, or:– there are no more proposals, while:– only building 1 proposal per parcel, per year, and:– marking buildings to be demolished on parcels being re-

developed, and:– always building planned proposals, regardless of

development_constraints, existing buildings, or available space

Recap DPPSM

• Calculates the ROI for proposals

• Determine demand for new proposals based on vacancy rates

• Sample proposals (weighted by ROI) and ‘build’ (set status_id to ‘active’) them until vacancy rates are satisfied

• Check for any planned proposals and set their status to ‘active’

Building Construction Model (aka BCM)

• General description:– Demolishes buildings marked by the previous model

for re-development (deletes them from the buildings dataset, unplacing any households or jobs that occupy them)

– Takes proposals marked as active or id_with_velocity and builds the appropriate type and number of buildings according to the velocity curve (adds records to the buildings dataset)

– If the proposal is not “built out,” meaning it has not reached the end of the velocity curve, it is marked as or remains ‘id_with_velocity’ in the development_project_proposals dataset to continue being built the next simulation year

BCM Dependencies

• Models required prior to BCM:– DPPSM

• Datasets required:– velocity_functions– development_project_proposals– development_project_proposal_components– buildings– building_types– parcels

Recap of the entire developer model

• The DPPRM selects proposals that are possible to be built, and predicts their expected price

• The DPPSM selects exactly which proposals actually get built based on ROI weighted sampling and demand for space (vacancy rates)

• The BCM adds or deletes records in the buildings dataset and properly accounts for households or jobs unplaced due to demolition (marks their building_id as -1)

How do I create a proposal I know is going to get built at a certain

time? (a planned proposal)• Create the development_project_proposals dataset for the base

year and populate it with a record to represent the proposal as a whole. Set the status_id to ‘3’ (planned) if you definitely want it to build, or ‘2’ (proposed) if you want it to be considered before status ‘4’ (tentative)

• Create corresponding records in the development_templates and development_template_components datasets– If you want this template to only be used for your known proposal, add a

field to the development_templates dataset called ‘is_active.’ Set the value to ‘0’ for templates that should not be used as simulated proposals and ‘1’ for templates that should

• Be sure there is a velocity_functions dataset with the appropriate functions

What does a planned proposal look like in terms of records in the

various the datasets?

This set of records represents one fairly dense SFR proposal that will be built by the model system starting in year 2011:

Update 3/17/2009: it turns out that the development_project_proposal_components table is not a required table in the base year for a planned project proposal. The model system will construct this table automatically. For details, see the create_from_proposals_and_template_components() function in the development_project_proposal_component_dataset.py

Identifying relationships between datasets

Column notes

Unique IDs

Update 3/18/2009: this

affects the units_proposed.p

y variable at urbansim_parcel.development_project_proposal.

Cost per unit in terms of these units(e.g. 98.7067 * 1933 = $190,800)

100 = a single free-standing building.Multiple component records with this adding

up to 100 represent a single building w/ multiple uses.Multiple component records each = 100 representsmultiple free-standing buildings with different uses. I

honestly don’t know how extensively it is used without further research.

0 = builds regardless of existing buildings, 1 = demolishes existing buildings

These can be 0 here because we don’t care, is_active = 0 so this template will only be used

for planned proposals

5 year plan with those percentages

built per year

• How many SFR homes will this planned proposal build?• assume parcel_id.parcel_sqft = 87120 (2 acres)• int(2 / 0.09426) = 21 units• approximately 4 units per year, according to velocity_function_id = 1

• What if we changed these values in the development_templates dataset:• land_sqft_min = 2,177,999 (just shy of 50 acres)• land_sqft_max = 3,049,201 (just over 70 acres)• is_active = 1 (meaning the template itself can also be proposed by the DPPRM)

• Then, if it were selected by the DPPSM:• assume parcel_id.parcel_sqft = 2,500,000 (57.39 acres)• int(57.39 / 0.09426) = 609 units• roughly 122 units per year, according to the velocity function