Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide how HRA should handle rasterization #1122

Closed
phargogh opened this issue Nov 21, 2022 · 2 comments
Closed

Decide how HRA should handle rasterization #1122

phargogh opened this issue Nov 21, 2022 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@phargogh
Copy link
Member

HRA is a raster-based model that uses rasterization to transform spatially explicit vectors into rasters ahead of the analysis. A user on the forums discovered a regression in the model where on certain inputs and at certain spatial resolutions you can end up with spatial criteria being 'buffered' due to the rasterization option ALL_TOUCHED=TRUE. By contrast, InVEST 3.9 uses ALL_TOUCHED=FALSE for spatial criteria only. For the sake of resolving that issue, #1120 / #1121 corrects that regression so behavior is consistent with the 3.9 version of HRA.

But the question remains: why would we want to use 2 different methods of rasterization for spatial criteria?

If memory serves, spatial criteria were added in the 3.7.0 rebuild of HRA (which stuck around until it was replaced in 3.12.0), so we may not have had a reference for this before.

Related: #1079
This is a continuation of #1120

@phargogh phargogh added the question Further information is requested label Nov 21, 2022
@phargogh phargogh self-assigned this Nov 21, 2022
@phargogh
Copy link
Member Author

@davemfish and I asked Jade about this (if she could think of a reason why spatial criteria might be rasterized differently) in a DM on slack, and her response was:

the only reason why I can think different approaches were used has to do with not over inflation the habitat at risk. When rasterizing the habitat you want to make sure that even small polygons get picked up (when yo I try to rasterize a vector if you start at 500 m for instance, little polygons often don’t make it into the 500m raster) but w the touched = true I can see that those small polygons would make it. That process in itself will largely increase that habitat area in the raster relative to the polygon.
Then when doing the risk analysis by rasterizing the criteria more ‘conservatively’ (if I understand the approach correctly) the habitat at risk would be closer to the area of the habitat in the polygon format.

@davemfish
Copy link
Contributor

I just took a quick look at the sample data. It seems commonplace for the footprint of a spatial criteria layer to exactly match the footprint of either a habitat or stressor. So I could imagine that rasterizing with different rules could result in a problem where, after rasterizing, a pixel on the margin might have presence of both the habitat & stressor, but would be missing the spatial criteria rating associated with that habitat-stressor pair.

I'm not sure if Jade is suggesting this is a feature and not a bug, but it seems like a hacky way to accomplish the goal of conservatively estimating risk. A better approach in my opinion would be for the user to reduce the risk values in the spatially explicit layer, rather than have the model silently reduce its footprint during rasterization.

If the criteria layers are rasterized differently from the habitat or stressor they represent -- when they all had identical vector geometries to begin with -- it's just a matter of time before someone is confused by that.

@natcap natcap locked and limited conversation to collaborators May 9, 2023
@dcdenu4 dcdenu4 converted this issue into discussion #1309 May 9, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants