2  Concepts

This chapter provides an overview of some of the workflows that can be used to perform a rapid watershed assessment using FluvialGeomorph. Through analyzing a wide range of study areas, we have created a standard analysis framework. This framework defines a series of standard analysis objects that are used in a regular process to perform different types of analysis.

Units of Analysis

To help organize the workflow process we have defined several units of analysis:

  • Study Area: These are the primary work units and correspond to projects that customers have requested for analysis. Customers define specific goals for each project that determine the specific workflow chosen. These goals define a project study area for each project. These project study areas typically consist of a particular watershed, a mainstem section of a named river, or a discrete stream reach.

  • Site: Study areas are subdivided into “sites”. Sites are typically named tributaries and their subwatersheds within the project study area.

  • Reach: Sites are further subdivided into “reaches”. Reaches are defined according to project goals and use conventional rules for specifying reaches (i.e., tributary confluence to confluence), significant infrastructure, changes in surficial geology, etc.

  • Survey Event: Since FluvialGeomorph analysis is based on LiDAR terrain surveys, the timing of the survey is a critical factor in the analysis. LiDAR is a single point-in-time dataset. Since LiDAR can be collected periodically, our data structure must accommodate multiple distinct time periods (typically separated by years) for which channel dimensions are extracted. If there are multiple LiDAR surveys available for the project study area, the most recent survey is referred to as the base year.

Analysis Levels

We have defined a standard workflow that is modular, allowing analysts to prescribe and customers to purchase progressively more detailed analysis as needed. The workflow is organized according to the following levels:

  • Level 1: Extract basic channel dimensions and profile.
  • Level 2: Extract bankfull channel dimensions and profile.
  • Level 3: Extract planform dimensions.

Workflows

The FluvialGeomorph workflow has been organized using the following hierarchical grouping to help analysts better understand how to perform the analysis and what is being done during each step of the process. All workflow steps are sequential and build on the outputs of previous steps.

  • Levels: The top hierarchical grouping of the workflow. Levels are distinguished by the degree of fluvial geometric detail and metrics that will be derived. Levels 2 and 3 are optional.

  • Phases: The second hierarchical grouping of the workflow. Each level is subdivided into phases. Phases are mostly a conceptual grouping of steps to accomplish a specific objective in the analysis chain.

  • Steps: The third hierarchical grouping of the workflow. Phases are subdivided into steps. Steps typically involve running tools, manual editing, and performing quality assurance checks.

  • Tools: Tools are the lowest hierarchical grouping of the workflow. Tools perform operations that are suitable for automation.

Project Folder Structure

Establishing a standard storage structure for all project data is an important quality control step. A standard folder structure has the following benefits:

  • Clearly defined functional roles for each storage location reduces ambiguity and confusion.
  • Predictability reduces errors.
  • Standard structure allows analysts to move between projects more easily.

The following folder structure is recommended to organize all project data:

Study_Area_Name
└─── Sites
│    └─── 01_Site_Name
│    │    └─── Data
│    │    │        Site1_year1.gdb
│    │    │        Site1_year2.gdb
│    │    │        Reach1_year1.gdb
│    │    │        Reach1_year2.gdb
│    │    │        Reach2_year1.gdb
│    │    │        Reach2_year2.gdb
│    │    │        ...
│    │    └─── Exports
│    │    └─── Maps
│    │    └─── Reports
│    └─── 02_Site_Name
│         ...
└─── Elevation
│    └─── ProjectName_Year1
│    │    └─── LAS
│    └─── ProjectName_Year2
│         └─── LAS
│         ...
└─── Exports
└─── Maps
  • Study Area Folder: The study area folder is used to store all of the files for the study area.
  • Site Folders: Site folders are used to store all of the files for each site. Each site in the study area gets its own folder. Site folder order can be controlled by prefixing a number to each site name.
  • Elevation Folders: The elevation folders are used to store all of the data required to create a DEM for each LiDAR survey event. A LAS subfolder at the project level is used to hold all of the point cloud data (typically delivered in .las format for modern surveys) for each LiDAR survey for the study area. Since these datasets can be massive, the idea is to separate these data into their own folder to streamline data management. Once the terrain data are processed at the project study area level, only derived DEMs are then copied to the site and reach geodatabases in the site data folders.
  • Site Data Folders: The site data folders are used to store all of the site site and reach geodatabases.
  • Reports: The Reports folders are used to store the reports created by tools for each reach.
  • Maps: The Maps folders are used to store map documents for a given study area or site.
  • Exports Folders: The Exports folders are used to store static .pdf map documents exported from map projects for a given study area or site.

Geodatabases

The FluvialGeomorph workflow was designed around a standard set of objects organized into a standard set of geodatabases.

  • Site Geodatabase: This type of geodatabase stores FCs that apply to a specific site. Datasets developed for the entire study area are clipped to the specific “site” unit of analysis and stored in the site geodatabase. If there are multiple LiDAR surveys for the project study area, a separate site geodatabase representing each survey is created beginning with the base year.

  • Reach Geodatabase: This type of geodatabase stores FCs that apply to a specific reach. The FluvialGeomorph tools create a standard set of FCs. Creating a separate geodatabase for each reach allows these standard FCs to be created for each “reach” unit of analysis. If there are multiple LiDAR surveys for the project study area, a separate reach geodatabase representing each survey is created beginning with the base year.

FluvialGeomorph Toolbox

Fluvialgeomorp toolbox creates a method for analyzing streams using Lidar Survey data, remote sensing practices to extract fluvial features. This toolbox has seven toolsets that structure the tasks of deriving features for analysis and reporting rapid watershed assessment.

  • Install: This toolset contains the install for the R package need in ArcGIS Pro, sessions and testing for the R code used in the toolbox.

  • Tools: This toolset contations all the feature extraction tools needed for the rapid assessment process.

  • Data Management: This toolset contains a tool to joins tabular data to spatial datasets.

  • Reports: This toolset contains all reporting options from the analysis and externatl data sources.

  • Symbology: This toolset contains the default symbology for the feature extracted from each tool that creates an output.

  • Check: This toolset contains tools to run checks on some of the outputs from the feature extraction tools.

  • Export: This toolset contains a tool to export the attribute tables from the level 1 feature classes.

Derived Features

The definition of a common set of derived features is an important step in standardizing any workflow. The standard FluvialGeomorph database objects form a tightly linked set of features that work together in a particular order to accomplish the analysis. See the FluvialGeomorph Tech Manual for a detailed description of each of these standard FCs.

Reports

FluvialGeomorph produces a series of reports that help to define stream conditions. Each report is created by the R Markdown parameterized report in the R package.

  • Level 1 Report: This report contains a set of maps and graphs that describe the channel as measured from the LiDAR derived DEM.

  • Estimate Bankfull Report: This report contains assists to estimate the bankfull water surface elevation for an ungaged stream with the assistance of regional curves and visual observation of geomorphic indicators from LiDAR surveys.

  • Level 2 Report: This report contains a set of maps and graphs that describe the Level 2 channel dimensions calculated at the specified bankfull elevation.

  • Level 3 Report: This report contains a set of maps and graphs that describe the Level 3 channel dimensions calculated at the specified bankfull elevation.

Quality Assurance

This workflow contains a LOT of detailed steps! If everything isn’t done just right, problems happen. So to help analysts stay on top of all of these details, we have adopted a layered approach to making sure everything gets done right. Here are the ways

  • Task Tracking Spreadsheet: To guide analysts through this workflow, we have developed a task tracking spreadsheet to use to record progress through the analysis. This spreadsheet allows an analyst to record the completion of each of the steps outlined above, as well as key values used in the analysis. This spreadsheet can be stored in the site folder while data development progresses. Records in this spreadsheet can be periodically appended to a project or team level version to improve team communication on project progress.

  • Check Tools: The FluvialGeomorph toolbox contains the Check toolset that allows the analyst to perform checks on the standard FluvialGeomorph FCs for basic rule compliance. If analysts have questions about if a specific FC is causing problems, these check tools can be used.

  • Tool Error Messages: A series of low-level defensive programming checks have been implemented across all FluvialGeomorph functions and tools to help head-off problems.

  • QA Checklist: The QA Checklist helps analysts review the reports created using the tools to identify and fix problems in the underlying derived data. See the QA Checklist chapter in this manual for details.