TADA Team Data Retrieval Updates

[hillarymarler]

https://github.com/USEPA/EPATADA/pull/566/files#top editable by TADA Team.

[hillarymarler]

Should this reference the internal shapefiles instead of relying on web services?

[cristinamullin]

I think that would be more efficient since we already store them within the package

[hillarymarler]

Is this something you want me to take a look at? Or plan to ask Ross lab about?

[cristinamullin]

@mbrousil We store copies of the tribal .shp files here for use in the TADA_OverviewMap, and update them frequently as part of routine maintenance: https://github.com/USEPA/EPATADA/tree/develop/inst/extdata

Do you think we should use those directly in TADA_DataRetreival instead of querying the service?

[mbrousil]

@cristinamullin Yep, I think that makes more sense! I only used the web service because I wasn't aware that they were stored internally.

[cristinamullin]

Thanks! I am aiming to merge this PR in by the end of the day tomorrow. I can create a separate issue for this update & we can address it later.

[cristinamullin]

I was curious how this would work for a sf lines object, and maybe I need to think through the logic more.

Continuing on with Hillary's code, once we run data retrieval to pull in all sites for the AU polygon with AU Name: REND, and we rerun TADA_GetATTAINS on this new dataframe. We find some sites get mapped to an AU line AU Name: Big Muddy River

If we were to try to now pull in all sites for AU line: Big Muddy River,

1. Should Data Retrieval be returning sites for a sf line? It returns

2. Will TADA_DataRetrieval only pull in sites found on the AU line if we use aoi_sf as an ATTAINS line? 3. Does the aoi_sf need to be a polygon?

Rend_TADA_ATTAINS <- TADA_GetATTAINS(Rend_TADA) TADA_ViewATTAINS(Rend_TADA_ATTAINS) Rend_AUID_line <- Rend_TADA_ATTAINS$ATTAINS_lines Rend_TADA_line <- TADA_DataRetrieval(aoi_sf = Rend_AUID_line, ask = "no")

@mbrousil My understanding is that this is designed to work on polygons only, is that correct? In that case, we can add that detail to the documentation for users. Although in theory, we could expand in the future using a similar logic to TADA_GetATTAINS() for lines, where the polygon area used for the "line" query could actually be the area of the catchments intersecting the line. I am not sure if there are a lot of use cases for this. Any thoughts?

[mbrousil]

I was curious how this would work for a sf lines object, and maybe I need to think through the logic more.
Continuing on with Hillary's code, once we run data retrieval to pull in all sites for the AU polygon with AU Name: REND, and we rerun TADA_GetATTAINS on this new dataframe. We find some sites get mapped to an AU line AU Name: Big Muddy River
If we were to try to now pull in all sites for AU line: Big Muddy River,

1. Should Data Retrieval be returning sites for a sf line? It returns

2. Will TADA_DataRetrieval only pull in sites found on the AU line if we use aoi_sf as an ATTAINS line? 3. Does the aoi_sf need to be a polygon? `Rend_TADA_ATTAINS <- TADA_GetATTAINS(Rend_TADA)` `TADA_ViewATTAINS(Rend_TADA_ATTAINS)` `Rend_AUID_line <- Rend_TADA_ATTAINS$ATTAINS_lines` `Rend_TADA_line <- TADA_DataRetrieval(aoi_sf = Rend_AUID_line, ask = "no")`

@mbrousil My understanding is that this is designed to work on polygons only, is that correct? In that case, we can add that detail to the documentation for users. Although in theory, we could expand in the future using a similar logic to TADA_GetATTAINS() for lines, where the polygon area used for the "line" query could actually be the area of the catchments intersecting the line. I am not sure if there are a lot of use cases for this. Any thoughts?

@cristinamullin That is correct! I don't personally have any insight into potential use cases but I don't see drawbacks to that expansion.

[cristinamullin]

After the new USGS dataRetrieval related issues are resolved, these edits will be pushed through from this branch/PR: #575