urbansim / urbansim_parcels

New version of urbansim_defaults for compatibility with new developer model
0 stars 1 forks source link

Network-based queries (rather than zone-based) for real estate models #21

Closed pksohn closed 7 years ago

pksohn commented 7 years ago

Currently, our the SD and SF models calculate prices and occupancies using the already-existing "zone" geography (these are traffic analysis zones as I understand it). So, for a given parcel, its rent (in $/sqft) is equivalent to that use's average price for the zone that it is in.

We can do this in a more sophisticated way, by using Pandana to aggregate prices and occupancies (per use) to nodes on the network. For example, get the average price for residential uses within 500m network distance from this node. Then we can assign node prices to parcels, and same with occupancies.

pksohn commented 7 years ago

The plan for this is to set up an occupancy_vars.yaml, similar to price_vars. I would simple need to:

  1. Calculate occupancy for each building
  2. Calculate occupancy for each node using network from_yaml method
  3. Assign occupancies to parcels from nodes

@conorhenley would love your brief sign off on this design

conorhenley commented 7 years ago

@pksohn This looks good to me. This would be built into a callback function?

pksohn commented 7 years ago

I suppose so. Not sure if that's the best way but it seems unnecessary to create another step like occupancy_vars

conorhenley commented 7 years ago

@pksohn do you expect it to be fairly simple to toggle between accessibility-based occupancy and zone-based?

pksohn commented 7 years ago

I could add in both. Do you think that's worth it?

conorhenley commented 7 years ago

It's been useful to test out both access and zone-based rents in the pro forma in the past. I was just thinking that the same might be true here. Sometimes edge effects reflect neighborhood bounds meaningfully, sometimes they don't.

pksohn commented 7 years ago

Cool. I will build in both.

pksohn commented 7 years ago

Addressed with #24.