Return original NASIS record IDs from SDM in relevant SDA queries

[brownag]

Provide access to (new in NASIS 7.4.3) NASIS record ID columns in relevant SDA queries, including:

• "nasiscoiid" in component
• "nasischiid" in chorizon

Here is a shortlist of affected functions:

• fetchSDA()
  • get_component_from_SDA()
  • get_chorizon_from_SDA()
• get_SDA_coecoclass()
• get_SDA_cosurfmorph()
• get_SDA_hydric()
• get_SDA_interpretation()
• get_SDA_pmgroupname()
• get_SDA_property()

For the get_SDA_*() methods this applies only to the aggregation methods that return component or horizon level data, e.g. dominant component, and "none" aggregations

These new columns can be added at any time, but will not be very useful until after the Oct. 1, 2025 refresh when the data will appear in these columns.

Many of the current SDA methods are designed to also work on snapshots of the data (i.e. those derived from SSURGO data packages). If using a snapshot we will not have these columns present, so to make sure things continue to work we have a few options:

• Short term solution would be including these columns conditional on the SDA API as the data source (dsn=NULL default).

• An intermediate solution might be able to use an SDA query to amend the tables created from the SSURGO data packages in e.g. createSSURGO(). This wouldn't work offline, and would probably need an argument to toggle this reliance on external API as opposed to local source.

  • This could be implemented as a simple helper function that takes cokey or chkey as input. (Add get_SDA_NASIS_key() #409)

• In the long run the SSURGO data model will be updated. I have discussed with Kyle helping to bring the legacy MS Access templates up to date--my understanding is that backwards compatibility with the templates is a key barrier that keeps SSURGO from being updated to have the newer components of the SDM data model.

[brownag]

I am removing completing this issue from the 2.9.x milestone because the SSURGO data model does not have these columns. The remaining get_SDA functions that are listed here take a dsn argument which can point to a local SSURGO SQLite database or other connection.

Until we have a way to amend an existing SSURGO schema (possibly using get_SDA_NASIS_key() inside createSSURGO, or as a stand-alone method for running on other variants of SQLite databases), I don't think it is worth building in the logic to conditionally add these columns to queries only when running against SDA. I'd like to keep 1:1 parity between the results from various backends wherever possible. fetchSDA() and friends do not support the dsn argument (though they potentially could), and they are common interfaces to the SDA data, so that should cover most use cases.