get_SDA_property(method = 'MAX') oddity

[dylanbeaudette]

Noticing something strange when using MAX aggregation.

library(soilDB)

mu <- '623426'

# note: one of these is a minor component
SDA_query("SELECT mukey, cokey, compname, majcompflag from component where mukey = '623426';")


# ok
get_SDA_property(property = 'claytotal_r', top_depth = 0, bottom_depth = 25, method = 'None', mukeys = mu, include_minors = TRUE)

# ok
get_SDA_property(property = 'claytotal_r', top_depth = 0, bottom_depth = 25, method = 'Dominant Component (Numeric)', mukeys = mu, include_minors = TRUE)

# ok
get_SDA_property(property = 'claytotal_r', top_depth = 0, bottom_depth = 25, method = 'Weighted Average', mukeys = mu, include_minors = TRUE)

# ok
get_SDA_property(property = 'claytotal_r', top_depth = 0, bottom_depth = 25, method = 'MIN', mukeys = mu, include_minors = TRUE)

# not right, should be 45
get_SDA_property(property = 'claytotal_r', top_depth = 0, bottom_depth = 25, method = 'MAX', mukeys = mu, include_minors = TRUE)

[brownag]

Thanks for reporting this. Three things here (that I can fix/upgrade)

• top_depth and bottom_depth are currently used only for method="weighted average" and "dominant component (numeric)" -- this is documented but unexpected/easy to forget -- so the correct value is 47.5 not 45 (as written). It is still wrong because it returns the MAX for the dominant component in this case

• Likewise include_minors currently has no effect on the MIN/MAX aggregation -- minors are always included (as written)

• The second subquery for MIN/MAX orders on comppct_r and takes the first record which appears to lead to this inconsistency -- this is easy to fix for single-property queries but becomes very complicated with vectorization. Need to think on this a bit and re-engineer. Will open a PR. For instance in a query calling MIN on claytotal_r and sandtotal_r in your example the former would come from the Braman component and the latter from Osage.