In getTogetherCovarData(), we need to find the site (parent) associated with all the subSites we are working on. That is, we have specific subSites in obs.eff.df that we are working on (see attr(obs.eff.df, "catch.subsites")). The EnvCovDB database just has Sites because we assume a single gage upstream of all subSites collects valid information for all subSites. Hence, we need to lookup the Site(s) associated with the subSites we are working on so we can query the API.
The way Jason set this up was expedient buy not the best. The subSite to Site map we are currently (campR v2.0.i14) handle this is to read a CSV stored over in the EnvCovDBpostgres package. We want to store the association between subSite and site in the postgreSQL database itself and retrieve it from the API. Better yet, store the association between site and subSite in the database then modify the API to accept subSiteID (rather than siteID). That is, the API does the cross walk between subSite and site and returns the correct data.
In
getTogetherCovarData(), we need to find the site (parent) associated with all the subSites we are working on. That is, we have specific subSites inobs.eff.dfthat we are working on (seeattr(obs.eff.df, "catch.subsites")). The EnvCovDB database just has Sites because we assume a single gage upstream of all subSites collects valid information for all subSites. Hence, we need to lookup the Site(s) associated with the subSites we are working on so we can query the API.The way Jason set this up was expedient buy not the best. The subSite to Site map we are currently (campR v2.0.i14) handle this is to read a CSV stored over in the EnvCovDBpostgres package. We want to store the association between subSite and site in the postgreSQL database itself and retrieve it from the API. Better yet, store the association between site and subSite in the database then modify the API to accept subSiteID (rather than siteID). That is, the API does the cross walk between subSite and site and returns the correct data.