search

Riverscapes / riverscapes-tools

Open-source Python 3.0 tools for the Riverscapes organization
https://tools.riverscapes.net/
GNU General Public License v3.0
10 stars 8 forks source link

Gradient and Sinuosity Calculations #225

Closed philipbaileynar closed 2 years ago

philipbaileynar commented 3 years ago

We need gradient and sinuosity calculations for reach typing.

The goal of this ticket is to produce standalone Python modules for calculating gradient and sinuosity. (Other calculations will follow soon...) Essentially this code takes a polyline feature class and adds the gradient and sinuosity attributes (dropping them first if they are already present) and populates them with the new values.

We already have gradient as part of the BRAT reach geometry module. So I recommend that this is simply moved up to rscommons and called from there. Then refactor to BRAT to call it from rscommons as well.

Sinuosity does not use an underlying raster, but it can essentially be written as a new standalone module that mimics some of the pattersn from the reach geometry code.

Important Notes

  1. How did GNAT calculate sinuosity and gradient in the past? Is it different?
  2. What scale does it make sense to calculate these attributes? We will get different values for very short reaches as opposed to longer lines.
  3. The gradient code linked above samples the elevations as the end of reach polylines. It does use a buffer (30m I think?) but it samples the raw DEM. USU in the past has used an averaging filter on the DEM first to avoid anomalous values.
  4. Sinuosity and gradient are the first of many calculations that we will need for reach typing. Keep in mind that we will be extending this code. Code these current features as standalone code but think about how we will combine methods into a coherent GNAT tool.
KellyMWhitehead commented 3 years ago

arcGNAT previously generated:

These tools can be run at any scale, but tend to work better for longer reaches (less 'noise' and fewer geometry special cases). We never quite figured out the idea segmentation to use during the arcGNAT era.

Shopping list for GNAT inputs (as we develop the GNAT rs project)

joewheaton commented 3 years ago

@lauren-herbine you should chime in on this one...

Gradient

We should differentiate

We should also look into what we did in BRAT a long time ago to smooth and get reasonable gradients. I vaguely recall:

Sinuosity

A few things: image For ideas on symbolization...

And, way back in 2016 Kirstie and I drew this on my whiteboard when we were trying to clarify these things. image

Primary Planform Measures

Out of it comes the idea that we need direct measures of:

A big challenge is whether we calculate channel distances as total of all anabranches in multithreaded system or mainstems?

Primary Sinuosity Metrics

To calculate primary sinuosity metrics:

Note similarity to @KellyMWhitehead :

  • Planform Sinuosity (Channel Segment length/distance of channel segment endpoints). This is easy and only needs the line network as an input.
  • Channel Sinuosity (Channel Segment length/ valley bottom Centerline length). We will need vb centerline and a method to spatially join the two (i.e. probably use vb sausages for this).
  • Valley Bottom Sinuosity (Valley Bottom Centerline Segment length/distance of Valley Bottom Centerline Segment endpoints)

Why do we need all this?

Well the various sinuosity measures are useful by themselves for discriminating different conditions. However, it is the intercomparing of some of these sinuosity values at the riverscape setting that helps us discriminate different settings really well.

For example:

philipbaileynar commented 3 years ago

What length scale are wee going to measure reach sinuosity? All rivers are straight if measured at some silly minute scale.

We are already segmenting NHD+ HR at 300m, land ownership, roads and rail. There's also talk of segmenting at ecoregions (#236 ).

The length over which we measure sinuosity affects the result. How do we pick the right length if our reaches are so fragmented that they are nearly all straight?

lauren-herbine commented 3 years ago

Sinuosity

Inputs:

From @joewheaton : Out of it comes the idea that we need direct measures of:

Metrics:

from @joewheaton Valley Sinuosity V CL/ VSL Valley Bottom Sinuosity - VB CL/ VB SL Planform Sinuosity - Ch CL/ Ch SL Channel Sinuosity - Ch CL/ VB CL Thalweg Sinuosity - Ch Th/ Ch CL

Scale

@philipbaileynar let's start segmenting at 500m. I think level IV ecoregions would be too long in some cases and could "pinch" a reach in others: image an example from CO

Multithreaded systems

... coming soon...

Gradient

Question for you all (@philipbaileynar @KellyMWhitehead @joewheaton)- the NHD+ has slope as an attribute. Could this be used? Ex from something I've already put together: image

lauren-herbine commented 3 years ago

an update for moving forward:

Let's calculate those things that are easy: (from @KellyMWhitehead)

For this first run I am interested in seeing how well channel sinuosity discriminates between river styles. This is what we were using in the MHFD, and for that "small" area it worked well. For multi-threaded systems, we will use the mainstem (if it is anastomosing/the NHD shows multiple channels). For braided systems, we will use the length of the channel belt. See figure below: image I am still thinking segmenting at 500 m will be a good place to start.

joewheaton commented 3 years ago

Slope

Please see how we calculate and display symbology for reach slope in BRAT. The slope in NHD+HR could be good, but it will be based on its segmentation, which may suffice.

We also need to think about valley bottom slope and this would be valley bottom centerline length divided by the difference in "nearest min elevation in a window (e.g. 10 x 10) at top and bottom.

Sinuosity Measures

I like what you have proposed for sinuosity measures. I would suggest NOT presupposing the sinuosity segmentation of channel netowork to 500 m to start. Start with existing NHD +HR segmentation and see how bad or different it is. I think for bigger rivers we may want to have longer segmentation. @KellyMWhitehead please lay out as you start doing this exactly what the choices are in making these calculations and or give us some different examples so we can make some informed decisions. The thing I don't think we're considering here yet is the discrepancy between NHD+HR channel segmentation (default) or our additional segmentaton, and our VBET cl segmentation. Any insights @KellyMWhitehead ?

Please also see @lauren-herbine what @kbartelt came up with in RIM for her Relative Flow Length metric, which was very good for multi-threaded systems (i.e. total channel(s) CL or thalweg length divided by riverscape length).

joewheaton commented 3 years ago

Thinking about @philipbaileynar :

@philipbaileynar let's start segmenting at 500m. I think level IV ecoregions would be too long in some cases and could "pinch" a reach in others:

and

The length over which we measure sinuosity affects the result. How do we pick the right length if our reaches are so fragmented that they are nearly all straight?

So another approach is with @KellyMWhitehead and Carol stole from the Fluvial Corridor Tool, in which some metrics can be calculated at length scales other than their segmentation with a moving window (also facilitates calculating at multiple scales). In other words, it doesn't matter what your segmentation length scale is, you choose a "metric length" calculation scale appropriate for the calculation (e.g. a fixed length window of VB for example). This is the approach laid out in Notebaert & Piegay (2013) of using DGOs and AGOs...

image