-
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
mollic thickness requirement, mollic epipedon, and more #132
Comments
I was curious about answering the question “How often is Mollic criterion 6c used to determine the minimum thickness requirement?” so I wrote up a basic calculation that applies the thickness criteria. I have ran EDIT: significant updates to functions that estimate soil diagnostic feature boundaries have rendered the values previously reported here obsolete. I previously reported that 70% of pedons would see an increase in minimum thickness requirement (under proposed 25cm criterion), when in fact it is only approximately 50% (6d+6c v.s. 6a)
|
I'm not sure if this is the correct place to post, but I'm very interested in translating different soil properties maps created from spatial prediction methods back into something interpretable, i.e., taxonomic classification. So that requires classifying depths and thicknesses of different diagnostic horizons. The example property I'm working with is the depth of mollic colors, or a quasi proxy for mollic epipedon thickness. I've found it challenging to use horizon names for criteria, because naming is very biased, but color is a bit more quantitative (hopefully more reliable). I was trying to create a function that could get the depth of contiguous horizons with mollic colors, as to avoid buried A's being included in the calculation. I see that Here's the data:
Long story short, it would be helpful to alter the code to account for max depth of exploration. It would also be great to make a 'getDepthtoFeature' where you could find the top depth of a reduced matrix, for example. Obviously, I'm crudely altering the code to fit my applications. I looked at the source code for 'getSurfaceHorizonDepth' but I had no clue what I was looking at 😆 |
I now see that my |
@MollicMeyer thanks for asking, this is approximately the right place. A lot to unpack here, and as a side-note, makes me think we need better documentation. |
Hey @MollicMeyer |
Thanks for reporting this. Very clever and good for you for trawling through the docs that we do have; it should have worked! Turns out in that uncommented, impenetrable code of This was never my intention. The test cases I used for this function are simply not robust enough -- as they are relatively simple cases all with traditional horizon designation field. So, thanks for some new tests :) I fixed the code -- get it with As far as use of estimateSoilDepth related functions -- as you found out that will do what you want either based on g suffix or a calculated field like you did here. You can also check out the new depthOf/maxDepthOf/minDepthOf in the mollic branch -- they have similar arguments as estimateSoilDepth but are a bit more flexible for criteria that may occur many times within a single profile. |
A couple of tips: Don't access SPC slots directly: you can create/edit/remove site or horizon level attributes with the
|
@MollicMeyer With latest version of mollic branch, the following code works as expected
|
Thank you both so much! I've been running into a lot of issues getting this training data ready for spatial prediction. NRCS RFOs are due June 11, so i'm only slightly panicking 😅 . Is there a proper forum to post in should I run into more issues along the way? (for example, filtering and/or converting horizon designations from older taxonomy editions) @brownag I will try this updated code out and get back to you. Once again, greatly appreciated! and @dylanbeaudette thanks for the tips as well! |
The GitHub issue pages are as close as you will get to a "forum" for these aqp R package related topics for now I would say that items related to the NASIS/SSURGO/LIMS data model specifically might be best discussed over on the https://github.com/ncss-tech/soilDB/issues/ page. If it pertains to these fundamental pattern-matching type functions in aqp, then this is the right place. Your finding of unexpected/undesired behavior with You could post even if there wasn't an existing issue related to your topic. This issue is opened for discussion around the mollic branch, as I implement a variety of new stuff that will be fully refined soon for a CRAN release. It will be closed when the mollic branch gets integrated into master. We are excited to have people applying these tools. As they get used outside their original scope, things will come up. It is fine to create "Issues" even if they don't turn out to be a bug -- there are enhancement, help wanted labels etc. None of us work on these packages as our primary duty, but generally will help if/when we can! |
…hes below a non-match are ignored (#132)
@brownag side note for the |
Yes sorry I glossed over that in my example. I filled in any NAs with "light" -- I'll see what I can do to make behavior a bit more stable |
@MollicMeyer I wanted to verify that this function was working as I intended -- it seems like it does. You can make different color criteria optional in
|
Yep. Check this out if you append to the previous script using my data.
|
Ok, so here is what I get: Pedon 1: bracket seems to be in right place I see what the problem is though -- look at the data in the second profile (1092093) It has a neutral (N) hue and NA for chroma -- so it is right to return NA, since chroma is NA. To work around that, you could try something like this: EDIT: complete example, fix axis
Which yields this lovely specimen: |
This is gooooood. I totally blanked on the Neutral hue being a potential troublemaker! I will work on this tomorrow. Regex expressions are also troublesome lately. I wanted to filter the E horizons out of my column indicating a reduced matrix, but keep those that included Eg. That involved.... Idx <- grep(“e[^g]”, hzs(spc)$hzname) Which worked... (kind of), but I later found out that plain “E” was not filtered with this expression. Only “E1, E2, EBt... etc.,). Any idea why that may be? Sorry about format, I’m on mobile currently. |
Add a
EDIT: formatting. Also, this makes me think I should clean up those examples in |
Significant updates to functions that estimate soil diagnostic feature boundaries have rendered the values previously reported here obsolete. I previously reported that 70% of R02 pedons would see an increase in minimum thickness requirement (under proposed 25cm criterion), when in fact it is only approximately 50% (6d+6c v.s. 6a)
I had originally expected that the sliding scale would be invoked a lot. I was surprised originally at how few diagnostic features were being detected. The 6c (untruncated) usage is even higher still. 65% (two-thirds) of pedons use the sliding scale: ~20% (absolute) of which are truncated to 18cm and ~35% of which are truncated to 25cm.
|
Quick demo graphic for Curtis Monger -- didnt have anywhere else to put this for now.
|
See branch aqp/mollic
Here is a demonstration of the new functionality I am working on for evaluating taxonomic criteria with aqp.
mollic.thickness.requirement
calculates the minimum thickness of the materials meeting other requirements for a mollic epipedon, per criterion 6 in U.S. Soil Taxonomy (12th edition). I have used it for QC of pedon data, and also to assess questions about how frequently e.g. the sliding scale portion of the thickness requirement is invoked.I'll have more fun graphs to show -- using more data -- but for now here is a demo showing how thick the mollic would have to be, and the boundaries of PSCS, for a subset of
loafercreek
.UPDATE (05/18/2020): to include better cambic finding via
getCambicBounds
and to portray "untruncated" sliding scale thickness requirements for QC.Obligatory profile plot
On a related note, along with this branch will come improvements to the
hzdesgnname
/hztexclname
slot usage and better / consistent methods for guessing horizon attributes of interest to analyses like these (argillic, mollic, PSCS) that are used in the default arguments to various functions that take a SPC as an argument.guessHzDesgnName
guessHzTexClName
guessHzAttrName
There are many notes in the
mollic.thickness.requirement
code comments about things that need to be expanded on pertaining to other diagnostic feature identification. Currently, this relies on variants of a new set of aqp methods calleddepthOf
.EDIT (5/24/2020): there have been significant updates to
getCambicBounds
, thedepthOf
family and other critical functions thatmollic.thickness.requirement
relies on. The results are much more stable with the Region 2 pedon dataset. There is still room to expand on natric, oxic, spodic horizon identification beyond horizon designations -- so I'll be seeking additional test cases for those next up.The text was updated successfully, but these errors were encountered: