[21pt] src/hydrotable_flood_extent_polygons.py: Generate flood extent polygo…

[hohe12ly]

Generate flood extent polygons for the synthetic river rating curve (hydroTable).

A python script is coded to implement a requested feature for generating flood extent polygon for each HydroID and each stage height in the hydroTable.csv. Instead of adding a WKT column to existing hydroTable, which would make hydroTable.csv big and less readable, the output is a GeoPackage file with attributes: HydroID, feature_id, stage, and stage_index (0-83). The usage of the script is documented in the python code.

Additions

src/hydrotable_flood_extent_polygons.py is added to implement this feature. It's a standalone python script and can be used as a bash command. Code is modularized into 3 python functions for further integration into FIM4 framework.

Testing

The performance of this script was tested on HUC8 12090205. Here is the overall performance in terms of computing time for each stage height. On average, each stage height takes about 1 minute to compute using 8 CPU cores.

The breakdowns of each component in the code is shown below. Note that polygonization is the most time-consuming step, consistently taking ~30 seconds:

[RobHanna-NOAA]

Hi folks. In consistency with our new FIM patterns for .py files, we are now slowly changing our files to move any logic from "main" into a new function that can serve as an entry point.

Why? If you run this command from command line, the logic in "main" will execute, but what happens if this get linked up with another .py file. That other .py file would not be calling "main" and will miss critical logic. I can change this for Dr. Liu before we approve it. As we attempt to move away from bash, this new code pattern will become critical. :)

[hohe12ly]

Hi folks. In consistency with our new FIM patterns for .py files, we are now slowly changing our files to move any logic from "main" into a new function that can serve as an entry point.

Why? If you run this command from command line, the logic in "main" will execute, but what happens if this get linked up with another .py file. That other .py file would not be calling "main" and will miss critical logic. I can change this for Dr. Liu before we approve it. As we attempt to move away from bash, this new code pattern will become critical. :)

Hi Rob,

Please feel free to refactor the code as you want to conform to the FIM patterns. The code has 3 functions and a main that can be easily wrapped into another function to stay away from being a standalone python application.

Thanks,
Yan

[RobHanna-NOAA]

Huge thanks Yan. We might just do that (TBD). Rob :)

…

On Wed, Jul 12, 2023 at 1:44 PM hohe12ly ***@***.***> wrote: Hi folks. In consistency with our new FIM patterns for .py files, we are now slowly changing our files to move any logic from "*main*" into a new function that can serve as an entry point. Why? If you run this command from command line, the logic in "main" will execute, but what happens if this get linked up with another .py file. That other .py file would not be calling "*main*" and will miss critical logic. I can change this for Dr. Liu before we approve it. As we attempt to move away from bash, this new code pattern will become critical. :) Hi Rob, Please feel free to refactor the code as you want to conform to the FIM patterns. The code has 3 functions and a *main* that can be easily wrapped into another function to stay away from being a standalone python application. Thanks, Yan — Reply to this email directly, view it on GitHub <#941 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVFLIVTV56VK6WLU4XFDJTXP35AZANCNFSM6AAAAAA2E352W4> . You are receiving this because you commented.Message ID: ***@***.***>

-- Rob Hanna ***@***.*** NOAA Affiliate, Lynker

[RyanSpies-NOAA]

See dev_hand_geocurve branch as an updated alternative for this PR.