Development Projects¶
Development projects represent a known real estate development pipeline and can be inserted directly into simulations. Large development projects are planned years in advance. In such cases, it is useful to be able to insert these projects into an UrbanSim simulation and see them reflected in results. Additionally, the development project feature can serve as a development project pipeline database to track projects in the region over time.
Examples of development projects¶
Examples of development projects can include a large single-family subdivision that covers many acres of land or an office tower in a downtown area, among others.
Creating a new development project¶
Name¶
Name (Required)
The name of the development project should be distinct.
Based on
New development projects can be based on existing records to quickly create or edit new records.
Note
The records available in the Based On dropdown menu currently only shows the names of records that are visible to you in the first page of your table of records. If you do not see a record in the list that you would like to use for Based On, use the table search or filter functions to first create a view of records in the table for which you want to have available in the Based On dropdown menu. This is designed to limit the number of records that appear in the dropdown menu when there are voluminous numbers of records in your table.
Location¶
Select geometry (Required)
Select the zone(s) that the project will be located in. Click here for more information on how to select polygons.
Descriptive location (Optional)
General description of project location.
Street address (Optional)
Physical street address, city, state or province, ZIP code or postal code of the project.
Building¶
Building type (Required)
Select the project building type from the drop-down list. For projects that include multiple building types, separate development projects should be created for each building type.
Note
Building types can be customized. To do this, send us a list of your region building types here denoting the name of the building type and the category: residential, non-residential, mixed (e.g. mixed residential and non-residential).
Real estate developer (optional)
Name of the project developer.
Number of buildings and Floors (optional)
Set the total number of buildings and the average number of floors in the buildings in the development project. These fields are optional and are not currently utilized by the zone model, however for users interested in transitioning to the parcel model at a future date it is a required field in the parcel model.
Building program (optional)
The residential building program specific to the development project to (Example: Senior, veteran etc.). Additional categories can be added upon request here. This field is not currently utilized by the zone model and is optional.
Group-quarters and Population / beds (optional)
If the project offers group-quarters, specify the category (Example: Assisted living, dormitory etc.) and the number of people or beds that can be accommodated. Additional categories can be added upon request here. This field is not currently utilized by the zone model and is optional.
Attributes¶
Residential
For residential development projects, set the number of residential units and average unit size. You have the option to break down the units by market rate and affordable, although the zone model does not currently utilize this information.
Residential units and Average unit size (Required)
The total number of residential units and the average unit size (square meters) in the development.
Tenure (Optional)
Own units:
The percent or number of units that will be owner occupied.Rent units:
The percent or number of units that will be renter occupied.
Unit type (Optional)
Market rate:
The percent or number of units that will be market rate. The default is 100%.Affordable Housing Program:
The percent or number of units that will be affordable. The default is 0%. If the number of affordable units is greater than 0, then an additional section is available to specify the type of program the affordable units belong to.
Program (Required only if affordable units exist):
Type of affordable housing program
Inclusionary:
In the United States, inclusionary affordable housing programs legally require a development project to include affordable units at specific Area Median Income (AMI) levels. If this development is subject to an inclusionary requirement, specify the AMI level (percent) and the number of affordable units that fall within that category. Multiple AMI levels can be specified using the green plus button. In some locations in the United States, inclusionary can also be referred to as a unilateral agreement, among other terms.Other:
The ‘other’ affordable housing program category can be used if the development does not have an inclusionary requirement and is instead governed by a different type of affordable housing program. If ‘other’ is used, the number of affordable units in the ‘other’ program category will equal the total number of affordable units.Both:
‘Both’ allows you to use both the inclusionary and ‘other’ categories if the development project is subject to more than one affordable housing program type.
Non-Residential
For non-residential types, set the employment capacity or the total square meters and square meters per job. Either one of the inputs are required.
Employment capacity
The total number of job spaces available in the development.
Non-residential space and Space per job
The total non-residential space (in square meters) in the development and the average space per job (in square meters).
Mixed residential & non-residential
For mixed types, set both the number of residential units and average unit size and non-residential attributes. See the preceding sections for information on the respective residential and non-residential fields.
Duration & Start Year¶
Duration and Start year (Required)
Set the construction duration in months and the construction start year of the development.
Phased Development (Optional)
Optionally, you can phase the number of units (market rate and or affordable), square footage, or employment capacity of development that comes online over the construction period in annual increments. If no phasing is specified, the units, square footage, or employment capacity is uniformly inserted into the simulation over the construction period. Otherwise, the phased values specified will be utilized.
Status¶
Status (Required)
The status drop down denotes the certainty that the project will be constructed or that it has already been constructed. In general the categories can be interpreted as: completed: project has already been built; committed: project is likely to be built; proposed: there is some amount of uncertainty if project will be built.
Redevelopment
If redevelopment is toggled on (toggle is blue), all existing residential units and employment spaces on the selected zones will be removed and replaced with the values specified in this development at the start of the project’s construction. If redevelopment is off, the development is added to existing units and job spaces. The default is off. It is important to note that if you have separate multiple development project records on the same zone, it is suggested you leave the redevelopment toggle off so that you do not inadvertently wipe out the new households or jobs that will be inserted from other projects on that site.
Other¶
Tags (Required)
Tags are applied to development projects so they can be linked with scenarios.
Identification (Optional)
A project can be given a user specified identification (ID). This ID can be different from that used by UrbanSim and is intended to be used to connect or join the development data to other external data sources outside of the platform.
Source (Optional)
You can reference where the source of the information on the development project came from.
Notes (Optional)
Notes can be added to include any other pertinent information for greater context.
Editing an existing development project¶
Select the development project to edit from the Developments table and click on the edit icon.
Make the desired changes in the form view.
Click Save edits.
Deleting an existing development project¶
Note
At this time you are unable to undo a deletion.
Select the development project to edit from the Developments table and click on the edit icon.
Click Delete in the editor form.
Confirm the deletion.
Generating a development project report¶
With the development project report tool you may download a CSV of your development projects, tag development projects with IDs from uploaded summary geography polygon shapefiles for use outside of the platform and generate summary statistics of development project attributes that fall within the polygons. By clicking on the Download Report button in the development project table, you may do the following:
All Development Projects
Download all your development projects as a CSV file to your local machine. The CSV will contain all data associated with your development projects and will include an additional column denoting the project zone ID.
Tag all your development projects with the ID of a uploaded summary geography file (e.g. polygons of neighborhood districts etc.) and then download all your development projects as a CSV file to your local machine. Tagging is performed by intersecting the zone polygon of development projects with the polygons in the uploaded data and assigning the summary geography ID based on the largest percent area overlap. Multiple files can be specified and processed at the same time. The resulting CSV will have columns denoted as [NAME OF UPLOADED FILE]_polygon_id that contain the polygon_id of the intersected polygon.
Summarize by Geography
Generate summary statistics for all development projects using a uploaded summary geography file (e.g. polygons of neighborhood districts etc.) and then download the result as a CSV file to your local machine. Results include min, max, mean, sum of units, square footage, building types, and other attributes that fall within each summary geography polygon. The CSV will contain a polygon_id column that holds the ID of the polygon in the uploaded file that the summary statistics belong to.
Notes¶
Relationship between development projects and constraints
Development projects are allowed to override capacity constraints.
Dealing with projects with unknown attributes
If information for a project is unclear or unavailable at the time of the initial creation of the development project record in UrbanSim, you may estimate attributes of the development project. Estimated attributes can be clarified and updated as better information on the project is received. You may use notes to mark estimated records and to keep track of estimated parameters. In addition, you may use specific tags on projects to specifically denote estimated records for which you can choose to include or not include in a simulation. Source can also be used to denote the certainty of the project construction.
Non-residential space in the zone model
Note
Non-residential space in the zone model is represented as employment capacities, which can be adjusted with development projects. However, for non-residential space to be directly represented with multiple building types this can be achieved through a consulting contract with us to load your preferred source of user-provided non-residential built-space data, such as in the Unites States: the county assessor or data vendors such as Costar. To learn more see here and contact us here.
Bulk upload of development projects
Note
The bulk upload of existing development projects is available by request here as long as the data schema is followed.
Representing development projects as parcels instead of zones
Note
For regions that wish to directly represent their development projects as parcels instead of zones, this is supported however you must request this feature in advance as part of your consulting contract. To learn more contact us here and consult the parcel model development projects page.
UrbanSim’s use of status and representation of phased development
Note
The default model system does not currently utilize project status to differentiate the likelihood a project will get built. By default all projects have the same likelihood of being built. However, this behavior can be modified. In addition, the current default behavior of the model system will distribute the attributes of a project uniformly over the years of its construction duration. However, this behavior can be instead modified in the following ways: 1) if you are phasing the attributes of the project over time, the phased attributes of the project will be built in the year specified; or 2) all attributes of the project will come on line at the end year of its construction duration. To change the default behaviour please contact us here.