sf_mpoly: Helper for sf MULTIPOLYGON

In sfheaders: Converts Between R Objects and Simple Feature Objects

Helper for sf MULTIPOLYGON

Description

Constructs sf of MULTIPOLYGON objects, a helper for sf_multipolygon() with a simpler syntax.

Usage

sf_mpoly(obj, close = TRUE, keep = FALSE, list_columns = NULL)

Arguments

obj	sorted matrix or data.frame
close	logical indicating whether polygons should be closed. If TRUE, all polygons will be checked and force closed if possible
keep	logical indicating if the non-geometry and non-id columns should be kept. if TRUE you must supply the geometry and id columns, and only the first row of each geometry is kept. See Keeping Properties.
list_columns	vector of column names to turn into a list.

Value

sf object of MULTIPOLYGON geometries

Helpers

These are simpler versions of the main functions sf_point(), sf_multipoint(), sf_linestring(), sf_multilinestring(), sf_polygon(), and sf_multipolygon() for input data frame or matrix that contains columns appropriately of 'x', 'y', 'z', 'm', ' multipolygon_id', polygon_id', 'multilinestring_id', 'linestring_id', 'multipoint_id'.

This puts the onus of the naming and identification of entities onto the input data set, rather than when calling the creator function. This has pros and cons, so is not necessarily always 'simpler'. Please choose the appropriate constructor for the context you have. For examples a data frame from the real world with columns 'lon', 'lat', 'line' will be best used with

sf_linestring(df, x = "lon", y = "lat", linestring_id = "line")

whereas a heavy user of sfheaders might always create a data frame with 'x', 'y', 'linestring_id' precisely because they are expecting to call sf_line(df) and no further work is required. These are very different contexts and both equally valid.

Some columns are mandatory, such as 'x' and 'y' (always), while others depend on the output type where each column for that type is mandatory. The 'z' and/or 'm' values are included for 'XYZ', 'XYM', or 'XYZM' geometry types if and as they are present.

In summary these helpers:

• do not require arguments declaring column names.

• use assumed default column names, with no variation or absence allowed for a given type.

• use z, and/or m if present.

• use close = FALSE and keep = FALSE same as proper constructors.

• unlike sf_point() sf_pt() does not accept a flat vector for a single point.

• require a matrix or data frame with complete column names.

None of the helpers allow partial name matching for column names.

notes

sfheaders functions do not perform any validity checks on the geometries. Nor do they set Coordinate Reference Systems, EPSG, PROJ4 or precision attributes.

The data.frame and matrices you send into the sfheader functions must be ordered.

Keeping Properties

Setting keep = TRUE will retain any columns not specified as a coordinate (x, y, z, m) or an id (e.g., linestring_id, polygon_id) of the input obj.

You can use list_columns to specify which of the properties will be turned into a list, thus keeping all the values in the column. For columns not specified in list_columns, only the first row of the column is kept

The sf_* functions assume the input obj is a long data.frame / matrix, where any properties are repeated down the table for the same geometry.

Examples

m <- matrix(c(0,0,0,0,1,0,0,1,1,0,0,1,0,0,0), ncol = 3, byrow = TRUE,
      dimnames = list(NULL, c("x", "y", "z")))
m <- cbind(m, multipolygon_id = 1, polygon_id = 1, linestring_id = 1)
sf_mpoly( m )

df <- as.data.frame(m)

sf_mpoly( df)

## order doesn't matter, only the names are used
sf_mpoly(df[c(6, 5, 3, 4, 1, 2)])

sfheaders documentation built on May 29, 2024, 1:36 a.m.