Proposal 1 : Creating functionality for linking to Component Horizon Data

[jneme910]

Overview

Component horizon records are typically copied and pasted from one component into another. For example, Alpha component is used in 10 project map units. The horizon data will be fully populated for a single Alpha map unit and then copied into the other 9 Alpha components. This is done to ensure that the horizon level data is consistent for same named components within a project.

Problem

Copying and pasting these records is extremely time consuming and the process has to be repeated anytime a small edit is made to the horizon table.

Solution

Set up a system in NASIS that allows a component record to point at the component horizon data of another component record. This can be accomplished by adding a component linage link in the component table. The NASIS user would then have the option to select the desired component in these lineage fields and the component horizon table would be auto populated with the corresponding horizon information. This would only create the option, as it would not be required to link to component horizon data.

1. The linked component horizon data would appear as “grayed out” and the user will not be able to edit this linked data. This would allow a single master set of component horizons to be maintained and all edits would automatically appear in the horizons of the linked components.

2. No component level information or other component child tables will be linked.

3. A new checkbox field will also be added to the component called “Master”. This will allow users to manage the main components.

[jneme910]

Adding a Component Horizon linage link in NASIS to the component table. It would essentially be another column in the component table, whereas a component ID or look up would be used to populate the column. This would then take the component horizon information and populate the component horizon table. The information would be grayed out but also included a linage link. It would allow 1 component to be populated and automatically change the rest of the component horizon. Nothing about the component horizon would be brought in. For example, data from 1 major component horizon data could be used for several minor components that are similar without having to populate it over and over or fixing an error once vs 10 times or how much a specific component is linked.

[jneme910]

Benefits:

1. Makes data more manageable
2. More time to work on the meat an potatoes (major components)
3. Allows the flexibly to populate minor components if that component is the same phase.
4. Serves a benefit with digital soil mapping by maintaining 1 data-set vs. 2 data-sets.

[jneme910]

There are way too many errors in the minor components. If you think about it. It has huge implications even if a component is 3 percent of the map unit. For example, if we are using the “dominant condition” method for a particular interpretation. It could change the map unit rating from Good to Severe or vice versa if the data is bad because of that that 1 component.

Map unit: Alpha-Beta, 0 to 2 percent slopes.

Component	Component Percent	Rating Class	Data Quality
Alpha	49	Good	Good
Beta	47	Severe	Good
Theta	3	Severe	Problem Child, the data should have been rated good but bad data population make it rate bad
Bert	1	Moderate	Good

Dominant Condition would rate this map unit “Severe”.