You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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)
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.
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.The text was updated successfully, but these errors were encountered: