implement weights argument for slab()

[brownag]

A planned feature for slab() is to (re-)support site-level weights. See #3

When specifying some dummy weights the following error message is issued

library(aqp)
#> This is aqp 1.30
#> 
#> Attaching package: 'aqp'
#> The following object is masked from 'package:stats':
#> 
#>     filter
data(sp1)
depths(sp1) <- id ~ top + bottom
slab(sp1, fm = ~ prop, weights = 1:length(sp1))
#> Error: weighted aggregation is not yet supported

Example use case:

• component percent weighted averages from an SPC derived from one or more SSURGO mapunits worth of horizon data (containing multiple soil components).

See ncss-tech/soilDB#194 for some sample DMU record IDs for weighted average aggregation and validation against Web Soil Survey aggregation

[dylanbeaudette]

Moving some specific content over from #3. It is on my list. I think that a full re-write based on data.table is in order. At the time (2016), I didn't have a viable alternative to split/apply/rbind or base::aggregate.

From #3

1. not currently possible with aggregate() as it can only operate on vectors
2. possible with other functions: https://stat.ethz.ch/pipermail/r-help/2003-June/035321.html
3. switching to data.table may be required:
   • http://stackoverflow.com/questions/17174653/return-multiple-columns-from-data-table-aggregation
4. split + lapply + parse list labels may be fast + flexible
   • split(d, list(d$g, d$h), drop=TRUE)
5. pre-standardization of weights based on entire range of weights in collection, or within a slab?

[brownag]

Note to consider option of supplying weights as a character vector length 1 column name (implemented in #258), or as a vector equal in length to number of profiles.
In principle I think it would be possible to support a matrix of weights, and/or horizon level weights.

[dylanbeaudette]

Note to consider option of supplying weights as a character vector length 1 column name (implemented in #258), or as a vector equal in length to number of profiles. In principle I think it would be possible to support a matrix of weights, and/or horizon level weights.

Yes: the original implementation (2008?) allowed for site-level or horizon-level weights. It wasn't entirely clear to me at the time how to implement horizon-level weighting into things like weighted SD over intervals > 1cm thickness.

I'd prefer that the updates as part of this issue and related PR implement site-level weighted first, via named column from site. Once the details of horizon-level weighting are determined, then I'd prefer to use a similar approach via named column from horizons.

[brownag]

I'd prefer that the updates as part of this issue and related PR implement site-level weighted first, via named column from site.

This is done