Core outputs (currently) are the TREE_CNS table and derived tables. There's potential for a bit of threading-the-needle between (1) computing derived quantities and handling data cleaning etc within the package and (2) providing the tables and then letting users do that work themselves.
At the stage of of packaging data for remote access - if data are in a database (e.g. duckdb, although I haven't tested this yet), would that present an obstacle to someone who has the FIADB and wants to do something novel/specific by linking the TREE_CNS table with surveys? This may be a reason to make source tables openly available as well (already planned).
Also: Continue to think/adjust around which FIA cols (e.g. a survey or cycle identifier) to include in the ForestTIME tables to facilitate interoperability for seasoned FIA users.
Core outputs (currently) are the TREE_CNS table and derived tables. There's potential for a bit of threading-the-needle between (1) computing derived quantities and handling data cleaning etc within the package and (2) providing the tables and then letting users do that work themselves.
At the stage of of packaging data for remote access - if data are in a database (e.g. duckdb, although I haven't tested this yet), would that present an obstacle to someone who has the FIADB and wants to do something novel/specific by linking the TREE_CNS table with surveys? This may be a reason to make source tables openly available as well (already planned).
Also: Continue to think/adjust around which FIA cols (e.g. a survey or cycle identifier) to include in the ForestTIME tables to facilitate interoperability for seasoned FIA users.