createSSURGO: add support for creating DuckDB and other DBI-compatible databases

[brownag]

For a few months I have been exploring the idea of making SSURGO DuckDB databases.

To further support incorporating this into my workflows, this PR configures createSSURGO() to optionally use {duckdb} instead of {sf}+{RSQLite}. To toggle on this behavior use createSSURGO(..., duckdb=TRUE).

In the future I would like to develop benchmarks and examples for large database processing--i.e. all of SSURGO in DuckDB vs. Spatialite or Geopackage.

[dylanbeaudette]

Good idea. I haven't tried, but there is certainly a lot of noise on the internet about how great duckdb might be. I'd also suggest unzipping SSURGO archives in parallel--that seems to be the biggest bottleneck right now.

[brownag]

Good idea. I haven't tried, but there is certainly a lot of noise on the internet about how great duckdb might be.

It is definitely very powerful.

Right now a slight barrier to my use of it for spatial stuff is interchanging between the internal duckdb format and WKB for use in sf or similar. Can use a query that invokes ST_AsWKB(), or there is a wrapper package {duckdbfs} to do this

I'd also suggest unzipping SSURGO archives in parallel--that seems to be the biggest bottleneck right now.

That is an improvement we could make for downloadSSURGO(), for sure. I am also curious how parallel unzip would compare to direct read with GDAL /vsizip/

[brownag]

Instead of duckdb=TRUE argument, consider initializing a DBIConnection object, defaulting to a new RSQLite::SQLite() connection. The class of the connection object can be used to trigger driver specific routines. This would likely make the routine more easily generalizable beyond RSQLite and duckdb

[brownag]

In a091516 I have implemented a more generalized approach using an optional connection (conn) argument.

Current pattern of specifying filename can still be used for GPKG or SQLite output, or an existing connection can be provided.

DuckDB now requires a custom connection be provided, and gets some special handling due to the unique way spatial data are handled internally.

For all other DBI connection types the spatial data are written with sf. I have tested this with PostGIS only at this time (see 87ff391 for minimal example), but in theory the routine should work with any DBI-compatible driver that supports spatial data.