![](media/image1.jpeg){width="4.245833333333334in"
height="3.1840277777777777in"}

# Pacific Northwest Hydrography Framework Clearinghouse User Guide

Version 1.1

09/16/04

[**http://hydro.reo.gov/**](http://hydro.reo.gov/)

TABLE OF CONTENTS

[Section 1 -- Introduction and Overview
1](#section-1-introduction-and-overview)

[1.1 What is the Hydrography Framework Clearinghouse?
1](#what-is-the-hydrography-framework-clearinghouse)

[1.2 History Leading to the Development of the Hydrography Clearinghouse
2](#history-leading-to-the-development-of-the-hydrography-clearinghouse)

[1.3 Overview of the Hydrography Framework Clearinghouse
3](#overview-of-the-hydrography-framework-clearinghouse)

[1.3.1 The Hydrography Framework Clearinghouse Structure
3](#the-hydrography-framework-clearinghouse-structure)

[1.3.2 Initial Population of the Clearinghouse
4](#initial-population-of-the-clearinghouse)

[1.3.3 Overview of Clearinghouse Update Transactions
4](#overview-of-clearinghouse-update-transactions)

[1.3.4 Supporting Tools and Documentation
7](#supporting-tools-and-documentation)

[1.3.5 Future Plans 7](#future-plans)

[1.4 Roles and Responsibilities 8](#roles-and-responsibilities)

[1.5 The Importance of Coordination 12](#the-importance-of-coordination)

[Section 2 -- The Hydrography Framework Clearinghouse Data Model
15](#__RefHeading___Toc64884505)

[2.1 Section 2 Outline 15](#section-2-outline)

[2.2 Overview of the Hydrography Framework Clearinghouse Data Model
15](#overview-of-the-hydrography-framework-clearinghouse-data-model)

[2.3 Background Information: Dynamic Segmentation
18](#background-information-dynamic-segmentation)

[2.4 Water Point Layer Description 24](#water-point-layer-description)

[2.5 Watercourse Layer Description 25](#watercourse-layer-description)

[2.6 Water Body Layer Description 28](#water-body-layer-description)

[2.7 Water Body Shoreline Layer Description
30](#water-body-shoreline-layer-description)

[2.8 Event Table Description 32](#event-table-description)

[2.9 Hydrologic Units Description 34](#__RefHeading___Toc64884514)

[Section 3 -- Transactions in the Hydrography Clearinghouse
37](#__RefHeading___Toc64884515)

[3.1 Section 3 Outline 37](#section-3-outline)

[3.2 The Hydrography Layer Editing Process and Clearinghouse Transaction
Overview
37](#the-hydrography-layer-editing-process-and-clearinghouse-transaction-overview)

[3.3 The Check-Out Process for Hydrography Data
41](#the-check-out-process-for-hydrography-data)

[3.4 Checking the Quality of Edited Hydrography Framework Clearinghouse
Data
48](#checking-the-quality-of-edited-hydrography-framework-clearinghouse-data)

[3.5 The Check-In Process 50](#the-check-in-process)

[Section 4 -- The Hydrologic Unit Layers
53](#section-4-the-hydrologic-unit-layers)

[4.1 Section 4 Outline 53](#section-4-outline)

[4.2 Hydrologic Unit Layer Background
53](#hydrologic-unit-layer-background)

[4.3 Hydrologic Unit Boundary Coverages
54](#hydrologic-unit-boundary-coverages)

[4.4 General Hydrologic Unit Editing Guidelines
55](#general-hydrologic-unit-editing-guidelines)

[4.5 Agency Data Steward Review Criteria
56](#agency-data-steward-review-criteria)

[4.6 The Hydrologic Unit Editing Process Overview
57](#the-hydrologic-unit-editing-process-overview)

[4.7 The Hydrologic Unit Layer Editing Process Instructions
58](#the-hydrologic-unit-layer-editing-process-instructions)

[4.8 Sample Hydrologic Unit Boundary Change Request Form
61](#sample-hydrologic-unit-boundary-change-request-form)

[Section 5 -- Editing Hydrography Framework Clearinghouse Layers
62](#section-5-editing-hydrography-framework-clearinghouse-layers)

[5.1 Section 5 Outline 62](#section-5-outline)

[5.2 Maintaining the Hydrography Framework Clearinghouse Data
62](#maintaining-the-hydrography-framework-clearinghouse-data)

[5.3 The Editing Process 63](#the-editing-process)

[5.4 General Editing Protocols 64](#general-editing-protocols)

[5.5 Editing Water Points 65](#editing-water-points)

[5.6 Editing Water Body Shorelines 66](#editing-water-body-shorelines)

[5.7 Editing Water Bodies 68](#editing-water-bodies)

[5.8 Editing Watercourses 69](#editing-watercourses)

[5.9 WC Route Edit Tools (WCEDIT) 79](#wc-route-edit-tools-wcedit)

[5.10 Line Type Update Tool (LTUPDATE)
79](#line-type-update-tool-ltupdate)

[Appendix A -- Guide to WC Route Edit Tools (WCEDIT)
81](#appendix-a-guide-to-wc-route-edit-tools-wcedit)

[Appendix B -- Guide to the Line Type / Centerline Update Tool
97](#appendix-b-guide-to-the-line-type-centerline-update-tool)

[Appendix C -- Training Exercises 103](#appendix-c-training-exercises)

[Exercise A: Editing Water Points 103](#exercise-a-editing-water-points)

[Exercise B: Editing Water Body Shorelines
107](#exercise-b-editing-water-body-shorelines)

[Exercise C: Editing Water Bodies 113](#exercise-c-editing-water-bodies)

[Exercise D: Editing Watercourses using WCEDIT
117](#exercise-d-editing-watercourses-using-wcedit)

[Exercise E: Using LTUPDATE 127](#exercise-e-using-ltupdate)

**PNW Framework Clearinghouse User Guide Revisions**

This section lists all major edits or updates to this user guide,
itemized by revision date.

**9/16/04 Revision**

1.  Added new Save options to the File \> Save table in Appendix A:
    Guide to WC Route Edit Tools (WCEDIT) (page 82).

**5/17/04 Revisions**

1.  Updated the Event Table Default Setup screen in different Training
    Exercises -- Appendix A (page 84), Appendix D -- Exercise D (page
    119), Appendix D -- Exercise D (page 122)

2.  Updated the Effects of Route Editing Tools on Event Table in
    Appendix A (page 92).

PAGE LEFT INTENTIONALLY BLANK

## Section 1 -- Introduction and Overview {#section-1-introduction-and-overview .TOC_REWORK___1}

## 1.1 What is the Hydrography Framework Clearinghouse? {#what-is-the-hydrography-framework-clearinghouse .toc_2}

**Hydrography Framework Clearinghouse Design**

The PNW Hydrography Framework Clearinghouse may be described, in a
general sense, as a central data repository where partners co-manage the
interagency Hydrography and Hydrologic Unit Boundary data layers.
Updates to these data layers are submitted in a controlled environment
and the resulting dataset is available to all for analysis and mapping
purposes.

More specifically, the Hydrography data layers (e.g. watercourses, water
bodies, water points) are managed through the Clearinghouse system, an
ArcSDE Oracle application and associated programs developed by ESRI for
the Framework partnership. Alternatively, the Hydrologic Unit Boundaries
are managed through a coverage-based transactional process that does not
utilize the ESRI-developed Clearinghouse system. All of the Hydrography
and Hydrologic Unit Boundary data layers are included under the umbrella
of the PNW Hydrography Framework Clearinghouse.

The ESRI Corporation provided consulting services in the design of the
Clearinghouse. As the data dictionary and protocols were developed and
agreed upon by the partner agencies, ESRI provided critical input to
ensure that these design elements could then be successfully integrated
into the Clearinghouse system.

As the Clearinghouse system was developed, many issues and priorities
had to be addressed by the respective agencies involved. The list below
contains a number of the topics considered paramount in the
Clearinghouse design:

-   The system must be easy to use in order to minimize resources needed
    to maintain it. The process for data stewards to submit and verify
    updates must not adversely impact existing agency priorities and
    workloads.

-   The Clearinghouse system must be able to support multiple scales.
    The goal is to develop an active repository for the best available
    data, as it is being developed for specific areas.

-   Updates to the water courses (e.g. streams), water bodies (e.g.
    lakes), water points (e.g. springs) and hydrologic unit boundaries
    (e.g. watersheds) will be controlled by the Clearinghouse
    Administrator (see section 1.4).

-   The Clearinghouse must collaborate with existing agency hydrography
    systems. Most agencies already have systems to track hydrography,
    and the Clearinghouse data must be available to these other agency
    hydrography systems.

-   The Clearinghouse must be internet-based providing ease of access to
    all potential users. Updates and requests for new data must be
    easily accessible. Anyone may request hydrography data from the
    Clearinghouse. An ID/Password is required to submit information.

-   The Clearinghouse data must have one central location to reduce
    redundancies, yet still be based on individual field information.
    This functionality will provide the most detailed and up-to-date
    information.

-   The Clearinghouse system must be easily maintained. Significant
    resources are not available for maintaining a complicated or
    intricate system.

-   The basic data model will be the ESRI Dynamic Segmentation system
    for tracking events on a routed coverage.

## 1.2 History Leading to the Development of the Hydrography Clearinghouse {#history-leading-to-the-development-of-the-hydrography-clearinghouse .toc_2}

**Hydrography Framework Clearinghouse Development Process**

**Hydrography**

Early during development, we realized a high level of coordination and
support was necessary at all agency levels for this Clearinghouse to be
successful. To provide adequate input into the Clearinghouse design and
to meet agency business needs, a series of 'Hydro Summits' were
convened. At each summit, State and Federal hydrologists, fisheries
biologists, GIS specialists, and database experts came together to
outline the many functional areas which needed to be addressed for this
Clearinghouse. The 'Hydro Summits' began in 1999 and continued for the
ensuing year. A number of conclusions and products were developed at
these summits and these provide the foundation for the Framework
Clearinghouse.

**Hydrologic Units**

There is a nationally recognized set of standards which describe
hydrologic unit boundaries based on defined size and composition
characteristics. These standards are established through the U.S.
Geological Survey (USGS) and the National Resources Conservation Service
(NRCS) at the national level, in coordination with hydrologists from the
Pacific Northwest.

Completing a GIS layer of 5^th^ and 6^th^ Level hydrologic units has
long been a high priority for the PNW. This project has been a high
priority in the Intergovernmental Resource Information Coordinating
Council (IRICC) and Regional Ecosystem Office (REO) work plan approved
by the agency executives.

Development of hydrologic unit boundaries is intrinsically subjective,
yet must be consistent with national standards. The result of this
situation is that most states, forests and districts had developed their
own hydrological unit boundaries. Most boundaries predate and therefore
were inconsistent with the new national standards. None of these
boundaries were coordinated with other development efforts.

In order to complete this project in a timely manner the state and
federal agencies agreed to support a series of workshops to develop a
single set of hydrologic unit boundaries. Hydrologists met to work
through the coordination issues involved in developing 5^th^ and 6^th^
level hydrologic units all at one time.

The REO planned and facilitated these workshops in conjunction with
federal and state agencies. Over 100 hydrologists from all areas of the
3 states participated in these workshops in a 3 week time frame.

The result of these workshops was a course dataset comprised of all
existing boundaries, and new boundaries developed in the workshops.
Funds were then pooled to complete the task, with contributions from
every state and federal agency. A contractor refined the lines and
delivered a draft dataset. These same hydrologists then reviewed and
commented on this draft. The REO coordinated this review and compiled
the resulting comments. The contractor incorporated these comments into
a final product. This resulting coverage was the starting point for
update and maintenance by the Framework partners.

## ![](media/image2.png){width="6.3354330708661415in" height="2.4751968503937007in"}1.3 Overview of the Hydrography Framework Clearinghouse {#overview-of-the-hydrography-framework-clearinghouse .toc_2}

-   Hydrographic features are modeled in five layers:

    -   Hydrologic Units (HU) -- polygon/region coverage to model
        hydrologic unit boundaries

    -   Water Points (WP) -- point coverage with related table to model
        hydrologic features best represented by points (seeps, springs,
        etc.)

    -   Watercourses (WC) -- routed arc coverage with associated event
        tables to model linear hydrologic centerline features (streams,
        canals, pipelines, etc.)

    -   Water Bodies (WB) -- polygon/region coverage to model polygonal
        hydrologic features (lakes, ponds, bays, wet areas, reservoirs,
        etc.)

    -   Water Body Shorelines (WS) -- routed arc coverage with
        associated event tables to model multiple representations of
        water body shorelines (high water shoreline, low water
        shoreline, etc.)

-   1:24,000-scale or better spatial data where available; 1:100,000 or
    better-scale in other areas

-   NAD83 geographic coordinates, double precision

-   A longitude/latitude identifier (LLID) uniquely identifies each
    feature (see the [PNW Hydrography Framework Clearinghouse
    Hydrography Data Dictionary for a definition of LLID)]{.underline}

## 1.3.1 The Hydrography Framework Clearinghouse Structure {#the-hydrography-framework-clearinghouse-structure .toc_3}

The Clearinghouse is based on 'client/server architecture.' It may be
accessed through any Internet connect at:
[http://hydro.reo.gov](http://hydro.reo.gov/). Downloading or querying
of Clearinghouse information is not restricted.

**Server Component**

The database engine supporting the Clearinghouse is Oracle ArcSDE.
ArcGIS 8.x is incorporated to manage the spatial data within the
Clearinghouse. An ArcIMS server is used to display and check out areas
from the Clearinghouse. MO IMS is used to manage transaction ID's.

A series of AML's were developed in order to manage the check out, check
in and QC routines. The Clearinghouse Manager intervenes only when
exceptions occur (faulty data) and when the final merge to the master is
required.

**Client Component**

A java-enabled browser is used for data viewing, check-out, and check-in
operations. Once coverages are checked out, an AML-based client package
is used to manage, QC, and submit updates to the Clearinghouse.

## 1.3.2 Initial Population of the Clearinghouse {#initial-population-of-the-clearinghouse .toc_3}

*Hydrography*

The Clearinghouse is populated incrementally by the OSO as priority
areas have successfully passed through the stream routing and data
integration process steps.

*Hydrologic Unit Boundaries*

The layer is initially populated with 1:24,000-scale boundaries
developed by all federal and state partners in the PNW. This layer is
established in the ESRI Regions format. All boundaries from the 1^st^
level to the 6^th^ level are contained in this coverage. In some areas,
this coverage also includes 7^th^ Level sub-drainages. The design of the
layer allows for 7^th^, 8^th^ and even 9^th^ level hydrological units.
The goal is to track the most refined boundaries where they exist.

## 1.3.3 Overview of Clearinghouse Update Transactions {#overview-of-clearinghouse-update-transactions .toc_3}

**Check out**

Data editors authorized by their agency data steward may check
Hydrography or Hydrologic Unit Boundary data out of the Clearinghouse.
The Check out process differs for Hydrography and Hydrologic Unit
Boundary updates. Tools and procedures have been developed to facilitate
checking out and downloading Clearinghouse data for update. The
Clearinghouse website and Internet Map Site (IMS) also support this
process. Sections 3 and 4 of this guide provides in depth instructions
for checking data for update out of the Clearinghouse.

*Hydrography*

For Hydrography updates, users receive a transaction ID number that is
used by the server to track the various steps of the transaction
process. The editor uses the IMS or submits a polygon to select the area
they wish to update. In order to prevent duplicate updates, the
Clearinghouse system 'locks' the area so that it cannot be checked out
by another editor until the first editors transaction is complete or
cancelled. The Clearinghouse then bundles all hydrography that falls
entirely within the selected area. The surrounding data is also included
in order to ensure edge matching of old to new data. For Hydrography
transactions, this area is bundled as a background coverage. The
Clearinghouse then transfers this dataset to the Clearinghouse FTP site
and notifies the user via email that the data is available for download.

*Hydrologic Unit Boundaries*

For Hydrologic Unit Boundary updates, users download a coverage off of
the hydro website in order to begin the edit process.

**Update**

Editors perform the necessary edits to the Hydrography or Hydrologic
Unit Boundary data layers. There are many ways to perform the edits. The
only requirement is that the edits conform to the Hydrography Framework
data model and follow the editing protocols. Sections 4 and 5 of this
guide provide more in depth discussion of editing tools and techniques.

*Hydrography*

The editor can edit directly in ArcEdit or, for the watercourse layer,
the editor can edit using the WC Route Edit Tools (WCEDIT) available
from the Clearinghouse.

*Hydrologic Unit Boundaries*

The update process is different for the Hydrologic Unit layer due to the
nature of the agreements and national standards. Hydrologic unit
boundaries are based on national protocols. Updates to hydrologic unit
boundaries are the responsibility of Agency Data Stewards. It is
critical that any updates conform to national and regional protocols. In
addition, these Hydrologic Unit Boundaries cross management boundaries
frequently. Frequent updating of Hydrologic Unit Boundaries will impact
neighboring agencies directly, since these boundaries are used for a
variety of other classifications. These range from watershed assessments
projects to land use allocations.

**Quality Control (QC)**

These procedures check the edited layers for errors. Checks are
performed for both structural errors (those that violate the design of
the data model) and for content errors (misrepresentation of a feature
or an attribute value error). Structural errors can be found and
corrected by the Data Maintainer. The Data Steward should ensure that
the layers are free of content errors.

**Check in**

Data layers are checked into the Clearinghouse according to instructions
in Sections 3 and 4. Only the four Hydro coverages or Hydrologic Unit
Boundary coverages are sent back to the Clearinghouse. Background
coverages are not returned to the Clearinghosue.

*Hydrography*

Following QC on the client side, data is transferred back to the
Clearinghouse. The Clearinghouse server performs another QC of the
spatial and event data to ensure that it meets proper protocol and
notifies the editor and other interested users that the submission has
been received. If the data does not pass QC, a report is sent back to
the editor for review and the data will not be posted to the database.

*Hydrologic Unit Boundaries*

The updated Hydrologic Unit Boundaries coverage is provided back to the
Agency Hydro GIS Lead so that it can be incorporated back into the
Clearinghouse coverage.

**Posting Data**

*Hydrography*

Once data has been checked in and passed the QC routines the
clearinghouse administrator will post that data to the database and
'unlock' the area. Once posted, the data is then available to other
users. It is assumed that any peer review needed on the part of other
data stewards in the area was done prior to submitting updates to the
Clearinghouse.

*Hydrologic Units*

Once the data has been checked-in and passed the QC routines, the
Clearinghouse administrator updates the master HU\<date\> polygon
coverage. The administrator then refreshes the Distribution copy of the
HU_BOUNDARY, which includes the eight region subclasses in addition to
the arc and polygon attributes. It is required that any peer review
needed on the part of other data stewards in the area was done prior to
submitting updates to the Clearinghouse. Since 5^th^ Field Hydrologic
Units are used for checking out Hydrography, the checkout layer on the
Clearinghouse website will be updated periodically as the Hydrologic
Unit coverage is updated.

**Email Notification**

For Hydrography Layer updates, the Clearinghouse will send an email
notification when updates have been submitted and posted. This
notification will go to all relevant listed contacts for all hydrologic
units affected by the change. This contact list by hydrologic unit is
maintained via the Hydro Stewards ArcIMS website:

<http://ims.reo.gov/website/hydrostewards>.

## 1.3.4 Supporting Tools and Documentation {#supporting-tools-and-documentation .toc_3}

Documents and tools have been developed to aid users in the development
and update of Hydrography data. These documents and tools were developed
through a combined effort of the State and Federal agencies in the PNW.
They are available from the Clearinghouse website at
[http://hydro.reo.gov/docs.html]{.underline}.

> Documents:

-   Pacific Northwest Hydrography Framework Clearinghouse User Guide

-   Hydrography Data Dictionary

-   Hydrologic Unit Data Dictionary

> Tools:

-   Clearinghouse AML Client Package

-   Route and Event Editing Tools (WCEDIT) -- Helps users in modifying
    existing routes and associated events during updates. For example a
    stream course may change.

-   Stream Routing Tool (SRT) -- conflates existing routes, names and
    unique identifiers from one dataset to another. Creates new routes
    and identifiers, check for line errors, etc.

-   Stream Event and Vector Editor (STEVE)

## 1.3.5 Future Plans {#future-plans .toc_3}

By establishing the Hydrography Framework Clearinghouse, the partners in
the PNW have instituted data standards and protocols that support this
integrated and co-managed Hydrography dataset. The level of coordination
and cooperation between Clearinghouse federal, state, and other partners
is unmatched. This cohesive partnership anticipates modifications will
be needed in order to meet future information requirements here in the
Pacific Northwest. In support of this, an analysis will be completed to
determine the most suitable approach to migrate the Clearinghouse
dataset to ESRI's geodatabase model. The USGS "NHD Geodatabase" and
"ESRI Arc Hydro" models will be evaluated within the context of the
emerging FGDC Hydrography content standard. Migration of the
Clearinghouse application and data format to meet future needs will be
guided by the Theme Management Board whose role is described in Section
1.5.

## 1.4 Roles and Responsibilities {#roles-and-responsibilities .toc_2}

**Introduction**

This section is intended to specify the major roles and responsibilities
that are required for successful management of the Clearinghouse. In
many cases, the roles may be fulfilled by more than one organization or
by different organizations at different levels of geography or
jurisdiction within the region.

Identified roles include Agency Data Steward, Local Data Steward, Area
Data Manager, Hydrography Theme Management Board, Clearinghouse
Administrator, Technical Advisory Committee, and Executive
Guidance/Sponsor. Also, the additional role of "Other Interested Users"
is referenced in the document. These are individuals who may register
with the Clearinghouse Administrator to receive email notification when
updates are posted to the Clearinghouse.

**Role #1: Agency Data Steward**

Definition: The Hydrography Agency Data Steward has ultimate
responsibility for all aspects of Hydrography data production and
maintenance for their organization. The Agency Data Steward enables
Local Data Stewards and/or their data editors to locally coordinate and
manage geospatial data and metadata production.

Responsibilities:

-   Manages creation and maintenance of Hydrography data/metadata within
    own organization.

-   Ensures organization follows agreed-upon Clearinghouse data
    standards, protocols, and processes for providing data/metadata to
    the Clearinghouse.

-   Communicates with participating partner organizations on planned
    data updates and maintenance and coordinates with other Agency Data
    Stewards to eliminate redundant and/or competing
    production/maintenance efforts.

-   Coordinates with other Clearinghouse partners to ensure consistency
    in the implementation of data update standards and protocols.

-   Promotes participation in the Clearinghouse.

-   Encourages new data partnerships.

-   Serves as organization's representative on the Theme Management
    Board.

-   Responsible for requesting issuance of security user ID's from
    Clearinghouse Administrator.

-   Responsible for notifying Clearinghouse Administrator when access
    for obsolete user ID's should be removed

**Role #2: Local Data Steward**

Definition: The Local Data Steward is responsible for all aspects of
Hydrography data production and maintenance for their local
jurisdictional area. The Local Data Steward either completes the work or
enables their data editors to coordinate geospatial data and metadata
production. In addition, Local Data Stewards responsibility is assigned
at the 5th field watershed level.

Responsibilities:

-   Creates and maintain Hydrography data/metadata within agreed-upon
    areas of responsibility.

-   Follows agreed-upon Clearinghouse data standards, protocols, and
    processes for providing data/metadata to the Clearinghouse.

-   Communicates with other local data stewards in adjoining areas of
    responsibility on planned data updates and maintenance.

-   Coordinates data production/maintenance activities within own
    organization and with Local Data Stewards in other partner
    agencies/groups.

-   Encourages new data partnerships.

-   Requests that obsolete user ID's be removed from Clearinghouse.

-   Requests issuance of security user ID for new editors.

**Role #3: Area Data Manager**

Definition: The Area Data Manager is the lead contact and coordinator
for data/metadata updates to the Clearinghouse within a given geography
or area of responsibility. Area Data Manager responsibility is assigned
at the 5th field watershed level. The Area Data Manager is responsible
for coordinating maintenance activities within the defined area. They
either approve partner organizations to have direct update access to the
Clearinghouse or they receive updates and integrate them for submittal
to the Clearinghouse. This is a role that may be implemented where Local
Data Stewards feel the need to assign coordination responsibilities to a
single individual.

Responsibilities:

-   Provides Clearinghouse data/metadata standards and protocols for
    Agency Data Stewards and editors to follow.

-   Ensures partner organizations follow agreed-upon Clearinghouse data
    standards, protocols, and processes for providing data/metadata to
    the Clearinghouse for their areas of responsibility.

-   Serves as lead contact and coordinates all updates to the
    Clearinghouse for a given geography or area of responsibility.

-   Conducts data integration from Local Data Steward and editor
    contributions, as needed, and submit to the Clearinghouse.

-   Encourages new data partnerships for the Clearinghouse.

-   Coordinates with other Area Data Managers to ensure consistency in
    the implementation of data update standards and protocols.

-   Develops partnership agreements for their area of responsibility.

-   Coordinates resolution of conflicts in data updates for their area
    of responsibility.

**Role #4: Hydrography Theme Management Board**

Definition: The Hydrography Theme Management Board (Board) provides an
important leadership role for the Clearinghouse. It consists of Agency
Data Stewards. Each organization has a seat on this Board. A chairperson
will be appointed by the Board.

This Board ensures data consistency, coordination and protocol
implementation for the Clearinghouse. It ensures consistency across the
state(s) for data integration and submission to the Clearinghouse
following agreed-upon protocols for communication and coordination. The
Board resolves conflicts and issues that are brought forward by the Area
Data Managers or the Clearinghouse Administrator that cannot be resolved
at a lower level or that impact the entire Clearinghouse.

Responsibilities:

-   Appoints a chairperson for the Board.

-   Establishes meeting schedule and protocols.

-   Ensures consistency in all aspects of the Clearinghouse
    implementation of Hydrography data (e.g. guidance on Hydrography
    stream densification, required verses recommended attributes).

-   Resolves conflicts and issues that are brought before the board.

-   Coordinates requirements for additional Clearinghouse data
    development and functionality.

-   Establishes review requirements and procedures for Hydrography
    edits.

**Role #5: Hydrography Framework Clearinghouse Administrator**

Definition: The Clearinghouse Administrator provides a variety of
functions related to administrative oversight for the Clearinghouse. Key
responsibilities include the following:

Responsibilities:

-   Maintains appropriate links to Clearinghouse partner websites.

-   Provides Clearinghouse help desk/training assistance.

-   Provides geographically referenced, up-to-date contact information
    for Agency Data Stewards, Local Data Stewards, and Area Data
    Managers.

-   Provides public distribution of regionally integrated Clearinghouse
    data and associated metadata according to agreed-upon standards and
    protocols.

-   Implements appropriate system security measures and control
    Clearinghouse database update access.

-   Issues User-IDs to Agency Data Stewards, Local Data Stewards, Area
    Data Managers, and approved editors within partnering organizations.

-   Notifies Agency Data Stewards, Local Data Stewards, , Area Data
    Managers, and editors of any system down time and expected recovery
    time.

-   Provides email notification to Agency Data Stewards, Local Data
    Stewards, Area Managers, and editors when updates have been posted
    to the Clearinghouse.

-   Provides email notification to broader group of individuals known as
    "Interested Parties" when updates have been posted to the
    Clearinghouse.

-   Provides a front-end Website Use Agreement to the Clearinghouse data
    application that includes a disclaimer and information on
    appropriate use.

-   Coordinates development or purchase of new or additional
    software/hardware when needed to meet the needs of Clearinghouse
    partners and users.

-   Provides hardware/software infrastructure maintenance and upgrades
    for the Clearinghouse.

-   Provides system/network administration for the Clearinghouse.

-   Adheres to agreed upon Clearinghouse decision-making process.

**Role #6: Technical Advisory Committee**

Definition: The Technical Advisory Committee (TAC) consists of appointed
technical experts in systems, networks, and Hydrography data
implementation. The TAC resolves technical issues that impact the
Clearinghouse with respect to data quality, technical standards,
application requirements, procedures, and protocols for data
maintenance. The TAC committee provides technical recommendations to the
Agency Data Stewards, Area Data Managers, Hydrography Theme Management
Board, and the Clearinghouse Administrator.

Responsibilities:

-   Defines statewide (interstate) technical editing process/protocols.

-   Defines security requirements for Clearinghouse database.

-   Develops/maintains procedures for posting data to the Clearinghouse.

-   Develops system network technical administration procedures.

-   Identifies/develops tools for data integration including quality
    control/assurance.

-   Provides support for application (or tool) enhancements.

-   Develops procedures for implementing data requirements and
    functionality.

-   Identifies additional hardware/software requirements.

**Role #7: Executive Guidance/Sponsors**

Definition: The Executive Guidance Sponsors role is comprised of
advocates within each partner organization. Sponsors provide
organizational leadership, policy direction, and oversight from the
perspective of their organization. They have a vested interest in the
successful development and maintenance of the Clearinghouse and are
committed to providing an appropriate level of support for its success.
Sponsors normally have decision authority (at the management level) and
approve organizational and funding resources to support the
Clearinghouse based on recommendations from the Theme Management Board.

Responsibilities:

-   Provides necessary funding/resources.

-   Provides oversight.

-   Serves as advocate for Clearinghouse.

-   Eliminates obstacles to success of Clearinghouse.

-   Provides policy direction.

-   Identifies appropriate decision making process.

**Conclusion**

This section provides information on the major roles, responsibilities,
and guidelines involved in the successful development and management of
the Clearinghouse. It is important to remember that these roles may be
fulfilled by more than one organization or by different organizations at
different levels of geography or jurisdiction within the region. This is
intended to be a living document that evolves and improves as experience
is gained in the successful operation of the Clearinghouse. It is clear
that coordination among the different roles will be paramount to the
success of the Clearinghouse.

## 1.5 The Importance of Coordination {#the-importance-of-coordination .toc_2}

The Hydrography Framework datasets are shared by many organizations.
Clearinghouse users should remember to use caution when making updates.
The goal of an edit is to improve the representation of the feature
while not degrading the quality of any attribute data already associated
with that feature. Given that other associated databases may exist in
the interagency environment, it is extremely important that edits not
result in the displacement of those attributes or the removal of
features used by other agencies. Editing requires cooperation and
coordination with other partners. If all parties involved are not
attentive, someone else's attribute information may be invalidated with
your edits!

One of the biggest problems with coordination between agencies is which
agency or which person to contact at that agency if a question does
arise. A good source of agency steward and ownership information is the
Hydrology Stewardship Program website located at:

[http://ims.reo.gov/website/hydrostewards.](http://ims.reo.gov/website/hydrostewards. T%0D)
This Hydrography Stewards hyperlink is available from the Roles and
Responsibilities section on the home page of the Clearinghouse website.

By accessing this website you can zoom in on the area of the state you
are interested in and identify responsible agencies by watershed using
the identify tool ![](media/image3.png){width="0.19027777777777777in"
height="0.19027777777777777in"} or hyperlink tool
![](media/image4.png){width="0.14930555555555555in"
height="0.14930555555555555in"} .

![](media/image5.png){width="4.777777777777778in"
height="3.747916666666667in"}

After you see the above page, click on the + magnifying glass
![](media/image6.png){width="0.19027777777777777in"
height="0.16180555555555556in"}and draw a box around a group of
watersheds. As you zoom in further more layers are added to the map.

![](media/image7.png){width="4.826388888888889in"
height="2.5791666666666666in"}

The hyperlink tool ![](media/image4.png){width="0.14930555555555555in"
height="0.14930555555555555in"}can be used to get information about the
interested parties of each watershed. Select this tool and click on a
watershed to display the Hydro and Agency Data Steward information

On the left side of the window, you will see two additional buttons:

![](media/image8.jpeg){width="1.7291666666666667in"
height="2.5520833333333335in"}

The top button (which looks like note paper) is the Steward Request
form. Selecting this button will pop up the Steward Request Form. This
form is used to request changes in the Hydro Stewards or the Area
steward listing for a watershed. All change requests are reviewed by
their Agency Data Steward. If your Agency Data Steward approves this
change, then the Hydro Steward Website will be updated.

The second button is a link to the latest copy of the Clearinghouse
Roles and Responsibilities document (Section 1.5). Since coordination
and cooperation is such a critical component of the Clearinghouse, it is
important that this document be reviewed as to partner's
responsibilities.

THIS PAGE LEFT INTENTIONALLY BLANK

[]{#__RefHeading___Toc64884505 .anchor}Section 2 -- The Hydrography
Framework Clearinghouse Data Model

## 2.1 Section 2 Outline {#section-2-outline .toc_2}

> 2.1 Section 2 Goals and Outline
>
> 2.2 Overview of the Hydrography Framework Clearinghouse physical data
> model
>
> 2.3 Background information: dynamic segmentation and regions
>
> 2.4 Water Points (WP)
>
> 2.5 Watercourses (WC)
>
> 2.6 Water Bodies (WB)
>
> 2.7 Water Shorelines (WS)
>
> 2.8 Event Tables

2.9 Hydrologic Units (HU)

## 2.2 Overview of the Hydrography Framework Clearinghouse Data Model {#overview-of-the-hydrography-framework-clearinghouse-data-model .toc_2}

![](media/image9.png)

**General Facts**

-   The desired source scale for all layer acquisition is 1:24,000 or
    better.

-   All data is stored in NAD83 geographic coordinates, double
    precision.

-   Hydrographic features are modeled in four layers:

    -   Water Points (WP) -- point coverage with related table to model
        hydrologic features best represented by points (seeps, springs,
        etc.)

    -   Watercourses (WC) -- routed arc coverage with associated event
        tables to model linear hydrologic centerline features (streams,
        canals, pipelines, etc.)

    -   Water Bodies (WB) -- polygon coverage with a region to model
        polygonal hydrologic features (lakes, ponds, bays, wet areas,
        reservoirs, etc.)

    -   Water Body Shorelines (WS) -- routed arc coverage with
        associated event tables modeling multiple representations of
        water body shorelines (high water shoreline, low water
        shoreline, etc.)

    ```{=html}
    <!-- -->
    ```
    -   Hydrologic Unit features are modeled in the Hydrologic Unit
        Layer.

        -   Hydrologic Units (HU) -- polygon/region coverage to model
            hydrologic unit boundaries.

**Hydrography**

-   A longitude/latitude identifier (LLID) uniquely identifies each
    hydrographic feature in the model. This 13-character identifier is
    composed of the concatenated decimal degree longitude and latitude
    of the feature. The identifier is unique within each layer but there
    is no requirement that it be unique between the layers.

-   Each feature has the following attributes:

    -   A unique LLID identifier.

    -   A generalized classification of the hydrographic feature type
        (e.g. stream, lake etc.)

    -   A classification of the type of cartographic element. This is a
        more detailed classification of the feature useful for mapping
        or more detailed database queries.

    -   A classification of seasonal, or periodic behavior of the water
        feature (e.g. perennial, intermittent or ephemeral)

    -   A robust set of attributes that describe the history of spatial
        edits to each feature.

**Hydrologic Units**

-   Each Hydrologic Unit will be identified with a unique identifier.
    These numbers are sequentially derived within the parent boundary.
    The identifier length of a boundary is dependent on its level.

These identifiers are based upon the "***LEVEL1***" through
"***LEVEL8***" attribute items shown below. This protocol follows
national standards as identified at www.usgs.gov.

  ------------------- --------------------- --------------------- ---------------------- -------------------- -------------------- ------------------------
  [ITEM               [LEVEL]{.underline}   [WIDTH]{.underline}   [OUTPUT]{.underline}   [TYPE]{.underline}   [NDEC]{.underline}   [EXAMPLES]{.underline}
  NAME]{.underline}                                                                                                                

  REGION                                    2                     2                      C                                         17

  SUBREGION           2                     4                     4                      C                                         1710

  BASIN               3                     6                     6                      C                                         171002

  SUBBASIN            4                     8                     8                      C                                         17100203

  WATERSHED           5                     10                    10                     C                                         1710020309

  SUBWATER            6                     12                    12                     C                                         171002030902

  DRAINAGE            7                     14                    14                     C                                         17100203090203

  SUBDRAIN            8                     16                    16                     C                                         17100203090203XX
  ------------------- --------------------- --------------------- ---------------------- -------------------- -------------------- ------------------------

-   Each unit will be uniquely named and attributed with the following
    general description of each attribute type:

```{=html}
<!-- -->
```
-   Hydrologic Unit Type -- A standard general description of the unit.
    For example Frontal, remnant, facial, etc.

-   Hydrologic Unit Modifications: Standard list of physical
    modifications constructed within the unit. For example: irrigation
    ditch, storm water canal, barge canal, etc.

-   Historic Unit Number -- When a change is made in the number, used
    for tracking old number to new.

-   Downstream Hydrologic Unit -- Unit number of the downstream
    watershed receiving the majority of downstream flow.

-   Encompassing States -- All states the hydrologic unit falls within.

-   Feature Level Metadata -- Data describing the source date and
    agency.

## 2.3 Background Information: Dynamic Segmentation {#background-information-dynamic-segmentation .toc_2}

![](media/image10.png){width="5.833333333333333in" height="2.34375in"}

**Overview**

Both the watercourse and water shoreline layers are routed; that is,
they employ a data design called dynamic segmentation. Dynamic
segmentation is a method of modeling linear spatial information. A
dynamic segmentation model consists of a ***route system*** and
associated ***event tables***. A route system is a collection of
***routes*** defined by an ordered series of arcs in a coverage. Each
location on a route is described by its relationship to the beginning of
the route. Event tables contain attributes associated with a route
system. Each event, or attribute, is tied to a specific place on a
specific route by describing the location of the event in relationship
to the beginning of a specific route.

The dynamic segmentation data model offers advantages over a traditional
arc-node data model when modeling a linear feature with many attributes,
like watercourses. With dynamic segmentation, attributes are stored as
events, and not as arc attributes, so arcs do not need to be split when
attributes change. Dynamic segmentation also facilitates sharing a
common coverage because each user of the coverage can develop as many
different event tables as they need. Attribute editing can be done
independently of spatial editing and can be done outside the Arc/Info
environment.

**Routes And Sections**

***Routes*** are the backbone of the dynamic segmentation data model.
Routes represent linear features and are defined over existing arcs in a
coverage. Each route consists of a spatial definition (the underlying
arcs) and measures (or indexes) that describe the distance along the
route. The indexes are ordered, thus implying direction for the route.
Every location on a route can be identified using the route's indexes.

![](media/image11.png){width="4.1097222222222225in"
height="1.6333333333333333in"}

A ***route system*** is a collection of routes with a common theme and
measurement or indexing system. Each route system is defined using two
tables: the route attribute table (RAT) and the section table (SEC).
Each route system contains one RAT and one SEC.

The ***Route Attribute Table*** (RAT) identifies each route in a route
system. There is one record in the RAT for each route. In order to link
to event tables, a *route key item* is commonly in a RAT. The *route key
item* is defined by the user and is unique for each route. An event
table uses the *route key item* in order to identify a specific route.
Routes are linked to underlying arcs through the section table. Routes
cannot exist without sections.

  ----------------------------------- ------------------------- ------------------------
  **RAT items**                                                 
  *(\<cover\>.rat\<route-system\>)*                             

  *(\<route-system\>#)*               *(\<route-system\>-ID)*   *(Route Key Item)*
  ----------------------------------- ------------------------- ------------------------

The ***Section Table*** (SEC) links the routes to the arcs. It also
contains the route measures or indexes. Sections keep track of which
arcs belong to which routes, what direction the route traverses the arc,
and the measuring or indexing system defined for the route. The
routelink# item in the SEC is equal to the \<route system\># item in the
RAT and links the routes to the sections. The arclink# item in the SEC
is equal to the \<cover\># in the AAT and links the sections to the
arcs.

  ----------------------------------- -------------- ----------- ----------- ------------ ------------ ----------------------- -------------------------
  **SEC items**                                                                                                                
  *(\<cover\>.sec\<route-system\>)*                                                                                            

  **RouteLink#**                      **ArcLink#**   **F-Pos**   **T-Pos**   **F-Meas**   **T-Meas**   *(\<route-system\>#)*   *(\<route-system\>-ID)*
  ----------------------------------- -------------- ----------- ----------- ------------ ------------ ----------------------- -------------------------

**Event Tables**

An ***event*** is an attribute that describes a segment of a route or a
specific location on a route. Events are stored separate from the routed
coverage in an ***event table***. Events are NOT part of the coverage;
they are not features. Events are located on a route using the *route
key item* and the route measures or indexes.

An event table must contain an ***event key item*** and a measure or
index location. The *event key item* is identical to the *route key
item* in a RAT and identifies on which route the event occurs. The
measure or index item(s) describe where on the route the event occurs.

Events are related to routes in Arc/Info by establishing an event
source. An event source must be established before events can be
displayed, queried, or used in Arc/Info.

There are 3 types of events: (1) discontinuous linear, (2) continuous
linear, and (3) point.

![](media/image12.png){width="2.0805555555555557in"
height="0.8166666666666667in"}
![](media/image13.png){width="2.0694444444444446in"
height="0.8076388888888889in"}
![](media/image14.png){width="1.9902777777777778in"
height="0.7833333333333333in"}

Discontinuous Linear Continuous Linear Point

  --------------- ------------------- --------------------------------- ---------------
  ***Event        ***Description***   ***Measure Items***               ***Example***
  Type***                                                               

  Discontinuous   Use with linear     Two measure items (typically      stream reach
  Linear Events   attributes when     called "from" and "to"),          
                  there are gaps in   describing where the event begins 
                  the data or where   and ends.                         
                  events overlap.                                       

  Continuous      Use with linear     One measure item (typically       stream order
  Linear Events   attributes when     called "to"), describing where    
                  there are no gaps   the attribute changes. Events are 
                  in the data and     assumed to begin at the beginning 
                  events do not       of the route. "From" measure is   
                  overlap.            implied and is equal to the "to"  
                                      measure of the previous event.    

  Point Events    Occurs at a single  One measure item (typically       bridge
                  location (a point)  called "location"), describing    
                  on the route.       the location of the event.        
  --------------- ------------------- --------------------------------- ---------------

For more information on dynamic segmentation, [ARC/INFO on-line help,
Working with Linear Features, Dynamic Segmentation]{.underline}.

**The Dynamic Segmentation Data Model**

+------------------------+-----------+----------+---------------------+
| #### surface.          |           |          |                     |
| evt *(Event Database)* |           |          |                     |
+------------------------+-----------+----------+---------------------+
| **Stream_Name**        | **From**  | **To**   | **Stream_Class**    |
|                        |           |          |                     |
| *(Event Key Item)*     |           |          | *(Attributes)*      |
+------------------------+-----------+----------+---------------------+

+----------------------+------------------------+---------------------+
| **                   |                        |                     |
| streams.ratstreams** |                        |                     |
| *(\<cover\>.r        |                        |                     |
| at\<route-system\>)* |                        |                     |
+----------------------+------------------------+---------------------+
| **stream#**          | **stream-ID**          | **Stream_Name**     |
|                      |                        |                     |
| *                    | *                      | *(Route Key Item)*  |
| (\<route-system\>#)* | (\<route-system\>-ID)* |                     |
+----------------------+------------------------+---------------------+

+---------+-------+---+----+----+----+-------------+---------------+
| **Strea |       |   |    |    |    |             |               |
| m.secst |       |   |    |    |    |             |               |
| reams** |       |   |    |    |    |             |               |
| *(\<c   |       |   |    |    |    |             |               |
| over\>. |       |   |    |    |    |             |               |
| sec\<ro |       |   |    |    |    |             |               |
| ute-sys |       |   |    |    |    |             |               |
| tem\>)* |       |   |    |    |    |             |               |
+---------+-------+---+----+----+----+-------------+---------------+
| **Route | **    | * | *  | ** | ** | **stream#** | **stream-ID** |
| Link#** | ArcLi | * | *T | F- | T- |             |               |
|         | nk#** | F | -P | Me | Me | *(\<route-  | *(\<route-    |
|         |       | - | os | as | as | system\>#)* | system\>-ID)* |
|         |       | P | ** | ** | ** |             |               |
|         |       | o |    |    |    |             |               |
|         |       | s |    |    |    |             |               |
|         |       | * |    |    |    |             |               |
|         |       | * |    |    |    |             |               |
+---------+-------+---+----+----+----+-------------+---------------+

+----------+------------+------------+---------+---------+-----------+
| **stre   |            |            |         | ####  A |           |
| am.aat** |            |            |         | rc File |           |
| *        |            |            |         |         |           |
| (\<cover |            |            |         |         |           |
| \>.aat)* |            |            |         |         |           |
+----------+------------+------------+---------+---------+-----------+
| **s      | **s        | *(At       |         | **st    | *Coo      |
| tream#** | tream-ID** | tributes)* |         | ream#** | rdinates* |
|          |            |            |         |         |           |
| *(\<co   | *(\<co     |            |         | *\<co   |           |
| ver\>#)* | ver\>-ID)* |            |         | ver\>#* |           |
+----------+------------+------------+---------+---------+-----------+

In this example, the coverage is called *streams* and an event table
called *surface.evt*.

The *streams* coverage contains arc features. Each arc contains a record
in the arc attribute table (AAT).

The coordinates of the arcs are stored in the Arc File.

The *streams* coverage also contains a route system called *streams*.
Each route in the *streams* route system contains a record in the route
attribute table (RAT). The route attribute table is linked to the arc
attribute table and the Arc File through the section table (SEC). The
routelink# item in the section table points to the internal route number
(\<route-system\>#) in the route attribute table. Similarly, the
arclink# item in the section table points to the internal arc number
(\<cover\>#) in the arc attribute table. The F-Pos and T-Pos items in
the section table define the start and end positions of the section,
defined as a percentage of the arc. Each section of a route contains a
record in the section table.

**A Simple Example Using Two Streams**

+----------------------------------+---+----+---+----+----+----+----+
| #####                            | * |    |   |    |    |    |    |
| ### ARCS**: The coverage is call | * |    |   |    |    |    |    |
| ed streams. There are 4 arcs. Hi | A |    |   |    |    |    |    |
| ghlighted records are the arcs** | r |    |   |    |    |    |    |
|                                  | c |    |   |    |    |    |    |
| underlying route 1               | A |    |   |    |    |    |    |
|                                  | t |    |   |    |    |    |    |
| (Main Stream).                   | t |    |   |    |    |    |    |
|                                  | r |    |   |    |    |    |    |
|                                  | i |    |   |    |    |    |    |
|                                  | b |    |   |    |    |    |    |
|                                  | u |    |   |    |    |    |    |
|                                  | t |    |   |    |    |    |    |
|                                  | e |    |   |    |    |    |    |
|                                  | T |    |   |    |    |    |    |
|                                  | a |    |   |    |    |    |    |
|                                  | b |    |   |    |    |    |    |
|                                  | l |    |   |    |    |    |    |
|                                  | e |    |   |    |    |    |    |
|                                  | ( |    |   |    |    |    |    |
|                                  | s |    |   |    |    |    |    |
|                                  | t |    |   |    |    |    |    |
|                                  | r |    |   |    |    |    |    |
|                                  | e |    |   |    |    |    |    |
|                                  | a |    |   |    |    |    |    |
|                                  | m |    |   |    |    |    |    |
|                                  | s |    |   |    |    |    |    |
|                                  | . |    |   |    |    |    |    |
|                                  | a |    |   |    |    |    |    |
|                                  | a |    |   |    |    |    |    |
|                                  | t |    |   |    |    |    |    |
|                                  | ) |    |   |    |    |    |    |
|                                  | * |    |   |    |    |    |    |
|                                  | * |    |   |    |    |    |    |
+----------------------------------+---+----+---+----+----+----+----+
|                                  | [ | [T | [ | [R | [L | [s | [s |
|                                  | F | no | L | po | en | tr | tr |
|                                  | n | de | p | ly | gt | ea | ea |
|                                  | o | #] | o | #] | h] | ms | ms |
|                                  | d | {. | l | {. | {. | #] | -I |
|                                  | e | un | y | un | un | {. | D] |
|                                  | # | de | # | de | de | un | {. |
|                                  | ] | rl | ] | rl | rl | de | un |
|                                  | { | in | { | in | in | rl | de |
|                                  | . | e} | . | e} | e} | in | rl |
|                                  | u |    | u |    |    | e} | in |
|                                  | n |    | n |    |    |    | e} |
|                                  | d |    | d |    |    |    |    |
|                                  | e |    | e |    |    |    |    |
|                                  | r |    | r |    |    |    |    |
|                                  | l |    | l |    |    |    |    |
|                                  | i |    | i |    |    |    |    |
|                                  | n |    | n |    |    |    |    |
|                                  | e |    | e |    |    |    |    |
|                                  | } |    | } |    |    |    |    |
+----------------------------------+---+----+---+----+----+----+----+
|                                  | 1 | 2  | 0 | 0  | 21 | 1  | 1  |
|                                  |   |    |   |    | 00 |    |    |
+----------------------------------+---+----+---+----+----+----+----+
|                                  | 3 | 2  | 0 | 0  | 19 | 2  | 2  |
|                                  |   |    |   |    | 00 |    |    |
+----------------------------------+---+----+---+----+----+----+----+
|                                  | 2 | 4  | 0 | 0  | 20 | 3  | 3  |
|                                  |   |    |   |    | 00 |    |    |
+----------------------------------+---+----+---+----+----+----+----+
|                                  | 5 | 2  | 0 | 0  | 18 | 4  | 4  |
|                                  |   |    |   |    | 00 |    |    |
+----------------------------------+---+----+---+----+----+----+----+

+-------------------------------------------+------+-------+----------+
| **[ROUTES]{.underline}:** Route System is | **R  |       |          |
| called *streams*.                         | oute |       |          |
|                                           | A    |       |          |
| There are 2 routes.                       | ttri |       |          |
|                                           | bute |       |          |
| Route 1 (Green Stream)                    | T    |       |          |
|                                           | able |       |          |
| is highlighted.                           | (    |       |          |
|                                           | stre |       |          |
|                                           | ams. |       |          |
|                                           | stre |       |          |
|                                           | amsw |       |          |
|                                           | c)** |       |          |
+-------------------------------------------+------+-------+----------+
|                                           | [s   | [str  | [        |
|                                           | trea | eams- | Stream_N |
|                                           | ms#] | ID]{. | ame]{.un |
|                                           | {.un | under | derline} |
|                                           | derl | line} |          |
|                                           | ine} |       |          |
+-------------------------------------------+------+-------+----------+
|                                           | 1    | 1     | Green    |
|                                           |      |       | Stream   |
+-------------------------------------------+------+-------+----------+
|                                           | 2    | 2     | Blue     |
|                                           |      |       | Stream   |
+-------------------------------------------+------+-------+----------+

+--------+------+------+-----+-----+------+--------+-----------------+
| #####  |      |      |     |     |      |        |                 |
| ### SE |      |      |     |     |      |        |                 |
| CTIONS |      |      |     |     |      |        |                 |
| **: Th |      |      |     |     |      |        |                 |
| e sect |      |      |     |     |      |        |                 |
| ion ta |      |      |     |     |      |        |                 |
| ble li |      |      |     |     |      |        |                 |
| nks th |      |      |     |     |      |        |                 |
| e rout |      |      |     |     |      |        |                 |
| es to  |      |      |     |     |      |        |                 |
| the ar |      |      |     |     |      |        |                 |
| cs. Th |      |      |     |     |      |        |                 |
| e reco |      |      |     |     |      |        |                 |
| rds fo |      |      |     |     |      |        |                 |
| r rout |      |      |     |     |      |        |                 |
| e 1 (G |      |      |     |     |      |        |                 |
| reen S |      |      |     |     |      |        |                 |
| tream) |      |      |     |     |      |        |                 |
|  are h |      |      |     |     |      |        |                 |
| ighlig |      |      |     |     |      |        |                 |
| hted i |      |      |     |     |      |        |                 |
| n the  |      |      |     |     |      |        |                 |
| table  |      |      |     |     |      |        |                 |
| and th |      |      |     |     |      |        |                 |
| e inde |      |      |     |     |      |        |                 |
| xes ar |      |      |     |     |      |        |                 |
| e show |      |      |     |     |      |        |                 |
| n in t |      |      |     |     |      |        |                 |
| he dia |      |      |     |     |      |        |                 |
| gram.  |      |      |     |     |      |        |                 |
| (Route |      |      |     |     |      |        |                 |
| link#  |      |      |     |     |      |        |                 |
| = 1 fo |      |      |     |     |      |        |                 |
| r the  |      |      |     |     |      |        |                 |
| highli |      |      |     |     |      |        |                 |
| ghted  |      |      |     |     |      |        |                 |
| record |      |      |     |     |      |        |                 |
| s.) Th |      |      |     |     |      |        |                 |
| e firs |      |      |     |     |      |        |                 |
| t reco |      |      |     |     |      |        |                 |
| rd is  |      |      |     |     |      |        |                 |
| the fi |      |      |     |     |      |        |                 |
| rst se |      |      |     |     |      |        |                 |
| ction  |      |      |     |     |      |        |                 |
| of rou |      |      |     |     |      |        |                 |
| te 1.  |      |      |     |     |      |        |                 |
| The fi |      |      |     |     |      |        |                 |
| rst se |      |      |     |     |      |        |                 |
| ction  |      |      |     |     |      |        |                 |
| of rou |      |      |     |     |      |        |                 |
| te 1 i |      |      |     |     |      |        |                 |
| s on a |      |      |     |     |      |        |                 |
| rc 1 ( |      |      |     |     |      |        |                 |
| Arclin |      |      |     |     |      |        |                 |
| k# = 1 |      |      |     |     |      |        |                 |
| ). It  |      |      |     |     |      |        |                 |
| begins |      |      |     |     |      |        |                 |
|  at ze |      |      |     |     |      |        |                 |
| ro (F- |      |      |     |     |      |        |                 |
| Meas = |      |      |     |     |      |        |                 |
|  0) an |      |      |     |     |      |        |                 |
| d ends |      |      |     |     |      |        |                 |
|  at 2. |      |      |     |     |      |        |                 |
| 00 (T- |      |      |     |     |      |        |                 |
| Meas = |      |      |     |     |      |        |                 |
|  2.00) |      |      |     |     |      |        |                 |
| . The  |      |      |     |     |      |        |                 |
| second |      |      |     |     |      |        |                 |
|  secti |      |      |     |     |      |        |                 |
| on of  |      |      |     |     |      |        |                 |
| route  |      |      |     |     |      |        |                 |
| 1 is o |      |      |     |     |      |        |                 |
| n arc  |      |      |     |     |      |        |                 |
| 3. (ar |      |      |     |     |      |        |                 |
| clink# |      |      |     |     |      |        |                 |
|  = 3). |      |      |     |     |      |        |                 |
|  It be |      |      |     |     |      |        |                 |
| gins a |      |      |     |     |      |        |                 |
| t 2.00 |      |      |     |     |      |        |                 |
|  (F-Me |      |      |     |     |      |        |                 |
| as = 2 |      |      |     |     |      |        |                 |
| .00) a |      |      |     |     |      |        |                 |
| nd end |      |      |     |     |      |        |                 |
| s at 3 |      |      |     |     |      |        |                 |
| .40 (T |      |      |     |     |      |        |                 |
| -Meas  |      |      |     |     |      |        |                 |
| = 3.40 |      |      |     |     |      |        |                 |
| ). The |      |      |     |     |      |        |                 |
|  secon |      |      |     |     |      |        |                 |
| d sect |      |      |     |     |      |        |                 |
| ion be |      |      |     |     |      |        |                 |
| gins w |      |      |     |     |      |        |                 |
| here t |      |      |     |     |      |        |                 |
| he fir |      |      |     |     |      |        |                 |
| st sec |      |      |     |     |      |        |                 |
| tion e |      |      |     |     |      |        |                 |
| nded.  |      |      |     |     |      |        |                 |
| There  |      |      |     |     |      |        |                 |
| are no |      |      |     |     |      |        |                 |
|  gaps  |      |      |     |     |      |        |                 |
| in the |      |      |     |     |      |        |                 |
|  index |      |      |     |     |      |        |                 |
| es.**  |      |      |     |     |      |        |                 |
+--------+------+------+-----+-----+------+--------+-----------------+
| **S    |      |      |     |     |      |        |                 |
| ection |      |      |     |     |      |        |                 |
| Table  |      |      |     |     |      |        |                 |
| (str   |      |      |     |     |      |        |                 |
| eams.s |      |      |     |     |      |        |                 |
| ecstre |      |      |     |     |      |        |                 |
| ams)** |      |      |     |     |      |        |                 |
+--------+------+------+-----+-----+------+--------+-----------------+
| [Route | [A   | [F-M | [T  | [   | [T-  | [str   | [streams-       |
| link#] | rcli | eas] | -Me | F-P | Pos] | eams#] | ID]{.underline} |
| {.unde | nk#] | {.un | as] | os] | {.un | {.unde |                 |
| rline} | {.un | derl | {.u | {.u | derl | rline} |                 |
|        | derl | ine} | nde | nde | ine} |        |                 |
|        | ine} |      | rli | rli |      |        |                 |
|        |      |      | ne} | ne} |      |        |                 |
+--------+------+------+-----+-----+------+--------+-----------------+
| 1      | 1    | 0.00 | 2   | 0   | 100  | 1      | 1               |
|        |      |      | .00 |     |      |        |                 |
+--------+------+------+-----+-----+------+--------+-----------------+
| 1      | 3    | 2.00 | 3   | 0   | 100  | 2      | 2               |
|        |      |      | .40 |     |      |        |                 |
+--------+------+------+-----+-----+------+--------+-----------------+
| 2      | 4    | 0.00 | 1   | 0   | 100  | 3      | 3               |
|        |      |      | .65 |     |      |        |                 |
+--------+------+------+-----+-----+------+--------+-----------------+
| 2      | 2    | 1.65 | 3   | 100 | 0    | 4      | 4               |
|        |      |      | .10 |     |      |        |                 |
+--------+------+------+-----+-----+------+--------+-----------------+

+-------------------------------------------+--------+-----+----------+
| ######## EVENTS**: This                   | ### P  |     |          |
| is an example of a point event table. It  | othole |     |          |
| contains the location of potholes on Gree |  Event |     |          |
| n and Blue Streams. There are 2 potholes  |  Table |     |          |
| on Green Stream and one on Blue Stream.** |        |     |          |
|                                           |        |     |          |
| The event key item is Stream_Name. This   |        |     |          |
| is also the name of the route key item in |        |     |          |
| the RAT. Tracing back through the RAT and |        |     |          |
| SEC, this event occurs on section 1.      |        |     |          |
| (This event occurs at 1.00 on Green       |        |     |          |
| Stream. From the RAT, Green Stream is     |        |     |          |
| route 1. From the SEC, route 1 is         |        |     |          |
| composed of arcs 1 and 2, with the index  |        |     |          |
| 1.00 occuring on arc 1.) To determine how |        |     |          |
| far along section 1 the event occurs, a   |        |     |          |
| percentage is applied. Section 1 is that  |        |     |          |
| part of route 1 from 0.00 to 2.00. The    |        |     |          |
| event is at 1.00 which is 50% of the way  |        |     |          |
| along section 1. The red star on on route |        |     |          |
| 1 (Green Stream) shows this pothole       |        |     |          |
| event. (Other potholes are shown with     |        |     |          |
| yellow stars),                            |        |     |          |
+-------------------------------------------+--------+-----+----------+
|                                           | [      | [   | ######## |
|                                           | Stream | Loc | # Pothol |
|                                           | _Name] | ati | e Number |
|                                           | {.unde | on] |          |
|                                           | rline} | {.u |          |
|                                           |        | nde |          |
|                                           |        | rli |          |
|                                           |        | ne} |          |
+-------------------------------------------+--------+-----+----------+
|                                           | Green  | 1   | 1        |
|                                           | Stream | .00 |          |
+-------------------------------------------+--------+-----+----------+
|                                           | Green  | 2   | 2        |
|                                           | Stream | .40 |          |
+-------------------------------------------+--------+-----+----------+
|                                           | Blue   | 2   | 3        |
|                                           | Stream | .90 |          |
+-------------------------------------------+--------+-----+----------+

**Background Information: Regions Data Model**

**Overview**

The water body layer (WB) and hydrologic unit (HU) use a regions data
model to represent polygonal water features. Like routes are based on an
underlying arc structure, regions are based on an underlying polygon
structure. Regions are often used to model complex area features that
overlap or contain multiple parts. Unlike polygons, regions can overlap,
be discontiguous, have void areas, have nested features, and support
multiple feature classes per coverage using shared geometry.

Although the regions data model has the ability to store multiple and/or
overlapping polygons in a single region, the Hydrography Framework has
agreed to store each water body as a non-overlapping, single polygon
region. Storing the polygons as regions provides a "safety net" in the
event of overlapping features being inadvertently stored on the server,
which could occur if improperly edgematched data are inserted.
Extracting overlapping features as polygons would result in loss of data
in the overlap area. Extracting overlapping features as regions results
in no data loss since overlaps are permissible, which gives the data
maintainer an opportunity to extract and correct overlapping polygons
without losing data.

Region features are stored in a ***region subclass***. A polygon
coverage can have more than one region subclass. All the subclasses
share the same polygon geometry; think of each as lying in its own plane
above the polygon topology. Each subclass has its own attribute table.

  -------------------------------------- --------------- -------------------------- ----------------------------
  **Region Subclass Attribute Table                                                 
  (PAT)**                                                                           
  *(\<cover\>.pat\<region-subclass\>)*                                              

  **Area**                               **Perimeter**   *(\<region-subclass\>#)*   *(\<region-subclass\>-ID)*
  -------------------------------------- --------------- -------------------------- ----------------------------

There is not a direct link between the region subclass attribute table
and the polygon attribute table because the linking table is stored in
binary format.

For more information on regions, see ARC/INFO on-line help, Regions.

## 2.4 Water Point Layer Description {#water-point-layer-description .toc_2}

![](media/image16.jpeg){width="4.90625in" height="1.5208333333333333in"}

**Quick Facts**

-   Use for Hydrography features most easily represented by a point
    (seeps, springs).

-   Point cover (WP) with related feature history table
    (WP.REL_FTR_HST).

-   Feature history table (WP.REL_FTR_HST) is related in a one-to-one
    relationship. The related item is the LLID field (WP_LLID_NR). Only
    the most recent feature history is maintained.

-   LLID of each feature is based on location of point and is unique
    within the water point layer.

**Description**

*[The Water Point (WP]{.underline})* layer is the repository for
springs, seeps and other hydrographic features with limited spatial
extent (i.e. most easily represented by a point). This layer consists of
a point coverage and a single related table. The related table, the
feature history table (WP.REL_FTR_HST), describes the history of spatial
edits to the feature. The feature history table is related to the water
point attribute table (WP.PAT) through the LLID (WP_LLID_NR) field. This
relationship is one-to-one, meaning that there may be only one record in
the feature history table for each water point; only the most recent
feature history is maintained. Table definitions and attribute value
definitions are available in [PNW Hydrography Framework Clearinghouse
Hydrography Data Dictionary]{.underline} at
<http://hydro.reo.gov/docs.html>.

**Water Points AttributeTable (WP.pat)**

  ------------------- ---------------------------------------------------
  **Event Table       **Event Table Description**
  Name**              

  WP.PAT              Point Attribute Table. Contains LLID, hydrographic
                      feature code, cartographic feature code, and
                      periodicity.

  WP.EVT_FTR_HST      Contains feature history. Related to WP.PAT using
                      LLID.
  ------------------- ---------------------------------------------------

## 2.5 Watercourse Layer Description {#watercourse-layer-description .toc_2}

![](media/image17.jpeg){width="6.49375in"
height="4.204861111111111in"}**Quick Facts**

-   Use for Hydrography feature centerlines (streams, canals).

-   Routed arc coverage with associated event tables. Route system is
    called WC.

    -   Each LLID is a separate route.

    -   Routes are continuous -- no gaps or overlaps.

    -   Routes cannot branch or loop.

    -   Route measures are an indexing scheme for linear referencing,
        not a stored attribute of watercourse length. They begin at zero
        and increase continuously along the length of the route.

    -   Routes point opposite flow direction.

    -   Routes should follow approved 1:100,000-scale stream routes as
        appropriate.

-   Watercourses flowing to the ocean end at the ocean shoreline.

-   Arcs point in direction of flow, routes point opposite flow
    direction.

-   Each arc in the coverage is included in one and only one route.

-   LLID of each feature is based on location of the beginning of the
    route and is unique within the watercourse layer.

-   Event tables are related to the routes using the LLID field. The
    LLID field (WC_LLID_NR) is the route key item in the RAT and the
    event key item in each event table.

-   All event tables are formatted as discontinuous event tables. Each
    has beginning and ending address fields.

-   Line type, feature type, stream flow, and feature history event
    tables:

    -   Continuous events modeled as discontinuous events.

    -   Events in these tables cannot overlap and no gaps are allowed.

    -   Beginning address of the first event on a route must be zero and
        subsequent events on the route must begin where the previous
        event ended.

    -   At least one event must be defined for every watercourse route
        in each table.

    -   Ending address of the last event for each route in each table
        must be either the ending index of the route or 9999, which
        ensures an event extends to the end of a route.

-   GNIS name and RRF number event tables:

    -   Discontinuous events.

    -   Events in these tables [cannot]{.underline} overlap and gaps
        [can]{.underline} occur. Events do not have to occur on every
        route and every part of every route does not have to be included
        in an event.

    -   An ending address of 9999 can be used in these tables.

**Description**

*[The Watercourse (WC]{.underline})* layer consists of stream, canal,
flume, pipeline and other linear hydrographic feature centerlines. Where
these features (especially streams) are represented as double lined
features at the source scale, they are represented in this layer by
their centerline. Streams that flow through water bodies such as lakes
and reservoirs will also be represented by a centerline. This layer has
been modeled to allow for flow modeling. All arcs must point in the
direction of flow.

This layer is routed using the LLID identifier for the watercourse. All
associated attributes are stored as event tables on the LLID routes.
Stream routes are indexed starting from 0 at the mouth of the stream and
continue to increase towards some maximum value at the headwaters.

All route measures are initially calibrated in kilometers to three
decimal places. As these routes are edited, effort is made to keep the
measure value at a given map location from shifting. Over time, the
route measures will approximate kilometers along a watercourse. The
measures are simply an indexing scheme for linear referencing, not a
stored attribute of watercourse length.

There are six event tables associated with the watercourse layer: (1)
GNIS name event table (WC.EVT_NAME), (2) line type event table
(WC.EVT_LN_TYPE), (3) feature type event table (WC.EVT_FTR_TYP), (4)
river reach file (RRF) number event table (WC.EVT_RRF), (5) stream flow
event table (WC.EVT_STRM_FLOW), and (6) feature history event table
(WC.EVT_FTR_HST).

Line type, feature type, stream flow and feature history events are
continuous but for ease of querying, the event tables are formatted as
discontinuous event tables. In each of these tables, each event has a
beginning and ending address; however, the beginning address of the
first event on a route must be zero and subsequent events on the route
must begin where the previous event ended. Events in these tables cannot
overlap. At least one event must be defined in each table for every
watercourse route. Since an event must be defined over every part of
every route in each table, the ending address of the last event for each
route in each table must be either the ending index of the route or
9999. An address of 9999 is used for events that always extend to the
end of the route. This ensures that the event will always extend to the
end of the route, even when the route is edited.

GNIS name and RRF number events are also discontinuous events. Like
feature history events, each event has a beginning and ending address.
However, unlike in the feature history event table, events in these
tables [cannot]{.underline} overlap and gaps [can]{.underline} occur.
Events do not have to occur on every route and every part of every route
does not have to be included in an event. An ending address of 9999 can
be used.

Table definitions and attribute value definitions are available in [PNW
Hydrography Framework Clearinghouse Hydrography Data
Dictionary]{.underline} at <http://hydro.reo.gov/docs.html>.

**Watercourse Event Tables**

  ------------------- ---------------------------------------------------
  **Event Table       **Event Table Description**
  Name**              

  WC.EVT_NAME         Contains GNIS name and number.

  WC.EVT_LN_TYPE      Contains line type code. This is the type of
                      watercourse feature represented. Example: single
                      line segment, line interior to a waterbody

  WC.EVT_FTR_TYPE     Contains hydrographic feature code. Code used to
                      describe hydrographic feature represented.
                      Examples: Stream, ditch, etc ...

  WC.EVT_RRF          Contains River Reach File number used by USEPA and
                      the river reach file segment number and mile number
                      used by WARIS.

  WC.EVT_STRM_FLOW    Contains classification and periodicity of flow.

  WC.EVT_FTR_HST      Contains feature history.
  ------------------- ---------------------------------------------------

## 2.6 Water Body Layer Description {#water-body-layer-description .toc_2}

![](media/image18.jpeg){width="2.7083333333333335in"
height="1.4479166666666667in"}

**Quick Facts**

-   Use for Hydrography features represented as areas (lakes, wet areas,
    bays).

-   Contains one region subclass called WB. All attributes are stored in
    the region subclass table, not in the polygon attribute table.

-   Regions are non-overlapping and non-multipart (i.e. one polygon per
    region).

-   Each water body represented in the water body layer is also
    represented in the water body shoreline layer. The water body
    boundary is the default shoreline.

-   Feature history attributes are stored in the water body shoreline
    layer and not in the water body layer.

-   LLID of each feature is based on location of label point in the
    polygon underlying the water body region feature and is unique
    within the water body layer.

**Description**

*[The Water Body (WB]{.underline})* layer consists of sounds, bays,
lakes, ponds, wet areas, reservoirs, inundation areas, the double lined
portions of streams and other hydrographic features best represented as
areas. Each water body represented in the water body (WB) layer is also
represented in the water body shoreline (WS) layer. The water body
boundary is the default shoreline in the water body shoreline (WS)
layer. For ease of managing these features, they have been modeled as
regions rather than simple polygons. However by agreement, each water
body will be stored as a non-overlapping, non-multi-part region (i.e.
there will be one polygon per region). Water body attributes are stored
in the WB region attribute table (PATWB.) Feature history attributes of
the water body are stored in the water body shoreline (WS) layer and
[not]{.underline} in the water body layer because feature history
attributes, such as data source may change along the shoreline. Note the
only relationship between the water body shoreline (WS) layer and the
water body (WB) layer is the coincident spatial location of the water
body boundary; there is no explicit linking item.

Table definitions and attribute value definitions are available in [PNW
Hydrography Framework Clearinghouse Hydrography Data
Dictionary]{.underline} at <http://hydro.reo.gov/docs.html>.

**Water Body Attributes (WB.wbpat)**

  ------------------- ---------------------------------------------------
  **Item Name**       **Item Description**

  WB_LLID_NR          Water Body LLID

  WB_HYDR_FTR_CD      Contains hydrographic feature code. Alpha code used
                      to describe hydrographic feature represented.
                      Examples: Island, Lake

  WB_CART_FTR_CD      Contains numeric cartographic feature code.
                      Example: reservoir, glacier, tailings pond.

  WB_GNIS_NM          GNIS name.

  WB_GNIS_NR          GNIS number.

  WB_PERIOD_CD        Periodicity code. Examples: Ephemeral,
                      Intermittent, Perennial
  ------------------- ---------------------------------------------------

##   {#section .toc_2}

## ![](media/image19.jpeg){width="6.302083333333333in" height="2.3958333333333335in"}2.7 Water Body Shoreline Layer Description {#water-body-shoreline-layer-description .toc_2}

**Quick Facts**

-   One or more representations of the shoreline of each water body.

-   Each water body represented in the water body layer is also
    represented in this shoreline layer. The water body boundary is the
    default shoreline.

-   Stored as routed coverage with associated event tables. The route
    system is called WS.

    -   Where possible, water is to the right side of each route. Arcs
        may point in any direction.

    -   Routes are non-overlapping; that is, each arc may belong to only
        one route. In the case of water bodies that share a common
        boundary, shoreline routes may not form closed loops.

    -   Route measures are an indexing scheme for linear referencing,
        not a stored attribute of shoreline length.

    -   There is one route for each LLID.

```{=html}
<!-- -->
```
-   LLID of each shoreline feature is based on location of the beginning
    of the route and is unique within the water body shoreline layer.

-   Event tables are related to the routes using the LLID field. The
    LLID field (WS_LLID_NR) is the route key item in the RAT and the
    event key item in each event table.

-   There are two event tables associated with the water body shoreline
    layer: shoreline type event table (WS.EVT_SL_TYPE) and the feature
    history event table (WS.EVT_FTR_HST). Both event tables are
    formatted as discontinuous event tables. Each has beginning and
    ending address fields.

-   Shoreline type and feature history events:

    -   Continuous events modeled as discontinuous events.

    -   Events in these tables cannot overlap and no gaps are allowed.

    -   Beginning address of the first event on a route must be zero and
        subsequent events on the route must begin where the previous
        event ended.

    -   At least one event must be defined for every watercourse route
        in each table.

    -   Ending address of the last event for each route in each table
        must be either the ending index of the route or 9999.

**Description**

*[The Water Body Shoreline (WS]{.underline})* layer consists of one or
more representations of the shoreline of each water body. One
representation of the shoreline for each water body will be flagged as
the "default" shoreline. Except for ocean shorelines, this default
shoreline is coincident with the water body perimeter of the water body
in the water body (WB) layer. Note: the only relationship between the
water body shoreline (WS) layer and the water body (WB) layer is the
coincident spatial location of the water body boundary; there is no
explicit linking item. This layer is to accommodate those instances
where multiple shorelines based on different datum (e.g. mean high
water, mean low water etc.) are useful, especially marine shorelines.

This layer is modeled as a routed linear feature. Where possible, water
will be on the right side of each route and one or more non-overlapping
routes will represent each shoreline. Most simple water bodies (e.g.
small lakes and ponds) will likely be represented by a single route. All
route measures will be initially calibrated and displayed in kilometers
to three decimal places. As these routes are edited, every effort will
be made to keep the measure value at a given map location from shifting.
Over time, the measures will only approximate kilometers along a
shoreline. The measures are simply an indexing scheme for linear
referencing, not a stored attribute of shoreline length.

The history of spatial edits to each water body will be stored as an
event on the route defining the default shoreline. Non-default
shorelines are intended to accommodate specialized requirements.

There are two event tables associated with the water body shoreline
layer: shoreline type event table (WS.EVT_SL_TYPE) and the feature
history event table (WS.EVT_FTR_HST). Both types of events are
continuous but for ease of querying, the event tables are formatted as
discontinuous event tables. Each event in each table has a beginning and
ending address; however, the beginning address of the first event on a
route must be zero and subsequent events on the route must begin where
the previous event ended. Events in these tables cannot overlap. At
least one event must be defined for every shoreline route. Since an
event must be defined over every part of every route, the ending address
of the last event for each route must be either the ending index of the
route or 9999. An address of 9999 is used for events that always extend
to the end of the route. This ensures that the event will indeed always
extend to the end of the route, even when the route is edited.

Table definitions and attribute value definitions are available in the
[PNW Hydrography Framework Clearinghouse Hydrography Data
Dictionary]{.underline} at <http://hydro.reo.gov/docs.html>.

**Water Body Shoreline Event Tables**

  ------------------- ---------------------------------------------------
  **Event Table       **Event Table Description**
  Name**              

  WS.EVT_SL_TYPE      Contains datum code describing type and level of
                      shoreline. Examples: Extreme high water, fresh
                      water shoreline, mean low water shoreline.

  WS.EVT_FTR_HST      Contains feature history.
  ------------------- ---------------------------------------------------

## 2.8 Event Table Description {#event-table-description .toc_2}

**Event Table Names**

There are two event tables associated with the water body shoreline
layer and six event tables associated with the watercourse layer. The
tables are listed below.

  --------------------- ------------------------------ ---------------------
  **[Table              **[Descriptive                 **[Abbreviated
  Name]{.underline}**   Name]{.underline}**            Name]{.underline}**

  WS.EVT_SL_TYPE        WS shoreline type event table  Shoreline table

  WS.EVT_FTR_HST        WS feature history event table WS feature history
                                                       table

  WC.EVT_NAME           WC GNIS name event table       Name table

  WC.EVT_RRF            WC river reach file number     RRF table
                        event table                    

  WC.EVT_LN_TYPE        WC line type event table       Line type table

  WC.EVT_FTR_TYP        WC feature type event table    Feature type table

  WC.EVT_STRM_FLOW      WC stream flow event table     Flow table

  WC.EVT_FTR_HST        WC feature history event table WC feature history
                                                       table
  --------------------- ------------------------------ ---------------------

**Common Event Table Structure**

All of the event tables in the Clearinghouse, whether associated with
the shoreline or watercourse layer, have the same basic structure. All
contain the LLID field (the event key) and two measure fields ("from"
and "to" fields), followed by one or more attribute fields. The basic
structure is listed below:

  ----------------------- ----------------------- --------------------------- -------------------------------
  **Basic Structure of                                                        
  Hydrography Framework                                                       
  Clearinghouse Event                                                         
  Tables**                                                                    

  **[Item Name in WC      **[Item Name in WS      **[Item                     **[Description]{.underline}**
  Event                   Event                   Definition]{.underline}**   
  Tables]{.underline}**   Tables]{.underline}**                               

  WC_LLID_NR              WS_LLID_NR              13, 13, C                   LLID Field -- Event Key Item

  WC_BEGIN_AD             WS_BEGIN_AD             4, 12, F, 3                 Beginning address of event -
                                                                              "From" Item

  WC_END_AD               WS_END_AD               4, 12, F, 3                 Ending address of event - "To"
                                                                              Item

  (Varies depending on    (Varies depending on    (Varies.)                   Other Attributes -- depending
  table.)                 table.)                                             on the table, may be more than
                                                                              one item.
  ----------------------- ----------------------- --------------------------- -------------------------------

**Event Table Groups**

The event tables can be separated into two groups based on their common
characteristics: Group 1 (continuous) and Group 2 (discontinuous).
Characteristics of each group are described on the next page.

**[Group 1 (continuous)]{.underline}**

-   Tables: shoreline, line type, feature type, flow, feature history

-   Events in these tables [cannot]{.underline} overlap. A single
    location may not have more than one shoreline, line type, feature
    type, flow or feature history attribute.

-   [No]{.underline} gaps can occur; every part of every route must be
    included in one (and only one) event.

-   Events must exist for every route; at least one event must be
    defined for every route.

-   One (and only one) event for each route must have a beginning
    address of zero and one (and only one) event must have an ending
    address equal to the ending index on the route or 9999.

-   The beginning address of the first event on a route must be zero and
    subsequent events on the route must begin where the previous event
    ended. The ending address of the last event for each route must be
    either the ending index of the route or 9999.

-   Existing events in these tables should be adjusted, although
    additional events can be added.

-   Example of flow table for one route. Route is 10 index units long.

  ------------------------------ ------------------------------- ----------------------------- ------------------------------- --------------------------------
  **[WC_LLID_NR]{.underline}**   **[WC_BEGIN_AD]{.underline}**   **[WC_END_AD]{.underline}**   **[WC_CONTU_CD]{.underline}**   **[WC_PERIOD_CD]{.underline}**

  1234567891234                  0.000                           2.600                         con                             per

  1234567891234                  2.600                           3.941                         con                             int

  1234567891234                  3.941                           9999                          con                             eph
  ------------------------------ ------------------------------- ----------------------------- ------------------------------- --------------------------------

**[Group 2 (discontinuous)]{.underline}**

-   Tables: name, RRF

-   Events in these tables [cannot]{.underline} overlap. Each location
    may have only one GNIS name and only one RRF number.

-   Gaps [can]{.underline} occur. Events do not have to occur on every
    route and every part of every route does not have to be included in
    an event.

-   Events may not exist for every route.

-   An ending address of 9999 can be used in these tables. It will be
    common in the name table.

-   Existing events in these tables can be modified; additional events
    can be added.

-   Example of RRF table for one route. Route is 10 index units long.

  ------------------------------ ------------------------------- ----------------------------- -----------------------------
  **[WC_LLID_NR]{.underline}**   **[WC_BEGIN_AD]{.underline}**   **[WC_END_AD]{.underline}**   **[WC_RRF_NR]{.underline}**

  1234567891234                  1.311                           1.876                         17060104005300.00

  1234567891234                  1.876                           2.749                         17060104005307.61

  1234567891234                  2.749                           5.610                         17060104005308.51
  ------------------------------ ------------------------------- ----------------------------- -----------------------------

**Ending Address (Measure) of 9999**

An ending address (measure) of 9999 is used for events that will most
likely always extend to the end of the route, even if the ending spatial
location of the route changes. Since a single route cannot be longer
than 9999 index units, using an ending address of 9999 ensures that the
event will indeed always extend to the end of the route, even when the
route is edited. Using an ending address of 9999 reduces event editing
because the ending address of events ending at the end of the route do
not need to be adjusted every time the ending measure of the route
changes.

Specific table definitions and attribute value definitions are available
in the [PNW Hydrography Framework Clearinghouse Hydrography Data
Dictionary]{.underline} at <http://hydro.reo.gov/docs.html>.

## 2.9 Hydrologic Units Description {#hydrologic-units-description .toc_2}

**Quick Facts**

-   Hydrologic units were incorporated into this dataset from an
    aggregate of pre-existing HU's.

-   A number of new Hydrological Unit Boundaries were delineated using
    flow lines and basins computed from 10- and 30-meter horizontal
    resolution Digital Elevation data based on flow derived from the
    elevation grid to determine potential pour points.

-   The DEM data is derived from hypsography represented on 1:24000 USGS
    topographic quadrangles.

-   Additional hydrography data was used as a template to control
    pourpoint locations for the delineated HU's.

**Description**

The purpose of the hydrologic unit boundaries dataset is to
simultaneously maintain an index representing Level One (1) through
Eight (8) hydrologic unit boundaries. This dataset is intended as a tool
for water-resource management and planning activities, particularly for
site-specific and localized studies, which require the amount of detail
provided by a large-scale map. The hydrologic unit boundaries coverage
contains attributes for polygons, arcs and eight Arc/Info regions.
Hydrologic unit delineations are closed polygons that encompass all area
draining toward the lowest point (called pour point) in the polygon.

To better classify hydrologic units, the dataset is divided into
separate size classifications called "Levels" or "Fields," which define
drainage areas of specific size within a network of hydrologic units.
The largest classification of this kind is called a 1st Level hydrologic
unit (also referred to as Region). An example of a 1st Level hydrologic
unit is the Columbia River Basin Region, which defines the drainage
network for the majority of the States of Oregon and Washington. As part
of the ranking system, 1st Level units can be subdivided into smaller
2nd Level units, which can be further subdivided into 3rd Level units
and so on. These divisions currently may continue until much smaller 8th
Level units are reached.

Several nested hydrologic unit boundaries have been incorporated to
create this geospatial dataset, which allow for mapping to the 8th
Level. The dataset was developed by delineating the boundary lines on
1:24,000 base maps and digitizing the delineated lines. Digital
Elevation Model data was used in part of the process to establish
preliminary boundaries. The hydrologic unit code attached to each
delineated polygon is linked to the attribute data, which can contain
information on area in acres, non-contributing area, state(s) the
hydrological unit falls within, name for 5th and 6th level HU, 5th and
6th level code for downstream hydrologic unit and hydrologic unit
modifications. Each line has attributes that describe the HU level
(1-6), originating source for that line and a metadata ID number that
links the line to its associated metadata file.

Maintenance Coverage versus Distribution Coverage

Two separate coverages exist for the Hydrologic Unit Layer dataset: the
publicly distributed coverage (referred hereafter as Distribution) and
the maintenance coverage (referred hereafter as Maintenance).

The Distribution coverage is available to all users for query and
analysis purposes and includes the Polygon Attribute Table, the Arc
Attribute Table and all region feature classes, e.g. PATHUC1 -- PATHUC8.
The Distribution coverage uses the following naming convention:
HU_BOUNDARY. This dataset can be downloaded at
[**http://hydro.reo.gov/hu.html**](http://hydro.reo.gov/hu.html).

The Maintenance coverage is to be checked out for editing purposes using
the Interim HU Guidelines and includes the Polygon Attribute and Arc
Attribute Tables only. The Maintenance coverage uses the following
naming convention: HU\<mm/dd/yy\> (e.g. HU082203, where the date
indicates the date of last update). This dataset and the interim HU
Guidelines can be downloaded at
[**http://hydro.reo.gov/hu.html**](http://hydro.reo.gov/hu.html).

THIS PAGE LEFT INTENTIONALLY BLANK

[]{#__RefHeading___Toc64884515 .anchor}Section 3 -- Transactions in the
Hydrography Clearinghouse

## 3.1 Section 3 Outline {#section-3-outline .toc_2}

> 3.1 Section 3 Outline
>
> 3.2 The Editing Process and Overview of a Hydrography Framework
> Clearinghouse Transaction
>
> 3.3 The Check-out Process
>
> 3.3.1 Internet Map Check-Out
>
> 3.3.2 Submitted Polygon Check-Out
>
> 3.4 Checking the quality of edited Hydrography Framework Clearinghouse
> Data

3.5 The Check-in process

## 3.2 The Hydrography Layer Editing Process and Clearinghouse Transaction Overview {#the-hydrography-layer-editing-process-and-clearinghouse-transaction-overview .toc_2}

**The Editing Process**

1.  Coordinate your proposed update with all concerned hydrography
    framework partners. They should be aware of, and approve of, the
    edits you are going to make. This coordination should be done by
    your Agency Data Steward or Local Data Stewards.

2.  Check out the area you wish to edit from the Clearinghouse.

3.  Project the layers to your local coordinate system.

4.  Gather any background information you need to help you with the
    edits. This may include maps, photos, survey notes, or other spatial
    data sets.

5.  Perform the necessary edits. Multiple options exist for performing
    these edits. The only requirement is that the edits conform to the
    Clearinghouse data model and follow the editing protocols. You can
    edit directly in ArcEdit or, for the watercourse layer, you can edit
    using the WC Route Edit Tools (WCEDIT) available from the
    Clearinghouse.

6.  Check the edited layers for errors. Check for both structural errors
    (those that violate the design of the data model) and for content
    errors (misrepresentation of a feature or an attribute value error).
    Structural errors can be found and corrected by the data editor.
    Your agency or Local Data Steward should ensure that the layers are
    free of content errors.

7.  Check in the layers to the Clearinghouse. The Clearinghouse will
    email interested partners that the edits are complete.

This section of the User Guide focuses on steps two, six, and seven of
the above list.

**Overview of a Hydrography Framework Clearinghouse Transaction**

This section of the guide assumes that you are a valid editor at the
Clearinghouse level, which means that you have a login and password to
allow you to check out data. Local data stewards are responsible for
contacting the Clearinghouse Administrator and obtaining access for
editors. Also assumed is that the client-software (a set of ArcInfo
AML's, including HYDROQA.AML and FTP_CHECKOUT_POLY.AML) has been
installed and configured on the system you will be using for editing.
The client software assumes that the following workspace locations have
been specified and set up during installation.

1.  Usersworkspace

    a.  ArcInfo workspace in which new transaction workspaces will be
        created while downloading data from Clearinghouse server. This
        workspace must at least exist or be created on the user's system
        before running the Clearinghouse utilities.

    b.  User must have write permission to this workspace

    c.  Default location: C:\\hydro_aml\\data

2.  CheckoutWspace

    a.  ArcInfo workspace in which checkout polygon export files (.e00)
        will be placed for submission to the Clearinghouse server. This
        workspace must at least exist or be created on the user's system
        before running the Clearinghouse utilities.

    b.  User must have write permission to this workspace

    c.  Default location: C:\\hydro_aml\\data\\checkout_covs

3.  Tempwspace

    a.  Workspace containing coverages and files used by the QA/QC
        utilities. If you change the Tempwspace location, you must also
        copy the associated folder (*hydro_aml\\data\\temporary_covs*
        respectively*)* to the new location specified in QASETUP.AML.

    b.  User must have write permission to this workspace

    c.  Default location: C:\\hydro_aml\\data\\temporary_covs

4.  &Amlpath

    a.  Workspace containing the Clearinghouse client AMLs. If you
        change the &Amlpath location, you must also copy the associated
        folder (*hydro_aml\\aml* respectively*)* to the new location
        specified in QASETUP.AML.

    b.  Default location: C:\\hydro_aml\\aml

The first step in initiating a transaction on the Clearinghouse is to
determine the area that you need to check-out. The Hydrography Framework
partners agreed that a fifth field watershed would be a convenient unit
of update, so the web interface was designed with that in mind.
Alternatively, editors may submit a user-defined polygon that
encompasses the area to be edited. This option is useful if an editor
has an area of update that does not conform to hydrologic unit
boundaries, or, if they are trying to start an update without
conflicting with surrounding check-outs already in progress.

If you intend to edit features that *are not fully contained within the
update area*, you need to redefine the update area to enclose those
features. When using the fifth-field check-out map, you should select
adjacent watersheds that allow you to fully enclose the features you
need to edit. If you are using the submitted polygon method, reshape the
polygon to completely surround the edit area. Remember to account for
new features you will be adding. Only those features entirely within the
edit boundary can be checked-in and they cannot touch the edit boundary.

If you are interested in editing the long route that leaves the
watershed and/or the double-line stream polygon, then you will need to
check-out one or more downstream watersheds so those features are
entirely enclosed by the polygon. Another option is to create your own
polygon that encloses those features and submit that as your check-out
area for the transaction.

Once you have defined the transaction area, you can begin a transaction
using either the HUC selection map on the web or by submitting a
user-defined polygon to the Clearinghouse. If the transaction does not
conflict with existing open transactions, the data will be available for
downloading when you receive an e-mail from the Clearinghouse. The
HYDROQA.AML transfers the data to your computer and imports the
coverages and associated event tables. They will be in a geographic
projection. Since each organization has specific requirements for data
editing, projections and other local differences will not be covered
here.

The WC, WB, WS, and WP coverages contain the data that you can edit in
that the features in these coverages fall completely inside the edit
area. The WC_BACK, WB_BACK, and WS_BACK coverages include the features
that partially overlap the edit boundary and, therefore, cannot be
edited. Since they fall partially within the edit area, they may be
useful for edgematching, snapping, or contextual reference, but they
will not be returned to the Clearinghouse. Since points cannot partially
overlap the edit boundary, the Clearinghouse check out tools creates
only an editable coverage of water points.

After completing the necessary edits (see Section 4 -- Editing
Hydrography framework Clearinghouse Layers for editing instructions),
use the HYDROQA.AML to identify any errors in the coverage. Since these
quality control steps are the same as those run by the Clearinghouse,
cleaning up your data before check-in should help ensure that your data
is not returned to you by the Clearinghouse Administrator.

##  

## 3.3 The Check-Out Process for Hydrography Data {#the-check-out-process-for-hydrography-data .toc_2}

The Hydro Clearinghouse website is located at
[**http://hydro.reo.gov**](http://hydro.reo.gov/). To begin the
check-out process, select the "Hydrography Data Layers" option from the
navigation option on the left (displayed below).

![](media/image20.png){width="5.5256944444444445in" height="2.69375in"}

As mentioned earlier, this user guide assumes that you are both a valid
clearinghouse editor and that the clearinghouse client package has been
installed properly on your workstation.

Two hydrography checkout options exist for clearinghouse editors:
checkout by "5^th^ field watershed interactive map" (Section 3.3.1 -
Internet Map Check-Out) or checkout by "user-provided polygon" (3.3.2 -
Submitted Polygon Check-Out).

To begin the "Check-out by Map" process, select the "5^th^ field
watershed interactive map" hyperlink (located in step 4 underneath the
Editing Hydrography Data Layers heading - displayed below). To begin the
"Submitted Polygon Check-Out" process, select the "user-provided
polygon" hyperlink (also located in step 4 underneath the Editing
Hydrography Data Layers heading).

![](media/image21.png){width="5.363888888888889in" height="2.96875in"}

**3.3.1 Internet Map Check-Out**

Select: **5^th^ field watershed interactive map**

The Clearinghouse check-out map opens. The tools in the upper left
corner are useful for panning and zooming on the display, as well as
finding and identifying specific features. If you zoom in far enough,
the hydro data becomes visible if populated in that area.

![](media/image22.png){width="5.4118055555555555in"
height="4.461805555555555in"}

Below the general tool buttons are the tools for selecting the
sub-watersheds for your transaction:

**Select**: One click selects a single sub-watershed. To select more
than one sub-watershed, click a second location to create a line or more
to create a polygon. Up to 25 adjacent polygons can be selected this
way. The red shaded areas are already checked-out so do not select them.
The green shaded areas are populated with data and available for
check-out.

**Undo Last**: Removes your last selection click.

**Undo All**: Clears all selected polygons.

**Submit**: Notifies the Clearinghouse of your intent to check-out the
selected polygons. If no conflicts are found with existing check-outs, a
transaction will be started.

**Help**: Basic instructions for using the check-out map.

The area below the map displays information related to the current tool,
such as selected polygons, query results, etc.

Selecting the appropriate watershed(s) using the tools

To select a sub-watershed, first press the **Select** button in the
ArcIMS toolbar on the left. Next, select an appropriate sub-watershed
with the mouse arrow. If a valid sub-watershed is selected, it will be
designated selected with a darker yellow shade and a red dot, line or
polygon as displayed in the example below.

![](media/image23.png){width="5.2034722222222225in"
height="4.285416666666666in"}

To request the data from the Clearinghouse, now press: **Submit**

![](media/image24.png){width="2.45in" height="2.1416666666666666in"}

A login window opens.

Enter your login name and password.

Choose, **Hydro** to download the WP,

WS, WC and WB coverages,

choose **Watershed Boundaries** to

download just the Hydrologic Unit

Boundaries.

Press: **OK**

Note: To request a User ID and Password please use the Hydro Stewards
web site form (see Section 1.5). For security purposes, this request
will be reviewed by Agency Hydrography Stewards before a profile is
created.

![](media/image25.png){width="3.123611111111111in"
height="2.6618055555555555in"}The Transaction ID screen displays your
transaction number.

Note: Write Down the Transaction ID Number!

You can close the browser window.

You will receive an e-mail when the data is ready to download.

After receiving the e-mail, start the HYDROQA.AML to download the data
from the Clearinghouse:

Arc: **&run hydroqa.aml init**

![](media/image26.png){width="4.5875in" height="4.486111111111111in"}

Press: the **Download a Transaction From The Server** button.

![](media/image27.wmf)

Enter the transaction ID number that you wrote down in the field
provided.

Press: **OK**

The data will download to a new workspace named T \<transaction_id\>
(e.g. T1283) inside your designated user's workspace. It will then be
imported to geographic (NAD83) projection.

After projecting to your local projection (remember to use units of
"feet" or "meters"), you are ready to start the edit process as
discussed in Section 4.

You are ready to start the edit process as discussed in Section 4.

**3.3.2 Submitted Polygon Check-Out**

To begin the Submitted Polygon Check-Out option, you must first create a
single polygon that encloses the area you wish to edit. Make sure that
the coverage is double precision and contains only one real closed
polygon without dangle nodes and the universe polygon. Project the
coverage to geographic decimal degrees, datum NAD83 and make sure the
coverage has a valid PRJ file.

After the steps above have been followed and the sub-watershed has been
selected, press the **Submit** option from the initial ArcIMS 5^th^
Fiedl interactive map screen. You will be prompted with the following
login screen:

![](media/image28.png){width="2.765277777777778in"
height="2.408333333333333in"}

Enter your login name and password.

Press: **OK**

![](media/image25.png){width="3.3125in"
height="2.8229166666666665in"}Your transaction ID appears in another
window...

Note: Write Down the Transaction ID Number!

Close the browser window.

Now that a transaction number has been assigned to you, create an
ARC/INFO export file named **c\<transaction_ID\>.e00** from the polygon
coverage you created earlier. Note: Be sure to use the coverage in
Geographic (NAD83) Projection

Arc: **export cover geo_bndry c1283.e00**

Place the export file in your designated checkoutWspace directory. (For
details, refer to Section 3.2)

Run the FTP_CHECKOUT_POLY.AML from the client-software package to
transfer the export file to the server and begin the transaction:

![](media/image29.wmf)

Arc: **&run ftp_checkout_poly.aml upload**

Enter the transaction ID number.

Press: **OK**

When the data is ready to download, you will receive an e-mail from the
server.

Once you have received the e-mail, start the HYDROQA.AML to download the
data from the Clearinghouse:

Arc: **&run hydroqa.aml init**

![](media/image26.png){width="4.5875in" height="4.486111111111111in"}

Press: **Download A Transaction From The Server**

![](media/image30.wmf)

Enter the **transaction ID number** that you wrote down in the field
provided.

Press: **OK**

The data downloads to a new workplace named T \<transaction_id\> (e.g.
T1283) inside your designated user workplace and imports into geographic
projection (NAD83).

After projecting to your local projection (remember to use units of
"feet" or "meters"), you are ready to start the edit process as
discussed in Section 4.

## 3.4 Checking the Quality of Edited Hydrography Framework Clearinghouse Data {#checking-the-quality-of-edited-hydrography-framework-clearinghouse-data .toc_2}

Because organizations will vary in how they edit the Hydrography data,
we cannot discuss all quality control types that will be performed. It
is also difficult to implement a standard set of quality control
programs since some organizations may alter the coverage formats during
the edit phase. However, it is possible to utilize the quality control
programs used by the check-in process. If your data passes through those
routines error-free, then you can safely assume that your check-in will
be accepted by the Clearinghouse Server. If you have reformatted the
coverages in any way (e.g. added non-Clearinghouse features or
attributes, or reprojected), you will need to return them to the
Framework format before running the Framework quality control routine.

NOTE: The coverages must be named "\<layer\>\_CHECKIN" (e.g. wc_checkin)
for the program to find them.

To launch the Framework Q.C. process, start HYDROQA.AML:

Arc: **&run hydroqa.aml init**

![](media/image26.png){width="4.5875in" height="4.486111111111111in"}

Click: **Choose A Transaction Workspace To Report Upon**

![](media/image31.png){width="2.25in"
height="2.0902777777777777in"}Select the transaction number that you
want to check.

Press: **OK**

Back on the main HYDROQA menu, verify the Transaction Workspace and note
the name of the Output Report File Name. Again, notice the required
coverage names for Hydro transactions:

wb_checkin

ws_checkin

wc_checkin

wp_checkin

To create the error report, press: **QA/QC covers now**

Look in the workspace that contains the coverages to find the error
report.

To dismiss the HYDROQA menu, press: **Cancel**

Currently the checkbox on the HydroQA form to perform feature level
error checking has been disabled. In the future this checkbox will be
available to create a more detailed error report or run a specific AML.

## 3.5 The Check-In Process {#the-check-in-process .toc_2}

If you are satisfied with the results of the quality control report, you
are ready to check-in the data to the Clearinghouse server.

NOTE: The data must be named "\<layer\>\_CHECKIN" for check-in to work.

Launch the HYDROQA program:

![](media/image26.png){width="4.995138888888889in" height="5.5in"}

Arc: **&run hydroqa.aml init**

Click: **Choose A Transaction Workspace To Report Upon**

![](media/image31.png){width="2.25in"
height="2.0902777777777777in"}Select the transaction number that you
want to check-in.

Press: **OK**

Back on the main HYDROQA menu, verify the Transaction Workspace and note
the name of the Output Report File Name.

Pressing **Upload A Transaction To The Server** will run the QA/Qc
routines and send the data to the Clearinghouse.

If your data passes the server tests, it will be inserted into the
Clearinghouse dataset and you will receive an e-mail notifying you that
your transaction is complete.

**THIS PAGE LEFT INTENTIONALLY BLANK**

## Section 4 -- The Hydrologic Unit Layers {#section-4-the-hydrologic-unit-layers .TOC_REWORK___1}

## 4.1 Section 4 Outline {#section-4-outline .toc_2}

> 4.1 Section 4 Outline
>
> 4.2 Hydrologic Unit Layer Background
>
> 4.3 Hydrologic Unit Coverages Maintained by the Clearinghouse
>
> 4.4 General Hydrologic Unit Layer Editing Guidelines
>
> 4.5 Agency Data Steward Review Criteria

4.6 The Hydrologic Unit Layer Editing Process Overview

4.7 The Hydrologic Unit Layer Editing Process Instructions

4.8 Sample Hydrologic Unit Boundary Change Request Form

## 4.2 Hydrologic Unit Layer Background {#hydrologic-unit-layer-background .toc_2}

In 2002, state and federal agencies, along with the Regional Ecosystem
Office (REO) coordinated the development of a single seamless set of
Hydrologic Units (HU's). The area covered by this dataset includes
Washington, Oregon, and N. California. The goal was to develop a common
dataset to be used by the partner agencies to coordinate land
management, analysis, and projects across agencies. This dataset, its
documentation, and corresponding technical specifications can be found
at

Currently the USGS and NRCS have drafted a very complete set of
guidelines in order to meet requirements for a national HU Boundary
dataset. See the NRCS website for details:

<http://www.ftw.nrcs.usda.gov/huc_data.html>. The guidelines provided in
this User Guide are intended to reinforce these national guidelines, and
also to provide direction on how to maintain these Hydrologic Unit
boundaries in a coordinated fashion across the state and federal
agencies.

Primary responsibility for refining this Hydrologic Unit Boundary
dataset, and coordinating updates with neighboring partners, rests at
the local unit level. This level requires the most accurate dataset, and
it is also at this level where the capability for updating the dataset
often resides. Descriptions of the Local and Agency Data Stewardship
roles that oversee this activity may be found at
<http://hydro.reo.gov/documentation/rols_responsibilities.doc>.
Coordination between partners can be facilitated through the Hydro
Stewardship website <http://ims.reo.gov/website/hydrostewards>.

In order to maintain this dataset in a consistent and seamless fashion,
the Agency Data Stewards have agreed to review all major updates. This
review process role provides oversight of the many local level changes
that are expected and ensures that updates meet the national guidelines
while maintaining a homogeneous composite.

In summary, the review by the Agency Data Stewards will ensure:

1\. Changes meet the national protocols

2\. Major changes to the Hydrologic Unit dataset are justified

3\. That all changes result in a consistent and homogeneous set of
Hydrologic Units.

Although Agency Data Stewards will review changes triggered by the
criteria described in this section, there may be instances where
stewards from each partner organization will need to meet and resolve
more difficult data issues. These meetings will be scheduled on an ad
hoc basis (See related notes in Section 4.6 - Agency Data Steward Review
Criteria).

## 4.3 Hydrologic Unit Boundary Coverages {#hydrologic-unit-boundary-coverages .toc_2}

Two Hydrologic Unit boundary coverages (with a spatial extent of
Washington, Oregon and N. California) will be maintained via the PNW
Hydrography Framework Clearinghouse website
(<http://hydro.reo.gov/hu.html>): a **maintenance copy** and a
**distribution copy**.

The Hydrologic Unit boundary **maintenance copy** is provided for
Framework partners to make edits (see Section 4.7 for details). The
Hydrologic Unit maintenance coverage will be named
HU\<last_update_date\> (e.g. HU082103). This layer will have the
following feature classes:

-   An ArcInfo polygon feature class and attributes (.PAT) depicting the
    various hydrologic unit levels (e.g. name, and Hydrologic Unit Code
    (HUC) and other important data about the polygons.

-   An ArcInfo arc feature class and attributes (.AAT) depicting the
    feature level metadata (e.g. source, organization, edit date)

The Hydrologic Unit **distribution copy** is provided to users for
query, mapping and analysis purposes. The Hydrologic Unit distribution
coverage will be named HU_Boundary. This layer is re-created from the
maintenance copy each time a partner updates the master maintenance
copy. Corresponding metadata is available at the Clearinghouse website
([http://hydro.reo.gov](http://hydro.reo.gov/)) and provides the date
for the last update to the coverage. This layer will have the following
feature classes:

-   An ArcInfo polygon feature class and attributes (.PAT) (as above).

-   An ArcInfo arc feature class and attributes (.AAT) (as above)

-   An ArcInfo region feature class and attributes (.PATHUCX) for each
    of the HU levels (1-8). These feature classes contain the name, the
    HUC and the acres (calculated using an Albers equal area projection)
    for each hydrologic unit. The 5th and 6th level hydrologic units
    also have an attribute that identifies the downstream hydrologic
    unit.

The full description of the Hydrologic Unit coverage is detailed in the
[PNW Hydrography Framework Clearinghouse Hydrologic Unit Boundary Data
Dictionary]{.underline} available at (<http://hydro.reo.gov/docs.html>).

## 4.4 General Hydrologic Unit Editing Guidelines {#general-hydrologic-unit-editing-guidelines .toc_2}

Below are general procedures to follow when editing your Hydrologic Unit
boundary coverage. Currently, tools are not available for spatially
editing the hydrologic units. Additional information will be added to
this section when these tools are in place.

Any interested organization may act as a Framework partner for the
purpose of making edits to the Hydrologic Unit Boundary layer. Those
without a designated Hydro GIS Data Lead may contact Ken Adee
(<kadee@fs.fed.us>, 503-808-2290) or Dan Wickwire
(<dwickwir@or.blm.gov>, 503-808-6272) to act as their representative.
Organizations with an ongoing need for maintenance of hydrologic unit
boundaries may apply for authority to do so by contacting Ken or Dan.
Any individual or organization may recommend changes to a Framework
partner and work with that Framework partner for the purposes of
submitting recommended changes. The following procedures must be
followed in order to have submitted edits considered for inclusion in
the master Hydrologic Unit boundary coverage:

All national and regional protocols for delineation, coordination and
review must be followed. For national guidelines, see the Federal
Standards for Delineation of Hydrologic Unit Boundaries (located at

<http://www.ftw.nrcs.usda.gov/huc_data.html>), For regional guidelines,
see the [PNW Hydrography Framework Clearinghouse Hydrologic Unit
Boundary Data Dictionary]{.underline} (located at
<http://hydro.reo.gov/docs.html>). In this user guide, we establish
criteria that require certification of Agency Data Steward review for
some submitted edits.

The master copy of the Hydrologic Unit boundary maintenance coverage
will be retained on the REO website (<http://hydro.reo.gov/hu.html>).
Editing will be accomplished by the Framework partners. General
guidelines to follow when editing this coverage include the following:

1.  Delineation of boundaries should meet the Federal Standards for
    Delineation of Hydrologic Unit Boundaries
    (<http://www.ftw.nrcs.usda.gov/huc_data.html>).

2.  Be aware of the kinds of edits that would trigger Agency Data
    Steward review (see Section 4.5).

3.  All attributes associated with the Hydrologic Unit's should be
    reviewed and edited according to the [PNW Hydrography Framework
    Clearinghouse Hydrologic Unit Boundary Data Dictionary]{.underline}
    standard.

4.  Coordinate with affected partners regarding edits. [No coverage that
    is submitted will be accepted where this coordination has not taken
    place.]{.underline}

## 4.5 Agency Data Steward Review Criteria {#agency-data-steward-review-criteria .toc_2}

Certification by your Agency Data Steward will be required for the
following edits.

1.  Changes made to more accurately delineate boundaries to match
    ridgelines or stream junctions resulting in acreage changes of
    greater than 10%. For a 5th Level HU of 80,000 acres, acreage
    adjustments of greater than 8,000 acres will be reviewed.

2.  Any splits of HU's.

3.  Any joining of existing HU's. Since the overall goal is to keep HU's
    at the larger end of their range, these changes are more likely to
    be acceptable.

4.  Any HU number changes. This is required since partner organizations
    and others may have significant investments in HU numbers (i.e.
    links to databases).

Certification of Agency Data Steward review will NOT be required for the
following common edits:

1.  Changes made to more accurately delineate boundaries to match
    ridgelines or stream junctions resulting in acreage changes of less
    than 10%.

2.  HU name changes that meet national protocols.

Rationale for exceptions to the regional or national protocols, and/or
other controversial changes should be documented in the Change Request
Form comments section and in the comments field for the Hydrologic Unit
boundary coverage

When Agency Data Steward review is triggered the

1.  Agency Data Steward from the editing agency will approve of those
    edits

> OR

2.  If the editing Agency Data Steward feels the need (due to inadequate
    protocols etc.) they would discuss the controversial edits with the
    other Agency Data Stewards (Theme Management Board).

Agency Data Stewards will also meet to conduct a periodic review of the
HU coverage to evaluate consistency, adherence to protocols and other
issues. This will be done every 3 months during the first year.

## 4.6 The Hydrologic Unit Editing Process Overview {#the-hydrologic-unit-editing-process-overview .toc_2}

1.  Coordinate your planned edit(s) with the proper partner. Use the
    Hydro Stewards website (<http://ims.reo.gov/website/hydrostewards>)
    to identify applicable partners. Contact the other partners to
    inform them that you are about to make edits and ensure that they
    are not making edits currently or have not recently submitted edits.

2.  Download the **maintenance** Hydrologic Unit boundary coverage from
    the REO website at <http://hydro.reo.gov/hu.html>.

3.  Reselect the hydrologic units of interest from the master Hydrologic
    Unit coverage to create a \"subset\" coverage that contains the
    hydrologic units that you are going to edit.

4.  Edit the proper \"subset\" coverage according to the Federal
    Standards for Delineation of Hydrologic Unit Boundaries and other
    guidelines specified in Section 4.4.

5.  Submit the edited coverage and the completed Hydrologic Unit
    Boundary Change Request Form (see Section 4.8 for an example) to the
    following anonymous ftp directory: <ftp://ftp.or.blm.gov/hu_input>.
    Email the completed form to your Agency Hydro GIS Lead.

6.  The Agency Hydro GIS Lead quality controls the submitted changes,
    incorporates acceptable changes into the master maintenance
    coverage, and then returns the updated master to the Clearinghouse
    administrator.

7.  The Hydro CH Administrator updates the distribution HU_BOUNDARY
    coverage and makes both updated versions available from the website.

See Section 4.7 (The Hydrologic Unit Layer Editing Process Instructions)
for complete instructions on this editing process.

## 4.7 The Hydrologic Unit Layer Editing Process Instructions {#the-hydrologic-unit-layer-editing-process-instructions .toc_2}

Once a partner determines they have a need to make an edit, the process
and responsibilities for Framework partners to update the master HU
Boundary coverage are as follows:

1.  The partner wishing to make edits should go to the Hydro Stewards
    website (<http://ims.reo.gov/website/hydrostewards>) to identify
    other partners with whom they should coordinate the edits. This site
    provides an interactive ArcIMS map that can be used to identify
    contacts by watershed. Zoom into the watershed of interest and use
    the identify (![](media/image32.png){width="0.16666666666666666in"
    height="0.16666666666666666in"} ) tool to click on the watershed,
    then click on the Contact Information link to get a list of stewards
    and contacts for the watershed. The site also provides a means to
    apply for stewardship responsibilities or to be notified when edits
    occur within a watershed. To proceed with this, click on the Hydro
    Stewardship Form button
    ![](media/image33.png){width="0.3548611111111111in"
    height="0.3548611111111111in"} and fill out the form.

Contact the other partners to:

-   Inform them that you are about to make edits

-   Ensure that they are not making edits currently or have not recently
    submitted edits.

    -   If they have recently submitted edits, check with the Agency
        Hydo GIS Lead[^1] (below) before continuing the editing process.

2.  Once you have done the coordination, download the maintenance HU
    boundary coverage from the REO website http://hydro.reo.gov/hu.html.
    This coverage will be named HU\<last_update_date\> (e.g. HU082103).

3.  Reselect the HU's of interest from the master HU coverage to create
    a "subset" coverage that contains the HU's that you are going to
    edit. All planned edits must be completely contained within this
    subset of HU's, i.e. the external boundary of the subset coverage
    should NEVER be edited. The editing organizations abbreviated
    organization code (with dashes removed) should be appended to the
    name of the downloaded master HU coverage when naming. For instance,
    if the Siskiyou NF (organization code usfs-sis) were editing a
    subset of the master coverage named HU060403 they would name their
    subset edit coverage HU060403FSSIS. A complete list of organization
    codes can be found in the [PNW Hydrography Framework Clearinghouse
    Hydrologic Unit Boundary Data Dictionary]{.underline}
    ([http://hydro.reo.gov/docs.html](http://hydro.reo.gov/toolsdocs.html))
    under the LINEORG item. All partners must abbreviate the
    organization code to 5 characters if the data dictionary code is
    longer.

4.  When editing the coverage please insure that you follow these
    guidelines:

    a.  Delineation of boundaries should meet the Federal Standards for
        Delineation of Hydrologic Unit Boundaries
        (<http://www.ftw.nrcs.usda.gov/huc_data.html>).

-   All changes should reflect a consistent size in relationship to
    surrounding HU's. A homogeneous structure of HU's is an overall
    goal.

    a.  Be aware of the kinds of edits that would trigger Agency Data
        Steward review (see criteria in Section 4.5).

-   Any edits that would trigger that review MUST be pre-approved by the
    Agency Data Steward. This means that the edits must be approved by
    the initiating Agency Data Steward before the submitted edits are
    actually incorporated into the interagency HU layer. The initiating
    Agency Data Steward will determine which other Agency Data stewards
    need to be included in the approval process. That approval may be
    granted to the field unit directly if the Agency Data Steward is
    working closely with the initiating Local Data Steward. Otherwise,
    approval of the Agency Data Steward must be obtained by the Hydro
    GIS Lead before the edits are made. Pre-approval obtained by the
    field unit is preferred. The LINEVER item on the AAT may be used to
    track the approval level (local, agency etc.) of the edited lines
    within your internal agency update process. If used, this field
    should be populated with a "level 4" prior to submitting for posting
    back to the maintenance coverage. At this time use of this attribute
    is optional but it provides a precise way to identify which line
    edits have been approved.

    a.  All attributes associated with the HU's should be reviewed and
        edited according to the [PNW Hydrography Framework Clearinghouse
        Hydrologic Unit Boundary Data Dictionary]{.underline} standard.
        Pay special attentions to the following:

-   Polygon attributes describing the HU (name and HUC number). You may
    edit either the HUC_NUM attribute or on of the redefined items (e.g.
    WATERSHED or FIFTH_FIELD). You only need to edit one or of these,
    the other will be updated automatically. The name attribute varies
    with the HU Level e.g. for watersheds it is WATERSHED_NAME. Do not
    edit the ACRES field, that is updated automatically.

-   Arc feature level metadata attributes describing the edit. Pay
    special attention to the LINESOURCE, LINDEDATE and LINEORG
    attributes. These are the primary attributes for determining the
    provider, data and source of the line work.

    a.  Coordinate with affected partners regarding edits[. No coverage
        that is submitted will be accepted where this coordination has
        not taken place.]{.underline}

    b.  The tolerances used to edit the coverage should be no larger
        than:

Tolerance Value

\-\-\-\-\-\-\-\-\-\-- \-\-\-\-\-\-\-\--

Fuzzy 1

Dangle 1

Edit 10

Node Snap 5

Weed 1

Grain 1

Snap 5

5.  Each agency partner will submit edited coverage to the ftp directory
    referenced in #5 under part 4.6 and will notify the Hydro GIS Lead
    for their agency. As stated above, other organizations (not included
    in this list) can nominate Agency Hydro GIS Leads or they can work
    with leads from the listed agencies:

    a.  Oregon State Agencies -- Bob Harmon
        (<robert.c.harmon@wrd.state.or.us>, 503-378-8455 ext 258)

    b.  Washington State Agencies -- Carl Harris
        (<carl.harris@wadnr.gov>, 360-902-1423)

    c.  NRCS - Ian Reid (<ian.reid@or.usda.gov>, 503-414-3015)

    d.  BLM -- Dan Wickwire (<dwickwir@or.blm.gov>, 503-808-6272)

    e.  FS -- Ken Adee (<kadee@fs.fed.us>, 503-808-2290)

-   Submit the edited coverage and the completed Hydrologic Unit
    Boundary Change Request Form to the following anonymous ftp
    directory: <ftp://ftp.or.blm.gov/hu_input>. Email the completed form
    to your Agency Hydro GIS Lead.

-   The partner submission must include the attached Change Request form
    that includes a certification of Agency Data Steward review for the
    types of edits requiring that review.

6.  The Agency Hydro GIS leads are responsible for quality control of
    each submission.

-   Submissions will be handled in the following manner:

    a.  The Agency Hydro GIS lead will coordinate with the PNW
        Hydrography Framework Clearinghouse Administrator to ensure that
        the master HU coverage is available for editing (i.e. not be
        editing by another partner)

    b.  The Agency GIS lead will download the master HU coverage from
        the REO website, update the coverage, and submit it to the
        Clearinghouse Administrator.

    c.  The HU coverage master copy and downloadable HU coverage will be
        named in the following format:

    -   HU\<update date\> e.g. HU060403

7.  The Hydro Clearinghouse Administrator receives the updated master
    maintenance coverage from the Agency Hydro GIS lead and updates the
    HU_BOUNDARY distribution coverage and associated metadata for the
    coverages. The updated coverages are then made available for
    download from the website.

## 4.8 Sample Hydrologic Unit Boundary Change Request Form {#sample-hydrologic-unit-boundary-change-request-form .toc_2}

**Name of Agency/Unit Initiating Edit:** [FS -- Siu/Wil]{.underline}

**Name of Local Data Steward (initiating Agency):** [Barb Ellis-Sugai/
Deigh Bates]{.underline}

**Name/Unit of [Local Data
Stewards](http://ims.reo.gov/website/hydrostewards/viewer.htm) (partner
Agencies):**

[Chester Novak/Salem DO]{.underline}

> [Mary D'Aversa/Eugene DO]{.underline}

**For this change:** [X]{.underline} Agency Data Steward review
completed and approval granted.

**(check one)** No Agency Data Steward review required.

[X]{.underline} Partner Agencies have reviewed and agree with changes.

No interagency coordination required.

**Name of coverage:** [HUCV13FSSIU]{.underline}

**Description of Change:**

**1. Edits requiring Agency Data Steward review:**

All of the 5th fields in 17090006 had to be renumbered since they were
originally numbered from the bottom of the watershed to the top. The BLM
renumbered these watersheds correctly then sent them to me and I put in
the new numbers. 1709000205 was changed to 1709000204 to correct an
error. A 6th field line was dropped between 170900050501 and 02.

**2. Edits not requiring Agency Data Steward review:**

About 17 line edits were made on 6th field watersheds, most of which
were made to correct lines that crossed streams in the 24k layer (find
them by looking for LINEDATE cn '2003'). Some 6th field lines were moved
in 1709000402 (Horse Creek) to correct the watersheds to better match
the stream layer and the geology. There were about 8 6th fields that
were renamed.

Edits were done by Diane Rainsford, GIS coordinator for the Siuslaw NF.

## Section 5 -- Editing Hydrography Framework Clearinghouse Layers {#section-5-editing-hydrography-framework-clearinghouse-layers .TOC_REWORK___1}

## 5.1 Section 5 Outline {#section-5-outline .toc_2}

> 5.1 Section 5 Outline
>
> 5.2 Maintaining the Hydrography Framework Clearinghouse Data
>
> 5.3 The editing process
>
> 5.4 General editing protocols
>
> 5.5 Editing Water Points *(also see Appendix C - Exercise* *A)*
>
> 5.6 Editing Water Body shorelines *(also see Appendix C - Exercise*
> *B)*
>
> 5.7 Editing Water Bodies *(also see Appendix C - Exercise* *C)*
>
> 5.8 Editing Watercourses *(also see Appendix C - Exercise* *D)*
>
> 5.9 Editing Event Tables
>
> 5.10 WC Route Edit Tool (WCEDIT) *(also see Appendix C - Exercise*
> *D)*

5.11 Line Type Update Tool (LTUPDATE) (also *see Appendix C* - Exercise
E)

##  {#section-2 .toc_2}

## 5.2 Maintaining the Hydrography Framework Clearinghouse Data {#maintaining-the-hydrography-framework-clearinghouse-data .toc_2}

![](media/image34.png)

This section of the User Guide describes some basic procedures to use
when editing Clearinghouse layers. It assumes the Clearinghouse layers
have already been checked out of the Clearinghouse. Complex edits may
require the combined use of several of the basic procedures described in
succession. At times, there may be more than one way to perform a
desired edit. Select the method that is easiest to accomplish and that
requires the least number of changes.

**5.2.1 Coordination**

Remember to use caution when making updates. The data stored in the
Clearinghouse is shared by many organizations. The goal of an edit is to
improve the representation of the feature while not degrading the
quality of any attribute data already associated with that feature.
Given that other associated databases may exist in the interagency
environment, it is extremely important that edits not result in the
displacement of those attributes or the removal of features used by
other agencies. As mentioned already, the Clearinghouse editing process
requires cooperation and coordination with other partners**.** If all
parties involved are not attentive, someone else's attribute information
may be invalidated with your edits!

**5.2.2 Projections**

All layers are stored in the Clearinghouse in geographic coordinates
with units in decimal degrees. Decimal degree units are designed to
measure angles, not distances, so after extracting the layers from the
Clearinghouse, project them to your local Cartesian coordinate system
using rectilinear units such as feet or meters. Projecting the extracted
Clearinghouse coverages to your local projection also allows you to use
local data in the background while editing.

## 5.3 The Editing Process {#the-editing-process .toc_2}

1.  Coordinate your proposed update with all concerned partners. They
    should be aware of, and approve of, the edits you are going to make.
    This coordination should be done by the Agency Data Steward.

2.  Check out the area you wish to edit from the Clearinghouse.
    Attribute Extent for each Hydrography feature can be found in the
    Event table outlined in the [PNW Hydrography Framework Clearinghouse
    Hydrography Data Dictionary]{.underline} at
    <http://hydro.reo.gov/docs.html>.

3.  Project the layers to your local coordinate system.

4.  Gather any background information you need to help you with the
    edits. This may include maps, photos, survey notes, or other spatial
    datasets.

5.  Perform the necessary edits. There are many ways to perform the
    edits. The only requirement is that the edits conform to the
    Clearinghouse data model and follow the editing protocols. You can
    edit directly in ArcEdit or, for the watercourse layer, you can edit
    using the WC Route Edit Tools (WCEDIT) available from the
    Clearinghouse.

6.  Check the edited layers for errors. Check for both structural errors
    (those that violate the design of the data model) and for content
    errors (misrepresentation of a feature or an attribute value error).
    Structural errors can be found and corrected by a data editor. The
    Data Steward should ensure that the layers are free of content
    errors.

7.  Check in the layers to the Clearinghouse. Contact concerned partners
    and inform them that the edits are complete.

This section of the User Guide focuses on step five for each layer. The
previous section describes the rest of the editing steps performed by
the data maintainer.

## 5.4 General Editing Protocols {#general-editing-protocols .toc_2}

Below are some general protocols to follow when you edit a Clearinghouse
layer:

**Hydrography**

1.  Each layer must conform to the Clearinghouse Data Model described in
    the [PNW Hydrography Framework Clearinghouse Hydrography Data
    Dictionary]{.underline} at <http://hydro.reo.gov/docs.html>. In
    addition to the spatial requirements, this includes:

-   Each feature must have a uniquely identifying longitude/latitude
    identifier (LLID). This 13-character identifier is composed of the
    concatenated decimal degree longitude and latitude of the feature.
    The identifier is unique within each layer but there is no
    requirement that it be unique between the layers. If the LLID of a
    new feature already exists, increase the LLID by one until the LLID
    is unique.

-   All attributes required by the Clearinghouse must be entered for
    each feature.

-   All attribute values must conform to the data model.

-   Once established, the LLID of a feature cannot be changed, even if
    the location of the feature changes.

## 5.5 Editing Water Points {#editing-water-points .toc_2}

![](media/image35.png){width="0.8854166666666666in"
height="1.0416666666666667in"}Currently, tools are not yet available for
spatially editing water points. Additional information will be added to
this section when these tools are in place. Below are general procedures
to follow when adding, updating, or deleting a water point. For more
information on editing water points, see Appendix C (Exercise A: Editing
Water Points).

When you have finished editing the water point layer, inspect the layer
for errors, correcting any that are found. (Error checking and quality
control of the Clearinghouse data are discussed in detail in Section 3 -
Transactions in the Hydrography Clearinghouse.) In particular, check the
following guideline:

-   All data conforms to the general editing protocols.

**Adding a Water Point**

1.  Add a new point using one of the approved means. The water point
    must be contained within the boundary used to check out the
    Clearinghouse coverage.

2.  Use wpedit to assign a LLID to the point. The LLID (concatenated
    decimal degree longitude and latitude \[to four places of
    precision\] of the feature) should be based on the position of the
    point and cannot already exist in the water point layer. If the LLID
    does already exist, increase the LLID by one until the LLID is
    unique. The LLID is stored in the WP_LLID_NR item.

3.  Populate the rest of the attributes in the point attribute table
    using wpedit, if desired.

4.  Use wpedit to add the feature history attributes. The feature
    modification code (FTR_MOD_CD) should be add.

**Deleting a Water Point**

1.  Select the point to delete and note its LLID.

2.  Delete the point.

3.  Modify the record of the deleted point in the related feature
    history table (WP.REL_FTR_HST). The feature modification code
    (FTR_MOD_CD) should be *del*. Enter the source date (FTR_SRC_DT),
    your agency code (FTR_ORG_CD), and the feature edit date
    (FTR_EDIT_DT). All other attributes should be coded *0* (zero) or
    *99* as appropriate.

**Updating the Attributes of a Water Point**

1.  Select the point to change.

2.  Change attributes in the point feature attribute table as necessary.
    Do not change the LLID. Do not make any changes to the related
    feature history table (WP.REL_FTR_HST).

**Change the Location of a Water Point**

1.  Select the point to move and note its LLID.

2.  Move the selected point to the new location.

3.  Change attributes in the point feature attribute table as necessary.
    Do not give the point a new LLID. Since this is the same feature,
    the LLID does not change, even though the location of the feature
    was changed to a better spatial representation of the feature.

4.  Update the record of the point in the related feature history table
    (WP.REL_FTR_HST). Update all attributes for the moved point. The
    FTR_MOD_CD should be *upd*.

## 5.6 Editing Water Body Shorelines {#editing-water-body-shorelines .toc_2}

![](media/image36.png){width="0.9583333333333334in"
height="1.1145833333333333in"}Currently, tools are not yet available for
editing water body shorelines. Additional information will be added to
this section when these tools are in place. Below are general procedures
to follow when adding and deleting a shoreline. For more information on
editing water body shorelines, see Appendix C (Exercise B: Editing Water
Body Shorelines).

When you have finished editing the water shoreline layer, inspect the
layer for errors, correcting any that are found. (Error checking and
quality control of the Clearinghouse data are discussed in detail in
Section 3 Transactions in the Hydrography Clearinghouse.) In particular,
check the following guidelines:

-   All data conforms to the general editing protocols.

-   There are no arc intersect errors in the coverage.

-   Water is on the right side of routes.

-   Each arc is fully contained in one and only one route.

-   Each water body in the water body layer is represented as a default
    shoreline in this layer.

-   One, and only one, representation of a water body shoreline is
    flagged as the default shoreline.

-   The LLID of each feature is based on the beginning of the route.

**Adding a Water Body Shoreline**

1.  Add all the arcs necessary to define the new shoreline using one of
    the approved means. The new shoreline must be contained within the
    boundary used to check out the Clearinghouse coverage.

2.  Create a new route feature in the WS route system from the new
    shoreline arcs. Where possible, the new route should point such that
    water is on the right. Route indexes should begin at zero and be
    based on the cumulative kilometer length along the shoreline.

3.  Assign a LLID to the new route. The LLID (concatenated decimal
    degree longitude and latitude (to four places of precision) of the
    feature) should be based on the position of the beginning of the
    route. It cannot already exist in the water body shoreline layer. If
    the LLID does already exist, increase the LLID by one until the LLID
    is unique. The LLID is stored in the WS_LLID_NR item.

4.  Populate the rest of the attributes in the WS route attribute table
    (RAT).

5.  Add event(s) to the shoreline type event table (WS.EVT_SL_TYPE) for
    the added route. Remember: (a) shoreline events cannot overlap, (b)
    the beginning address of the first event on the route must be zero
    and subsequent events on the route must begin where the previous
    event ended, and (c) the ending measure of the last event on the
    route must be either the ending index of the route or 9999.

6.  Add new event(s) to the feature history event table (WS.EVT_FTR_HST)
    for the added route. Populate all attributes for the new feature. At
    least one added event should have a beginning measure of zero, and
    at least one event should have an ending measure equal to the ending
    index of the route. The feature modification code (FTR_MOD_CD) for
    all added events should be *add*.

7.  If this is a default shoreline, use the shoreline location to add a
    new water body to the water body layer.

**Deleting a Water Body Shoreline**

Occasionally, a water body shoreline may need to be removed from the
water body shoreline layer. These deletions may be the result of initial
mapping errors corrected with the collection of better shoreline
location information, or the result of a verified catastrophic event. In
either case, verify with all concerned partners that the shoreline truly
does not exist prior to deleting it! Deleting the shoreline could result
in existing event data not having a spatial location.

1.  Select the water body shoreline route to be deleted.

2.  Note the LLID of the routes to be deleted and if the deleted route
    is a default shoreline.

3.  Delete the selected route(s). You must delete the route before
    deleting the underlying arcs.

4.  Select the arc(s) underlying the delete route(s) and delete them.

5.  If the deleted route was a default shoreline, you have two options:

    a.  Select (and delete) any other shorelines associated with this
        water body OR

    b.  Select one of the other shorelines associated with this water
        body and make it the default shoreline.

6.  Update the shoreline type event table (WS.EVT_SL_TYPE). Select any
    records containing the LLID of the deleted route(s) and delete these
    event(s).

7.  Update the feature history event table (WS.EVT_FTR_HST).

    a.  Select any records containing the LLID of the deleted route(s)
        and delete these event(s).

    b.  Now add a record for each deleted route. The beginning address
        for each event should be zero and the ending address should
        be 9999. In each event, the feature modification code
        (FTR_MOD_CD) should be *del*. Enter the source date
        (FTR_SRC_DT), your agency code (FTR_ORG_CD), and the feature
        edit date (FTR_EDIT_DT). All other attributes should be coded
        *0* (zero) or *99* as appropriate.

8.  Update the water body layer to reflect the change in the shoreline
    layer.

## 5.7 Editing Water Bodies {#editing-water-bodies .toc_2}

![](media/image37.png){width="0.8958333333333334in"
height="1.0729166666666667in"}Currently, tools are not yet available for
spatially editing water bodies. Additional information will be added to
this section when these tools are in place. Below are general procedures
to follow when adding and deleting a water body. For more information on
editing water bodies, see Appendix C (Exercise C: Editing Water Bodies).

When you have finished editing the water body layer, inspect the layer
for errors, correcting any that are found. (Error checking and quality
control of the Clearinghouse data are discussed in detail in Section 3
Transactions in the Hydrography Clearinghouse.) In particular, check the
following guidelines:

-   All data conforms to the general editing protocols.

-   There are no arc intersect errors or dangling arcs in the coverage.

-   Each polygon consists of a closed loop of arcs and an associated
    label. No extraneous labels or arcs can exist in the coverage. Each
    polygon may only have one label point.

-   Each polygon in the layer is included in the water body region
    class. Each polygon may belong to only one region feature.

-   Each region feature is composed of only one polygon.

-   Each water body is represented as a default shoreline in the water
    body shoreline layer.

-   The LLID of each water body is based on the position of the polygon
    label.

**Adding a water body**

1.  Add a new water body polygon using a default shoreline boundary
    defined in the water body shoreline (WS) layer.

2.  Create a new region feature in the WB region subclass from the new
    polygon.

3.  Use wbedit to assign a LLID to the new region feature. The LLID
    (concatenated decimal degree longitude and latitude \[to four places
    of precision\] of the feature) should be based on the position of
    the label in the polygon underlying the region. It cannot already
    exist in the water body layer. If the LLID does already exist,
    increase the LLID by one until the LLID is unique. The LLID is
    stored in the WB_LLID_NR item.

4.  Populate the rest of the attributes in the WB region attribute
    table.

5.  If a watercourse flows through this new water body, update the WC
    line type event table to reflect the new water body.

**Deleting a Water Body**

1.  Select the water body polygon to be deleted. The corresponding water
    body shoreline should already have been deleted from the water body
    shoreline (WS) layer.

2.  Delete the water body region.

3.  If a watercourse flowed through the deleted water body, update the
    WC line type event table to reflect the changes made to the water
    body (WB) layer.

## 5.8 Editing Watercourses {#editing-watercourses .toc_2}

![](media/image38.png){width="1.1145833333333333in"
height="1.15625in"}Described below are general procedures for spatial
editing of some common editing scenarios for watercourses such as adding
a new watercourse, deleting an existing watercourse, modifying the end
of an existing watercourse, reshaping an existing watercourse, and
moving an existing watercourse to a new location. The following section
contains more detail on editing the event tables. For more information
on editing watercourses, see Appendix C (Exercise D: Editing
Watercourses using WCEDIT).

Unlike the other layers, there are tools available for editing
watercourses. The WC Route Edit tools (WCEDIT) help to perform the
common editing scenarios listed above. WCEDIT can be downloaded from the
Clearinghouse website.

When you have finished editing the watercourse layer, inspect the layer
for errors, correcting any that are found. (Error checking and quality
control of the Clearinghouse data are discussed in detail in Section 3
Transactions in the Hydrography Clearinghouse.) In particular, check the
following guidlines:

-   All data conforms to the general editing protocols.

-   All arcs in this layer point in the direction of flow. This is
    downstream for stream watercourses.

-   Except in very rare circumstances, the watercourse network should
    not contain gaps. Discontinuous watercourse segments should be
    connected to the watercourse network by approximating an artificial
    line between the discontinuous watercourse line and the watercourse
    network. Centerlines must be digitized through water bodies.

-   Watercourses that flow to the ocean end at the ocean shoreline.

-   All watercourse routes point opposite of flow direction. This is
    upstream for stream watercourses.

-   Each arc is in only one route and every part of every arc is in a
    route.

-   Route measures begin at zero and increase continuously along the
    length of the route. There are no gaps or overlaps in the route
    measures.

-   Routes are spatially continuous.

-   Watercourse routes should follow approved 1:100,000-scale stream
    routes as appropriate.

-   Measures at tributary junctions have remained unchanged.

-   The LLID of each route is based on the position of the beginning of
    the route.

**Adding a New Watercourse**

Different definitions of watercourses between partners (especially the
definition of small, ephemeral, or seasonal streams) may cause one
partner to add a watercourse that another partner did not include. In
addition, new watercourses may be added as better (field) watercourse
location information is collected.

1.  Add all of the arcs necessary to define the new watercourse using
    one of the approved means. The new arcs must:

-   Point in the flow direction.

-   Connect to the existing watercourse network except in rare cases
    where the watercourse flows into a true sink.

-   Be entirely contained within the boundary used to check out the
    Clearinghouse coverage.

2.  Create a new WC route over the new arcs. The new route cannot be
    built on arcs already contained in a route. The new route must:

-   Point opposite of flow direction.

-   Have indexes based on the cumulative kilometer length of the
    underlying arcs.

-   Have a beginning index of zero.

3.  Assign a LLID to the new route. The LLID (concatenated decimal
    degree longitude and latitude (to four places of precision) of the
    feature) should be based on the position of the beginning of the
    route. It cannot already exist in the watercourse layer. If the LLID
    does already exist, increase the LLID by one until the LLID is
    unique. The LLID is stored in the WC_LLID_NR item in the RAT.

4.  Update event tables as follows. The LLID for every event added is
    the LLID assigned to the new route. In every table, the LLID is
    stored in the WC_LLID_NR field.

    a.  Feature type event table (WC.EVT_FTR_TYP): Add event(s) for the
        new route.

    b.  Line type event table (WC.EVT_LN_TYP): Add event(s) for the new
        route.

    c.  Stream flow event table (WC.EVT_STRM_FLOW): Add event(s) for the
        new route.

    d.  Feature history event table (WC.EVT_FTR_HST): Add event(s) for
        the new route. The feature modification code (FTR_MOD_CD) of all
        added events should be *add*.

    e.  Name event table (WC.EVT_NAME): Add event(s) for the new route
        if the new watercourse has a GNIS name.

    f.  RRF event table (WC.EVT_RRF): Add event(s) for the new route if
        the watercourse has RRF numbers.

**Deleting an Existing Watercourse**

Occasionally, watercourse routes may need to be removed from the
watercourse layer. These deletions may be the result of initial mapping
errors corrected with the collection of better watercourse location
information or the result of a verified catastrophic event. In either
case, verify with all concerned partners that the watercourse truly does
not exist prior to deleting the route! Differing definitions of
watercourses between partners (especially the definition of a small,
ephemeral, or seasonal stream) may cause one partner to delete a
watercourse that another partner believes should not be deleted.
Deleting the watercourse would result in existing event data not having
a spatial location. When a watercourse is deleted, all tributaries and
side channels that flow into the deleted route also need to be removed
from the watercourse layer.

1.  Select the watercourse route to be deleted and any tributaries or
    side channels flowing into the route to be deleted.

2.  Note the LLID of the selected routes.

3.  Delete the selected routes. This removes the records for the
    selected routes from the route attribute table as well as all
    associated section records from the section attribute table. Route
    internal numbers and section internal numbers are updated
    accordingly. You must delete the routes before deleting the arcs.

4.  Select the arcs underlying the route(s) just deleted and delete
    them.

```{=html}
<!-- -->
```
5.  Update event tables as follows:

    a.  Feature type event table (WC.EVT_FTR_TYP): Delete all events
        occurring on the deleted routes.

    b.  Line type event table (WC.EVT_LN_TYP): Delete all events
        occurring on the deleted routes.

    c.  Stream flow event table (WC.EVT_STRM_FLOW): Delete all events
        occurring on the deleted routes.

    d.  Feature history event table (WC.EVT_FTR_HST):

        i.  Delete all events occurring on the deleted routes.

        ii. Add one event for each route deleted. The event should begin
            at zero and encompass the entire route. For all added
            events, populate the feature modification code (FTR_MOD_CD)
            with *del*, enter the source date (FTR_SRC_DT), your agency
            code (FTR_ORG_CD), and the feature edit date (FTR_EDIT_DT).
            All other attributes should be coded *0* (zero) or *99* as
            appropriate

    e.  Name event table (WC.EVT_NAME): Delete all events occurring on
        the deleted routes.

    f.  RRF event table (WC.EVT_RRF): Delete all events occurring on the
        deleted routes.

**Moving the End of an Existing Watercourse**

The endpoint of a watercourse route can be moved to a new location, such
as a GPS stream initiation point, provided that the new location is
within 30 meters of the existing watercourse endpoint. The existing
watercourse endpoint also must [not]{.underline} be connected to another
route. Measures do not need to be adjusted.

1.  Move the ending node of the route. The ending node must be a dangle
    node; that is, the endpoint to move cannot be connected to another
    route. One way to ensure that the endpoint is not moved more than 30
    meters is to snap the node to a point in a point coverage. The point
    represents the new endpoint location. If the snap tolerance is set
    to 30 meters, the point will only snap if the point representing the
    new endpoint location is no more than 30 meters away from the
    existing endpoint. Moving the endpoint node will not affect the
    route. There is no need to edit the route.

```{=html}
<!-- -->
```
1.  Update events to event tables as follows:

    1.  Feature type event table (WC.EVT_FTR_TYP): No changes necessary.

    2.  Line type event table (WC.EVT_LN_TYP): No changes necessary.

    3.  Stream flow event table (WC.EVT_STRM_FLOW): No changes
        necessary.

    4.  Feature history event table (WC.EVT_FTR_HST):

        1.  Modify the ending address of the last feature history event
            on each route whose endpoint was moved. The ending address
            should be 0.001 index units less than the ending measure of
            the route.

        2.  Add an event for each route whose endpoint was moved. The
            event should be 0.001 index value long. It should begin
            0.001 index value from the end of the route and end at the
            end of the route. The feature modification code (FTR_MOD_CD)
            for all added events should be *upd*. Complete all other
            attributes as appropriate.

    5.  Name event table (WC.EVT_NAME): No changes necessary.

    6.  RRF event table (WC.EVT_RRF): No changes necessary.

**Extending the End of an Existing Watercourse**

You might need to extend the end of a watercourse, for example, if a
stream was not mapped far enough up the ridge. When extending a
watercourse route, the measures are extended along the new section.

1.  Add all of the arcs necessary to extend the watercourse using one of
    the approved means. The new arcs must:

-   Point in the flow direction.

-   Connect to the end of an existing watercourse.

-   Be entirely contained within the boundary used to check out the
    Clearinghouse coverage.

1.  Append the new arcs to the existing watercourse route.

2.  Add measures to the new route segment. The measure should:

-   Begin where the original route measures left off.

-   Have measures based on the cumulative kilometer length of the arcs
    underlying the new route segment.

3.  Update event tables as follows:

    a.  Feature type event table (WC.EVT_FTR_TYP): Adjust existing
        events or add event(s) to include extended portion of route as
        necessary.

    b.  Line type event table (WC.EVT_LN_TYP): Adjust existing events or
        add event(s) to include extended portion of route as necessary.

    c.  Stream flow event table (WC.EVT_STRM_FLOW): Adjust existing
        events or add event(s) to include extended portion of route as
        necessary.

    d.  Feature history event table (WC.EVT_FTR_HST): Add event(s) for
        the entire extended portion of the route. The first event added
        should begin at the index where the original route index ended.
        Subsequent events should begin where the previous event ended
        until the end of the route is reached. The feature modification
        code (FTR_MOD_CD) for all added events should be *add*. Complete
        all other attributes as appropriate.

    e.  Name event table (WC.EVT_NAME): Adjust existing events or add
        event(s) to include extended portion of route as necessary.

    f.  RRF event table (WC.EVT_RRF): Adjust existing events or add
        event(s) to include extended portion of route as necessary.

**Shortening the End of an Existing Watercourse**

The need to shorten a watercourse is probably a result of initial
mapping errors corrected with the collection of better watercourse
location information (for example, a stream watercourse mapped too far
up a ridge). Because shortening a watercourse route requires the
deletion of part of the route, it is important to verify with all
concerned partners that part of the watercourse should truly be deleted
prior to shortening the route**!** Deleting part of the watercourse
could result in the event data of a partner not having a spatial
location. *Note that if you shorten a stream past a tributary or side
channel junction, you may need to delete the tributary or side channel
as well. To shorten a watercourse route:*

1.  Create a node at the new route endpoint. You may need to split an
    existing arc. Splitting an existing arc should not affect the
    routes.

2.  Delete any tributary or side channel routes that exist above the new
    endpoint. See *Deleting an Existing Watercourse*.

3.  Remove the sections above the new endpoint from the route.

4.  Delete the arcs that were underlying the sections deleted from the
    route.

```{=html}
<!-- -->
```
4.  Update event tables for the shortened watercourse as follows:

    a.  Feature type event table (WC.EVT_FTR_TYP): Adjust or delete
        existing event(s), removing all events that occur after the new
        ending point.

    b.  Line type event table (WC.EVT_LN_TYP): Adjust or delete existing
        event(s), removing all events that occur after the new ending
        point.

    c.  Stream flow event table (WC.EVT_STRM_FLOW): Adjust or delete
        existing event(s), removing all events that occur after the new
        ending point.

    d.  Feature history event table (WC.EVT_FTR_HST):

        i.  Adjust or delete existing event(s), removing all events that
            occur after the new ending point.

        ii. Add a new event beginning at the new ending index of the
            route and ending *9999*. The feature modification code
            (FTR_MOD_CD) should be *del*. Enter the source date
            (FTR_SRC_DT), your agency code (FTR_ORG_CD), and the feature
            edit date (FTR_EDIT_DT). All other attributes should be
            coded *0* (zero) or *99* as appropriate.

    e.  Name event table (WC.EVT_NAME): Adjust or delete existing
        event(s) if necessary, removing all events that occur after the
        new ending point.

    f.  RRF event table (WC.EVT_RRF): Adjust or delete existing event(s)
        if necessary, removing all events that occur after the new
        ending point.

**Reshaping the End of an Existing Watercourse**

If there are tributary junctions along the path to be reshaped, see
*Reshaping an Existing Watercourse* below. If there are no tributary
junctions, shorten the route to the beginning point of the reshape and
then extend the route along a new path.

**Reshaping an Existing Watercourse**

You may need to reshape an existing watercourse because of mapping
errors or because a catastrophic event (such as a mud slide) caused a
change in the location of the channel of a stream watercourse. To
preserve event information as accurately as possible, retain measures
outside of the extent of the edit. The measures on the reshaped section
of the watercourse will be adjusted, forcing the beginning, ending (for
a mid-route reshape only), and tributary junction measures to match
those of the original section. The edit may be especially complex at
confluences where a change in the location of a main route could result
in a tributary route falling short or extending past the updated main
route. Coordinate the update with concerned partners. This type of edit
can be very complex, affecting many different routes.

1.  Add new arcs to the watercourse layer depicting the new watercourse
    path (the reshape) and connecting any tributaries that fall short of
    the new (reshaped) path. The new path should connect to the existing
    route. If the edit is mid-route, connect both the beginning and
    ending of the new path to the existing route. If the edit is a
    reshape of the end of the route, only the beginning of the new path
    is connected. Create nodes at all tributary junctions. All arcs must
    point in the flow direction.

2.  Reshape the main route by:

    1.  Remove the original route path sections from the route.

    2.  Delete the arcs associated with the removed sections.

    3.  Append the new (reshaped) route path to the existing route. Flip
        sections if necessary.

    4.  Create measures on the reshaped route path, forcing the measures
        to remain the same at the beginning of the reshaped path and at
        each tributary junction. For a mid-route reshape, the ending
        measure must also remain unchanged.

3.  Correct each tributary that [extends past]{.underline} the reshaped
    route path by:

    1.  Remove from the tributary route the sections that extend past
        the reshaped main route.

    2.  Delete the arcs that were underlying the sections deleted from
        the tributary route.

    3.  Adjust the measures on the first arc of the tributary. The
        measure at the new confluence should be zero. The measure at the
        end of the first arc should remain unchanged. (Measures will be
        compressed along the first section of the tributary.)

4.  Correct each tributary that [falls short]{.underline} of the
    reshaped route path by:

    1.  Append the connecting arcs (added in step 2) to the beginning of
        the tributary route. The tributary route should connect with the
        reshaped main route.

    2.  Adjust the measures on the first arc of the tributary. The
        measure at the new confluence should be zero. The measure at the
        end of the first arc should remain unchanged. (Measures will be
        stretched along the first section of the tributary.)

5.  Update event tables for the reshaped watercourse and for each
    tributary junction as follows:

    1.  Feature type event table (WC.EVT_FTR_TYP): No changes necessary.

    2.  Line type event table (WC.EVT_LN_TYP): No changes necessary.

    3.  Stream flow event table (WC.EVT_STRM_FLOW): No changes
        necessary.

    4.  Feature history event table (WC.EVT_FTR_HST):

        1.  Reshaped Watercourse:

            1.  Adjust or delete existing events to
                [EXCLUDE]{.underline} the reshaped portion of route. In
                the example to the right, all events between index
                measures 1.2000 and 2.000 would be removed from the
                table. This would require changing the ending address of
                the first event to 1.2000, deleting the second event,
                and changing the beginning address of the last event to
                2.000.

> Add event(s) to the table to record the feature history of the
> reshaped area. The first event added should have a beginning address
> equal to the index at the beginning of the reshape. Subsequent added
> events, if necessary, should begin where the previous added event
> ended. The ending address of the last added event is the index at the
> end of the reshape. The feature modification code (FTR_MOD_CD) for all
> of these added events should be *upd*. Populate other attributes. In
> the example, a single feature history event is added from index
> measure 1.2000 to 2.000.

2.  Extended Tributary (tributary too short):

    1.  Adjust or delete existing events to so that the beginning
        measure of the first event occurring on the route is the index
        at the previous confluence. In the example to the right, the
        beginning address of the first event would be changed to 0.100.

Add event(s) for the extension. The beginning address of the first added
event is zero. Subsequent added events should begin where the previous
added event ended. The ending address of the last added event is the
index at the previous confluence. The feature modification code
(FTR_MOD_CD) for all added events should be *add*. Populate other
attributes. In the example, an event is added from index measure 0.000
to 0.1000.

3.  Shortened Tributary (tributary too long): No changes necessary.

```{=html}
<!-- -->
```
5.  Name event table (WC.EVT_NAME): No changes necessary.

6.  RRF event table (WC.EVT_RRF): No changes necessary.

**Moving an Existing Watercourse to a New Location**

In addition to deleting a route, correcting mapping errors may require
moving a watercourse to a new location. When moving a route to a new
location, the LLID, name, and tributary junction measures are
maintained. Some judgment is required when determining if a watercourse
route should be moved to a new location (retaining the LLID and
measures), or if the route should be deleted and an entirely new route
created (with different LLID and measures). You cannot move a route with
tributaries without also moving the tributary routes.

1.  Note the LLID of the route to move and the measures of that route at
    the beginning, ending, and at every tributary junction. Also note
    the LLID of every tributary route to move and its associated
    measures.

2.  Delete the route to move and all of its tributaries but do not
    modify any event tables. See *Deleting an Existing Watercourse*.

3.  Create new watercourse routes in the new locations. See *Adding a
    New Watercourse* above. Instead of determining new LLID's for the
    newly added routes, use the LLID's noted in step 1 above.

4.  Adjust the measures on the newly added routes, forcing the measures
    to remain unchanged at the beginning and ending of each route and at
    each tributary junction.

5.  Update events to event tables as follows:

    1.  Feature type event table (WC.EVT_FTR_TYP): No changes necessary.

    2.  Line type event table (WC.EVT_LN_TYP): No changes necessary.

    3.  Stream flow event table (WC.EVT_STRM_FLOW): No changes
        necessary.

    4.  Feature history event table (WC.EVT_FTR_HST): Add event(s) for
        all moved routes. The feature modification code (FTR_MOD_CD) of
        all added events should be *add*.

    5.  Name event table (WC.EVT_NAME): No changes necessary.

    6.  RRF event table (WC.EVT_RRF): No changes necessary.

## 5.9 WC Route Edit Tools (WCEDIT)  {#wc-route-edit-tools-wcedit .toc_2}

The WC Route Edit tools (WCEDIT) help to perform common basic editing
scenarios such as:

-   adding a new watercourse route,

-   deleting an existing watercourse route,

-   modifying the end of an existing watercourse route,

-   reshaping an existing watercourse route, and

-   moving an existing watercourse route to a new location.

In addition to spatial editing tools, WCEDIT also contains tools to edit
and display event tables associated with the WC layer.

For more information on the WCEDIT, see Appendix A -- Guide to WC Route
Edit Tools (WCEDIT).

## 5.10 Line Type Update Tool (LTUPDATE) {#line-type-update-tool-ltupdate .toc_2}

The Line Type Update Tool (LTUPDATE) helps automate updates to the WC
line type event table (WC.EVT_LN_TYPE). This event table includes two
attributes: (1) The line type code indicates the main cartographic
function of each line regardless of the feature or hydrologic function
it represents. (2) The flow path code defines the flow hierarchy of
watercourse centerlines that are within water bodies and is used to
define and segregate out various flow pathways.

Spatial changes to watercourses or water bodies can affect the accuracy
of line type event. These include: (1) adding or deleting a water body
or watercourse feature, (2) altering the shape or position of a
watercourse that flows wholly or partially through a water body feature,
and (3) altering the shape or position of a water body.

LTUPDATE will:

-   Help ensure that all line type event measures are accurately
    adjusted and properly snapped to water body shorelines.

-   Help ensure that line type events exist for all new watercourses or
    segments of watercourses.

-   Create a centerline event table in your workspace that may or may
    not be used by your agency. You can delete or ignore the centerline
    table if your agency does not need it.

For more information on the LTUPDATE, see Appendix B - Guide to the Line
Type / Centerline Utility (LTUPDATE)

**THIS PAGE LEFT INTENTIONALLY BLANK**

## Appendix A -- Guide to WC Route Edit Tools (WCEDIT) {#appendix-a-guide-to-wc-route-edit-tools-wcedit .TOC_REWORK___1}

The WC Route Edit tools (WCEDIT) facilitate the execution of the most
common basic editing scenarios such as adding a new watercourse route,
deleting an existing watercourse route, modifying the end of an existing
watercourse route, reshaping an existing watercourse route, and moving
an existing watercourse route to a new location. WCEDIT can be
downloaded from the Clearinghouse website.

Installing WCEDIT

Download WCEDIT from the Clearinghouse website and uncompress the files.
Before installing WCEDIT, you must know two things:

1.  The path to a valid atool directory,

2.  The path to the directory containing the WCEDIT application.

You must have write access to both the atool directory and the directory
containing the WCEDIT application. Begin Arc/Info and run the install
AML located in the /wcedit/wc/ directory. When prompted, select the
directory containing the WCEDIT application. When prompted, select a
valid atool directory. If WCEDIT installs correctly, you will be
notified.

Beginning WCEDIT

To begin WCEDIT, do the following:

1.  ![](media/image39.png){width="2.9270833333333335in"
    height="2.2604166666666665in"}Navigate to the workspace that
    contains the WC coverage you wish to edit.

2.  Create a backup copy of the WC coverage you wish to edit.

3.  Type *wcedit* at the Arc: prompt.

4.  In the Select WC Cover list that appears, select the WC coverage you
    wish to edit. If you are running on NT, select the **OK** button. If
    you choose none, WCEDIT will end.

5.  ArcEdit will begin. The Main Menu, the ArcEdit graphic window, the
    Status Window, and the Edit Tools Menu will be open. Prior to making
    any edits to the WC coverage, set a pour point and make sure the
    event table default values are correct.

The Main Menu

![](media/image40.png){width="3.8993055555555554in"
height="0.46805555555555556in"}The Main Menu provides access to all
other menus, allows you to set draw and back environments, and allows
you to set default values. The menu includes:

  ------------------------ --------------------- -----------------------------------------
  **[F]{.underline}ile**  Save                  Saves the WCEDIT working copy of the WC
                                                 coverage

                           Save and Make Backup  Saves and makes a backup of the WCEDIT
                                                 working coverage; backups are named
                                                 WC_BKUP\<#####\> and are numbered
                                                 sequentially. If the system crashes,
                                                 replace the WC coverage with the most
                                                 recent backup and then restart WCEDIT and
                                                 resume editing.

                           Save and Exit         Exits WCEDIT and saves all edits made
                                                 during the WCEDIT session back to the
                                                 master WC coverage.

                           Exit and Discard      Exits WCEDIT. Discards all edits made
                           Edits                 during the WCEDIT session including those
                                                 saved to the WCEDIT working copy of the
                                                 coverage.
  ------------------------ --------------------- -----------------------------------------

  ----------------------- ----------------- ---------------------------------------
  **[T]{.underline}ools   Draw Environment  Invokes the Draw Environment Menu. This
  Menus**                                  choice is unavailable if the menu is
                                            already open.

                          Back Environment  Invokes the Back Environment Menu. This
                                            choice is unavailable if the menu is
                                            already open.

                          Snap Settings     Invokes the Snap Settings Menu. This
                                            choice is unavailable if the menu is
                                            already open.

                          Edit Tools        Invokes the Edit Tools Menu. This
                                            choice is unavailable if the menu is
                                            already open.

                          Event Tools       Invokes the Event Tools Menu. No other
                                            menus can be used while this menu is
                                            open.

                          Command Window    Invokes the Enter Command Menu. This
                                            choice is unavailable if the menu is
                                            already open.

                          Status Window     Invokes the Status Window. This choice
                                            is unavailable if the menu is already
                                            open.
  ----------------------- ----------------- ---------------------------------------

+-----------------+-------+------------+------------------------------+
| **[D]           | Nodes | All Nodes  | Draws all nodes.             |
| {.underline}raw |      |            |                              |
| Environment**  |       |            |                              |
+-----------------+-------+------------+------------------------------+
|                 |       | ######## N | Draws node errors (dangle    |
|                 |       | ode Errors | and pseudo) only.            |
+-----------------+-------+------------+------------------------------+
|                 |       | #######    | Removes nodes from the draw  |
|                 |       | # NO Nodes | environment.                 |
+-----------------+-------+------------+------------------------------+
|                 | A     | *Arc       | Draws arc arrows.            |
|                 | rrows | Arrows*    |                              |
|                 |      |            |                              |
+-----------------+-------+------------+------------------------------+
|                 |       | *Route     | Draws route arrows.          |
|                 |       | Arrows*    |                              |
+-----------------+-------+------------+------------------------------+
|                 |       | *NO        | Removes all arrows from the  |
|                 |       | Arrows*    | draw environment.            |
+-----------------+-------+------------+------------------------------+
|                 | L     | *Section   | Labels routes with measures  |
|                 | abels | Measures*  | at section breaks.           |
|                 |      |            |                              |
+-----------------+-------+------------+------------------------------+
|                 |       | *Route     | Labels routes with LLID      |
|                 |       | LLID*      | number.                      |
+-----------------+-------+------------+------------------------------+
|                 |       | *NO        | Removes all labels from the  |
|                 |       | Labels*    | draw environment.            |
+-----------------+-------+------------+------------------------------+

  ----------------- ------------------- --------------- ----------------------
  **Back            Set Back            Arcs            Toggles arcs on and
  Environment**    Environment                        off in the back
                                                        environment.

                                        Labels/Points   Toggles labels
                                                        (points) on and off in
                                                        the back environment.

                                        Filled Polys    Toggles filled
                                                        polygons on and off in
                                                        the back environment.

                    Add Back Coverage                   Add a coverage to the
                                                        back environment.
                                                        Unavailable if the
                                                        Back Environment Menu
                                                        is open.

                    Add Back Image                      Add an image to the
                                                        back environment.
                                                        Unavailable if the
                                                        Back Environment Menu
                                                        is open.
  ----------------- ------------------- --------------- ----------------------

  -------------- ------------- ---------------- -----------------------------
  **Defaults**  Pour Point   Set/Change       Set or change the pour point.

                               Display          Display the set pour point.

                               Show             Show all arcs in the WC
                               Disconnected     coverage that are
                                                disconnected from the set
                                                pour point.

                 Event Tables  Set/Change       Invokes a menu that allows
                              Defaults         you to set or change event
                                                table defaults.
  -------------- ------------- ---------------- -----------------------------

Working with Pour Points

The WC data model requires that all arcs in the coverage point in the
direction of flow. A pour point is the down-stream-most node in a stream
network. Water flows into the pour point but not out of the pour point.
WCEDIT ensures that arcs point in the direction of flow defined by the
pour point. Use the Main Menu (Defaults  Pour Point) to set a pour
point, display the set pour point, and to display all arcs disconnected
from the set pour point.

Set or Change the Pour Point

To set or change the pour point, use the Main Menu and choose: Defaults
 Pour Point  Set/Change. You will be prompt to select a pour point.
Select the pour point node. You can use the [P]{.underline}an/Zoom menu
in the upper left corner of the graphic window if necessary. A green
star will appear highlighting the selected pour point.

Display the Pour Point

To display the pour point, use the Main Menu and choose: Defaults  Pour
Point  Display. A green star will appear highlighting the pour point.

Show Arcs Disconnected from the Pour Point

To highlight arcs disconnected from the pour point (that is, they are
not connected to the watercourse network defined by the pour point), use
the Main Menu and choose: Defaults  Pour Point  Show Disconnected.
Disconnected arcs will appear in green and a green star will appear
highlighting the pour point. The Status Window reports the number of
disconnected arcs.

Setting Default Event Table Values

To ease the input of event table attributes, you can define default
values to use when editing watercourses. The default values are stored
in a text file (wcdefault.txt) in the workspace from which you started
WCEDIT. Set default values using the Main Menu and choose: Defaults 
Event Tables  Set/Change Defaults. The Default Setup Menu will appear.
Enter default values. To invoke a pick-box of valid attribute values,
right click in the input box. In Windows NT, the Edit Date field is
automatically set to the current date. (This function does not currently
work on the UNIX platform.) When you are finished, click the **Save as
Defaults** button to save the entered values as default values and close
the menu.

## 

![](media/image41.png){width="4.051388888888889in"
height="5.072916666666667in"}

Changing the Draw Environment

![](media/image42.png){width="3.1284722222222223in"
height="1.0576388888888888in"}The Draw Environment Menu allows you to
change the draw environment. You can also change the draw environment
using the Main Menu. To change the draw environment using the menu,
click the appropriate button. The current setting is also shown on the
menu. In Unix, the current setting is the depressed choice.

Managing the Back Environment

![](media/image43.png){width="4.110416666666667in"
height="2.1465277777777776in"}The Back Environment Menu allows you
change the back environment and to add coverages and images to it. You
can also change the back environment using the Main Menu. If the Back
Environment Menu is not open, you can also add coverages and images to
the back environment using the Main Menu.

Back Environment

To draw arcs, labels/points, or filled polygons in the back environment,
check the box next to the appropriate option. Uncheck the box to remove
the feature from the back environment.

Back Themes

Press the **Add Coverage** button to add a cover to the back
environment. The list of back themes on the Back Environment Menu will
be updated to include the new added coverage.

Press the **Add Image** button to add an image to the back environment.
The list of back themes on the Back Environment Menu will be updated to
include the new added image.

To display a theme in the back environment, check the box next to the
theme name.

To change the order in which the themes are drawn, press the **Up or
Down Arrows**. Themes display from top to bottom. The theme at the end
of the list draws last. Images always draw before coverages.

To remove a theme from the back environment, click the **Remove** button
next to the theme. In Unix, click the **R** button.

To change the color in which a coverage is drawn, click the **Color**
button next to the theme. In Unix, click the **C** button.

![](media/image44.png){width="2.3027777777777776in"
height="0.9819444444444444in"}Setting Snap Settings

Use the Snap Settings Menu to change the arcsnap and nodesnap
tolerances. Type in a number or slide the bar to change the tolerance.
The initial tolerances are both 20.

Command Window

![](media/image45.png){width="3.752083333333333in" height="0.725in"}

The Enter Command Window allows you to enter ArcEdit commands. Be
careful when entering in commands. Any changes to the edit feature, draw
environment, or back environment will not be reflected in the menus if
they are issued from the Enter Command Menu.

The Status Window

The Status Window displays messages from WCEDIT. Keep this window
visible since this is where WCEDIT reports errors and problems in
executing a request.

![](media/image46.png){width="6.5in" height="0.65625in"}

The Edit Tools Menu

The Edit Tools Menu contains the tools used to make spatial edits to the
WC coverage. There are two edit features available to edit in WCEDIT:
arcs and WC routes. The options available on the Edit Tools Menu change
depending on which edit feature is selected. When WCEDIT begins, the
edit feature is set to WC ROUTES.

There are four sections to the Edit Tools Menu. The first section
toggles the edit feature between arcs and WC routes. The second section
contains feature selection tools. The third section contains rudimentary
zoom tools and the **Undo** button. The final section contains the
editing tools.

Toggle Edit Feature Between Arcs and WC Routes

To change the edit feature, select the button next to the desired
feature. The Edit Tools Menu will change accordingly. You can edit
either arcs or WC routes. When the edit feature is set to WC routes, the
**List LLID** button becomes active. Pressing this button will list the
LLID's of selected WC routes. The LLID's are listed in a popup window
and also in the command window.

Selection Tools

Depending on which feature you are editing, there are different feature
selection tools available. Besides the selection tools, the selection
section of the Edit Tools Menu also reports how many features are
currently selected.

The following means of selecting features are available when editing
[both]{.underline} arcs and WC Routes:

+--------+-------------------------------------------------------------+
| ####   | ######### Selection Method                                  |
| #####  |                                                             |
| Button |                                                             |
+--------+-------------------------------------------------------------+
| **     | All features are unselected                                 |
| None** |                                                             |
+--------+-------------------------------------------------------------+
| *      | Click on one feature to select it                           |
| *One** |                                                             |
+--------+-------------------------------------------------------------+
| **     | Interactively select features. Click on the features you    |
| Many** | wish to select. Press 9 when you are finished selecting     |
|        | features.                                                   |
+--------+-------------------------------------------------------------+
| **     | All features inside a user defined box are selected. Define |
| Within | the box by clicking on two opposite corners                 |
| Box**  |                                                             |
+--------+-------------------------------------------------------------+
| **     | All features within a user defined polygon are selected.    |
| Within | Define the polygon, ending with a double click              |
| Poly** |                                                             |
+--------+-------------------------------------------------------------+

In addition to the tools listed on the previous page, the following is
also available when editing [ARCS]{.underline}:

+--------+-------------------------------------------------------------+
| ####   | ######### Selection Method                                  |
| #####  |                                                             |
| Button |                                                             |
+--------+-------------------------------------------------------------+
| Path   | Select an arc path. Click on the first and last arcs in the |
|        | path. The arcs you clicked on and all arcs in between are   |
|        | selected.                                                   |
+--------+-------------------------------------------------------------+

When editing [WC Routes]{.underline}, you can also select by LLID. Type
an LLID in the input box or right click for a list of LLID's in the WC
coverage.

Zoom Tools

The following zoom tools are available on the Edit Tools Menu:

+--------+-------------------------------------------------------------+
| ####   | ######### Selection Method                                  |
| #####  |                                                             |
| Button |                                                             |
+--------+-------------------------------------------------------------+
| Se     | Zooms to the selected feature(s)                            |
| lected |                                                             |
+--------+-------------------------------------------------------------+
| **Full | Zooms to entire WC coverage                                 |
| View** |                                                             |
+--------+-------------------------------------------------------------+
| **Ref  | Updates the display.                                        |
| resh** |                                                             |
+--------+-------------------------------------------------------------+

In addition, you can pan and zoom using the Pan/Zoom menu in the upper
left corner of the graphic window.

Undo Button

You can undo the last edit performed by clicking the **Undo** Button.
The action that will be undone by clicking the **Undo** Button is
displayed on the Edit Tools Menu next to the **Undo** Button. You cannot
undo any actions completed prior to a save.

Arc Editing Tools

Different editing tools are available on the Edit Tools Menu depending
on the edit feature. When editing arcs, you can heads-up digitize new
arcs, get arcs from another coverage, delete arcs, extend arcs, reshape
an arc, flip selected arcs or flip all arcs to the pour point, split
arcs at a user specified point or vertex, and create a new WC route.

Edit Tools Menu when Editing Arcs

![](media/image47.png){width="3.3229166666666665in"
height="5.540277777777778in"}

When the edit feature is Arcs, the Edit Tools Menu looks like this:

Description of Arc Editing Tools

Following are descriptions of these editing tools:

+--------+-------------------------------------------------------------+
| ####   | ####### Function                                            |
| #####  |                                                             |
| Button |                                                             |
+--------+-------------------------------------------------------------+
| *      | Add new arcs by digitizing on screen. Begin and end each    |
| *Add** | arc with a node. Press 9 when you are finished. Add all     |
|        | arcs such that they point in the direction of flow, which   |
|        | is accomplished by digitizing from headwaters toward        |
|        | confluence..                                                |
+--------+-------------------------------------------------------------+
| *      | Add new arcs by importing them from another coverage. All   |
| *Get** | the arcs in the import coverage will be appended to the WC  |
|        | coverage being edited. After importing the arcs, make sure  |
|        | all of the new arcs point in the direction of flow.         |
+--------+-------------------------------------------------------------+

  ------------- -------------------------------------------------------------
  **Delete**    Delete selected arcs.

  **Extend**    Extends both ends of the select arc(s) the distance
                specified. Specify the distance by clicking a length in the
                graphic window. If the arc to extend encounters another arc
                within the extension distance, the arc to extend is snapped
                to this other arc.

  **Reshape**   Reshape the selected arc. To reshape, digitize the new path,
                making sure to cross the existing arc at both the beginning
                and ending of the reshape. Only one arc can be reshaped at a
                time.

  **Flip**      Flip selected arc(s). Arcs already in a route will NOT be
                flipped, even if they are selected.

  **Flip All**  Flips all arcs not already in a route to the set pour point.
                Arcs not connected to the pour point will not be flipped.
                Arcs do not need to be selected first.

  **Split**     Split selected arc. You can split the arc at a vertex or at
                any point along the arc, depending on which option button is
                selected. The location at which to split the arc is defined
                in both cases by clicking on the screen.

  **Make WC     Creates a new route over the selected arcs. The selected arcs
  Route over    must all connect in a valid path. The path cannot branch or
  Selected      contain cycles. A route will not be created if any of the
  Arcs**        selected arcs are already in another route. The new route
                points opposite flow direction defined by the pour point. The
                indexes of the new route are based on the kilometer length of
                the underlying arcs. A new unique LLID is assigned to the new
                route. The feature history event table (WC.EVT_FTR_HST), the
                feature type event table (WC.EVT_FTR_TYP), and the stream
                flow event table (WC.EVT_STRM_FLOW) are all updated. A single
                event is added to each table encompassing the entire length
                of the new route. The added event is populated with default
                attributes. The other event tables are not updated. If
                necessary, update these using the Event Tools Menu.
  ------------- -------------------------------------------------------------

WC Route Editing Tools

Different editing tools are available on the Edit Tools Menu when
editing WC routes than when editing arcs. The tools available are
designed to help you perform common editing tasks such as deleting a
watercourse, shortening, extending or snapping the end of an existing
watercourse, reshaping an existing watercourse, and moving a selected
watercourse.

These tools make both spatial and event table changes. Where possible,
the tools update the feature history event table (WC.EVT_FTR_HST), the
feature type event table (WC.EVT_FTR_TYP), and the stream flow event
table (WC.EVT_STRM_FLOW) to reflect the spatial change. These automated
updates use the default event values. The other event tables -- the name
event table (WC.EVT_NAME), the river reach file event table
(WC.EVT_RRF), and the line type event table (WC.EVT_LN_TYPE) -- are
updated only when routes are deleted. If necessary, all of the event
tables can be updated using the Event Tools Menu.

Edit Tools Menu when Editing WC Routes

![](media/image48.png){width="3.8958333333333335in"
height="6.510416666666667in"}When the edit feature is WC Routes, the
Edit Tools Menu looks like this:

Description of WC Route Editing Tools

Below are descriptions of each editing tool available when editing WC
routes. The following table describes the impact of the tool on any
event tables.

+----------+-----------------------------------------------------------+
| ####     | ####### **Function**                                      |
| ##### ** |                                                           |
| Button** |                                                           |
+----------+-----------------------------------------------------------+
| **       | Deletes selected WC route(s). If the Route and Arcs       |
| Delete** | button is selected, all arcs underlying the deleted       |
|          | route(s) are also deleted. If the Route Only button is    |
|          | selected, only the route(s) themselves are deleted; the   |
|          | underlying arcs remain.                                   |
+----------+-----------------------------------------------------------+
| **Snap   | Snaps the end of selected route(s) to points in a point   |
| End**    | coverage (the snap coverage). If the end of a selected    |
|          | route is within 30 meters of a point in the snap          |
|          | coverage, the end (last node) of the route will snap. If  |
|          | the end of a selected route is not within 30 meters of a  |
|          | point in the snap coverage, the route end will            |
|          | [not]{.underline} snap. The snap coverage must exist in   |
|          | the same workspace as the edit WC coverage. The name of   |
|          | the defined snap coverage is displayed on the menu. If no |
|          | snap coverage is defined, you will be prompted to select  |
|          | one. Otherwise, the defined snap coverage will be used.   |
|          | To change the snap coverage (and to initially define a    |
|          | snap coverage), use the **Change** button.                |
+----------+-----------------------------------------------------------+
| **       | Extends the selected route over [existing                 |
| Extend** | arcs]{.underline}. (You must add the arcs first.) You     |
|          | cannot extend a route over arcs that are already in a     |
|          | route. When you extend a route, you will be prompted to   |
|          | select the path of arcs over which to extend the route.   |
|          | The selected arcs are appended to the selected route and  |
|          | the measures are adjusted accordingly.                    |
+----------+-----------------------------------------------------------+
| **S      | Shortens the selected route to an [existing               |
| horten** | node]{.underline}. (The node must already exist before    |
|          | you shorten the route.) Any tributaries above the new     |
|          | route ending point will be deleted. You will be prompted  |
|          | to select the node to shorten to if the route contains    |
|          | more than one node. Like with the delete option, you can  |
|          | choose to remove the underlying arcs (all arcs above the  |
|          | new route end point and all arcs underlying any deleted   |
|          | tributary routes) by selecting the **DELETE Arcs**        |
|          | button. To retain all the underlying the arcs, select the |
|          | **KEEP Arcs** button.                                     |
+----------+-----------------------------------------------------------+
| **R      | Reshape the selected route over [existing                 |
| eshape** | arcs]{.underline}. You must add arcs defining the new     |
|          | path, and any arcs necessary to connect tributaries to    |
|          | the new path, [prior]{.underline} to reshaping the route. |
|          | The new path must connect to the route selected for       |
|          | reshape. None of these added arcs can already be in a     |
|          | route. This is a complex edit; do not add extraneous      |
|          | arcs. You will be prompted to select the path to change   |
|          | (the old path). WCEDIT then attempts to determine the new |
|          | path and to connect tributaries to the new path using     |
|          | user input when choices arise.                            |
+----------+-----------------------------------------------------------+
| **Move** | Move the selected route to another set of                 |
|          | [existing]{.underline} arcs. You must add arcs defining   |
|          | the new path [prior]{.underline} to moving the route. The |
|          | selected route cannot contain tributaries. You will be    |
|          | prompted to select the new path.                          |
+----------+-----------------------------------------------------------+
| **Move   | Move the beginning (or mouth) of the selected route. You  |
| Beg      | must add arcs defining the new path [prior]{.underline}   |
| inning** | to moving the route. The new path must connect to the     |
|          | existing route before and tributaries flow into the       |
|          | existing route.                                           |
+----------+-----------------------------------------------------------+

Effects of Route Editing Tools on Event Tables

+--------+------------------------+----------------------+-----------+
| ###    | ##                     |                      |           |
| ###### | ##### **EVENT TABLES** |                      |           |
|  **Too |                        |                      |           |
| l (But |                        |                      |           |
| ton)** |                        |                      |           |
+--------+------------------------+----------------------+-----------+
|        | #####                  | ####                 | ######    |
|        | ## **Feature history** | ### **Feature type** | # **Other |
|        |                        |                      |  Tables** |
|        | ######                 | ####### *            |           |
|        | # **(WC.EVT_FTR_HST)** | *(WC.EVT_FTR_TYPE)** |           |
|        |                        |                      |           |
|        |                        | ###                  |           |
|        |                        | #### **Stream flow** |           |
|        |                        |                      |           |
|        |                        | ####### **           |           |
|        |                        | (WC.EVT_STRM_FLOW)** |           |
|        |                        |                      |           |
|        |                        | **Line type**        |           |
|        |                        |                      |           |
|        |                        | #######              |           |
|        |                        | **(WC.EVT_LN_TYPE)** |           |
+--------+------------------------+----------------------+-----------+
| **De   | A [delete]{.underline} | All events on the    | All       |
| lete** | event is added for     | deleted routes are   | events on |
|        | each deleted route.    | removed from the     | the       |
|        | The event encompasses  | table.               | deleted   |
|        | the entire route.      |                      | routes    |
|        | Default values are     |                      | are       |
|        | used for the           |                      | removed   |
|        | organizational code    |                      | from the  |
|        | (ftr_org_cd) and the   |                      | tables.   |
|        | source date            |                      |           |
|        | (ftr_src_dt). The edit |                      |           |
|        | date (ftr_edit_dt) is  |                      |           |
|        | populated with current |                      |           |
|        | date.                  |                      |           |
+--------+------------------------+----------------------+-----------+
| **Snap | An                     | Event table remains  | Event     |
| End**  | *[update]{.underline}* | unchanged.           | tables    |
|        | event is added for     |                      | remain    |
|        | each snapped route.    |                      | u         |
|        | The new event is one   |                      | nchanged. |
|        | index value long and   |                      |           |
|        | is populated with the  |                      |           |
|        | default event values.  |                      |           |
+--------+------------------------+----------------------+-----------+
| **Ex   | An *[add]{.underline}* | Event encompassing   | Event     |
| tend** | event is added for the | the length of the    | tables    |
|        | extended route. The    | extension and        | remain    |
|        | event encompasses the  | populated with       | u         |
|        | length of the          | default event values | nchanged. |
|        | extension and is       | is added.            |           |
|        | populated with default |                      |           |
|        | event values.          |                      |           |
+--------+------------------------+----------------------+-----------+
| **Sho  | A                      | All events on the    | All       |
| rten** | *[delete]{.underline}* | deleted tributary    | events on |
|        | event encompassing the | routes are removed   | the       |
|        | deleted part of the    | from the table.      | deleted   |
|        | shortened route is     | Events on the        | tributary |
|        | added. A               | shortened route      | routes    |
|        | *[delete]{.underline}* | occurring past the   | are       |
|        | event encompassing the | new ending point are | removed   |
|        | entire route is also   | adjusted.            | from the  |
|        | added for each deleted |                      | table.    |
|        | tributary route.       |                      | Events on |
|        | Default values are     |                      | the       |
|        | used for the           |                      | shortened |
|        | organizational code    |                      | route     |
|        | (ftr_org_cd) and the   |                      | remain    |
|        | source date            |                      | u         |
|        | (ftr_src_dt). The edit |                      | nchanged. |
|        | date (ftr_edit_dt) is  |                      |           |
|        | populated with current |                      |           |
|        | date.                  |                      |           |
+--------+------------------------+----------------------+-----------+
| **Res  | [Reshaped              | Event table remains  | Event     |
| hape** | route]{.underline}:    | unchanged.           | tables    |
|        | *[update]{.underline}* |                      | remain    |
|        | event added along      |                      | u         |
|        | length of reshape      |                      | nchanged. |
|        | using default event    |                      |           |
|        | values. [Shortened     |                      |           |
|        | T                      |                      |           |
|        | ributary]{.underline}: |                      |           |
|        | *[update]{.underline}* |                      |           |
|        | event added using      |                      |           |
|        | default event values.  |                      |           |
|        | [Extended              |                      |           |
|        | T                      |                      |           |
|        | ributary]{.underline}: |                      |           |
|        | *[Add]{.underline}*    |                      |           |
|        | event added along the  |                      |           |
|        | extended segments      |                      |           |
|        | using default event    |                      |           |
|        | values.                |                      |           |
|        | *[Update]{.underline}* |                      |           |
|        | event added along the  |                      |           |
|        | first segment after    |                      |           |
|        | the extension using    |                      |           |
|        | default event values.  |                      |           |
+--------+------------------------+----------------------+-----------+

**Effects of Route Editing Tools on Event Tables continued...**

  ------------- ------------------------ ----------------------- --------------
  **Move**      An                       Existing event          Existing event
                *[update]{.underline}*   encompassing end of     encompassing
                event is added for moved route is adjust to new  end of route
                route encompassing       route end measure if    is adjust to
                entire route using       not 9999.               new route end
                default event values.                            measure if not
                                                                 9999.

  **Move        An                       Event table remains     Event tables
  Beginning**   *[update]{.underline}*   unchanged.              remain
                event is added for                               unchanged.
                portion of route with                            
                new path using default                           
                event values.                                    
  ------------- ------------------------ ----------------------- --------------

Working with Events

The Event Tools Menu can be used to manipulate all event tables
associated with the WC coverage. Before opening the Event Tools Menu,
the WC coverage must be saved; you will not be able to undo any edits
after saving. When the Event Tools Menus is open, no other menus can be
accessed. The edit feature is set to WC routes although no spatial edits
can occur during event editing.

There are six event tables associated with the WC layer:

  ------------------------------ ----------------------------------------
  **[Table Name]{.underline}**   **[Description]{.underline}**

  WC.EVT_FTR_HST                 Feature History Event Table

  WC.EVT_FTR_TYPE                Feature Type Event Table

  WC.EVT_LN_TYPE                 Line Type Event Table

  WC.EVT_NAME                    GNIS Name Event Table

  WC.EVT_RRF                     River Reach File Number Event Table

  WC.EVT_STRM_FLOW               Stream Flow Event Table
  ------------------------------ ----------------------------------------

Of these event tables, two of them, GNIS name event table (WC.EVT_NAME)
and the river reach file number event table (WC.EVT_RRF), are different
in that some of the routes may not have events over them. The remaining
four event tables have events that cover all locations of every route in
the coverage.

There are five sections to the Event Tools Menu. The first section
reminds you that the edit feature is WC routes. The **List LLID** button
will list the LLID's of selected WC routes. The LLID's are listed in a
popup window and also in the command window. The second section contains
selection tools. These tools are the same as those found on the Edit
Tools Menu when the edit feature is set to WC routes. Note that when
editing events, selected routes are drawn in a thick gray line instead
of cyan as during spatial editing. The third section contains zoom tools
and the Undo button. These tools are also the same as those found on the
Edit Tools Menu when the edit feature is set to WC routes. The fourth
sections allows you to display and list events. The final section
contains event editing tools.

![](media/image49.png){width="3.9902777777777776in"
height="5.754166666666666in"}Event Tools Menu

The Event Tools Menu looks like this:

Displaying Events

Display events using the Event Theme section of the Event Tools Menu.
Enter the name of a table from which to display event in the **Table:**
input box. Right click in the input box to bring up a pick list of the
six event tables. Enter the field from the event table listed in the
**Table:** input box to display by entering the field name in the
**Display:** input box. Right click in the input box to bring up a
pick-list of valid fields. Some fields are consistently displayed with
the same legend. Others are generated based on the values available in
the event table. Note that colors may be reused if the number of unique
values is large. The ends of each event are displayed with a short
yellow hatch. If the Selected Routes Only check box is checked, display
is restricted to events on selected routes only. This can significantly
improve redraw times on large coverages.

The **Identify** button lets you click on the spatial location of an
event displayed in the graphic window and see its values. The clicked
event is temporarily colored yellow. The **Key** button generates a
legend of colors used to display the chosen event field.

Description of Event Editing Tools

Edit events using the Edit Events section of the Event Tools Menu. The
table identified in the **Table:** input box in the Event Theme section
of the Event Tools Menu is the event table that can be edited. Use the
**Table:** input box to select a different table to edit.

+----------+-----------------------------------------------------------+
| ####     | ####### **Function**                                      |
| ##### ** |                                                           |
| Button** |                                                           |
+----------+-----------------------------------------------------------+
| **Add    | You must have a single route selected when adding an      |
| Event**  | event. It will prompt you to click on the ends of the new |
|          | event (must be on the same route!), confirm the location, |
|          | and fill in the attribute table. If the new event is at   |
|          | the end of a route, it is strongly recommended that you   |
|          | select and adjust the end of the event by snapping it to  |
|          | the node, otherwise a portion of the previous event may   |
|          | remain. If you add an event with a value that is not      |
|          | present in the coverage already, you may need to use the  |
|          | "display" control to reinitialize the color-coding of the |
|          | events.                                                   |
+----------+-----------------------------------------------------------+
| **Select | Graphically select a single event. It will be highlighted |
| Event**  | in yellow                                                 |
+----------+-----------------------------------------------------------+
| **Attr   | Displays a menu that allows you to change the attributes  |
| ibutes** | of the selected event.                                    |
+----------+-----------------------------------------------------------+
| **       | Use to delete a selected event in the GNIS name event     |
| Delete** | table (WC.EVT_NAME) or the river reach file number event  |
|          | table (WC.EVT_RRF) only! Since the other event tables     |
|          | must have complete coverage, events can only be deleted   |
|          | by adding new or adjusting existing events over the top   |
|          | of the events that you want to remove.                    |
+----------+-----------------------------------------------------------+
| **Adjust | Modify the location of a selected event by one of the     |
| End**    | three snapping methods: (1) no snapping, (2) snap to      |
|          | node, or (3) snap to end of existing event. If the        |
|          | location selected is in the middle of the event, you will |
|          | be prompted to indicate whether to move the upstream or   |
|          | downstream end of the event at that location. To move the |
|          | end of the event to the location indicated by the cursor, |
|          | select the **None** button. To snap to an exiting node,   |
|          | select the **Node** button. To snap to the end of another |
|          | event on the same route, select the **Existing Event**    |
|          | button.                                                   |
+----------+-----------------------------------------------------------+

Closing the Event Editor

Press the Close Event Editor button to close the Event Tools Menu and
return control to the Edit Tools Menu. Once the Event Tools Menu is
closed, you can resume spatial edits to the WC layer.

Ending WCEDIT

Use the Main Menu to end WCEDIT. There are two exit options. You can
exit WCEDIT saving all edits made during the edit session, or you can
exit WCEDIT without saving any edits made during the edit session. The
options are described below:

  -------------------------- --------------------------------------------
  **[F]{.underline}ile**    Exits WCEDIT and saves all changes to the WC
  Exit and Save              coverage and associated event tables.

  **File**  Exit and        Exits WCEDIT and discards all changes to the
  Discard Edits              WC coverage and associated event tables made
                             during the edit session, [even if the edits
                             were saved]{.underline} using the
                             [F]{.underline}ile  Save option on the Main
                             Menu. The WC coverage and associated event
                             tables revert back to the pre-edit state.
  -------------------------- --------------------------------------------

Topology in the WC coverage is rebuilt after exiting.

## Appendix B -- Guide to the Line Type / Centerline Update Tool {#appendix-b-guide-to-the-line-type-centerline-update-tool .TOC_REWORK___1}

The Line Type Update Tool (LTUPDATE) helps automate updates to the WC
line type event table (WC.EVT_LN_TYPE). LTUPDATE is included in the
WCEDIT download and will automatically be installed when WCEDIT is
installed. LTUPDATE will:

-   Help ensure that all line type event measures are accurately
    adjusted and properly snapped to water body shorelines.

-   Help ensure that line type events exist for all new watercourses or
    segments of watercourses.

-   Create a centerline event table in your workspace that may or may
    not be used by your agency. You can delete or ignore the centerline
    table if your agency does not need it.

The WC line type event table includes two primary attributes:

-   The line type code (WC_LN_TYPE_CD) indicates the main cartographic
    function of each line regardless of the feature or hydrologic
    function it represents.

-   The flow path code (WC_FLOW_PATH_CD) defines the flow hierarchy of
    watercourse centerlines that are within water bodies and is used to
    define and segregate out various flow pathways through water bodies.

Spatial changes to watercourses or water bodies can affect the beginning
and or ending measures of line type events. The following types of
changes can impact the accuracy of line type events:

-   Adding or deleting a water body or watercourse feature,

-   Altering the shape or position of a watercourse that flows wholly or
    partially through a water body feature, and

-   Altering the shape or position of a water body.

There are two steps to LTUPDATE: the automated update and the
interactive review. LTUPDATE first tries to automate updates to the line
type event table. It then checks for potential errors and discrepancies
in the table. If any are found, an interactive review of these
potentially erroneous events follows the automated update.

**Installing LTUPDATE**

LTUPDATE is installed when WCEDIT is installed. See the [Guide to WC
Route Edit Tools (WCEDIT)]{.underline} for installation instructions.

**Beginning LTUPDATE**

To begin LTUPDATE, do the following:

1.  Navigate to the workspace that contains the WC for which you wish to
    update the line type event table. The workspace must also contain a
    WB coverage associated with the WC coverage.

2.  Type ltupdate at the Arc: prompt.

3.  ![](media/image50.png){width="2.645669291338583in"
    height="2.041732283464567in"}![](media/image51.png){width="2.6251968503937007in"
    height="2.0311023622047246in"}In the Select WC Cover list that
    appears, select the WC coverage whose line type event table you wish
    to update. If you are running on NT, select the OK button. If you
    choose none, LTUPDATE will end.

4.  In the Select WB Cover list that appears, select the WB coverage
    associated with the WC coverage you selected. If you are running on
    NT, select the OK button. If you choose none, LTUPDATE will end.

5.  LTUPDATE begins with the automated update process.

**The Automated Update Process**

In the automated process, LTUPDATE creates a NEW line type event table
by intersecting the watercourses with polygons derived from the water
body coverage. The original OLD line type event table also remains in
the workspace. The program automatically populates the line type and
flow path events in the NEW table and then validates or modifies them by
comparing it to the OLD line type event table. The tool adds a status
field to the NEW table and marks the events that have been validated as
'OK'. The status field for events that cannot be validated against the
OLD table are left blank and must be interactively reviewed in the next
step of the process. The tool also checks for water bodies where there
are interior lines that have either no event or multiple events coded as
the primary flow path. When either situation occurs, the status of all
interior lines in the water body is left blank.

In more detail, the automated process does the following:

1.  Creates a polygon cover from water body regions and attaches the
    region attributes to the polygons.

2.  Makes a backup of the OLD (original, unmodified) line type event
    table to use for processing.

3.  Creates a NEW line type event table by intersecting the watercourse
    routes with the water body polygons. Adds a status field to the NEW
    event table to keep track of modifications.

4.  Processes and populates the line type code (WC_LN_TYPE_CD) and the
    flow path code (WC_FLOW_PATH_CD) in the NEW event table using
    predetermined assumptions.

5.  Compares the line type codes (WC_LN_TYPE_CD) and the flow path codes
    (WC_FLOW_PATH_CD) in the NEW event table against those in the OLD
    event table.

6.  Events where the LLID (WC_LLID_NR), the beginning index
    (WC_BEGIN_AD), the ending index (WC_END_AD), the line type code
    (WC_LN_TYPE_CD) and the flow path code (WC_FLOW_PATH_CD) are
    identical are marked "OK" in the status field.

7.  Events where the LLID (WC_LLID_NR), the beginning index
    (WC_BEGIN_AD), and the ending index (WC_END_AD) are identical but
    where the line type code (WC_LN_TYPE_CD) and/or the flow path code
    (WC_FLOW_PATH_CD) are not identical are processed through preset
    routines that determine whether to accept the new codes or copy over
    the old codes. These events are then marked as "OK" in the status
    field.

8.  Artificial connector events in the old table are moved to the new
    table when matching LLID's exist and are then marked as "OK" in the
    status field.

9.  Events in the NEW event table with no match in the OLD event table
    or those that have not yet been marked as "OK" are flagged for
    interactive processing. Interior events occurring within water
    bodies where no or multiple primary flow paths are designated are
    also flagged for interactive review. If everything is OK, the
    interactive processing step is skipped.

**The Interactive Review Process**

If some potential errors or discrepancies were encountered during the
automated update of the line type event table, the interactive review
phase is started. ArcEdit is begun, the Line Type Event Editor window is
opened, and the graphic window is zoomed into the first event to check.
Both the NEW updated line type events and the OLD line type events are
displayed. The WC coverage also is displayed in the background.

**The Graphic Window**

When interactive processing is required, arc coverages are created from
both the OLD and NEW line type event tables. The new_lines cover is set
up as the edit cover in ArcEdit; the old_lines cover is the back
coverage. The old_lines cover is symbolized using the flow path code
(WC_FLOW_PATH_CD) value + 1 (e.g. if the flow path code is 2, then color
is 3) and the lines are offset slightly from the edit cover. An example
of the graphic window is shown below.

![](media/image52.png){width="5.947916666666667in" height="3.34375in"}

![](media/image53.png){width="3.579861111111111in"
height="4.676388888888889in"}**The Line Type Event Editor Menu**

The Line Type Event Editor Menu opens with a cursor open on the events
in the NEW event table that are not yet marked as "OK" in the status
field.

The top of the menu shows the attributes for the selected event.

The menu displays the LLID (WC_LLID_NR), beginning index value
(WC_BEGIN_AD), ending index value (WC_END_AD), current line type code
(WC_LN_TYPE_CD), and the current flow path code (WC_FLOW_PATH_CD) for
the selected event.

Use the Line Type and/or Flow Path scrolling lists to change the
applicable field.

Use **EVENT OK** when the data is correct to mark the status field as
"OK".

**SPLIT EVENT** lets you split an event into two or more events.

**NEXT FEATURE IN SET** moves the graphic display and the menu to next
record in the selected set (the next event to review).

**SELECT ONE OR MANY** facilitates graphic selection of one or more
lines and opens a cursor on the set.

**SELECT STATUS NOT OK** selects records where Status field is not OK.

**SELECTED SET** zooms in on selected line(s).

**FULL VIEW** zooms out to the full extent of the edit coverage.

![](media/image54.png){width="3.3in"
height="1.4631944444444445in"}**DISPLAY ENVIRONMENT** opens the Display
Environment Tool Menu. This menu allows you to make quick changes to the
drawing or background environment.

Use the **Arcedit Command:** input box to enter valid ArcEdit commands
if needed.

The **HELP** button opens a message box explaining the interactive
phase.

**SAVE EDITS** writes saves all unsaved changes to the current edit
coverage.

**CLOSE** dismisses the menu, exits ArcEdit, and continues the line type
update process.

**Reviewing Events Using the Line Type Event Editor Menu**

The Line Type Event Editor Menu steps through the event(s) to review one
at a time. The process to use when reviewing events is described below:

1.  When the Line Type Event Editor Menu is opened, the first event to
    review is selected and the graphic window is zoomed into this first
    event.

2.  Review the event and make any changes that are necessary. Use the
    pick lists to change the line type code (WC_LN_TYPE_CD) or the flow
    path code (WC_FLOW_PATH_CD) as needed. If the spatial extent of the
    event is incorrect, use the **SPLIT EVENT** button and follow
    instructions in the command window. The Split Event tool closes the
    cursor on the initial selected set and opens a new cursor on the
    events created from the split. When the split events are processed,
    click the **SELECT STATUS NOT OK** button to reselect the
    unprocessed events and open a new cursor.

3.  When the event data is correct, click the **EVENT OK** button to
    mark the status field as "OK".

4.  Click the **NEXT FEATURE IN SET** button to advance to the next
    event to review. You will be informed when there are no more events
    left to review.

5.  When you have finished reviewing, click the **CLOSE** button to
    close the menu. It will save unsaved edits and check for records not
    yet marked "OK" and, if any are found, give the user chance to
    return to the interactive review process.

**Ending LTUPDATE**

**Interactive Update Process is Bypassed**

If LTUPDATE does not enter the interactive process, the line type event
table is automatically updated and the centerline (CENTERLINES) event
table is created. The centerline event table stores centerline
information as reach events on the routed watercourse coverage. You can
delete or ignore the centerline table if your agency does not need it.

**Interactive Update Process is Used**

![](media/image55.png){width="2.35in" height="1.8145833333333334in"}Once
you have finished with your review and edits, you are prompted to
replace the OLD line type event table with the NEW (modified) line type
event table.

Select **YES** to replace the OLD line type event table with the NEW
(modified) line type event table. The OLD line type event table is
retained and is called WC.EVT_LN_TYPE_OLD. The centerline (CENTERLINES)
event table is also created. The centerline event table stores
centerline information as reach events on the routed watercourse
coverage. You can delete or ignore the centerline table if your agency
does not need it.

Click **NO** to stop the update process. You are prompted to either
return to the interactive review process or to quit LTUPDATE and start
over. If you choose to quit and start over, the line type event table
remains unchanged and all interim covers and tables created during the
update process are deleted.

-   
-   
-   

```{=html}
<!-- -->
```
-   
-   

```{=html}
<!-- -->
```
-   
-   
-   

1.  
2.  
3.  
4.  
5.  

```{=html}
<!-- -->
```
6.  
7.  
8.  
9.  
10. 
11. 
12. 
13. 
14. 
15. 
16. 
17. 
18. 
19. 
20. 
21. 
22. 
23. 
24. 
25. 
26. 
27. 
28. 
29. 
30. 
31. 
32. 
33. 
34. 

```{=html}
<!-- -->
```
6.  
7.  
8.  
9.  
10. 
11. 
12. 
13. 
14. 
15. 
16. 
17. 
18. 
19. 
20. 

**THIS PAGE LEFT INTENTIONALLY BLANK**

## Appendix C -- Training Exercises {#appendix-c-training-exercises .TOC_REWORK___1}

## Exercise A: Editing Water Points {#exercise-a-editing-water-points .toc_2}

This exercise shows explicitly an example of editing water points. In
this exercise, you will add a perennial spring feature, the location of
which was collected using GPS. The GPS location of the spring has
already been imported into a separate point coverage called spring. This
coverage is located in the training workspace. Since the point to add is
in a separate coverage, it is easiest to determine the LLID for the
point before adding it to the water point layer.

**Determine the LLID of the spring point to add.**

1.  Project the spring coverage to geographic coordinates in decimal
    degrees. The projection for the spring coverage is already defined
    so you only need to enter the output projection information.

Arc: **project cover spring spring_geo**

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

\* The INPUT projection has been defined. \*

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

Use OUTPUT to define the output projection and END to finish.

Project: **output**

Project: **projection geographic**

Project: **units dd**

Project: **parameters**

Project: **end**

2.  Add the X-Y coordinates to the point attribute table (PAT) of the
    newly projected coverage. The coordinates will be in geographic
    decimal degree coordinates.

Arc: **addxy spring_geo point**

3.  List the PAT of the project coverage and note the LLID. The LLID is
    the first 7 numbers of the X-Coord value (longitude) followed by the
    first 6 digits of the Y-Coord value (latitude). For the spring
    point, the LLID is 1181735452777.

Arc: **list spring_geo.pat**

1

AREA = 0.00000

PERIMETER = 0.00000

SPRING_GEO# = 1

SPRING_GEO-ID = 1901

X-COORD = -118.17359

Y-COORD = 45.27779

4.  Check that this LLID does not already exist in the water point
    coverage. If the new LLID does not already exist in the WP coverage
    you checked out from the Clearinghouse and the point to be added is
    not near the boundary of the area you checked out from the
    Clearinghouse, then you can be reasonably sure the new LLID is
    unique within the water point layer. To check that the new LLID does
    not exist in the water point layer checked out from the
    Clearinghouse, start tables, select the water point PAT, and
    reselect any records with the new LLID. If no records are found, the
    new LLID is unique. If records are found, add 1 to the new LLID
    until the new LLID is unique.

Arc: **Tables**

Tables: **select wp.pat**

Tables: **reselect WP_LLID_NR = '1181735452777'**

0 Records Selected.

Tables: **quit**

**Begin editing the water point layer in ArcEdit.**

1.  Start ArcEdit.

Arc: **ArcEdit**

2.  Set your edit coverage to the water point layer. The water point
    layer is called WP. Set the edit feature to points.

ArcEdit: **edit wp point**

3.  Set the draw environment to draw the points.

ArcEdit: **drawenvironment points**

4.  Add the spring coverage in the background with red points and
    refresh the graphic window.

ArcEdit: **backcoverage spring 2**

ArcEdit: **backenvironment points**

ArcEdit: **draw**

**Add the spring point to the water point coverage, attribute the point
in the PAT, and save your edits.**

1.  Add the spring point to the water point coverage.

ArcEdit: **get spring**

2.  The new spring point should be selected. If it is not selected,
    select it now by clicking on it in the graphic window.

ArcEdit: **Select**

3.  Assign the new LLID to the new point.

ArcEdit: **calculate WP_LLID_NR = \'1181735452777\'**

4.  Populate the rest of the attributes in the PAT. The new point
    feature is a perennial spring.

ArcEdit: **calculate WP_HYDR_FTR_CD = 'SP'**

ArcEdit: **calculate WP_CART_FTR_CD = 300**

ArcEdit: **calculate WP_PERIOD_CD = 'per'**

5.  Save your edits to the water point layer.

ArcEdit: **Save**

**Add a record to the related feature history table and save edits to
the table.**

1.  Begin editing the related feature history table (WP.REL_FTR_HST).

ArcEdit: **edit WP.REL_FTR_HST info**

2.  Add a record. The added record will remain the selected record.

ArcEdit: **add**

3.  Populate the attributes. Use the LLID of the new point. Enter
    today's date in the feature edit date field (FTR_EDIT_DT) in
    4-digit-year-month-day format. For example, October 9, 2001 will
    be 20011009. Enter the rest of the fields as shown.

ArcEdit: **Calculate WP_LLID_NR = '1181735452777'**

ArcEdit: **Calculate FTR_MOD_CD = 'add'**

ArcEdit: **Calculate FTR_INPUT_CD = 4**

ArcEdit: **Calculate FTR_INTRP_CD = 2**

ArcEdit: **Calculate FTR_SRC_CD = 5**

ArcEdit: **Calculate FTR_SRC_DT = 20010928**

ArcEdit: **Calculate FTR_SRCSCALE_NR = 0**

ArcEdit: **Calculate FTR_ACCUR_NR = 0**

ArcEdit: **Calculate FTR_ORG_CD = 'usblm'**

ArcEdit: **Calculate FTR_EDIT_DT = \<today's date\>**

4.  Save edits to the feature history table.

ArcEdit: **Save**

**Quit ArcEdit and build the water point layer.**

1.  Quit ArcEdit.

ArcEdit: **quit**

2.  Build the water point layer.

Arc: **build wp point**

**This completes exercise A.**

**THIS PAGE LEFT INTENTIONALLY BLANK**

## Exercise B: Editing Water Body Shorelines {#exercise-b-editing-water-body-shorelines .toc_2}

![](media/image56.jpeg){width="2.1354166666666665in"
height="1.9166666666666667in"}This exercise shows explicitly an example
of editing water body shorelines. In this exercise, you will add a
perennial lake feature, the location of which will be digitized from a
USGS topographic quad. The digital form of the USGS topographic quad,
known as a DRG, is located in the training workspace. In this exercise,
you add the feature to the water body shoreline layer. In the next
exercise, you add the feature to the water body layer. Since no
watercourses flow into the added water body, no changes to the WC line
type event table are necessary.

**Step 1 -Begin editing the water body shoreline layer in ArcEdit**

1.  Start ArcEdit.

Arc: **ArcEdit**

2.  Set your edit coverage to the shoreline layer. The shoreline layer
    is called WS. Set the edit feature to arcs.

ArcEdit: **edit ws arcs**

3.  Set the draw environment to draw arc arrows and node errors.

ArcEdit: **drawenvironment arc arrows node errors**

4.  Add the DRG image in the background.

ArcEdit: **image drg**

ArcEdit: **draw**

5.  Zoom in, pan, and center the map extent around Hunter Lake. (Hint:
    Hunter Lake is to the west of Twin and Morgan Lakes.)

**Step 2 - Digitize the new shoreline boundary.**

1.  Add the new shoreline, digitizing from the background image.
    Digitize the lake boundary in one arc with smooth curves. Connect
    the beginning of the arc to the end. Begin the arc at the southern
    end of the lake and digitize clockwise so that water is on the right
    side. Since Hunter Lake is not near the boundary of the area checked
    out from the Clearinghouse, the entire lake shoreline falls with the
    checked out boundary.

ArcEdit: Add

**Step 3 - Determine the LLID of the new shoreline.**

1.  The arc you added in step 2 should still be selected. If it is not
    selected, select it now by clicking on it in the graphic window.

ArcEdit: **select**

2.  Find the beginning coordinates of the arc. The coordinates will be
    in the same projection as the WS coverage. The first set of
    coordinates contains those of the beginning of the arc. The
    X-coordinate is reported first, followed by the Y-coordinate. The
    second set contains those of the end of the arc. Because the arc
    begins and ends at the same point, both the beginning and ending
    coordinates of the arc are the same. Your coordinate values may be
    slightly different than this example.

Arcedit: **show arc \[show select 1\] vertex 1**

408198.5925044,5016786.595219

3.  Put the coordinate information into a text file. Name the text file
    coordws.txt. The text file should have one line consisting of the
    X-coordinate, followed by a space, followed by the Y-coordinate. The
    method of doing this will vary depending on your system
    configuration and the text editors available to you. Ask your
    instructor if you need more help. Make sure the text file does not
    have any tabs.

4.  Convert the coordinate in the coordinate text file (coordws.txt) to
    geographic coordinates in decimal degrees. The output will be
    another text file called coordws_geo.txt. The input projection for
    the text file is the same as the projection of the WS coverage. In
    this case, the input projection is UTM, zone 11, NAD27. Project is
    an arc command so it needs to be run from an arc prompt.

ArcEdit: **&sys arc project file coordws.txt coordws_geo.txt**

Please define the input and output map projections. Use INPUT to define
the input projection, OUTPUT to define the output projection, and END to
finish.

Project: **input**

Project: **projection utm**

Project: **zone 11**

Project: **units meters**

Project: **datum nad27**

Project: **parameters**

Project: **output**

Project: **projection geographic**

Project: **units dd**

Project: **datum nad27**

Project: **parameters**

Project: **end**

5.  Look at the text file resulting from the project command
    (coordws_geo.txt). It should contain one line of geographic
    coordinates. The LLID is the first 7 numbers of the X-Coord value
    (longitude) followed by the first 6 digits of the Y-Coord value
    (latitude). Suppose the text file is: -118.17086971 45.30053811. The
    LLID would be 1181708453005. Your LLID may be slightly different,
    depending on where you started the arc digitized in step 2.

**Step 4 - Create the new shoreline route.**

1.  Add an item to the shoreline arc attribute table (AAT) to store arc
    lengths in kilometers. If this item already exists in the AAT, you
    do not need to add it.

ArcEdit: **additem KILO 7 7 n 3**

2.  Select the arc you digitized in step 2 by clicking on it in the
    graphic window.

ArcEdit: **select**

3.  Calculate the kilometer length of the arc. Since the units of the WS
    coverage in this example are meters, the kilometer length of the arc
    is the length divided by 1000. A different conversion factor should
    be used if the WS coverage units are not meters.

ArcEdit: **calculate KILO = LENGTH / 1000**

4.  Save the WS coverage.

ArcEdit: **save**

5.  Select the arc you digitized in step 2 by clicking on it in the
    graphic window.

ArcEdit: **select**

6.  Create a route in the WS route system using the KILO item for
    indexes.

ArcEdit: **makeroute ws \# KILO**

7.  Remove the arcs from the draw environment, add WS routes with
    arrows, and refresh the graphic window.

ArcEdit: **drawenvironment arc off route.ws arrows**

ArcEdit: **draw**

8.  Note the direction of the new route. It should point clockwise such
    that water is on the right side. If the new route does not point in
    the correct direction, change the edit feature to WS routes, select
    the route by clicking on it in the graphic window, and flip it.

ArcEdit: **editfeature route.ws**

ArcEdit: **select**

ArcEdit: **flip**

ArcEdit: **draw**

**Step 5 - Assign the new route a unique LLID**

1.  Change the edit feature to WS routes if you have not already done
    so.

ArcEdit: **editfeature route.ws**

2.  Check that the LLID determined in Step 3 does not already exist in
    the shoreline coverage. If the new LLID does not already exist in
    the WS coverage you checked out from the Clearinghouse and the new
    shoreline to be added is not near the boundary of the area you
    checked out from the Clearinghouse, then you can be reasonably sure
    the new LLID is unique within the shoreline layer. To check that the
    new LLID does not exist in the shoreline layer checked out from the
    Clearinghouse, select routes with the new LLID. If no routes are
    found, the new LLID is unique. If records are found, add 1 to the
    new LLID until the new LLID is unique. In this example, the new LLID
    determined in step 3 is 1181708453005. Your new LLID may be slightly
    different.

ArcEdit: **select WS_LLID_NR = '1181708453005'**

0 element(s) now selected

3.  Select the new shoreline route by clicking on the route in the
    graphic window.

ArcEdit: **select**

4.  Assign the new LLID. In this example, the new LLID is 1181708453005.
    Your new LLID may be slightly different.

ArcEdit: **calculate WS_LLID_NR = '1181708453005'**

**Step 6 - Populate the rest of the attributes in the WS route attribute
table.**

1.  The shoreline you added is a freshwater shoreline. It is also the
    default shoreline.

ArcEdit: **calculate WS_DATUM_CD = 'fw'**

ArcEdit: **calculate WS_DFLT_SHORE_CD = 'y'**

**Step 7 - Populate the shoreline type event table.**

The entire route has the same shoreline type code so only one record
needs to be added to this table. The new event will encompass the entire
route.

1.  Select the new route if it not already selected by clicking on it in
    the graphic window.

ArcEdit: **select**

2.  Determine the measure at the end of the route. In this example the
    route begins at 0 and ends at 0.295. Your ending measure may be
    slightly different.

ArcEdit: **show route.ws \[show select 1\] measures**

Write down your measure here (i.e.: 0,0.295)
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

3.  Begin editing the Shoreline Type Event Table (WS.EVT_SL_TYPE).

ArcEdit: **edit WS.EVT_SL_TYPE info**

4.  Add a record. The added record will remain the selected record.

ArcEdit: **add**

5.  Populate the attributes. Use the LLID of the new shoreline route. In
    this example, the new LLID is 1181708453005. Your new LLID may be
    slightly different. The entire shoreline you added is a freshwater
    shoreline (code = 3). Since the entire route is included in this
    event, the beginning address is zero and the ending address is the
    end of the route. In this example, the ending route measure is
    0.295. Yours may be slightly different.

ArcEdit: **Calculate WS_LLID_NR = '1181708453005'**

ArcEdit: **Calculate WS_BEGIN_AD = 0**

ArcEdit: **Calculate WS_END_AD = 0.295**

ArcEdit: **Calculate WS_TYPE_CD = 3**

**Step 8 - Populate the feature history event table.**

The entire route has the same feature history so only one record needs
to be added to this table also. The new event will encompass the entire
route.

1.  Begin editing the feature history event table.

ArcEdit: **edit WS.EVT_FTR_HST info**

2.  Add a record. The added record will remain the selected record.

ArcEdit: **add**

3.  Populate the attributes. Use the LLID of the new shoreline route. In
    this example, the new LLID is 1181708453005. Your new LLID may be
    slightly different. Since the entire route is has the same feature
    history, the beginning address of this single event is zero and the
    ending address is the end of the route. You determined the measure
    at the end of the route in step 7 above. In this example, the ending
    route measure is 0.295. Yours may be slightly different. Enter
    today's date in the feature edit date field (FTR_EDIT_DT) in
    4-digit-year-month-day format. For example, October 9, 2002 would
    be 20021009. Since this is a new shoreline feature, the feature
    modification code (FTR_MOD_CD) is *add*. Enter the rest of the
    fields as shown.

ArcEdit: **Calculate WS_LLID_NR = '1181708453005'**

ArcEdit: **Calculate WS_BEGIN_AD = 0**

ArcEdit: **Calculate WS_END_AD = 0.295**

ArcEdit: **Calculate FTR_MOD_CD = 'add'**

ArcEdit: **Calculate FTR_INPUT_CD = 6**

ArcEdit: **Calculate FTR_INTRP_CD = 99**

ArcEdit: **Calculate FTR_SRC_CD = 1**

ArcEdit: **Calculate FTR_SRC_DT = 20010928**

ArcEdit: **Calculate FTR_SRCSCALE_NR = 24000**

ArcEdit: **Calculate FTR_ACCUR_NR = 12.192**

ArcEdit: **Calculate FTR_ORG_CD = 'usblm'**

ArcEdit: **Calculate FTR_EDIT_DT = \<enter today's date\>**

**Step 9 - Save changes, exit out of ArcEdit, and build the shoreline
layer.**

Since you are done editing, you can also delete the coordinate text
files created in step 3.

1.  Exit out of ArcEdit. When prompted to save, choose yes.

ArcEdit: **quit**

Keep all edit changes (Y/N): **yes**

This will replace all changes back into the original coverage(s) and/or
INFO file(s)

Do you really want to do this (Y/N): **yes**

2.  Build the shoreline coverage.

Arc: **build ws line**

3.  Remove the KILO item from the arc attribute table.

Arc: **dropitem ws.aat ws.aat KILO**

**Step 10 - Since the shoreline added is a default shoreline, the
corresponding water body needs to be added to the water body layer. The
next exercise will add the new water body.**

**This completes Exercise B.**

**THIS PAGE LEFT INTENTIONALLY BLANK**

## Exercise C: Editing Water Bodies {#exercise-c-editing-water-bodies .toc_2}

This exercise explicitly shows an example of editing water bodies. In
this exercise, you will add a perennial lake feature, the shoreline of
which has already been input into the water body shoreline layer in the
previous exercise.

**Step 1 - Begin editing the water body layer in ArcEdit.**

1.  Start ArcEdit.

Arc: **ArcEdit**

2.  Set your edit coverage to the water body layer. The water body layer
    is called WB. Set the edit feature to arcs.

ArcEdit: **edit wb arcs**

3.  Set the draw environment to draw arcs, labels, node errors.

ArcEdit: **drawenvironment arc label node errors**

4.  Draw the shoreline layer in red in the background and refresh the
    graphic window.

ArcEdit: **backcover ws 2**

ArcEdit: **backenvironment arcs**

ArcEdit: **draw**

5.  Zoom in, pan, and center the map extent around Hunter Lake. (Hint:
    Hunter Lake is to the west of Twin and Morgan Lakes.)

**Step 2: Get the new water body boundary from the shoreline layer.**

1.  Edit the shoreline layer, setting the edit feature to arcs.

ArcEdit: **edit ws arcs**

2.  Select the arc comprising the new water body boundary by clicking on
    it in the graphics window. This is the arc you added in the last
    exercise.

ArcEdit: **select**

3.  Put the arc into the water body layer. When asked if you want to
    append, answer, "yes".

ArcEdit: **put wb**

Coverage WB already exists. Do you want to append \<Y/N\>: YES

**Step 3: Add a label to the new water body and update polygon
topology.**

1.  Change the edit coverage back to the water body layer with an edit
    feature of label.

ArcEdit: **edit wb label**

2.  Add a new label inside the new water body boundary.

ArcEdit: **Add**

3.  Build the water body layer for polygons.

ArcEdit: **build**

**Step 4: Determine the LLID of the new water body.**

1.  If the label you added in step 2 is not selected, select it now by
    clicking on it in the graphics window.

ArcEdit: **select**

2.  Find the coordinates of the label. These coordinates will be in the
    same projection as the WB coverage. The X-coordinate is reported
    first, followed by the Y-coordinate. Your coordinate values may be
    slightly different than this example.

Arcedit: **show label \[show select 1\] coordinate**

408181.3554572,5016827.802574

3.  Put the coordinate information into a text file. Name the text file
    coordwb.txt. The text file should have one line consisting of the
    X-coordinate, followed by a space, followed by the Y-coordinate. The
    method of doing this will vary depending on your system
    configuration and the text editors available to you. Ask your
    instructor if you need more help. Make sure the text file does not
    have any tabs.

4.  Convert the coordinate in the coordinate text file to geographic
    coordinates in decimal degrees. The output will be another text file
    (coordwb_geo.txt). The input projection for the text file is the
    same as the projection of the WB coverage. In this case, the input
    projection is UTM, zone 11, NAD27. Project is an arc command so it
    needs to be run from an arc prompt.

ArcEdit: **&sys arc project file coordwb.txt coordwb_geo.txt**

Please define the input and output map projections. Use INPUT to define
the input projection, OUTPUT to define the output projection, and END to
finish.

Project: **input**

Project: **projection utm**

Project: **zone 11**

Project: **units meters**

Project: **datum nad27**

Project: **parameters**

Project: **output**

Project: **projection geographic**

Project: **units dd**

Project: **datum nad27**

Project: **parameters**

Project: **end**

5.  Look at the text file resulting from the project command
    (coordwb_geo.txt). It should contain one line of geographic
    coordinates. The LLID is the first 7 numbers of the X-Coord value
    (longitude) followed by the first 6 digits of the Y-Coord value
    (latitude). Suppose the text file is: -118.17109715 45.30090671. The
    LLID would be 1181710453009. Your LLID may be slightly different,
    depending on where you added the new label.

**Step 5: Create the water body region feature.**

1.  Change the edit feature to polygons.

ArcEdit: **editfeature polygon**

2.  Remove arcs, nodes, labels from the draw environment and add
    polygons. Refresh the graphic window.

ArcEdit: **drawenvironment arc off node off label off polygon**

ArcEdit: **draw**

3.  Select the new water body polygon by clicking on it in the graphics
    window.

ArcEdit: **select**

4.  Create a new region feature in the WB region subclass from the
    polygon.

ArcEdit: **makeregion wb**

**Step 6: Assign the new water body region a unique LLID**

1.  Change the edit feature to the WB region subclass.

ArcEdit: **editfeature region.wb**

2.  Remove polygons from the draw environment and add the WB region
    subclass. Refresh the graphic window.

ArcEdit: **drawenvironment polygon off region.wb**

ArcEdit: **draw**

3.  Check that this LLID determined in step 4 does not already exist in
    the water body coverage. If the new LLID does not already exist in
    the WB coverage you checked out from the Clearinghouse and the new
    water body added is not near the boundary of the area you checked
    out from the Clearinghouse, then you can be reasonably sure the new
    LLID is unique within the water body layer. To check that the new
    LLID does not exist in the water body layer checked out from the
    Clearinghouse, select region features with the new LLID. If no
    region features are found, the new LLID is unique. If records are
    found, add 1 to the new LLID until the new LLID is unique. In this
    example, the new LLID is 1181710453009. Your new LLID may be
    slightly different.

ArcEdit: **select WB_LLID_NR = '1181710453009'**

0 element(s) now selected

4.  Select the new water body region feature by clicking on it in the
    graphics window.

ArcEdit: **select**

5.  Assign the new LLID. In this example, the new LLID is 1181710453009.
    Your new LLID may be slightly different.

ArcEdit: **calculate WB_LLID_NR = '1181710453009'**

**Step 7: Attribute the new water body region feature.**

1.  Populate the region attributes as shown below.

ArcEdit: **Calculate WB_HYDR_FTR_CD = 'LA'**

ArcEdit: **Calculate WB_CART_FTR_CD = 421**

ArcEdit: **Calculate WB_GNIS_NM = 'Hunter Lake'**

ArcEdit: **Calculate WB_GNIS_NR = 1122152**

ArcEdit: **Calculate WB_PERIOD_CD = 'int'**

**Step 8: Save, quit ArcEdit and build the water body layer.**

Save the water body (WB) coverage.

ArcEdit: **save**

Quit ArcEdit.

ArcEdit: **quit**

Build the water body layer.

Arc: **build wb polys**

**This completes Exercise C.**

**THIS PAGE LEFT INTENTIONALLY BLANK**

## Exercise D: Editing Watercourses using WCEDIT {#exercise-d-editing-watercourses-using-wcedit .toc_2}

In this exercise, you will do a variety of edits to a watercourse layer.
This is a long exercise and may take awhile to complete. You will add a
new watercourse based on contour crenulations, delete an existing
watercourse, snap the end points of two existing watercourses to new
locations, extend an existing watercourse, shorten an existing
watercourse, and reshape an existing watercourse. Finally, you will
review event tables associated with the watercourse (WC) layer. All of
the edits will be performed using WCEDIT. The next exercise will
describe how to update the line type event table using LTUPDATE. All
necessary background coverages and images are located in the training
workspace.

**Step 1- Start WCEDIT**

1.  From the training workspace, start WCEDIT.

Arc: **wcedit**

Select the WC coverage from the list that appears.

Define the pour point for the WC coverage.

a.  From the **Main Menu**, select: **Defaults  Pour Point 
    Set/Change**

b.  **Select the pour point when prompted**. You can use the
    [P]{.underline}an/Zoom menu in the upper left corner of the graphic
    window if needed. The pour point is the northern-most node. A green
    star will appear at the selected pour point.

Prepare for edits by defining the background environment. You will add
two background coverages (gps_channel and gps_endpts) and a background
image (drg). The gps_channel coverage is a line coverage and the
gps_endpts coverage is a point coverage.

c.  From the **Main Menu**, select: **Tool Menus  Back Environment** to
    open the Back Environment Menu

d.  On the **Back Environment Menu**, **make sure there is a check next
    to Arcs** and a check in the **checkbox next to Labels/Points.**
    These are the feature types you wish to draw in the background.

e.  On the **Back Environment Menu**, click: Add **Coverage**

f.  On the **Get Back Coverage Menu** that appears, select
    ***gps_channel*** from the **Select a Coverage** list box. From the
    **Symbol** list that appears, **select a bright color**. This will
    add the gps_channel coverage to the back environment with the color
    you selected. This coverage will not automatically draw in the
    graphic window when added. **Turn on the coverage by clicking the
    checkbox next to its name**.

g.  On the **Back Environment Menu**, click the **Add Coverage** button
    again to add another coverage to the back environment.

h.  On the **Get Back Coverage Menu** that appears, select
    ***gps_endpts*** from the **Select a Coverage** list box. From the
    **Symbol** list that appears, select another bright color. This will
    add the gps_endpts coverage to the back environment with the color
    you selected. **Turn on the coverage by clicking the checkbox next
    to its name**.

i.  On the **Back Environment Menu**, now click the **Add Image** button
    to add an image to back environment.

j.  On the **Get Back Image Menu** that appears, select ***drg.tif***
    from the **Select an Image** list box. This will add the image to
    the back environment. **Turn on the image by clicking the checkbox
    next to its name**.

![](media/image57.jpeg){width="2.25in" height="2.15625in"}**Step 2 -
Adding A New Watercourse**

The new watercourse is a tributary to Graves Creek (LLID 1182042453200)
and is shown in red on the map. It is in section 34. The location of the
new watercourse will be digitized on screen from the contours in the
background image.

1.  Pan and zoom to the area shown on the map to the right. This is
    where the new watercourse will be added.

2.  Add the new watercourse arcs.

    a.  ![](media/image58.png){width="3.5520833333333335in"
        height="0.48333333333333334in"}On the **Edit Tools Menu**, click
        the button next to **ARC** to change the edit feature to arcs.

    b.  Click the **Add** button to add new arcs.

    c.  ![](media/image59.png){width="3.9791666666666665in"
        height="0.3020833333333333in"}**Digitize the new watercourse
        arc.** Begin the arc at the upstream end of the watercourse
        stream and end it at its junction with Graves Creek. The new arc
        should connect with Graves Creek; there should be no overshoots
        or undershoots so correct any that occur. You can draw node
        errors by selecting Draw Environment  Nodes  Node Errors from
        the **Main Menu**. Check the direction of the new arc by adding
        arc arrows to the draw environment. Select Draw Environment 
        Arrows  Arc Arrows from the **Main Menu**. The arc should point
        downstream (towards Graves Creek).

3.  Create the new watercourse route.

    a.  Check the default event table attributes. When creating a new
        route, events on the new route will automatically be created
        using the default attributes. From the **Main Menu**, select:
        Defaults ** Event Tables  Set/Change Defaults** to bring up
        the **Default Setup Menu**.

    b.  Fill out the menu as shown on the next page, then click the
        **Save as Defaults** button to save any changes.

![](media/image60.png){width="3.6284722222222223in"
height="4.555555555555555in"}

c.  Select the new arc added above if it is not already selected. Use
    the selection option on the **Edit Tools Menu**.

d.  ![](media/image61.png){width="3.9479166666666665in"
    height="0.3020833333333333in"}Click the **Make WC Route over
    Selected Arcs** button to create the route. The **Status Window**
    will let you know when the route has been created.

e.  ![](media/image62.png){width="3.125in"
    height="1.2604166666666667in"}You can use the Draw Environment Menu
    to check the route. To bring up the **Draw Environment Menu**,
    select: **Tool Menus  Draw Environment** from the **Main Menu**.
    Draw route arrows by clicking on the **Route** button in the
    *Arrows:* row. Display route measures by clicking on the
    **Measures** button in the *Labels:* row. Verify that the route
    points upstream (away from Graves Creek) and that the measures begin
    at zero and get larger as they progress upstream.

![](media/image63.png){width="2.2291666666666665in"
height="1.8645833333333333in"}**Step 3 - Delete the Route with an LLID
of 1181019452069.**

The data steward has already coordinated with appropriate partners and
all agree that the delineation of the stream is a mapping error and the
stream does not truly exist.

1.  Delete the route.

    a.  ![](media/image64.png){width="3.9791666666666665in"
        height="0.5in"}On the **Edit Tools Menu**, click the button next
        to **WC ROUTES** to change the edit feature to routes.

    b.  ![](media/image65.png){width="3.96875in"
        height="1.4166666666666667in"}Select the watercourse to delete.
        Use the **Edit Tools Menu** to select a watercourse by LLID.
        Right click in the **Select LLID =** input box to bring up a
        pick list of unique LLID's in the WC coverage you are editing.
        Select: **1181019452069**.

> To zoom to the selected watercourse, click the **Selected** button
> next to the *ZOOM TO:* label. If the background image is in your way,
> use the **Back Environment Menu** to turn the image off. Uncheck the
> box next to the image name on the **Back Environment Menu**.

c.  ![](media/image66.png){width="3.9583333333333335in"
    height="0.4791666666666667in"}Delete the watercourse. Since you want
    to delete both the route and the underlying arcs, make sure the
    button next to **Route and Arcs** under the **Delete** button on the
    **Edit Tools Menu** is selected. Click the **Delete** button to
    delete the selected route.

> The **Status Window** will tell you when the route has been deleted.
> When finished, notice that the route and all underlying arcs are
> deleted. All records for the deleted route are also removed from the
> event tables. A single delete event is added for this route to the
> feature history event table.

**Step 4 - Extend route 1181754453168 using contour crenulations. The
extension is shown in red on the map below.**

1.  Pan and zoom to the area shown on the map below. If necessary, turn
    on the background image using the **Back Environment Menu**. (Check
    the box next to the image name.)

2.  Add new arcs defining the length of the extension.

    a.  ![](media/image58.png){width="3.75in"
        height="0.5104166666666666in"}On the **Edit Tools Menu**, click
        the button next to **ARC** to change the edit feature to arcs.

    b.  Click the **Add** button to add new arcs.

    c.  ![](media/image59.png){width="3.9791666666666665in"
        height="0.3020833333333333in"}**Digitize the new arc as shown in
        red on the map.** Begin the arc at the [new]{.underline}
        upstream end of the watercourse and end it at the current
        endpoint of route 1181754453168. The new arc should connect with
        route 1181754453168; there should be a pseudo node where the new
        arc connects with the existing route 1181754453168. Check that
        the new arc points downstream.

```{=html}
<!-- -->
```
3.  Extend the route.

    a.  On the **Edit Tools Menu**, click the button next to **WC
        ROUTES** to change the edit feature to routes.

    b.  Use the **Edit Tools Menu** to select the route to extend (LLID
        = 1181754453168).

    c.  Check the default event table attributes. Events on the route
        extension will automatically be created using the default
        attributes. From the **Main Menu**, select **Defaults  Event
        Tables  Set/Change Defaults** to bring up the **Default Setup
        Menu**. In this case, no changes should be necessary. The
        default attributes set when adding a watercourse are still
        appropriate.

    d.  Click the **Extend** button. When prompted, select the path to
        extend. Click on the first arc in the path then click on the
        last arc in the path. In this case, the path consists of only
        one arc so click on the arc twice. When asked if you want to
        extend the route over the selected path, choose *yes*. The
        **Status Window** will let you know when the route has been
        extended.

    e.  ![](media/image68.png){width="3.9791666666666665in"
        height="0.21875in"}Check the edited route. Make sure the route
        still points upstream. If your draw environment still includes
        measures, notice that the measures continue to increase
        upstream.

**Step 5 - Move the Endpoints of Route 1181624452440 and Route
1182042453200**

The data steward has recently gone into the field and located the
endpoints of these routes with GPS. The new endpoints are within 30
meters of the existing endpoints so the existing route endpoints can be
snapped to the new GPS endpoints. The GPS endpoints are in the
gps_endpts coverage. This coverage should already be displayed in the
back environment.

1.  Pan and zoom into the area shown on the map. You should be able to
    see the GPS endpoints and the ends of routes 1181624452440 and
    1182042453200.

2.  Check the default event table attributes. When snapping the end of a
    route, a one meter feature history event is added using the default
    attributes.

    a.  ![](media/image69.png){width="1.34375in" height="2.6875in"}From
        the **Main Menu**, select **Defaults  Event Tables  Set/Change
        Defaults** to bring up the **Default Setup Menu**.

> ![](media/image70.png){width="3.234722222222222in"
> height="4.044444444444444in"}

b.  The default attributes set when adding a watercourse are now no
    longer appropriate since the new endpoint locations were determined
    using GPS and not by using contours. **Fill out the menu as shown**,
    then click the **Save as Defaults** button to save any changes.

```{=html}
<!-- -->
```
3.  Define a snap coverage and snap the endpoints.

    a.  On the **Edit Tools Menu**, click the **Change** button next to
        the **Snap End** button. This will allow you to define or change
        the snap coverage used when snapping route ends.

    b.  ![](media/image71.png){width="3.9895833333333335in"
        height="0.5104166666666666in"}In the **Select Point Cover to
        Snap To** pick list that appears, select *gps_endpts*. Notice
        that **Edit Tools Menu** now displays *gps_endpts* as the snap
        cover.

    c.  **Select route 1181624452440** using the **Edit Tools Menu**.
        Click the **Snap End** button to snap the endpoints. The
        **Status Window** will tell you when the endpoint has been
        snapped. Notice that the endpoint moves to the GPS endpoint
        location. If your draw environment still includes measures,
        notice that the endpoint measures do not change. A single event
        is added to the Feature History Event Table using the default
        attributes. No other events are changed or added.

    d.  Now **select route 1182042453200** and click the **Snap End**
        button to snap its endpoint.

![](media/image72.png){width="1.2597222222222222in"
height="2.254861111111111in"}**Step 6 - Shorten route 1181511451973**

The data steward has already coordinated with appropriate partners and
all agree that the delineation of the stream and its tributary is a
mapping error. After checking in the field, they conclude that the
stream ends at the point indicated by the red dot on the map and the
tributary stream does not exist.

1.  Pan and zoom into the area shown on the map. You may want to turn
    off the background image.

```{=html}
<!-- -->
```
2.  Create a node at the new endpoint.

    a.  Make sure your draw environment contains node errors. If
        necessary, use either the **Main Menu** or the **Draw
        Environment Menu** to add node errors to the draw environment.

    b.  On the **Edit Tools Menu**, click the button next to **ARC** to
        change the edit feature to arcs.

    c.  Use the **Edit Tools Menu** to select the arc that will contain
        the new endpoint. (The first arc of route 1181511451973.)

    d.  ![](media/image73.png){width="4.010416666666667in"
        height="0.2708333333333333in"}Since you want to split the
        selected arc at a specific point and not at a specific vertex,
        click on the **point** option (next to the **Split** button) on
        the **Edit Tools Menu**.

    e.  Click the **Split** button then click on the selected arc in the
        graphic window approximately at the location of the red dot on
        the map. A pseudo node will be created where you clicked.

3.  Shorten route 1181511451973 and delete its tributary.

    a.  On the **Edit Tools Menu**, click the button next to **WC
        ROUTES** to change the edit feature to routes.

    b.  Using the **Edit Tools Menu**, select route 1181511451973 if it
        is not already selected.

    c.  Since you do not want to keep the arcs after shortening the
        route, click on the **DELETE Arcs** option next to the
        **Shorten** button.

    d.  Click the **Shorten** button. When prompted, click on the node
        delineating the new endpoint of route 1181511451973. (This is
        the node added above.) Answer "yes" when asked if you want to
        shorten the route to the star and delete the tributary routes.
        The **Status Window** will inform you when the route has been
        shortened and the tributary deleted.

    e.  ![](media/image74.png){width="4.010416666666667in"
        height="0.4895833333333333in"}Inspect the shortened route.
        Notice that the measures are adjusted. The event tables for the
        shortened route are also adjusted and a delete event is added to
        the feature history event table to indicate that part of the
        route has been deleted. All records for the deleted tributary
        route are removed from the event tables and a single delete
        event is added for this route to the feature history event
        table.

![](media/image75.png){width="2.3958333333333335in"
height="3.1041666666666665in"}**Step 7 - Reshape Rock Creek (LLID
1182268453419)**

A major event has occurred, causing a change in the stream channel. The
change in the channel location impacts two tributaries: the mouths of
routes 1181216452375 and 1181260452375 must be moved to intersect with
the new channel. The data steward has recently gone into the field and
used GPS to find the new locations. The GPS locations are in the
gps_channel coverage. This coverage should already be displayed in the
back environment.

1.  Pan and zoom into the area shown on the map above. You should be
    able to see the arcs defining the new channel in the background.

2.  Bring the arcs defining the new channel into the current WC coverage
    you are editing.

    a.  On the **Edit Tools Menu**, click the button next to **ARC** to
        change the edit feature to arcs.

    b.  ![](media/image59.png){width="3.9791666666666665in"
        height="0.3020833333333333in"}Click the **Get** button to get
        arcs from another coverage. In the **Get Cover Window** that
        appears, select the *gps_channel* cover. The arcs from the
        *gps_channel* coverage will be imported into the WC coverage you
        are editing. Notice that the imported arcs connect to the
        existing stream network. If they do not connect, connect them
        now.

    c.  Check that the imported arcs point in the direction of flow
        (downstream). Using either the **Main Menu** or the **Draw
        Environment Menu**, add arc arrows to the draw environment.
        Select any of the imported arcs that do not point in the correct
        direction and flip them by clicking the **Flip** button on the
        **Edit Tools Menu**.

3.  Reshape Rock Creek.

    a.  On the **Edit Tools Menu**, click the button next to **WC
        ROUTES** to change the edit feature to routes.

    b.  Select route 1182268453419 (Rock Creek) using the **Edit Tools
        Menu**.

    c.  Check the default event table attributes. Events on the route
        reshaped route and any impacted tributaries will automatically
        be updated using the default attributes. From the **Main Menu**,
        select Defaults  Event Tables  Set/Change Defaults to bring up
        the **Default Setup Menu**. In this case, no changes should be
        necessary. The default attributes set when snapping endpoints
        are still appropriate.

    d.  ![](media/image76.png){width="4.114583333333333in"
        height="0.2708333333333333in"}Click the **Reshape** button to
        begin the reshape process. When prompted to *Select path to
        change*, select the first and last arc of the old stream
        channel. When asked if you want to "Reshape GREEN to YELLOW
        (tribs extended along blue path)?", **answer "yes".** Note that
        the yellow path shown in the graphic window should be the same
        as the path of the new channel shown in red on the map. The blue
        path shown in the graphic window should be the same as that
        shown in green on the map.

    e.  The **Status Window** will let you know when the reshape process
        is finished. When finished, notice that Rock Creek has now been
        reshaped along the GPS path. The beginning of the tributary to
        the south of Rock Creek (LLID = 1181260452375) has been extended
        so that the mouth of the stream now intersects with the new Rock
        Creek path. The beginning of the tributary to the north of Rock
        Creek (LLID = 1181216452375) has been shortened so that the
        mouth of the stream intersects with the new Rock Creek path. If
        you still have measures in your draw environment, notice that
        the measures on Rock Creek at the beginning of the reshape, and
        the end of the reshape, and at each tributary junction have not
        changed.

**Step 8 - Examine Events**

You are now finished with the spatial edits. Before exiting WCEDIT, take
a look at the events on the routes that you edited.

1.  From the **Main Menu**, select **Tool Menus  Event Tools** to open
    the **Event Tools Menu**. When asked if it's ok to accept previous
    edits, answer "yes". Note: you may want to turn off all draw
    environment features before opening the **Event Tools Menu**.

2.  First, examine some events on the route you reshaped in the previous
    step. You should already be zoomed into the area around the reshaped
    route. Let's look at some of the name attribute.

    a.  On the **Event Tools Menu**, right click in the **Table:** input
        box and select *NAME* from the pick list that appears.

    b.  Right click in the **Display:** input box and select *Name* from
        the pick list that appears.

    c.  ![](media/image77.png){width="3.533333333333333in"
        height="1.1041666666666667in"}Uncheck the box next to **Selected
        routes only** if it is checked.

    d.  The name event displays in the graphic window. Click the **Key**
        button to bring up a key showing what each color displayed in
        the graphic window means. Notice that the reshaped segment still
        contains the correct name event (Rock Creek).

    e.  Display some of the other events using the **Event Tools Menu**.
        To display an item from a different table, right click in the
        **Table:** input box and select a different table, then right
        click in the **Display:** input box and select an item to
        display from that table. The yellow tick marks that sometimes
        appear in the graphic window indicate the beginning and ending
        of events. Some of the line type events may not be correct.
        Instead of fixing the errors now, you will update the line type
        event table using LTUPDATE in the next exercise.

3.  Use the [P]{.underline}an/Zoom function of the graphic window to
    look at events on other routes you have edited during this exercise.

4.  When you are finished examining events, close the **Event Tools
    Menu** by clicking the **Close Event Editor** button.

**Step 9 - Exit from WCEDIT and Save Edits**

5.  From the **Main Menu**, select **File  Exit and Save** to exit
    WCEDIT and save edits to the WC coverage.

**This completes Exercise D.**

## Exercise E: Using LTUPDATE {#exercise-e-using-ltupdate .toc_2}

In this exercise, you will update the WC line type event table using
LTUPDATE. You must update the WC line type event table after editing the
WC layer in the previous exercise. There are two steps to LTUPDATE: the
automated update and the interactive review. LTUPDATE first tries to
automate updates to the line type event table. It then checks for
potential errors and discrepancies in the table. If any are found, an
interactive review of these potentially erroneous events follows the
automated update.

**Step 1 - Start LTUPDATE and Initiate the Automated Update.**

1.  From the training workspace, start LTUPDATE.

Arc: **ltupdate**

> **Select the WC coverage** you edited in the previous exercise from
> the list that appears.
>
> **Select the WB coverage** associated with the selected WC coverage
> from the list that appears.
>
> **Wait while LTUPDATE tries to automatically update the line type
> event table**.

LTUPDATE creates a "new" line type event table by intersecting the
watercourses with polygons derived from the water body coverage. The
original "old" line type event table also remains in the workspace. The
program automatically populates the line type and flow path events in
the "new" table and then validates or modifies them by comparing it to
the "old" line type event table. The tool also adds a status field to
the new table and marks the events that have been validated as 'OK'. The
status fields for events that cannot be validated against the old table
are left blank and must be interactively reviewed in the next step of
the process. The tool also checks for water bodies where there are
interior lines that have either no event or multiple events coded as the
primary flow path. When either situation occurs, the status of all
interior lines in the water body is left blank.

**Step 2 - Interactively Review New and Modified Line Type Events**

Since some potential errors or discrepancies were encountered during the
automated update of the line type event table, the interactive phase is
started. The **Line Type Event Editor window** is opened and the graphic
window is zoomed into the first event to check. Both the "new" updated
line type events and the "old" line type events are displayed. The WC
coverage also is displayed.

1.  The first events to check are the line type events on the
    watercourse with LLID = 1181754453168. This is the watercourse that
    was extended in the previous exercise. No line type events were
    created on the extended part of the watercourse during the extension
    process in WCEDIT. During the automated update process, LTUPDATE
    modified the existing line type event to go to the new end of the
    watercourse. Notice from the graphic window (see below) that the
    event selected to review goes to the end of the watercourse. From
    the **Line Type Event Editor window**, the line type code
    (WC_LN_TYPE_CD) is 10 (single line watercourse) and the flow path
    code (WC_FLOW_PATH_CD) is 3 (not applicable). These are the correct
    attributes. No changes need to take place; the automated process
    correctly updated the line type event table for this route. Press
    the **EVENT OK** button on the **Line Type Event Editor window** to
    indicate that you have reviewed the event and found it acceptable.

2.  ![](media/image78.png){width="3.6251968503937007in"
    height="4.572047244094488in"}![](media/image79.png){width="1.8228346456692914in"
    height="2.5in"}Press the **NEXT FEATURE IN SET** button on the
    **Line Type Event Editor window** to continue with the review
    process and zoom to the next feature to review.

3.  The next event to check is the line type event on the watercourse
    that was added in the previous exercise. In this example, it is the
    route with LLID = 1181652452556. Your LLID may be slightly different
    depending on where you digitized the mouth of the new stream
    watercourse. Once again, no line type events were created on the new
    watercourse during the add route process in WCEDIT. During the
    automated update process, LTUPDATE added a line type event for the
    new watercourse using the default value line type code value of 10
    (single line watercourse) and the default flow path value of 3 (not
    applicable). Notice from the graphic window (see below) that the
    event added for the new watercourse includes the entire route. The
    **Line Type Event Editor window** shows that the line type code
    (WC_LN_TYPE_CD) is the default value of 10 (single line watercourse)
    and the flow path code (WC_FLOW_PATH_CD) is the default value of 3
    (not applicable). These are the correct attributes so no changes are
    needed for this route either. The automated process correctly added
    the line type event for this new route. Press the **EVENT OK**
    button on the **Line Type Event Editor window** to indicate that you
    have reviewed the event and found it acceptable.

4.  ![](media/image80.png){width="3.6251968503937007in"
    height="4.572834645669292in"}![](media/image81.png){width="1.8228346456692914in"
    height="2.5in"}Press the **NEXT FEATURE IN SET** button on the
    **Line Type Event Editor window** to continue with the review
    process and zoom to the next feature to review. You are prompted
    that there are no more features to review. Click **OK** to close the
    prompt.

5.  Press the **CLOSE** button on the **Line Type Event Editor window**
    to finish with the interactive mode.

6.  **Answer "Yes"** when asked if you are finished editing.

7.  **Answer "Yes"** when asked if you are ready to replace the OLD
    table.

LTUPDATE replaces the current event table with the newly created one.
The old event table is retained and is called WC.EVT_LN_TYPE_OLD.
LTUPDATE also creates a centerline event table called CENTERLINES. The
centerline event table can be discarded or ignored if your agency does
not use it.

**This completes Exercise E.**

[^1]: Note this role is not identified in the PNW Hydrography Framework
    Clearinghouse Roles and Responsibilities document.