California PECAS Model
The SD Construction Cost System
Technical Memo
Internal Working Document - Subject to modification
Submitted to University of California, Davis
HBA Specto Incorporated
Calgary, Alberta
April 2010
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 2
Table of Contents
Section
Page
1. Introduction ................................................................................................................................. 3
2. Overview ..................................................................................................................................... 3
3. Storage of Construction Costs and Rent Modifiers in the SD database ..................................... 5
4. Accessing the database from the SD Program ............................................................................ 8
5. ORM System ............................................................................................................................... 9
6. The Parcels_temp table ............................................................................................................. 10
7. Batch loading system ................................................................................................................ 10
8. GIS integration .......................................................................................................................... 11
9. Conclusions ............................................................................................................................... 11
Appendix A: SD Database Documentation .................................................................................. 12
A.1. space_types_i .................................................................................................................... 12
A.2. transition_constants_i........................................................................................................ 14
A.3. luzs .................................................................................................................................... 14
A.4. tazs .................................................................................................................................... 14
A.5. parcels ............................................................................................................................... 14
A.6. development_free_schedules ............................................................................................ 15
A.7. development_fees.............................................................................................................. 15
A.8. parcel_fee_xref.................................................................................................................. 16
A.9. transition_cost_codes ........................................................................................................ 16
A.10. transition_costs................................................................................................................ 16
A.11. parcel_cost_xref .............................................................................................................. 17
A.12. zoning_rules_i ................................................................................................................. 17
A.13 zoning_permissions .......................................................................................................... 18
A.14. parcel_zoning_xref.......................................................................................................... 18
A.15. local_effects .................................................................................................................... 19
A.16. local_effect_parameters .................................................................................................. 19
A.17. local_effect_distances ..................................................................................................... 19
A.18. space_types_group .......................................................................................................... 20
A.19. construction_commodities .............................................................................................. 20
A.20. space_to_commodity ...................................................................................................... 20
A.21. current_year_table ........................................................................................................... 21
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 3
1. Introduction
The Space Development (SD) module of the PECAS software is responsible for
simulating the construction of space by developers over the period of one year. The SD
module runs for each year of the PECAS simulation, interacting with the Activity
Allocation (AA) module. The AA module is responsible for representing the demand for
space1 of each space type in each Land Use Zone (LUZ), and solving for the price for
each space type in each zone.
The theory behind the SD system is described in Chapter 6 of the PECAS Theoretical
Formulation document. That chapter of the Theoretical Formulation document refers to
these costs as TrCostsS and TrCostsL, and up until now they were previously described
as “in new PA-database version of software: this is specified at the parcel level, built-up
from parcel level information on fees, construction costs and zoning conditions penalty.”
This document describes the newly written version of the software that was referred to
as the “PA-database” version.
2. Overview
This section provides a brief overview of how SD works. A full description of the SD
module operation is contained in the PECAS Theoretical Formulation. The SD module
works with a database representing the physical characteristics of land and the built
space upon the land, updating this database when it simulates developer actions.
The developers in the SD system consider the Net Present Value of each development
option. The development options are show in the following table (which is Table 2 in the
PECAS Theoretical Formulation document):
1
AA also has a separate supply function which represents the high vacancy rates that can occur if demand is very
low, but the supply function within AA is for occupied space as a function of physical space; the supply of physical
space is simulated entirely within SD.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
Event
Name
Event
Designation
new space En
type and
quantity
event_type code in
development_events
table
C or CS
no change
E0
US
add
Ea
A or AS
renovate
Er
R or RS
demolish
Ex
D or DS
derelict
Ed
L or LS
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 4
Description
demolish any existing space and
develop new space type and new
space quantity as permitted by zoning
rules
make no change, leaving the space
type and space quantity the same
space type is kept the same, but the
space quantity is increased within the
range permitted by zoning rules and
the age is reset to reflect the
proportions of existing and new space
space type is kept the same, but the
age of the space is reset to 0
demolish any existing space and
leave land empty
allow the space to become derelict
Net Present Value is calculated per unit of land within SD. It is the annual rent per unit
space, multiplied by the intensity of development to convert it into a measure per unit of
land. It is then capitalized over a period of time assuming a certain discount rate, so
that it can be compared with construction costs.
The behavioural theory that underlies SD is that developers will want to construct (or
add to, or renovate) buildings when the rent is high enough so that they can make
enough money (either by renting it out as the landlord, or by selling it to a third-party
landlord) to recoup their construction costs.
There are three main elements to the equations that are used within SD:
1. The zonal average rent calculated within AA as AA represents the desire to locate in
particular zones due to the structure of the spatial economy and the travel
interactions that occur between different activities that are located in the region.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 5
2. The “local effect” modifications to the rent, which represents the differences in
desirability between specific parcels within a Land Use Zone (for instance parcels
near major roads are less desirable for residential use and may be more desirable
for commercial use.)
3. The costs of constructing different types of space on the parcel.
This document describes the work done to have a flexible database and GIS driven
system for representing item 3) above, the costs of construction. Along with the work to
develop the system for item 3) above, substantial work was done to develop a system
for item 2) above.
3. Storage of Construction Costs and Rent Modifiers in the SD database
The new SD stores all of its inputs in a relational database which has been normalized
according to the standard industry rules for database design. This allows the database
structure to remain unchanged over a wide range of possible representations of the
physical and policy environment.
The relationships between the tables have been formalized, and this is enforced by the
database software (PostgreSQL or SQL Server) to ensure the consistency and
referential integrity of the data.
The software database design is shown in Figure 1 and is described in detail in
Appendix A.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 6
Figure 1: SD Database Structure
The cost representation is contained in three groups of three tables. The first group,
consisting of the parcel_cost_xref table, the transition_cost_codes table and the
transition_costs table, describes how the physical costs of construction vary over time,
across space types, and across space. The parcel_cost_xref table describes the spatial
and temporal arrangement of costs: each parcel can be related to a different
cost_schedule_id in different years of the simulation. The transition_cost_codes table
identifies the cost_schedule_id’s themselves, but also is a place to store the costs of
providing different levels of servicing that may be required, as well as the cost of
preparing the land before construction, whether the parcel is Greenfield or a Brownfield.
(The level of servicing required of developers is stored along with the zoning, as a policy
variable in the separate zoning_permissions table). The transition_costs table is the
place to store the costs of physical changes to the building structure through demolition,
renovation, addition or new construction.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 7
The second group of three tables, consisting of the parcel_fee_xref table, the
development_fee_schedules table, and the development_fees table, describes how the
governmental fees of construction vary over time, across space types, and across
space. These tables represent political and policy variations across time and space,
which is why they are separated from the previous group (which represent physical
variations across time and space.) The parcel_fee_xref table describes the spatial and
temporal arrangement of fees: each parcel can be related to a different fee_schedule_id
in different years of the simulation. The development_fee_schedules table identifies the
fee_schedule_ids. The development_fees table is the place to store the fees that apply
to different types of construction, and the fees can be represented as a function of the
amount of space that is being built (square feet of buildings) as well as the amount of
land that is being used, and can also be one-time fees (amortized over the cost of the
project) or ongoing fees (converted to a Net Present Value based on the scenario
discount rate).
The third group of tables, consisting of the parcel_zoning_xref table, the zoning_rules_i
table, and the zoning_permissions table are primarily concerned with listing the
possibilities for development that are allowed under the land use regulation. However
within the zoning_permissions table there are three data fields that influence costs. The
penalty_acknowledged_space and penalty_acknowledged_land fields represent costs
associated with building space in areas where certain type of construction is not
technically allowed (or at least not specifically encouraged) but still occurs. These
penalties can represent specific real costs or fees associated with such non-conforming
development, or they can represent the costs of delays or additional bureaucratic red
tape. But they need to be represented in PECAS on the basis of the quantity of space
and the quantity of land in the proposed development project. The third field that
influences costs is the services_requirement field, which tells SD what level of servicing
is required before a space type is permitted on a parcel. The actual costs of servicing
are considered a physical cost, and so appears in the transition_cost_codes table, but
the requirement for servicing is stored here in the zoning_permissions table.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 8
(In general, the three tables representing PECAS “zoning” are used to represent
General Plan designations on land, since what is called “zoning” in different jurisdiction
is very specific to each jurisdiction and is subject to many frequent changes on petition
from land owners. In the PECAS software these are called “Zoning” but in most PECAS
models, including the California Statewide PECAS Model, they contain what is called
“General Plan” information.)
The storage of the local effect modifications to rent follows a similar design. Although
not part of the cost calculations, the rent modifiers are in many ways similar as they are
a parcel-level influence on the probabilities of development. There are three tables. The
local_effects tables lists the Local Effects that are being used in SD. Typical entries
include “distance to freeway”, “distance to park” and “distance to major transit station.”
The local_effect_distances table describes how far away each parcel is from each local
effect, in each year. For instance, a parcel may be 3000ft from a freeway in one year,
but in some future year, due to new freeway construction, the parcel may be 500 ft from
a freeway. The local_effect_parameters describes how each local effect influences the
rent for each space type. The details of the local effect functions are described in the
PECAS Theoretical Formulation in the rents section of chapter 6.3.
4. Accessing the database from the SD Program
The SD program is written in the Java programming language. The Java programming
language has a system for accessing databases, called Java Database Connectivity or
JDBC. The previous version of the SD software used the JDBC system to read the
parcel data from the database, and used a different system to read many of the inputs
from text files.
The new SD system contains much more data (as an example, with 160 million parcel
records and 8 local effects there are at least 1.2 billion records in the
local_effect_distances table). It is no longer feasible to load all of the inputs into
memory at the beginning of SD execution, because of memory size limitations. It is also
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 9
not practical to load each record from the database into Java when it is required, as
each interaction with the database requires a certain amount of overhead time.
5. ORM System
A system for accessing records in batches was required, and for storing these records
in memory as Java objects once they have been retrieved from the database. Such a
system is called an “Object Relational Mapping” system, or ORM, since it creates
Objects in a Java program based on the tables in a Relational Database.
A comprehensive review of various ORM technologies was carried out. Two
technologies were selected for further analysis, Hibernate and SimpleORM. Hibernate
is a very popular system that provides many sophisticated methods for ensuring
consistency between the database and the Java code. In testing, however, Hibernate
had a very significant negative effect on program execution speed. As well, Hibernate
makes changes to the compiled Java code (called “Byte Code Enhancement”.) This
makes programs that use Hibernate very difficult to debug using the standard Java
debugging tools.
SimpleORM is a simple system for creating Java objects from database tables, yet still
has the built-in methods for going to the database to retrieve an object if it hasn’t
already been retrieved. This functionality allows SD to ask SimpleORM for objects
based on the database, and SimpleORM will create the Java object from the database
data during the first request, and thereafter return the already created object from
SimpleORM’s cache.
SimpleORM is open-source software, and the source code is sufficiently small and self
contained to be understood and modified, if required, by the developers of PECAS.
Thus it was ultimately selected as the ORM method for PECAS SD.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 10
6. The Parcels_temp table
The SD database (shown in Figure 1 and described in detail in Appendix A) is a flexible
system for representing spatial inputs that change over time. However the SD program
itself only processes one year at a time. In performance testing of SD it was determined
that there is a lot of overhead if SD tries to load only the most recent Transition Cost
Code, Development Fee Schedule, Zoning Rules and the Local Effect Distances for
each parcel. Instead the database itself was programmed to combine the one most
recent year (less than or equal to the current simulation year) entry in the three xref
tables (parcel_cost_xref, parcel_fee_xref and parcel_zoning_xref) with the current
parcel data in the parcels table, in a parcels_temp table. In this way SD can view a
simpler representation of the SD database that shows only the inputs for the current
simulation year.
7. Batch loading system
To obtain a proper balance of speed and memory use, SD processes the parcel
database in batches. The batches correspond to random parcels, for instance a
random subset of 1/250th of the parcels might be loaded in a single batch.
Databases can use multiple processing cores on modern computers, but (in normal
configurations) each database query is assigned to only one processor. To speed up
SD the two slowest queries were assigned to separate processes in Java, so that they
could be processed in parallel by the database software as well as by the SimpleORM
system. These two queries retrieve the parcels for the batch, and the local effect
distances for the batch.
SD now operates in three separate parallel “threads”. One thread retrieves batches of
parcels for processing and puts each batch in a queue. Another thread retrieves
batches of local level effect distances for processing and puts each batch in a queue.
The third thread retrieves the parcels and local effect distances from the queues,
processes them, and writes out the development events that have been simulated.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 11
8. GIS integration
The costs, fees and zoning inputs visible by a typical user should be polygon layers in a
Geographical Information System (GIS) which specify the full set of costs, fees and
zoning polygons in the base year, and any modifications that occur to these in future
years of the simulation as a result of policy changes or physical changes. The xref
tables as shown in the SD database structure diagram are populated by simple spatial
joins in the GIS. These spatial joins are currently done in the ArcGIS interactive GIS,
but can also be programmed into the run script if the database is spatially enabled, so
that the user only needs to modify the GIS layers themselves without worrying about the
spatial join. (PostgreSQL and SQL Server were selected as supported database
platforms for PECAS partly because they can be spatially enabled.)
9. Conclusions
The SD construction cost system is a flexible system for representing construction costs
in a relational database, with variation over the time period of the policy simulation and
over the spatial model region. The SD software interacts with the SD database using
several computing technologies that simplify the database interaction while maintaining
a fast program execution speed.
The representation of construction costs follows three different types of GIS layers.
There are layers for the physical costs of construction, layers for the fees associated
primarily with jurisdictional boundaries, and layers associated with land use regulations
such as zoning and general plans. A fourth set of layers following a similar database
design represents changes in rents associated with specific grid cell or parcel attributes
(beyond what can be represented in the PECAS AA module at the Land Use Zone
geography).
The GIS input layers are pre-processed into a set of database tables as shown in
Figure 1 before SD runs. This provides a completely defined and consistent set of
inputs to the SD program without reducing the flexibility available to the user in
specifying the construction costs.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 12
Appendix A: SD Database Documentation
This section describes the database design underlying the SD module of PECAS
software. In particular, it describes the physical model of the database design which
shows the actual tables and relationships as they are physically created in the
database.
The physical model consists of 21 tables. The purpose of each table, the fields that
comprise it, and the relationships it participates in with other tables will be illustrated as
follows:
A.1. space_types_i
This table contains all the possible space types inputted to the system, including the
type 'Vacant'. Space types, such as retail; residential; and agricultural and mining,
exemplify records in the space_type_i table. This table includes the following fields:
 space_type_id: This is the unique identifier of the table (i.e. primary key). It is of
the type integer.
 space_type_name: This field represents the name of the space type as text.
 space_type_code: This field represents the corresponding code assigned to a
space type. This field is of the type text.
 age_rent_discount: This field provides the discount value applied on rents
according to space type age. This field is of the type double precision.
 density_rent_discount: This field provides the discount value applied on rents
according to density. This field is of the type double precision.
 maintenance_cost: This field represents the maintenance cost values for the
existing/current space type. This field is of the type double precision.
 age_maintenance_cost: This field represents the maintenance cost based on the
space type age. This field is of the type double precision.
 add_transition_const: This field contains the utility function constant for the "add"
development event (Ea). This field is of the type double precision.
 new_transition_const: This field contains the utility function constant for the "New
Space Type and Quantity" development event (En). This field is of the type
double precision.
 renovate_transition_const: This field contains the utility function constant for the
"renovate" development event (Er). This field is of the type double precision.
 renovate_derelict_transition_const: This field contains the utility function constant
used for renovating a derelict space type. It is used for the "renovate"
development event (Er) when the existing space type is derelict. This field is of
the type double precision.
 demolish_transition_const: This field contains the utility function constant for the
"demolish" development event (Ex). This field is of the type double precision.
 derelict_transition_const: This field contains the utility function constant for the
"derelict" development event (Ed). This field is of the type double precision.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification












2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 13
no_change_transition_const: This field contains the utility function constant for
the "no change" development event (E0). This field is of the type double
precision.
new_type_dispersion_parameter: This field contains the dispersion parameter
value associated with "new type" development event (En). This field is of the type
double precision.
gy_dispersion_parameter: This field specifies the dispersion parameter value
associated with "Gy" subtree. This field is of the type double precision.
gz_dispersion_parameter: This field specifies the dispersion parameter value
associated with "Gz" subtree. This field is of the type double precision.
gw_dispersion_parameter: This field specifies the dispersion parameter value
associated with "Gw" subtree. This field is of the type double precision.
gk_dispersion_parameter: This field specifies the dispersion parameter value
associated with "Gk" subtree. This field is of the type double precision.
nochange_dispersion_parameter: This field contains the dispersion parameter
value associated with "no change" development event (E0). This field is of the
type double precision.
intensity_dispersion_parameter: This field specifies the intensity dispersion
parameter associated with a space type. This field is of the type double precision.
space_type_group_id: This is a reference to a space types group in
space_types_group table. This field id of the type integer.
cost_adjustment_factor: This field specifies the cost adjustment factor for the
construction costs for an updated space type related to the target for a group of
space types batch n of the full set of parcels. This field is of the type double
precision.
construction_capacity_tuning_parameter: This represents a utility function
dispersion parameter for development event choice between Gk and E0 for a the
pace type. This value is used in the cost adjustment equation for the Capacity
Constraint feature. This field is of the type double precision.
converting_factor_for_space_type_group: This field specifies a factor converting
quantity in units for a space type into quantity in units of space used for target
quantity of construction for a group of space types. This field is of the type double
precision.
Space_types_i is related to:
 itself via the transition_constant_i table (refer to 'transition_constant_i' table
section below)
 parcels table
 space_types_group table
 space_to_commodity table
 zoning_rules_i table via zoning_permissions table
 transition_cost_codes table via transition_costs table
development_fee_schedules table via development_fees table
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 14
A.2. transition_constants_i
This table stores the constant values required when transitioning from one space
type to another. This table includes the following fields:
 from_space_type_id: This field represents a space type before the transition. It
stores
 a reference (id) of a space type in the space_type_i table. This field is of the type
integer.
 to_space_type_id: This field represents a space type after the transition. It
stores a reference (id) of a space type in the space_type_i table. This field is of
the type integer.
 transition_constant: This field stores the utility function constant for transition
from an existing space type (from_space_type_id) to a new space type
(to_space_type_id). This field is of the type double precision.
transition_constant_i is related only to the space_types_i table.
A.3. luzs
The luzs table stores information about the various Land Use Zones (luzs) in the
system. It includes the following fields:

luz_number: This field stores the zone number. It is of the type integer.
luz_name: This field stores the land use zone name (if applicable). This field is on the type text.
A.4. tazs



The tazs table represents the transport zones available in the system. Transport
zones are located within larger land use zones. Tazs table has two fields:
taz_number: This is an integer value that represents the transport zone number.
luz_number: This is a reference to the land use zone in which the transport zone
is located.
tazs table is related to luzs table in a one-to-many relationship; in that, many tazs
can be located in one luz.
A.5. parcels
This table stores information about all the parcels in the study area. It contains the
following fields:
 parcel_id: This field represents the parcel identifier. This field is of the type text.
 pecas_parcel_num: This field represents the unique identifier (primary key) of the
table. This field is of the type integer.
 year_built: This field stores the year when the space type was built. This field is
of the type integer.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification







2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 15
taz: This field stores a reference to the transport zone in which the parcel is
located. This field is of the type integer.
space_type_id: This field stores a reference to the space type existing on the
parcel. This field is of the type integer.
space_quantity: This field represents the amount of space development on a
parcel. This field is of the type double precision.
land_area: This field stores the area of a parcel. This field is of the type double
precision.
available_services_code: This field identifies the level of services available on
the parcel. This field is of the type integer. This field is of the type integer.
is_derelict: This field defines whether a parcel is derelict or not. This field is of the
type boolean (i.e. true or false).
is_brownfield: This field defines whether a parcel is a brown field or not. It is of
the type boolean (i.e. true or false).
parcels table is related to the following tables:
 development_fee_schedules via parcel_fee_xref table.
 transition_cost_codes via parcel_cost_xref table.
 zoing_rules_i via parcel_zoning_xref table.
 local_effects via local_effect_distances table.
A.6. development_free_schedules


This table is responsible for storing fee schedules that are associated with a
development. This table has the following field:
fee_schedule_id: This field is the table identifier (i.e. primary key). It is of the type
integer.
development_fee_schedules table is related to:
 space_types_i table via development_fees table.
 parcels table via the parcel_fee_xref table.
A.7. development_fees
This table is responsible for modeling the many-to-many relationship between
development_fee_schedules and space_types_i. It provides values of the various fees
that are charged on a specific space type on a parcel. This table includes the following
fields:
 fee_schedule_id: This field is a reference to a fee_schedule in the
development_fee_schedules table. This field is of the type integer.
 space_type_id: This field is a reference to a space type in the space_types_i
table. This field is of type integer.
 development_fee_per_unit_space_initial: This field sets the initial development
fees charged per unit of space. This field is of the type double precision.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification



2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 16
development_fee_per_unit_land_initial: This field sets the initial development
fees charged per unit of land. This field is of the type double precision.
development_fee_per_unit_space_ongoing: This field sets the development
fees charged on an ongoing basis per unit of space. This field is of the type
double precision.
development_fee_per_unit_land_ongoing: This field sets the development fees
charged on an ongoing basis per unit of land. This field is of the type double
precision.
A.8. parcel_fee_xref
This table links the parcels with the applicable fees to be charged at a specific year.
This table includes the following fields:
 pecas_parcel_num: This is a reference to a parcel in the parcels table. This field
is of the type integer.
 fee_schedule_id: This field contains a reference to a fee schedule in the
development_fee_schedules table. This field is of the type integer.
 year_effective: This field specifies the year when the fees are applied on a
parcel. This field is of the type integer.
A.9. transition_cost_codes
This table lists the categories used to define the costs associated with construction.
This table also contains those costs that are not associated with any particular space
type, in particular those costs associated with developing and improving services as
required for development on a parcel. This table includes the fields below:
 cost_schedule_id: This field is the unique identifier (primary key) of the table.
This field is of the type integer.
 high_capacity_services_installation_cost: This field specifies the costs
associated with installing high capacity services. This field is of the type double
precision.
 low_capacity_services_installation_cost: This field specifies the costs associated
with installing low capacity services. This field is of the type double precision.
 brownfield_cleanup_cost: This field specifies the costs associated with cleaning
brownfield parcels up. This field is of the type double precision.
 greenfield_preparation_cost: This field specifies the costs associated with
preparing greenfield parcels. This field is of the type double precision.
transition_cost_codes is related to the following tables, namely:
 space_types_i table via transition_costs table.
 parcels table via parcel_cost_xref table.
A.10. transition_costs
This table defines the costs associated with the various development events (e.g.
demolish, renovate and add) for a specific space type on a parcel. This table includes
the fields below:
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 17

cost_schedule_id: This field holds a reference to a cost_schedule in the
transition_cost_codes table. This field is of the type integer.
 space_type_id: This field is a reference to a space type in the space_types_i
table. This field is of the type integer.
 demolition_cost: This field represents the amortized money cost for demolishing
a space type on a parcel. This field is of the type double precision.
 renovation_cost: This field represents the amortized money cost for renovating a
space type on a parcel. This field is of the type double precision.
 renovation_derelict_cost: This field represents the amortized money cost for
renovating a derelict space type on a parcel. This field is of the type double
precision.
 addition_cost: This field represents the amortized money cost for adding to the
existing space type on a parcel. This field is of the type double precision.
 construction_cost: This field represents the amortized money cost for building a
new space type on a parcel. This field is of the type double precision.
A.11. parcel_cost_xref
This table defines the parcels and the applicable cost schedules associated with them in
a specific year. It includes the following fields:
 pecas_parcel_num: This is a reference to a parcel in the parcels table. This field
is of the type integer.
 cost_schedule_id: This field holds a reference to a cost_schedule in the
transition_cost_codes. This field is of the type integer.
 year_effective: This field holds the year when the costs are applicable on a
parcel. This field is of the type integer.
A.12. zoning_rules_i
This table defines the vast array of zoning rules available in the system. The table
includes the following fields:
 zoning_rules_code: This field is the unique identifier of the table (i.e. primary
key). This field is of the type integer.
 zoning_rules_code_name: This field contains the name of the zoning rule. This
field is of the type text.
 no_change_possibilities: This field indicates whether development event 'no
change' is permissible or not in the zone. It indicates whether space type
transition is permissible or not in the zone. This field is of the type boolean (true
or false).
 deriliction_possibilities: This field indicates whether development event 'derelict'
is permissible or not in the zone. This field is of the type boolean (true or false).
 demolition_possibilities: This field indicates whether development event
'demolish' is permissible or not in the zone. This field is of the type boolean (true
or false).
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification



2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 18
renovation_possibilities: This field indicates whether development event
'renovate' is permissible or not in the zone. This field is of the type boolean (true
or false).
addition_possibilities: This field indicates whether development event 'add' is
permissible or not in the zone. This field is of the type boolean (true or false).
new_development_possibilities: This field indicates whether development event
'new space type and quantity' is permissible or not in the zone. This field is of the
type boolean (true or false).
zoning_rules_i table is related to:
 space_types_i via zoning_permissions table.
 parcels table via parcel_zoing_xref table.
A.13 zoning_permissions
This table describes how a zoning rule applies to a specific space type. This table
includes the following fields:
 zoning_rules_code: This field holds a reference to a zoning_rule in the
zoning_rules_i table. This field is of the type integer.
 space_type_id: This field holds a reference to a space type in the space_types_i
table. This field is of the type integer.
 min_intensity_permitted: This field defines minimum intensity permitted in a
zoning. This field is of the type double precision.
 max_intensity_permitted: This field defines maximum intensity permitted in a
zoning. This field is of the type double precision.
 acknowledged_use: This is a flag indicating whether the particular use is not the
preferred use, and hence is discouraged. If the boolean flag is true the two
penalties will apply, thus discouraging this use in this zoning.
 penalty_acknowledged_space: This field represents the amount of penalty, in
dollars, to apply to developers per unit of space to be developed if the
"acknowledged use" flag is true. It also can represent an actual out-of-pocket
cost but can also be used to represent bureaucratic delays that discourage
development.
 penalty_acknowledged_land: The amount of penalty, in dollars, to apply to
developers per unit of land to be developed if the "acknowledged use" flag is
true. It also can represent an actual out-of-pocket cost but can also be used to
represent bureaucratic delays that discourage development.
 services_requirement: This field includes the code that represents the level of
services required. This field is of the type integer.
A.14. parcel_zoning_xref
This table links the parcels with the zoning rules to which they apply. In other words, it
links the parcels with the applicable zoning rules in a specific year. This table has the
following fields:
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification



2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 19
pecas_parcel_num: This is a reference to a parcel in the parcels table. This field
is of the type integer.
zoning_rules_code: This field holds a reference to a zoning_rule in the
zoning_rules_i table. This field is of the type integer.
year_effective: This field defines the year when zoning rules are applicable on a
parcel. This field is of the type integer.
A.15. local_effects
This table defines all the local effects that might affect a parcel in the system. It has the
following fields:
 local_effect_id: This field is the key identifier of the table (i.e. primary key). This
field is of the type integer.
 local_effect_name: This field contains the name of the local effect. This field is of
the type text.
local_effects table is related to:
 space_types_i via local_effect_parameters table.
 parcels table via local_effect_distances table.
A.16. local_effect_parameters





local_effect_id: This field is a reference to a local effect in the local_effects table.
This field is of type integer.
space_type_id: This field is a reference to a space type in the space_types_i
table. This field is of type integer.
function_type: The function type 1 through 9 to be used use when applying local
level effects. 1: Constant, 2: Exponential, 3: Shifted Exponential, 4: Power, 5:
Shifted Power, 6: Reversed Power, 7: Reversed Shifted Power, 8: Multiplicative,
9: Shifted Multiplicative.
max_dist: A reference value on dimension relevant for a local-level effect
(RefDValueg), see "Rents" section of theory guide.
theta_parameter: A parameter for function calculating values of change-in-rent
adjustment factor (LEFac).
A.17. local_effect_distances
This table links the parcels with the local effects associated with them in a specific year.
This table includes the following fields:
 pecas_parcel_num: This is a reference to a parcel in the parcels table. This field
is of the type integer.
 local_effect_id: This field is a reference to a local effect in the local_effects table.
This field is of the type integer.
 local_effect_distance: This field defines the distance value of the parcel to the
local effect. This field is of the type double precision.
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification

2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 20
year_effective: This field holds the year when the local effect is applicable on the
parcel. This field is of the type integer.
A.18. space_types_group
This table groups space types that are common for capacity constraints feature. This
table includes the following fields:
 space_types_group_id: This field is the key identifier of the table (i.e. primary
key). This field is of the type integer.
 space_types_group_name: This field contains the name of the space types
group. This field is of the type text.
 cost_adjustment_damping_factor: This field specifies the cost adjustment
damping factor for modifying the rate of adjustment to the cost adjustment factor
with each additional batch of parcels considered. This field is of the type double
precision.
space_types_group table is related to:
 space_types_i.
 construction_commodities.
A.19. construction_commodities




cc_commodity_id: This field is the key identifier of the table (i.e. primary key).
This field is of the type integer.
cc_commodity_name: This field contains the name of the construction
commodity. This field is of the type text.
space_types_group_id: This is a reference to a space types group in
space_types_group table. This field id of the type integer.
converting_factor: This is a factor converting quantity in units for commodity c
into quantity in units of space used for target quantity of construction for group of
space types k.
A.20. space_to_commodity
This table provides the link between the SD module and AA in PECAS. In essence, it
maps some of commodities in AA to some of the space types in SD. This table includes
the following fields:
 space_type_id: This field stores a reference to a space type in the space_types_i
table. This field is of the type integer.
 aa_commodity: This field stores the commodity name in AA module. This field is
of the type text.
 weight: This field represents the proportion of the space type that matches to the
AA commodity. For instance a mixed-use space type in SD might be 25% retail
space in AA and 75% residential space in AA, in which case the relevant entries
California PECAS Model
Tech Memo: The SD Construction Cost System
Internal Working Document - Subject to modification
2010.03.31/JEA/ARM
File: SD Scenario Tests.doc
Page 21
could be 25 and 75, or .25 and .75, or 1 and 3. This field is of type double
precision.
space_to_commodity table is related to space_types_i table.
A.21. current_year_table
This table keeps track of the current year in a SD run. It contains one field only, namely:
 current_year: This filed contains the current year in the a SD simulation.
current_year_table has no relationships.