geom_sf does not plot geometry when it has name different from "geometry"

[edzer]

In this example:

library(sf)
library(ggplot2)
nc = st_read(system.file("gpkg/nc.gpkg", package="sf"))
ggplot(nc) + geom_sf(aes(fill = AREA))
# Error in eval(expr, envir, enclos) : object 'geometry' not found

the geometry column is called geom, instead of geometry, however nc knows this:

> attr(nc, "sf_column")
# [1] "geom"

why doesn't geom_sf use sf_column, or get the geometry from nc by st_geometry(nc)?

The docs suggest that

ggplot(nc) + geom_sf(aes(geometry = geom, fill = AREA))

should work, but looks to me as if it doesn't. The examples are also not very helpful for this.

ggplot(nc) + geom_sf(data = nc, aes(fill = AREA))
#Error in if (st_is_longlat(crs)) bb = trim_bb(bb, margin) : 
#  missing value where TRUE/FALSE needed

[hadley]

The problem is that geom_sf() doesn't have access to the plot data. However, it should work if you supply the data directly.

[edzer]

With which command? (I have had problems reproducing a case posted to r-sig-geo)

[hadley]

Your final example should work:

ggplot(nc) + geom_sf(data = nc, aes(fill = AREA))

[edzer]

For the r-sig-geo poster it worked too, for me it doesn't, e.g. with sf from CRAN and ggplot2 from github (I tried both in terminal and in rstudio), and:

> devtools::session_info()
Session info -------------------------------------------------------------------
 setting  value                       
 version  R version 3.3.2 (2016-10-31)
 system   x86_64, linux-gnu           
 ui       X11                         
 language en_US                       
 collate  en_US.UTF-8                 
 tz       Europe/Berlin               
 date     2017-02-27                  

Packages -----------------------------------------------------------------------
 package    * version    date       source                            
 assertthat   0.1        2013-12-06 CRAN (R 3.3.0)                    
 colorspace   1.2-6      2015-03-11 CRAN (R 3.3.0)                    
 DBI          0.5-17     2017-02-27 Github (rstats-db/DBI@89005a5)    
 devtools     1.12.0     2016-06-24 CRAN (R 3.3.2)                    
 digest       0.6.12     2017-01-27 cran (@0.6.12)                    
 ggplot2    * 2.2.1.9000 2017-02-27 Github (tidyverse/ggplot2@2dce982)
 gtable       0.2.0      2016-02-26 CRAN (R 3.3.0)                    
 lazyeval     0.2.0      2016-06-12 CRAN (R 3.3.2)                    
 memoise      1.0.0      2016-01-29 CRAN (R 3.3.2)                    
 munsell      0.4.3      2016-02-13 CRAN (R 3.3.0)                    
 plyr         1.8.4      2016-06-08 CRAN (R 3.3.0)                    
 Rcpp         0.12.9     2017-01-14 CRAN (R 3.3.2)                    
 scales       0.4.1      2016-11-09 CRAN (R 3.3.2)                    
 sf         * 0.3-4      2017-02-06 CRAN (R 3.3.2)                    
 tibble       1.2        2016-08-26 CRAN (R 3.3.1)                    
 udunits2     0.13       2016-11-17 CRAN (R 3.3.2)                    
 units        0.4-3      2017-02-05 local                             
 withr        1.0.2      2016-06-20 CRAN (R 3.3.1)                    

[edzer]

Traceback:

> ggplot(nc) + geom_sf(data = nc, aes(fill = AREA))
Error in if (st_is_longlat(crs)) bb = trim_bb(bb, margin) : 
  missing value where TRUE/FALSE needed
> traceback()
12: sf::st_graticule(bbox, crs = params$crs, lat = scale_y$breaks %|W|% 
        NULL, lon = scale_x$breaks %|W|% NULL, datum = self$datum)
11: f(..., self = self)
10: self$coord$setup_panel_params(scale_x, scale_y, params = self$coord_params)
9: (function (scale_x, scale_y) 
   {
       self$coord$setup_panel_params(scale_x, scale_y, params = self$coord_params)
   })(dots[[1L]][[1L]], dots[[2L]][[1L]])
8: mapply(FUN = f, ..., SIMPLIFY = FALSE)
7: Map(setup_panel_params, scales_x, scales_y)
6: f(..., self = self)
5: layout$setup_panel_params()
4: ggplot_build(x)
3: print.ggplot(yy$value)
2: print(yy$value)
1: source("gg", , T)

debugging indicates that in st_graticule, argument crs is NULL, which shouldn't happen.

[hadley]

I'll look into it, but it probably won't be for a couple of weeks as I'm currently deep in dplyr.

[edzer]

I understand. For the record, this

ggplot(nc) + geom_sf(data = nc, aes(fill = AREA)) + coord_sf(crs = st_crs(nc))

works fine. I'll see if I can grasp ggproto, in the meantime.

[balazsdukai]

I've got the same problem as @edzer but his solution works for me as well.

[adrfantini]

AFAICT this is still present, one needs to pass the data argument for it to work. This feels like a workaround more than a solution to be honest.

[Robinlovelace]

Bump: the issue is not fixed so not sure why it was closed. Reproducible example showing the work-around:

devtools::install_github("tidyverse/ggplot2")
library(ggplot2)
library(sf)
nc = read_sf(system.file("shape/nc.shp", package = "sf"))
ggplot(nc) + geom_sf(aes(fill = BIR79))
write_sf(nc, "nc.gpkg")
nc2 = read_sf("nc.gpkg")
ggplot(nc2) + geom_sf(aes(fill = BIR79))
nc2$geometry = st_geometry(nc2)
ggplot(nc2) + geom_sf(aes(fill = BIR79))

Can print the result of reprexing that but to save internet bandwidth, it's sufficient to say that I get the following error message on the first ggplot2(nc2) ... call:

Error in FUN(X[[i]], ...) : object 'geometry' not found

@karawoo or @hadley please could you try to reproduce this issue and re-open the issue if you can.

Many thanks for an awesome package by-the-way, hope this helps in the final push for improvements and bug fixes in time for the CRAN release of ggplot 2.2.2.

[karawoo]

I can confirm the issue is still present. As @hadley said originally, geom_sf() doesn't have access to the plot data. Supplying the data with ggplot(nc2) + geom_sf(data = nc2, aes(fill = BIR79)) works, so I'll leave it to Hadley on whether or not to reopen.

[Robinlovelace]

Many thanks for the quick reply. Just tested and this also works:

ggplot() + geom_sf(data = nc2, aes(fill = BIR79))

I just took a look at ?geom_sf (probably should have done that before bumping this issue, apologies) and see it's well-documented:

geom_sf uses a unique aesthetic: geometry, giving an column of class sfc containg simple features data. There are three ways to supply the geometry aesthetic:

Do nothing: by default geom_sf assumes it is stored in the geometry column.

Explicitly pass an sf object to the data argument. This will use the primary geometry column, no matter what it's called.

Supply your own using aes(geometry = my_column)

Unlike other aesthetics, geometry will never be inherited from the plot.

[Robinlovelace]

So in summary, happy for this to remain closed. Great work, look forward to seeing sf support on CRAN, not only because we're using geom_sf() in our forthcoming book, as illustrated here (any comments / suggestions on this very welcome): https://geocompr.robinlovelace.net/adv-map.html#fig:nz-gg

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/