Shinyapps working locally but failing on build (related to sf)


ms_fips <- c("28009", "28033", "28093", "28137", "28143")

county.fips <- maps::county.fips

ms_map <- st_as_sf(maps::map("county", plot = FALSE, fill = TRUE)) %>%
    inner_join(county.fips, by = c("ID" = "polyname")) %>%
    filter(str_detect(ID, "^mississippi")) %>%
    filter(!fips %in% ms_fips) %>%
    ungroup() %>%
    summarize(geom = sf::st_union(geom)) %>%
    mutate(geo_name = "MS", fips = "28")

I am trying to make a map with specific counties compared to the rest of the state. Thus, I am using st_union() to aggregate the geometries for the rest of the counties. This process works fine locally, but fails when I try to deploy it to shinyapps (see error message below).

If I replace the st_union() call with st_combine(), it works both locally and online (but the inner borders for counties are retained, which is undesirable).

Error in value[[3L]](cond) : Problem with `summarise()` input `geom`.
✖ Evaluation error: TopologyException: Input geom 1 is invalid: Self-intersection at or near point -88.49768635253028 33.571661541724637 at -88.49768635253028 33.571661541724637.
ℹ Input `geom` is `sf::st_union(geom)`.

Upon further investigation, this has specifically to do with the Mississippi counties. Tennessee and Arkansas both work without issue.

However, the app launches successfully on my machine, but not when deploying.

Not sure why MS is specifically throwing the error, it's fixed with sf::st_buffer(x,0). Arkansas and Tennessee are both fine without it, however.

Buffer with zero is a well known "magic dust"; it works wonders... It is especially effective when dealing with objects originated in the ESRI world, as ESRI has different opinion of validity of some edge cases than what is the norm in the OGC world.

Other options to consider are:

  • correcting the geometry via sf::st_make_valid()
  • load the counties from an alternative source, tigris::counties() come to mind ({tigris} being the golden standard for US census data)
  • preparing a local working version of your object, and deploy to shinyapps as a digested object, known to consist of valid geometry, as a RDS file
  • using a more current version of GEOS backend (not really an option with shinyapps I am afraid)

I definitely saw other issues that were solved with st_buffer() - I think I was thrown off because I couldn't replicate the error locally, which led me to believe it was a shinyapps issue when it was actually an R issue.

It is not a R issue, but rather a GEOS issue (one of the three backends supporting {sf}, the other two being PROJ and GDAL). The version of GEOS on shinyapps is sort of ancient, even though R itself is current.
Not that it matters of course...

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.