Segmentation of Valley Bottom Suggestions & Observatons

[joewheaton]

The goal of this discussion is to find agreement among the @Riverscapes/developers on how we move forward with segmentation, centerlines and topology. I am consolidating the plethora of duplicative tickets and articulation of this need to here (closing those issues). I don't care if we stick with the proposal, but we need to move past these repeating discussions and get some actionable tickets and try some things. In my review of VBET, I see things actually looking pretty positive (not perfect). I can live with imperfection in solutions from imperfect national datasets. Even in what we are already doing, VBET looks good at over 80% of the riverscape network! Let's build off that.

Background

Can skip ahead to actions proposed as "Answers" below, but this is where we consolidate what has been discussed and proposed.
Segmentation of valley bottom area is perhaps one of the most difficult remaining issues to crack for the @Riverscapes/developers team for VBET and all its downstream dependencies (i.e. metric calculation, confinement tool, GNAT, river styling, commercial grade VBET experience, Riverscapes Studio (QRiS). To highlight how tricky this is, here's a short list of some of the many issues and discussions that are either explicitly about segmentation, or can't be meaningfully solved until segmentation is decided.

Segmentation Issues

• In Segmentation questions #326, @lauren-herbine poses some fundamental questions about segmentation that remain unanswered.
• In Valley Bottom Segmentation Tool #17 @joewheaton lays out why we need segmentation and illustrated it. But @philipbaileynar poses the challenges and questions that are never answered or decided on (I'll put those down below).

Related Metric Issues

• In Specify the VBET Segment Metric Calculation #395, we need to calculate metrics, but there is apprehension in calculating them until we know what what segmentation looks like.
• In Valley Bottom Segmentation QRiS#18, we ask the exact same question but for the QGIS Desktop version of Riverscapes Studio - QRiS
• In Gradient and Sinuosity Calculations #225, we get dangerously close to providing the full specification of metrics that @philipbaileynar asks for in Specify the VBET Segment Metric Calculation #395, but we stall out on segmentation issues.
• In discussions on a project in the UK a few years back Duncan Hornby highlights some interesting related issues in segmenting valley bottoms and calculating reach metrics How to create a valley centre line? ConfinementTool#39
• In VBET Attributes #9, @joewheaton highlights the primary VBET metrics he wants, many of which depend on Valley Centerline Length (this was converted to discussion VBET Attributes #385, and is also what @philipbaileynar is asking for in Specify the VBET Segment Metric Calculation #395
• In Master List of Reach Attributes - GNAT and River Styler #118 we get more into the master list of reach attributes for River Styling and GNAT purposes, but all of these are dependent on VBET segmentation.
• In VBET Sausage Links - Metrics wishlist brainstorm #108 @joewheaton laid out a pretty comprehensive list of VBET metrics (by sausagelinks). Similar discussions have been started in VBET Metrics #346 and VBET Attributes #385

Related Valley Bottom "Centerline" or "Riverscape Network" Topology Issues

• In Figure out Algorithm for deriving polygon segment (channel area or valley bottom) Centerlines #396, the same old boring question gets posed duplicativelly again...
• In Key to New Riverscape Network - Topology & "hydroenforcement" #419 @joewheaton suggests a new topology method to implement for valley bottom segments first and then apply to centerlines.

@KellyMWhitehead highlights in these tickets "failure" of running centerlines from these segments. The segmentation and centerline calculations are computationally expensive.

• VBET Centerlines Cybercastor run Failures #287
• Vbet centerline fail on HUC 10090102 #311
• VBET Failed for Huc 16010202 (int argument is coming in None) #338

On how to actually do Centerlines:

• In Valley-bottom centerline #270 @philipbaileynar suggests a few ideas and points to RiverTools open source code for generating centerlines.
• In Decide and Implement new Centerline Strategy #382 we flag up deciding a new Centerline Strategy (and have not tried it, nor is there any discussion from @Riverscapes/developers or @shelbysawyer or @lauren-herbine on the proposal). @philipbaileynar and I discussed this a little, but not followed up or through.
• In Riverscape Network Generator Tool #16 @joewheaton suggested that we need a new 'Riverscape Network Generator Tool'. We know this network is really just the centerline of the valley bottom output, and should be simpler than the channel network. We do not need a new different tool, but this will just be a new default output of VBET, and Riverscapes Studio allows additional segmentation of it.

The Problems @philipbaileynar Posed & Some "Responses"

From #17 and prior to more thorough interrogation of what @KellyMWhitehead implemented for initial segmentation based on stream order and NHD attributes, these are legit questions that @philipbaileynar posed:

I appreciate the value of this and we can make progress here, but this is going to require lots of
discussion. Everything looks so perfect and tidy in an isolated single channel situation. But the image below is the NHD network (red) in Bear Valley (16010202) with 60% VBET in green. Where's the valley? What's a tributary?

So, we don't concern ourselves with the valley (yet) in VBET. Just the valley bottom. It is really hard for me to know for sure without better context of hillshade, but just based on flowline geometry, below is my best guess at answers to your question from that screen shot @philipbaileynar :

I guess my questions are:

• Is segmentation something we do everywhere or something we run on a case by case basis in places of interest/restoration/funding?

I think we have a default, coarse segmentation in VBET, and segmentation is something that is very user-driven in Riverscapes Studio. I think I have articulated that now in #389 and #390. Agreed @philipbaileynar?

• The segments in your graphic are perpendicular to the valley centerline. This tells me we need to incorporate a centerline algorithm.

Absolutely! Centerlines are fundamental. See above on centerline issues and lets focus our strategy there in #382.

• What is a tributary?

A tributary is a smaller (drainage area and flow), typically steeper, valley bottom or stream(s) that join a larger, flatter "mainstem". With channel networks we have to be careful to differentiate three types of confluences ():

1. Tributary confluences
2. Anabranch confluences (sourced from anabranch that split at diffluence upstream on same mainstem)
3. Channel head or backwater confluences, who initiate as headcuts on the mainstem's valley bottom or floodplain. These often form in response to localized incision associated with return flows from overbank flows.

Tributary channels are pretty easy to differentiate from mainstems as before they reach their "alluvial fans" or terminus, they are generally flowing at more perpendicular orientations into the trunk valley or valley bottom. Tributary channels can sometimes become distributary channels across their fans (more difluences than confluences) and frequently avulse across fans. When they join the mainstem channel(s), their orientation really depends on whether or not they are

• a) still on their alluvial fan (i.e. distal edge of fan abuts mainstem),
• b) working their way across the trunk valley bottom (in which case their orientation often shifts downstream with the trunk orientation), or c) the more complicated "shared-custody" situations (i.e. where answer to who's valley bottom is it is both the tributary and mainstem as they can both plausibly flood that land).

We need to differentiate tributary channels (from NHD) from tributary valleys. This helps us get at "who's valley bottom is it"? I suggest that we use the stream-order stuff @KellyMWhitehead is using right now to give us our "transform zones" as some assistance in the answer to this. Another way of saying this is

Is it any junction? Or only where stream order changes?

No. junction types for confluences above defined. Other junctions include diffluences. We are only interested in tributary valley bottom junctions for our purposes here.

Below is a more sensible location in the same Bear Valley HUC. How many valleys and tribs are shown? (I know VBET needs to be extended for the entire network not just the perennial).

So in the figure below I label all the tributary confluences with blue circles (n=22) and label stream order with numbers.

The question of how many valley bottoms (implied segments) could be viewed as as a stream order question. If we did so, we might follow (topologically) downstream on the valley bottom network and just stay as one valley bottom segment as long as stream order does not change. Whenever stream order changes, you end up with a new segment. I think this is roughly what @KellyMWhitehead is already doing. Essentially:

• All of the 1's (first order) are their own segments
• The 2's are their own segments (i.e. NOT broken at tributary junctions unless stream order increases by n+1)

By this accounting, in the figure above:

Stream Order	Number of Valley Bottom Segments	Number of tributaries Past up without splitting
1st	26	0
2nd	6	1 (just N)
3rd	2	8 (7 from B → H; and 1 with O)
4th	1	2 (J & K)
Sum	39	11

So @philipbaileynar in that example there are 39 valley bottom segments, in if you split at all junctions would be roughly 50 segments. This is basically the difference between Strahler (what we're proposing) and Shreve Stream Order:

The reason I like Strahler better for now is it avoids mainstem rivers, which are characterized by lots of smaller inputs, getting tweaked whenever a minor tributary feeds in. This will help us for River Styling at a more appropriate scale. If a user zooms into "their" riverscape and wants to split, let them. But we don't need to for reporting of metrics.

That all sounds nice, like you say @philipbaileynar for a simpler dendritic network. So how does this work when we get downstream. I will attempt to tackle that in my suggestions below. However, the above does help us out with 80 to 90% of the network, so lets celebrate that. It is the 5th order and higher wear stuff goes pear shaped.

In summary... we can develop a segmentation, but I'm not sure it makes sense everywhere and I think generic rules that work everywhere are going to be difficult.

Difficult yes... impossible no. I think the key is to isolate user splitting and subjectivity of segmentation to Riverscapes Studio, and just focus on broad brushed segments out of default VBET.

---

Questions to be addressed in this discussion

• 1. What parts of existing segmentation are working well?
• 2. What parts of existing segmentation are falling apart?
• 3. What alternatives and ideas are there for improving the parts where we're struggling?
• 4. What are our priorities for trying these ideas out?

[joewheaton]

Based largely on observations from our test St. Vrain VBET for HUC 10190005 and in part from St Mary's Upper Humboldt VBET for HUC 16040101

1. What parts of existing segmentation are working well?

In the 15 minute video below I pan around the VBET results and basically come to the conclusion that 90-95% of the network is working well. In the headwaters and more classic tributaries it is doing really well.

Some of the issues raised:

• We need to add attributes to the VBET output polygons that separate this into the perennial, intermittent, ephemeral and waterbody only valley bottoms.
• We will need to have a way to use that valley bottom type to query for display and summary metric purposes.

2. What parts of existing segmentation are falling apart?

In the video below we highlight the bigger valley bottoms where the segmentation falls apart.

For the most part, this is where:

• High order streams with lots of anabranches.
• Where we included too many or isolated water bodies (e.g. off-channel reservoirs).
• Where tributaries come in and get kicked downstream (parallel to trunk) for a while.
  Reassuringly, many of these are easy to fix with a more carefully curated channel area input. More over, some of the others are easy to fix in Riverscapes Studio.

3. What alternatives and ideas are there for improving the parts where we're struggling?

Idea'r 1 - Just allow in Riverscapes Studio (QRiS or Web) user to Clean Up

As long as we can calculate the metrics we want and re-derive centerlines, if the user can modify geometry by simply unioning adjoining valley bottom segments, we can save ourselves a ton of time and headaches. This is of course an order-of-operations and chain of custody housekeeping cluster... but that's what Riverscapes Studio is. All punted over to a myVBET project.

Idea'r 2 - Take advantage of what we know about Anabranches

Many of the places we struggle are places where we're dealing with anastomosing and braiding anabranches. It seems like we know this from NHD attributes (though maybe we're not preserving them through into RS-Context → Channel Area → VBET). What if we used this information and the identification of "lateral" to "lateral" intersections (as opposed to "upstream trib" to "lateral" intersections. Where such overlaps exist, union the geometries back together?

Idea'r 3 - Take advantage of Stream Order and Adjoin "lateral" or "parallel" segments

We do see that in general, the only problems are happening on higher stream order stuff. We can use our TransformZones feature class (just classified drainage wings) and the "Stream Order" attribute to identify the potential problem zones.

In the video below I speculate about using stream order to help us out.

4. What are our priorities for trying these ideas out?

@philipbaileynar, @MattReimer and @KellyMWhitehead that's in your court?

[philipbaileynar]

I am rapidly arriving at the following conclusions:

1. We abandon all attempts to run centerlines and do any kind of segmentation at the network scale. Watershed resolution VBET runs are nothing more than a course initial representation of the percentage of the landscape in the high level geomorphic units.
2. We focus all our efforts on Riverscapes Studio and sub-five-mile scale where the workflow would be:
   1. Zoom to your riverscape
   2. either draw your valley bottom polygons from scratch or start by importing from a watershed VBET run
   3. automated centerline delineation.
   4. user refines centerlines.
   5. automated segmentation.
   6. user refines segmentation.
   7. metrics.

[lauren-herbine]

After reading through @joewheaton 's post, I am inclined to agree with @philipbaileynar. As I understand it, we wouldn't change much by giving a network scale VBET output based on NHD flowlines vs. derived centerlines from the Channel Area tool. However I see what @joewheaton is saying about the anabranching problem- I saw that in the QC for the Upper Humboldt:

Would this not be an issue because we would skip using the Channel Area input if we go back to using NHD flowlines? In which case, would there be multiple channels that VBET would be built off of in an anastamosing area like this?

[lauren-herbine]

With further clarification:

I will need centerlines no matter what for metric calculations in river styling. What VBET or river styles are mapped onto at a ~HUC 8 scale doesn't matter much, which is what I thought we were talking about above (NHD vs. centerlines/polygons for a geometry to display our tool outputs), but I will need centerlines, so I don't think it makes sense to abandon them at the ChannelArea/VBET stages...
My 2 ¢

[lauren-herbine]

Hi @joewheaton and @philipbaileynar In this gist I lay out some of the thoughts we had about segmenting using NHD attributes, ecoregions, and level paths. @joewheaton do you want me to just copy it into this discussion? I will be updating with more examples on the process we laid out at the end.

[lauren-herbine]

@joewheaton bump

[lauren-herbine]

Segmentation

Some thoughts on a tiered process with some examples.

This would be using ChannelArea geometries as our main geometry, and then tying the valley bottom segment to it. This is because the ChannelArea polygons have NHD+ data tied to them. The main examples will be from the Alarka Creek- Little Tennessee basin in North Carolina.

Process

1. Break out any FlowArea FCODEs and make them their own segment

​ Areas

​ 53700, 46100, 48400, 31800, 34300, 34305, 34306, 4600, 46003, 46006, 46007

2. Break out any Waterbodies FCODEs and make them their own segment

• Waterbodies

49300, 3900, 39001, 39004, 39005, 39006, 39009, 39010, 39011, 39012, 43600, 43601, 43603, 43604, 43605, 43606, 43607, 43608, 43609, 43610, 43611, 43612, 43613, 43614, 43615, 43618, 43619, 43621, 43623, 43624, 43625, 43626, 46600, 46601, 46602

3. Segment out Perennial

46006

4. Intermittent

46003

5. Ephemeral

46007

These can be either Flowlines or Flowareas

6. Use LevelPath within VBET to segment

7. Segment at Level IV EcoRegion transitions

8. Tiered segmentation depending on drainage area/stream order for segments still longer than 5 km

• Still need to figure this one out

[lauren-herbine]

This is further discussed on the new discussion board #564