AEP FIM: RAS2FIM Bugs

[shawncrawley]

An issue was reported to us indicating that the RAS2FIM polygons were missing from the static_nwm_aep_inundation_extent_library_noaa service in UAT. While investigating, we confirmed the issue, but also uncovered a few other issues. Namely:

• All RAS2FIM features have "FIM 5.0.0" as their fim_version value, while HAND FIM has "4_5_2_11"
• There are duplicates of all RAS2FIM features. This is being caused by the SQL query that extracts the RAS2FIM for the AEP services. The query is joining the ras2fim.geocurves table to the derived.fim4_featureid_crosswalk, which is not necessary because that is a HAND crosswalk that maps the NWM hydrofabric with the HAND hydrofabric, but RAS2FIM is based on the NWM hydrofabric. The hydro_id, hydro_id_str, huc8, and branch columns are being pulled as metadata from that table as well, but all of those except huc8 are irrelevant for RAS2FIM as well. I believe huc8 can be pulled from the derived.channels_conus table instead.
• Finally, we have yet to fully pinpoint why the service is not actually drawing. However, the best guess is that the data types in the aepfim.rf*_inundation tables behind the service don't match the data types configured in the service's .mapx file.

Update: Sep 16, 2024

• It is ok if we leave HUC8 null for now so we don't have to reload the ras2fim data, but we will fix it in the dataload script later
• If we need to leave ras2fim off AEP for 2.1.8, that is ok
• We can continue (or confirm) that any ras2fim records that don't have points inside the curve can be dropped.

---

Safety test: To test, find a ras2fim feature ID, then filter a layer for that feature id. If it is a ras2fim record, you should only get either 0 or 1 feature returned. If 0, it was dropped for some reason, maybe flow ranges or something, but worth more researching. If more than 1, something is very wrong. ras2fim can only have one aep feature per aep stage. But HAND will have 1 to many as it has multiple hydroid (features) crosswalked to one feature ID.

[shawncrawley]

We actually found that the issue with RAS2FIM not drawing was actually stemming from the polygons being ingested into the ras2fim.geocurves table with the wrong projection. So technically RAS2FIM is drawing, just in the completely wrong place: in the sea far north of Russia. We have corrected the projection bug in our ingest scripts and are re-running those now.

[RobHanna-NOAA]

The ras2fim data load was incorrectly applying the wrong crs. I thought incoming it was 5070 but it is really 2277. Now that we changed the incoming ras2fim csv's to 2277 and reprojected it in the data load scripts to 3857, we should be good. We did a quick test after loading one ras2fim csv and it was good now. Re-running the full ras2fim as we speak.

[RobHanna-NOAA]

Fixed the crs problem. Re-ran the ras2fim data, checked just that data in arc and the mapviewer (??). Now re-running AEP and hopefully we are all good.

[RobHanna-NOAA]

All fixed now for the ras2fim.geocurves and mas_geocurves.