Urban Cooling: change building-intensity metric to "floor-area-ratio (FAR)"

[jagoldstein]

My understanding of the "building_intensity" data requirement of the Urban Cooling model's biophysical table is that it should be:

"the ratio of building footprint floor area to land footprint area, with all values in this column normalized between 0 and 1. Required if the ‘intensity’ option is selected for the Cooling Capacity Calculation Method."

This change makes much more sense to me based on how the model is described to work. Also, with the current definition, values ought to be accepted that are >1, such as for multi-story buildings. This change would also seem to align better with the energy consumption table note:

The consumption value is per unit of footprint area, not floor area. This value must be adjusted for the average number of stories for structures of this type.

Please correct me if I'm mistaken.

[davemfish]

I'm not sure @jagoldstein , if the building area only includes the footprint of one floor, then single-story buildings are equivalent to multi-story buildings, which doesn't seem right. I think it's okay for this floor_area / footprint_area ratio to be > 1. And then the description says these values should then be normalized (by the user) to between 0 and 1, probably because it is uncommon to have good data on number of floors per building. So using normalized intensities allows people to either A) use data on number of floors to calculate the floor_area / footprint_area ratio if they can, or B) simply choose values between 0 and 1 that vary by building "type" when they lack data on number of floors.

The consumption value is per unit of footprint area, not floor area. This value must be adjusted for the average number of stories for structures of this type.

Again I'm guessing it is because the floor area (or # of floors) is not known, only the footprint area is. So the consumption value is per footprint area, and then the model scales it by building "type", which is a required attribute of the buildings vector.

What do you think @chrisnootenboom ?

[chrisnootenboom]

My understanding of the "building_intensity" parameter comes from the architecture world, in which flood area ratio (FAR) is a common measure of building size (https://en.wikipedia.org/wiki/Floor_area_ratio). FAR can and often does exceed 1 for multistory buildings. This is a great way to measure the vertical density of the built environment, which is what the "building_intensity" parameter seeks to do.

However, in the UCM the building_intensity parameter is only used in calculating the Cooling Capacity Index (Eq. 107) and to do so it must be normalized from 0 to 1. Normalizing the parameter changes it from an actual measure of FAR to a unitless index which is not useful for calculating building energy expenditure; in fact, the model does not use building_intensity at all in its energy consumption calculations, instead multiplying the building's footprint area by the change in temperature-related energy expenditures per m2 (see the quote Dave brought in). The normalized FAR is still a good way of estimating Cooling Capacity, since the buildings with the highest FAR (read: tallest and taking up the most space on their parcel of land) will achieve a normalized 1 and have the least cooling capacity.

As regards the energy side of things, I think this is somewhat of an oversimplification in the model. Changes in energy expenditures per m2 should scale with building height, since additional floors add more m2 of floor area to heat/cool. Currently the only way to deal with this, as Dave flags, is by artificially scaling building energy expenditures by height: the user must adapt a typical kWh/C/m2 measure by multiplying it by the expected number of stories before running the model. Rather than leave this artificial scaling to the user, I would suggest replacing the "building_intensity" parameter with an explicit "floor area ratio" parameter that is allowed to exceed 1. The model can normalize FAR to calculate cooling capacity but revert to a non-normalized FAR to scale energy expenditure by height, without relying on the user to provide anything more than a typical measure of energy cost and a typical estimate of building floor area via FAR.

But to clarify Jesse's initial question: the documentation is correct as it stands.

[jagoldstein]

Ah ok, I believe I understand this now, thanks for clarifying @davemfish and @chrisnootenboom. It was helpful to hear this described another way, and especially that

the model does not use building_intensity at all in its energy consumption calculations, instead multiplying the building's footprint area by the change in temperature-related energy expenditures per m2...

So, the building_intensity values are purely user defined and are only meaningful as relative to one another, respective of building type, within a single model run, correct? Absolute building_intensity values are meaningless on their own.

So, if I only had 3 building types, and

• type A's FAR=3
• type B's FAR=1, and
• type C's FAR=0.5,

then their building_intensity values would be:

• type A=1,
• type B=0.2, and
• type C=0.

I like Chris' suggestion to

Rather than leave this artificial scaling to the user, I would suggest replacing the "building_intensity" parameter with an explicit "floor area ratio" parameter that is allowed to exceed 1.

I agree that such a change would make parameterization more intuitive for users.

[jagoldstein]

ok, I was confusing building_intensity and building type. the intensity is mapped to LULC classes, not to types in the buildings vector and energy consumption table.

[davemfish]

Yes, it sounds like we're all on the same page now @jagoldstein

Rather than leave this artificial scaling to the user, I would suggest replacing the "building_intensity" parameter with an explicit "floor area ratio" parameter that is allowed to exceed 1.

I agree that such a change would make parameterization more intuitive for users.

I think I also agree with this. I'm just trying to think about the case where the user does not have any empirical data on number of floors. Is it still easier for them to create reasonable estimates of FAR -- maybe only varying them by building "type" -- than it is to create intensities from 0 -1? I think the answer might be, yes, FAR is still more intuitive. If so, we should consider changing it.

[chrisnootenboom]

So in the case of data-poor areas, the original method could still hold true for calculating cooling--if the user puts in 'building_intensity' from 0 to 1 as a proxy for an empirical FAR, the model will still calculate cooling capacity no problem (the normalization step would just be trivial). If they lack data on FAR (and thus total building area), energy use calculations will already be highly uncertain, so as long as we caveat that in the users' guide I think it is the better choice.

[davemfish]

if the user puts in 'building_intensity' from 0 to 1 as a proxy for an empirical FAR, the model will still calculate cooling capacity no problem (the normalization step would just be trivial).

That's true! Though if we rename the column to "floor-area-ratio" then users will not be entering values between 0 and 1. Anyway, this change sounds like a good idea to me!

[dcdenu4]

Hey All, to make sure we don't lose this great discussion in the Users Guide issue queue how would folks feel about using the transfer feature to park it over in the InVEST queue?

Also, pertaining to Jesse's original question, are any UG / ARG_SPEC updates actually needed?

[davemfish]

Good idea, Doug. I don't think any UG/docs changes are needed at this point.

[jagoldstein]

Yes, please transfer this to the proper queue and repo. I realized last night that it's not a UG issue after all, and was wondering if I should close this, but I was not aware of the transfer feature.