developer max_parcel_size

[Eh2406]

https://github.com/UDST/urbansim/blob/master/urbansim/developer/developer.py#L138

Many people at the user conference discussed being blindsided by this parameter. I do not know how to fix it, but we can get the conversation started.

[fscottfoti]

Good point. I'm fine with setting this to None by default and just not apply the filter when None is passed.

I don't really think UrbanSim should be in the business of predicting enormous devs but maybe that limit doesn't qualify as enormous. I've always thought the easy and appropriate solution would be to chop very large parcels up at the beginning of the simulation such that the parcel size is more manageable. Since UrbanSim doesn't need the geometry of the parcel right now this would be a pretty easy thing to do (just copy over zoning attributes and split the parcel up into virtual sub parcels). This also would help quite a bit with stochasticity as dev-ing a large parcel would require dev-ing all the parcels you split it up into. Thus in this case the max_parcel_size would really be applied by chopping parcels up into sub-parcels of that size rather than enforcing it in the dev model.

[waddell]

As a preface, I also don't like seeing hard coded constraints like this one. I think this and others are there because of broader structural issues that need to be addressed in this part of the code.

Based on the discussions we began at the user meeting, I think we'll be embarking on a much larger scale re-envisioning and re-engineering of the pro forma developer model. Since it is a broad and complex topic, I think it is a good one to use a forum for discussing, and we are going to set that up pretty soon. But in this conversation I'll just mention a few things I would propose to explore:

1. Some form of parcel subdivision, possibly using procedural geometric modeling at some point, but probably beginning with virtual subdivision as already mentioned.

2. Moving away from spot pro formas as the default and towards multi-period pro formas with appropriate discounting over time, which would enable some soft costs like permitting delays to have an impact, and to increase the risk related costs of large-scale multi-period projects, reducing the amount of development that is currently showing up in large scale projects.

3. Using a pipeline to store the planned development, and phasing it over time, with an opportunity to revisit/reassess the actual construction as market conditions change in future simulation years. This would help dampen the model considerably, and avoid single-shot over-building, made worse by stochasticity since a large parcel might be fully built in one simulation and not at all in another as currently implemented.

4. Using Monte Carlo simulation of the pro forma calculations to account for more of the uncertainty in the inputs to its calculations, which would generate a probability distribution of results. There are more ideas to bring into the re-envisioning of the model, but these are some of the key ones I want to use to drive the new design.

[Eh2406]

We had been thinking of chopping parcels anyway. So as to smooth development patterns over time. So I guess that they can be combined.

[waddell]

It would just be unfortunate to have to chop them arbitrarily, a priori. Might be a reasonable band-aid in the near term though.