Re: RE: Model not locating development projects

Quinn,

I've found out what's going on:

The DPLCM runs by default on submodels; the variable that determines what
projects are in what submodel is called 'size_category'. Thus, the
projects are assigned to submodels according to their size. (The
categories are defined in urbansim/configs/general_configuration.py). The
specifications should contain variables for all submodels. I suppose in
your case you have only one submodel (with value 1) in the specifications
and therefore only projects of the first category are considered by the
model and the rest is ignored. We do have the same problem in the eugene
database - so we do need to change that!

BTW, there is a difference if the sub_model_id in your specification and
coefficients table has value 1 or -2: Value 1 refers to a sub-model number
1, whereas value -2 refers to 'no sub-models'.

There are four ways of fixing this (any single one should be enough):

1. (the easiest one) Change sub-model values in your DPLCM specifications
   and coefficients tables to -2.

2. Create DPLCM specifications for all submodels.

3. Change the size categories in
   urbansim/configs/general_configuration.py. You'll see the categories
   lists in
        'models_configuration': {
                'development_project_types':
                ...
                        categories = [...]

   Note that you need one submodel more than you have entries in the
   categories list. In case of one submodel, it can be an empty list.

4. In the same file, in the controller entries of the specific model
   uncomment the entry
        submodel_string=None
   (please update the code from SVN, I just added it there)

I apologize that the documentation is not clear about this and that we
even got the same problem in the eugene database. I will try to correct it
right away. So thank you very much for helping us to find these gaps!

Hana

On Mon, 9 Jul 2007, Quinn Korbulic wrote:

> Thanks Paul,
>
> I am using a more recent version of the code with the
> development_constraints table containing min and max fields for the general
> landuse types. I did as you suggested (built a rough development constraints
> table and re-estimated) and am getting similar results. Commercial
> development is getting located but industrial sqft and residential units are
> not, or not as much as they should be. Residential development is being
> located at about 1 unit per year and industrial development is not being
> located at all...
>
> I have attached a log files for two of the years.
>
> I'm a bit baffled by this. Do you have any other suggestions as to why this
> is happening?
>
> Thanks,
>
>
> Quinn Korbulic
> GIS Coordinator
> Spatial Applications and Research Center
> New Mexico State University
> Geography Department
> Box 30001, Dept. MAP
> Las Cruces, NM 88003-0001
> VOICE (505) 646-5755
> FAX (505) 646-7430
>
> Quinn
>
> First, I am assuming you are using fairly recent code and that the
> development_constraints table contains max_residential_units and similar
> fields rather than the earlier format that did not contain min and max
> fields, and instead had a development_type field. If this is not the case,
> please indicate what version of the model system you are using.
>
> I think the problem is due to a change in the behavior of the model when the
> development constraints are not specified in the table. In the transition
> style developer model (the earlier model that would have used the
> development constraints table that included a development_type field in it),
> leaving out constraints information behaved as you expected: no constraints
> meant that a cell could transition to any of the development types. There
> were other issues with this transition model, but that is not the issue so
> let's put that aside. The newer developer model that uses a location choice
> framework handles development constraints somewhat differently. Most
> importantly in your case, it uses a capacity calculation to figure out if a
> project of a given size can fit into a cell, given its available developable
> capacity --- which is determined by looking up the constraints that apply to
> the cell and computing whether the remaining capacity is greater than the
> size of the project to be placed. That works as you expect in most cases,
> but not if you do not specify any constraint information at all. In that
> case, it is treated as having no capacity rather than infinite capacity. I
> hope that helps explain why it is behaving as it is. Now on to what to do
> about it.
>
> If you really want to see what would happen if you had no planning
> constraints at all, you could put in a single development constraint record
> with a -1 for the plan_type_id and a fairly high value for the
> max_residential_units, max_commercial_sqft, max_industrial_sqft. I don't
> think this would be very effective for estimating the model parameters,
> since this is not how the world generally works. You will get better results
> by estimating the model using even a rough approximation of what the
> constraints actually are in local land use policy, and putting this into the
> development_constraints table.
>
> Hope this helps.
>
> Paul
>
>
Received on Tue Jul 10 2007 - 10:56:00 PDT