You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{aqp} SoilProfileCollections are supposed to be schema-agnostic. In general the @diagnostic slot has been used for diagnostic features. A while back, I added a @restrictions slot for the related (but different in SSURGO/NASIS) restrictions table.
At the time, it seemed simpler to add a slot rather than disrupt the current workflows where @diagnostic contains only diagnostic features.
I propose that the restrictions slot be removed and common use cases of these slots (e.g. by soilDB fetch functions) be updated to add both restrictions and diagnostics to the diagnostics slot. {aqp} should provide several methods to facilitate this. In principle, one should be able to add diagnostics and restrictions, preserving original column names by data.table::rbindlist(fill = TRUE) creating "wide" tables that should, in general, be backwards compatible with existing code. {aqp} would continue to define diagnostic_hz getter/setter, whereas the restrictions methods that are currently less frequently used could be defined as a SoilProfileCollection-method within {soilDB} (that uses something like, pattern matching on column name to find "restr", or makes use of origin metadata to match schema)
I have been meaning to put this into an issue for some time. I guess I want feedback on two things.
Should the restrictions slot be removed from the SoilProfileCollection?
If restrictions slot is removed, how can we best retain the existing functionality and also expand to deal with more generalized zones (control sections, etc) that might be valuable to visualize with addDiagnosticBracket?
The text was updated successfully, but these errors were encountered:
I was thinking about this some more and was wondering if this could be an opportunity to generalize diagnostic_hz as well as restrictions. We could define a SPC method such as feature/feature<- that handles arbitrary data.frame-like data containing top and bottom depths of zones that have some sort of group and unique label.
e.g.
feature(spc, type = "diag") <- diagnostic.data.frame
feature(spc, type = "restr") <- restr.data.frame
feature(spc, type = "psc") <- psc.data.frame
# get just diagnostic feature types
# ... filter columns with "diag" in name? and rows with type "diag"?
feature(spc, type = "diag")
# get all feature types
feature(spc)
Instead of removing diagnostic_hz/restrictions and their setters, redefine them to use the feature method.
I don't think this is ideal --but just another idea. The above provides a way to keep definitions of diagnostic_hz and restrictions in {aqp} while further generalizing the single data.frame-like slot for other types of soil depth intervals.
addDiagnosticBracket has esentially all of the relevant arguments to support the more generalized result. Not sure if it could be further streamlined.
{aqp} SoilProfileCollections are supposed to be schema-agnostic. In general the
@diagnostic
slot has been used for diagnostic features. A while back, I added a@restrictions
slot for the related (but different in SSURGO/NASIS) restrictions table.At the time, it seemed simpler to add a slot rather than disrupt the current workflows where
@diagnostic
contains only diagnostic features.I propose that the restrictions slot be removed and common use cases of these slots (e.g. by soilDB fetch functions) be updated to add both restrictions and diagnostics to the diagnostics slot. {aqp} should provide several methods to facilitate this. In principle, one should be able to add diagnostics and restrictions, preserving original column names by
data.table::rbindlist(fill = TRUE)
creating "wide" tables that should, in general, be backwards compatible with existing code. {aqp} would continue to definediagnostic_hz
getter/setter, whereas therestrictions
methods that are currently less frequently used could be defined as a SoilProfileCollection-method within {soilDB} (that uses something like, pattern matching on column name to find "restr", or makes use of origin metadata to match schema)I have been meaning to put this into an issue for some time. I guess I want feedback on two things.
Should the restrictions slot be removed from the SoilProfileCollection?
If restrictions slot is removed, how can we best retain the existing functionality and also expand to deal with more generalized zones (control sections, etc) that might be valuable to visualize with
addDiagnosticBracket
?The text was updated successfully, but these errors were encountered: