-
Notifications
You must be signed in to change notification settings - Fork 14
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
Deprecate 'guessing' functions for horizon-level column names #309
Conversation
- `guessHzAttrName()` is still available for users, but never called in aqp functions - Preferred method is to specify in function call or have users set metadata. - Require metadata via `required` argument to metadata get methods
…lumn metadata storage
- update examples and tests accordingly
Thanks. I did not mean to trigger an all at once change, but I do think that magical function action is best avoided. I'll think about how to best address |
IMO it is not that magical if we have exported, documented functions as default arguments to do the operation vs. having it buried inside a function, or having custom handling within the function like plotSPC() did. I agree there were a few variants of approaches, which was confusing and inconsistent. We still have some variation for functions that can take data.frame or SPC as input, but I think this PR is a step in the right direction for the future. It is better overall to guide the users towards using the metadata functions / setting the metadata, and ensuring that soilDB functions also set relevant metadata so most users don't have to worry about it. |
I would suggest merging this after CRAN release of 2.0.3 |
I think this is ready to merge |
Thanks for review, just synced with master branch, assuming everything passes (aside pending fixes from #317) will proceed with merge |
RE: #306 (comment)
This PR deprecates
guessHzDesgnName()
guessHzTexClName()
and removesguessHzAttrName()
from usage in aqp functions. I think the latter function is useful for certain applications if users "opt in" by using it in their own code but we can certainly avoid "internal" use of it.The mechanism to require metadata be set, and generic methods for getting/setting site or horizon level metadata have existed for some time (
aqp/R/SoilProfileCollection-metadata.R
Lines 3 to 59 in fcad3e8
To ease the handling of generic metadata column names,
hzmetaname()
andhzmetaname<-
have been added. It allows the specification/storage of standard, but custom, metadata that relates a name for horizon data of a particular type. This replaces the use ofguessHzAttrName(p, attr = 'clay', c("total", "_r"))
in argillic/PSCS function definitions.For example:
One area where guessing is still used is
guessGenHzLevels()
. I will not address that in this PR, but out of all of these functions this is actually the only one I am aware of having caused confusion. I have had folks ask me about why the levels returned bygeneralize.hz()
were ordered the way they were, and perhaps we should move this logic outside of the generalization function. Ordered factors make sense when the SPC is carefully curated, but can wind up being a bit illogical when there is, for example, a wide range of depth classes with different types of vertical subdivision present.