Hi, I’m wondering if there’s any issue with using the Urban Cooling Model in a rural setting.
We’d like to quantify the welfare benefits to livestock of tree planting.
As well as shade, there will be a cooling effect from increased evapotranspiration and induced cooling breeze (the so-called ‘vegetation breeze’ phenomenon from cool, humid air under clusters of trees.
I don’t see any limitations listed relating to using this tool outside of urban areas.
Cheers
Richard
Hi @Minton71 ,
Thank you for writing in with your question!
As far as I can tell, InVEST’s Urban Cooling model is suitable for the clever application you’ve described in a rural setting. Please just be aware of the resolution of your input data to ensure the scale is fine enough to capture individual clusters of trees as opposed to only entire forest patches. However, I don’t believe the model explicitly deals with the ‘vegetative breeze’ phenomenon caused by differential heating and humidity in naturally shaded versus unshaded areas, so you may need to parameterize carefully to try to incorporate that effect. The model will also consider the cooling or heating impacts caused by changes in albedo associated with changes in land cover (trees versus pasture).
Perhaps @chris could provide more clarity.
We’d be curious to hear back from you later about how successful (or not) your modeling goes for this using InVEST!
-Jesse
1 Like
Hi Jesse and @chris
I have a question about UHImax in this exercise (looking at using the UC model in a rural context).
I’m trying to understand how HMi is calculated - refer equation 107. I’m not sure if its me or if its a problem with formatting but I can’t decipher the logic of whats being said between the {parentheses}. HMi is critical to understanding the influence on UHImax on Tair no mix (Tair no mix = Tair,rural + (1-HMi) x UHImax) (equation 108). If you can help me with the logic of Eq. 107 it should help me parameterise UHImax for application in a rural context (i.e. how to differntiate it from Tair,rural (aka Tair,ref.)
I hope I’ve explained my query sufficiently.
Cheers
Richard
Hi @Minton71,
HMi equals CC for pixels that are unaffected by any green spaces >2 ha. For pixels that ARE affected by any green spaces >2 ha, HMi equals the distance-weighted average of the CC values from those large green spaces and the pixels of interest.
This post may help explain more.
-Jesse
Hi Jesse
Thanks, this answers my query about the logic of HMi.
I’m now running the model and hitting a very slow process at the very end of the run:
Can you advise what component might be slowing the model down?
Cheers
Richard
Hi @Minton71 ,
Can you please upload your log file (.txt) here once the run completes? How long is it taking to complete in total, minutes, hours, days?
Thanks,
Jesse
Hi Jesse
The model took about an hour and a half to run. This is longer than previous attempts, but may be normal?
Hopefully we can find a way to run faster trails that will allow me to play around with parameters to see how we can adapt this model for patoral use.
Please see the log file attached.
Cheers
Richard
Slow run times are typically caused by:
- compute speeds,
- large spatial extent of the LULC raster input, or
- high spatial resolution of the LULC raster input.
Since all InVEST Urban Cooling raster results are resampled to match the LULC input, consider resampling your LULC to be coarser or clipping it to a smaller extent. What is the file size of your LULC input?
What did you change from your previous runs which completed more quickly?
-Jesse
Hi @Minton71 ,
Just to add on to what @jesseG said in terms of runtime, this model does some convolutions which is an expensive operation depending on resolution and the distance being convolved.
As Jesse noted I’d be curious what the size and resolution of your input rasters are.
Cheers,
Doug
Hi Doug and @jesseG
- LULC raster = 1.31 MB - I had to do a shape to raster conversion to get this file, so its bigger than it needs to be. Not quite sure how to get under the hood to reduce this but I can figure it out if you think its critical. Its clipped right down to the research area / site boundary.
- ET raster = 0.000016 MB (16B)
What did I change from my previous runs which completed more quickly? Addition of the ET raster! In error I had previously run the model using a solar radiation tiff (319kb) in place of the ET tiff. These were taking much longer i.e. I quit after 1.5 hours @ 2% completion
Cheers
Richard
Hi @Minton71 -
Those files are tiny! Do they happen to be in a geographic coordinate system (with distances in degrees), instead of a projected coordinate system (with distances in meters, which is required)? Having a mismatch between the usually very small degree values, and the model inputs that are expressed in meters can cause strange things to happen. I think the model should catch this and throw an error early on (since other models catch this), but I haven’t used Urban Cooling lately. Just a thought.
~ Stacie
Hi Stacie
Both are in a projected coordinate system.
Cheers
Richard
Hi @Minton71,
If you’d like to share your data I’d be happy to give this a run on my end to see if anything jumps out for why it would be taking so long to run. If the files are that small you can probably post everything here, or you can share via a cloud service.
Doug
Hi Doug – whats the best method for sharing? I use ArcGIS Pro – what file would I send to you?
Hi @Minton71 , I’ve found sharing data via Google Drive to be pretty easy. To reproduce your run on our end and investigate we would need all your input data for the model. If you could zip all the inputs into a folder and share that zip via Google Drive, that would be great.
Thanks,
Doug
Hi Doug
Would you mind accessing it via Dropbox:
https://www.dropbox.com/sh/iki3x67eh9k9zaw/AADcwJYv0Cyni0RaEuUVSFRQa?dl=0
Kind regards
Richard
Hi Doug – just wondering if you found time to take a look at this?
Cheers
Richard
Hi, further to above discussion, I’ve used new data and the model is working much faster. I have got another issue however and that is there is a disconnect between my LULC raster and biophysical table. Please see attached log file. I have updated the raster to remove the referred to [0] value, but am getting the same error. I notice when I export the raster as a TIF for input into InVEST, the attribute field name defaults to VALUE (instead of lucode). But it seems the model is seeing past this, as it appears to pick up the values (LULC codes) that are in the raster.
link to relevant data including log file:
Thanks for the data @Minton71 -
Looking at the data you uploaded, and there is indeed a value of 0 in the raster UC_merge6_2_1.tif, which is not in the biophysical table. Over 300,000 cells are assigned this value, so you’ll need to figure out whether they’re their own class (such that 0 needs to be assigned a value in the biophysical table) or whether the 0 values need to be reclassified into one of your other LULC classes.
You’re correct that the default raster field is called VALUE, and that works just fine for InVEST.
~ Stacie