GUT Plans and Floodplains

[joewheaton]

Email from a GUT User:

I’ve been experimenting with GUT for mapping geomorphic units. Working with an aerial lidar/multibeam DEM covering the channel(s) and floodplain, I’ve gotten GUT to successfully run through Tier 3 and delineate subunits in the channel. I have a few questions I’m hoping you might be able to shed light on (or point me in the right direction if someone else is actively maintaining/working on the tool):

1. We’re hoping to map floodplain features as well as in-channel units. It seems the tool currently does not map floodplain GUs, although your 2015 fluvial taxonomy paper does define them in terms of similar morphometric attributes used to map in-channel units. Is there ongoing or anticipated future work to include floodplain GUs in the tool?
2. Have they not been included so far due to time/funding constraints, or because it proved more challenging to map them meaningfully with this approach?
3. In other words, if you or others aren’t planning to do so in the near future, do you think adapting the code to map floodplain features would be a worthwhile effort? I suspect it would be a non-trivial task to do it right, and am not sure it would be within the scope of this project, but am assessing options.
4. I believe the tool was developed and calibrated with reference to smaller, wadable streams. Has it been used at all in larger systems? Do you have a sense to how robust it is across spatial scales? It looks like the algorithm scales metrics based on channel width. I haven’t done much validation of the Upper Mississippi results yet, and plan to do so more thoroughly. From a first pass examination, they seem pretty reasonable. Before plowing too far ahead, I thought I’d see if anyone had applied it on larger-scale rivers and had experience or results you could point me to.

[joewheaton]

From a GUT User:
I’ve been experimenting with GUT for mapping geomorphic units. Working with an aerial lidar/multibeam DEM covering the channel(s) and floodplain, I’ve gotten GUT to successfully run through Tier 3 and delineate subunits in the channel. I have a few questions I’m hoping you might be able to shed light on (or point me in the right direction if someone else is actively maintaining/working on the tool):

1. We’re hoping to map floodplain features as well as in-channel units. It seems the tool currently does not map floodplain GUs, although your 2015 fluvial taxonomy paper does define them in terms of similar morphometric attributes used to map in-channel units. Is there ongoing or anticipated future work to include floodplain GUs in the tool?

So, I would love to secure funding or a collaboration to bring the floodplain stuff back into GUT explicitly (previously funding focus was on in-channel fish habitat) so we cut it out. The floodplain stuff is actually pretty straight forward to bring back in, but will take some time and GUT also is overdue for a refactor. In the mean-time, you can get Tier 2 form out of GUT by lying to GUT about what the boundaries are of the bankfull channel. It is pretty simple, just edit your bankfull polygon to be valley bottom and include floodplain, and then run it to tier 2. Scott Dietrich (you might have overlapped) actually did this successfully for his Sierra meadow work to look at Willow Fly Catcher habitat.

2. Have they not been included so far due to time/funding constraints, or because it proved more challenging to map them meaningfully with this approach?

Time and funding. We have it scoped and planned and have pitched a few proposals with colleagues in New Zealand and UK, but nothing has yet materialized. We basically want to refactor GUT into a QGIS plugin (similar to GCD) and refactor all the crappy ESRI dependencies so it is more scalable, performant and entirely open source. I have copied @philipbaileynar and Richard Williams here as they have been involved in these efforts.

3. In other words, if you or others aren’t planning to do so in the near future, do you think adapting the code to map floodplain features would be a worthwhile effort? I suspect it would be a non-trivial task to do it right, and am not sure it would be within the scope of this project, but am assessing options.

We don't have plans to do this in next year, nor do I have the time to chase proposals on it in the next year. If someone else chases the funding, we can staff up within North Arrow Research to get the work done. Otherwise, it is likely something I will start pursing in 2-3 years time after some other Riverscape Consortium initiatives are complete.

4. I believe the tool was developed and calibrated with reference to smaller, wadable streams. Has it been used at all in larger systems?

That's correct. It was developed explicitly (but not solely) to work for the CHaMP protocol originally, which included some smaller rivers that were wadeable at low-flow. However, it definitely works on bigger rivers if the bathymetry and topography is good. The real problem with it being "scaled-up" is just a memory allocation issue that is actually easy to overcome with some refactoring, but that was above the pay-grade of the researchers working on it at the time. It is one of the things we have slated to fix if we raise the funds to refactor this. For now, sadly, you just end up splitting bigger reaches into smaller reaches and running separately (note you can still manually merge the inputs, intermediates and outputs later in one project that will work with RAVE.

Do you have a sense to how robust it is across spatial scales? It looks like the algorithm scales metrics based on channel width. I haven’t done much validation of the Upper Mississippi results yet, and plan to do so more thoroughly. From a first pass examination, they seem pretty reasonable. Before plowing too far ahead, I thought I’d see if anyone had applied it on larger-scale rivers and had experience or results you could point me to.

Yes, Richard Williams and I played around a little bit with this on some bigger systems. Because most the algorithms are normalized by bankfull width, it tends to work pretty well. The downside at this stage is just the memory allocation issue.