Data Overview

The UrbanSim block-level model template operates at the U.S. Census block level of geography. All the tables listed below are supplied for your region by UrbanSim unless otherwise specified. The core tables in this model template are:

Blocks:

Built Space:

Agents:

Capacities (optional but recommended)

Rents and Prices:

The core block geometry and attribute, residential units, households, persons, and jobs tables as well as the ancillary building types and job sector IDs tables come pre-built with a block-level model UrbanCanvas Modeler subscription.

The default block-level model simulates the addition and/or movement of individual household and job records in the region and the construction and demolition of built space. The households table contains one record for each household in the region that links to a persons table that contains a record for each person in a household. Employment is represented with the jobs table which contains one record for each job in the region. Residential built space is represented with the residential units table which contains one record for each residential unit in the region. Non-residential built space is not explicitly represented in the block model owing to the lack of public nationwide data. Non-residential space is instead a construct of zoned block employment capacities supplied by users. Each table has a unique identifier field, a block ID Federal Information Processing Standard (FIPS) field, as well as fields representing agent characteristics.

Each new agent introduced into the simulation is allocated to a particular block in the region using multinomial logit-based location choice models, estimated off of local data. The blocks table, which contains one record for each block in the region, represents the base geography of the block template. When allocating households to blocks, rent and price is often a key explanatory variable, and residential price models can be estimated using UrbanSim’s default Census rent or price data or from datasets that the user has uploaded.

The primary data schema difference between the block-level model and the parcel-level model is that the tables representing agents (e.g. households and jobs) in the block model are associated with Census blocks rather than individual buildings on parcels. In a typical parcel-level model, space is represented by buildings and parcels, and each agent has a building_id. In a block-level model, space is represented by blocks (and attributes of the blocks table), and each agent has a block_id.

The block and zone-level models operate in a similar fashion and have similar data schema requirements. The main difference between block and zone models is the requirement of zone model users to provide the zonal base geography and the synthetic agent datasets when public data are unavailable.

Because the simulation operates at the block-level, model output can be summarized at any geography at the block level or coarser (e.g. tracts, zones, counties).

UrbanCanvas: Core Base Year Data

Both the block geometry and building types table are supplied by UrbanSim and are required to initialize the UrbanCanvas user interface for new subscribers.

Block geometry

UrbanCanvas Modeler requires a zipped (.zip) shapefile of regional Census Block geometries with the same block identifier that is used in the simulation block attributes table. This shapefile will be used as the base data geometry in the UrbanCanvas user interface and database. See Table 1 for the data schema. The block identifier (block_id) must be unique 2010 Census FIPS codes as a strings. The block_id is used to link data created and uploaded into UrbanCanvas (e.g. development projects, constraints, etc.) with the core UrbanSim simulation data. This identifier will be displayed in the user interface for reference in the map and tables. UrbanSim will provide these data for you to initialize your user account however you have the option to upload new data and change these geometries if needed.

Note

Upon the initialization of your block geometry in UrbanCanvas Modeler, if any changes or updates to the geometries are required after the initial upload you can change it at anytime if you do not have any existing development projects, constraints, or adjustments in your account. If these data exist in your account and you would like to change the block geometry and or the building types table set in the initialization collection please contact us here for assistance.

Table 1: Block Geometry

Column Name

Data Type

Required

Description

block_id

String

Yes

Block 2010 Census FIPS: FIPS code.
block_ids must be identical to the block_ids
in the block attributes table

Building types (Optionally supplied by user)

Block model users will have a default building type table supplied by UrbanSim upon the creation of your account with the following building types in Block Model Default Building Types table. However, if you wish to utilize custom named building types, this can be achieved by working with us through a consulting contract. Contact us here for more information and see the the data schema below.

UrbanCanvas Modeler requires a table of regional building types that exist in the simulation. This table is also used to initialize the building type categories available when creating new development projects from within the UrbanCanvas Modeler user interface. The building types table contains the typology of building types to use in the model. See Table 2 for details on the data schema.

Note

Upon the initialization of your supplied building types table in UrbanCanvas Modeler, if any changes or updates to the table are required after the initial upload you must contact us here for instructions.

Block Model Default Building Types

Building Type ID

Building Type Name

Residential

1

Single-family owned

Yes

2

Multi-family owned

Yes

3

Single-family rental

Yes

4

Multi-family rental

Yes

5

Non-residential

No
Table 2: Block Model Building Types Table

Column Name

Data Type

Required

Description

building_type_id

Integer

Yes

Unique identifier for the building type. By default
values can correspond to the building_type_ids in the
default Block model building types table.

name

String

Yes

Name of the building type. Name will be displayed in the
user interface as a reference.

is_residential

Boolean

Yes

True if building type can have a residential
component, else False

is_non_residential

Boolean

Yes

True if building type can have a
non-residential component, else False

is_rent

Boolean

Yes

True if building type tenure is renter occupied,
else False

is_own

Boolean

Yes

True if building type tenure is owner occupied,
else False

description

String

No

Description of the building type

is_other

Boolean

No

True if building type is not a residential or a non-residential
building type, else False. Can be used to separately
track other types of buildings such as hotels and resorts.
Not currently used by default in the model.

Simulation: Core Base Year Data

Blocks

Block attributes

The blocks attribute table is the core geographic table in the block model, and it contains one record for each block. Each agent in the simulation is associated with a particular block. The blocks table is to the block model what the parcel table is to the parcel model: a representation of land, a spatial look-up for summary geographies, the link to network data for accessibility queries, and the link to development constraint information. The block_ids in the blocks table are 2010 Census FIPS codes. UrbanSim will provide these data for you to initialize your user account however you have the option to upload new data and change these attributes if needed. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

See Table 3 for the data schema. Note in particular the residential_unit_capacity and employment_capacity fields. These are populated initially with high placeholder values representing unconstrained capacity, and users should provide their own capacity data using one of these options.

Ways to represent block capacity

Type

Units

Reference link

Development capacities

Job and residential unit capacity

Block capacities

Development constraints

Max employment and dwelling units per acre

Development constraints

Regional zoning

Max floor-area ratio (FAR) and dwelling units per acre

Zoning data schema

The base year placeholder capacity values in the residential_unit_capacity and employment_capacity fields can be updated to reflect known base year capacities using any of the three options above. Development capacities can be directly represented as job and residential unit development capacities and uploaded to your base data collection when following the block capacity data schema. This is the most direct method of providing base year capacities and can either be applied as a stand-alone table of capacities (recommended) or can be appended as columns to the existing block attribute table, but cannot be represented as both. Development capacities can also be represented by regional development constraint data using employment and residential unit densities. The model will translate densities directly into capacities. This is designed for use in scenario development but can be used to update base year capacities. Data can be bulk uploaded upon request here. In addition, development capacities can be represented by regional zoning data that follows the block model zoning data schema. Once uploaded, these data can be converted to development constraints using the zoning to constraint conversion tool and will be represented as max development densities. The model will translate the derived densities directly into capacities. This is designed for use in scenario development but can be used to update base year capacities.

The block residential rents and price information available by default from UrbanSim is found in the corresponding res_rents and res_values fields in the block attribute table. These fields are created using a process that applies block-group level 2009-2013 5-year American Community Survey (ACS) estimate rent and price data from ACS tables B25058 median contract rent (dollars) for renter-occupied housing units paying cash rent to represent residential rents and B25077 median value (dollars) for owner-occupied housing units to represent residential price values. Each block that occupies the block-group is assigned the same value. When values are suppressed at the block-group level, subsequent coarser geographies are used for this information when it is available at the tract and or county level. To use other sources of residential rents and prices in place of the defaults please contact us here to incorporate your data and consult the rent and price data uploaders available in the user interface.

Table 3: Blocks Table

Column Name

Data Type

Required

Description

block_id

String

Yes

Block 2010 Census FIPS: FIPS code. FIPS codes
for other geographies (e.g. tract, county) parsed
from this. Must correspond to the block geometry block_id.

puma10_id

String

Yes

PUMA 2010 ID.

place_id

String

Yes

2010 Census Designated Place ID (See [1]).

x

Float

Yes

Longitude coordinate of block centroid.

y

Float

Yes

Latitude coordinate of block centroid.

res_rents

Float

Yes

Median residential rent for renter-occupied housing units.

res_values

Float

Yes

Median value of owner-occupied housing units.

square_meters_land

Float

Yes

Block land area in square meters (excludes water).
Default values are derived from the Census TIGER Block ALAND field

node_id

Integer

No

Network node ID. A computed attribute: nearest
OpenStreetMap street network node ID (street intersection).

residential_unit_capacity

Integer

No

Total residential unit capacity of block
as implied by zoning and other development constraints.

employment_capacity

Integer

No

Total employment capacity of block as implied
by zoning and other development constraints.

location_id

Integer

No

If using an optional non-residential
space table with area per job table, a location ID
can be added to tie to the area per job table location_ids

Built Space

Residential built space is represented with the residential units table which contains one record for each residential unit in the region. These data are supplied by UrbanSim. Non-residential built space is not explicitly represented in the block model owing to the lack of public nationwide data. Non-residential space is instead a construct of zoned block employment capacities supplied by users. See the non-residential space section for more information on how non-residential space is derived.

Residential Units

The residential units table contains disaggregate residential unit data for residential buildings the region, with each row pertaining to one residential unit. Each unit must be tied to a specific block in the blocks table using block_ids. Optionally, you may also specify du_id in the households table to tie households to residential units, however this is discouraged for use with the default block model. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

The disaggregate residential units table is created using a process that applies tract and block-group level 2009-2013 5-year American Community Survey (ACS) estimate characteristics to block-level observed 2010 Summary File 1 (SF1) residential unit counts. ACS table B25127 provides household estimates for tenure by units_in_structure by year_structure_built, and this information comes at the census Tract level. ACS table B25032 provides block-group level estimates of tenure by units_in_structure. ACS table B25036 provides block-group level estimates of tenure by year_structure_built. Using the block-group tenure by units_in_structure data and tenure by year_structure_built data as marginals, an iterative proportional fitting (IPF) procedure is run for each block-group, with the tract-level tenure by units_in_structure by year_structure_built joint distribution as a seed, and the result is block-group level estimates of this joint distribution. This is then scaled so that the totals match the block-group level sum of residential units by block from the 2010 Census. What results is block-group level residential units by type, which are then allocated to the census block-level allocating from block-group to block according to the number of residential units in each block and the observed block-level tenure proportions. The final table reflects 2010 SF1 residential unit block counts and ACS marginals from the block-group and tract levels. See Table 4 for the fields in the residential units table and see Table 2 for the building type categories. UrbanSim will provide these data for you to initialize your user account however you have the option to upload new data and change these attributes if needed.

Table 4: Block Model Residential Units Table

Column Name

Data Type

Required

Description

du_id

Integer

Yes

Unique dwelling unit record identifier

block_id

String

Yes

Block 2010 Census FIPS. Must correspond to
the block_ids in the block attribute table.

building_type_id

Integer

Yes

Type of residential structure. See the building types table
if using the default building types. Otherwise values must correspond to
the residential building_type_ids in the building types table.

year_built

Integer

No

Year of construction.

Non-residential Space (Available via consulting contract)

Non-residential built space is not explicitly represented in the block model owing to the lack of public nationwide data. Non-residential space is instead a construct of block employment capacities typically represented as zoned employment capacities. These capacities can be adjusted with development projects and constraints. For non-residential space to be directly represented with multiple building types this can be achieved through a consulting contract to load your preferred source of non-residential space data, such as the county assessor or data vendors such as Costar. To learn more, contact us here. The non-residential space table gives quantities of non-residential area by block with one row per block and one column for each non-residential building type. See Table 5 below for the fields in the non-residential space table. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

Table 5: Block Model Non-Residential Space Table (Default)

Column Name

Data Type

Required

Description

block_id

String

Yes

Block 2010 Census FIPS. Must correspond to
the block_ids in the block attribute table.

mean_year_built

Integer

Yes

Mean year of construction for non-residential
structures. If using custom building types, this column must
be named mean_year_built_btype_[BUILDING_TYPE_ID]
where each non-residential building
type is represented with its own column.

sqft_5

Integer

Yes

Total sqft of structures of building type 5 (non-residential) in Census Block.
If using the default Block model building types
value corresponds to the building_type_ids in the
default block model building types table. Otherwise if using custom building types,
this column must be named non_res_sqft_btype_[BUILDING_TYPE_ID] where
each non-residential building type is represented with its own column.

Note

If you are not using the default block model non-residential building types and are using the optional non-residential space table, you must also have an area per job table.

Area per job (required only if using Non-Residential Space)

The area per job table contains the non-residential square footage each job will occupy in each building type, or optionally in each combination of building type and block as denoted with the use of a location_id that corresponds to the location_id in the block table. This information is used in the calculation of both the number of job spaces of each building type in each block and non-residential vacancy rates. This table must have a building_type_id that corresponds to the IDs in the building types table. The area per job table is optional and only required when using the optional non-residential space table.

Table 6: Block Model Area Per Job Table

Column Name

Data Type

Required

Description

building_type_id

Integer

Yes

ID of non-residential building
structure types that corresponds to the building types table.

area_per_job

Float

Yes

The unit of space required per job in square feet.

location_id

Integer

No

ID of geography that corresponds to a location ID
on the block table. Optional to use
to stratify area_per_job across different geographies in a region

Agents

Each agent table outlined below comes pre-built for your region with a block-level model UrbanCanvas Modeler subscription. Subscribers do not need to supply any of their own agent data however you may opt to use your own data in place of the pre-generated synthetic population and jobs data we supply as long as it is consistent with the data schemas outline here.

Note

If you wish to use different data than the pre-generated synthetic population and jobs data we supply, you may create your own synthetic data in the exact format prescribed in the schemas below and we can replace the data used in the model. Consulting contracts are available to have us at UrbanSim re-synthesize using more recent ACS data and re-allocate households to blocks. To learn more about either of these topics contact us here.

Households

Households

The disaggregate households table that comes with the block-level UrbanSim model is created using the Synthpop [13] population synthesizer using block-group level demographic marginals from 2009-2013 5-year American Community Survey (ACS) estimates. Synthetic households are then allocated from block group to block based on observed 2010 Summary File 1 (SF1) household counts by tenure and household size. Detailed household attributes are controlled at the block group level using ACS data and the block-group to block allocation is informed by 2010 SF1 counts. Synthpop household and person records are formatted in the UrbanSim schema. Any of the household characteristics in the table below can be utilized in model adjustments and household control totals. See Table 7. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

Table 7: Block Model Households Table

Column Name

Data Type

Required

Description

household_id

Integer

Yes

Unique household record identifier

block_id

String

Yes

2010 Census Block FIPS. Must correspond to
the block_ids in the block attribute table.

persons

Integer

Yes

Number of persons in the household (See PUMS NP variable)

income

Integer

Yes

Annual household income in 2013 dollars (See HINCP NP variable)

tenure

Integer

Yes

Tenure code of households (1 : own, 2 : rent) (See PUMS TEN variable [2])

serialno

Integer or String

No

Public Use Microdata Sample (PUMS) serial number (See PUMS SERIALNO variable)

cars

Integer

No

Number of vehicles in the household (See PUMS VEH variable [3])

race_of_head

Integer

No

Race code of head of household (See PUMS RAC1P variable lookup and [4])

age_of_head

Integer

No

Age of head of household (See [4])

workers

Integer

No

Number of workers (employed persons) in the household (See PUMS ESR variable [5])

children

Integer

No

Number of persons under age 18 in household (See PUMS AGEP variable [6])

recent_mover

Boolean

No

1 if household moved within last 5 years, else 0 (See PUMS MV variable [7])

hispanic_status_of_head

Boolean

No

1 if head of household is hispanic, else 0 (See PUMS HISP variable [11])

Note

Annual household and person income is in 2013 dollars, however you may request a different reference year by contacting us here. We can adjust the values to any year dollars based on the consumer price index (CPI).

Persons

The persons table contains disaggregate persons data for the region, with each row pertaining to one synthesized person. The persons table should have a household_id attribute corresponding to the household table that indicates which household each person is in. The UrbanSim transition model has the ability to keep the households and persons table in sync as it seeks to match values in the annual household control totals table. See Table 9 for the persons table data schema. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

Table 8: Block Model Persons Table

Column Name

Data Type

Required

Description

person_id

Integer

Yes

Unique person record identifier

household_id

Integer

Yes

Unique household record identifier. Must
correspond to the household table household_id.

member_id

Integer

No

PUMS person number (See PUMS SPORDER variable)”

age

Integer

No

Age of person in years (See PUMS AGEP variable)

income

Integer

No

Person annual income in 2013 dollars (See PUMS PERNP variable)

education

Integer

No

Person educational attainment (See PUMS SCHL variable lookup)

race_id

Integer

No

Race code of person (See PUMS RAC1P variable lookup)

hh_relationship

Integer

No

Person relationship to household (See PUMS RELP variable lookup)

sex

Integer

No

Person gender (1 : male, 2 : female) (See PUMS SEX variable)

student_status

Boolean

No

Person student status (See PUMS SCH variable [8])

worker_status

Boolean

No

Person worker status (See PUMS ESR variable [9])

hours

Integer

No

Person hours worked per week in past 12 months (See PUMS WKHP variable)

work_at_home

Boolean

No

Person worker status, where 1 if person works at home, else 0 (See PUMS JWTR variable [10])

hispanic

Boolean

No

1 if head of person is hispanic, else 0 (See PUMS HISP variable [12])

Note

Annual household and person income is in 2013 dollars, however you may request a different reference year by contacting us here. We can adjust the values to any year dollars based on the consumer price index (CPI).

Employment

By default, employment in the block model comes pre-built for subscribers as a disaggregated jobs table from the Census Longitudinal Employer-Household Dynamics (LEHD) program. Users have the option to use their own source of jobs data usually in the form of commercially available business establishment data with employee counts for each establishment. One or the other can be used to represent employment in the region but both are not required. Establishment data can be more difficult to collect and clean, but it can facilitate a more behavioral way to represent employment and allows for the use of future firmographic models. To learn more about this contact us here.

Jobs

The disaggregate jobs table provided by default by UrbanSim is created based on 2011 employment data by sector from the Census Longitudinal Employer-Household Dynamics (LEHD) program. LEHD estimates come at the block-level, and the estimates are then expanded into a full jobs table in the UrbanSim schema. The sector ids in the jobs table can be utilized in the default model adjustments and employment control totals. The home_based field is optional, and indicates whether the job is based in a residential unit. See Table 9 for a description of the jobs table columns, and see the LEHD Employment Sectors table for the sector typology. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

Table 9: Block Model Jobs Table

Column Name

Data Type

Required

Description

job_id

Integer

Yes

Unique job record identifier

block_id

String

Yes

Block 2010 Census FIPS. Must correspond to
the block_ids in the block attribute table.

sector_id

Integer

Yes

NAICS sector ID. See LEHD Employment Sectors table.
If using custom sector IDs, IDs must correspond to
the job sector IDs table

home_based

Boolean

No

Where 1 denotes the job must locate in a
residential structure

occupation

Integer

No

Identifier of occupation category

recent_mover

Boolean

No

1 if job moved within last 5 years, else 0

establishment_id

Integer

No

If jobs were generated from establishments
data, this is the unique establishment identifier for the
establishment for tracking purposes. Must correspond to
the establishment_ids in the establishments table.

Establishments (Optionally supplied by user)

If you wish to use different data than the pre-generated LEHD jobs data we supply, such as commercially available business establishment data, you may provide us your data and we can replace the data used in the model. You will need to supply the business establishment data and a separate csv table that lists the employment sector IDs and their corresponding industry name. Establishment employee counts will be transformed into a disaggregate jobs table for use in the model. To learn more about this contact us here. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

Table 10: Block Model Establishments Table

Column Name

Data Type

Required

Description

establishment_id

Integer

Yes

Unique establishment record identifier.

employees

Integer

Yes

Total number of employees in establishment

sector_id

Integer

Yes

Employment sector ID. Must correspond to the sector_ids
in the Job Sector IDs table.

block_id

String

Yes

Block 2010 Census FIPS. Must correspond to
the block_ids in the block attribute table.

home_based

Boolean

No

Where 1 denotes the establishment must locate in a
residential structure

recent_mover

Boolean

No

1 if establishment moved within last 5 years, else 0

Job Sector IDs (supplied by UrbanSim)

The job sector ID table denotes all the unique employment sector IDs that are utilized in either the jobs or establishment tables. This table must have the sector_id and corresponding sector name as columns. This table will be used in UrbanCanvas as a reference in the user interface and to generate indicators. If using the default LEHD derived jobs data provided by UrbanSim, the job sector ID table is provided for you populated with the LEHD employment sectors below. If you are using custom job or establishments data with sector IDs that differ from the block model defaults, then a Job Sector ID table will need to be supplied using the data schema below. An unlimited number of optional columns may be added to this table for use, however the model will interpret the columns listed as optional below by default.

Table 11: Block Model Job Sector ID Table

Column Name

Data Type

Required

Description

sector_id

Integer

Yes

Unique employment sector ID. Represents the corresponding
sector_ids in the jobs or establishment tables.

name

String

Yes

Name of employment sector. This name will be used as a
reference and displayed in the UrbanCanvas user interface.
LEHD Employment Sectors

Sector ID

Sector Name

11

Agriculture, Forestry, Fishing and Hunting

21

Mining, Quarrying, and Oil and Gas Extraction

22

Utilities

23

Construction

3133

Manufacturing

42

Wholesale Trade

4445

Retail Trade

4849

Transportation and Warehousing

51

Information

52

Finance and Insurance

53

Real Estate and Rental and Leasing

54

Professional, Scientific, and Technical Services

55

Management of Companies and Enterprises

56

Administrative and Support and Waste Management and Remediation Services

61

Educational Services

62

Health Care and Social Assistance

71

Arts, Entertainment, and Recreation

72

Accommodation and Food Services

81

Other Services [except Public Administration]

92

Public Administration

Rents and Prices

The market price of built space is a key input to UrbanSim and is also a modeled output of UrbanSim. Prices play a role in the demand-side models as an explanatory variable in household and employment location choices. They also play a role in the supply-side model, as an explanatory variable in the real estate development location choice model. Models of real estate rents and prices are estimated so that rents and prices are updated endogenously in the model system. If the model system has a price equilibration component, prices in the model are further updated based on a demand-price equilibration routine.

Rent and price data can be appended as columns to the blocks and/or residential units table, or supplied as separate uploaded datasets. By default, UrbanSim provides residential rent and price data derived from Census data (see here for more information). However, these data can be replaced or updated using alternate observed or predicted data. Please contact us here for more information and consult the rent and price upload data schema below. Price observations need not be comprehensive for all built space, a sample of prices can be used to estimate a model that can then be applied to predict prices more broadly. It is suggested you upload separate rent and price data using the rent and price data uploader following the data schema for each building and transaction types listed in the following sections below. Once uploaded, you may manage each dataset separately from the rest of your base data. You can choose to use specific data in UrbanSim or simply choose to upload and explore these data on the map.

Residential Rents

Observed data on the rental price of residential space provides a price signal for the renter side of the residential real estate market. Based on the supplied data, regression models of residential rents are estimated and the predicted values are then input to both the supply model and renter segments of the household location choice model. It is not required to connect these data directly to blocks however you may use the optional identification columns below to tie data directly to your other base data tables or use x (longitude) and y (latitude) columns to tie directly to block locations. Coordinates must be in the World Geodetic System 1984 (WGS84) coordinate system. When coordinates are present in the data, the data will automatically be available to view on the map as a point layer.

Table 13: Residential Rents

Column Name

Data Type

Required

Description

year

Integer

Yes

Year of the transaction

rent

Float

Yes

Predicted or observed rent per unit per month

x

Float

No

Longitude coordinate of transaction address or centroid.

y

Float

No

Latitude coordinate of transaction address or centroid.

unit_id

Integer

No

Unit ID of the transaction. Corresponds to the residential unit table du_id column.

building_type_id

Integer

No

ID of mixed-use or residential building
structure type for the transaction that corresponds
to the building types table.

block_id

String

No

Block ID of the transaction. Corresponds to the
block attribute table’s block_id

residential_sqft

Integer

No

Amount of residential square footage

year_built

Integer

No

Year of building construction

bathrooms

Float

No

Number of bathrooms

bedrooms

Float

No

Number of bedrooms

Residential Prices

Observed data on the sale price of residential space provides a price signal for the ownership side of the residential real estate market. Based on the supplied data, regression models of residential sale prices are estimated and the predicted values are then input to both the supply model and owner segments of the household location choice model. It is not required to connect these data directly to blocks however you may use the optional identification columns below to tie data directly to your other base data tables or use x (longitude) and y (latitude) columns to tie directly to block locations. Coordinates must be in the World Geodetic System 1984 (WGS84) coordinate system. When coordinates are present in the data, the data will automatically be available to view on the map as a point layer.

Table 14: Residential Prices

Column Name

Data Type

Required

Description

year

Integer

Yes

Year of the transaction

price

Float

Yes

Predicted or observed price per unit

x

Float

No

Longitude coordinate of transaction address or centroid.

y

Float

No

Latitude coordinate of transaction address or centroid.

unit_id

Integer

No

Unit ID of the transaction. Corresponds to the residential unit table du_id column.

building_type_id

Integer

No

ID of mixed-use or residential building
structure type for the transaction that corresponds to
the building types table.

block_id

String

No

Block ID of the transaction. Corresponds to the
block attribute table’s block_id

residential_sqft

Integer

No

Amount of residential square footage

year_built

Integer

No

Year of building construction

bathrooms

Float

No

Number of bathrooms

bedrooms

Float

No

Number of bedrooms

Non-Residential Rents

Observed data on the rental price of non-residential space provides a price signal for the non-residential real estate market. Based on the supplied data, regression models of non-residential rents are estimated and the predicted values are then input to both the supply model and employment location choice model. It is not required to connect these data directly to blocks however you may use the optional identification columns below to tie data directly to your other base data tables or use x (longitude) and y (latitude) columns to tie directly to block locations. Coordinates must be in the World Geodetic System 1984 (WGS84) coordinate system. When coordinates are present in the data, the data will automatically be available to view on the map as a point layer.

Table 15: Non-Residential Rents

Column Name

Data Type

Required

Description

year

Integer

Yes

Year of the transaction

rent

Float

Yes

Predicted or observed rent per square foot per year

x

Float

No

Longitude coordinate of transaction address or centroid.

y

Float

No

Latitude coordinate of transaction address or centroid.

building_type_id

Integer

No

ID of mixed-use or non-residential building
structure type for the transaction that corresponds to
the building types table.

block_id

String

No

Block ID of the transaction. Corresponds to the
block attribute table’s block_id

non_residential_sqft

Integer

No

Amount of non-residential square footage

year_built

Integer

No

Year of building construction

Non-Residential Prices

Observed data on the sale price of non-residential space provides a price signal for the non-residential real estate market. Based on the supplied data, regression models of non-residential sale prices are estimated and the predicted values are then input to both the supply model and employment location choice model. It is not required to connect these data directly to blocks however you may use the optional identification columns below to tie data directly to your other base data tables or use x (longitude) and y (latitude) columns to tie directly to block locations. Coordinates must be in the World Geodetic System 1984 (WGS84) coordinate system. When coordinates are present in the data, the data will automatically be available to view on the map as a point layer.

Table 16: Non-Residential Prices

Column Name

Data Type

Required

Description

year

Integer

Yes

Year of the transaction

price

Float

Yes

Predicted or observed price per square foot

x

Float

No

Longitude coordinate of transaction address or centroid.

y

Float

No

Latitude coordinate of transaction address or centroid.

building_type_id

Integer

No

ID of mixed-use or non-residential building
structure type for the transaction that corresponds to
the building types table.

block_id

String

No

Block ID of the transaction. Corresponds to the
block attribute table’s block_id

non_residential_sqft

Integer

No

Amount of non-residential square footage

year_built

Integer

No

Year of building construction

Model Calibration Data

Default: County and PUMA calibration routine

The base-year of the model is 2010, and more recent ACS releases are used for calibration and longitudinal validation purposes. Data from the 2010 - 2013 period is reserved for calibration, and calibration parameters are tuned such that the simulation matches (within some threshold) aggregate calibration targets. For regions with greater than three counties, calibration occurs using county-level observed targets. Otherwise, observed targets are at the Public Use Microdata Area (PUMA) level. Calibration targets are expressed in terms of proportion growth captured by geography in the 2010 - 2013 period. Household targets are obtained from ACS estimates for total number of households at the relevant geography. Residential unit targets are obtained from ACS estimates for total number of residential units at the relevant geography. Employment targets are obtained from the Census County Business Patterns (CBP) data at the county level and LEHD data at the PUMA level.

Optional: Place type calibration routine

For small regions with one or two counties and or PUMAs, the county or puma geography may not be a suitable calibration geography and fine scale geographies such as tracts may be overly-constraining. As an alternative, calibration can be achieved using the concept of place types where the calibration geography are aggregated census tracts based on a place type typology. To create place type typologies at the tract level the following is computed: First, a random forest regression on observed tract-level household/dwelling-unit growth using all tract-level variables as explanatory variables is computed. Then the 10 most important variables (as determined by the random forest regressor) are selected, all locations in the region are characterized using those 10 variables, then the variable values are standardized/scaled, and lastly a set of clustering algorithms are computed to automatically identify similar places (e.g. tracts). Then the various clustering schemes are evaluated and the one that best separates the region by growth trends is selected. The observed ACS data at the place type level are then summarized and these are used as calibration targets. To calibrate, the simulation is run in iterations and coefficients are adjusted so as to move in the direction of the targets during each iteration.

This calibration routine is automatically used for small regions of one or two counties and or PUMAs, however it is also available upon request for other regions. For regions that wish to use their own place types, contact us here to request this and to receive the required data schema.

User Uploaded Scenario Inputs

There are a number of block model scenario inputs that can be uploaded into the platform using the uploader tool. You can then select each data type to use in a scenario.

Annual Household Control Totals

A key input to UrbanSim is an assumption about total regional household growth in the forecast period. When composing a scenario, this input can be expressed as a growth rate, or alternatively, as an uploaded control totals table. A household control totals table (annual household control totals) gives the total number of households in the region by year, for every year between the model base-year (2010) and the forecast year (e.g. 2050). This information is typically based on a macro-economic forecast or data from the state demographer. The regional household totals can optionally be broken down by demographic group, giving control over how aggregate household characteristics are transitioned over time in the simulation. You may use any of the household characteristics in the households table to segment your control total table.

Both regional and sub-regional control totals are supported in the control total uploader. If control totals are sub-regional, include a sub-regional location identifier column that corresponds to a location identifier in the block table (e.g. county_id).

Note

To utilize sub-regional control totals in your model please contact us here.

Annual Household Control Totals: CSV File (.csv)

Column Name

Data Type

Required

Description

year

Integer

Yes

Year

total_number_of_households

Integer

Yes

Total number of households in year

total_number_of_people

Integer

No

Optional field, total number of people in household

[SUB-REGIONAL_LOCATION_ID]

Integer

No

Optional field, required field if applying sub-regional control
totals. Must connect to a corresponding column in the blocks table

The minimum requirement for a household control totals table is that it contains two columns: year and total_number_of_households. For example:

Annual Household Control Totals Table: Minimum Example

year

total_number_of_households

2010

1000

2011

1100

2012

1200

2013

1300

2014

1400

For additional control over how aggregate household characteristics transition over time, annual household totals can be segmented by adding additional columns and rows. For example, by adding persons_min and persons_max columns to the table, we segment the total number of households by household size:

Annual Household Control Totals Table: Household Size Example

year

total_number_of_households

persons_min

persons_max

2010

300

1

1

2010

200

2

2

2010

100

3

3

2010

250

4

-1

2011

330

1

1

2011

220

2

2

2011

110

3

3

2011

270

4

-1

The first row indicates that there are 300 households of size one in year 2010. UrbanSim recognizes that persons is an attribute of the households table, and the _min and _max column naming convention communicates to the model that the control total in the first row applies to households with a minimum of one person and a maximum of one person. Similarly, row 2 indicates that there are 200 households of size two in year 2010, and row 5 indicates that in 2011 there are 330 households of size one. In columns with name containing _min or _max, a value of -1 means no limit. So row 4 of the table pertains to households with four or more persons (no upper bound).

Another example of a segmented control totals table, this time where the segmentation of household totals is by income:

Annual Household Control Totals Table: Household Income Example

year

total_number_of_households

income_min

income_max

2010

500

0

30000

2010

900

30000

-1

2011

480

0

30000

2011

950

30000

-1

This example table buckets households into two income-based categories: those with <=30,000 in income, and those with >30,000 in income. The low-income bucket shrinks from 500 households in 2010 to 480 households in 2011. The high-income bucket grows from 900 households in 2010 to 950 households in 2011. This example region has 1400 (500 + 900) total households in year 2010, and 1430 (480 + 950) total households in year 2011.

Additional columns added to the household control totals table do not have to be expressed in _min and _max terms if the added column pertains to a known household attribute and no minimum/maximum attribute values are needed in the group definitions. For example:

Annual Household Control Totals Table: Tenure Example

year

total_number_of_households

tenure

2010

700

1

2010

800

2

2011

730

1

2011

820

2

This table indicates that in year 2010 there are 700 households with tenure = 1 (own), and 800 households of tenure = 2 (rent).

As the examples above show, annual household control totals tables give you the ability to break down regional household totals by detailed demographic characteristics. This table is the mechanism by which one can simulate demographic trends such as decreasing average household size, increasing average income, and increasing average age of household head.

To utilize a control totals table in UrbanCanvas, create as csv file representing the table, and then use the Upload feature to upload and name the table. In Uploads, look for the Household Control Totals uploader. The uploaded control totals table can then be referenced when composing a scenario. Scenarios can reflect alternative demographic assumptions if they point to different control totals table. For example, one scenario can reference a baseline household control totals table, and a different scenario can reference a household control totals table that shows a decline in home-ownership. Remember that household control totals tables need to contain information for every year between the base year and the forecast year.

Annual Employment Control Totals

A key input to UrbanSim is an assumption about total regional employment growth in the forecast period. When composing a scenario, this input can be expressed as a single growth rate, or alternatively, as an uploaded control totals table. An employment control totals table (annual employment control totals) gives the total number of jobs in the region by year, for every year between the model base-year (2010) and the forecast year (e.g. 2050). This information is typically based on a macro-economic forecast or data from the state demographer. The regional employment totals can optionally be broken down by sector, giving control over how the sectoral make-up of the economy changes over time in the simulation. You may use the sector_ids as well as any other characteristic available in the jobs table (or if you are using optional establishments, the sector_ids in the user supplied establishments table) to segment your control total table.

Both regional and sub-regional control totals are supported in the control total uploader. If control totals are sub-regional, include a sub-regional location identifier column that corresponds to a location identifier in the blocks table (e.g. county_id).

Note

To utilize sub-regional control totals in your model please contact us here.

Annual Employment Control Totals: CSV File (.csv)

Column Name

Data Type

Required

Description

year

Integer

Yes

Year

total_number_of_jobs

Integer

Yes

Total number of jobs in year

sector_id

Integer

No

Optional field, required if segmenting by this attribute,
must correspond to the sector_ids in the jobs table

home_based

Boolean

No

Optional field, required if segmenting by this attribute,
must connect to corresponding column in the jobs table

occupation

Integer

No

Optional field, required if segmenting by this attribute,
must connect to corresponding column in the jobs table

recent_mover

Boolean

No

Optional field, required if segmenting by this attribute,
must connect to corresponding column in the jobs table

[SUB-REGIONAL_LOCATION_ID]

Integer

No

Optional field, required field if applying sub-regional control
totals. Must connect to a corresponding column in the blocks table

The minimum requirement for an employment control totals table is that it contains two columns: year and total_number_of_jobs. For example:

Annual Employment Control Totals Table: Minimum Example

year

total_number_of_jobs

2010

800

2011

900

2012

1000

2013

1100

2014

1200

For additional control of the employment sector break-down over time, annual employment totals can be segmented by adding an additional column named sector_id:

Annual Employment Control Totals Table: Sector Example

year

total_number_of_jobs

sector_id

2010

100

11

2010

100

21

2010

100

22

2010

100

23

2010

100

3133

2010

100

42

2010

100

4445

2010

100

4849

2010

100

51

2010

100

52

2010

100

53

2010

100

54

2010

100

55

2010

100

56

2010

100

61

2010

100

62

2010

100

71

2010

100

72

2010

100

81

2010

100

92

2011

200

11

2011

200

21

2011

200

22

2011

200

23

2011

200

3133

2011

200

42

2011

200

4445

2011

200

4849

2011

200

51

2011

200

52

2011

200

53

2011

200

54

2011

200

55

2011

200

56

2011

200

61

2011

200

62

2011

200

71

2011

200

72

2011

200

81

2011

200

92

In this example, note how the sector ID’s match those from LEHD (see the LEHD Employment Sectors table). Each employment sector in this mock example has 100 regional jobs in year 2010 and 200 regional jobs in year 2011. The annual employment control totals table is the mechanism by which sectoral growth and decline is simulated. For example, one might create a scenario-specific control totals table to simulate the impact of a rapid increase in healthcare jobs over the forecast horizon.

To utilize an employment control totals table in UrbanCanvas, create as csv file representing the table, and then use the upload feature to upload and name the table. In Uploads, look for the Employment Control Totals uploader. The uploaded control totals table can then be referenced when composing a scenario. Scenarios can reflect alternative employment assumptions if they point to different control totals table. For example, one scenario can reference a baseline employment control totals table, and a different scenario can reference an employment control totals table that shows certain sectors growing faster or declining faster. Remember that control totals tables need to contain information for every year between the base year and the forecast year.

Travel Model Zones

Travel model zones (i.e. traffic analysis zones, TAZs) is the unit of geography used by most regional travel models. UrbanSim is typically run in order to feed land use inputs to a regional travel model, so UrbanSim output needs to be summarized at the travel model zone-level. This can be achieved by downloading the block-level simulation results and manually aggregating to zone. As a convenience, UrbanCanvas offers a travel model zone uploader so that users can upload their zonal geography, and then UrbanSim will automatically return results at the zone level (i.e. do the block-to-zone aggregation). The file format should be a zipped (.zip) shapefile. The only requirement for the shapefile is that it should have an integer field named zone_id with the travel model zone ID values. The TAZ uploader displays the percent of the base data geometry polygons that have been successfully intersected with the TAZ polygons. Once uploaded, travel model zones can be assigned to specific scenarios where post-simulation the resulting indicators will be available as indicators viewable on the map or downloadable as a CSV at the specified zone geography. The zone_ids for the zones selected for the scenario must correspond to the zone_ids in the corresponding skims that have been selected for the scenario.

Note

Blocks are automatically assigned a TAZ ID when a TAZ file is uploaded using a block polygon largest area overlap by TAZ polygon intersection operation.

Travel Model Zones: Zipped Shapefile (.zip)

Column Name

Data Type

Description

zone_id

Integer

Travel model zone ID

Travel Model Skims

Travel model skims contain zone to zone travel times (sometimes along with other measures of impedance), as generated by a regional travel model. It is desirable to have skims represented in UrbanSim for the calculation of zonal accessibility metrics, and to facilitate feedback between the travel model and UrbanSim. Skims can be uploaded at any time, but a pre-requisite for using the skims in the model is to already have travel model zones uploaded. Skims should be formatted as a CSV file with, at the minimum, the following fields: from_zone_id, to_zone_id. Each row represents one zone-to-zone pair. Any number of impedance columns with any arbitrary column name are accepted. An example of an impedance measure is: AM peak period travel time from origin zone to destination zone, in minutes.

When used in scenarios, the zone_ids for the skims selected for the scenario must correspond to the zone_ids in the corresponding travel model zones that have been selected for the scenario. A single skim CSV file should represent travel times for a single year (e.g 2010) or travel times for a single range of years (e.g. 2010-2015). The year or year range that each skim represents is specified when skims are selected for use in a scenario. Skim CSV files do not need to include a year column because of the aforementioned method of specifying the skim year in the scenario form. If the CSV does contain a year column, only one single year value can be included. If travel times are different between multiple years, specific skim travel time CSV files for those years should be uploaded as separate skim files that represent each independent year or year range.

Note

Upon upload of base-year skims, contact us here so that we know to re-run the model specification routine for your region and incorporate travel time sensitivity into the location choice models.

If you would like to automate the two way feedback between your travel model and UrbanSim by integrating the two systems, this can be achieved with a consulting contract. See here for more information or contact us here.

Travel Model Skims: CSV File (.csv)

Column Name

Data Type

Description

from_zone_id

Integer

Origin zone ID

to_zone_id

Integer

Destination zone ID

[ARBITRARY_COL_NAME]

Float

Any number of columns with any arbitrary
column name are accepted. These columns should contain
a measure of impedance between zones for
example: AM peak period travel time from origin
zone to destination zone, in minutes

Regional Zoning

Development capacity in the block model is represented by two block-level fields: residential_unit_capacity and employment_capacity. These fields are initially set with high placeholder values representing near-unconstrained development capacity. The primary mechanism for constraining development capacity is the Constraints feature. Constraint records can be added to blocks to reflect zoning, undevelopable areas, and other development regulations. As a convenience for users who have a regional zoning layer, an uploader is available to bulk-load region-wide development constraint information to the platform. Upon upload of zoning data, implied block-level capacities are calculated using the max_dua column to derive residential unit capacity and max_far column with a square feet per job conversion factor set in the constraints user interface to derive employment capacity. Constraint records are created for each block. The zoning layer should be in the form of a zipped (.zip) shapefile. The shapefile should have the following fields: id, zoning, max_dua, max_far. To convert uploaded regional zoning data to constraints for use in the model see here. If you have multiple records of polygons with the same zoning designation ID, we suggest you dissolve those polygons to create a set of unique record IDs.

Zoning data is typically one of the more challenging categories of data to collect owing to the many forms it can come in from member jurisdictions. If your regional zoning data may have data gaps, contact us here to review potential solutions.

In jurisdictions that may not utilize FAR in their zoning code, you may be able to derive FAR if the zoning data has lot coverage and building height or stories information. Otherwise, GIS data on zoning, building footprints, and parcels for a sample of locations in the jurisdiction could be used to estimate lot coverage and then with height information can derive an estimate FAR.

In jurisdictions that may not utilize DUA in their zoning code, you may be able to derive DUA through assumptions about average sqft per unit in the jurisdiction from Census data or other sources.

Note

Blocks that are completely intersected by a zoning polygon will have that zoning polygon’s max_dua value set for the block residential capacity and the polygon max_far is converted to employment capacity using this equation (1). Blocks that are partially intersected by one or more zoning polygons are assigned capacities proportional to the area by which the intersecting polygons overlap the block.

(1)\[\frac{\bigg(\frac{FAR * Block area (SQFT)}{SQFT per job}\bigg)}{Block area (Acres)}\]
Zoning: Zipped Shapefile (.zip)

Column Name

Data Type

Unit

Required

Description

id

Integer

Yes

Zoning designation ID. ID must be
unique, no duplicates allowed.

zoning

String

Yes

Name of zoning designation

max_dua

Float

Units per acre

Yes

Maximum allowable dwelling units
per acre (DUA) in this zoning designation

max_far

Float

Yes

Maximum floor-area ratio (FAR) in this zoning designation

Other User Uploaded Data

Summary Geography

Arbitrary polygon shapefiles can be uploaded and used to tag development projects with the corresponding polygon IDs for use outside of the platform and to generate summary statistics of development project attributes that fall within the polygons. See development projects reports for more information. The summary geography layer should be in the form of a zipped (.zip) shapefile. The shapefile should have the following field: polygon_id

Note

Blocks are automatically assigned a summary geography polygon_id when a summary geography file is uploaded using a block polygon largest area overlap by summary geography polygon intersection operation.

Summary Geography: Zipped Shapefile (.zip)

Column Name

Data Type

Description

polygon_id

Integer

Polygon ID

Bulk upload of development projects

See the bulk upload of development projects page.

Bulk upload of constraints

Constraints can be bulk uploaded by using the zoning to constraint conversion tool.

Bulk upload of adjustments

See the bulk upload of adjustments page.

Footnotes

References