information services az-smart arizona’s socioeconomic modeling, analysis and reporting tool box...

INFORMATION SERVICES

AZ-SMARTAZ-SMARTArizona’s Socioeconomic Modeling, Analysis and Arizona’s Socioeconomic Modeling, Analysis and Reporting Tool BoxReporting Tool Box

UrbanSim/OPUS COG/MPO Users GroupUrbanSim/OPUS COG/MPO Users GroupApril 30, 2009April 30, 2009

Hanyi LiHanyi LiJesse AyersJesse Ayers

Anubhav BagleyAnubhav Bagley

Copyright © 2009

INFORMATION SERVICES Socioeconomic Modeling

MAG & Maricopa CountyMAG & Maricopa County Members:Members:

25 cities and Towns25 cities and Towns 3 Indian Communities3 Indian Communities Maricopa CountyMaricopa County ADOT and CTOCADOT and CTOC

Vital Statistics (2008):Vital Statistics (2008): Population: 3.9 million Population: 3.9 million

Phoenix 1.5 millionPhoenix 1.5 million Jobs: 1.9 millionJobs: 1.9 million Area: 9,200 sq. miArea: 9,200 sq. mi

Copyright © 2009


AZ-SMARTAZ-SMARTArizona’s Socioeconomic Modeling, Analysis & Reporting Tool BoxArizona’s Socioeconomic Modeling, Analysis & Reporting Tool Box

Phase IPhase I Contract with UW: Dec. 2006 to July 2008 Current stable version of OPUS includes all features

developed under AZ-SMART contract Key additions:

Addition of the GUI – use of XML configuration files Windows Installer New Real Estate Development model Sub-Regional Control totals:

At any geography (County, sub-region, TAZ) Multi level control – feedback from lower to higher

Two new generic model types: Allocation model and “Simple model”

ArcGIS storage (usable for small datasets)

Copyright © 2009


July 2008 - presentJuly 2008 - present

OPUS implemented using:OPUS implemented using: v1 polygon based data (pseudo-parcels)v1 polygon based data (pseudo-parcels) Land use types matching with SAM-IM:Land use types matching with SAM-IM:

Residential: Single family, Multi familyResidential: Single family, Multi family Employment: Retail, Office, Industrial, OtherEmployment: Retail, Office, Industrial, Other

v1 simple model estimations: no HLCM or ELCM v1 simple model estimations: no HLCM or ELCM submodelssubmodels

Starting from simple – working towards end-state models:Starting from simple – working towards end-state models: Simplistic development constraintsSimplistic development constraints Small number of known development projects and templatesSmall number of known development projects and templates

Control at County and sub-regionsControl at County and sub-regions

OPUS ver. 4.2.2 ++OPUS ver. 4.2.2 ++ Identified and fixed bugs Identified and fixed bugs Constant interaction with CUSPAConstant interaction with CUSPA

Copyright © 2009


July 2008 - presentJuly 2008 - present DocumentationDocumentation

Internal workings of models – developer modelInternal workings of models – developer model Estimation techniquesEstimation techniques Lessons and needsLessons and needs Beginnings of internal user and technical documentationBeginnings of internal user and technical documentation AZ-SMART Data ModelAZ-SMART Data Model

Household and Population SynthesizerHousehold and Population Synthesizer Testing version from ASUTesting version from ASU

AZ-SMART system architectureAZ-SMART system architecture

Completed the modeling team - finallyCompleted the modeling team - finally Hanyi LiHanyi Li Jesse AyersJesse Ayers

Copyright © 2009


Next stepsNext steps Finish testing with v1 dataset, move on to v2:Finish testing with v1 dataset, move on to v2: v2 Data creationv2 Data creation

Settle on v2 parcels – large parcels pre-split Settle on v2 parcels – large parcels pre-split More realistic development_constraints dataset – applied to More realistic development_constraints dataset – applied to

parcels from our General Planparcels from our General Plan Adding all known development projects – aligned with Adding all known development projects – aligned with

parcelsparcels Develop enhanced building dataset linked to enhanced HH Develop enhanced building dataset linked to enhanced HH

and jobs datasets from internal sourcesand jobs datasets from internal sources EstimationEstimation

REPM – submodels stratified by more detailed land-use typesREPM – submodels stratified by more detailed land-use types HLCM – submodels stratified by household typeHLCM – submodels stratified by household type ELCM – submodels stratified by NAICS sectorsELCM – submodels stratified by NAICS sectors

Models Models Sub-regional control with spill over to higher geographySub-regional control with spill over to higher geography Test development of zonal modelsTest development of zonal models Develop other allocation models as needed Develop other allocation models as needed

Copyright © 2009


Lessons being learnt

Data Consistency – all spatial datasets need to match

boundaries with the base parcel dataset Reconfigure the way plans and development projects

are maintained internally Table and field names must exactly match what OPUS

is expecting or the simulation will fail with a Python traceback

Estimation Multi-Linear Regression

Numpy Array - Negative R2 and Singularity Discrete Choice Model

Dataset for Estimation Vacant VS. Non-Vacant for Sampling Weights BHHH MNL Estimation VS. BHHH WESML Estimation Observed and Sampled Shares

Copyright © 2009


Lessons being learnt (contd.) Models

Development Velocity had bugs – fixed Large parcel issues: once development proposal starts,

the system will build it out completely regardless of demand

Sub-regional control – HTM issues (draws from sub-region, problems w/ low or 0 HH in base year)

Filter for Home-Based Employment Location Choice Model

Table for Build out Indicators Tool Current difficulty with HLCM leaving many unplaced HHs

w/ many vacant units Knowledge of Python and DBMS was essential to get

model running for first time on MAG data Not everything is documented - adding Jesse to the

team helped immensely

Copyright © 2009


Needs More control over what is written to the cache each

simulation year: Many tables and fields are written over and over in a

simulation, perhaps write only changed tables\fields? Many interim steps and results are discarded during a

simulation (expected ROI, units proposed, etc.), writing these to the cache would be useful for analyzing model behavior and debugging

Some form of “cache validation,” a way to tell if all required tables and fields are present before starting a run

Some items that still need to be exposed in the GUI: Some inherited scenario configuration information is not

exposed in XML yet, all parcel based projects inherit a lot of configuration information from: urbansim_parcel.configs.controller_config.py

Copyright © 2009


Needs

More targeted reports/diagnostics from individual models: Many things (warnings, errors, diagnostic info, etc.)

are printed to the log, but are difficult to find after a simulation year is complete

Demographic transition models (aging, HH formation, etc.)

Method for aggregating/splitting parcels: Subdivision and aggregation of parcels is needed

prior to application of development templates Need ability to work with parcel information within

known development projects Business lifecycle and transition

Copyright © 2009


QuestionsQuestions

Can models be controlled to population rather Can models be controlled to population rather than HH?than HH?

Details on persons<>jobs linkDetails on persons<>jobs link

Discrete Choice Model with Capacity Constraints

information services az-smart arizona’s socioeconomic modeling, analysis and reporting tool box...

Documents