plotly not plotting geom_sf data, "Error in st_coordinates.sfc(sf::st_geometry(model)) : not implemented for objects of class sfc_GEOMETRY"

[SebastianKrog]

Hi,

I am trying to convert this geom_sf plot to plotly, but I keep receiving an error:

library(ggplot2)
library(sf)
library(geojsonsf)
library(plotly)

dk_map <- geojson_sf("https://raw.githubusercontent.com/moestrup/covid19/master/test.json")

mainland <- ggplot(data=dk_map) +
  geom_sf()

mainland

ggplotly(mainland)

sessionInfo()

Gives the following output:

> dk_map <- geojson_sf("https://raw.githubusercontent.com/moestrup/covid19/master/test.json")
> mainland <- ggplot(data=dk_map) +
+   geom_sf()
> mainland

> ggplotly(mainland)
Error in st_coordinates.sfc(sf::st_geometry(model)) : 
  not implemented for objects of class sfc_GEOMETRY
> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 17763)

Matrix products: default

locale:
[1] LC_COLLATE=English_United Kingdom.1252  LC_CTYPE=English_United Kingdom.1252    LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C                            LC_TIME=English_United Kingdom.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] plotly_4.9.2.9000 geojsonsf_1.3.3   sf_0.9-3          ggplot2_3.3.0    

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.4         pillar_1.4.3       compiler_3.6.3     class_7.3-15       tools_3.6.3        digest_0.6.25      viridisLite_0.3.0 
 [8] jsonlite_1.6.1     lifecycle_0.2.0    tibble_3.0.0       gtable_0.3.0       pkgconfig_2.0.3    rlang_0.4.6        DBI_1.1.0         
[15] cli_2.0.2          rstudioapi_0.11    curl_4.3           e1071_1.7-3        httr_1.4.1         withr_2.1.2        dplyr_0.8.5       
[22] htmlwidgets_1.5.1  vctrs_0.3.0        classInt_0.4-3     grid_3.6.3         tidyselect_1.0.0   glue_1.3.2         data.table_1.12.8 
[29] R6_2.4.1           fansi_0.4.1        farver_2.0.3       tidyr_1.0.2        purrr_0.3.3        magrittr_1.5       scales_1.1.0      
[36] ellipsis_0.3.0     htmltools_0.4.0    units_0.6-6        assertthat_0.2.1   colorspace_1.4-1   KernSmooth_2.23-16 lazyeval_0.2.2    
[43] munsell_0.5.0      crayon_1.3.4       Cairo_1.5-12      
> 

I thought this was related to issue #1659, and tried installing the newest version of plotly from github (4.9.2.9000) but am still seeing the error above.

[GitHunter0]

I am also having this issue.

[GitHunter0]

@PhazeDK , I found a simple solution (using sf::st_cast(..., "MULTIPOLYGON")) that worked for me, try this:

library(ggplot2)
library(geojsonsf)
library(plotly)
library(sf)

dk_map <- geojson_sf("https://raw.githubusercontent.com/moestrup/covid19/master/test.json")

dk_map <- sf::st_cast(dk_map, "MULTIPOLYGON")

mainland <- ggplot(data=dk_map) + geom_sf()

mainland

ggplotly(mainland)

[Gutschlhofer]

I'm having the same issue when following the tutorial in the book for catograms: (https://plotly-r.com/maps.html#cartograms)

library(cartogram)
library(albersusa)

us_cont <- cartogram_cont(usa_sf("laea"), "pop_2014")

plot_ly(us_cont) %>% 
  add_sf(
    color = ~pop_2014, 
    split = ~name, 
    span = I(1),
    text = ~paste(name, scales::number_si(pop_2014)),
    hoverinfo = "text",
    hoveron = "fills"
  ) %>%
  layout(showlegend = FALSE) %>%
  colorbar(title = "Population \n 2014")

also gives the error you specified.

So this is probably something that was introduced in a recent commit, otherwise it wouldn't be in the book I guess.

The workaround above works, but is obviously not the desired solution.

[avsdev-cw]

Just bumping this a bit:

I work around the inability to handle GEOMETRY sf's by splitting my sf tables into (MULTI)LINESTRING, (MULTI)POINT and (MULTI)POLYGON tables and adding each as a new trace. This avoids the "cannot handle GEOMETRY" problem, however it does mean that I have 3 legend entries, (one line-style, one point-style, one filled line-style respectively). This means its a pain for users to toggle an entry on or off, they have to do all 3. Yes, I could use legendgroups, but that only works if I haven't already got a legendgroup.

I understand why it can't handle GEOMETRY well (let's be honest, the handling of polygons is a bit of a hack as it is), as it requires a different processing stream/plot type for each geometry type, but it would be very much of use to have it done internally. Whether this means that a sub-legendgroup needs inventing or a logical grouping of traces other than via a legend group which all behave off the same event, I have no answer.