1 / 7
May 2017

I've been trying to apply the pro-forma developer model to our data and came across some questions:

  1. It seems the model should be called separately for residential and non-residential development, respectively, controlled by the argument residential5. How should it be called for mixed-use development? Each call of the model calculates the number of units necessary to meet the vacancy rate, either residential units or non-residential sqft. It's not clear to me what to do in case of mixed-use forms.

  2. The developer model determines which form has the highest profit on each parcel. If run for example for residential development, one can restrict the model to choose the most profitable form among the residential forms only, in which case the non-residential forms are completely ignored. That does not feel right, since then the most profitable form depends on the order the models are run. How do people normally use it? The examples in sanfran_urbansim and bayarea_urbansim suggest the use described above.

  • created

    May '17
  • last reply

    May '17
  • 6

    replies

  • 5.1k

    views

  • 2

    users

  • 1

    like

  • 4

    links

Hi Hana,

To run the developer model with mixed use forms I passed a list of forms to the run_developer method in models.py

In the sanfran_urbansim example, the models.py contains functions for the residential and non residential developer. Both functions call the run_developer method in the utils.py file. So in the residential_developer method my first argument is ['residential', 'mixedresidential']. The ratio of uses can be changed for mixedresidential or mixedoffice forms in the SqftProFormaConfig object when you create your feasibility table.

Getting the developer model to actually pick buildings with mixed use forms requires the net_units to be greater than one. It will also require the right assumptions on price, parking, and zoning in order for the feasibility model to pick the mixed use form as the most profitable. We make sure to include all forms that contain non-residential units in our non-res model ['office', 'industrial', 'retail', 'mixedoffice'] and all forms that contain residential units in our res model ['residential', 'mixedresidential']. That way, it doesn't matter what the order of non_res vs. res developer model is run, because either call to the model is only considering buildings with the right unit type. I hope this helps, let me know if you have any additional questions.

Hi Justin,

Thanks so much for your answer! I really appreciate it. I have two follow up questions.

  1. I don't understand what you mean with
    "We make sure to include all forms that contain non-residential units in our non-res model ['office', 'industrial', 'retail', 'mixedoffice'] and all forms that contain residential units in our res model ['residential', 'mixedresidential']."
    In the default settings4, mixedoffice and mixedresidential forms have both, residential and non-residential uses (i.e. also units). How do you decide which forms go to which developer model. Is it by which use has the largest proportion?

  2. You don't have parcels where zoning would allow both, non-residential as well as residential development, and thus they could go either way in terms of res or non-res forms? We have many of those - that's why I don't see how the processing order of the developer model would not influence the results.

Thanks again!

Hi Hana,

I think the confusion is the different functions of the feasibility model and the developer model. The feasibility model classifies each parcel by building form, where classification depends on a pro-forma analysis of profitability. The output of the model is dataframe with parcel_id as the index, and there is a column that has the form that was determined to be the most profitable building form for that particular parcel. Then that table is stored as an orca table to be used in the developer models.

The developer model randomly picks parcels from the feasibility output using the max_profit to create the probability distribution used for the random pick. The first model filters the output of the feasibility model using a list of building forms. So in a residential model we could pass ['residential', 'mixedresidential'] to the developer, and the model's choice parcel set for the random pick would be limited to the parcels with residential or mixedresidential forms as the most profitable. So the key to not having an overlapping problem, is to make sure that you don't include the same form to both models.

We do have parcels where zoning would allow both non-residential and residential development. The feasibility model uses the zoning regulations along with a number of other assumptions about price, parking, zoning codes etc. to determine which building form is the most profitable. So if a parcel is zoned to allow residential and commercial, the feasibility model will calculate the max_profit of each different building form for every parcel. Then it will look up which form is most profitable, and output a table of parcels with the most profitable form, max_profit, and a bunch of other calculated variables.

I think there could potentially be problems when mixed use building forms like mixedresidential or mixedoffice are frequently picked for redevelopment. For example, if you add mixedoffice (30% res, 70% office) in a non-residential developer model, the added units from the residential side are not accounted for in the residential model. So you might be at risk for overbuilding residential units from mixed use buildings being added in the non-residential model.

I hope this helps, we are still working on a full implementation of this model. We have been using co-star to update pricing data to help improve the accuracy of our developer model. We are also working on updating our parcel and building data sets. Let me know if you have any questions or want to share what you guys are up to with UrbanSim.

Thanks,

Justin

Hi Justin,

That's what I thought how it works and it would make complete sense. But I don't think it's the case. (I've been going through the code step by step in a debugger and see a different behavior.)

The feasibility model returns a data frame that determines for each parcel and EACH form if that form is feasible and what is the most profitable max far/DU under that form. That's what happens in this loop4. The resulting data frame has columns in a multi-index form, with forms being one level of the hierarchy. Thus, there can be non-residential as well as residential forms feasible for the same parcel.

This dataset goes into the developer model which takes a set of forms as an argument. The function keep_form_with_max_profit1 selects the most profitable form for each parcel among the user-given forms. Thus, in order not to bias the model towards residential or non-residential development, I think the developer model should get all forms passed (i.e. "forms=None"), even if it runs for residential or non-residential development only.

The code I'm looking at is the standard urbansim implementation. You might have a different version of it that works differently.

Thanks for your help Justin!

Hi Hana,

Ok now I understand what you are saying. So if we pass all forms to the developer, and only run the developer once, we wouldn't have the problem of order for the models. It looks like in order to pull this off we will need to change the developer.pick function to treat residential and non-residential exactly the same. I think a lot of these problems come from the fact that we try to convert square footage to units, and it does that differently based on the context of residential or non-residential. I would rather work in sqft 100% of the time and find another way to work in assumptions on sqft per residential unit some where else in the model. What do you think?

-Justin

I completely agree. It would also solve the mixed-use problem. It would be great if people who are now working on the new version of the pro-forma model would consider this.