aoi in get_surgo_tables stopped working

[femiguez]

I get an error from a spatial package

[brownag]

Hey @femiguez. Maintainer of soilDB here

I looked at this as I was concerned this was some sort of regression in soilDB...

It appears the problem is with conversion of sf object to sp here:

apsimx/R/get_ssurgo_tables.R

Line 84 in 5e1e812

if(inherits(aoi, "sf")) aoi <- sf::as_Spatial(aoi, "Spatial")

I get error

Error in if (cast) from = st_cast(from) : 
  argument is not interpretable as logical

In this case I believe all you need to change is remove "Spatial" as second argument

if(inherits(aoi, "sf")) aoi <- sf::as_Spatial(aoi) 

[femiguez]

@brownag Thanks Andrew! I was testing this. It looks like I can remove that line all together. Maybe at some point soilDB was expecting 'Spatial' objects and now it handles 'sf' as well.

I do have another question. I have a method for comparing soil profiles that is a work in progress. With the current version of the model from github I can do the following:

library(apsimx)
sp1 <- get_ssurgo_soil_profile(c(-93, 42), fix = TRUE)
sp2 <- get_isric_soil_profile(c(-93, 42), fix = TRUE)

cmp12 <- compare_apsim_soil_profile(sp1[[1]], sp2, labels = c("ssurgo", "isric"),
                                    merge.wide = FALSE)

plot(cmp12, property = "Carbon")

How would you do this (using your packages)? You can just point me in the right direction. Thanks!

[brownag]

Yes, we've supported various spatial object inputs for a little while now. I was going to suggest that you possibly don't need 'sp' here but didn't look deeply at the rest of the code. Great!

For visual comparison of a single property, I probably would use the SoilProfileCollection object from aqp package. soilDB uses this class as a common multi-profile container for various database outputs. With an SPC you can quickly make sketches of soil profiles with the plotSPC() function using e.g. "Carbon" as the thematic variable.

Something like this:

library(aqp)
library(apsimx)

sp1 <- get_ssurgo_soil_profile(c(-93, 42), fix = TRUE)
sp2 <- get_isric_soil_profile(c(-93, 42), fix = TRUE)

spc <- data.table::rbindlist(list(
  data.frame(id = "SSURGO", sp1[[1]]$soil),
  data.frame(id = "ISRIC", sp2$soil)
), fill = TRUE)

spc$top <- gsub("(\\d+)-\\d+", "\\1", spc$Depth)
spc$bottom <- gsub("\\d+-(\\d+)", "\\1", spc$Depth)

depths(spc) <- c("id", "top", "bottom")
plotSPC(spc, color = "Carbon")

Happy to provide any additional feedback or answer questions on this topic!

---

An aside: I see that CEC is not returned for get_ssurgo_soil_profile()--CEC by a couple methods (pH 7 cec7_r, pH 8.2 sumbases_r should be accessible from the fetchSDA() function result). Unfortunately SSURGO does not (yet) include Nitrogen information

[femiguez]

@brownag Yes, I should get rid of sp, I'm waiting for this to stop working. :)

Is there a way to compare soils side-by-side as it is done below? (There is obviously R code behind these graphs). In apsimx I'm trying to make it really easy with those functions.

https://casoilresource.lawr.ucdavis.edu/sde/?series=kalamazoo#lab-data

[brownag]

Is there a way to compare soils side-by-side as it is done below? (There is obviously R code behind these graphs). In apsimx I'm trying to make it really easy with those functions.

https://casoilresource.lawr.ucdavis.edu/sde/?series=kalamazoo#lab-data

Yes, those plots use lattice graphics and some custom panel functions that are defined in aqp.

This "aggregation over slabs" section of the Intro to SPC objects vignette has some demo code you could start with. The second plot example in that section demonstrates adding lines for multiple groups of profiles. It should be feasible with a little modification of the example and reshaping of profile data to omit the multi-profile/group aggregation via aqp::slab() and just show lines for individual profiles: https://ncss-tech.github.io/aqp/articles/Introduction-to-SoilProfileCollection-Objects.html#aggregation-over-slabs

[femiguez]

@brownag Thanks! This helps me understand the capabilities of 'soilDB/aqp' better. I think they are complimentary rather than overlapping. In part the design in apsimx is driven by APSIM needs, but there are opportunities to make it a bit more flexible. A main reason behind what I'm doing is that I want to understand better the impact of soil on APSIM simulations. This requires the main variables that differ between different synthetic soil profiles