sqlBRAT does not handle Anabranches

[philipbaileynar]

The old pyBRAT3 anabranch handler was capable of distinguishing mainstem from secondary anabranches. This helped route larger upstream discharges down the mainstem while leaving lower discharges on the secondary anabranches. As a result beaver dams could be supported on the secondary anabranches.

sqlBRAT does not handle anabranches and makes no attempt to distribute discharge down different channels. The end result is that all anabranches in the main valley bottom are unable to support beaver dams (see Elk Creek below). Here's a section of a video where @joewheaton identifies the problem.

Note that sqlBRAT uses the "total upstream drainage area" values for each reach that are pre-calculated and come shipped with NHDPlus network. We do not use our own flow accumulation and drainage area rasters (although they are calculated and part of riverscapes context). The NHDPlus data does, however, have several "value added attrivutes" (VAA) that describe the proportion of flow that passes into each Anabranch, as well as several other fields that I think can inform our workflow. I have not looked into these values and their potential usefulness for solving this problem.

NHDPlus also has topological information that can be used to build a NetworkX graph in memory that we can perhaps use to improve upon the way the old Anabranch handler tool used to work.

In conclusion:

1. Let's @joewheaton @wally-mac @MattReimer @tyler1218hatch meet to discuss how best to proceed.
2. I feel strongly that sqlBRAT should continue to use the NHDPlus total upstream drainage area attribute values and not revert to using our own flow accumulation rasters.
3. As always, my preference is to find a simple, reliable, automated process for distinguishing the mainstem from secondary anabranches. I want to try really hard to avoid a mandatory manual step in the middle of the BRAT workflow that we have expended so much effort on automating!

[philipbaileynar]

I have started researching how NHDPlus data can support splitting upstream drainage area between mainstem and secondary Anabranches. I haven't completely solved the problem, but I am more convinced than ever that NHDPlus contains the necessary information to make this possible. Here's a quick video explaining:

https://www.youtube.com/watch?v=m7NlU3lvr0A

[joewheaton]

This is really, really interesting. Very promising. Not that we want to do exactly what we did in pyBRAT, but we were getting "the right answer, reasonably consistently for the wrong reason'.
Just to clarify what pyBRAT did and why it worked:

• By right answer, I mean that primary anabranches had high stream power (actually too high, as they took all the drainage area with no partitioning of flow or drainage area) and low or no capacity, and the secondary anabranches had low stream power and could support some capacity to build beaver dams. This is what @kbartelt terms "floodplain" type systems instead of "classic".
• This was desirable to capture schematically and conceptually lots of capacity in a riverscape, even when no capacity on a main channel/anabranch.
• For every segment in pyBRAT (with no topological sense) it searched all intersecting and nearby drainage area grid cells for the max value
• The result of this was (typically) that a "primary or main anabranch" had a high drainage area and because the secondary anabranches were off on the floodplain had artificially low drainage areas. This produced above desireable (but technically wrong result).
• I don't actually know exactly what we did with the logic on the classification of Anabranches (whether we forced the above issue or something). What I do know is that it was useful byitself as an attribute!

Moving forward, what we want is to get to a BRAT capacity estimate that is the right answer, ideally for the right reason. From your video it appears those VAA (value added attributes) are amazing in NHDPlus HR