Code Monkey home page Code Monkey logo

ggspc's Introduction

{ggspc}

R-CMD-check ggspc HTML Manual CRAN status Codecov test coverage

The goal of {ggspc} is to provide custom ‘Stat’, ‘Geom’ and ‘theme’ definitions for ‘SoilProfileCollection’ object compatibility with ‘ggplot2’.

Installation

You can install the development version of {ggspc} like so:

remotes::install_github("brownag/ggspc")

Example

This a example shows how to solve the common problem of plotting variables contained in a SoilProfileCollection with ggplot2::ggplot()

library(aqp)
#> The legacy packages maptools, rgdal, and rgeos, underpinning the sp package,
#> which was just loaded, will retire in October 2023.
#> Please refer to R-spatial evolution reports for details, especially
#> https://r-spatial.org/r/2023/05/15/evolution4.html.
#> It may be desirable to make the sf package available;
#> package maintainers should consider adding sf to Suggests:.
#> The sp package is now running under evolution status 2
#>      (status 2 uses the sf package in place of rgdal)
#> This is aqp 2.0
library(ggspc)
library(ggplot2)

data(loafercreek, package = "soilDB")
GHL(loafercreek) <- "genhz"

Basics

This is a demonstration of what is possible with a simple fortify(<SPC>) method defined. The “fortify” method makes it such that names from horizon and site slots of the SPC can be used in ggplot() aesthetics via aes().

# site v.s. site level
ggplot(loafercreek, aes(earthcovkind1, slope_field)) +
  geom_boxplot(na.rm = TRUE)

# site v.s. horizon level
ggplot(loafercreek, aes(hillslopeprof, clay)) +
  geom_boxplot(na.rm = TRUE)

# horizon v.s. horizon level
ggplot(loafercreek, aes(clay, genhz)) +
  geom_boxplot(na.rm = TRUE)

Depth Weighted Aggregation (stat_depth_weighted())

The stat_depth_weighted() function is a specialized {ggplot2} statistic intended for calculation of depth-weighted values for horizon data in a SoilProfileCollection. The default uses a constant interval from=0 to=200 (centimeters), but the intervals of interest may alternately be specified as site-level column names (unquoted), and therefore may vary between profiles.

Currently, stat_depth_weighted() only supports the “point” geometry type, but in future “boxplot” and others may be supported.

# default y aesthetic is the profile_id(<SPC>)
ggplot(loafercreek[1:10], aes(clay)) +
  stat_depth_weighted(na.rm = TRUE)

# can use alternate y aesthetic, e.g. hillslopeprof
ggplot(loafercreek, aes(clay, hillslopeprof)) +
  stat_depth_weighted(na.rm = TRUE)

# continuous y axes works too (horizon v.s. horizon)
ggplot(loafercreek, aes(clay, sand)) +
  stat_depth_weighted(na.rm = TRUE)

# continuous y (horizon v.s. site)
ggplot(loafercreek, aes(clay, slope_field)) +
  stat_depth_weighted(na.rm = TRUE)

# can combine with typical ggplot geoms (0-200cm mean over boxplots)
ggplot(loafercreek, aes(clay, hillslopeprof)) +
  geom_boxplot(na.rm = TRUE) + 
  stat_depth_weighted(na.rm = TRUE, col = "red", pch = 17, cex = 3)

# use site-level columns for profile-specific intervals (e.g. PSCS)
ggplot() +
  stat_depth_weighted(
    loafercreek,
    aes(clay, hillslopeprof),
    na.rm = TRUE,
    from = psctopdepth,
    to = pscbotdepth
  )

ggspc's People

Contributors

brownag avatar

Stargazers

 avatar

Watchers

 avatar

ggspc's Issues

`ggplot()` and `fortify()` for SoilProfileCollection / standard syntax for creating ggplot with an SPC

"Problem" (quoted from initial README entry ~February 2023)

Currently the stat_* functions extract metadata after the fortify() method is called by accessing a “last SoilProfileCollection” cached in a special environment ggspc.env exported by the package.

It was previously recognized this can be “fixed” with an explicit reference to the dataset in the stat or geom calls (i.e. ggplot() + stat_depth_weighted(loafercreek)).

Demonstration of Problem

This causes problems when data are defined in the ggplot() call, such as the following unexpected behavior.

library(ggspc)
library(ggplot2)

data(loafercreek, package = "soilDB")
data(gopheridge, package = "soilDB")

aqp::nrow(loafercreek)
## [1] 626
aqp::nrow(gopheridge)
## [1] 317
x <- ggplot(loafercreek, aes(clay, hillslopeprof))
y <- ggplot(gopheridge, aes(clay, hillslopeprof))

x + geom_boxplot() # works
## Warning: Removed 167 rows containing non-finite values (`stat_boxplot()`).

y + geom_boxplot() # works
## Warning: Removed 80 rows containing non-finite values (`stat_boxplot()`).

x + stat_depth_weighted() # error
## Error in `stat_depth_weighted()`:
## ! Problem while computing stat.
## ℹ Error occurred in the 1st layer.
## Caused by error in `$<-.data.frame`:
## ! replacement has 317 rows, data has 626
x + stat_depth_weighted(loafercreek) # works

y + stat_depth_weighted() # error
## Error in `stat_depth_weighted()`:
## ! Problem while computing stat.
## ℹ Error occurred in the 1st layer.
## Caused by error in `$<-.data.frame`:
## ! replacement has 626 rows, data has 317
y + stat_depth_weighted(gopheridge) # works

Path forward

Looking around at other packages that hack ggplot2 and/or provide special methods for S4 classes... most give examples of using the  ggplot() + stat_depth_weighted(loafercreek) style. The S4 object is not supplied to the ggplot() function. The general idea that full object information can persist past fortify() is not likely consistent with the design of ggplot2/ggproto objects.

With adequate warning and documentation the above workaround could be a simple and effective way of doing things. Would need to revise the few examples that suggest doing the other way, and provide warnings to folks who will almost certainly try to pass their SoilProfileCollection directly to ggplot2::ggplot(). Rather than overwriting a last SPC object in a shared package environment, I have tried returning the SPC as an attribute of the ggplot() result, but I don’t know that it is possible to expose that attribute to the stat_* functions or ggproto classes by any standard method.

An alternate approach might also include providing a custom ggplot() like method, or an object that can store a custom dataset-specific environment (rather than a package environment.

Perhaps there is still a better, more canonical, ggplot2 way to implement this I have still not figured out.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.