Key to New Riverscape Network - Topology & "hydroenforcement"

[joewheaton]

Central to deriving a centerline (#396) from our new segmented valley bottoms (#414) is creating a new, simplified riverscape network. This new riverscape network will be far simpler than the 1:24K USGS Drainage Network (channels) and even the 1:100K network. Although the solution we seek should be mindful about being applicable outside the US, we should really adopt similar procedures to what the USGS does. The purpose of this discussion is to propose (a) method(s) for topological enforcement of riverscape segments and the riverscape centerline network. After discussed by the @Riverscapes/developers, we will create the enhancement issue(s) needed to try it out.

Proposed Hydroenforcement

A little NHD+ USGS Inspiration

Archuleta and Terziotti (2020, p. 10 describe hydroenforcement as:

".. aligning the streams in the high-resolution NHDPlus drainage network onto the 3DEP DEM data; this alignment is achieved through overlaying the mapped stream network onto the 3DEP DEM (creating virtual trenches at the locations of the streams) and enforcing the WBD hydrologic divides through “walls” (lines of raster cells with greatly exaggerated elevation values)."

The key here for the topology is a "FromNode" and "ToNode" as well as a NHDPlusID every. This is admittedly easier for a line network as their are discrete node points that can be "shared". For example in the figure below, FID 4241 and 8391 share the same "ToNode" of A, and FID 8390 would have a primary FromNode of 8391, but also 4241. :

These are the fields they use (highlighting where topology gets described:

Our challenge is how to do this for valley bottom segments (or sausage links).

Hydroenforcement on Sausages?

The following fields to facilitate topology could be defined in both the vbet_68 polygon and a new vbet_68_cl polyline in the vbet.gpkg outputs in VBET projects:

Field Name	Data Type	Allow Nulls	Alias Name	Domain	Precision	Scale	Length	Comments
VB_Code	String	No	ValleyBottom_Code	NA	0	0	18	A valley bottom specific code that starts with HUC12 and appends a six-digit unique number
VB_From	Double list	Yes (for headwaters)	ValleyBottom_From_Code	NA	0	0	18 digit code(s) in array	The list of immediately adjacent upstream and/or tributary valley bottoms feeding that valley bottom segment
VB_To	Double list	Yes (for sinks)	ValleyBottom_To_Code	NA	0	0	18 digit code(s) in array	The list of immediately adjacent downstream valley bottoms segments receiving from this valley bottom (generally only one, but valley bottom difluences are possible)
VB_Headwater	Bool	No	ValleyBottom_Links	NA	0	NoYes	NA	Is this the special case of headwaters

We can debate about the HUC12 suffix, but I think this will help us later. As for the rest of the number, Kelly already generates a LevelPathI, which appears to be systematic but not unique? That might help? Otherwise, maybe we do something like first part of number comes from count of all unique headwaters in HUC12, then sequencing downstream from each using network trace traverse (we figured out flow direction. Yes, @philipbaileynar and @nick4rivers, this will be a pain in the ass to tweak or edit for user edited feature-classes in Riverscapes Studio, but, I don't think we need to concern ourselves with maintaining topological integrity of an entire network for those myVBET projects. All we need to worry about is topological integrity of "connected" or intersecting valley bottom segments in their project.

We have network traversing in the Network Attributes tool, or we can use stuff from USGS Streamer or Sam Learner's River Runner, or something else more clever that @MattReimer figures out.

Step 1 - Find headwater valley bottoms

If we start by identifying headwater node points of drainage network input, we can then flag these as "headwater" valley bottoms.

Here are steeper headwaters in the mid-part of a catchment:

Step 2 - Find intersection zones

I think we can identify shared edges based on what we already have from @KellyMWhitehead segmentation (overlaps highlighted in orange).

Step 3 - Intersect Intersection zones with Network Traverse

Using the network we have (requisite that it has topology and has those key upstream point elevation, downstream point elevation), work downstream and flag each intersection, with the VBET_Up and VBET_Down values. This starts in a headwater, and continues downstream along network until it intersects what has to be leaving. While that valley bottom is the focus, it generates the VB_Code. In the process, it will pass by all all its tributaries. The process repeats until the end or bottom of the catchment is found. At each Intersection Zone, place intersection points found from stream network in vbet_intermediate.gpkg for later use in inferring centerlines.

Note that TauDEM has a lot of Stream Network Tools that are what the USGS used for NHD + and we could eventually or selectively employ if we need things like finding outlets ,

Step 4 - After symbology is applied to VB Sausage Links, Copy Attributes to Centerline Riverscape Network

If we do the hard part of imposing this topology for the valley bottom polygons first, then we:

1. Independently derive Centerlines (Decide and Implement new Centerline Strategy #382) for each valley bottom cell working in the topological order defined by VB_Code topology. Note that headwater centerlines will have special case of a NON-Intersecting upstream end point, and downstream end points are found. All non-headwater centerlines will share the upstream end-point with the downstream end-point of their VBET_Up parent.
2. These primary centerlines shall simply have the same attributes copied into their attribute table from the valley bottoms. They will be the main axis of the valley bottom.
3. Tributary *centerlines (similar to connectors in NHD) will represent the length of centerline that extends from the tributaries to the primary centerline. These will have the same attributes copied in as well, but also have a true value for a VB_CL_Trib field. The four point types shown below will be helpful to derive, but unlike the polygons, the polyline centerline should NOT overlap.

---

References

• Archuleta CM, Terziotti S. 2020. Elevation-Derived Hydrography—Representation, Extraction, Attribution, and Delineation Rules. In Book 11, Collection and Delineation of Spatial Data , 60. https://doi.org/10.3133/tm11B12

@philipbaileynar and @KellyMWhitehead please suggest changes or ask clarifications. If this sounds okay, lets try it and see where it breaks.

[philipbaileynar]

See my response on #414.

[lauren-herbine]

@joewheaton How relevant is any of this now? Has any of this been tried/implemented, or are we/did we move away from this?