# Presentation: 454419

## 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

- Same link to the data mapunit

- Mapunit Name,
- DMU Description,
- & Component Name
- all have the -osd
- extension to make
- them unique

## 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, 

- 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 

- 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 

- 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 

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

## Provided diagnostic

- features as
- appropriate

- 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.

## Entered moisture class. This was not

- populated during conversion
- and needs to be for interp generation.

## Stripped out all stored interps and 

- 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

## Used Dr. Pam Thomas guide

- ECEC and CEC according to:
- mineralogy
- organic matter
- Clay %

## Check to see if OM for “A” horizon agrees with RIC for

- the series. I may have applied the range used
- in standard horizon data (A horizon-OSD). E, B, and C
- horizons all have 0.0-0.25-0.5 entries.

## If you need to change the organic matter

- for your component, make sure you also have
- total clay entered, and use
- these reports to generate a new set of
- CEC7 & ECEC data
- for your component based on the
- appropriate mineralogy.

## Kw and Kf should be appropriate

- for the “A” horizons, but the other layers
- will need to be edited by you for your RV
- texture.

## If there are rock fragments, make sure that if you 

- If there are rock fragments, make sure that if you
- change something, that the horizon volume fragments
- agree with the >10, 3-10, and #10. “Most” standardized data
- is rounded to nearest multiple of 5.

## If you change rock fragment volumes, you will also 

- If you change rock fragment volumes, you will also
- affect the #40 and #200, and may change the >10 and 3-10 inch.
- You may want to run the VanLear
- engine again based on your rock fragments.

## Pedon

- Have not been entering the OSD typical pedon into NASIS to this point
- May do in the future, but time is limited
- Priority is the DMU data
- Entering your typical pedons for your own components is more important

## Limitations of these DMUs

- No or little interpretive data, such as yields, capability, hydric limitation, HEL ranking, etc
- Did not reference existing lab data. Relied on standard guide sheets.
- Most of our old SIR data was not related to lab data anyways (not a true statement for all)

## Helpful hints

- You might want to do the agronomic interpretive data at the end of your project for the full legend so that you consistently apply your state guidelines
- Follow the MO14 NASIS checklist to insure that everything is populated appropriately
- This includes text notes that you will need to develop per guidelines

## Helpful hints

- If you use a query to load an *-OSD DMU that also loads correlation, deselect the “legend” while you work. Having it in your possession while you work “locks” others out of the legend and does not allow them to create a correlation. When you are ready to do any legend/correlation activities of your own, do a “load related”  “correlation” for your DMU. (This hint meant mainly for MO staff)

## Helpful hints

- We are applying the old SIR principle of layers versus horizons.  You may need to split layers for your purposes, or even create new layers.  This is particularly true if you need to add transition horizons that have a different RIC than the major horizons.

## Helpful hints

- Realize that many surface layers converted from SSSD included “E”, “BE”, or “BA” horizons with the “A” horizon.  These horizons have different organic matter content than the A horizon and should now be separated.

## Helpful hints

- Work with your SDQS to insure that appropriate text notes are added. Reference the master MO14 NASIS checklist for text notes that are required or optional and who is responsible for the note.