**NHD Data Migration -- Crosswalk Recommendations**

**Review Document**

**May 4, 2006**

**Background**

The Pacific Northwest Hydrography Framework (PNWHF) is poised to migrate
the Hydrography Clearinghouse dataset for the Oregon/Washington area to
the NHD data format. Developing the crosswalk between the LLID-based
PNWHF Clearinghouse data format and the NHD format has been challenging
because there is not an exact 1:1 relationship between the two formats.
Even so, nearly all existing hydrography clearinghouse data elements and
attributes can be accommodated by the new NHD data structure. Data
elements or attributes without a target location in the NHD format are
handled via extensions to the data model. Data elements that are no
longer considered a PNWHF requirement are recommended to be dropped from
the PNWHF and will be handled internally by the partner organization
having the requirement.

In all instances, even with additional tables, the NHD data format has
been left intact. Where needed the NHD data format has been extended by
adding new related tables. The PNWHF technical working group met several
times to address the crosswalk and has developed recommendations on
"how" to transfer the clearinghouse data elements into the NHD. This
document contains these recommendations along with discussion on why the
approach is recommended.

**Assumptions**

The migration to the NHD represents an acceptable level of change
although it introduces a different way to organize the hydrography data
here in the Pacific Northwest. For the most part, the NHD and existing
LLID-based clearinghouse datasets attempt to address the same business
requirement.

A period of adjustment in each partner organization to the NHD data can
be expected. Most partners will employ the used of publication formats
to make this change as transparent as possible for their internal data
users. The NHD dataset, in its native format, will be available for
hydrologic modeling and for use with applications such as the USFS NRIS
Water and the BLM ARIMS applications.

All data elements representing validated PNWHF requirements are retained
in the extended NHD data format.

Initially the LLID will be modeled as an event on the NHD route system.
In addition, we are considering a permanent table with the NHD basic
features (ComIDs) explicitly tied to the whole stream identifier. In
that scenario the LLID in the form of a NHD event takes care of a PNW
business need during the migration phase, but later, there will be a
table with this link so there is no question of what basic features make
up a particular stream.

The final PNWHF NHD data format needs to minimize administrative costs
and the cost to each partner organization. This is accomplished by
keeping the core NHD geodatabase design intact.

The final PNWHF NHD data format needs to support a simplified process of
transacting on the national NHD database. This is accomplished by
keeping the core NHD geodatabase design intact.

**Recommendations**

Below are recommendations and discussion points. These are organized
around the source data input to the crosswalk. Issues associated with
the existing clearinghouse WC, WB, WS, and WP datasets are addressed in
order.

**Watercourse (WC)**

The PNW Hydrography Framework Clearinghouse definition: "*[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 will be 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 feature has
been modeled to allow for flow modeling. All arcs must point downstream.
This layer will be routed using the LLID identifier for the stream. All
associated attributes are stored as event tables on the LLID routes. The
stream routes are indexed starting from 0 at the mouth of the stream to
some maximum value at the headwaters. All route measures will be
initially calibrated 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. This will be accomplished by
stretching or shrinking the measure values to accommodate lengthening or
shrinking along the route as its X,Y coordinates are edited. Thus, over
time, the measures will only approximate kilometers along a watercourse
or shoreline. These measures are simply an indexing scheme for linear
referencing, not a stored attribute of shoreline or watercourse
length."*[^1]

> **WC_LN_TYPE_CD (event)** Clearinghouse definition: *Watercourse line
> type code. The type of watercourse feature that is represented in the
> database. Code used to differentiate the primary cartographic function
> of the lines regardless of the hydrographic feature or hydrologic
> function they represent*

***Example: 20***

> Discussion: The PNW attribute values directly map into NHD[^2]
> subtypes such as stream/river, connector, or artificial path. Note: In
> addition to the line type code the complete NHD attribute values for
> individual watercourse features were derived from queries of several
> different PNW attributes such as the hydrographic feature code, the
> cartographic feature code, and the periodicity code.
>
> Options: Use NHD subtypes
>
> Recommended Action: Use NHD subtypes
>
> **WC_FLOW_PATH_CD (event)** Clearinghouse definition: *Watercourse
> flow path code. Defines the flow hierarchy of stream centerlines that
> exist within water body features. This code is used to define and
> segregate out the various flow pathways through water bodies. These
> centerlines usually have a WC_LN_TYPE_CD of 20 or 21.*
>
> Domain of Attribute Values: Primary, Secondary, and Not Applicable
>
> Discussion: The BLM has used this attribute for their production
> processes in the past. BLM may not even use this attribute now. While
> the Washington DNR utilizes this attribute, the USFS does not. Note:
> When level is populated in the NHD, then this will provide the main
> path through the waterbody.
>
> Recommended Action: Use the NHD artificial path. If BLM still requires
> this attribute for flow path calculations, then it should be
> maintained in a separate table or part of a BLM internal database.
>
> WC_GNIS_NM
>
> Clearinghouse Definition: *Watercourse GNIS name. The name of the
> feature as represented within the Geographic Names Information System
> (GNIS). The USGS is the mandated source of this information. Not all
> features contained within the coverage will have GNIS names.*

*Example: Deschutes River*

> **WC_GNIS_NR**
>
> Clearinghouse Definition: *Watercourse GNIS (Geographic Names
> Information System) number. The unique identifier number assigned to
> each feature name represented within the GNIS database. This number is
> used to insert and/or update watercourse names stored in the framework
> hydrography database. Not all features contained within the coverage
> will have GNIS number.*
>
> Discussion: These two attributes map directly into NHD attributes.
> Local names, i.e. those names that are not in the GNIS, can be carried
> by individual agencies as event tables. Agencies that wish to have
> "local names" considered for the GNIS and NHD must initiate a Domestic
> Geographic Names proposal and work through their respective State
> Board of Geographic Names.
>
> Recommended Action: Use NHD attributes.
>
> WC_HYDR_FTR_CD Clearinghouse Definition: *Watercourse hydrographic
> feature code. The code used to describe the hydrographic feature type
> that the watercourse represents.*
>
> *Example: ST*
>
> **WC_CART_FTR_CD** Clearinghouse Definition: *Watercourse cartographic
> feature code. The code used to describe the cartographic feature type
> that the watercourse represents. This represents feature codes
> developed initially by the USGS and used on the DLG's.*
>
> *Example: 412*
>
> Discussion: The NHD attributes were populated in a pre-processing AML
> that derived NHD attributes by querying the PNW attributes
> hydrographic feature code, cartographic feature code, periodicity, and
> the line type. With the exception of the state of Washington, most
> partner agencies do not use the WC_CART_FTR_CD. There is the problem
> of unknown feature types that will be encountered in the densification
> process. Note: According to Mike Braymen, USFS, there are only
> [nine]{.underline} unknown feature types.
>
> WC_RRF_NR Clearinghouse Definition: *Watercourse River Reach File
> number. This represents the unique identifier used by the USEPA. A
> unique identifiers is carried on individual stream segments, running
> confluence to confluence. The identifier is comprised of 3 components
> -- the watercourse hydrographic unit code number, the watercourse
> river reach file segment number, and the watercourse river reach file
> mile number. The source of this data will be USGS National Hydrography
> Database (NHD) once Washington State 100K hydrography is incorporated
> into that database. Not all stream segments have been assigned a RRF
> number by the USGS. In some cases this information in not necessarly
> available.*
>
> Discussion: The NHD Reach Code supercedes this attribute.
>
> Recommended Action: Drop attribute
>
> **WC_PERIOD_CD** Clearinghouse Definition: *Watercourse periodicity
> code. This is a classification for watercourses in terms of the
> seasonal behavior of the feature over time or in terms of its surface
> flow.*
>
> Domain: perennial, intermittent, ephemeral, unknown
>
> Discussion: All attribute values of the PNW dataset map into the NHD
> with the exception of unknown. Ephemeral is now part of the NHD
> standards and the new NHD GeoEdit Tools can handle this attribute
> value. For ditches and pipelines periodicity is not present in the
> NHD. So those two features can be mapped directly into the NHD without
> the pediodicity attribute value.
>
> **Q.** What will happen to features that change periodicity in the
> middle of an existing stream segment? ***A**.* The NHD edit tools will
> be able to split the feature.
>
> UNKNOWN values: PNW will utilize the generic stream/river feature for
> all unknown values. This will flag the streams so that they can be
> classified correctly by the data stewards.
>
> Recommended Action: Use the NHD attribute values including generic
> stream/river.
>
> WC_CONTU_CD *Clearinghouse definition: Watercourse continuity code.
> This is the classification of stream flow primarily in relation to its
> expression at the earth's surface. The most common condition is that a
> stream is continuous in space. With respect to continuity, streams may
> be divided into continuous streams and interrupted steams. An
> interrupted stream is one that contains (a) perennial stretches with
> intervening intermittent or ephemeral stretches or (b) intermittent
> stretches with intervening ephemeral stretches. These two classes of
> interrupted streams are designated respectively, perennial interrupted
> streams and intermittent interrupted streams. A continuous stream is
> one that does not have interruptions in space.*
>
> ***Example of use with Periodicity Code:** You do not need to separate
> out each small segment of perennial, intermittent or ephemeral stream.
> If they sporadically exist along a \"reach\" the hydrologist chooses
> the dominant periodicity and calls the continuity interrupted. If the
> reach is not continuously perennial or intermittent we are noting it
> through the use of the interrupted attribute. It may be a scale issue
> but it also says a lot about the channel itself.*
>
> Discussion: Since BLM is the only agency that utilizes information
> that is carried in this attribute, it is appropriate for BLM to manage
> this attribute internally.
>
> Recommended Action: BLM will handle this attribute in ARIMS.
> Sub-surface flow will be mapped as a NHD connector.

**Water Body (WB)**

The PNW Hydrography Framework Clearinghouse definition: *"[The Water
Body (WB]{.underline}) layer consists of sounds, bays, lakes, ponds,
wetlands, reservoirs, inundation areas, the double lined portions of
streams and other hydrographic features best represented as areas. For
ease of managing these features they have been modeled as regions rather
than simple polygons in the Framework model. 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). The advantages of this
approach will be described in detail in document titled "Oregon and
Washington State Framework Hydrography Concepts, Rules & Procedures."
Water body attributes will be stored in the WB region attribute table
(PATWB.) Changes to the water body shape will be made and tracked in the
water body shoreline coverage."*

> **WB_LLID_NR (region attribute)** Clearinghouse definition: "*The
> 13-character longitude/latitude derived unique identifier of the water
> body. All water bodies and islands represented as polygonal features
> are assigned an identifier. The identifier is based on position of the
> polygon label point. The identifier code is composed by concatenating
> the decimal degree values (to four places of precision) of the
> coordinates (minus the decimal points). LLID numbers are not unique
> across the four coverages. There is no valid default value for this
> field and it must be populated."*

***Example: 1224814467121***

> **Discussion:**
>
> The NHD uses reach codes as unique water body identifiers instead of
> LLID numbers.
>
> **Options:**
>
> Create a ReachCode/LLID crosswalk
>
> **Recommended Action:**
>
> Create a ReachCode/LLID crosswalk. Note: The NHD key for the crosswalk
> table may be the water body ComID rather than the reach code.
>
> **WB_HYDR_FTR_CD (region attribute)** Clearinghouse definition:
> "*Water body hydrographic feature code. The code used to describe the
> hydrographic feature type that the water body polygon represents."*

***Example: LA***

> **Discussion:** For the most part, the PNW attribute values directly
> map into NHD subtypes such as lake/pond, estuary, or ice mass. There
> are some notable exceptions:
>
> Reservoirs: the NHD has a different definition of the reservoir
> feature type than the Clearinghouse. NHD defines a reservoir as an
> artificial basin with human created shorelines whereas PNWHF defines a
> reservoir as a human caused impoundment with natural banks.
>
> Unknown/unclassified features: NHD does not allow for water body
> features to be unclassified. PNWHF currently has approximately 909
> water body features which are "Unknown/unclassified". These features
> will need to be classified into a NHD subtype or be stored outside of
> NHD until they can be classified.
>
> Islands: NHD has no feature type for islands, PNWHF does. In NHD,
> islands are represented as donut holes inside of water body features.
> At the present time, NHD management are not interested in adding an
> Island subtype.
>
> Impounded Wetlands: NHD has no feature type for Impounded Wetlands,
> PNWHF does. PNWHF was inconsistent in the use of this code.
>
> **Options:**

-   Use NHD subtypes -- in the short-term PNW can utilize an FCODE
    of 39010. This translates into a lake/pond: hydrographic category
    perennial: stage = normal pool. Use of the stage value implies an
    artificial impoundment.

-   Create feature class external to NHD for features without direct
    PNWHF feature/NHD feature mapping

```{=html}
<!-- -->
```
-   include unknown/unclassified features

-   drop unknown/unclassified features

```{=html}
<!-- -->
```
-   Create external attribute table for feature type

> **Recommended Action:**
>
> Use NHD subtypes with the following caveats:

-   Short-term: Utilize the lake/pond feature with the stage attribute
    value of normal pool.

-   Long-term: Work with the NHD management to adopt a broader
    definition of the lake/pond feature type that is consistent with the
    PNWHF definition of reservoir.

-   PNWHF partners work to properly classify unknown/unclassified
    features

-   PNWHF store island centroids and associated attributes as point
    features external to NHD. Partners can reunite the island points
    with the shorelines from the NHDFlowline feature class to recreate
    island polygons. This process will be fully documented for users in
    the near future.

-   Reclassify Impounded Wetlands into appropriate NHD features codes
    such as swamp/marsh.

-   Unknown will be sent back to the originating agency for
    classification and then inclusion into the NHD.

> **WB_CART_FTR_CD (region attribute)** Clearinghouse definition:
> "*Water body cartographic feature code. The code used to describe the
> cartographic feature type that the water body polygon represents. This
> represents feature codes developed initially by the USGS and used on
> the DLG's."*

***Example: 101***

> **Discussion:**
>
> As the function of WB_CART_FTR_CD is so similar to the WB_HYDR_FTR_CD
> attribute, the discussion of the two attributes was combined. See the
> WB_HYDR_FTR_CD discussion above.
>
> **Options:**
>
> See the WB_HYDR_FTR_CD options above
>
> **Recommended Action:**
>
> See the WB_HYDR_FTR_CD recommendation above. Cranberry bogs will have
> to represented in a related table as the NHD considers these to be a
> crop and not a hydrographic feature.
>
> **WB_GNIS_NM (region attribute)** Clearinghouse definition: "*The name
> of the water body as contained within the Geographic Names Information
> System (GNIS) which is maintained by the USGS. Not all features
> contained within the coverage will have GNIS names."*

***Example: Ross Lake***

> **Discussion:**
>
> The NHD has a GNIS_Name attribute which duplicates the WB_GNIS_NM
> attribute. There was little discussion on this as it seemed like a
> "no-brainer" to just use the NHD attribute. Local Names can be carried
> by individual agencies as event tables. See corresbonding discussion
> in the WC section.
>
> **Options:**
>
> Use the NHD Attribute
>
> **Recommended Action:**
>
> Use the NHD Attribute
>
> **WB_GNIS_NR (region attribute)** Clearinghouse definition: "*The
> unique identifier number assigned to each feature name represented
> within the GNIS database. This number is used to insert and/or update
> water body names stored in the framework hydrography database. Not all
> features contained within the coverage will have GNIS number"*

***Example: 426671***

> **Discussion:**
>
> The NHD has a GNIS_ID attribute which duplicates the WB_GNIS_NR
> attribute. These was little discussion on this as it seemed like a
> "no-brainer" to just use the NHD attribute. Local Names can be carried
> by individual agencies as event tables. Agencies that wish to have
> "local names" considered for the GNIS and NHD must initiate a Domestic
> Geographic Names proposal and work through their respective State
> Board of Geographic Names. See WC_GNIS\_ discussion.
>
> **Options:**
>
> Use the NHD Attribute
>
> **Recommended Action:**
>
> Use the NHD Attribute
>
> **WB_PERIOD_CD (region attribute)** Clearinghouse definition: "*This
> is a classification of a water bodies in terms of the seasonal
> behavior of the feature over time or in terms of its surface flow."
> ^3^*

***Example: per***

> **Discussion:**
>
> The NHD has a Hydrographic Category attribute with classifications for
> perennial, intermittent, and ephemeral. These classifications match
> the PNWHF codes with the exception that PNWHF allows periodicity to be
> defined as unknown, NHD does not.
>
> **Options:**

-   Use the NHD attribute (HydrograhicCategory)

```{=html}
<!-- -->
```
-   Drop features with unknown values

-   Use a default value of generic lake/pond for features with unknown
    values. See discussion in the water course section above.

    -   Continue separate event table

> **Recommended Action:** Use the NHD Attribute and use the generic
> lake/pond feature for unknown values. This will flag the unknown
> values for the data stewards so that these unknowns can be classified
> correctly by the data stewards. See WC_Period discussion and
> recommended action.

**Water Body Shoreline (WS)**

The PNW Hydrography Framework Clearinghouse definition: *"[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 in the Framework
database as the "default" shoreline. This default shoreline will be
coincident with the water body perimeter in the water body (WB) layer.
This layer is modeled in the Framework 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. Water will be on the
right side of each route and each shoreline will be represented by one
or more non-overlapping routes. However, most simple water bodies (e.g.
small lakes and ponds) will likely be represented by a single route. The
history of spatial edits to each water body will be stored as an event
on the route(s) on the default shoreline. Our agreement is that unless
there is good justification to do so, all other shoreline attributes
will be stored as events on the default shoreline. Non-default
shorelines are intended to accommodate specialized requirements."*

> **WS_LLID_NR (route attribute)** Clearinghouse definition: "*The
> 13-character longitude/latitude derived unique identifier of the
> shoreline. All water body shorelines and island shorelines are
> assigned an identifier. All shoreline segments are grouped into
> shoreline routes. The identifier is based on beginning of the route
> and is composed by concatenating the decimal degree values (to four
> places of precision) of the coordinates (minus the decimal points).
> LLID numbers are not unique across the four coverages. There is no
> valid default value for this field and it must be populated."*

***Example: 1224814467121***

> **Discussion:**
>
> The NHD uses reach codes as unique water body shoreline identifiers
> instead of LLID numbers.
>
> **Options:**
>
> Create a ReachCode/LLID crosswalk
>
> **Recommended Action:**
>
> Create a ReachCode/LLID crosswalk
>
> **WS_DATUM_CD (route attribute)** Clearinghouse definition: "*The
> character code that describes the type and level that the water body
> shoreline was mapped at. The framework model is designed to store
> multiple shorelines; some of them are complete for a state's coastline
> while others are short segments. Shorelines consist of water body
> perimeters (lakes, ponds, and reservoirs) as well as linear segments
> like marine shorelines."*

***Example: mhw***

> **Discussion:**
>
> The Framework data model allows for the storing of multiple shorelines
> representing various tidal datums, the NHD data model has no
> equivalent function. This attribute has no counterpart in the NHD
> model.
>
> Though the PNWHF design allows for it, currently no Framework partner
> has loaded any multiple shorelines into the Framework database.
>
> **Options:**
>
> • Turn into event table
>
> • Incorporate into feature level metadata
>
> **Recommended Action:**
>
> Incorporate the tidal datum into the NHD metadata.
>
> **WS_DFLT_SHORE_CD (route attribute)** Clearinghouse definition: "*The
> character code that designates the shoreline that's used to build
> water body area features. The default shoreline is comprised of the
> mean-high water line (mh) and the fresh water (fw) shoreline. This
> field is included to unambiguously designate the default shoreline
> regardless of the future changes or exceptions to the business
> rules."*

***Example: y***

> **Discussion:**
>
> The Framework data model allows for the storing of multiple shorelines
> representing various tidal datums, the NHD data model has no
> equivalent function. This attribute has no counterpart in the NHD
> model.
>
> Though the PNWHF design allows for it, currently no Framework partner
> has loaded any multiple shorelines into the Framework database.
>
> **Options:**
>
> • Drop the attribute
>
> **Recommended Action:**
>
> Drop the attribute as it not meaningful in the NHD model
>
> **WS_TYPE_CD (event)** Clearinghouse definition: "*Water shoreline
> type code. The type of water body shoreline feature that is
> represented."*

***Example: 1***

> **Discussion:**
>
> The domain for this attribute is {marine, marine island, freshwater,
> freshwater island, artificial, estuarine, unknown}.
>
> NHD differentiates marine and freshwater shorelines by assigning
> marine shorelines to the Coastline subtype and freshwater shorelines
> to the Shoreline subtype. NHD does not provide mapping targets for the
> other domain members.
>
> PNWHF was inconsistent in the use of the estuarine code.
>
> NHD does not store artificial shorelines.
>
> The major impact upon PNWHF users would be the loss of distinction of
> island shorelines. This can be compensated for by the use of ArcMap's
> "Select By Location" tool to select shorelines contained by a
> selection of NHD WaterBody or WaterArea polygons.
>
> **Options:**

-   Rely on NHD subtypes to differentiate "Marine" and "Freshwater"

-   Keep Islands as events

-   Drop Islands

-   Incorporate estuary data into NHDWaterbody

> **Recommended Action:**
>
> A combination of using NHD subtypes to differentiate marine and
> freshwater shorelines and using NHDWaterbody to define estuarine
> areas. Drop use of the island code and allow island shorelines to be
> selected using ArcGIS tools.

**WATER POINT (WP)**

The PNW Hydrography Framework Clearinghouse definition: "*[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 describes the history of
spatial edits to the feature."*

> **WP_CART_FTR_CD** and **WP_HYDR_FTR_CD**
>
> Discussion: PNW will try to utilize existing NHD subtypes wherever
> possible. A big question is what to do with the unknown attribute
> value. Should PNW drop these or put them in an external table? NHD
> does not model lake/ponds as points. PNW would have to convert these
> points to reservoir.
>
> Recommended Action: Use NHD subtypes and convert point lake/ponds to
> reservoirs in the NHD. Send unknown values (total of 371) back to the
> originating agency for classification.
>
> **WP_PERIOD_CD**
>
> Clearinghouse Definition: *Water point periodicity code. This is a
> classification of a water point in terms of the seasonal behavior of
> the feature over time or in terms of its surface expression.*
>
> Discussion: NHD does not track periodicity for spring/seeps -- they
> are assumed to be perennial. Clearinghouse data is spotty for springs
> and few are identified as intermittent (these are all on the east side
> of the Cascades).
>
> Should these go in an external related database or should we
> assimilate everything into the NHD feature and individual agencies
> (mainly FS) track periodicity.
>
> Recommended Action: use NHD Hydrographic Category to track
> periodicity. Drop intermittent attribute, but not spring feature
> itself and integrate these springs into the NHD. Individual agencies
> to track periodicity, if this is still a requirement for their agency.

**Miscellaneous: Feature Level Metadata**

PNW has feature level metadata in event tables tracking agency, source,
date, etc. We can maintain a separate event table for these data or try
to migrate it to the existing NHD metadata structure \-- which has the
capacity to handle feature level metadata. At the present time, a
contractor for the USFS is exploring the option to migrate the feature
level metadata to the NHD.

[^1]: Hydrodatadicty_09_04.doc - the entire document is available at:
    <http://hydro.reo.gov/docs.html> . Also see the metadata at:
    <http://hydro.reo.gov/metadata/WatercoursesOregonWashington.htm> .

[^2]: See NHD technical reference documents at:
    <http://nhd.usgs.gov/techref.html>