1 / 25

UrbanSim\OPUS Real Estate Development model

UrbanSimOPUS Real Estate Development model. Notes prepared by: Jesse Ayers Maricopa Association of Governments Last revised: 1/29/2009. Real Estate Developer Model.

lamya
Télécharger la présentation

UrbanSim\OPUS Real Estate Development model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 model’s 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_constraints 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_constraints 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. 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

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

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

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

  13. 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)

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

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

  16. 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’

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

  18. BCM Dependencies • Models required prior to BCM: • DPPSM • Datasets required: • velocity_functions • development_project_proposals • development_project_proposal_components • buildings • building_types • parcels

  19. 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)

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

  21. 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_components() 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:

  22. Identifying relationships between datasets

  23. These can be 0 here because we don’t care, is_active = 0 so this template will only be used for planned proposals Column notes 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 don’t know how extensively it is used without further research. Update 3/18/2009: this affects the units_proposed.py variable at urbansim_parcel.development_project_proposal. 5 year plan with those percentages built per year

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

More Related