new functions for common QC of pedon / component data

[dylanbeaudette]

These would enhance the basic QC checks performed by fetchNASIS.

[brownag]

I have many of these.

We should drum up a list of them that we want and come up with a convenient way of outputting the QC results that are currently stored in objects in the package environment.

Then add an option and or plotting function for convenient display of QC that is (optionally?) run during fetchNASIS()

[dylanbeaudette]

List-away!
Last time Jay and I were discussing this we thought that it would be nice to retain a small-level of QC in fetchNASIS while off-loading a more comprehensive suite to a set of new dedicated functions. The console is rather congested after the current calls to fetchNASIS and we probably shouldn't be stuffing anything else into the output. The use of hidden objects in a new environment is also a bit of a hack.

First thought that comes to mind, pedonQC (or whatever) could be a parent function that invokes a series of tests. Results are stored in a list, each element is a test containing IDs and notes. We can start with NASIS-specific tests for now and expand to the broader range of SoilProfilecollection objects later.

[brownag]

Agreed.

I like the idea of returning a profileQC object (different flavors for different SPC data origins)

Then sharpshootR and/or soilReports could have some clever tabular and or graphical functions for displaying the different types of profileQC results in an easy-to-read format (similar to NASIS reports, but not crippled by the limitations of CVIR)

The profileQC result would probably have a basic panel of default checks (i.e. fundamental SPC topologic constraints already part of fetchNASIS) -- but also would provide more information than is currently given in the console output.

For instance, when a horizon overlap is due to duplication of a record from join on RV in presence of multiple RVs in the input, there is no way to programmatically resolve the RV to choose... the user needs to fix it.

But we can at least inform the user (by inspection of the individual query results or test_hz_logic()) whether the duplication is due to multiple RV in texture, structure, etc.

I would argue that some of these constraints should preclude a SPC from being created by the fetchXX function. The rmHzErrors = TRUE default is handy, but as these data structures and analysis routines become more widely adopted, I feel we have an obligation to force the user to do their basic QC, or at least acknowledge the omission (by fixing it or at least removing the offending profile from their selected set )