Skip to content
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

Open
wants to merge 89 commits into
base: develop
Choose a base branch
from

Conversation

wokenny13
Copy link
Collaborator

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.
 

  • Check to see if using argument input, excel = TRUE, creates the myfileRef spreadsheet in your downloads folder path.
  • Test out different argument inputs and test on other datasets.
  • Test out any warning/error messages from running the functions due to any invalid inputs to ensure no additional bugs.
  • Test out the general usability and user interface of the 2 functions.

First 2 reference files draft functions have been pushed through.
@wokenny13
Copy link
Collaborator Author

working on addressing some check issues that were found

Copy link
Collaborator

@hillarymarler hillarymarler left a 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 Show resolved Hide resolved
R/CriteriaInputs.R Outdated Show resolved Hide resolved
R/CriteriaInputs.R Outdated Show resolved Hide resolved
R/CriteriaInputs.R Outdated Show resolved Hide resolved
R/CriteriaInputs.R Outdated Show resolved Hide resolved
R/CriteriaInputs.R Show resolved Hide resolved
R/CriteriaInputs.R Outdated Show resolved Hide resolved
R/CriteriaInputs.R Outdated Show resolved Hide resolved
R/CriteriaInputs.R Show resolved Hide resolved
}

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")
Copy link
Collaborator

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.

Copy link
Collaborator Author

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
@wokenny13
Copy link
Collaborator Author

@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.

R/TADARefTables.R Outdated Show resolved Hide resolved
R/TADARefTables.R Outdated Show resolved Hide resolved
R/TADARefTables.R Outdated Show resolved Hide resolved
@hillarymarler
Copy link
Collaborator

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:
"Lac du Flambeau Band of Lake Superior Chippewa Indians of the Lac du Flambeau Reservation of Wisconsin" (LFWATER2007)
"Minnesota Chippewa Tribe, Minnesota (Grand Portage Band)" (GPORTAGE)
 "Assiniboine and Sioux Tribes of the Fort Peck Indian Reservation, Montana" (FORTPECK)

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
@wokenny13
Copy link
Collaborator Author

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: "Lac du Flambeau Band of Lake Superior Chippewa Indians of the Lac du Flambeau Reservation of Wisconsin" (LFWATER2007) "Minnesota Chippewa Tribe, Minnesota (Grand Portage Band)" (GPORTAGE)  "Assiniboine and Sioux Tribes of the Fort Peck Indian Reservation, Montana" (FORTPECK)

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?

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

@cristinamullin
Copy link
Collaborator

organization identifier ("code" in the rATTAINS domain_values for OrgName)

@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.

@hillarymarler
Copy link
Collaborator

My review/suggested changes of the mod 3 vignette stop at the R code chunk before the "Three cases of TADA_CreateParamUseRef"

cristinamullin and others added 17 commits January 22, 2025 12:27
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants