The standardized legend and its mapunit table

Working on your NASIS data in conjunction with a standardized OSD component prepared by your SDQS(4/16/2002 - osd dmu tutorial)

The standardized legend and its mapunit table All names have the -OSD extension Status is provisional or “correlated” when ready

The standardized OSD data has the same structure as other data Mapunit Name, DMU Description, & Component Name all have the -osd extension to make them unique Same link to the data mapunit

Data Mapunit & Component DMU and Component names also have the -OSD extension

Selecting a query You can always query for your entire legend and a full set of data mapunits.

To load less data while you work, use a query by component that can also download area and correlation which are needed to run most reports. Load a component from your survey with this query.

Select target tables Select: Data Mapunit, Area, & Correlation (you could select component in place of dmu)

Enter query parameters for your own dmu/component Area name=your county with standard 2 letter state abbreviation (for your working legend) Component name = component name

Using the same query, enter query parameters for the standardized dmu/component To query for a standardized OSD DMU: Area Name = osd Component name has -osd extension

These are your selected legends and map units

These are your selected data mapunits

These are your selected components

More than one standardized component? Sometimes there may be more than one standardized component developed based on OSD concept

Copy and then paste the standardized OSD component into your data mapunit You will have two components with same name at this time

Suggested that you use the standardized component as your base - it’s the “keeper”. The data in the standardized component has been run through NSSH guides

Your component will have some data worth keeping Your component will have interpretive data that you may want to keep. You will want to transfer it to the standardized component manually, cell copy paste, or copy paste.

Your SDQS will provide an MO14 checklist to guide you through the process of verifying and editing the data to apply it to your survey area

Layers and horizons Some of the earlier standardized horizon table data is done by OSD horizons. Later ones are done as layers. You want to do layers for your data. Edit as needed.

When you are ready, delete your old component and rename the new one Delete Rename by dropping the -osd extension

Some things about what has and has not been done to the standardized OSD component

Most standardized Relative Values (RV) are midpoints. You will need to decide whether to use midpoints, typical pedon values (where appropriate), averages for documented data, or some other value. A team decision for all RVs may be appropriate.

Stripped out DMU crop yields. Promoting yields by component anyway.

Slope is range for the series. RV may be midpoint or, if known, slope given for the typical pedon in OSD. You will edit for this map unit.

Kept data that is related to the soil. You may need to edit it for your survey. Deleted any interpretive data that is phase dependent, such as land capability class & subclass.

Stripped out wildlife data. Phase dependent, but also no longer supported by NCSS.

Calculated classification should be current. If you are correlating a taxadjunct, you will need to edit the classification and recalculate.

Stripped out component crop yields. Phase dependent. Crops differ from state to state.

Left forest and plant data. It is less dependent to phases. You will need to edit accordingly.

Geomorphic Data Provided basic landscape and landform data. You will need to be more specific if desired.

Provided basic three dimensional morphometry. Again, you may need to edit to be more specific.

Provided two dimensional morphometry if appropriate for the landform. In this case, I did not believe it to be appropriate for Flatwoods soil.

Provide slope shape in most all cases. You may need to add/edit to be specific to your component.

Parent Material Provided based on OSD description.

Provided flooding frequency and duration as appropriate. Based on SSSD data.

Provided soil moisture status based on months and depths from old SSSD data.

Nothing in the component restrictions if not appropriate. None in this case.

Complete when appropriate. Probably use TP for RV entries, unless transect data provides enough data for averages.

If series has limitations as far as depth to a diagnostic feature, sometimes used low and high to show the range. RV is midpoint, averages of data, or from TP. Provided diagnostic features as appropriate

Entered moisture class. This was not populated during conversion and needs to be for interp generation.

Stripped out all stored interps and interp restrictions. Hydric soil rating will need to be kept or added back if component is hydric, and this is where that occurs for now.

Hydric soil kind and restriction added.

Added this edit note in Component Text for osd dmu category

Used this edit note to paste a text file of the OSD used.

Horizon Note use of horizon designation column. Some may show “A”, but more recently, have used override to show you what texture this row applies to. Note that the “Master” column is “A”. Did this for A horizons only. Nomenclature used for Designation in other layers.

Horizon Did not provide “A” horizon “groups” of textures. If you want a group with your typical texture as RV, use these rows to bracket all data appropriately and build a group row for your component. I may do some in the future.

Sieves developed using the VanLear engine. RVs set at midpoint in most cases.

Also used the VanLear engine for: • Atterburgs • AASHTO • Unified

Used other guides from Thunderbook for: • Bulk density • AWC • Ksat for paralithic and lithic horizons

Ksat • Data from SSSD has been accepted • You need to check the entries to make sure that fragipans, dense layers, and others limiting layers have correct Ksat data

Accepted converted SIR data • LEP

The standardized legend and its mapunit table