6. Miscellaneous

In sf: Simple Features for R

For a better version of the sf vignettes see https://r-spatial.github.io/sf/articles/

knitr::opts_chunk$set(fig.height = 4.5)
knitr::opts_chunk$set(fig.width = 6)
knitr::opts_chunk$set(collapse = TRUE)

This vignette describes a number of issues that did not come up in the previous vignettes, and that may or may not be categorized as "frequently asked questions". Readers are encouraged to provide entries for this vignette (as for the others).

What is this EPSG code all about?

EPSG stands for a maintained, well-understood registry of spatial reference systems, maintained by the International Association of Oil \& Gass Producers (IOGP). "EPSG" stands for the authority, e.g. "EPSG:4326" stands for spatial reference system with ID 4326 as it is maintained by the EPSG authority. The website for the EPSG registry is found at the epsg.org domain.

How does sf deal with secondary geometry columns?

sf objects can have more than one geometry list-column, but always only one geometry column is considered active, and returned by st_geometry. When there are multiple geometry columns, the default print methods reports which one is active:

library(sf)
demo(nc, ask = FALSE, echo = FALSE)
nc$geom2 = st_centroid(st_geometry(nc))
print(nc, n = 2)

We can switch the active geometry by using st_geometry<- or st_set_geometry, as in

plot(st_geometry(nc))
st_geometry(nc) <- "geom2"
plot(st_geometry(nc))

Does st_simplify preserve topology?

st_simplify is a topology-preserving function, but does this on the level of individual feature geometries. That means, simply said, that after applying it, a polygon will still be a polygon. However when two features have a longer shared boundary, applying st_simplify to the object does not guarantee that in the resulting object these two polygons still have the same boundary in common, since the simplification is done independently, for each feature geometry.

Why do dplyr verbs not work for sf objects?

They do! However, many developers like to write scripts that never load packages but address all functions by the sf:: prefix, as in

i = sf::st_intersects(sf1, sf2)

This works up to the moment that a dplyr generic like select for an sf object is needed: should one call dplyr::select (won't know it should search in package sf) or sf::select (which doesn't exist)? Neither works. One should in this case simply load sf, e.g. by

library(sf)

What is this error/warning/message about?

although coordinates are longitude/latitude, xxx assumes that they are planar

Most (but not all) of the geometry calculating routines used by sf come from the GEOS library. This library considers coordinates in a two-dimensional, flat, Euclidean space. For longitude latitude data, this is not the case. A simple example is a polygon enclosing the North pole, which should include the pole:

polygon = st_sfc(st_polygon(list(rbind(c(0,80), c(120,80), c(240,80), c(0,80)))), 
        crs = 4326)
pole = st_sfc(st_point(c(0,90)), crs = 4326)
st_intersects(polygon, pole)

which gives a wrong result (no intersection).

st_centroid does not give correct centroids for longitude/latitude data

Similar to the above, centroids are computed assuming flat, 2D space:

st_centroid(polygon)[[1]]

where the centroid should have been the pole.

dist is assumed to be in decimal degrees (arc_degrees).

This message indicates that sf assumes a distance value is given in degrees. To avoid this message, pass a value with the right units:

pt = st_sfc(st_point(c(0,0)), crs = 4326)
buf = st_buffer(polygon, 1)
buf = st_buffer(polygon, units::set_units(1, degree))

sf documentation built on July 26, 2023, 5:22 p.m.