EMPLOYMENT POSTPROCESSING TO BUILD NON-RESIDENTIAL ACTIVITY TARGETS
A schema called ‘employment_postprocesing’ was created in the ‘Oregon’ database, a PostgreSQL
program. The final goal of the employment post-processing is to produce the non-residential activity
targets of the two input files needed for the Activity Allocation (AA) module of Oregon PECAS model.
These files are: FloorspaceI.csv and ActivityConstraintsI.csv. As a part of the process the employment is
estimated by economic activity and by zone. Even if the employment is not an input file in PECAS itself,
is an input file for the estimations made to obtain the floorspace and the money amount of employment
estimated in ActivityConstraintI.csv file. An additional file called OptionSizeCalibI.csv needs to be created
or updated in terms of floorspace use rates and labor use rates. This last file is used for calibration
purpose at the level of technology selection in AA module.
The ‘employment_postprocesing’ schema has 38 tables that are involved in the estimation of the
activity targets (Figure 1).
Figure 1. Tables involved in the employment post-processing to build activity targets
In order to obtain the employment and create the files FloorspaceI.csv and ActivityConstraintsI.csv three
scripts has been written in PostgreSQL. Information regarding the name, location, purpose and number
of steps are described in Table 1:
Table 1. SQL scripts description
Name:
Script_1
Script_2
Script_3
from output sample to emp from emp by zone by act to ActivityConstraints.sql
by zone by activity.sql
floorspaceI.sql
Location:
P:\Oregon
TLUMIP\PopSynth\SQL
scripts emp postproc
Purpose:
To obtain an employment To create the FloorspaceI.csv file To create the file
estimation as a base to for AA module
ActivityConstraints.csv
estimate input files for AA
for AA module
module
4
13
3
Number
of steps:
P:\Oregon TLUMIP\PopSynth\SQL P:\Oregon
scripts emp postproc
TLUMIP\PopSynth\SQL
scripts emp postproc
SCRIPT 1: from output sample to emp by zone by activity.sql
Step 1. Creating the table pop_synth_output. Once we run the employment synthesizer we obtain an
updated version of the file outputsamples.csv, which is the main Input file for this employment
post-processing process.
Output from step 1: pop_synth_output (with 2 columns: "zone" and "unit_id")
Step 2. Adding and estimating 2 more columns to the pop_synth_output table : "serilano"and "sporder".
These 2 columns are used as keys to join with pums_person_pecas table.
Output from step 2: pop_synth_output (with 4 columns). This section of the script also creates an index
for each of these 2 new columns to improve the performance during database operations.
Step 3. Creating the view synth_occ_ind_counts joining 4 tables: pop_synth_output +
pums_person_pecas + commodity + activity.
Output from step 3: synth_occ_ind_counts, which contains employment (counts) by occupation and by
industry, ordered by the columns office_split_activity_id and commodity_id. This section of the script
and the graph of the join is shown in Figure 2.
Figure 2. Graphical explanation of the joins in step 3.
Step 4. Creating the file pecas_pop_synth_counts.csv joining 4 tables: pop_synth_output +
pums_person_pecas + commodity + activity
Output from step 4: pecas_pop_synth_counts.csv, which contains employment (cnt) by zone,
industry (office_split_activity_id and activity_shortname) and occupation (commodity_id,
commodity_name), grouped by the columns: zone, office_split_activity_id and commodity_id. A partial
view of this file is shown below in Table 2.
Table 2. Partial view of the pecas_pop_synth_counts.csv file
zone office_split_activity_id activity_short_name commodity_id commodity_name
cnt
1
3 RES_offc_off
401 A1-Mgmt Bus
1
1
3 RES_offc_off
404 B3-Health
1
1
3 RES_offc_off
408 C3-Clerical
1
1
5 ENGY_ngas_hi
410 D1-Production Specialists
1
1
7 ENGY_offc_off
401 A1-Mgmt Bus
8
1
7 ENGY_offc_off
402 B1-Prof Specialty
8
1
7 ENGY_offc_off
406 C1-Sales Clerical Professionals
3
1
7 ENGY_offc_off
408 C3-Clerical
15
1
8 CNST_main_xxx
410 D1-Production Specialists
1
1
8 CNST_main_xxx
411 D2-MaintConstRepair Specialists
6
1
8 CNST_main_xxx
412 D3-ProtectTrans Specialists
1
1
8 CNST_main_xxx
413 D4-Blue Collar Unskilled
18
The section of the script that corresponds to this step and the graph of the join is shown in Figure 3.
Figure 3. Graphical explanations of the join in step 4.
The steps 3 and 4 are similar in the way they are both using the same input tables. But, note that in the
step 4 the zone is included in the query in order to get the same data from step 3 but by zone. The
output from these 2 steps are used and needed later in other estimations for the model.
SCRIPT 2: from emp by zone by act to floorspaceI.sql
There are six input tables that were used in this script 2. These files contains data (observations,
floorspace use rates, land use intensity, floorspace allowed by activity, etc.) that was used during the
process to obtain the floorspace estimation. Files and table names involved and correspondent
description are shown in Table 3. The explanations of how this information was used will be reflected in
the steps defined in this script.
Table 3. Input files to create input tables in employment_postprocessing schema
Input files
res_agg_land_max.csv
Table’s name
res_agg_land_max
job_space_type.csv
job_space_type
Lui.csv
lui_temp
res_space.csv
res_space
space_use_rates_n.csv
space_use_rates
Description
aggricultural and resources (agriculture and
logging) space observed (sq ft) by zone
Type of floorspace based on economic activity
(industry) and job type (occupation) used by
employees
Land use intensity code (H-high, medium-M,
low-L and very low – VL) by zone
Quantities of residential space by space type by
zone
Space use rates based on activity and land use
code (0 space use rate for aggriculture, logging and
accommodation)
space_use_rates_n.csv
space_use_rates_HOSP Space use rates based on activity and land use
(edited for
code (not 0 space use rate for accommodation space)
office_split_activity = 44)
These files are located in: P:\Oregon TLUMIP\PopSynth\Input tables for employment_postprocessing
schema
Step 1. Creating the table with employment called emp_synth_zone_ind_occ_temp from a join among
four tables: employment synthesizer output file (pop_synth_output), pums data (pums_person_pecas),
activity and commodity. Once we run the employment synthesizer we obtain an updated version of the
file outputsamples.csv, which is the main Input to estimate the floorspaceI file.
Output from step 1: emp_synth_zone_ind_occ_temp
Step 2. Adding primary keys and indexes to improve performance in the joins and estimations. One
primary key and five indexes were added to the table emp_synth_zone_ind_occ_temp in order to make
faster all the queries and joins made with this table.
Output from step 2: improved emp_synth_zone_ind_occ_temp
Step 3. Creating table lui_temp with land use intensity data by zone (input table). The input table used
was ‘land use intensity’and the column ‘taz’ was added as a primary key.
Output from step 3: lui_temp
Step 4. Creating the view job_space_type_commodity joining the table job_space_type (crosswalk
between activities and labor types, and space types or floorspace allowed) and the commodity table
(with a condition to link only with labor commodity).
Output from step 4: job_space_type_commodity
Step 5. Re-writting to 0 the space use rates of the space types that are processed outside of the
emp_synth. The regular processing to get the floorspace is to multiply the employment by a specific
space use rate. But, there are three space types that require a more detail employment postprocesing:
aggriculture, logging and accomodation space. As a result, the space use rates in the table need to be set
to zero in order to avoid the estimation of these space for these space types at this stage of the process.
Output from step 5: space_use_rates (with zero as a rate in aggriculture, logging and accomodation
space)
Step 6. Creating a main table called spaceuse_rates_temp1 which has correspondent employment,
space use rates and estimated floorspace. The objective with this table is to estimate the space (use
rates x employment) where use rates comes from the table space_use_rates (depend on lui code and
activity_id). Other tables are included in the join in order to provide useful information for the
crosswalk: employment (from emp_synth_zone_ind_occ_temp), lui temp (land use code), space use
rates (from space_use_rates) and space allowed by labor type
and activity (from
job_space_type_commodity).
Output from step 6: spaceuse_rates_temp1
Step 7. Extracting employment in accommodation('HOSP_acc_acc') and employment in eating and
drinking places ('HOSP_eat_ret_acc') from the main table spaceuse_rates_temp1. Two tables were
created in order to separate the employment by zone for the floorspace estimations: emp_accom and
emp_eat_dri.
Output from step 7: emp_accom and emp_eat_dri
Step 8. Re-allocating employment in accomodation and in eating and drinking places. The idea is to use
the employment in accommodation to get an estimation of how much employment in eating and
drinking places are. The hypothesis is that for every two employees in accommodation, there could be
as many as one job in eating and drinking places that are located in accommodation space. This
estimation was only applied to the zones were both types of employment are present. A table called
emp_temp4 is created to estimate the adjustment in both types of space. The final eatng an drinking
employment is estimated by zone, and a column with the activity id correspondent to the land use code
for accommodation space is also added in order to connect later with the space use rate information.
Output from step 8: emp_temp4
Step 9. Estimating additional retail and accommodation floorspace: retail (from eating and drinking
places) and accommodation (from restaurants in hotels). This estimation was made multiplying the
employment from accommodation and eating and drinking places by different correspondent space use
rates (from the table spaceuse_rates_HOSP). The idea was to to be able to apply space use rates from
eating and drinking places to this accommodation space and to apply retail use rates to eating and
drinking places to obtain additional retail space. As a result, one table was obtained with the space
estimations: n_ret_acc_sp.
Output from step 9: n_ret_acc_sp
Step 10. Estimating Agriculture Floorspace. This step includes 4 substeps. First, the extraction of
aggriculture employment in production occupations from the main table spaceuse_rates_temp1.
Second, a join with the table called res_agg_land_max with the current aggriculture land by zone (from
inventory). Third, a column with a space use rate (392040 sq fts which is 9 acres) for aggriculture space
was added and updated. Fourth, the estimation of the space needed that was made multiplying the
employment by the space use rate if the employment is greater than zero.
Note: final estimation of agriculture space is made is step 11.
Output from step 10: agg_flr
Step 11. Estimating Logging Floorspace. This step includes 5 substeps. First, the extraction of logging
employment in production occupations from the main table spaceuse_rates_temp1. Second, a join with
the table called res_agg_land_max with the current resource land by zone (from inventory). Third, a
column with a space use rate for logging space (2178000 sq fts which is 50 acres) was added and
updated. Fourth, the estimation of the space needed that was made multiplying the employment by the
space use rate if the employment is greater than zero. Fifth, a table called agg&logg_flr was created
with the following data by zone: resource land (res_land_max), agriculture land (agg_land_max), land
needed for agriculture (agg_needed), land needed for logging (logg_needed) and extra land (the
resource land minus the land needed for both, agrculture and logging). Then aggriculture space
estimations were made with the condition:

Agriculture space = agg_needed + extra * (agg_needed/(agg_needed + logg_needed)) when
(extra>0 and (agg_needed + logg_needed>0)), if not, agg_need
A validation was made after this estimation using two columns as controls: agg_flr_min and
agg_flr_max, where:


agg_flr_min = when agg_land_max < agg_flr then agg_land_max else agg_flr
agg_flr_max = when agg_needed > agg_flr_min then agg_needed else agg_flr_min
Logging espace was estimated using the folowing condition:

Logging space = logg_needed when logg_needed > (res_land_max-agg_flr_max), if not,
res_land_max-agg_flr_max
Output from step 11: logg_flr
Step 12. Organizing floorspace estimation. Different space types from the main table
spaceuse_rates_temp1, in addition to retail, accommodation, agriculture and logging space were
organied by space type and by zone. This step includes 4 substeps. First, a table called floorsp is created
with the space estimated in spaceuse_rates_temp1. Second, a table called ret_flr is created with the
retail space estimated in n_ret_acc_sp table. Third, a table called acc_flr is created with the
accommodation space estimated in n_ret_acc_sp table. Forth, aggriculture space is organized in the
table n_agg_flr. Fifth, logging space is organized in the table new_logg_flr.
Output from step 12: floorsp, ret_flr, acc_flr, n_agg_flr and new_logg_flr
Step 13. Adding floorspace to get floorspace_i. This step involves the creation of 5 tables (floorsp_1,
floorsp_2, floorsp_3, floorsp_4, floorsp_i) that add floorpace in incremental way. floorsp_1 add the
table floorsp (from step 12) plus residential floorspace. floorsp_2 add floorsp_1 plus the additional
retail space. floorsp_3 add floorsp_3 plus the additional accommodation space. floorsp_4 add floorsp_2
plus the aggriculture space. And, floorsp_i add floorsp_4 plus the logging space.
Output from step 13: floorsp_1, floorsp_2, floorsp_3, floorsp_4, floorsp_i (floorspaceI file)