Sf: st_coordinates() doesn't know about sfc_GEOMETRY

[cpsievert]

I was surprised to see this error

library(sf)
library(albersusa)

counties_sf("laea") %>%
    st_simplify(TRUE, dTolerance = 5000) %>% 
    st_coordinates()

#> Error in st_coordinates.sfc(st_geometry(x)) : not implemented

That's because st_coordinates() doesn't know what to do with "sfc_GEOMETRY" -- seems like it should?

counties_sf("laea") %>%
    st_simplify(TRUE, dTolerance = 5000) %>% 
    st_geometry() %>% 
    class()

#> "sfc_GEOMETRY" "sfc" 

Session info ------------------------------------------------------------------
 setting  value                       
 version  R version 3.4.2 (2017-09-28)
 system   x86_64, darwin15.6.0        
 ui       X11                         
 language (EN)                        
 collate  en_US.UTF-8                 
 tz       America/Chicago             
 date     2017-12-04                  

Packages ----------------------------------------------------------------------
 package     * version    date       source                               
 albersusa   * 0.3.0      2017-04-25 Github (hrbrmstr/albersusa@82220d3)  
 assertthat    0.2.0      2017-04-11 CRAN (R 3.4.0)                       
 autoinst      0.0.0.9000 2017-04-27 Github (jimhester/autoinst@dfbdc50)  
 backports     1.1.1      2017-09-25 CRAN (R 3.4.1)                       
 base        * 3.4.2      2017-10-04 local                                
 class         7.3-14     2015-08-30 CRAN (R 3.4.2)                       
 classInt      0.1-24     2017-04-16 CRAN (R 3.4.0)                       
 colorout      1.1-2      2017-04-23 Github (jalvesaq/colorout@020a14d)   
 compiler      3.4.2      2017-10-04 local                                
 crayon        1.3.4      2017-09-16 CRAN (R 3.4.1)                       
 datasets    * 3.4.2      2017-10-04 local                                
 DBI           0.7        2017-06-18 CRAN (R 3.4.0)                       
 desc          1.1.1      2017-08-03 CRAN (R 3.4.1)                       
 devtools    * 1.13.4     2017-11-09 CRAN (R 3.4.2)                       
 digest        0.6.12     2017-01-27 CRAN (R 3.4.0)                       
 e1071         1.6-8      2017-02-02 CRAN (R 3.4.0)                       
 foreign       0.8-69     2017-06-22 CRAN (R 3.4.2)                       
 fortunes      1.5-4      2016-12-29 CRAN (R 3.4.0)                       
 graphics    * 3.4.2      2017-10-04 local                                
 grDevices   * 3.4.2      2017-10-04 local                                
 grid          3.4.2      2017-10-04 local                                
 htmltools     0.3.6      2017-09-11 local                                
 htmlwidgets   0.9        2017-11-27 Github (ramnathv/htmlwidgets@c042cca)
 inline        0.3.14     2015-04-13 CRAN (R 3.4.0)                       
 knitr         1.17       2017-08-10 CRAN (R 3.4.1)                       
 lattice       0.20-35    2017-03-25 CRAN (R 3.4.2)                       
 magrittr      1.5        2014-11-22 CRAN (R 3.4.0)                       
 maptools      0.9-2      2017-03-25 CRAN (R 3.4.0)                       
 memoise       1.1.0      2017-04-21 CRAN (R 3.4.0)                       
 methods     * 3.4.2      2017-10-04 local                                
 pkgload       0.0.0.9000 2017-10-26 Github (r-lib/pkgload@8b97605)       
 R6            2.2.2      2017-06-17 CRAN (R 3.4.0)                       
 Rcpp          0.12.14    2017-11-23 CRAN (R 3.4.3)                       
 rematch2      2.0.1      2017-06-20 CRAN (R 3.4.0)                       
 reprex      * 0.1.1      2017-01-13 CRAN (R 3.4.0)                       
 rgdal         1.2-16     2017-11-21 CRAN (R 3.4.3)                       
 rgeos         0.3-26     2017-10-31 CRAN (R 3.4.2)                       
 rlang         0.1.4      2017-11-05 CRAN (R 3.4.2)                       
 rprojroot     1.2        2017-01-16 CRAN (R 3.4.0)                       
 sf          * 0.5-6      2017-12-04 local                                
 sp            1.2-5      2017-06-29 CRAN (R 3.4.1)                       
 stats       * 3.4.2      2017-10-04 local                                
 testthat      1.0.2      2016-04-23 CRAN (R 3.4.0)                       
 tibble        1.3.4      2017-08-22 CRAN (R 3.4.1)                       
 tools         3.4.2      2017-10-04 local                                
 udunits2      0.13       2016-11-17 CRAN (R 3.4.0)                       
 units         0.4-6      2017-08-27 CRAN (R 3.4.1)                       
 utils       * 3.4.2      2017-10-04 local                                
 withr         2.1.0.9000 2017-11-29 Github (jimhester/withr@fe81c00) 

[edzer]

The question is: what should it return? What should e.g.

st_coordinates(st_sfc(st_point(0:1), st_polygon(list(rbind(c(0,0),c(1,0),c(1,1),c(0,0))))))

return?

[mdsumner]

I'd expect NAs where their values are not relevant to less complex geoms. It's a bad way to encode complex forms, but it's the best you can do in a single table.

My approach in silicate is to split into relational forms, so these two tables record almost everything required to decompose to general form and round-trip (for "devs").

g <- st_sfc(st_point(0:1), st_polygon(list(rbind(c(0,0),c(1,0),c(1,1),c(0,0)))))
## gives a map of what's there
gibble::gibble(g)
# A tibble: 2 x 4
#   nrow  ncol    type object
#  <dbl> <dbl>   <chr>  <dbl>
#1     1     2   POINT      1
#2     4     2 POLYGON      2

## the raw coordinates, matching the geometry map above
## devtools::install_github("hypertidy/silicate")
silicate::sc_coord(g)
# A tibble: 5 x 2
#     x_    y_
#  <dbl> <dbl>
#1     0     1
#2     0     0
#3     1     0
#4     1     1
#5     0     0

[edzer]

For @cpsievert 's case, I would go for

counties_sf("laea") %>% 
   st_simplify(TRUE, dTolerance = 5000) %>% 
   st_cast("MULTIPOLYGON") %>% 
   st_coordinates()

[cpsievert]

Thanks for the responses @edzer @mdsumner

The question is: what should it return?

Maybe a list of matrices with an informative warning? An informative error would also be an improvement.

[edzer]

a list would make the function type-unsafe; I've tried to improve the error message.

[edzer]

@cpsievert I am fully in favor of robust polygon plotting support in plotly, but think that the native representation of POLYGON and MULTIPOLYGON is straightforward enough, and more useful than what you'd get from st_coordinates. But even with that, you're not 100% sure plotting will go right, since there is no (hard) requirement in the simple feature standard regarding ring directions (outer ring: counter clockwise, holes clockwise); this recently led to changing defaults in https://github.com/r-spatial/sf/commit/889b8c00b4dfd009447f80d0bf904e169af7a5c1 .