UrbanSimOPUS Real Estate Development model

1
UrbanSim\OPUS Real Estate Development model

• Notes prepared by
• Jesse Ayers
• Maricopa Association of Governments
• Last revised 1/29/2009

2
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 models outputs
• The Development Project Proposal Regression Model
• The Development Project Proposal Sampling Model
• The Building Construction Model

3
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

4
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

5
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

6
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

7
DPPRM 1st step

• Determine if there is already a
  development_project_proposals dataset, if so, add
  any new proposals to it, if not, create a new one
• 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_constraint
  s and determine which templates can be built on
  each parcel (see next slide)
• 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_constraint
  s and determine which templates can be built on
  each parcel (see next slide)
• Turn over the development_project_proposals
  dataset to the 2nd stage of the model

8
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

9
(No Transcript)
10
DPPRM 2nd step

• Predicts expected sale price of each proposal
  (proposed and tentative) using the Real Estate
  Price Model specification and parameter estimates
• 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

11
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.

12
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)

13
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

14
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 parcelgtbuildingsgtdemolition_c
  ost_per_sqft dataset)

15
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

16
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

17
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

18
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

19
BCM Dependencies

• Models required prior to BCM
• DPPSM
• Datasets required
• velocity_functions
• development_project_proposals
• development_project_proposal_components
• buildings
• building_types
• parcels

20
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)

21
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_com
  ponents 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

22
What does a planned proposal look like in terms
of records in the various the datasets?
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_compone
nts() function in the development_project_proposal
_component_dataset.py
This set of records represents one fairly dense
SFR proposal that will be built by the model
system starting in year 2011
23
Identifying relationships between datasets
24
Column notes
These can be 0 here because we dont care,
is_active 0 so this template will only be used
for planned proposals
0 builds regardless of existing buildings, 1
demolishes existing buildings
Cost per unit in terms of these units (e.g.
98.7067 1933 190,800)
Unique IDs
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
represents multiple free-standing buildings with
different uses. I honestly dont know how
extensively it is used without further research.
Update 3/18/2009 this affects the
units_proposed.py variable at urbansim_parcel.deve
lopment_project_proposal.
5 year plan with those percentages built per year
25

• 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