Important note: The {duckspatial} R package is undergoing major changes in preparation for v1.0.0. This release will align with DuckDB v1.5 and its native CRS support in the Spatial extension.
Previously, {duckspatial} relied on a workaround to store CRS information in a dedicated column (named “crs_duckspatial” by default and referenced via the crs_column argument). With native CRS support now available, this workaround is no longer needed and will be removed. As a result, the crs and crs_column arguments are deprecated as of v0.9.0.
The upcoming version also introduces a new native spatial class, duckspatial_df. This represents a lazy spatial table backed by a temporary DuckDB view, allowing workflows to remain fully lazy until results are explicitly materialized with ddbs_collect(). In practice, this means you can work with {duckspatial} without eagerly loading data into R.
Finally, v1.0.0 will include many new functions and broader API improvements.
The {duckspatial} package provides fast and memory-efficient functions to analyze and manipulate large spatial vector datasets in R. It allows R users to benefit directly from the analytical power of DuckDB and its spatial extension, while remaining fully compatible with R’s spatial ecosystem, especially {sf}.
At its core, {duckspatial} bridges two worlds:
- R spatial workflows based on {sf} objects
- Database-backed spatial analytics powered by DuckDB SQL
This design makes {duckspatial} especially well suited for:
- Working with large spatial data sets
- Speeding up spatial analysis at scale
- Workflows where data does not fit comfortably in memory
Importantly, {duckspatial} brings the power of DuckDB spatial to R users while keeping workflows similar to {sf} .
You can install duckspatial directly from CRAN with:
install.packages("duckspatial")Or you can install the development version from GitHub with:
# install.packages("pak")
pak::pak("Cidree/duckspatial")A central design principle of {duckspatial} is that the same spatial operation can be used in different ways, depending on how your data is stored and how you want to manage memory and performance.
Most functions in {duckspatial} support four complementary workflows:
- Input
sf→ Outputsf - Input
sf→ Output DuckDB table - Input DuckDB table → Output
sf - Input DuckDB table → Output DuckDB table
See the “Get Started” vignette for examples.