New function neon_cloud() leverages NEON’s migration to Google Cloud Storage (GCS). This function provides direct access to NEON csv data without downloading the data first.
neon_table() gains the optional argument lazy. Set to TRUE to return a “lazy” table as a dplyr connection directly to the table in duckdb. This is suitable for working with any tables that would be much to large to interact with directly in R.
neon_index() to run on read-only filesystemsneon_store() [#50]neon_store() import terminates prematurely, [#48])show_deprecated_data(), shows which if any local data files have been updated in the NEON API. Such files have changed both the timestamp in their filename and changed content, and older versions are no longer returned by the NEON API. The warning only appears if the deprecated data files are still available in the local store.neon_store()) is now pluggable: you can pass any valid DBIConnection to a SQL database of your choice in favor of the default duckdb connection provided by neon_db(). This may be valuable in cases where concurrent write access to the database is desired. ([#39]).zip file packaging in favor of requests to individual files. ([#34])neon_download(), neon_index(), neon_read() gain a release argument ([#36]). Release tags associated with each file are recorded in the database, but database functions neon_store() and neon_table() do not directly filter by release tag since the database holds all current data.neon_download() now creates and maintains a ‘manifest’ tracking the release tag associated with each file by content hash.neon_index() gains a release column, as well as displaying NEON’s md5 (non-AOP data) or crc32 (AOP only) hashes recorded in the manifest. Note: With the .h5.gz files we record the hash of the compressed file even though we don’t keep the .gz version around, which is a bit of a slight-of-hand. This means that consecutive calls to neon_download() will no longer perform any downloads whenever the data remains unchanged.neon_db() handle multiple connections betterneon_db_dir(). Note that in multi-user environments, users may prefer to share a file store but utilize separate databases that they can write to independently.neon_read() gains the argument keep_filename, to always add a column with the filename of the original source data. Filenames may contain important metadata (such as siteID) that is not always included in the tables themselves.neon_store() (some more)neon_store()neon_store()neon_store(), neon_table(), and neon_db() (see README and docs for examples) [#23]neon_index() defaults to include horizontalPosition and verticalPosition & samplingInterval metadata from filename for sensor data [#11]?neon_readneon_store() [#10]neon_export() and neon_import() for importing/exporting a whole neonstore [#9]neon_read() now parses additional columns into Instrumental Systems (sensor data) by default: DomainID, SiteID, horizontalPosition, verticalPosition, and publicationDate.neonstore now handles this change.neon_read() will now check if a file requested has identical product, site, month, & table names. If it does, then it will use only the more recent timestamp instead of reading the same file in twice.initial release to CRAN