-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TADA_CreateParamRef() and TADA_CreateParamUseRef() #555
base: develop
Are you sure you want to change the base?
Conversation
First 2 reference files draft functions have been pushed through.
working on addressing some check issues that were found |
TADA_CreateParamRef and TADA_CreateParamUseRef .RD files
removal of some intermediate objects
Update - only print df if there are failing URLs
documentation suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments about requested changes are in-line or discussed in our working session call.
R/CriteriaInputs.R
Outdated
} | ||
|
||
if (sum(is.na(paramRef$EPA304A.PollutantName)) > 1 && org_names == "EPA304a") { | ||
print("NAs were found in EPA304A.PollutantName. Please ensure that you have inputted all field values of interest in the EPA304A.PollutantName column generated from TADA_CreateParamRef() function if you are interested in using the 304a recommended standards") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do users input this? Or is it done automatically? or a combination? Might be worth clarifying in the message and documentation that not all 304a pollutant names can be automatically crosswalked, so user review/input is required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good question. I had these lines included in past development to consider allowing users to also make edits to the EPA304a.PollutantName. But was unsure if we wanted to give this option to allow these values to be changed?
Making it clear that 'not all 304a pollutant names can be automatically crosswalked, so user review/input is required' will be nice to include if we want to proceed with allowing users to make further edits to the efforts we made with this crosswalk if an org feels one is more appropriate.
Added a tab for org_name filtered paramter and use names from ATTAINS Modified return values of ATTAINS.FlagParameterName
@cristinamullin @hillarymarler There are still some edits and formatting I would like to make, but I think this is in a good spot to review now. I will be out of the office tomorrow but will be back on Friday the 20th. |
…/USEPA/EPATADA into Create-Module-3-Reference-Tables
Commenting out test_that ph for now
Fixed minor bug in flagging ATTAINS.ParameterName
Intro updates
Should we be using the organization identifier ("code" in the rATTAINS domain_values for OrgName) as the input for selecting the org in functions? Some of the organization names are very long (particularly for tribes) and contain whitespaces or other potentially problematic characters, which can get tricky for manually entering strings that need to be machine readable. A few examples with name first, followed by code in parentheses: I had set up the ATTAINS related functions in https://github.com/USEPA/EPATADA/pull/562/files to work off organization identifier to avoid potential issues with long organization names. If we decide to keep mod 3 functions working off organization names rather than organization identifiers, should I edit PR#562 functions to match? |
mod 3 vignette updates
I am thinking organization identifier would be more appropriate to use. I kept it as organization names for the time being as that was what I used originally when creating the reference functions. rATTAINS and other functions seem to use organization identifiers, and it is probably best to switch these mod 3 functions over to organization identifier rather than the organization name. But if there are other thoughts on this, I would be interested before proceeding with this switch over @cristinamullin |
@wokenny13 @hillarymarler Yes, I agree it is best to use ATTAINS organization identifier ("code" in the rATTAINS domain_values for OrgName) for all relevant TADA functions. |
My review/suggested changes of the mod 3 vignette stop at the R code chunk before the "Three cases of TADA_CreateParamUseRef" |
Changed name to identifier where applicable. Updated some flagging functions Updates to vignette
Data_6Tribes_5y_Harmonized is showing TADA.ComparableDataIdentifier as PH_NA_NA_NA. Did we decide on if we wanted it all to be harmonized to PH_NA_NA_STD UNITS or PH_NA_NA_NA?
Update to .Rd documents Updates to global variables
Updated minor excel output bug, and updated documentation for greater clarity in Mod 3 functions.
First 2 reference files draft functions have been pushed through to test.
I am still working on the Mod 3 vignettes, however the R document contains a detailed explanation of what the two functions' goals are, and can be reviewed in the meantime while I continue to work on the Mod 3 vignettes.