Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal 2: Adding the NASIS Component record ID into the SSURGO component table #3

Open
jneme910 opened this issue Sep 30, 2017 · 5 comments

Comments

@jneme910
Copy link
Member

jneme910 commented Sep 30, 2017

Overview

We are proposing that the NASIS component record ID be added to the SSURGO component table.

Problem

Through disaggregation and advances in raster modeling, the SSD is moving towards the publication of component based maps. Currently, the traditional SSURGO data model is not set up to support these maps because the NASIS component record ID is not exported to the SSRUGO data model. This means that the NASIS components cannot be linked to the SSURGO data. The first critical step in developing component maps is to add the NASIS component record ID to the data model.

The reason the NASIS component record ID is not in SSURGO is because a DMU can be used with more than one map unit, which creates the potential for the same NASIS component record ID to occur more than once in SSURGO. Since every COKEY in SSURGO had to be unique, the NASIS component record IDs could not be used as the COKEY in SSURGO due to the chance they may repeat.

Solution

Add a new field to the SSURGO Component table called NASIS_COIID. This will create the ability to link our NASIS component records to the SSURGO data. We can then begin to design SSURGO to support both component maps and traditional aggregated products.

@jneme910
Copy link
Member Author

The SSURGO cokey needs to be made the same as NASIS cokey.  If this can't be done, we might need a lmapunit cokey sub-table, with a lineage back, that auto populates it.  The second option creates redundancy, but it might be the option that works best.

@jneme910
Copy link
Member Author

jneme910 commented Feb 3, 2020

Another need is to link back to NASIS Component ID is because the need to know with the different vintages of SSURGO (and the randomly generated SSURGO cokeys and mukeys)

@saraya209
Copy link

saraya209 commented Jan 26, 2022

Has this issue been solved? I need to query NASIS by cokey (from SSURGO) any suggestion on how this could be done?

@dylanbeaudette
Copy link
Member

Has this issue been solved? I need to query NASIS by cokey (from SSURGO) any suggestion on how this could be done?

Not yet. What exactly are you trying to do?

@saraya209
Copy link

Has this issue been solved? I need to query NASIS by cokey (from SSURGO) any suggestion on how this could be done?

Not yet. What exactly are you trying to do?

I have a list of components (cokey's) that were subset based on a horizon property (horizon contains "H" major horizon designation instead of A-C). I wanted to find these components on NASIS for detailed analysis.

The only solution I can think of now is to use the mukey (dmuiid) associated with these components and then try to further subset using compname.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants