search

ctmm-initiative / ctmm

Continuous-Time Movement Modeling. Functions for identifying, fitting, and applying continuous-space, continuous-time stochastic movement models to animal tracking data.
http://biology.umd.edu/movement.html
43 stars 10 forks source link

Feature request: compatibility with sf #37

Closed taoofcoffee closed 3 years ago

taoofcoffee commented 3 years ago

At present, ctmm allows the export of UDs as a raster, SpatialPolygonsDataFrame, or as a shapefile. Considering the movement in the spatial community to use sf instead of sp, it would be great if ctmm had compatibility with this package in the future.

chfleming commented 3 years ago

Just glancing at sf, would there be anything lost if the coercion functions went ctmm -> sp -> sf ?

taoofcoffee commented 3 years ago

That's a good question. I found this information regarding conversion from sp to sf:

"As the Spatial objects only support MULTILINESTRING and MULTIPOLYGON, LINESTRING and POLYGON geometries are automatically coerced into their MULTI form. When converting Spatial into sf, if all geometries consist of a single POLYGON (possibly with holes), a POLYGON and otherwise all geometries are returned as MULTIPOLYGON: a mix of POLYGON and MULTIPOLYGON (such as common in shapefiles) is not created. Argument forceMulti=TRUE will override this, and create MULTIPOLYGONs in all cases. For LINES the situation is identical"

Given that sp objects exported from UD objects are either single or multipolygons, it seems like it should be an easy conversion. The only problem I've encountered converting sp to sf has been with multiline files that result in invalid geometries, but that should not be the case here.

chfleming commented 3 years ago

I coded up sf exporting with as.sf() on GitHub. Please tell me if there is anything else required.