Carbon model requires aligned input rasters (rather than aligning/resizing rasters itself)

[claire-simpson]

The carbon model currently requires that the baseline and alternate LULC rasters be exactly aligned. The model will throw an error if these 2 rasters have different pixel sizes or dimensions. Is there a reason why we require users to provide perfectly aligned input rasters, or could we ease this requirement and instead use pygeoprocessing.align_and_resize_raster_stack based on the baseline LULC raster?

@jagoldstein @newtpatrol @dcdenu4

[jagoldstein]

I like your intention here, but I suppose the reason it's like this now is to ensure that the LULC pixels are reasonable representations of reality. If the model were to realign (and/or resize) pixels, the realigned rasters may be inaccurate, such as if a user obtains LULCs for the two different years from different sources. The way it is now puts the responsibility on the user to critically assess their inputs, which I believe is best.
But I'm curious what others think and do generally support reasonable UX improvements and simplifications.

[newtpatrol]

Hm... Jesse makes a good point that the way it is now forces users to pay attention to their input maps, which is generally a good thing. The carbon model is so simple that any misalignment with the inputs can be obvious in the outputs, and it would be on the user to deal with that.

We can automagically align their layers like we do in other models, but while doing that does make the individual pixels line up, it does not sanity check that any shifting that happens to the alternate LULC shifts pixels in the correct way, so that, say, the same urban street corner pixel appears in the same place in both maps (not off by a pixel in some direction). I've had this issue with freshwater models that do automatic alignment to the DEM, where the result maps are shifted a bit from the original LULC, then it's hard to overlay and compare (especially if you're working in a small area and/or coarse resolution where the individual pixels are obvious).

So I can see where it's temping to auto-align, since that's consistent with other models, and is one less burden for the user. And I also know that the auto-aligning can cause problems. We don't actually address the alignment thing in the User Guide, and usually it's not a big deal, except when it is.

How does Blue Carbon handle it? That's the other model I can think of that takes a series of land cover maps at different times (but it has more actual modeling going on).

[claire-simpson]

Ah that makes sense, I wasn't thinking about it that way since it does seem like most models do the alignment/resizing for the user (Coastal Blue Carbon also does align and resize the LULC rasters). I am curious if the alignment preprocessing that most users would do would be meaningfully different than the alignment we could do for them? Or, if we do have recommendations on how to ensure a user's rasters are properly aligned in a way that reduces the risk of bad pixel shifting, perhaps we could add these to the user's guide?

[dcdenu4]

I am curious if the alignment preprocessing that most users would do would be meaningfully different than the alignment we could do for them?

I'd be curious to know more about this too!

For other InVEST models, certainly one thing we could do a better job of at the moment is explicitly stating which layer is used as the baseline for aligning. We haven't always been consistent with this.

[newtpatrol]

I am curious if the alignment preprocessing that most users would do would be meaningfully different than the alignment we could do for them?

It sounds like it's time to do an experiment in model input aligning, and compare the model's result to me doing the aligning manually. Also to see what happens when I put my intentionally-aligned layers into the model, do they change?

Here's what I usually do, which is pretty simple. Let's say we're talking about current and alternate LULC for Carbon. It happens early in the layer preparation process, often when reprojecting (or, if the layer doesn't need to be reprojected, just exporting to create a new aligned layer).

1. Do all of this either before clipping to the modeling area of interest, or clipped to the area of interest + buffer, in case things shift.
2. Make sure the current LULC has the desired final projected coordinate system, cell size, etc.
3. (If applicable) use the current LULC's coordinate system for reprojecting the alternate LULC
4. Whether reprojecting or simply exporting, set the geoprocessing environment "snap raster" (in Arc) to the current LULC layer
5. Whether reprojecting or simply exporting, I'll often also set the geoprocessing environment "extent" option to the current LULC layer
6. Run the reprojection (or export or whatever) and zoom in to look at the result to see if the pixels actually align correctly.
7. If they don't, then I don't really have a standard way of dealing with that, might go back more steps in the data processing pipeline if possible and repeat a similar process, try with and without setting the extent, etc.

It seems like steps 1 and 3-5 could be automated, and perhaps that's what InVEST actually does? It's the sanity checking of step 6 and fussing of step 7 that really needs a human.

For other InVEST models, certainly one thing we could do a better job of at the moment is explicitly stating which layer is used as the baseline for aligning. We haven't always been consistent with this.

Totally agreed.

Or, if we do have recommendations on how to ensure a user's rasters are properly aligned in a way that reduces the risk of bad pixel shifting, perhaps we could add these to the user's guide?

Also agreed. I'd want to go through the process of understanding exactly what InVEST does, so we can inform the user, as well as make recommendations for pre-aligning that are specific to both Arc and QGIS.