TADA_GetATTAINS index usability

[cristinamullin]

Is your feature request related to a problem? Please describe:

TADA_GetATTAINS may cause the dataframe to grow (contain more rows than the original TADA dataframe) because Water Quality Portal observations can fall within an NHD catchment that contains more than one ATTAINS assessment unit. The new, “index”, column links these duplicate observations for sites that fall within more than one AU. This is important. Should we print a message for users when this occurs? I can foresee users running into subsequent analysis issues if they are not aware (don’t really read the documentation). Also, is the column name, “index”, too vague? Any ideas on how to make this more user friendly? How about TADA.SameResultMultipleAUs ? Currently, it is placed in at the start of the df, is that where we want it to go?

Describe the solution you'd like:

Update "index" column to something more user friendly. Also, considering printing a messaging for users when this occurs (observations are duplicated).

Describe alternatives you've considered:

Open to other ideas!

Additional context:

Some assessment topics that @wokenny13 and @cristinamullin discussed to think through:

• If impairment decisions with assessments are always done on an AU level, where it always including an AUID column, then it may not cause issues.
• If done on just a monitoring site level, that then gets rolled up to an AU, these duplicate observations may then be counted more than once by accident. In TADA, we can address this but if users perform the next steps of the assessment outside of TADA it may be problematic.
• I want to give users some flexibility on how to summarize any impairment for a parameter & designated use combination, while also handling of "site-specific" cases that may contain more than 1 monitoring location, etc. The current view that I have for this summary (based only on discrete, individual observations, can be seen below. Once a user defines the standards value for a parameter and designated use, we count the number of monitoring location sites found in the user's TADA dataframe pull, along with discrete counts of observation (each row with ResultMeasureValue), and the number of those discrete observations that have exceeded that standard value. Any thoughts on this current 'standards exceedance' summary layout? (There are other columns that are not shown in this view)
• Flagging these instances in which they occur should be addressed. The column name "Index" does seem too vague and a name change for this would make it more user friendly in my view.

[cristinamullin]

@kathryn-willi I merged in your last PR. The edits discussed here (#536) can be included in the next PR. Thank you for all your hard work!

[cristinamullin]

Note from R8 team: One concern we ran into when applying monitoring locations to AU shapefiles is (a) making sure the monitoring location is assigned to the correct AU type (lake vs. stream), and (b) how to apply a distance-based join in areas where distinctions between tributaries is important.

Let's review how our well (or not) process handles tributaries and water types. For TADA, we may need to think more about this if we choose to apply a distance-based logic for assigning WQP sites to the correct AU in cases where there are overlapping catchments that represent the AUs (and they would otherwise we counted for both).

[cristinamullin]

Let's explore options (USGS nhdplusTools https://doi-usgs.github.io/nhdplusTools/index.html and/or EPA WATERS services:https://watersgeo.epa.gov/openapi/waters/ ) to help review these matches & add more sophisticated logic (e.g., maybe flow/rain drop logic) for areas where multiple assessment units overlap the same high-res catchment (for example at tributaries). Ideally, each site could be matched with a single assessment unit and not multiple. I’d like to explore if this can be accomplished through use of geospatial tools.

Note: I think a simple matching of metadata between the ATTAINS AUs and WQP monitoring locations would help too (e.g. monitoring location names and types should also match – but that would likely require additional manual review especially for the names).