1. Summary of Changes from NHDinARC to NHDinGEO

2. Reach Application Several changes have taken place in the application of reaches in the NHDinGEO implementation. The basic concept of the reach as the primary reference for linking external data to the NHD remains the same. The changes with NHDinGEO are the result of a redesign effort to both simplify the data and to take advantage of the new capabilities in the geodatabase environment. Even with these changes, in most instances the same reach codes apply to the same features with the same measurement values as with previous data. To simplify the data content, the reach reference is now placed directly on the associated basic feature. Rather than having a parallel feature class, as implemented in NHDinARC datasets with reach routes and reach regions, the reach reference (ReachCode) is on the feature associated to the reach. These reach applications are on NHDFlowline, NHDWaterbody, and NHDPoint. The NHDinARC attributes for reaches, including GNIS_ID, Name, and Level have been transferred to the associated feature. In the case of NHDFlowline, the reach code attribute acts as the key for linear referencing. All metadata history for the reach features has been transferred to the associated feature instances.

3. As part of the geodatabase implementation of linear referencing, the geometry of the NHDFlowline features carry an explicit M value on the coordinates. These M values replace the section measures from the coverage data model. The M values are applied to all features that belong to linear reach features. The rules for measure application are identical to the rules applied to NHDinARC data. The M values are calculated from the downstream point to the upstream source of each reach extent, with values from 0 to 100. Another change to the application of reaches is the elimination of the reach as the core element of flow navigation. In the NHDinARC model, the flow was built around the extent of the reaches. This approach became increasingly complex with the incorporation of multi-part reaches as higher resolution datasets were Reach Application (Cont.) built. In the geodatabase implementation, the flow model is built around the NHDFlowline features, not the reaches (see flow model discussion).(see flow model discussion)

4. New Attributes Three new attributes have been added to the data. These include: FDate: Date of last feature modification Resolution:Source data resolution FlowDir:Direction of flow relative to coordinate order The FDate and Resolution attributes are metadata characteristics that have been brought to the feature instance level. The purpose of bringing the FDate to the feature instance is to provide a clear indicator of change in the data. If a feature instance has been changed since the last access of the data, this change will be apparent by comparing the FDate values. The Resolution attribute has been added to provide the source resolution of the feature instance (see Multi-Scale). The FlowDir attribute captures whether or not a feature participates in flow navigation and the direction of the flow relative to the order of the coordinates in the geometry (see Flow Model). (see Multi-Scale) (see Flow Model)

5. Multi-Scale To accommodate requirements of many of our cooperators and partners, we have altered our plan for a single, multi-resolution dataset. Instead, we will continue to maintain the NHD data at separate resolutions (medium, high, and local).

6. Flow Model In the previous NHD design, two flow representations were included in the data. One representation was spatial, with features connected at nodes and the coordinates ordered from upstream to downstream. The other representation was non-spatial, with a binary flow relationship between reaches that was held in a separate table. The new model also includes spatial and a non-spatial flow representations, but with modifications that both take advantage of ESRI's geometric network and to simplify the design. For the spatial implementation, flow connectivity is built from the topological connections of the geometric network and the value of the FlowDir attribute. If features are topologically connected and have a FlowDir value of "With Digitized", the features will be part of a geometric flow network that is traceable in ESRI's network solvers. This design is consistent with ESRI's Arc Hydro approach for the flow network.

7. The model also contains a flow table to support non-spatial traces through the flow network. Unlike the reach flow tables of the previous system, the new flow table refers to the flow connections of NHDFlowline features, not the reaches. This change reflects a simplification of the flow table by eliminating the requirement for flow direction and flow sequence characteristics on the relationships. Additionally, this flow representation is at the granularity of the basic flow features rather than at a more abstract level, which is more difficult to build, use, and maintain. We are keeping the delta_level attribute to aid in identification of the mainpath at confluences for the non-spatial traces. Flow Model (Cont.)

8. Metadata Metadata will now be stored in the database with the feature data. The NHDinARC implementation did not allow this approach for most of the metadata due to the limitations of the INFO database. The geodatabase does not have these limitations. The metadata is broken out to four tables: FeatureToMetadata, Metadata, SourceCitation, and ReachCrossReference. The FeatureToMetadata is a link between the features and their metadata. The Metadata table contains the general metadata characteristics for each collection of feature updates. The SourceCitation table lists the sources associated with each metadata instance. The ReachCrossReference table holds the reach lineage information that users of the NHD.RCL table are used to seeing. A second change for the metadata is that we have eliminated the Digital Update Unit boundaries. Since the feature updates associated with a set of metadata define the extent of changes, we simplified the data by eliminating the need to build and maintain bounding areas for the updates.

9. Simplified Content In addition to the model changes listed above, several minor features and attributes were removed to simplify the data. Although these features and attributes existed on the original topographic maps, they are not significant enough to justify their continued representation in the National data. In many cases these features are better represented in other data sources. For example, the water obstacles of post, snag/stump, and wreck are more of a concern for nautical charts than for NHD data. These changes should reduce the cost of building and maintaining the NHD data with very little impact on the application of the data.

10. Dropped features include: Anchorage Crevasse Field Fish Ladder Fumerole (changed to Spring) Geyser (changed to Spring) Mud Pot (changed to Spring) Post Snag/Stump Underpass Wreck

11. Dropped attributes include: Continental Glaciation Category (Ice Mass) Cover Type (Reservoir) Disposal Type (Reservoir) Gate Type (Gate) Hazard Zone Category (Hazard Zone) Ice Mass Category (Ice Mass) Inundation Area Type (Inundation Area) Operational Status (Dam/Weir) Positional Accuracy (Stream/River) Sea/Ocean Category (Sea/Ocean) Treatment Type (Reservoir) Wall Type (Wall) Water Characteristics (Lake/Pond, Spring/Seep, Well) Water Intake/Outflow Type (Water Intake/Outflow) One feature was added to the data content. A coastline feature type replaces “coastal” artificial paths.