Vision Solver

[fscottfoti]

Vision Solver First Pass Algorithm

This page will be used to spec out the price equilibration features for @mkreilly but presumably will be useful for all users of UrbanSim so others may weigh in if they would like. After talking with Mike, we decided to make this the third task after #110 and #111, since the other two tasks will probably make "solving the vision" easier.

Purpose

The purpose of this module is to find the policy inputs that yield a desired distribution of development in a region, where policy inputs can include the possibility of fees and subsidies. The method here should be consistent with related work - #110 and #111 - which adjusts prices based on the interaction of supply and demand and provide subsidies for development respectively. The vision solver needs to work for both residential and non-residential outcomes, but I imagine that its use will be emphasized for development of residential units (rather than commercial floor space).

Implementation Details

In short, the vision solver takes a subarea of the region, something the size of a zone, a neighborhood, or a PDA (priority development area), and a target for the number of units (and floorspace) that subarea should contain in a future year. There are a certain number of units (and floorspace) currently in the subarea, and the difference between the amounts is the target for development in the subarea. This module is being written primarily to understand development in PDAs in the Bay Area region, of which there are a couple hundred PDAs with a few hundred parcels each.

It should be noted right away that there are a few outcomes that can result from this analysis:

• If the zoning and feasibility are consistent with the target, the model will choose among buildings (presumably weighted based on profitability), to pick the more likely to be built buildings.

There are a number of other cases which bring about issues in the model (and are the purpose for this module):

• The zoning might be inconsistent with the target, which would essentially create an infeasible solution. This should be flagged by UrbanSim, but must be corrected by the modeler (e.g. the zoning must be changed to accommodate the target)
• The feasibility of development might be inconsistent with the target. This would take base year (observed), or simulated (for a future year), or simulated plus equilibrated versions of the prices, use them in feasibility, build all the feasible buildings, and still not meet the target. In this case, subsidies must be applied to meet the target. This process is rather simple since developments are already sorted based on profitability and the developments can be chosen off the stack until the target is met, with the sum of negatively profitable buildings being the subsidy that is required. (Cross subsidizing unprofitable buildings with profitable ones is part of task Accounts System #111 which will help us reach the vision this reason, task Accounts System #111 is probably a dependency of this task).

Visualization of results

The output of this analysis is a set of buildings which can be visualized in UrbanCanvas. Not only can the planner now see what the rough amount of floor space required to meet the target actually looks like in 3D, but also a reasonable set of parcels that might actually be redeveloped will be the ones that are chosen by the feasibility analysis. This is the real power derived from tying together visualization and analysis in this way.

Doing the above in the context of a 30 year simulation

It is pretty straightforward to imagine a workflow which uses UrbanCanvas to set the target for a given PDA, uses the Python module to pick a reasonable set of parcels in order to meet the target, and returns the results to UrbanCanvas for visualization. The power of this approach to the problem is presumably that the user could be allowed to manually edit the results that were generated by the model, or perhaps zoning could be edited directly in UrbanCanvas so that an iterative workflow is possible.

In general though, the purpose of this module is to operate within the context of a 30 year forecast. After chatting with Mike, my best proposal on how to solve this would be to try to achieve 1/30th of the target for each year in the 30 year simulation - not that exactly that number of units would be built each year - that would clearly based on the specific parcels being developed, but somehow the accounting is maintained so that on average 1/30th of the target is developed each year. If the targets account for the entirety of the control totals, presumably we will need dampening in other zones which are also profitable either by charging fees or by having limits or by some other mechanism.