Run BRAT off of channel area projects instead of drainage network lines

[philipbaileynar]

What problem are you trying to solve here Jordan? Who requested this?

Some issues for you to think about:

• I don't think the channel area polygons are segmented to 300m.
• The top, bottom and midpoint of the reach polylines for several geophysical attributes (slope, elevation, length etc) that are harder with polygons.
• I don't think the channel area polygons do not have NHD attributes needed to calculate discharge and therefore stream power.

[jtgilbert]

@philipbaileynar yeah, this is kind of a place holder to think about how to make this change (an improvement @joewheaton wants). The model will still have to be based off of the network because of the segmentation, attributes, all of that. the main reason for adding channel area is to:

• use it as a mask so you can ignore raster cells within the channel, like open water in LANDFIRE
• summarize some output metrics by channel area instead of length

[joewheaton]

@jtgilbert is right on some of the reasons. Additionally,

• the channel area projects are what we plan to invite users to invest time in making a better input into any model. If we invite them to do this on a segment by segment basis, they will not necessarily do it for all segments, but they will want to see it having benefit to the segments they curate.
• the "logic" of the vegetation model makes more sense (particularly in bigger rivers) to go from the approximate water's edge than it does from a centerline. It is how we explain the model in the paper, and notionally means we get a "better" sample of the vegetation (also avoids the problems with reservoirs).

This change is likely only to produce insignificant or modest benefits for BRAT as it is currently run with free national data. However, this change will help us a ton in performance as BRAT starts to ingest higher resolution vegetation data, custom inputs (e.g. MHFD) and for what we are on the hook for with NASA on the myBRAT "commercial-grade" version of BRAT. Much like we did with VBET, this is benefit that will help us going forward. Also, I want confinement to be run off its own channel area project instead of some garbage it buffers with untransparent assumptions on its own. Lets isolate that process back to ChannelArea. So abstracting this piece out now, helps us. Finally, although we don't currently do this, there is no reason that a channel area project could not also or only be the network line.

Re these excellent points:

Some issues for you to think about:

• I don't think the channel area polygons are segmented to 300m.

We might need to sort this out (at least ability do do it) for things like VBET and confinement anyway

• The top, bottom and midpoint of the reach polylines for several geophysical attributes (slope, elevation, length etc) that are harder with polygons.

Calculating buffers from polygons as opposed to lines does not preclude us from still calculating some things on polylines where it still make sense. What it means is we need to have a common currency (e.g. reachID) between our polylines and polygons. This is a known issue we need to fix/solve anyway for VBET to get to finish line.

• I don't think the channel area polygons do not have NHD attributes needed to calculate discharge and therefore stream power.

True. They need to - period.

[philipbaileynar]

There are four tasks here:

1. Coming up with the idea to use channel area instead of buffering lines.
2. Figuring out how this will work in the context of BRAT.
3. Writing the code.
4. Testing and QC.

Task 1, 3 and 4 are easy. Who is doing task 2?

Task 2 is multiple weeks, probably a month or two of work.

[joewheaton]

There are four tasks here:

1. Coming up with the idea to use channel area instead of buffering lines.
2. Figuring out how this will work in the context of BRAT.
3. Writing the code.
4. Testing and QC.

Well put.

Task 1, 3 and 4 are easy. Who is doing task 2?

@jtgilbert and @joewheaton. Lets be very clear what we're talking about here. The proposal could change everything so that BRAT information is all stored on channel area polygons instead of segmented networks. I'm not thinking that's what we want to do to start. What I was proposing is substituting the step that runs buffers to buffer off of channel areas instead of off of polylines. The hard part here is having that buffer keep the perpendicular line from the segment boundary. Anyhow, let us play around and figure out if the scope of what we're talking about is a mountain or a mole hill then regroup.

Task 2 is multiple weeks, probably a month or two of work.

I think you mean Task 3? If it is a month or two of work, I'll be very surprised. But maybe you are right... Maybe this is a bigger issue...

I suppose I should confess that my future hope for BRAT, after VBET is done, is to add a step that recasts this to a riverscape network model from a channel model. In other words, we still run BRAT like we do where channels are the segments things get calculated on, but we then summarize them onto riverscape segments. In other words, if I have multiple channels they have a total length and a total number of dams within a riverscape segment. With those primary measures we can have a riverscape BRAT density (dams / km riverscape) as well as an average channel BRAT density for the riverscape segment (dams / k