[1pt] PR: Catchment Boundary Tool Addition

[RileyMcDermott-NOAA]

This PR adds scripts that can identify areas within produced inundation rasters where glasswalling of inundation occurs due to catchment boundaries, know as catchment boundary issues.

Addresses #1063.

Additions

• tools/identify_catchment_boundary.py: Identifies where catchment boundaries are glasswalling inundation extent.

• tools/inundate_catchment_boundary.py: Produces inundation for given HUC and identifies catchment boundary issues in produced FIM.

Testing

• Tested successfully on HUC 17110009 and 17110010.

Screenshots

Examples of HUC 17110010 from #1063:

Issuer Checklist (For developer use)

You may update this checklist before and/or after creating the PR. If you're unsure about any of them, please ask, we're here to help! These items are what we are going to look for before merging your code.

• Informative and human-readable title, using the format: [_pt] PR: <description>
• Links are provided if this PR resolves an issue, or depends on another other PR
• If submitting a PR to the dev branch (the default branch), you have a descriptive Feature Branch name using the format: dev-<description-of-change> (e.g. dev-revise-levee-masking)
• Changes are limited to a single goal (no scope creep)
• The feature branch you're submitting as a PR is up to date (merged) with the latest dev branch
• pre-commit hooks were run locally
• Any change in functionality is tested
• Passes all unit tests locally (inside interactive Docker container, at /foss_fim/, run: pytest unit_tests/)
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• CHANGELOG updated with template version number, e.g. 4.x.x.x
• Reviewers requested
• Add yourself as an assignee in the PR as well as the FIM Technical Lead

Merge Checklist (For Technical Lead use only)

• Update CHANGELOG with latest version number and merge date
• Update the Citation.cff file to reflect the latest version number in the CHANGELOG
• If applicable, update README with major alterations

[RyanSpies-NOAA]

I briefly tested the code tools/inundate_catchment_boundary.py for huc 12090301 using the 50yr AEP flow file. The process took 6.69 minutes using 7 cores on my ec2 machine. The boundary_output.gpkg is correctly identifying all instances with coincident boundaries between the inundation extent and any of the catchment boundaries.

Some future consideration notes:
It may make sense to set a length threshold on the boundary output segments to help weed out "benign" boundaries. I've noted numerous instances with very small (<100m) boundary segments. Many of these small boundary segments appear to be an "artifact" of having slightly different inundation extents along the branch 0 catchment boundaries (this is more of a WSE smoothing issue rather than catchment boundary).

It would also be nice to have an attribute stored with the boundary lines that identified whether a segment applies to branch 0, the GMS branch, or both. In my opinion, the most egregious and impactful glass walling issues often coincide with locations where both branch 0 and the GMS branch share a catchment boundary so it would be awesome if we could filter to just view those cases.

Looks like the boundary line segments are spliced according to the 10m pixel boundaries - 12090301 currently shows 36k+ line segments in the boundary gpkg. I suggest joining the connected lines together in grouped segments to make the lines more manageable if we anticipate exposing any metadata with the lines.

[ZahraGhahremani]

I tested the tools/inundate_catchment_boundary.py script for several HUCs (02030105, 21010005, 15020001, and 01060001). Each run took approximately 2 to 3 minutes, and the results successfully identified the intersection between the raster extent and the catchment boundary.
However, I suggest adding an attribute to the boundary lines to indicate whether a segment applies to branch 0, the GMS branch, or both (As Ryan mentioned too). This would help prevent confusion at first glance. For example, in HUC 02030105, there is a boundary line in branch 0 even though there is no intersection between the raster and the catchment. This initially seems confusing but makes sense when examining other branch boundaries.

Example of HUC 02030105, branch 0:

Example of HUC 02030105, branch 6264000012:

[RobHanna-NOAA]

still being worked on

[RobHanna-NOAA]

Still wip

[RileyMcDermott-NOAA]

Updated code to link catchment boundary lines correct HydroID:

• Error lines labeled with HydroID
• Catchment polygons labeled with HydroID

Updated code to identify which branch is causing the error:

• Error lines labeled with branch number
• Catchment polygons from branch 0 labeled with HydroID
• Overlapping error (same error area from multiple branches) creates one error line for each branch, shown in the overlapping yellow and purple lines.

Additionally filtered out all error lines less than 100m.