Closed pksohn closed 7 years ago
The plan for this is to set up an occupancy_vars.yaml, similar to price_vars. I would simple need to:
@conorhenley would love your brief sign off on this design
@pksohn This looks good to me. This would be built into a callback function?
I suppose so. Not sure if that's the best way but it seems unnecessary to create another step like occupancy_vars
@pksohn do you expect it to be fairly simple to toggle between accessibility-based occupancy and zone-based?
I could add in both. Do you think that's worth it?
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.
Cool. I will build in both.
Addressed with #24.
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.