[3pt] Investigate why stage-based CatFIM isn't mapping in Puerto Rico

[EmilyDeardorff]

Currently, stage-based CatFIM is not creating any mapped points in Puerto Rico. This might be an accurate response to the data quality, but it could also reflect an issue in how our data filtering processes data in Puerto Rico.

Look into the CatFIM acceptance criteria and check for any issues with how the Puerto Rico points are being filtered.

[EmilyDeardorff]

Summary of Stage-Based CatFIM Site Filtering in Puerto Rico

The acceptance criteria filters the sites based on site type, altitude data method, and altitude accuracy code. The site type code must be stream (code “ST”), the altitude data method code must be a highly accurate method (codes "A", "D", "F", "I", "J", "L", "N", "R", "W", "X", "Y", or "Z"), and the altitude data accuracy code must be below 1 or lower.

Acceptance Criteria Performance of Puerto Rico HUCs

• There are 8 stream sites in Puerto Rico in the HAND-FIM HUCs, none of which are eligibile for stage-based CatFIM based on their altitude data codes.
  • Of the stream sites, 2 sites have acceptable altitude data methods (altitude is from a DEM), 6 have an unacceptable altitude data method where the altitude is from a map or not listed (site RGMP4)
  • Of the 8 stream sites, all have unacceptable altitude accuracy codes (above 1) or unlisted (site RGMP4)

For further detail, please see the annotated filtering summary table attached below.

Summary, Future Steps

Based on this information, it seems like the stage-based CatFIM code is correctly filtering out all of the Puerto Rico sites. If we wanted to get more CatFIM sites in the future, we could possibly pull the gage elevations from our own DEMs rather than from the USGS site, which would potentially allow us to create stage-based CatFIM for up to 8 more sites in Puerto Rico.

filtering_summary_table_all_hucs_ANNOTATED.pdf

[EmilyDeardorff]

Analysis of Sites with Altitude Accuracy Values of 1.6 - Full CatFIM Domain

A few Puerto Rico sites evaluated above meet two of the three acceptance criteria but simply have a USGS data altitude accuracy value of 1.6, which is a little bit higher than the acceptance threshold of 1. This altitude accuracy code is derived from the input data. Since 1.6 ft is about half a meter, it is likely that this altitude accuracy code was used because the input DEM had a spatial resolution of 1 meter. In this case, it might actually make sense to accept sites that have an altitude accuracy code of up to 1.6, since a 1-meter DEM is likely an acceptable data source.

Sites that meet all three acceptance criteria are then processed for stage-based CatFIM (although many will still not have CatFIM produced due to other errors or filters). /data/previous_fim/fim_4_5_2_11/ has a total of 9,771 sites that meet all three acceptance criteria. Out of those potential sites, 6,381 sites have acceptable values for all three acceptance criteria. There are 86 sites that meet the other two criteria and would be added if we expanded the altitude error acceptance threshold from 1 to 1.6. These sites come from a total of 64 unique HUC8 catchments.

The following table delineates how many sites have each altitude accuracy code between the values of 1.1 and 2. As we can see, the majority of sites that have codes in this range have a code of 1.6, which likely means they are derived from meter-scale DEMs.

usgs_data_alt_accuracy_code	number of sites
1.2	2
1.3	0
1.4	1
1.5	1
1.6	82
1.7	1
1.8	1
1.9	0
2.0	21

[EmilyDeardorff]

Testing increasing acceptable_alt_acc_thresh from 1 to 1.6

I updated acceptable_alt_acc_thresh to be 1.6 in order to see if it would produce more stage-based CatFIM points. I tested the following 4 HUCs:

• 21010002 (1 potential site in PR: CORP4)
• 21010005 (1 potential site in PR: BCAP4)
• 14010001 (9 potential sites: MDWC2, TNSC2, TBRC2, CBLC2, LTCC2, HMTC2, TAIC2, TBLC2, INLC2)
• 18050004 (3 potential sites: AJBC1, BJBC1, ASLC1)

Note: Bolded sites are the only ones that showed up in the output csv, and no additional sites were mapped.

huc	site	status	status	notes
21010002	CORP4	not mapped	Large discrepancy in elevation estimates from gage and HAND
21010005	BCAP4	not mapped	Missing all threshold stage data
14010001	mbwc2	not mapped	Gage not in HAND usgs gage records	this is because the usgs gage file also uses acceptable_alt_acc_thresh so we’d have to re-run that to implement these changes

Based on this test, it doesn't seem like increasing the altitude threshold from 1 to 1.6 will add that many points. Importantly, it does not add the two stage-based sites in Puerto Rico that we were hoping it would add, which means it might not be worth implementing. However, if we're still interested in testing it, then we will need to re-run rating_curve_get_usgs_curves.py with the updated altitude acceptability threshold to get an updated USGS gages file.

[EmilyDeardorff]

Next Steps, Data Method Updates

Based on the above analysis, it seems like increasing the acceptable_alt_acc_thresh from 1 to 1.6 will not add any additional stage-based CatFIM sites in Puerto Rico. Due to that finding, we will not be implementing that change into CatFIM.

The other main reason that stage-based CatFIM sites in Puerto Rico are being thrown out is because their altitude data does not have the correct altitude data method. The altitude data must be collected from a highly accurate method (codes "A", "D", "F", "I", "J", "L", "N", "R", "W", "X", "Y", or "Z"). Updating the altitude data provided by the WRDS database to have altitude data from one of the approved methods would likely increase the number of stage-based CatFIM sites in Puerto Rico. This is work that is outside of the development scope of the FIM Dev Team but would be a welcome contribution.