[1pt] Update stage-based CatFIM to prevent overflooding if stage + elevation is provided in lieu of stage

[EmilyDeardorff]

There are some CatFIM sites where the stage values that are provided in the WRDS API actually have the water surface elevation (WSE) rather than the stage value. One site where this is true is site prdk2 in Paradise, KY. At this site, the action stage is listed as 378 ft, which has caused very intense over inundation (as showen in the "before" example below). This code update detects that this issue is occurring and subtracts the elevation from the incorrect "stage" value to produce the actual stage value. In the case of site prdk2, the listed "stage" value is 378 ft, so the gage elevation (363.19 ft) is subtracted to produce the much more reasonable stage value of 14.81 ft. This results in a much more reasonable stage-based CatFIM result, as shown in the "after" example below.

Addresses vlab ticket #141569.

Changes

• inundation-mapping/tools/catfim/generate_categorical_fim.py: Added an update to detect and fix cases where WSE is provided in lieu of stage. Added uncorrected_stage and is_interval columns to output CSV.
• inundation-mapping/tools/catfim/generate_categorical_fim_mapping.py: Added update to facilitate the new is_interval column.

Testing

Test HUC	Site	Site Info	Test Result
05110003	prdk2	Original site that was tagged in the VLAB ticket. Site in Kentucky where action stage>elevation because stage is incorrect.	Error was caught and mitigated!
05130101	pvlk2	Site in Kentucky where action stage>elevation because stage is incorrect.	Error was caught and mitigated!
01090004	crar1	Coastal Rhode Island site where action stage>elevation but the stage isn’t incorrect. (Action stage is 8ft, elevation is 7.1 ft.)	Site processing wasn’t changed because the stage is less than 250 ft (expected outcome).
18010105	scoc1	Coastal Northern California site where action stage>elevation but the stage probably isn’t incorrect. (Action stage is 45ft, elevation is 35.5 ft.)	Site processing wasn’t changed because the stage is less than 250 ft (expected outcome).

Deployment Plan (For developer use)

How does the changes affect the product?

• Code only?
• If applicable, has a deployment plan be created with the deployment person/team?
• Require new or adjusted data inputs? Does it have start, end and duration code (in UTC)?
• If new or updated data sets, has the FIM code been updated and tested with the new/adjusted data (subset is fine, but must be a subset of the new data)?
• Require new pre-clip set?
• Has new or updated python packages?

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
• 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
• 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

[RobHanna-NOAA]

We need a fix. In the library csv/gpkg, the stage column must show the value that was used for inundation. But.. the original code was updating the "stage" value directly from the thresholds list. With us adjusting some stage values, we need to find a way to make sure the stage column is corrected.

I found this with 05130101, pvlk2. Note: I also added a new column called "is_interval" (true/false), to help keep track of which is which. It is fine to leave it in. I have checked in this change and a few minor tidbits.

Not sure the right fix, and you will need to play with it, but maybe change:

for threshold in valid_stage_names:
....
'stage': thresholds[threshold],

to:
something that tied the stage_values_df['stage_value'] instead of the threshhold data? Something to play with.