Riverscapes Metric Engine - Sample Grain

[joewheaton]

From Scott Miller

@joewheaton or @AldenShallcross - can one of you tell me the grain of the sample unit used for metric engine (e.g., NHD segment, arbitrary 200 m)?

And, was any thought given to linking these sample units to other products such as EPA’s StreamCat to allow data integration and aggregation among disparate data sets?

-Scott

[joewheaton]

Hi Scott,
These are great questions. So great, I am posting them here until we get our documentation to point where it can answer it (others have similar questions). I need to put together a few figures for the Framework and VBET documentation to explain this better.

tell me the grain of the sample unit used for metric engine (e.g., NHD segment, arbitrary 200 m)?

So you have a quick answer - it depends. To be clear, it depends on the metric. We have both channel network metrics and riverscape network metrics. The "grain" is:

• the polyline segment for channel network metrics
• the DGO for DGO riverscape network metrics
• the IGO for most riverscape network metrics in Riverscapes metric engine.

I will try to explain semi-briefly... 

We have now this idea of "Hybrid Models", that are both channel network models and riverscape network models. 

The channel network models are what you are used to (e.g. BRAT). By default, we ingest NHD+HR into riverscape context, and so one flavor of metrics just uses, as you suggest, the NHD segmentation (pretty much splits at junctions (confluences, influences, etc). For BRAT, we further segment that network at 250 m and then at all road crossings and major ownership boundaries (e.g. BLM boundary), and for RCAT, I think we segment it at 300 m. Thus, the channel network metrics in those models, many of which we pass over into Riverscape Metric Engine, are simply calculated for those segments from one or more attributes tied to that segment. 

Okay, breath. Now it gets complicated.

We also have riverscape network metrics. This is actually why we are a year behind on releasing freaking VBET, but it is cracked now and it is really powerful. Probably the most commonly used class of riverscape network metrics will be the IGO (integrated geographic objects), which are moving window metrics. These metrics are easiest to just show you in a video (until I get some nicer figures made). To understand them, you also need to understand the sample frame building blocks they are based on, which are DGOs (discrete geographic objects).  A DGO is a sample frame that we derive now for VBET. The DGOs have lateral extents of the valley bottom margins, and extend upstream and downstream based on a segmentation of the valley bottom centerline. In the example below, you see a valley bottom liklihood raster, and the DGO sample frames on top of it. It is hard to see, but the tributaries have much smaller segmentation, then this larger river.

Figure adapted from @lauren-herbine Confinement Vignette

IGO metrics are then calculated as a moving window of DGOs centered on the IGO point. For example, above IGO metric will be based on sampling the DGO it is in  as well as 2 upstream and 2 downstream. The advantage of this approach is for each metric, you can choose an appropriate length scale to look integrate across, but maintain high spatial resolution in looking, for example, at downstream trends on a longitudinal profile. If you think about a simple sinuosity calculation, in the example above, if sinuosity was calculated as length of mainstem channel divided by valley bottom centerline length, almost every DGO would show a really low sinuosity (near 1). However, if we calculated an IGO sinuosity based on the say an 9xDGO sample, it would be the sum of all 9 mainstem channel lengths divided by sum of all valley bottom centerline lengths (i.e. 2700 m in this example), and might give a more appropriate indication of sinuosity. 
Anyway, I know that is convoluted, but it is extremely powerful.

And, was any thought given to linking these sample units to other products such as EPA’s StreamCat to allow data integration and aggregation among disparate data sets?

Yes. The whole reason we developed this DGO/IGO sampling frame approach was to allow easy sampling of other's datasets. In short, each DGO becomes an AOI (area of interest) to then sample using their API. We should include StreamCat in what we explore for Riverscapes Data Exchange integration with this year. We can either

• potentially use Riverscape Studio to add commands that take sample frames (e.g. DGOs) in QRiS and ping reliable APIs of something like StreamCat, Climate Engine, PRoSPER or RAP and get back values in those grains.
• or we make riverscape projects (regional or national) of their datasets and then run a version of RME (metric engine) to harvest off of those projects so you have values across a riverscape network
• or we add functionality to RME to sample directly using the APIs at run-time (requires their APIs to be performant and reliable...)

Anyhow plenty to digest.

[AldenShallcross]

Love it! In addition to finally providing the type and scale of information we need to understand riverscape health and restoration opportunities at planning, project, and other spatial scales with data & models we've been using, it will provide the capability and flexibility we need to finally integrate other data/tools from complimentary projects. An anticipated "side effect" will likely be "acceptance" and use by others with their own favorite data and metrics, as they can still customize the output to include whatever values are important to them/their AOI. Powerful and efficient! So many opportunities.