What sources were used to produce the data?
It's a combination of USGS hydrologic digital line graph files and EPA reach files, version 3.0 (RF3). The USGS files are used for spatial accuracy and the EPA files are used for attribute information.
Why has this dataset been created?
The idea is to combine spatial accuracy with detailed features, attributes, and values. Information such as flow paths, permanent reach IDs, and hydrologic ordering can now be used in modeling. The NHD is not designed to replace or supercede existing datasets, but offer users another tool with more flexibility.
In what scale are the data?
Medium resolution NHD data are available
at 1:100,000 scale for the conterminous US and Hawaii. High resolution NHD data
are available for Puerto Rico at 1:20,000 scale and the Virgin Islands at
1:24,000 scale. In addition, data for Alaska are being produced at 1:63,360
scale. Users are encouraged to produce and submit data at higher resolution.
Whether the data is medium resolution or high resolution can be determined from
the NHD.met file. Medium resolution data has a title 'National Hydrography
Dataset' while high resolution NHD has a title 'National Hydrography Dataset -
High resolution'. The scale of the source material used to create the NHD can be
found in the source citation abbreviation listing in the subbasin level metadata.
In what format are the data?
Data are offered in both compressed ARC workspaces and compressed SDTS transfer format.
Who can I contact for NHD information?
Contact an
In the process of building the NHD from RF3 and DLG3 (Digital Line Graph Version 3), the rules for delineating reaches were changed in some significant ways. For example, RF3 has reaches on the shorelines of wide rivers and lakes, while NHD has reaches on artificial paths that run through wide rivers and lakes. Another example is, RF3 did not have waterbody reaches and NHD does. Consequently the spatial representation of an RF3 reach will not equal the spatial representation of an NHD reach in some cases. However, a large number of RF3 reaches are 1-1 with NHD reaches. For example, almost all of the single line stream confluence-to-confluence reaches in RF3 have the same spatial extent in NHD. (The coordinates in NHD are more accurate/precise than those in RF3 and you will generally see a slight shift in the line work between RF3 and NHD.)
It is important to know that even the reaches that are 1-1 between RF3 and NHD will have new reach codes. The reach code in RF3 was CU+Segment+MarkerIndex (17 characters) and in NHD it's CU+Segment (14 characters). Every reach received a new code when NHD was built, however an RF3-to-NHD crosswalk (also known as the RF3-to-NHD Cross Reference Archive) was also created. Although the cross walk is not perfect, it works very well for the 1-1 reaches and for small to medium-sized lakes, and less well on wide rivers and large lakes.
The RF3-to-NHD Crosswalk traces the RF3 reach codes to their Initial Release NHD reach codes. The table is in the
same format as the RCL table in
the NHD workspaces. Reach code changes that have occurred since NHD Initial
Release are traced with entries that are distributed in the RCL table contained
in the NHD workspaces. Together, the RF3-to-NHD Crosswalk and the RCL table in
the workspaces provide a complete crosswalk from any vintage of RF3 reach codes
to current NHD reach codes. The RF3-to-NHD Crosswalk tables contain all of the
RF3 cross references beginning with the original version of the RF3 subbasins dating back as far as 1990. Given an RF3 Reach Code and the Reach Date from the UPDATE1 field of the associated RF3 reach attribute table (the DS3 Info table in an RF3 ArcInfo coverage), you can follow the trail that traces that particular RF3 reach code to the initial release of the NHD. There may be many records that trace a single RF3 reach to the NHD.
If you are using a version of the NHD beyond initial release, you can continue the tracing of the initial release reach code by using the cross-reference entries in the Info table called RCL within each NHD workspace. Future changes to NHD reaches will be recorded in the RCL table.
RF3 single-line stream reaches generally have a 1-1 correspondence with NHD reaches and can be traced through the crosswalk tables in a fairly straightforward manner. The RF3 reaches along the shorelines of areal features (wide rivers, lakes, and reservoirs) are not generally linked 1-1 to the NHD centerline reaches. After tracing these RF3 reaches through the cross-reference data, it is necessary to perform a spatial match to the set of identified NHD reaches to determine exactly what set of whole and partial NHD reaches equate to the original RF3 reach. In a small number of cases, RF3 reaches were not translated into NHD reaches. Data linked to these RF3 reaches will need to be linked to the NHD without the use of the RF3-to-NHD Crosswalk.
The RF3-to-NHD crosswalk is currently available. It's organized in DBF format by hydrologic region. To receive all or part of the crosswalk, please post your request via email to nhd@usgs.gov."
How can the NHD be used to support modeling?
We say that NHD is a 'framework' for modeling. This framework consists of two basic components. First, there are permanent features (reaches) with permanent, public identifiers (reach code) that support the linear referencing (reach route system) of attributes to the stream network. Second, the reaches have flow relationships (RFlow table) that enable you to programmatically walk up and down the network encountering the information that you have linked to the network through linear referencing.
To perform meaningful modeling, you'll have to link additional information on the NHD network. For example, if you wanted to perform impact analysis, you might link pollution events to the network (through linear referencing) and then navigate downstream (with the flow table) to see what streams would be affected by the events. If you want to do dilution modeling, you'll need lots of additional information such as flow volume, velocity, travel time, etc. for NHD reaches. So the NHD provides the framework, but the modeler needs to acquire and link to the NHD any attributes needed for a particular type of modeling.
The NHD ArcView Toolkit provides some of the basic functions that you would need to get into the modeling business. For example, the NHD Reach Indexing Tool provides tools to perform linear referencing of attributes to the stream network and NHD Navigate provides tools to walk upstream and downstream on the network.
How can I tell when NHD workspaces have been updated?
On the NHD ftp site, along with all the NHD workspaces, a status file is provided to assist users in tracking changes in the NHD. The file is in text format and called 0000_CU_STATUS_LIST_FILE.txt. A sample of the file content is shown in the following image.
When an NHD workspace is updated, the status file entry for that workspace is updated. Each entry in the file provides the following information:
CU Number: The eight digit HUC number for the NHD subbasin (formerly known
as cataloging unit) workspace.
Distribution Status: Generally, this column will say 'distributable'. Occasionally, when an update process experiences problems, this column will say 'not distributable' which means that updates are pending and a new workspace is not yet available.
Date Updated: The date that the updates were processed and stored in the NHD central database.
Date Distributed: The date that the workspace was distributed to the NHD ftp site.
Process Description: The first 60 characters of the most recent metadata process description. This describes what updates were made to the workspace.
By comparing the 'Date Distributed' with the date of the workspace held by the user, it is possible for a user to determine when an updated workspace is available. If the user uses an ftp client to download NHD workspaces and if that ftp client preserves the workspace file date, the user can use the workspace file date for comparison. If the user downloads NHD workspaces with a method that does not preserve the file date, then the user should use the file date of the OPENME.TXT file inside the compressed NHD workspace for the comparison.