The UrbanFootprint land use system allows you to capture the complexity, range, and nuance of urban form and land use. In order to make land use creation transparent and defensible, UrbanFootprint employs a nested hierarchy comprised of individual components, which are grouped together to form types. Components—which include buildings, parking structures, and parking lots, parks, and other urban elements—are used to construct prototypical or average building types for a project area. Finally, to construct districts, known as place types building types are used.
This clear hierarchical structure helps ensure that types are grounded in real-world, tangible elements. The alternative—directly asserting population and employment densities and land use types characteristics instead of combining components—can yield unrealistic types, whose densities do not align predictably or reasonably with development characteristics. The feasibility of types can be difficult to vet, particularly at the place type scale. It is particularly difficult to trace the downstream impacts of unrealistic attributes, which often show up in analysis module results.
In short, the detailed inputs for land use types are abstractions of the real world. The built environment is complex and varied—although the land use types setup process is input-intensive, its consistency and grounding in tangible components helps ensure more realistic scenarios and consistent, transparent analytical outcomes.
Libraries are collections of land use components and types. When you start a project, it will include a copy of UrbanFootprint’s default land use library. Whatever changes you make to existing land use types in the default library, or new types you create, will live within the new project without affecting the original library.
Components and Types
Components are a set of built form, demographic and land use characteristics that depict a prototypical or empirical building, park, or other urban element. Components themselves are not used to paint scenarios. They are the core ingredients for creating all other UrbanFootprint land use types, which in turn are used in painting. Components are defined by a detailed set of inputs and variables, which include things like land use designation; floor area ratio; residential, population and employment densities; residential and non-residential area breakdowns; average gross floor area per employee; and total parking spaces. For a detailed breakdown of these inputs, variables, and their dependencies, please see Appendix A: Components schema.
Figure 1. Examples of components (from left to right: single-family home, mid-rise apartment building, mixed-use skyscraper, urban park)
Building types are a composite of one or more components. Building types are created by blending components and specifying a weight in terms of land area for each component (see Figure 2). Building types cannot be used to create another building type. After a type is created it can be used to paint. Building types are typically used at the parcel level. Building types specify what occurs on “net” or parcel area. Let’s say you wanted to paint on a large greenfield parcel or a Census Block. Painting a building type would deploy parcel (net) characteristics, which excludes right-of-way. In this case, you would likely want to include right-of-way, so you would instead paint a place type. If you want to paint with a single building instead of a blend, you can create a building type as 100% of the given component building, essentially promoting a component to a building type (see Figure 3).
Figure 2. Creating building types
Figure 3. Promoting a component to a building type
Block types are a composite of one or more components and/or building types. Like building types, they are created by specifying weighted mixes of constituent parts. In technical terms, block types are identical to building types; conceptually, however, they represent groups of buildings within a city block, rather than what can occur on a single parcel.
Figure 4. Creating block types
Place types represent prototypical places and include both “net” parcel area and “gross” area occupied by the right-of-way. They are created by combining a weighted mix of building and/or block types — just like building and block types are weighted mixes of components, plus right-of-way (ROW) characteristics (roadway and sidewalks). Within UrbanFootprint, they are created the same way that building types are created. In addition to blending one or more building/block types to define the net characteristics of a place type, you must also define the ROW characteristics. Place types are typically painted at an aggregate scale (e.g., Census blocks). They represent “gross” densities by default (measured over the total area, including ROW).
Figure 5. Creating place types
Project Library Settings
The project library settings tab is where values for project variables and project defaults are set. Project variables are used to allow certain demographic and building occupancy characteristics (e.g., household size) to be dynamically updated project-wide. Project defaults are used to initially populate a select set of required input assumptions (e.g., average surface parking lot stall size) for components, but they cannot be updated dynamically.
Project variables are dynamic inputs that vary the population and employment characteristics of land use types. These can be adjusted at any time and will change dependent characteristics within all land use types. Adjustments will affect any paints you have already done. Variables are set at the project level; they cannot be varied on a scenario-by-scenario or type-by-type basis.
Let’s look at an example of how project variables work: Let’s say you originally thought the average household size for single-family homes should be 3.2, but then decide you want to model it as 3.3. To make this change, you would modify the value on the project settings tab, and UrbanFootprint would dynamically update all land use types that include single-family homes and associated paints. If a land use type had one single-family dwelling unit, the population attribute would change from 1 * 3.2 to 1 * 3.3, with corresponding changes to the type’s population density. Other variables include building occupancy rates and square feet per employee by sector.
Project defaults prepopulate the input fields of components. Changing them affects the default values used to create new components. Changes to default values do NOT ripple through existing components or affect already executed paints. You can edit inputs of individual components; it will not affect the defaults themselves, just the component you are creating. Defaults are a shortcut that provide a starting point for filling out the detailed inputs required for components. They also enhance the flexibility of the land use system — if your project is at a regional or city-wide scale, you may not care about something like parking stall size. Defaults allow you to either keep UrbanFootprint's standard values, or set values once for a project (obviating the need to change these values every time you create a new component). When you create a component, you can focus on the handful of inputs that are important for your project without losing the level of detail that a component provides for modeling the built environment. In contrast, if your project is at the neighborhood or block scale, you can vary the detailed land use inputs across buildings to create meaningful analytical differences across building types and scenarios.
Let’s look at an example of how project defaults work: Let’s say that you create component_xyz where the default average parking stall size default is 330 sqft. A few days later, you change the default to 340 sqft and create component_abc. Component_xyz will retain an average parking stall size of 330 sqft while component_abc will have an average stall size of 340 sqft. Other examples of defaults include average height per story and building floor area net to gross percent.