##
NHD/LLID Data Conversion Application version 1.2

##
User Help and Documentation

Note: This is the initial release of this application. While the application has been tested thoroughly, there may be problems that made it past our scrutiny or helpful enhancements that we did not think of. Please send comments on any problems that you find or enhancements that you would like to see to StreamNetGIS@psmfc.org, and revisions will be made where possible. Thank you.

### Overview

- General Background
- Software and User Requirements
- Application Description
- FAQ

### Application Help

- Getting Started
- Converting data from LLID to NHD
- Converting data from NHD to LLID
- Accuracy, Cautions, and Limitations
- Customizing the Application for use with 1:24k Hydrography or other Route Systems

### Documentation (Metadata)

- Identification_Information
- Data_Quality_Information
- Spatial_Data_Organization_Information
- Spatial_Reference_Information
- Entity_and_Attribute_Information
- Distribution_Information
- Metadata_Reference_Information

Overview

General Background

The Environmental Protection Agency and US Geological Survey recently (2001) completed their joint project to develop the National Hydrography Dataset (NHD) at the 1:100,000 scale for the entire U.S, including the Pacific Northwest. To date, many Northwest agencies and organizations have been utilizing the PNW Reach files LLID-based routing system to reference their geographic stream-based data. Many of these agencies and organizations may now plan to switch to the NHD. To do so, they face the issue of how to convert their pre-existing data that is tied to the LLID-based system over to the NHD reach-based system. Other organizations and agencies that will continue to maintain their data on the PNW Reach files may need the flexibility to convert data from future NHD sources to the LLID system or vice versa so that data may be freely exchanged in both formats. Therefore, a need exists in the region for an application that may be used to efficiently and accurately convert stream-based data between the NHD and LLID-based systems.

The NHD was developed using linework and attributes from the PNW Reach files, so the NHD linework is currently "in sync" with the PNW Reach files and the LLID-based system that is built on them (with a few exceptions - see the "Accuracy, Cautions, and Limitations" section for a discussion of these). A cross-reference table (the 'RCL' table) was included with each NHD cataloging unit and is a bridge between the old PNW reach numbers and the new NHD reach numbers. In places where there is a one-to-one correspondence between reaches, this cross reference table is effective at transferring data between the old and new hydrography layers, but in some areas, particularly areas where there are 'connector arcs' through lakes or reservoirs, one NHD reach corresponds with multiple PNW reaches and it is wasn't possible to directly translate through this table. To build a cross reference for the purpose of translating between the LLID and NHD systems, it was necessary to accurately rebuild the LLID routing system on top of the NHD linework through the use of the preliminary cross-reference (RCL) table and through GIS conflation methods where this table didn't entail a one-to-one relationship. After the results of this rebuild were QA'd and fixed where necessary to ensure accuracy, a tabular cross-reference which contained the NHD and LLID route information was derived from the GIS files. A database application was then designed to allow a user to precisely convert large amounts of data between the two systems through this cross reference table. The StreamNet project at Pacific States Marine Fisheries Commission completed this work in cooperation with the US Environmental Protection Agency and the US Geological Survey. The products of this work, the NHD/LLID Data Conversion Application and the NHD GIS layers with the LLID routing system built onto them, are available for download and public use from the StreamNet site at http://www.streamnet.org/nhdllid/. All HUCs (USGS 4th code hydrologic units) which fell partially or entirely within the states of Washington, Oregon, Idaho (EPA Region 10) and those in Montana, West of the continental divide, were included in this work. This document provides help on how to use the data conversion application and complete documentation on for the application and related GIS files.

Software and User Requirements

Software Requirements: To run this application, you will either need to have a copy of Access 97 or Access 2000 installed on your computer. The application is provided for download in both formats and runs in the same way in both versions of the database software. You will also need to have approximately 24 MB of free disk space to store the database and help documentation once it is uncompressed.

The application works entirely with tabular data and does not require GIS software to run. The application does, however, refer to routing systems which are built on GIS hydrography layers and it converts event data in a format that is meant to be tied to these route systems. Its full value is therefore derived from the application of these event tables to hydrography layers with GIS software. The cross reference table that this application uses was derived from NHD hydrography layers on which the LLID route system was rebuilt. These GIS files, which include both the NHD and LLID routing systems, are available for download in a zipped arc export format from http://www.streamnet.org/nhdllid/regionmap.html

User Requirements: A user of this application should be familiar with what the LLID and NHD routing systems are and how event data are tied to these systems. The user should also have a basic understanding of relational databases and a basic knowledge of how to use MS Access software. It is recommended that users read at least the Overview and the 'Accuracy, Cautions, and Limitations' section under the Application Help part of this document before using the application.

Application Description

The NHD/LLID Data Conversion Application is a tool developed in MS Access with Visual Basic for Applications (VBA) programming code. The application is self-contained in the database with the exception of this document which you are reading and the images that are displayed by this document. To make this document accessible from the application, simply save it (.HTML file) and its related images (.GIF files) in the same folder as the database.

The database includes a menu form that is used to run the application from buttons on the form, two VBA modules that do the data conversion, and two tables, one of which is used to run the application and one that is provided for reference.

The form is named Menu and automatically opens when the database is started. This form is designed to provide a user-friendly means to run the application. The first two buttons run the data conversion applications, from LLID to NHD events, and from NHD to LLID events. These two procedures are described in more detail in the "Application Help" section. The third button opens the help/documentation document which you are currently reading. The fourth button opens the database in a standard Access database view.

The two VBA modules in the database are:

LLID-NHD: Converts event data from a source table of LLID-based events to an output table of NHD reach-based events.

NHD-LLID: Converts event data from a source table of NHD reach-based events to an output table of LLID-based events.

Both modules create preliminary output tables that are parsed to each arc in the NHD hydrography. Additional "aggregate" procedures are included which recombine these events into a more condensed and practical format. See the next section "Application Help" for more information on how these procedures are run.

The two tables in the database are:

CrossRef: A cross reference table for each arc in the NHD (Washington, Oregon, Idaho, and W.Montana) that includes the NHD reach-based coordinates and the LLID-based coordinates for that arc.

CrossReferenceQA: A table of results of the process to rebuild the LLID routes on top of the NHD linework. This table was used for QA of this process and is useful for identifying LLID routes that couldn't be precisely transferred to the NHD because of modifications to the NHD linework.

See section "Customizing the Application for use with 1:24k hydrography or other route systems" for assistance with how the CrossRef table may be customized for usage with different coverages and route systems. See the section "Accuracy, Cautions, and Limitations" for how to use the CrossReferenceQA table to check areas that may not translate precisely because of changes in the NHD linework.

FAQ

What is the difference between NHD reach-based data and LLID-based data?

The NHD and the PNW Reach file are two 1:100,000 GIS hydrography data sets that include different route systems that are built "on top" of them to reference data to. A route is a measured line that relates to the underlying linework (in this case stream and hydro features). The LLID route system is a stream-based system which contains one route per stream. For example, the Columbia river is its own route, identified by a unique 13-digit LLID code. Any location along the Columbia River route can be identified by a measurement upstream from the mouth of the river. The NHD contains various route systems, including a reach-based route system as the one that is intended to be used for tying stream data to the NHD and is cross-referenced with this application. A reach-based system contains one route per reach (a stream segment located between two river confluences). Each reach is assigned a unique reach code. In the example of the Columbia, the river itself will have multiple reaches. Each reach is measured in proportion, rather than a real-world measurement, so you can reference a point on that reach with the reach code and a proportion (ex: the location is at 55.7% of the distance down the reach).

Event tables contain "events" which are data records that are tied to route systems. Event tables may contain various types of information about stream segments, including water quality, temperature, fish presence, etc. but must define the location of the event on a route system in order to be mapped. In the case of the LLID system, they will have an LLID which identifies the stream, a beginning measurement which locates the start location of the event, and an end measurement that identifies the end of the event. In the NHD reach-based system, the event table needs to contain a reach code that identifies the reach, and a beginning and an end measurement on that reach. See the diagrams below for an illustration of the difference between the NHD reach-based route system and the LLID stream-based route system and event data tied to these systems.

How was the cross reference table built?

The procedure to build the cross-reference table was the most time-consuming part of the project. The NHD GIS coverages for the Pacific Northwest were downloaded from the NHD web site last spring, after flow validation was complete. A series of Arc/Info AML's (Arc Macro Language procedures) were written to rebuild the LLID routes from the PNW Reach files onto the NHD linework. These AML's used a combination of automated and semi-automated Arc/Info procedures to rebuild the LLID routes. The preliminary cross reference table that is included with each NHD coverage (the RCL table) was used if possible to determine the stream segments that a LLID route belonged to. Where there wasn't a one-to-one relationship in this table, a conflation approach was used to transfer the LLID attribute spatially to the NHD segments.

Once the LLID routes were built onto the NHD linework, information about the newly built routes was compared to the source (correct) LLID routes on the PNW Reach files. Whenever a route differed significantly in length (by more than 100 feet) between the two, it was examined and corrected manually on the NHD layers by viewing both the source and new routes at the same time and rebuilding the LLID route on the correct stream segments.

When the QA process was complete and the LLID routes were determined to be accurately and completely rebuilt on top of the NHD linework, the tabular cross reference table was created. This was done by transferring the NHD reach-based route information and the LLID route-based information to each arc (stream section) in the NHD coverage. The arc attribute table was then dumped out to a tabular database with this dual route system information. The resulting table is named CrossRef and contains coordinate information for both route systems and is the engine that the the application uses to convert event data between the LLID and NHD systems.

How does the data conversion application work?

The data conversion application runs through a table of source events, one record at a time. It reads each source event and searches the cross reference table for any records (which represent individual arcs on the NHD linework) that the event falls on, either partially or completely, in the native route system that the source event is in (LLID or NHD). When it finds an arc that it does correspond to, the program computes which portion of that arc that the event covers (i.e. 15.834% to 74.239%, 0 to 100%, 34.333% to 95.042%, etc.) With this information it then determines what these coordinates are in the output routing system (LLID or NHD) that it is converting the event to. It then writes out the event in an output table with coordinates from the new routing system. The second part of the conversion application aggregates these output events together if they are consecutive and from the same source event, and pastes these out to a second, aggregate events table. The new events are related to the source events on a user-specified key field that can be joined between the two tables after the conversion is run. The application keeps track of any events that were not converted successfully (because they didn't correspond to any sections contains in the cross reference table) and writes these to a table named unconverted events

What format does my source event data need to be in?

Any format that Access recognizes and can import data from may be used as a data source for the application. These formats include other Access databases, dBase files, Excel spreadsheets, Fox Pro databases, HTML tables, and text files. If your data is in another format, you can try using an ODBC connection to establish it as a data source and then you should be able to point to it through Access as an 'ODBC data source'. Establishing an ODBC connection to a data source is done through the start menu through >Settings >Control Panel >Data Sources(ODBC). Irrespective of the source data format, when you run the conversion application, you will be prompted to import the source table of event data from its native format into the database if it isn't already there.

The source event table must contain a few required fields in order for the application to work. These fields may be named anything in the source table but must fit a few key criterion:

Event Key - This field is needed to identify each event and will be carried through to the output events as a means of linking them back to the source events. This field should allow you to link the location information for the event back to the data for the event. It does not necessarily have to be a unique field in the source table as a data event could conceivably correspond to multiple locations. The field may be a number or text string; the conversion application will read it (and output it) as a text string.

Route Identifier - This field identifies each route. With LLID-based events, this must be an LLID. With NHD reach-based events, this must be a NHD reach.

From Measure - This field identifies the starting location of the event on the route. For NHD reach-based events, this must be the proportion (%) along the reach. For LLID-based events this may be in either feet, yards, miles, meters, or kilometers (the application will prompt you to identify which unit of measurement it is in).

To Measure - This field identifies the ending location of the event on the route. For NHD reach-based events, this must be the proportion (%) along the reach. For LLID-based events this may be in either feet, yards, miles, meters, or kilometers (the application will prompt you to identify which unit of measurement it is in).

What area does the cross reference cover?

The cross-reference application and related GIS files cover all USGS HUCs (4th code hydrologic units) that fall partially or entirely within the borders of Washington, Oregon, or Idaho (EPA Region 10) and those in Montana, West of the continental divide. In HUCs that straddle state borders, only the LLIDs from the states described were cross referenced since an LLID-based system was not available in the other states. This application may be used in other states as long as a cross reference has been built between the LLID and NHD route systems and is added to the CrossRef table. The application may also be modified to run more quickly by only checking a smaller area within the Northwest. (see the "Customizing the Application for use with 1:24k hydrography or other route systems" section for more information on how to customize the application for these purposes.)

Application Help

Getting Started

To begin, download and save the cross reference application file from the StreamNet web site to a location on your hard drive. When you download it to your computer, it will be contained within a zip compressed file. Extract the files to a folder on your computer - the name and location of the folder are unimportant, but all files, including the database (.mdb extension), the help documentation (.html extension), and the images (.gif extension) need to be stored in the same folder in order for the help documentation to be available from the database application. To extract the files, use a zip compression software. If you have winzip installed on your computer, you should be able to double-click on the file to extract. If you don't have zip compression software, PC-compatible compression tools are free for download from the NHD web site

To start the application, double click on the file named NHDLLIDCrosswalk.mdb or open it from within Access. When you start the application, the menu form will automatically open. The form has four options with corresponding buttons. The first 2 buttons run the data conversion application and are described in the sections below.

Clicking the third button should open the help document (which you are reading).

If this document does not open automatically, then check to make sure that the file named 'Help_Documentation.html' is stored in the same directory as the database. If it still doesn't open, check to make sure that you have a web browser installed on the computer and that it is set up to automatically open HTML files.

Click the fourth button to show the database in standard Access view.

From the standard Access view, you can open and create tables and queries, or customize the database. If you haven't closed the menu form, you can return to the form view by clicking >Window >Menu:Form from the menu on the top of the screen.

Converting Data from LLID to NHD

The first button runs the LLID to NHD data conversion.

The LLID to NHD data conversion application will begin by asking you whether you need to import your source event table. If the table is not already in the database, then click yes to browse to the table (it may in various formats: Access database, dBase file, Excel spreadsheet, Fox Pro database, HTML table, text files, or ODBC data source). The source table will be imported into the database as an Access table. Next you will be prompted to enter the exact name of the table with the source data events and then to enter the fields (exact names) that are needed for the application to run. The fields may be named anything you would like but do have certain restrictions that they must meet. The necessary fields are:

Event Key - This field is needed to identify source data and will be carried through to the output events as a means of linking them back to the source events. This field should be capable of linking to the data that each location corresponds to but does not necessarily have to be a unique field in the source table as a record of data could conceivably correspond to multiple locations (events). The field may be a number or text string; the conversion application will read it (and output it) as a text string.

LLID - This field identifies each LLID route and must carry a 13-digit LLID from the PNW Reach files.

From Measure - This field identifies the starting location of the event on the LLID route. This may be in either feet, yards, miles, meters, or kilometers (the application will prompt you to identify which unit of measurement it is in).

To Measure - This field identifies the ending location of the event on the LLID route. This may be in either feet, yards, miles, meters, or kilometers (the application will prompt you to identify which unit of measurement it is in).

After the fields names are entered and a unit of measurement is defined, the application is ready to run. A message will let you know that it is running and a status bar is shown at the bottom of the screen to show application progress. After the application finishes, you will receive a message telling you how many events were successfully created and giving information on the key fields that relate the new events back to your source events. These new events will be stored in a table named NHDEvents. If any events did not overlap with any of the arcs in the cross-reference table, then you will receive a message detailing how many were not converted and these events will be written to a table named UnconvertedEvents.

You will next be prompted with a message asking whether you wish to aggregate the new events together. When the conversion application runs, it parses each event to records in the cross reference table which correspond to individual arcs in the NHD linework. All new events that are created are therefore parsed to the arc level. In most situations, it makes sense to recombine events that occur on multiple arcs if they occur consecutively on the same route. For example, a source event on the LLID system may be run through the cross reference table and parsed out to 3 different NHD events on the same reach (Reach X, from 0% to 25%, Reach X, from 25% to 75%, Reach X from 75% to 90%). Aggregating these events will recombine them to make one single event (Reach X, from 0% to 90%). If there are any true gaps in the data then these will be preserved when the aggregation procedure is run. For example, if the LLID event was parsed out to 3 events (Reach X, from 0% to 25%, Reach X from 25% to 70%, Reach X from 80% to 90%), aggregating these events will recombine them as (Reach X from 0% to 70%, Reach X from 80% to 90%), preserving the gap. The aggregated events are pasted to a new table named AggNHDEvents so the parsed events are still available in the NHDEvents table even if the aggregation procedure is run.

If the aggregation procedure is run (this is recommended), then it may take several more minutes to complete. Once this is finished, the data will have been converted to the NHD-based system. If the aggregation procedure was run, the new NHD reach-based events will be stored in the table named AggNHDEvents, and regardless of whether the aggregation procedure was run, parsed NHD reach-based events will be stored in the table named NHDEvents. You should be able to view and open these tables directly from database view when the application is finished. If they don't appear, the view can be refreshed by clicking on the 'queries' tab and then clicking on the 'tables' tab to return to the tables view. Each new event will have a HUC (the USGS 4th code subbasin), an NHD reach code, from and to measurements (in percent) that describe the location of this event on the NHD reach. These coordinates may be used to map out the data on the NHD reach route system, which is provided with each NHD coverage. The source NHD GIS data may be downloaded from the NHD home site or the NHD layer that was enhanced for this project by building the LLID-based routing system on top of it may be downloaded from the StreamNet site at http://www.streamnet.org/nhdllid/regionmap.html.

Each new NHD event will also contain a field named 'EvntKey'. This links the new event back to the original source LLID-based event that your data is tied to. Since one LLID event will often correspond to multiple NHD reaches, this source event may now occur as multiple locations. These new event locations may be linked back to the source data through any standard database software by linking on this event key field. In Access, this can be done through a query by adding both tables and then dragging a link between the event key fields and then selecting the fields that you want to display from the query. For more help on how to create an Access query, read the "Working with Queries" section under contents in Access help. If this query does not work because of a "type mismatch in the join expression", this is most likely because the event key fields are of different data types (i.e. text vs integer). The application automatically uses the event key as a text string, regardless of the source field data type. To run the query, you need to make these the same data type, either by changing the event key in the source event table to a 'text' data type or by changing the event key in the output events to match the data type of the event key in the source table. Field data types may be changed by opening the table in design view and right-clicking the data type column next to the field name.

It's also important to check the table UnconvertedEvents to see if any of your source events could not be translated successfully. If a source event is written to this table, then it could be for a variety of reasons:

Does the LLID occur in the CrossRef table? If not, it may be an obsolete LLID or a new LLID that your organization added that is not part of the PNW Reach files. To see a record of updates and changes to LLIDs in the PNW Reach File, please view the Data Maintenance Log File. It may also be an LLID that falls outside of the area of the cross-reference (Washington, Oregon, Idaho, or W.Montana).

Do the coordinates of the event exceed those in the cross-reference table? For example, the cross-reference table may only define LLID X from 0 to 5000 feet. If a source event is defined entirely outside of this range as LLID X from 6000 to 8000 feet, then it won't be translated. It then exceeds the length of this stream route in the PNW Reach files. It may be useful to check and confirm that this event is not a 1:24,000 event since the PNW Reach files are 1:100,000 scale and many streams stop in the headwaters area at this scale, where they may be drawn further upstream at the 1:24,000 scale.

Did you correctly identify the unit of measurement of the source events? If you didn't do this at the start of the application, it will have interpreted the event locations incorrectly. For example, if your events are in miles but you entered 'feet' when prompted for unit of measurement, then all of your results will be incorrect. It will then be necessary to re-run the application, detailing the correct unit of measurement.

Converting Data from NHD to LLID

The second button runs the NHD to LLID data conversion.

The NHD to LLID data conversion application will begin by asking you whether you need to import your source event table. If the table is not already in the database, then click yes to browse to the table (it may in various formats: Access database, dBase file, Excel spreadsheet, Fox Pro database, HTML table, text files, or ODBC data source). The source table will be imported into the database as an Access table. Next you will be prompted to enter the exact name of the table with the source data events and then to enter the fields (exact names) that are needed for the application to run. The fields may be named anything you would like but do have certain restrictions that they must meet. The necessary fields are:

Event Key - This field is needed to identify source data and will be carried through to the output events as a means of linking them back to the source events. This field should be capable of linking to the data that each location corresponds to but does not necessarily have to be a unique field in the source table as a record of data could conceivably correspond to multiple locations (events). The field may be a number or text string; the conversion application will read it (and output it) as a text string.

NHD Reach - This field identifies each NHD reach (route) and must carry the NHD reach code as it exists in the NHD.

From Measure - This field identifies the starting location of the event on the NHD reach route. This must be stored as a percentage of the reach.

To Measure - This field identifies the ending location of the event on the LLID route. This must be stored as a percentage of the reach.

Once the fields are entered, the application is ready to run. A message will let you know that it is running and a status bar is shown at the bottom of the screen to show application progress. After the application finishes, you will receive a message telling you how many events were successfully created and giving information on the key fields that relate the new events back to your source events. These new events will be stored in a table named LLIDEvents. If any events did not overlap with any of the arcs in the cross-reference table, then you will receive a message detailing how many were not converted and these events will be written to a table named UnconvertedEvents.

You will next be prompted with a message asking whether you wish to aggregate the new events together. When the conversion application runs, it parses each event to records in the cross reference table which correspond to individual arcs in the NHD linework. All new events that are created are therefore parsed to the arc level. In most situations, it makes sense to recombine events that occur on multiple arcs if they occur consecutively on the same route. For example, a source event on the NHD reach system may be run through the cross reference table and parsed out to 3 different events on the same LLID (LLID X, from 0 to 250 feet, LLID X, from 250 feet to 750 feet, LLID X from 750 feet to 900 feet). Aggregating these events will recombine them to make one single event (LLID X, from 0 to 900 feet). If there are any true gaps in the data then these will be preserved when the aggregation procedure is run. For example, if the source NHD event was parsed out to 3 events (LLID X, from 0 to 250 feet, LLID X from 250 feet to 700 feet, LLID X from 800 feet to 900 feet), aggregating these events will recombine them as two events (LLID X from 0 to 700 feet, LLID X from 800 feet to 900 feet), preserving the gap. The aggregated events are pasted to a new table named AggLLIDEvents so the parsed events are still available in the LLIDEvents table even if the aggregation procedure is run.

If the aggregation procedure is run (this is recommended), then it may take several more minutes to complete. Once this is finished, the data will have been converted to the LLID-based system. If the aggregation procedure was run, the new LLID-based events will be stored in the table named AggLLIDEvents, and regardless of whether the aggregation procedure was run, parsed LLID-based events will be stored in the table named LLIDEvents. You should be able to view and open these tables directly from database view when the application is finished. If they don't appear, the view can be refreshed by clicking on the 'queries' tab and then clicking on the 'tables' tab to return to the tables view. Each new event will have a HUC (the USGS 4th code subbasin), an LLID code, and from and to measurements (in feet) that describe the location of this event on the LLID route. These coordinates may be used to map out the data on the LLID route system that is provided with the PNW reach files and the enhanced NHD files. The PNW Reach File GIS data may be downloaded from the StreamNet homesite at PNW Reach File or the NHD layer that was enhanced for this project by building the LLID-based routing system on top of it may be downloaded from the StreamNet site at http://www.streamnet.org/nhdllid/regionmap.html.

Each new LLID event will also contain a field named 'EvntKey'. This links the new event back to the original source NHD reach-based event that your data is tied to. Since one NHD event can sometimes correspond to multiple LLID routes, this source event may now occur as multiple locations. These new event locations may be linked back to the source data through any standard database software by linking on this event key field. In Access, this can be done through a query by adding both tables and then dragging a link between the event key fields and then selecting the fields that you want to display from the query. For more help on how to create an Access query, read the "Working with Queries" section under contents in Access help. If this query does not work because of a "type mismatch in the join expression", this is most likely because the event key fields are of different data types (i.e. text vs integer). The application automatically uses the event key as a text string, regardless of the source field data type. To run the query, you need to make these the same data type, either by changing the event key in the source event table to a 'text' data type or by changing the event key in the output events to match the data type of the event key in the source table. Field data types may be changed by opening the table in design view and right-clicking the data type column next to the field name.

It's also important to check the table UnconvertedEvents to see if any of your source events could not be translated successfully. If a source event is written to this table, then it could be for a couple of different reasons:

Does the NHD Reach occur in the CrossRef table? If not, it may be a typing error or a new NHD reach that your organization added that is not part of the PNW Reach files. For information about NHD reaches, visit the NHD home site

Do the coordinates of the event exceed those in the cross-reference table? For example, an NHD reach is typically defined from 0 to 100%. If a source event is defined entirely outside of this range as NHD Reach X from 100% to 120%, then it won't be translated.

Accuracy, Cautions, and Limitations

It is important for users of the data conversion application to know that there are limitations to the accuracy of translation and that there is also a potential for errors when older or modified versions of the route systems are used to reference data. These issues may cause data to be inaccurately translated through the application. Fortunately, these potential inaccuracies are mostly limited to a few routes and there are a couple of possible methods to identify these situations where inaccurate translation of data may occur.

As discussed previously, the LLID/NHD cross reference table that is used by the data conversion application was developed by rebuilding the LLID route system from the PNW Reach files on top of the NHD arc coverages. It basically involved developing automated and semi-automated methods to rebuild the routes on the NHD linework and then screening the results of this rebuild for inaccuracies. Whenever an inaccurate rebuild of the LLID route was found, it was corrected by using Arc/Info software to build the route manually, repeating this QA process as necessary until it was built as accurately as possible on the NHD linework. This process is described in more detail in the metadata section below. The results of this rebuild are contained in the table named CrossReferenceQA, which is contained in the application database. This table contains the following fields:

HUC - The USGS hydrologic unit code (4th code subbasin) that the LLID route is in.

LLID - The 13-digit code LLID route identifier

NHD_length - The length, in feet, of this LLID route after it was rebuilt on the NHD linework

PNW_length - The length, in feet, of the original LLID route from the PNW reach file

difference - The difference between the NHD_length and the PNW_length. This is essentially the level of accuracy of the rebuild, with the desirable result being the smallest possible difference

comments - Whenever an LLID route could not be rebuilt on the NHD with a difference of less than 100 feet, it was examined and the reason for the discrepancy is entered in the comments field

Note: On major rivers like the Columbia, which pass through various HUCs, there will be a separate record in this table for each HUC that the river passes through. Route measurements for these rivers were squared up at the beginning the route in each HUC with the original route measure to ensure accurate translation of data.

The final results of the rebuild work are contained in the CrossReferenceQA table and can be summarized as follows.

Out of 71,161 total LLID routes,

68,250 (95.9%) were rebuilt within a tolerance of 5 feet or less of the original route.

1,821 (2.6%) were rebuilt within a tolerance of 5 to 20 feet of the original route.

637 (0.9%) were rebuilt within a tolerance of 20 to 100 feet of the original route.

404 (0.6%) were rebuilt with a tolerance greater than 100 feet of the original route. Because of various changes to the NHD linework, some of these situations may still be accurate even though the routes differed significantly in total length (see discussion of this below).

49 (0.07%) could not be rebuilt because their linework had been eliminated in the NHD.

For the purposes of this project, a rebuilt route was examined and corrected whenever the distance between the original and rebuilt routes was greater than 100 feet. In some cases the NHD linework was found to have been changed from the source PNW Reach file line work. In these cases, the LLID route was built as faithfully as possible on the NHD linework, and then a comment was added to explain why the difference was greater than 100 feet. In most cases, the comment will say "OK, linework changed in NHD" meaning that the linework was modified somewhat in on the arcs that the route is on so consequently events translated on this route may vary by as much as the difference value. In many cases, the NHD linework was adjusted in connector arcs that connect a stream route from its origin at the mouth of the lake to the artificial center line of the lake, but the linework was the same over the true course of the stream from the mouth to the headwaters. In these cases, an adjusted route measurement was used to ensure that the measurement from the true mouth of the river (and hence all points upstream) was accurate. The difference value for these situations will still be high but this will be because of the differences in linework in the connector arcs in the lake and will not affect events that are tied to the actual river. These situations will have a comment that is something like this: "OK, first arc longer in NHD, used adjusted route meas" or "OK, connector arcs changed in NHD. Used adjusted route measure." Occasionally, this also occurred in headwaters areas where the NHD added or removed linework at the end (headwaters) of a route, so measurements below this will be accurately translated but any events in the headwaters area may not be accurately translated. These situations will have a comment that reads something like this: "OK, NHD eliminates linework at end of route." At the borders with California and Nevada, another situation occurred sometimes where a PNW Reach file arc had been split at the border, but the NHD linework included the entire arc. To rebuild the route accurately in these areas, it was necessary to use an adjusted start route measure at the border, so even though the route was rebuilt accurately, the difference value will be high. These situations will have a comment that reads something like this: "OK, used adjusted measure due to state boundary clip". Another situation that occurred was routes that could not be rebuilt because in the linework for these routes had been eliminated or moved to a different HUC in the NHD. Typically, these were very short routes, many of them actually sections of routes that were moved to the correct HUC in the NHD. In the latter case, the route may have been successfully built, but the section that was moved just did not show up in the original HUC, hence a record in the QA table. These situations can be found by querying for all records where the difference value is null (but not zero, an important distinction) and the comment will read something like "OK, No linework in NHD".

It is recommended that users check their LLID routes against this QA table to determine if there are any situations where inaccuracies or the special situations described above may occur with the events that they are converting. If you are running the LLID to NHD conversion, this may be done by first running a query to link your source events to this table on the LLID field, and viewing the QA information for the LLIDs that your events are on. If you are running the NHD to LLID conversion, this may be done by comparing the output events that you generate after the data conversion is run with this QA table in the same way. Users may also wish to ensure an accuracy level of translation of better than 100 feet for their data. This can be done by filtering the cross-reference table to only those routes within a predefined accuracy limit. For example, if your data type requires a confidence of 30 feet or less, then you could rename the original cross-reference table and make a copy of it (right click the table and choose the copy option). Then name the new (copied) table "crossreference" so that it will be used by the conversion application when it is run. In this new table, you can then delete all records where the difference value was greater than 30 feet and then perform the data conversion. Only records that were on routes with a difference of 30 feet or better will then be translated. Any other events will be written out to the UnconvertedEvents table.

Another concern may be whether you are using a current version of the NHD or LLID route systems to reference your events to. The data conversion application was built during the Spring/Summer of 2001 and references the NHD reach-based routing system and PNW Reach Files LLID-based routing systems as they stood at that time. There are currently no definite plans to keep the application up-to-date with future modifications so if changes to the two hydrography sets do occur, then these may not be reflected in the application you are using. If the application is maintained to reflect any changes made to the NHD or LLID route systems, the version with the most current information will be available for download at http://www.streamnet.org/nhdllid/. It is unclear at this time whether the NHD will be managed actively in the Pacific Northwest to encourage modifications. The PNW Reach files have been maintained by the StreamNet project at Pacific States Marine Fisheries Commission since 1997. The LLID route system was built during this time and although the overall emphasis has been on keeping it static, there have been some modifications made when the state GIS managers of the files wanted to make corrections to the LLID system in their states. It is believed that there were few if any changes made during the period between the building of the routes and the Summer of 1999. Since the Summer of 1999, a Data Maintenance Log File has been maintained, which details any changes or enhancements made to the LLID route system. No changes to the underlying PNW Reach file linework have been made during this period.

If your organization is using an older version of the LLID routing system, it's a good idea to check to see if any of your events fall on LLIDs that have been modified. To do so, download the log file from the link above (it is available as an Access table or text-delimited file). Design a query to link your event table by LLID to the log file LLID field and then view the log information for any records that do occur in both tables. If your organization has modified the LLID or NHD route systems that you use, this may also cause data to be converted incorrectly. If there is a log of changes that you have made, it is recommended that you check these changed routes against the ones used by the data conversion application in a GIS software. The GIS files that the cross reference application was built with (and contain both the LLID and NHD routing systems) are available for download from http://www.streamnet.org/nhdllid/regionmap.html.

One other thing to be aware of when using the application is that source events that fall patially (but not completely) on stream segments covered in the cross reference table will be translated and written as output events. This may occur for any of the reasons discussed regarding inaccurate translation or out-of-date or modified hydrography. For example, if a source event is on LLID X from 2000 to 3000 feet, but it only is defined in the current GIS files and the cross reference table as LLID X from 0 to 2500 feet, the portion of the event that is represented (LLID X from 2000 to 2500 feet) will be translated but the portion that is not (LLID X from 2500 to 3000 feet) will not be translated. These partially converted events will not be readily apparent because they will not be written to the UnconvertedEvents table since the event itself was translated in part. For most data types, it makes sense to still use partially translated events but in some cases, it may be important to discard any events that were not entirely translated. The best method to do this is to run the application twice to return your events to their original format. For example, if you are converting from LLID to NHD, when this LLID to NHD data conversion is complete, run the reverse conversion process (NHD to LLID) with the NHD-based results to rebuild your data as LLID events. When this is complete, design a query to compute the length of each event in both the new and source events (group by EvntKey and compute a new field that is the sum of the length of each event (ToMeasure - FromMeasure). Compare the total length of each end event to that of each corresponding source event. Where these distances are different, and the end event is shorter than the source event in length, there has only been a partial translation of the data because some of the source data falls outside the area defined in the cross reference table. You may then choose to discard any results for these events if you do not want to use partial translations of data.

Finally, it is not a bad idea to map out your events in GIS software after they have been converted to a different routing system and to overlay them with the original source events on the other routing system. This is a good way to quickly check to make sure that the conversion was accurate. An easy way to do this is to color one layer red and the other layer blue and then to view them together, alternately with one layer on top and then the other on top, to see if they match up correctly.

Customizing the Application for use with 1:24k Hydrography or with Other Route Systems

This application was designed so that it may easily be customized for use in the future with 1:24,000 scale hydrography or with other route systems. At the time of the application design, neither the LLID routing system or NHD were complete at the 1:24,000 scale, but there was substantial progress and discussion toward the design of these products. If these are developed on the same linework, then it will be possible to convert tabular event data between these two systems through this application. To do this, the table CrossRef need only be changed to include information from the 1:24,000 scale layer instead of the 1:100,000 scale layer, which it currently describes. Assuming that a 1:24,000 scale layer has been built with both LLID-based and NHD reach-based routing systems, it is a fairly simple procedure to relate the coordinate information from these two route systems back to each arc in the layer. This may be done in either GIS software like Arc/Info, or by moving the info tables to a relational database like Access and linking the records up there. Each route section in the .sec table in the Arc/Info dynamic segmentation model contains an arclink# that links it to an arc in the arc attribute table (.aat). After these links are made, the end result should be a table with the same information as the CrossRef table, with the LLID and NHD reach coordinate information both filled in for each arc. The application can then be run in the same way as it is at the 1:100,000 scale to translate event data between the two systems. If a 1:24,000 scale hydrography is developed with only one of the systems (LLID or NHD) as a routing system and the other as events on that system, it should still be a relatively simple process to derive the cross reference table, which in fact may closely resemble what the event table would look like under this scenario.

It is similarly possible to use the application for LLID/NHD translation outside of the current design area of Washington, Oregon, Idaho, or W.Montana, or to even use it with completely different route systems that aren't related to LLIDs or NHDs. As with the use of the application at the 1:24,000 scale described above, it is necessary to replace the current information in the CrossRef table with the information from the GIS files that you are using. This may entail the conversion of data between LLID and NHD systems or entirely different systems. In the latter case, the only requirement is that there be two route systems built on the same arc linework, and (unless modifications are made to the VBA code) that one system be based on percentage measurements (like the NHD) and the other system be based on real-world measurements (like the LLID). Since the application is completely designed with open-source code, the forms and modules may be changed and the LLID and NHD route systems renamed.

Some users may also prefer to use the application only for specific area(s) within the Pacific Northwest. To increase speed, these users can restrict the application to their area of interest by deleting all records from the CrossRef table that correspond to areas that they are not interested in (it may be best to make a backup copy of the CrossRef table renamed to something else before doing this). The first 8 digits of the NHD reach code for each record in the cross ref table describes the USGS 4th code hydrologic unit (subbasin) that the reach falls in and can be filtered to include only specific areas. For example, if a user was only interested in the HUCs of the Yakima Basin, they could keep all records where the reach code was preceded by 17030001, 17030002, or 17030003 (the HUCs of the Yakima basin) and discard the rest. The application should then run considerably faster because it will be working through a much smaller table. For a complete list of Northwest HUC codes and watershed names, please see ftp://ftp.streamnet.org/pub/streamnet/ASCII_Data/huc.txt

For more help on how to use the data conversion application at the 1:24,000 scale or with other route systems, please contact StreamNetGIS@psmfc.org

.

# NHD/LLID cross reference files and data conversion application metadata

- Identification_Information
- Data_Quality_Information
- Spatial_Data_Organization_Information
- Spatial_Reference_Information
- Entity_and_Attribute_Information
- Distribution_Information
- Metadata_Reference_Information

Identification_Information:
  Citation:
    Citation_Information:
      Originator: StreamNet Project, Pacific States Marine Fisheries Commission
      Publication_Date: October, 2001
      Title: NHD/LLID cross reference files and data conversion application
      Edition: 1
      Geospatial_Data_Presentation_Form: vector digital data
      Online_Linkage: http://www.streamnet.org/nhdllid/
  Description:
    Abstract:
      The StreamNet project, Pacific States Marine Fisheries Commission, in cooperation with the U.S Environmental Protection Agency and the U.S Geological Survey, has completed a data conversion tool for converting event data (tabular data tied to a GIS route system) from the 1:100,000 scale National Hydrography Dataset (NHD) reach-based routing system to the 1:100,000 scale PNW Reach File LLID-based routing system. This tool also works in the reverse (converting data from LLID to NHD). This tool is programmed in MS Access with VBA in and uses a cross reference table which was developed by rebuilding the LLID route system onto the NHD GIS files. The data conversion tool is available as either an Access 97 or Access 2000 database. The GIS files (enhanced NHD with LLID routes) are also available in an arc export (.e00) format. These products and accompanying documentation, are available for free download and usage from http://www.streamnet.org/nhdllid/. These tools are intended to assist hydrography users from the Pacific Northwest with their data management and conversion and may be customized for uses in other areas or at finer scales (see help section for more details on this). It is recommended that all users of the tools and/or GIS files review the user help document before use. Future versions of this tool and files are not currently planned but if users discover any errors or potential enhancements, they are encouraged to send them to StreamNetGIS@psmfc.org . Time permitting, improvements will be made.

      *********************************************************************************************************************************************

      Note: This metadata set describes the products of the NHD/LLID data conversion project, which include:

      (a) A complete set of National Hydrography Dataset (NHD) files for the states of Washington, Oregon, Idaho, and Western Montana with

      the 1:100,000 scale LLID routing system from the PNW Reach file built onto them.

      (b) The NHD/LLID data conversion application: An Access database that may be used to convert event data between the NHD and LLID-based routing systems.

      Insofar as the development of product (a) was an enhancement to the NHD, only this enhanced feature, the LLID-based routing system, is described within this metadata. Complete metadata and documentation for the NHD is available from <http://nhd.usgs.gov>

      *********************************************************************************************************************************************

    Purpose:
      To date, many Northwest agencies and organizations have been utilizing the PNW Reach files LLID-based routing system to reference their geographic stream-based data. Many of these agencies and organizations may now plan to switch to the NHD. To do so, they face the issue of how to convert their pre-existing data that is tied to the LLID-based system over to the NHD reach-based system. Other organizations and agencies that will continue to maintain their data on the PNW Reach files may need the flexibility to convert data from future NHD sources to the LLID system or vice versa so that data may be freely exchanged in both formats. Therefore, a need exists in the region for an application that may be used to efficiently and accurately convert stream-based data between the NHD and LLID-based systems. The NHD/LLID data conversion application is designed for this purpose. The related GIS files, which are the NHD files with the LLID-based routing system from the PNW Reach File built onto them, may also be helpful for the display, management, or analysis of data from both route systems.
  Time_Period_of_Content:
    Time_Period_Information:
      Single_Date/Time:
        Calendar_Date: October, 2001
    Currentness_Reference: publication date
  Status:
    Progress: Complete
    Maintenance_and_Update_Frequency:

      The application has been updated to implement small corrections or enhancements:

      version 1.1 - Added enhancements to improve speed and performance, including indexing of tables, error trapping for certain situations, and clarified documentation.

      version 1.2 - It was noticed that in HUCs 17010101 and 17010213, which straddle the Montana/Idaho border, LLID routing information had not been completed for the Montana portion of these HUCs. To remedy this, LLID routes were built and QA'd on the Montana streams, and the GIS files for these HUCs were updated with this new information and the crossreference information for these streams was added to the database application.

      Further updates are possible in the future but are not currently planned.

  Spatial_Domain:
    Bounding_Coordinates:
      West_Bounding_Coordinate: -125.001232
      East_Bounding_Coordinate: -110.644797
      North_Bounding_Coordinate: 49.002622
      South_Bounding_Coordinate: 40.763408
  Keywords:
    Theme:
      Theme_Keyword_Thesaurus: Standard English Thesaurus
      Theme_Keyword: NHD/LLID
      Theme_Keyword: NHD
      Theme_Keyword: LLID
      Theme_Keyword: National Hydrography Dataset
      Theme_Keyword: data conversion
      Theme_Keyword: event table
      Theme_Keyword: route system
      Theme_Keyword: hydrography
      Theme_Keyword: PNW Reach File
  Access_Constraints: none
  Use_Constraints: none
  Point_of_Contact:
    Contact_Information:
      Contact_Person_Primary:
        Contact_Person: StreamNet GIS Specialist
        Contact_Organization: StreamNet Project, Pacific States Marine Fisheries Commission
      Contact_Position: GIS Specialist
      Contact_Address:
        Address_Type: mailing and physical address
        Address: 45 SE 82nd Drive, Suite #100
        City: Gladstone
        State_or_Province: OR
        Postal_Code: 97027-2522
        Country: USA
      Contact_Voice_Telephone: (503) 595-3200
      Contact_Facsimile_Telephone: (503) 595-3232
      Contact_Electronic_Mail_Address: StreamNetGIS@psmfc.org
      Hours_of_Service: 8:30 AM - 5:30 PM
  Data_Set_Credit:
    StreamNet Project, Pacific States Marine Fisheries Commission, in cooperation with the U.S Environmental Protection Agency and the U.S Geological Survey
  Native_Data_Set_Environment:
    Microsoft Windows NT Version 4.0 (Build 1381) Service Pack 6; ESRI ArcCatalog 8.1.0.642

Data_Quality_Information:
  Attribute_Accuracy:
    Attribute_Accuracy_Report:
      It is important for users of the data conversion application to know that there are limitations to the accuracy of translation and that there is also a potential for errors when older or modified versions of the route systems are used to reference data. These issues may cause data to be inaccurately translated through the application. Fortunately, these potential inaccuracies are mostly limited to a few routes and there are a couple of possible methods to identify these situations where inaccurate translation of data may occur.

      As discussed previously, the LLID/NHD cross reference table that is used by the data conversion application was developed by rebuilding the LLID route system from the PNW Reach files on top of the NHD arc coverages. The rebuild was accomplished through a multi-step process with AML's (Arc Macro Language scripts): (1) Derived a preliminary cross reference table of LLID sections to NHD reaches, using the RCL table that is included with most PNW NHD coverages. (2) Used this preliminary cross reference to rebuild the LLID routes on the NHD. (3) Checked results. Where routes were found that were not rebuilt, used a conflation based approach to geographically determine the correct NHD arcs that an LLID route should include and then built these LLID routes onto the NHD. (4) The results of the rebuilds were then screened for inaccuracies. Whenever an inaccurate rebuild of the LLID route was found, it was corrected by using Arc/Info software to build the route manually, repeating this QA process as necessary until it was built as accurately as possible on the NHD linework. The results of this rebuild are contained in the table named CrossReferenceQA, which is contained in the application database. This table contains the following fields:

      HUC - The USGS hydrologic unit code (4th code subbasin) that the LLID route is in.

      LLID - The 13-digit code LLID route identifier

      NHD_length - The length, in feet, of this LLID route after it was rebuilt on the NHD linework

      PNW_length - The length, in feet, of the original LLID route from the PNW reach file

      difference - The difference between the NHD_length and the PNW_length. This is essentially the level of accuracy of the rebuild, with the desirable result being the smallest possible difference

      comments - Whenever an LLID route could not be rebuilt on the NHD with a difference of less than 100 feet, it was examined and the reason for the discrepancy is entered in the comments field

      Note: On major rivers like the Columbia, which pass through various HUCs, there will be a separate record in this table for each HUC that the river passes through. Route measurements for these rivers were squared up at the beginning the route in each HUC with the original route measure to ensure accurate translation of data.

      The final results of the rebuild work are contained in the CrossReferenceQA table and can be summarized as follows.

      Out of 71,161 total LLID routes,

      68,250 (95.9%) were rebuilt within a tolerance of 5 feet or less of the original route.

      1,821 (2.6%) were rebuilt within a tolerance of 5 to 20 feet of the original route.

      637 (0.9%) were rebuilt within a tolerance of 20 to 100 feet of the original route.

      404 (0.6%) were rebuilt with a tolerance greater than 100 feet of the original route. Because of various changes to the NHD linework, some of these situations may still be accurate even though the routes differed significantly in total length (see discussion of this below).

      49 (0.07%) could not be rebuilt because their linework had been eliminated in the NHD.

      For the purposes of this project, a rebuilt route was examined and corrected whenever the distance between the original and rebuilt routes was greater than 100 feet. In some cases the NHD linework was found to have been changed from the source PNW Reach file line work. In these cases, the LLID route was built as faithfully as possible on the NHD linework, and then a comment was added to explain why the difference was greater than 100 feet. In most cases, the comment will say "OK, linework changed in NHD" meaning that the linework was modified somewhat in on the arcs that the route is on so consequently events translated on this route may vary by as much as the difference value. In many cases, the NHD linework was adjusted in connector arcs that connect a stream route from its origin at the mouth of the lake to the artificial center line of the lake, but the linework was the same over the true course of the stream from the mouth to the headwaters. In these cases, an adjusted route measurement was used to ensure that the measurement from the true mouth of the river (and hence all points upstream) was accurate. The difference value for these situations will still be high but this will be because of the differences in linework in the connector arcs in the lake and will not affect events that are tied to the actual river. These situations will have a comment that is something like this: "OK, first arc longer in NHD, used adjusted route meas" or "OK, connector arcs changed in NHD. Used adjusted route measure." Occasionally, this also occurred in headwaters areas where the NHD added or removed linework at the end (headwaters) of a route, so measurements below this will be accurately translated but any events in the headwaters area may not be accurately translated. These situations will have a comment that reads something like this: "OK, NHD eliminates linework at end of route." At the borders with California and Nevada, another situation occurred sometimes where a PNW Reach file arc had been split at the border, but the NHD linework included the entire arc. To rebuild the route accurately in these areas, it was necessary to use an adjusted start route measure at the border, so even though the route was rebuilt accurately, the difference value will be high. These situations will have a comment that reads something like this: "OK, used adjusted measure due to state boundary clip". Another situation that occurred was routes that could not be rebuilt because in the linework for these routes had been eliminated or moved to a different HUC in the NHD. Typically, these were very short routes, many of them actually sections of routes that were moved to the correct HUC in the NHD. In the latter case, the route may have been successfully built, but the section that was moved just did not show up in the original HUC, hence a record in the QA table. These situations can be found by querying for all records where the difference value is null (but not zero, an important distinction) and the comment will read something like "OK, No linework in NHD".

      It is recommended that users check their LLID routes against this QA table to determine if there are any situations where inaccuracies or the special situations described above may occur with the events that they are converting. If you are running the LLID to NHD conversion, this may be done by first running a query to link your source events to this table on the LLID field, and viewing the QA information for the LLIDs that your events are on. If you are running the NHD to LLID conversion, this may be done by comparing the output events that you generate after the data conversion is run with this QA table in the same way. Users may also wish to ensure an accuracy level of translation of better than 100 feet for their data. This can be done by filtering the cross-reference table to only those routes within a predefined accuracy limit. For example, if your data type requires a confidence of 30 feet or less, then you could rename the original cross-reference table and make a copy of it (right click the table and choose the copy option). Then name the new (copied) table "crossreference" so that it will be used by the conversion application when it is run. In this new table, you can then delete all records where the difference value was greater than 30 feet and then perform the data conversion. Only records that were on routes with a difference of 30 feet or better will then be translated. Any other events will be written out to the UnconvertedEvents table.

      Another concern may be whether you are using a current version of the NHD or LLID route systems to reference your events to. The data conversion application was built during the Spring/Summer of 2001 and references the NHD reach-based routing system and PNW Reach Files LLID-based routing systems as they stood at that time. There are currently no definite plans to keep the application up-to-date with future modifications so if changes to the two hydrography sets do occur, then these may not be reflected in the application you are using. If the application is maintained to reflect any changes made to the NHD or LLID route systems, the version with the most current information will be available for download at http://www.streamnet.org/nhdllid. It is unclear at this time whether the NHD will be managed actively in the Pacific Northwest to encourage modifications. The PNW Reach files have been maintained by the StreamNet project at Pacific States Marine Fisheries Commission since 1997. The LLID route system was built during this time and although the overall emphasis has been on keeping it static, there have been some modifications made when the state GIS managers of the files wanted to make corrections to the LLID system in their states. It is believed that there were few if any changes made during the period between the building of the routes and the Summer of 1999. Since the Summer of 1999, a Data Maintenance Log File has been maintained to detail any changes or enhancements made to the LLID route system. No changes to the underlying PNW Reach file linework have been made during this period.

      If your organization is using an older version of the LLID routing system, it's a good idea to check to see if any of your events fall on LLIDs that have been modified. To do so, download the log file from the link above (it is available as an Access table or text-delimited file). Design a query to link your event table by LLID to the log file LLID field and then view the log information for any records that do occur in both tables. If your organization has modified the LLID or NHD route systems that you use, this may also cause data to be converted incorrectly. If there is a log of changes that you have made, it is recommended that you check these changed routes against the ones used by the data conversion application in a GIS software. The GIS files that the cross reference application was built with (and contain both the LLID and NHD routing systems) are available for download from http://www.streamnet.org/nhdllid/regionmap.html.

      One other thing to be aware of when using the application is that source events that fall patially (but not completely) on stream segments covered in the cross reference table will be translated and written as output events. This may occur for any of the reasons discussed regarding inaccurate translation or out-of-date or modified hydrography. For example, if a source event is on LLID X from 2000 to 3000 feet, but it only is defined in the current GIS files and the cross reference table as LLID X from 0 to 2500 feet, the portion of the event that is represented (LLID X from 2000 to 2500 feet) will be translated but the portion that is not (LLID X from 2500 to 3000 feet) will not be translated. These partially converted events will not be readily apparent because they will not be written to the UnconvertedEvents table since the event itself was translated in part. For most data types, it makes sense to still use partially translated events but in some cases, it may be important to discard any events that were not entirely translated. The best method to do this is to run the application twice to return your events to their original format. For example, if you are converting from LLID to NHD, when this LLID to NHD data conversion is complete, run the reverse conversion process (NHD to LLID) with the NHD-based results to rebuild your data as LLID events. When this is complete, design a query to compute the length of each event in both the new and source events (group by EvntKey and compute a new field that is the sum of the length of each event (ToMeasure - FromMeasure). Compare the total length of each end event to that of each corresponding source event. Where these distances are different, and the end event is shorter than the source event in length, there has only been a partial translation of the data because some of the source data falls outside the area defined in the cross reference table. You may then choose to discard any results for these events if you do not want to use partial translations of data.

      Finally, it is not a bad idea to map out your events in GIS software after they have been converted to a different routing system and to overlay them with the original source events on the other routing system. This is a good way to quickly check to make sure that the conversion was accurate. An easy way to do this is to color one layer red and the other layer blue and then to view them together, alternately with one layer on top and then the other on top, to see if they match up correctly.

  Logical_Consistency_Report: Logically consistent (arcs connect to nodes, etc.)
  Completeness_Report: Complete data set
  Positional_Accuracy:
    Horizontal_Positional_Accuracy:
      Horizontal_Positional_Accuracy_Report:
        See Attribute Accuracy Report for a discussion of overall accuracy, including positional accuracy.
    Vertical_Positional_Accuracy:
      Vertical_Positional_Accuracy_Report:
        See Attribute Accuracy Report for a discussion of overall accuracy, including positional accuracy.
  Lineage:
    Source_Information:
      Source_Scale_Denominator: 1:100,000
      Type_of_Source_Media: online
      Source_Time_Period_of_Content:
        Time_Period_Information:
          Single_Date/Time:
            Calendar_Date: November, 2001
        Source_Currentness_Reference: publication date
      Source_Citation_Abbreviation: NHD, PNW Reach File
      Source_Contribution:
        NHD - Environmental Protection Agency and US Geological Survey

        PNW Reach File - Environmental Protection Agency, US Geological Survey, Bonneville Power Administration, StreamNet, Oregon Dept of Fish & Wildlife, Washington Dept of Fish & Wildlife, Idaho Dept of Fish and Game, Montana Dept of Fish, Wildlife, and Parks

    Process_Step:
      Process_Description:
        A multi-step procedure was outlined to develop a complete and accurate cross-reference table and to build an application through which agencies and organizations can translate their data between the LLID-based system and NHD reaches. The procedure steps below detail the entire process that was used to develop the end products.

        Step 1 - Build the preliminary cross reference table between LLIDs and NHD reaches

        The RCL cross reference table which is provided with the NHD is a direct cross-reference between NHD reaches and PNW reaches. This is used as the starting point to develop the final cross reference table. The first step is to convert this table to one that is a link between LLIDs and NHD reaches (rather than PNW reaches and NHD reaches). An AML has been built here to do this for each HUC. The procedure is straightforward: In each PNW Reach HUC, the LLID, FMeas, and TMeas attributes are transferred over from the section table to the corresponding reaches in the arc table. The resulting table (a cross-reference of PNW reaches to LLID & measurements) is then copied by the AML into the NHD directory. A new table is then created using this PNW cross reference and the NHD RCL by linking on the PNW reach code. This new table is the preliminary cross reference and contains the following fields: NHD_Reach Code, LLID, FMeas, and TMeas.

        Step 2 - Use the preliminary cross reference table to rebuild the LLID routes on the NHD arc features

        The next step is to rebuild the LLID routes on the NHD. An AML has been designed here to do this. The AML cycles through the unique list of LLIDs for this HUC. For each LLID, it selects the NHD reaches that are linked to that LLID in the preliminary cross reference table. It then selects the point where the LLID FMeas= 0 (the start of the stream route) and builds the LLID route on the selected arcs, beginning at this point of origin. If for any reason the NHD arcs that correspond to the LLID cannot be routed (most likely because they are not continuous or a point of origin cannot determined), the AML then writes the LLID code to a text file which will list all of the LLIDs that could not be routed. This will occur in situations where the preliminary cross-reference table cannot be used to completely rebuild the routes. Generally, these are areas where the route passes through a lake or reservoir but also may include other spots where the new NHD and PNW reaches do not correspond on a 1-to-1 basis.

        Step 3 - Build the routes that could not be built automatically with the cross-reference table

        At this point, it is necessary to rebuild the routes that could not be built automatically. Since there is no cross-reference to the NHD for these, this process probably could not be successfully automated and would have to be done interactively for each route. Based on the percentage of routes that cross lakes or reservoirs (7% estimated) and assuming a few other abnormalities in the cross-reference table (reaches w/o a 1-to-1 correspondence in the NHD and PNW, etc.), it is estimated that this work will take approximately forty-five minutes per 4th field HUC to complete. For each LLID route, this process is to bring both the PNW route and the NHD arcs on screen, visually ensure that the correct NHD arcs are selected, identify the point of origin of the route and then enter the command to the GIS software to build the route. The LLID attribute then needs to then be entered into the arc route attribute table for each route.

        Step 4 - QA the routes

        Once Step 3 is completed and all LLID routes have been built on the NHD coverages, it is necessary to QA the results to ensure that this has been done correctly and fix any errors where they might have occurred. The most reliable approach is to check the length of the routes. Since the linework between the PNW reach files and the NHD is essentially the same, when the routes are rebuilt, they should be of the same length as the original routes on the PNW Reach files. An AML will be designed that dumps the length information of both the routes in the NHD and the routes in the PNW by LLID to a database, where they may then be compared to each other. When the routes are off in length by any significant measure or percentage, the routes will be checked and corrected if necessary. A preliminary test of this procedure was run on HUC 17100203 and the results were very encouraging. Of 361 routes (LLIDs), the mean deviation between the total length of each route rebuilt on the NHD and the total length of the route on the PNW Reach files was 1.19 feet (or .000072 % of the total stream length). The largest deviation was 7.14 feet, and 97.8 % of the routes deviated by less than 4 feet. These small deviations are most likely due to slight differences in the linework of the NHD and PNW reach files that developed through the process that was used to ungenerate and regenerate the coordinates when the linework was originally transferred from the PNW reach files to the NHD and the reprojection of the data. Issues of "slippage" which may occur when these small deviations are repeated over the course of long rivers like the Columbia can be avoided by building the cross-reference on a huc-by-huc basis so that the coordinates are squared up at each HUC boundary.

        Step 5 - Complete the cross reference table

        Once all of the LLID routes have been successfully built on the NHD and QA'd for accuracy, it is then possible to generate the complete cross-reference table from these results. An AML will be built which moves the LLID and measurement information over from the Section tables to the Arc tables on the NHD coverages. This information may then be dumped along with NHD attributes to a table which will contain the following fields: NHD_Reach, FMeas, Tmeas, LLID, FMeas, TMeas. (Note: NHD reaches are routed in proportion rather than in a direct measurement like feet. So, each NHD reach is routed from 0 % to 100%) A complete cross reference table will then have been established.

        Step 6 - Build an application to translate data between the two systems

        The cross-reference table in itself may be used to translate a record from LLID to NHD or vice versa, but it can be difficult to do this for large data sets without an automated procedure. To gain full advantage of the cross-reference table, it would be helpful to have an application that automates this procedure for large sets of data. We can develop this as a Visual Basic procedure in MS Access through which an input table which contains LLID, FMeas, TMeas attributes for location can automatically be translated to NHD, FMeas, TMeas attributes or vice versa. This application will take some programming and testing. In essence, it will run through a list of data records and for each record it will perform the conversion and feed the results to an output table. For example, if a data record is tied to LLID X, From 700 to 1300 feet, the procedure will search through the cross reference table to find the NHD reach(es) that correspond to this record. It will calculate the translation and then output the data record as a single or multiple records in another table which details the NHD reaches (and measurements where applicable) that the original LLID-based data corresponds to. An example of the output might be: NHD Reach A, 57.3% to 100%, NHD Reach B, 0% to 100%, NHD Reach C, 0% to 100%, and NHD Reach D, 0% to 23.2%. The data record is then tied to the NHD system and can be used with the NHD GIS coverages. Another process will be included through which one could feed this data tied to NHD reaches to return the LLID-based location information. The capability to automate this for large data sets will make this application helpful for users in the region to transfer existing data sets from the LLID-based system and the NHD system or exchange old and new data sets in either format.

        Step 7 - Document and Distribute the Results

        Although the intent is to design an application that will be very easy to use, full documentation will be written that details how to use the application to convert data and the procedure that was used to create the cross reference table and application. Once the documentation and the final products are complete, a web page will be designed and implemented to distribute the products and documentation. This site can reside at StreamNet or elsewhere. The final products and documentation will also be burned onto CDs for those who would prefer a hard copy version.

        Final Products

        The final products of this work will be:

        * Data Conversion application: An Access application which has the built in features to automatically convert data between the LLID-based system and the NHD. A user will be able to import a table of data that is tied to either system and click a button to convert the data to and from either system. A resulting table will be built with the original data tied to the new system. The conversion will be from LLID/FMEAS/TMEAS to NHD_REACH/FMEAS/TMEAS or vice versa. The process will be straight forward and easy to use, but documentation will also be included.

        * A set of the NHD GIS coverages for the Pacific Northwest (Washington, Oregon, Idaho, and W.Montana) by 4th field HUC with the complete LLID-based routes built onto the coverages.

        Both products will be made available via the StreamNet web site or elsewhere if preferred and through CD versions. This work will be completed at the 1:100,000 level since this is the current level of NHD resolution. If 1:24,000 linework is added to the NHD in the future, the application will work with this as long as the new streams information (1:24,000 LLIDs and 1:24,000 NHD) are cross-referenced and added to the cross-reference table in the same format as the existing 1:100,000 information.

      Process_Date: Spring/Summer 2001
      Process_Contact:
        Contact_Information:
          Contact_Person_Primary:
            Contact_Person: StreamNet GIS Specialist
            Contact_Organization: StreamNet Project, Pacific States Marine Fisheries Commission
          Contact_Position: GIS Specialist
          Contact_Address:
            Address_Type: mailing address
            Address: 205 SE Spokane st, Suite 100
            City: Portland
            State_or_Province: OR
            Postal_Code: 97202
            Country: USA
          Contact_Voice_Telephone: (503) 595-3200
          Contact_Facsimile_Telephone: (503) 595-3232
          Contact_Electronic_Mail_Address: StreamNetGIS@psmfc.org
          Hours_of_Service: 8:30 am to 5:30 pm
  Cloud_Cover: Not applicable

Spatial_Data_Organization_Information:
  Direct_Spatial_Reference_Method: Vector
  Point_and_Vector_Object_Information:
    SDTS_Terms_Description:
      SDTS_Point_and_Vector_Object_Type: Complete chain
      Point_and_Vector_Object_Count: 343340
    SDTS_Terms_Description:
      SDTS_Point_and_Vector_Object_Type: Point
      Point_and_Vector_Object_Count: 868
    SDTS_Terms_Description:
      SDTS_Point_and_Vector_Object_Type: Composite object
      Point_and_Vector_Object_Count: 71116

Spatial_Reference_Information:
  Horizontal_Coordinate_System_Definition:
    Geographic:
      Latitude_Resolution: 0.000000
      Longitude_Resolution: 0.000000
      Geographic_Coordinate_Units: Decimal degrees
    Geodetic_Model:
      Horizontal_Datum_Name: North American Datum of 1983
      Ellipsoid_Name: Geodetic Reference System 80
      Semi-major_Axis: 6378137.000000
      Denominator_of_Flattening_Ratio: 298.257222

Entity_and_Attribute_Information:
  Detailed_Description:
    Entity_Type:
      Entity_Type_Label: NHD.RatStreams
      Entity_Type_Definition: LLID route system attribute table
      Entity_Type_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: FID
      Attribute_Definition: Internal feature number.
      Attribute_Definition_Source: Arc/Info generated number.
      Attribute_Domain_Values:
        Unrepresentable_Domain:
          Sequential unique whole numbers that are automatically generated.
    Attribute:
      Attribute_Label: Shape
      Attribute_Definition: Feature geometry.
      Attribute_Definition_Source: Arc/Info generated field.
      Attribute_Domain_Values:
        Unrepresentable_Domain: Coordinates defining the features.
    Attribute:
      Attribute_Label: STREAMS#
      Attribute_Definition:
        Unique route identifier for each LLID-based route. Functions as a primary key for this table.
      Attribute_Definition_Source: Arc/Info generated number.
      Attribute_Domain_Values:
        Unrepresentable_Domain:
          Sequential unique whole numbers that are automatically generated.
    Attribute:
      Attribute_Label: STREAMS-ID
      Attribute_Definition: User-defined feature number.
      Attribute_Definition_Source: Arc/Info generated number.
      Attribute_Domain_Values:
        Unrepresentable_Domain:
          Sequential unique whole numbers that are automatically generated.
    Attribute:
      Attribute_Label: LLID
      Attribute_Definition:
        Longitude-latitude identifier which uniquely identifies each stream.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
      Attribute_Domain_Values:
        Enumerated_Domain:
          Enumerated_Domain_Value_Definition_Source:
            See <ftp://ftp.streamnet.org/pub/streamnet/ASCII_Data/LLIDStream.txt> for complete list of LLIDs.
    Attribute:
      Attribute_Label: NAME
      Attribute_Definition: Name of the stream or water body that this route represents.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
  Detailed_Description:
    Entity_Type:
      Entity_Type_Label: NHD.SecStreams
      Entity_Type_Definition: LLID route system section table
      Entity_Type_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: RouteLink#
      Attribute_Definition:
        Unique route identifier for each LLID-based route. Functions as a foreign key to link to the route attribute table (NHD.RatStreams)
      Attribute_Definition_Source: Arc/Info generated number
      Attribute_Domain_Values:
        Unrepresentable_Domain:
          Sequential unique whole numbers that are automatically generated.
    Attribute:
      Attribute_Label: ArcLink#
      Attribute_Definition:
        Unique identifier for each arc in the GIS coverage. Functions as a foreign key to link to the arc attribute table (NHD.aat)
      Attribute_Definition_Source: Arc/Info generated number
      Attribute_Domain_Values:
        Unrepresentable_Domain:
          Sequential unique whole numbers that are automatically generated.
    Attribute:
      Attribute_Label: F-Meas
      Attribute_Definition: Beginning coordinate of this section along the route, in feet.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: T-Meas
      Attribute_Definition: Ending coordinate of this section along the route, in feet.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: F-Pos
      Attribute_Definition:
        Beginning coordinate of this section along the arc, in percentage.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: T-Pos
      Attribute_Definition: Ending coordinate of this section along the arc, in percentage.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
  Detailed_Description:
    Entity_Type:
      Entity_Type_Label: NHDLLIDCrosswalk.mdb, CrossRef table
      Entity_Type_Definition:
        NHD/LLID Data Conversion application - NHD/LLID crossreference table
      Entity_Type_Definition_Source: StreamNet project (<http://www.streamnet.org>)
    Attribute:
      Attribute_Label: huc
      Attribute_Definition:
        4th Code Hydrologic Unit Code which identifies the subbasin that the stream segment occurs in.
      Attribute_Definition_Source: US Geological Survey (<http://www.usgs.gov>)
    Attribute:
      Attribute_Label: reach
      Attribute_Definition: NHD Reach code which identifies the stream reach.
      Attribute_Definition_Source: National Hydrography Dataset (<http://nhd.usgs.gov>)
    Attribute:
      Attribute_Label: begrch
      Attribute_Definition:
        Beginning coordinate of this stream section along the NHD reach-based route, in percentage.
      Attribute_Definition_Source: National Hydrography Dataset (<http://nhd.usgs.gov>)
    Attribute:
      Attribute_Label: endrch
      Attribute_Definition:
        Ending coordinate of this stream section along the NHD reach-based route, in percentage.
      Attribute_Definition_Source: National Hydrography Dataset (<http://nhd.usgs.gov>)
    Attribute:
      Attribute_Label: llid
      Attribute_Definition:
        Longitude-latitude identifier which uniquely identifies each stream.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: begft
      Attribute_Definition:
        Beginning coordinate of this stream section along the LLID-based route, in feet.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: endft
      Attribute_Definition:
        Ending coordinate of this stream section along the LLID-based route, in feet.
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
  Detailed_Description:
    Entity_Type:
      Entity_Type_Label: NHDLLIDCrosswalk.mdb, CrossRefQA table
      Entity_Type_Definition:
        NHD/LLID Data Conversion application - LLID rebuild quality assurance evaluation results
      Entity_Type_Definition_Source: StreamNet project (<http://www.streamnet.org>)
    Attribute:
      Attribute_Label: HUC
      Attribute_Definition:
        The 4th Code Hydrologic Unit Code for the subbasin that the LLID route falls in.
      Attribute_Definition_Source: US Geological Survey (<http://www.usgs.gov>)
    Attribute:
      Attribute_Label: LLID
      Attribute_Definition:
        The Longitude Latitude Identifier which uniquely identifies the stream
      Attribute_Definition_Source: PNW Reach File (<http://www.streamnet.org/pnwr/pnwrhome.html>)
    Attribute:
      Attribute_Label: NHD_length
      Attribute_Definition:
        The length, in feet, of this LLID route after it was rebuilt onto the NHD linework.
      Attribute_Definition_Source: StreamNet (<http://www.streamnet.org>)
    Attribute:
      Attribute_Label: PNW_length
      Attribute_Definition:
        The length, in feet, of the original LLID route from the PNW Reach File.
      Attribute_Definition_Source: StreamNet (<http://www.streamnet.org>)
    Attribute:
      Attribute_Label: Difference
      Attribute_Definition:
        The difference between the NHD_length and the PNW_length fields, in feet. This represents the degree of accuracy of the rebuild, with the desirable result being the smallest possible difference.
      Attribute_Definition_Source: StreamNet Project (<http://www.streamnet.org>)
    Attribute:
      Attribute_Label: Comments
      Attribute_Definition:
        Whenever an LLID route could not be rebuilt on the NHD with a difference of less then 100 feet, it was examined and the reason for the discrepancy is entered in the comments field.
      Attribute_Definition_Source: StreamNet Project, <http://www.streamnet.org>

Distribution_Information:
  Distributor:
    Contact_Information:
      Contact_Person_Primary:
        Contact_Person: StreamNet GIS Specialist
        Contact_Organization: StreamNet Project, Pacific States Marine Fisheries Commission
      Contact_Position: GIS Specialist
      Contact_Address:
        Address_Type: mailing and physical address
        Address: 205 SE Spokane St, Suite 100
        City: Portland
        State_or_Province: OR
        Postal_Code: 97202
        Country: USA
      Contact_Voice_Telephone: (503) 595-3200
      Contact_Facsimile_Telephone: (503) 595-3232
      Contact_Electronic_Mail_Address: StreamNetGIS@psmfc.org
      Hours_of_Service: 8:30 AM to 5:30 PM
  Resource_Description: Arc/Info export files, Microsoft Access database
  Distribution_Liability:
    This product was prepared as a cooperative effort of the U.S. Government, state governments, the region's tribes and tribal fish organizations, and the Pacific States Marine Fisheries Commission. None of these organizations, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe on privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the participating organizations. The views and opinions of authors expressed herein do not necessarily reflect those of the participating agencies.
  Standard_Order_Process:
    Digital_Form:
      Digital_Transfer_Information:
        Format_Version_Number: 1
        Format_Specification:
          GIS Files - Arc/Info export (.e00) files. Data Conversion Application - MS Access database
        File_Decompression_Technique:
          tarred and zipped. See <http://nhd.usgs.gov/tools.html#compression> for free decompression tools and instructions.
        Transfer_Size: 137.867
    Fees: none
    Ordering_Instructions: free download from http://www.streamnet.org/nhdllid
    Turnaround: not applicable
  Custom_Order_Process:
    If unable to download files via internet (http://www.streamnet.org/nhdllid), contact the StreamNet GIS Specialist (503) 595-3200 to receive these products through alternate means.
  Technical_Prerequisites:
    Software Requirements: To run this application, you will either need to have a copy of Access 97 or Access 2000 installed on your computer. The application is provided for download in both formats and runs in the same way in both versions of the database software. You will also need to have approximately 24 MB of free disk space to store the database and help documentation once it is uncompressed.

    The application works entirely with tabular data and does not require GIS software to run. The application does, however, refer to routing systems which are built on GIS hydrography layers and it converts event data in a format that is meant to be tied to these route systems. Its full value is therefore derived from the application of these event tables to hydrography layers with GIS software. The cross reference table that this application uses was derived from NHD hydrography layers on which the LLID route system was rebuilt. These GIS files, which include both the NHD and LLID routing systems, are available for download in a zipped arc export format from http://www.streamnet.org/nhdllid

    User Requirements: A user of this application should be familiar with what the LLID and NHD routing systems are and how event data are tied to these systems. The user should also have a basic understanding of relational databases and a basic knowledge of how to use MS Access software. It is recommended that users read at least the Overview and the 'Accuracy, Cautions, and Limitations' section under the Application Help part of this document before using the application.

  Available_Time_Period:
    Time_Period_Information:
      Single_Date/Time:
        Calendar_Date: November, 2001

Metadata_Reference_Information:
  Metadata_Date: November, 2001
  Metadata_Contact:
    Contact_Information:
      Contact_Person_Primary:
        Contact_Person: StreamNet GIS Specialist
        Contact_Organization: StreamNet Project, Pacific States Marine Fisheries Commission
      Contact_Position: GIS Specialist
      Contact_Address:
        Address_Type: mailing and physical address
        Address: 205 SE Spokane st, suite 100
        City: Portland
        State_or_Province: OR
        Postal_Code: 97202
        Country: USA
      Contact_Voice_Telephone: (503) 650-5400
      Contact_Facsimile_Telephone: (503) 650-5426
      Contact_Electronic_Mail_Address: StreamNetGIS@psmfc.org
      Hours_of_Service: 8:30 am to 5:30 pm
  Metadata_Standard_Name: FGDC Content Standards for Digital Geospatial Metadata
  Metadata_Standard_Version: FGDC-STD-001-1998
  Metadata_Time_Convention: local time
  Metadata_Access_Constraints: none
  Metadata_Use_Constraints: none
  Metadata_Extensions:
    Online_Linkage: <http://www.esri.com/metadata/esriprof80.html>
    Profile_Name: ESRI Metadata Profile

Generated by `mp` version 2.7.3 on Mon Sep 24 17:24:23 2001