U.S. Geological Survey --------------------------------------------------------------------------- Metadata for RF3MJR Table of Contents Identification_Information Abstract Purpose Supplemental Information Data_Quality_Information Spatial_Data_Organization_Information Entity_and_Attribute_Information Detailed Description Overview Distribution_Information Metadata_Reference_Section --------------------------------------------------------------------------- Identification_Information Citation_Information Originator: McFadden, Keith W., and Burgoon, Diane C. Publication_Date: 1996 Title: U.S. EPA River Reach File, Version 3, Major Streams of Georgia Edition: 1.0 1.1 Datum change from 1927 to 1983 (North American Datum of 1983) Data Re-projected using North American Datum (NAD83) - September 2000 Series_Information Series_Name: Digital Data Series Publication_Information Publication_Place: Atlanta, GA Publisher: U.S. Geological Survey Online_Linkage: http://csat.er.usgs.gov/statewide/layers/rf3mjr.html Scale_Denominator: 100000 Description Abstract This data set is an extraction from the EPA River Reach File 3 (RF3). It is based on the attribute RF3ORGFLG when the value if this is equal to 1, which indicates that the source for attribute information was from RF1. Therefore, this data set is equivalent to RF1 in its reach representation, but contains the more accurate geometry of RF3. This data was extracted from each RF3 basin and appended using ARC/INFO to form a state-wide coverage. In a few cases, additional reaches were manually added from RF3 in order to fill in missing linework. This was usually due to missing attribute information in RF3. For a general description of RF3, see the EPA web site at: http://www.epa.gov/OWOW/NPS/rf/rfindex.html For a more detail document describing RF3 and its attributes, contact the EPA STORET User Assistance Group at 800-424-9067, or see RF3 documentation under the References section. Purpose This dataset was compiled to provide a geometrically accurate intermediate level stream data set. While RF3 may be somewhat less accurate than 1:100000 dlg, for intermediate scale maps that do not require the detail of a full hydro coverage, but need a better representation than 1:250k or 1:2m data sets, this set is a suitable alternative. Supplemental_Information Procedures_Used Reselected linework using the ARC RESELECT command and the query RF3ORGFLG = 1. In addition, in order to restrict linework to the state of Georgia and still retain the topological connectivity of RF3, the lines were reselected in Arcplot using the OVERLAP option with the Ga. county100 data layer as the overlap coverage. This method selected all arcs that have any portion that fall within the state boundary. Unfortunately, some arcs along boundary streams do fall completely outside of the state and therefore were not included in this selection, causing a discontinuity in the stream network. This problem may be fixed in future versions. Revisions 1.0 Reviews_Applied Colleague review May 1, 1996 by Jack Alhadeff and Jonathan Musser. Digital data was reviewed with respect to positional accuracy, contextual accuracy, attribute accuracy, topological consistency, and metadata content Fixed tics. Done. Remove annotation. Done. Add Datum. Done Move EPA RF3 documentation to Notes. Done. Approved by Tim Hale, Georgia District Chief, May 3, 1996. Related_Spatial_and_Tabular_Data_Sets All related data joined to .aat Other_References_Cited RF3 Working Group, 1993, Technical Documentation, U. S. Environmental Protection Agency, Office for Water, Washington DC Notes * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 01/22/93 * U.S. Environmental Protection Agency * Office of Information Resources Management * Geographic Resources Information and Data System * * * * * G R I D S * * * * * R E T R I E V A L * * + + + + + + + + + + + + + + + + + + + * * *The data that has been retrieved is located on NL (Nonlabled), *6250 bpi (bits/inch) 9-track tapes. * * + + + + + + + + + + + + + + + + + + + + + + + + + + * GRIDS: Reach File 3 README File 02/25/91 * *The following information is intended as a brief overview of the *Reach File, Version 3 (RF3), data. This product in presently being *evaluated and is in draft form and should be considered in that light. *Included in this readme file is a draft technical memorandum developed *by the Environmental Monitoring Systems Lab (EMSL) in Las Vegas which *contains valuable information on the use of this data. * *When importing RF3 data into ARC/Info the data will be partitioned *into four files per cataloging unit. Each file name consists of the *eight digit cataloging unit number and a three character extension. *Because file names cannot begin with a number, the first digit of the *cataloging unit number has been coded with a letter, either A or B. *The letter A represents 0 and B represents the number 1. * *For example: A1080204 TIC represents the cataloging unit 01080204 *and it is a TIC file. * *When you import this data into ARC/Info you get TIC, BND, and AAT *files as well as a related DS2 file that contains RF3 attributes. * *For example, for the cataloging unit 01080204 you will end up with *the following files: * * A1080204.TIC * A1080204.AAT * A1080204.BND * A1080204.DS2 * A1080204.NAR * *The following items will be contained in the AAT file: * *COL ITEM NAME WDTH OPUT TYP N.DEC * 29 CU 8 8 I - * 37 SEG 4 4 I - * 41 MILE 5 5 N 2 * 46 UP 4 5 B 0 * 50 DOWN 4 5 B 0 * ** REDEFINED ITEMS ** * 29 RF3RCHID 17 17 C - * * *The following items will be contained in the DS2 file: * * * REACH FILE VERSION 3 (RF3) * STRUCTURE FILE FORMAT * (02/27/91 - INCLUSION OF SPECIAL STATE CODE) * * *VAR NAME BASIC TYPE LENGTH START/STOP DESCRIPTION *______________________________________________________________________ * *CATUNIT AS LONG INTEGER 8 1 - 8 CATALOGING UNIT (CU) *SEGM AS INTEGER 4 9 - 12 SEGMENT NUMBER (SEG) *MI AS SINGLE 5.2 13 - 17 MILE POINT (MI) *UPMI AS SINGLE 5.2 18 - 22 UPSTREAM MILE PT. *SEQNO AS DOUBLE 11.6 23 - 33 HYDRO SEQUENCE NO. *RFLAG AS STRING * 1 1 34 - 34 REACH FLAG (0,1) *OWFLAG AS STRING * 1 1 35 - 35 OPEN WATER FLAG(0,1) *TFLAG AS STRING * 1 1 36 - 36 TERMINAL FLAG *(0,1) *SFLAG AS STRING * 1 1 37 - 37 START FLAG (0,1) *RCHTYPE AS STRING * 1 1 38 - 38 REACH TYPE CODE *LEV AS INTEGER 2 39 - 40 STREAM LEVEL *JUNC AS INTEGER 2 41 - 42 LEVEL OF * DOWNSTREAM REACH *DIVERGENCE AS INTEGER 1 43 - 43 DIVERGENCE CODE *STARTCU AS INTEGER 8 44 - 51 START CU *STRTSG AS DOUBLE 4 52 - 55 START SEG *STOPCU AS INTEGER 8 56 - 63 STOP CU *STOPSG AS DOUBLE 4 64 - 67 STOP SEG *USDIR AS STRING * 1 1 68 - 68 UPSTREAM DIRECTION *TERMID AS LONG INTEGER 5 69 - 73 TERMINAL STREAM ID *TRMBLV AS INTEGER 1 74 - 74 TERMINAL BASE LEVEL *PNAME AS STRING * 30 30 75 - 104 PRIMARY NAME *PNMCD AS DOUBLE 11 105 - 115 PRIMARY NAME CODE *CNAME AS STRING * 30 30 116 - 145 COMPLEMENT NAME *CNMCD AS DOUBLE 11 146 - 156 COMPLEMENT NAME CODE *OWNAME AS STRING * 30 30 157 - 186 OPEN WATER NAME *OWNMCD AS DOUBLE 11 187 - 197 OPEN WATER NAME CODE *DSCU AS LONG INTEGER 8 198 - 205 DOWNSTREAM CU *DSSEG AS INTEGER 4 206 - 209 DOWNSTREAM SEG *DSMI AS SINGLE 5.2 210 - 214 DOWNSTREAM MI *CCU AS LONG INTEGER 8 215 - 222 COMPLEMENT CU *CSEG AS INTEGER 4 223 - 226 COMPLEMENT SEG *CMILE AS SINGLE 5.2 227 - 231 COMPLEMENT MI *CDIR AS STRING * 1 1 232 - 232 COMPLEMENT DIRECTION *ULCU AS LONG INTEGER 8 233 - 240 UPSTREAM LEFT CU *ULSEG AS INTEGER 4 241 - 244 UPSTREAM LEFT SEG *ULMI AS SINGLE 5.2 245 - 249 UPSTREAM LEFT MI *URCU AS LONG INTEGER 8 250 - 257 UPSTREAM RIGHT CU *URSEG AS INTEGER 4 258 - 261 UPSTREAM RIGHT SEG *URMI AS SINGLE 5.2 262 - 266 UPSTREAM RIGHT MI *SEGL AS SINGLE 6.2 267 - 272 REACH LENGTH (MILES) *RFORGFLAG AS STRING * 1 1 273 - 273 RF ORGIN FLAG(1,2,3) *ALTPNMCD AS LONG INTEGER 8 274 - 281 ALT.PRIMARY NAME CD *ALTOWNMC AS LONG INTEGER 8 282 - 289 ALT.OW NAME CODE *DLAT AS SINGLE 8.4 290 - 297 DOWNSTREAM LATITUDE *DLONG AS SINGLE 8.4 298 - 305 DOWNSTREAM LONGITUDE *ULAT AS SINGLE 8.4 306 - 313 UPSTREAM LATITUDE *ULONG AS SINGLE 8.4 314 - 321 UPSTREAM LONGITUDE *MINLAT AS SINGLE 8.4 322 - 329 MINIMUM LATITUDE *MINLONG AS SINGLE 8.4 330 - 337 MINIMUM LONGITUDE *MAXLAT AS SINGLE 8.4 338 - 345 MAXIMUM LATITUDE *MAXLONG AS SINGLE 8.4 346 - 353 MAXIMUM LONGITUDE *NDLGREC AS INTEGER 4 354 - 357 NO. OF DLG RECORDS *LL1KEY1 AS DOUBLE 10 358 - 367 STARTING DLG LL KEY1 *LL2KEY1 AS DOUBLE 10 368 - 377 ENDING DLG LL KEY1 *LL1KEY2 AS DOUBLE 10 378 - 387 STARTING DLG LL KEY2 *LL2KEY2 AS DOUBLE 10 388 - 497 ENDING DLG LL KEY2 *LL1KEY3 AS DOUBLE 10 398 - 407 STARTING DLG LL KEY3 *LL2KEY3 AS DOUBLE 10 408 - 417 ENDING DLG LL KEY3 *LL1KEY4 AS DOUBLE 10 418 - 427 STARTING DLG LL KEY4 *LL2KEY4 AS DOUBLE 10 428 - 437 ENDING DLG LL KEY4 *LL1KEY5 AS DOUBLE 10 438 - 447 STARTING DLG LL KEY5 *LL2KEY5 AS DOUBLE 10 448 - 457 ENDING DLG LL KEY5 *LL1KEY6 AS DOUBLE 10 458 - 467 STARTING DLG LL KEY6 *LL2KEY6 AS DOUBLE 10 468 - 477 ENDING DLG LL KEY6 *LL1KEY7 AS DOUBLE 10 478 - 487 STARTING DLG LL KEY7 *LL2KEY7 AS DOUBLE 10 488 - 597 ENDING DLG LL KEY7 *LL1KEY8 AS DOUBLE 10 498 - 507 STARTING DLG LL KEY8 *LL2KEY8 AS DOUBLE 10 508 - 517 ENDING DLG LL KEY8 *LL1KEY9 AS DOUBLE 10 518 - 527 STARTING DLG LL KEY9 *LL2KEY9 AS DOUBLE 10 528 - 537 ENDING DLG LL KEY9 *LL1KEY10 AS DOUBLE 10 538 - 547 START DLG LL KEY 10 *LL2KEY10 AS DOUBLE 10 548 - 557 ENDING DLG LLKEY10 *LN1AT2 AS INTEGER 4 558 - 561 DLG LINE ATTR. 1 *LN2AT2 AS INTEGER 4 562 - 565 DLG LINE ATTR. 2 *AREA1 AS INTEGER 4 566 - 569 DLG AREA ID 1 *AREA2 AS INTEGER 4 570 - 573 DLG AREA ID 2 *AR1AT2 AS INTEGER 4 574 - 577 DLG AREA ATTRIBUTE *AR1AT4 AS INTEGER 4 578 - 581 DLG AREA ATTRIBUTE *AR2AT2 AS INTEGER 4 582 - 585 DLG AREA ATTRIBUTE *AR2AT4 AS INTEGER 4 586 - 589 DLG AREA ATTRIBUTE *UPDATE1 AS STRING * 6 6 590 - 595 UPDATE DATE #1 * (MMDDYY) *UPDTCD1 AS STRING * 8 8 596 - 603 UPDATE TYPE CODE#1 *UPDTSRC1 AS STRING * 8 8 604 - 611 UPDATE SOURCE #1 *UPDATE2 AS STRING * 6 6 612 - 617 UPDATE DATE #2 * (MMDDYY) *UPDTCD2 AS STRING * 8 8 618 - 625 UPDATE TYPE CODE#2 *UPDTSRC2 AS STRING * 8 8 626 - 633 UPDATE SOURCE #2 *UPDATE3 AS STRING * 6 6 634 - 639 UPDATE DATE #3 * (MMDDYY) *UPDTCD3 AS STRING * 8 8 640 - 647 UPDATE TYPE CODE#3 *UPDTSRC3 AS STRING * 8 8 648 - 655 UPDATE SOURCE #3 *DIVCU AS LONG INTEGER 8 656 - 663 DIVERGENT CU *DIVSEG AS INTEGER 4 664 - 667 DIVERGENT SEG *DIVMILE AS SINGLE 5.2 668 - 672 DIVERGENT MI *DLGID AS INTEGER 6 673 - 678 DLG NUMBER * (SPECIAL USE FOR INTERNAL STATE CODES) *FILLER AS STRING * 7 7 678 - 685 FILLER: FUTURE USE * *Due to the fact that the Office of Water is still developing *RF3, these data descriptions are brief. As they are revised this *README file will be updated accordingly. * * * * * *GIS Technical Memorandum *RF3-ARC/INFO Bridge * * * *by * *Richard A. Dulaney *Lockheed Engineering and Sciences Company *1050 E. Flamingo Rd., Suite 126 *Las Vegas, Nevada 89119 * *and * *Mason J. Hewitt III *U. S. Environmental Protection Agency *Environmental Monitoring Systems Laboratory *Las Vegas, Nevada 89193-3478 * * * * * * * * * *EPA Project Officer *Mason J. Hewitt III *Advanced Monitoring Systems Division *Environmental Monitoring Systems Laboratory *Las Vegas, Nevada 89193-3478 * * * * * * * *ENVIRONMENTAL MONITORING SYSTEMS LABORATORY *OFFICE OF RESEARCH AND DEVELOPMENT *U.S. ENVIRONMENTAL PROTECTION AGENCY *P.O. BOX 93478 *LAS VEGAS, NEVADA 89193-3478 * * *NOTICE * * *This document is a preliminary draft. It has not been formally *released by the U.S. Environmental Protection Agency and should not *at this stage be construed to represent Agency policy. It is being *circulated for comments on its technical merit and policy *implications. *Contents * *INTRODUCTION . . . . . . . . . . . . . . . . . . . . 1 * RF3-ARC/INFO BRIDGE - TECHNICAL WORKING * GROUP. . . . . . . . . . . . . . . . . . . 1 * *REACH FILE SYSTEM. . . . . . . . . . . . . . . . . . 1 * RF3 DEVELOPMENT . . . . . . . . . . . . . . . . 2 * Building The RF3 Network. . . . . . . . . 3 * Basic RF3 Attributes . . . . . . . . . . . 4 * *CONVERSION OF RF3 DATA TO ARC/INFO FORMAT. . . . . . 5 * CREATING EXPORT FILE. . . . . . . . . . . . . . 5 * CREATION OF ARC/INFO COVERAGE . . . . . . . . . 5 * Running Renode . . . . . . . . . . . . . . 7 * *NETWORK CONSIDERATIONS . . . . . . . . . . . . . . . 7 * *RF3NODE.AML. . . . . . . . . . . . . . . . . . . . . 7 * DYNAMIC SEGMENTATION. . . . . . . . . . . . . . 8 * NETWORK ANALYSIS USING ATTRIBUTES . . . . . . . 8 * *UPDATING RF3 DATA WITH ARC/INFO. . . . . . . . . . . 9 * LEVEL 1 UPDATES : NON-STRUCTURAL CHANGES. . . . 9 * Changing Names . . . . . . . . . . . . . . 9 * Changing Name Codes (PNMCD, OWNMCD, * CNMCD). . . . . . . . . . . . . . . . 10 * Changing Reach Types . . . . . . . . . . . 10 * LEVEL 2 UPDATES - MINOR STRUCTURAL CHANGES. . . 10 * Splitting a Reach (Breaking a Reach Into * two Reaches). . . . . . . . . . . . . 11 * Deleting a Reach . . . . . . . . . . . . . 12 * Adding a Reach . . . . . . . . . . . . . . 12 * Connecting Existing Reaches. . . . . . . . 13 * Breaking Existing Connections. . . . . . . 13 * Combining Update Operations. . . . . . . . 13 * RETURNING UPDATED RF3 DATA. . . . . . . . . . . 13 * *SUMMARY AND CONCLUSION . . . . . . . . . . . . . . . 14 * *ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . 14 * *APPENDIX A: INFO DATAFILE DEFINITIONS . . . . . . . 15 * *APPENDIX B: RF3NODE.AML . . . . . . . . . . . . . . 18 * *APPENDIX C: UPDATE AML DESCRIPTION. . . . . . . . . 20 * * INTRODUCTION * * *The utility of the USGS 1:100,000 scale digital line *graph (DLG) hydrography data for GIS data base *development is well known in the EPA GIS community. *Also well known is the large amount of analyst and CPU *time that are required to process the raw data into a *usable ARC/INFO format, including the dreaded "edge- *matching". Another drawback to the DLG hydrography data *is the lack of hydrologic flow or network logic. The *direction of each individual arc in the hydrography data *set is arbitrary and there are no implicit attributes *concerning hydrologic connectivities, which makes *network analysis difficult, if not impossible. There is *currently an EPA funded, nationally available data set *under production that will provide Agency ARC/INFO users *with 1:100,000 scale DLG hydrography data in a *processed, edgematched, hydrologically networked format. *These data are being produced by the EPA Office of Water *(OW) and are referred to as the Reach File 3 (RF3). * * *RF3-ARC/INFO BRIDGE - TECHNICAL WORKING GROUP * *In order to guide the RF3-ARC/INFO data sharing efforts, *a Technical Working Group was formed. This group *consists of GIS analysts from EMSL-LV, Region IV, *Headquarters/OIRM, representatives of OW and RF3 *contractors. This group is defining the RF3-ARC/INFO *"bridge" as well as the pertinent issues related to this *data sharing effort. This document is part of a package *which contains documentation on RF3, the RF3-ARC/INFO *bridge, RF3 updating processes and standards and network *considerations. Included in the package are AMLs to *guide the updating process and fortran programs designed *to translate updated ARC RF3 coverages into ASCII files *for return to OW. * * * *REACH FILE SYSTEM * *The following discussion provides general background *information on the EPA Reach File system. A large *portion of this discussion is modified from existing *documents on the Reach File System which were written by *Timothy R. Bondelid and Sue A. Hanson of Horizon Systems *Corporation. *In 1982 the EPA implemented the first Reach File (RF1) *which was a national hydrographic database of surface *water features. The features were based on 1:500,000 *scale NOAA aeronautical charts. Approximately 68,000 *records representing 650,000 miles of streams and *shorelines were present in RF1. RF1 was developed and *implemented on the IBM mainframe located at the EPA *National Computing Center (NCC) in Research Triangle *Park, North Carolina. *Within the Reach File, reaches were defined as specific *stretches of streams/shorelines usually extending from *one stream junction to another. Reaches were each given *a unique reach number. This number was the *concatenation of three separate fields called CU *(cataloging unit) SEG (segment) and MI (milepoint). The *RF1 Reach numbering, indexing, routing, and retrieval *software capabilities have proven to be very effective *for a variety of EPA applications and many state and *local offices have adopted the EPA reach numbering *system. The 1988 Reach File, called RF2, doubled the *size of the original File and retained all of the *attribute data element specifications of the RF1. The *newest Reach File currently under development, called *RF3, will retain all of the essential capabilities of *the previous Reach Files while having greatly increased *resolution and feature density along with some data *element or attribute modifications. * *RF3 DEVELOPMENT * *The RF3 file is based upon the USGS 1:100,000 scale *hydrography DLGs. The data were acquired by EPA-OW on *240 tapes which contained 54,000 files. The first *processing performed was to convert from UTM to *latitude/longitude. This conversion was accomplished *preserving the nearest 1/10,000 of a degree, which is *well within the stated resolution of these data. The *data were then collapsed into line records (trace files) *without nodes, and the line records were concatenated. *There were then 4 million line elements and 93 million *latitude/longitude coordinates. Each line, or trace, *retained a key record that can be directed back to the *original DLG data tape if necessary. * *Traces were then assigned to USGS Cataloging Units (CU). *Traces that crossed CU boundaries were assigned to both *CUs. A CU is a geographic area representing all or part *of a surface drainage basin, a combination of basins, or *a distinct hydrologic feature. There are approximately *2150 CUs in the Nation. The USGS CU boundaries were *developed at a scale of 1:2,000,000 (see Figure 1). *They represent the "smallest element in the hierarchy of *hydrologic units" (U.S. Geological Survey, 1982). CUs *are not accurately correlated to topography and do not *always correspond directly to true watersheds as they *are more administrative in function. * *Horizon Systems Corporation, the prime contractor to *EPA-OW, developed a software tool called PC Reach File *(PCRF). PCRF is the program that performs the RF3 file *construction. Production development of RF3 proceeds in *discrete units corresponding to the CU. Because of the *ability to *run many of the steps in batch, a given analyst running *PCRF may be working on as many as 25 CUs at a time. * *Building The RF3 Network. * *In order to update the RF2 file to RF3, the RF2 data, *the DLG data and the CU boundaries are all downloaded to *a PC running PCRF. There, an analyst identifies a *starting point for the automated construction of the *network topology. The starting point designated was the *furthest reach downstream and the network was built up *in the reverse direction of flow. Between reaches there *may be gaps, usually along map sheet boundaries. *Therefore, a search tolerance of 3/10,0000 of a degree *or approximately 100 feet was specified in order to *"bridge" these gaps. Edgematching takes place by the *addition of segments in these gaps. Once this has been *completed, the analyst will "replay" and supervise the *network that was created. There may be some network *discrepancies that are not able to be resolved by PCRF *and that may cause a break in the processing. These are *resolved by the analyst. * *Once the network is built, segment and milepoint numbers *must be assigned along the network. The analyst begins *this session by viewing both the RF2 and the processed *DLG data together, color coded for differentiation. The *analyst then will "tag" the RF2 segment endpoints to the *corresponding DLG points. PCRF will then work upstream *from the downstream end of the segment and allocate *milepoints. The RF2 milepoints are retained in RF3, *despite the actual length of the new segments. In other *words, the milepoint figures will not reflect the true *length of the RF3 reaches. For example, if an RF2 *segment had ten reaches (differentiated by milepoints), *the more detailed RF3 segment will also have ten *milepoints, but the trace of these reaches will be *entirely different. New milepoints are not being *created because this would disrupt databases that index *to the earlier Reach Files. The actual length of *reaches as derived from the DLG trace is recorded in a *field called SEGL. New segments and reaches are not an *uncommon outcome of this conversion to the more highly *resolved hydrography network. In this step, PCRF will *assign new SEG/MI numbers to traces that appear in the *1:100,000 DLG that did not exist in the previous *1:500,000 Trace File. * *Production of the RF3 data is taking place by state and *EPA Region. The status of RF3 CUs available for access *by GIS users is as follows (May 17, 1991): * * TOTAL TOTAL CAT PERCENT TOTAL BYTES * STATE COMPLETE UNITS COMPLETE ARC EXPORT * ----- ----- -------- -------- ----------- * AK 0 18 0 0 * AL 47 50 98 281,951,974 * AR 5 56 9 21,477,352 * AZ 5 84 6 18,258,536 * CA 0 146 0 0 * CO 22 93 23 62,938,271 * CT 8 12 67 28,051,844 * DC 1 1 100 3,943,682 * DE 1 7 14 3,160,521 * FL 41 52 79 250,099,382 * GA 51 52 98 281,190,090 * HI 0 9 0 0 * IA 39 56 70 134,177,180 * ID 0 84 0 0 * IL 47 51 92 192,358,398 * IN 35 36 97 88,958,406 * KS 27 89 31 114,792,458 * KY 42 42 100 152,716,286 * LA 12 54 22 53,232,101 * MA 18 19 95 70,872,219 * MD 6 20 35 27,661,217 * ME 21 21 100 96,962,361 * MI 52 61 85 170,538,889 * MN 72 85 85 272,358,038 * MO 30 65 46 135,342,811 * MS 45 52 87 255,977,494 * MT 11 100 11 59,497,384 * NC 48 52 92 258,217,382 * ND 19 49 39 85,719,764 * NE 19 68 28 58,791,996 * NH 12 12 100 50,365,581 * NJ 2 13 15 10,112,655 * NM 14 81 17 53,601,100 * NV 5 69 7 25,428,063 * NY 14 51 27 52,494,561 * OH 38 44 86 142,976,207 * OK 6 64 9 27,174,908 * OR 0 91 0 0 * PA 36 54 67 122,930,843 * RI 3 4 75 9,136,872 * SC 32 33 97 167,287,130 * SD 27 54 50 146,707,897 * TN 52 56 93 228,062,972 * TX 67 204 33 153,826,391 * UT 34 66 52 110,079,375 * VA 28 46 61 125,536,314 * VT 16 16 100 30,880,343 * WA 0 69 0 0 * WI 48 51 94 221,667,357 * WV 23 30 77 73,429,529 * WY 13 82 16 32,007,698 * * *The completed RF3 file is maintained in a packed binary format on *the NCC IBM. Two major files make up the backbone of the RF3; a *trace file which contains the latitude/longitude coordinates, and *a structure file which contains the attributes for each reach. * *Basic RF3 Attributes * *The primary index in the Reach File is the Reach Number, consisting *of three parts: * * CU - the 8 digit Hydrologic Cataloging Unit; * * SEG - the 4-digit Segment Number, and; * * MI - the milepoint along the CU-SEG as measured from the * downstream end. * *Thus, each reach has a unique CU-SEG/MI. These reach numbers are *also used as an index system for monitoring stations, discharge *locations, etc. Assignment to the reach network places these points *in proper hydrologic position. * *The network connectivity is established in RF3 by attributes that *store the reach numbers for upstream left, upstream right, *downstream, and complement reaches. Physical connectivity of the *hydrologic features are not required in the RF3 system for *hydrologic modelling. Instead, the RF3 system uses attributes for *this purpose. * * * *CONVERSION OF RF3 DATA TO ARC/INFO FORMAT * * *CREATING EXPORT FILE * *The completed RF3 data exist in a packed binary format on the NCC *IBM 3090. In order to allow GIS users access to these data, a *conversion program was written. This program was developed by Dr. *Jim Bricker of EPA Region IV. It creates an ARC/INFO non-compressed *(ASCII) export format file from the EBCDIC RF3 data. The RF3 *conversion program can be accessed via the EPA Geographic Resources *Information & Data System (GRIDS). The user simply logs onto GRIDS *on the NCC IBM, selects the option to create an RF3 data set, and *enters one or more USGS cataloging units. The RF3 data are *presently being provided by individual CU, but an option to extract *an aggregate of CUs is being looked into. The export file(s) can *then be sent to the user on a 9-track tape, or it can be put on the *IBM disk pack for downloading to the users ARC/INFO platform. A *user can also run the conversion program from the NCC IBM 3090 Reach *File Management System (RFMS). RFMS has the capability to download *the resulting export file using RFMS routines. * * *CREATION OF ARC/INFO COVERAGE * *The export file created by Dr. Brickers program is imported in *ARC/INFO, resulting in a line coverage and two important INFO data *files. The first, the .AAT file, contains the reach number *and two impedance items used in ARC Network. In addition, a *.DS1 file is created which contains the reach number and 426 *bytes of attributes from the original RF3 data. To link the two *files, the user simply relates on the reach number which is stored *in the redefined item RF3RCHID. The user may choose to run ARC *JOINITEM to associate the entire suite of RF3 attributes with the *coverage attribute file (.AAT). However, this will result *in a coverage containing over 400 bytes of attribute data. Whether *the user chooses to run JOINITEM or not, it is advisable to rename *the .DS1 file to another name, such as .DS1. This *will ensure that any additional processing steps, like project, will *not duplicate the large .DS1 file. A full description of the *attribute fields contained in these data files can be found in *Appendix A. * *The reach coverage is provided by GRIDS in the standard Albers conic *equal-area projection with the following parameters: * *Units = Meters *1st Standard Parallel = 29.5 *2nd Standard Parallel = 45.5 *Central Meridian = -96.0 *Latitude of Origin = 23.0 *False Easting = 0 *False Northing = 0 * *Because the imported reach coverage already contains an arc *attribute table, there is no need to create one with the BUILD, or *CLEAN commands. As a matter of fact, it is recommended that the *coverage NOT be CLEANed for the reasons detailed below. CLEAN re- *orders the arc list, weeds coordinates (depending on tolerances), *and creates new arcs and new arc intersections. All of these may *be undesirable if the user is updating the RF3 file for OW. * *Reaches in the RF3 data are created by stringing together the *coordinates found in the original DLG data. This is obviously the *same method ARC/INFO uses in the DLGARC procedure. Where the two *methods differ is in the definition of the beginning and ending *points of the arc or reach, especially along map borders or *neatlines. Arcs created from DLGs with DLGARC will end artificially *at neat lines and a node will be placed at this end. When *edgematching takes place, these nodes are usually connected together *creating a continuous set of arcs which share a single node near the *map boundary. The arcs (reaches) imported from the RF3 export file *will usually not have a node at the neatline. They are instead *defined as a single stretch of river, with nodes only at the *junction point with other reaches. Segments are added within the *RF3 derived coverages to connect any dangling reaches, but no nodes *are created for these segments (i.e. the added segments are not true *arcs). The coordinates for these segments are instead added to the *coordinate string defining the entire reach (see Figure 2). At neat *lines, the RF3 derived coverage could very possibly have arcs which *loop or cross, depending on where the segment was added and how the *dangling DLG arcs were configured (see Figure 3). CLEANing this *coverage would create nodes where the arcs crossed as well as create *new arcs defined by these nodes. This addition of new records may *hamper the integration of the updated file back into the master *reach file (see "Updating" below). * * * * *Running Renode * *Node numbers and arc/node topology are required by ARC NETWORK which *uses these to assign arcs to a given network model. However, the *imported reach coverage does not have node numbers, and arc/node *topology is not present. Therefore, the command RENODE should be *run to build arc/node topology and to assign node numbers. * * * *NETWORK CONSIDERATIONS * *RF3 data in ARC/INFO format should prove invaluable to those users *wishing to perform hydrologic network analyses with 1:100,000 scale *DLG data. As mentioned above, the reach file coverage arcs are *stored with the from-to direction equal to opposite the direction *of flow (from downstream to upstream). Therefore, ARC NETWORK can *be easily used to model flow and to assign reaches to a downstream *or upstream point. The .AAT file for the coverage contains two *items that are useful for performing upstream and downstream *allocations. These items, "UP" and "DOWN", can be used in the *ALLOCATE and ROUTE "READNETWORK" command to set the impedance of *reaches in a particular direction to a -1. This will allow NETWORK *to model in only one direction; either upstream or downstream. To *allocate arcs (reaches) upstream from a given point the command is: *READNETWORK DOWN UP. To allocate arcs downstream from a *given point the command is: READNETWORK UP DOWN. * * *RF3NODE.AML * *Some problems arise when attempting to run ARC NETWORK analyses on *the RF3 data. These occur when there is a break in the topological *connectivity of the network, i.e. reaches are not physically *attached. Although PCRF is programmed to catch most of these *situations, some reaches are separated by too great a distance and *the program fails to connect them. This poses no problem to the IBM *Reach File System, as flow modelling takes place via the attributes *and does not require topological connections. However, this will *cause ARC NETWORK to stop prematurely at the dangling reach. * *To help alleviate this problem, and to avoid having to physically *attach each dangle, Dr. Jim Bricker has produced an ARC AML called *RF3NODE.AML. RF3NODE is a partial solution to the problem of using *ARC INFO ALLOCATE and ROUTE across gaps. This AML initially *performs ARC RENODE to calculate both FNODE# and TNODE# values. Then *the FNODE# values are changed to reflect the TNODE# of the *downstream reach according to the .DS1 file. As this AML is run, *there will be some "NO MATCH" messages. These are usually caused by *isolated water bodies and are not a problem. This AML uses names for *files and for items which are compatible with the names resulting *from coverages made from RF3 EXPORT files generated on the IBM 3090. *A copy of RF3NODE has been included with this Technical Memorandum *package. The coding is provided in Appendix B. * * *DYNAMIC SEGMENTATION * *ARC/INFO version 6.0 will provide a new system for handling the *creation, edit, query, and display of linear data that are spatially *referenced by linear measure. The purpose of this system is to *provide the capability to define an abstract linear feature and then *link attributes to a segment of that feature. The position of the *linear features and their segments are independent of arc topology *(i.e. they do not have to start and end on nodes) (ESRI, 1990). *This new system, called Dynamic Segmentation, will greatly enhance *the association of attributes with reaches. It will allow *attributes (flow rate, volume, etc.) to be assigned to specific *reaches, or segments of reaches, even though these segments may not *be defined by a starting and ending node. These attributes will be *independent of the reach coverage .AAT file. Dynamic Segmentation *will also make the locating of features along a reach, such as point *dischargers, easier and more accurate. * *Unfortunately, ARC/INFO version 6.0 is presently released only in *a beta test format, and only on the SUN Workstation platform. *Version 6.0 is not slated for full release on mini-based platforms *for at least a year, and many of the function of 6.0 may not be *available on minis due to memory restrictions. * * *NETWORK ANALYSIS USING ATTRIBUTES * *In addition to performing ARC NETWORK analysis, the network *connectivity attributes (upstream reach number, downstream reach *number, etc.) can be used for hydrologic modeling. ARC/INFO NETWORK *running on the RF3 data is not capable of precisely emulating the *RF3 System network routing which relies on the network connectivity *attributes, particularly when it encounters open water bodies. *Therefore, alternate methods for networking in ARC/INFO are being *investigated. These methods will not rely on arc-node *connectivities but will draw upon network attribute fields to model *upstream and downstream routes. * * * * *UPDATING RF3 DATA WITH ARC/INFO * * *ARC/INFO provides a powerful capability for editing and manipulating *digital information. It is this power, unique in the RF3 user *community, which will allow ARC/INFO users to update the RF3 files *to include new reaches, to improve existing reach traces and to *reflect better name and reach type attribute codes. However, *because the RF3 file is an integrated national database, *implications of modifying the existing information are far reaching. *Policies and practices must be put in place to ensure the updates *being undertaken are within defined bounds. * *The following discussion of RF3 update levels is derived from a *technical memorandum dated 9/14/90 authored by Tim Bondelid of *Horizons Systems Corporation. * * *LEVEL 1 UPDATES : NON-STRUCTURAL CHANGES * *Level I updates are non-structural changes in which Reach *connectivities and hydrologic routing information is unchanged. *These changes include changing/adding names and changing some reach *types. * *Changing Names * *There are three names in RF3: the primary name (PNAME), the open *water name (OWNAME), and the complement (CNAME). The primary name *is the name of the stream or river itself. The open water name is *the name of the lake or reservoir, and the complement name is the *name of the tributary that connects to the reach at the complements *downstream end. * *Associated with each named feature in the RF3 is a unique 11-digit *name code. These name codes provide the ability to distinguish *individual named features that have the same name. For instance, *there are many streams named "Beaver Creek". Each individual stream *named Beaver Creek has a unique name code in RF3. Many named *features are made up of more than one reach, and it is critical that *each reach making up the particular named feature have the same name *unique code. * *Primary Name (PNAME)-- *All changes to the primary name should be based upon *upstream/downstream routing expressions, or existing reach *attributes, and should be confined to a particular CU (no inter-CU *changes). This will ensure that the change is a consistent change *affecting a single path and that the change is limited to the *current CU being updated. Changes involving inter-CU transfers will *require manual oversight and control. Errors such as a stream *becoming a tributary to itself or occurring along two different *routing paths will be prevented with the upstream/downstream routing *control. Spellings and correctness of the PNAME updates will have *to be the responsibility of the updating party. * * *Open Water Name (OWNAME)-- *Once again, routing expressions, or existing reach attributes, can *be utilized to identify a particular open water boundary that may *comprise many different reaches. The same OWNAME should be supplied *for each of these arcs/reaches. * *Complement Name (CNAME)-- *The complement name is a direct derivative of the name assigned to *the complement reach in the RF3 structure (attribute file) record. *As such, the CNAME for the complement reach should be updated each *time the PNAME of a reach is updated. * * * *Changing Name Codes (PNMCD, OWNMCD, CNMCD) * *The 11-digit name codes MUST be unique for each named feature. This *requires that each time a name is added or changed, a unique name *code must be generated. This code must have a zero chance of being *repeated by another updating party. The field for name codes will *accept up to 11 characters. One proposed convention for calculating *the name code is: * *columns 1-6: the update date in the format YYMMDD *columns 7-9: the 3-character NCC userid of the updating party *columns 10-11: a sequential number ranging from 00 to 99. * *The above name code convention will automatically include the date, *and by cross reference with NCC, the name of the updating party. *The only restriction will be that a single user is limited to 100 *name changes a day. * *Using the NCC userid may present problems for those not possessing *a valid id. Many GIS analysts will NOT possess a valid NCC userid. *Perhaps the userid of another member of the updating parties staff *would suffice. The userid does provide a name and address which *would prove very valuable should questions about the updating *process arise. * *Changing Reach Types * *Certain reach type codes (TYPE) can be changed. A common change *will be changing TYPE "U" to either TYPE "L" (lake shoreline) or *TYPE "I" (island shoreline). The nature of the DLG coding is such *that it was not possible to compute with certainty the coding of *some isolated lakes and islands. Many reach type changes will *involve changing the connectivity structure such as changing a *single-line stream to a shoreline; these changes need to be *addressed as level 2 or level 3 updates. * * *LEVEL 2 UPDATES - MINOR STRUCTURAL CHANGES * *These changes involve minor structural changes that affect reach *connectivities. These include adding and deleting individual *reaches and connecting existing reaches. There are two levels of *complexity that may occur. Single line streams are relatively *simple, while open water updates are much more complex. This *memorandum will address single-line changes only. Open water *updates are currently being evaluated and may or may not be feasible *as level 2 updates. * *Reach coordinate changes will require that the master OW DLG trace *file be supplemented. On the master RF3 copy, the pointers to the *DLG trace file will have to be replaced with new keys generated when *the DLG trace is supplemented. These are functions that can only *occur on the mainframe where the RF3 master is maintained. * *Updating the RF3 trace means that several RF3 structure data *elements also need to be updated. These data elements are: * *1) SEGL - the reach segment length (miles) *2) DSLAT,DSLON - the downstream lat/long coordinates *3) USLAT,USLON - the upstream lat/long coordinates *4) MINLAT,MINLON - the minimum lat/long coordinates *5) MAXLAT,MAXLON - the maximum lat/long coordinates * *Note that the milepoint (MI) field of RF3 should NOT be changed. *The milepoints are relative values in RF3 and are not necessarily *dependent upon the reach segment length. * *There are five primary functions that need to be provided for level *2 single-line updates: * *Splitting a Reach (Breaking a Reach Into two Reaches) * *This process entails creating two new RF3 structure and trace *records out of one reach. Both new reaches will contain the name *and name code of the original reach. The upstream portion will *contain the upstream connectivity of the original reach. The *downstream connectivity of the new upstream portion will point to *the new downstream portion. The junction between the two will be *a simple junction. * * * * * Data elements in the upstream portion: * * CU, SEG, UPMI, PNAME, PNMCD, ULCU, ULSEG, ULMI, URCU, * URSEG, URMI, and USDIR from the original reach. * * MI is proportional to the distance up from the downstream end *of the original reach. Definethis distance in miles as *BRKDIST and the MI value of original reach as ORGMI. The MI *value of the upstream reach is then: * * New MI = ORGMI + (UPMI - ORGMI)*(BRKDIST/SEGL) * * DSCU, DSSEG, DSMI = CU, SEG, MI of the original reach. * * TYPE = TYPE of the original reach unless the original is *"T" or "X". If original TYPE = "T" then new TYPE = "R". If *original TYPE = "X" then new TYPE = "S". TheSFLAG and TFLAG *values must also be changed accordingly. * * SEGL and lat/lons are computed from the trace of the upstream * portion. * * LLKEYS are all zero. * * * Data elements in the downstream portion: * * CU, SEG, MI, PNAME, PNMCD, DSCU, DSSEG, DSMI, CCU, CSEG, * CMI, and CDIR from the original reach. * * UPMI is the new MI from the upstream portion. * * URCU, URSEG, URMI = CU, SEG, MI of the upstream portion. * * USDIR = "R" (by convention) * * TYPE = TYPE of the original reach unless the original is "S" *or "X". If original TYPE ="S" then new TYPE = "R". If original *TYPE = "X" then new TYPE = "T". The SFLAGand TFLAG values *must also be changed accordingly. * * SEGL and lat/lons are computed from the trace of the upstream * portion. * * LLKEYS are all zero. * * *In addition, the downstream milepoint (DSMI) values of the reach(es) *immediately upstream of the original reach must be updated to the *new MI value of the upstream portion. * *Deleting a Reach * *Only start and isolated reaches can be deleted. The delete entails *removing the reach from the structure file and removing the *connectivities to the deleted reach from the structure records of *the downstream connecting reaches. If the downstream connection is *a simple junction then the reach type code of the downstream reach *needs to be changed to TYPE = "S". * *Note that a complex network can be deleted by successive deletion *starting at the upstream end and working down. * *Adding a Reach * *Adding a reach entails setting up a new structure record and *corresponding trace record. The structure SEGL and lat/lon values *are derived from the trace record. The CU is the current CU, the *SEG is the next available unused SEG within the CU, and the MI is *0.0. The UPMI is set to the SEGL. * * * * * *Connecting Existing Reaches * *This function will connect the downstream end of an existing *isolated reach to an existing simple junction in the hydrologic *network. The reach connectivities of all 3 reaches involved will *need to be updated to reflect the connection. * *Breaking Existing Connections * *An existing connection can be broken by changing the reach *connectivities for the reaches at the junction. The "break" will *result in one simple junction between two reaches and one isolated *reach or sub-network. * *Combining Update Operations * *Names for new reaches should be added using the conventions *described in level-1 updates, after the reaches are connected. * *Many reach update operations can be performed using the level-1 and *level-2 conventions. Individual reaches can be updated or replaced. *Whole sub-networks can be added or modified as needed. Reach *connections can be changed using the break and connect operations. * *Structural changes will require PCRF to "rebuild" the new or updated *reaches into RF3. Numbering of new reaches also will require EPA- *OW intervention to preserve consistency. * *ARC AMLs are being developed to help guide the updating process. *These AMLs will enable the analyst to automatically update certain *required fields such as date and time "stamps". They will also *ensure that the standard update process is being followed. The *policy and procedures for these updates are presently evolving. It *is expected that input from EPA Regional GIS users of RF3 data will *play a critical role in helping to define these policies. * * *A first-draft version of the update AMLs is provided with this *Technical Memorandum package. These AMLs provide menu driven *interfaces and allow Level-1 updating of the RF3 attributes for open *water name, primary name and reachtype only. A discussion of the *draft AMLs can be found in Appendix C. Level 2 and 3 updating will *require much more rigorous programs and more well defined processes. *It is hoped that these can be designed in the near future, *preferably with the input of GIS RF3 users in the Regions. * * *RETURNING UPDATED RF3 DATA * *Once a CU of RF3 data has been updated, it must be returned to EPA- *OW for testing and possible inclusion into the RF3 "master" file. *A Fortran program which converts an ARC/INFO coverage into a series *of ASCII files has been developed to aid in this process. These *output ASCII files can be read into the RF3 system for examination *and possible reintegration. * *Avenues for transferring the updated CUs back to EPA-OW are being *investigated. EMSL-LV has developed a fortran program which *converts an RF3 ARC coverage into several ASCII files which can be *read by OW. Dr. Bricker is also investigating the feasibility of *a program that will operate in reverse of the RF3 to ARC EXPORT *program, thus making an RF3 file of the ARC coverage. This would *greatly simplify the process of returning updated RF3 files to OW. * * *SUMMARY AND CONCLUSION * *As the use of GIS and other information management technologies *becomes commonplace in government agencies, we begin to see a *breakdown of the proprietary attitudes towards data that used to *pervade. The EPA GIS community will greatly benefit from the *cooperative efforts being undertaken with the Office of Water. RF3 *data, which have proven themselves of immense value to the present *RF3 user community, hold great promise for Agency GIS users. In *this spirit of cooperation, GIS users will in turn provide a *valuable tool for updating the RF3 data. These efforts will save *the Agency a tremendous amount of time and money, while providing *data that will enhance the fight for a better environment. * * *ACKNOWLEDGEMENTS * *Much of the material contained in this document was compiled from *memorandums and unpublished documents provided by the various EPA *employees and contractors taking part in this data sharing effort. *Credit is due Mr. Tim Bondelid, formerly with Horizon Systems *Corporation (presently with Research Triangle Institute, RTP North *Carolina) for his invaluable input. Mr. Bondelid was one of the *chief developers of the Reach File System and his cooperation was *instrumental in the success of this activity. Sue A. Hanson of *Horizon Systems Corporation has also been extremely cooperative and *supportive of this effort. Dr. Jim Bricker of EPA Region 4 has *contributed much valued technical programming and ARC/INFO support, *and Michael Paquette of Vigyan has provided the all important link *to the EPA GRIDS system which makes these data readily available to *Agency users. * * APPENDIX A: INFO DATAFILE DEFINITIONS * *The .AAT file contains the following items. * * 12 ITEMS: STARTING IN POSITION 1 * COL ITEM NAME WDTH OPUT TYP N.DEC ALTERNATE NAME * 1 FNODE# 4 5 B - * 5 TNODE# 4 5 B - * 9 LPOLY# 4 5 B - * 13 RPOLY# 4 5 B - * 17 LENGTH 4 12 F 3 * 21 A6020004# 4 5 B - * 25 A6020004-ID 4 5 B - * 29 CU 8 8 I - * 37 SEG 4 4 I - * 41 MILE 5 5 N 2 * 46 UP 4 5 B - * 50 DOWN 4 5 B - * ** REDEFINED ITEMS ** * 29 RF3RCHID 17 17 C - * *The .DS1 datafile contains the following fields: * * 64 ITEMS: STARTING IN POSITION 1 * COL ITEM NAME WDTH OPUT TYP N.DEC ALTERNATE NAME * 1 CU 8 8 I - * 9 SEG 4 4 I - * 13 MILE 5 5 N 2 * 18 UPMI 5 5 N 2 * 23 RFLAG 1 1 C - * 24 OWFLAG 1 1 C - * 25 TFLAG 1 1 C - * 26 SFLAG 1 1 C - * 27 REACHTYPE 1 1 C - * 28 LEVEL 2 2 I - * 30 JUNC 2 2 I - * 32 DIVERGENCE 1 1 I - * 33 USDIR 1 1 C - * 34 TERMID 5 5 I - * 39 TRMBLV 1 1 I - * 40 PNAME 30 30 C - * 70 PNMCD 11 11 C - * 81 CNAME 30 30 C - * 111 CNMCD 11 11 C - * 122 OWNAME 30 30 C - * 152 OWNMCD 11 11 C - * 163 DSCU 8 8 I - * 171 DSSEG 4 4 I - * 175 DSMI 5 5 N 2 * 180 CCU 8 8 I - * 188 CSEG 4 4 I - * 192 CMILE 5 5 N 2 * 197 CDIR 1 1 C - * 198 ULCU 8 8 I - * 206 ULSEG 4 4 I - * 210 ULMI 5 5 N 2 * 215 URCU 8 8 I - * 223 URSEG 4 4 I - * 227 URMI 5 5 N 2 * 232 SEGL 6 6 N 2 * 238 RFORGFLAG 1 1 I - * 239 ALTPNMCD 8 8 I - * 247 ALTOWNMC 8 8 I - * 255 DLAT 8 8 N 4 * 263 DLONG 8 8 N 4 * 271 ULAT 8 8 N 4 * 279 ULONG 8 8 N 4 * 287 MINLAT 8 8 N 4 * 295 MINLONG 8 8 N 4 * 303 MAXLAT 8 8 N 4 * 311 MAXLONG 8 8 N 4 * 319 LN1AT2 4 4 I - * 323 LN2AT2 4 4 I - * 327 AR1AT2 4 4 I - * 331 AR1AT4 4 4 I - * 335 AR2AT2 4 4 I - * 339 AR2AT4 4 4 I - * 343 UPDATE1 6 6 C - * 349 UPDTCD1 8 8 C - * 357 UPDTSRC1 8 8 C - * 365 UPDATE2 6 6 C - * 371 UPDTCD2 8 8 C - * 379 UPDTSRC2 8 8 C - * 387 UPDATE3 6 6 C - * 393 UPDTCD3 8 8 C - * 401 UPDTSRC3 8 8 C - * 409 DIVCU 8 8 I - * 417 DIVSEG 4 4 I - * 421 DIVMI 5 5 N 2 * ** REDEFINED ITEMS ** * 1 RF3RCHID 17 17 C - * 163 DSRF3RCHID 17 17 C - * 180 CURF3RCHID 17 17 C - * 198 ULRF3RCHID 17 17 C - * 215 URRF3RCHID 17 17 C - * *The following is a brief description of the items in this file: * * ITEM NAME DESCRIPTION * CU Catalog Unit * SEG Segment Number * MILE Mile Point (MI) * UPMI Upstream Mile Point * RFLAG Reach Flag(0,1) * OWFLAG Open Water Flag(0,1) * TFLAG Terminal Flag(0,1) * SFLAG Start Flag(0,1) * REACHTYPE Reach Type Code * LEVEL Level * JUNC Junction Number * DIVERGENCE Divergence Code * USDIR Upstream Direction * TERMID Terminal Stream Id * TRMBLV Terminal Base Level * PNAME Primary Name * PNMCD Primary Name Code * CNAME Complement Name * CNMCD Complement Name Code * OWNAME Open Water Name * OWNMCD Open Water Name Code * DSCU Downstream CU * DSSEG Downstream SEG * DSMI Downstream MI * CCU Complement CU * CSEG Complement SEG * CMILE Complement MI * CDIR Complement Direction * ULCU Upstream Left CU * ULSEG Upstream Left SEG * ULMI Upstream Left MI * URCU Upstream Right CU * URSEG Upstream Right SEG * URMI Upstream Right MI * SEGL Reach Length (Miles) * RFORGFLAG RF Origin Flag(1,2,3,) * ALTPNMCD Alt. Primary Name Code * ALTOWNMC Alt. OW Name Code * DLAT Downstream Latitude * DLONG Downstream Longitude * ULAT Upstream Latitude * ULONG Upstream Longitude * MINLAT Minimum Latitude * MAXLAT Maximum Latitude * MAXLONG Maximum Longitude * LN1AT2 DLG Line Attribute 1 * LN2AT2 DLG Line Attribute 2 * AR1AT2 DLG Area Attribute * AR1AT4 DLG Area Attribute * AR2AT2 DLG Area Attribute * AR2AT4 DLG Area Attribute * UPDATE1 Update Date #1(mmddyy) * UPDTCD1 Update Type Code #1 * UPDTSRC1 Update Source #1 * UPDATE2 Update Date #2(mmddyy) * UPDTCD2 Update Type Code #2 * UPDTSRC2 Update Source #2 * UPDATE3 Update Date #3 * UPDTCD3 Update Type Code #3 * UPDTSRC3 Update Source #3 * DIVCU Divergence CU * DIVSEG Divergence SEG * DIVMI Divergence MI * ** REDEFINED ITEMS ** * RF3RCHID Reach Number (RN) * DSRF3RCHID Downstream RN * CURF3RCHID Complementary RN * ULRF3RCHID Upper Left RN * URRF3RCHID Upper Right RN * APPENDIX B: RF3NODE.AML * * * */* THIS AML IS RUN UNDER ARC TO AJUST THE FNODE# AND TNODE# TO */* CORRESPOND TO RF3 DOWNSTREAM STRUCTURE IN ORDER TO RUN ARC * /* INFO NETWORK USING ALLOCATE ACROSS GAPS IN THE TRACES. */* */* PLEASE TEST THIS AML AND REPORT ANY PROBLEMS WITH IT TO: */* Jim Bricker */* (404) 347-3402 */* OR FTS 257-3402 */* *&ARGS COV RUNON:REST *&DATA ARC *RENODE %COV% *ADDITEM %COV%.DS1 %COV%.DS1 RECNUM 4 5 B *INFO *DEFINE %COV%.XX1 *RF3RCHID,17,17,C *DSRF3RCHID,17,17,C *TNODE#,4,5,B *%COV%#,4,5,B * *SEL %COV%.AAT *SORT RF3RCHID *RELATE %COV%.XX1 BY %COV%# WITH INIT *MOVE RF3RCHID TO $1RF3RCHID *CAL $1TNODE# = TNODE# *SEL %COV%.DS1 *CAL RECNUM = $RECNO *SORT RF3RCHID *RELATE %COV%.XX1 BY RF3RCHID WITH ORDERED *MOVE DSRF3RCHID TO $1DSRF3RCHID *Q STOP *ADDITEM %COV%.XX1 %COV%.XX2 FNODE# 4 5 B # DSRF3RCHID *INFO *SEL %COV%.XX1 *MOVE RF3RCHID TO DSRF3RCHID *SEL %COV%.XX2 *CAL FNODE# = 0 *RELATE %COV%.XX1 BY DSRF3RCHID WITH ORDERED *CAL FNODE# = $1TNODE# *CAL %COV%# = -1 * $1TNODE# *REDEFINE *35 *ALPHA,4,4,C * *RESEL ALPHA CN *RELATE %COV%.AAT BY RF3RCHID WITH ORDERED *CAL FNODE# = $1FNODE# *SEL %COV%.AAT *RELATE %COV%.XX2 BY RF3RCHID WITH ORDERED *CAL FNODE# = $1FNODE# *Q STOP *ADDITEM %COV%.XX2 %COV%.XX3 NULL 1 1 C *INFO *SEL %COV%.XX3 *RESEL %COV%# LT 0 *NSEL *PURGE *Y *SEL %COV%.AAT *RELATE %COV%.XX3 BY RF3RCHID *CAL TNODE# = $1TNODE# *REDEFINE *5 *ALPHA,4,4,C * *RESEL ALPHA CN *RELATE %COV%.XX2 BY RF3RCHID WITH ORDERED *CAL TNODE# = $1TNODE# *SORT %COV%# *SEL %COV%.DS1 *SORT RECNUM *SEL %COV%.XX1 *ERASE %COV%.XX1 *Y *SEL %COV%.XX2 *ERASE %COV%.XX2 *Y *SEL %COV%.XX3 *ERASE %COV%.XX3 *Y *Q STOP *DROPITEM %COV%.DS1 %COV%.DS1 RECNUM *Q *&END *&RETURN APPENDIX C: UPDATE AML DESCRIPTION * *RF3 Update AMLs - 1st Draft, Level 1 Updating * *These AMLs provide tools for the updating of RF3 attributes (level *1 update) in the ARC/INFO ARCEDIT environment. They are designed *to query for necessary variables and to code particular fields with *appropriate information. They help guide the updating process and *assure the updating is performed in a standardized, well documented *manner. Eventually, AMLs will be developed to guide level two and *three updating as well. * *These AMLs were developed on a Sun SparcStation 1+. They have been *developed to run on any platform (except PC), but will perform best *on a UNIX based workstation. It is highly recommended that they be *run on a workstation when possible. * *UPDATE.AML * *The syntax for running the update AML is: * *&run update {input device} * *The first menu (main.menu) encountered when the program is run *prompts the users for several items. The first is the users NCC *IBM user id (three letter id). This will provide the name and *location of the user via cross referencing with the NCC IBM. *However, it is recognized that many users of these AMLs will not *possess a valid IBM user id. It is envisioned that these users *would input a co-workers id or the id of someone associated with *the group. This field is obviously subject to change as the *updating proceedures become better defined. * *The next field the user is prompted for is the "RF3 coverage to *update". The user can enter a valid coverage name, or query for *coverages available (using the middle mouse button or a "?"). * *The user then selects the field to update. Three different RF3 *attributes can be updated using these AMLs. These are primary name *(PNAME), open water name (OWNAME) and reach type (REACHTYPE). * *When all the menu fields are filled in, the user selects "OK" and *the next aml is run. This AML is called SETAE.AML. * *SETAE.AML first checks for the existence of required fields in the *RF3 coverage. If any of these fields is missing, the program *returns the user to the main menu where they can select a new *coverage to update. The program then checks to see if the edit *coverage has been changed, and sets up the ARCEDIT environment. * *The edit coverage is drawn onto the graphics screen and a sidebar *menu is produced (SIDE1.MENU). The sidebar allows the user to *select a single reach graphically (with the cursor), or select a *reach based on a character string (reach name). The user can also *zoom in/out, save changes, return to the main menu, or quit the *session. * *After a reach is selected, several things happen in the program *SEL1.AML. If the user has selected a reach that is coded as a *wetland, a warning message appears informing the user that the reach *is not a river or shoreline reach. Wetland reaches do not possess *PNAMEs or OWNAMEs, but they can be updated for REACHTYPE. If the *user has chosen OWNAME as the field to update, and the selected *reach is not presently coded as an open water body shoreline, a *warning message appears. * *When updating PNAME, the program first examines the value for the *reach file origin (1, 2, or 3). When it is a RF1 reach, the program *aselects (adds to the selected set) all reaches that have the same *primary name code (PNMCD) as the selected reach. This should ensure *that all reaches within the same main channel, which should have the *same name, are selected and available to be updated with a new name *provided by the user. * *If the reach selected is a RF2 or RF3 reach, the program aselects *all reaches that have the same SEG value (are within the same reach *segment), which again should provide all reaches within the same *main channel. * *If the field selected for update is OWNAME, the program selects all *reaches that are coded as open water reaches and have the same SEG *value. * *If the field selected for update is REACHTYPE, no aselect logic is *used. Only the selected reach is updated. In other words, updating *of REACHTYPE occurs on a reach-by-reach basis. * *Once a set of reaches has been selected, they are drawn with symbol *2 (red). A new menu appears (SIDE2.MENU) which allows the user to *change the selected set by adding to the set, removing from the set, *clearing the set, etc. It will also allow the user to zoom in/out, *to save changes, to return to the previous menu, to quit the *session, or to perform an update. If the user chooses "Update *Attributes" to perform an update, the AML MOVEITEM.AML is run. * *MOVEITEM.AML runs a menu called MOVEITEM.MENU which displays the *current value in the chosen update field, and prompts for the user *to input a new character string. If no character string is input a *menu called MOVEITEM2.MENU is run which queries whether it is okay *to enter a null string in the current update field. Once a valid *string is entered, the program moves the new string into the update *field, and moves several more strings into the following fields. * *The field UPDATE2 is filled with a character string representing *the current date (e.g. "051691" which is May 16, 1991). The field *UPDTCD2 is filled with the NCC user id and a number which follows *the decimal place in the date format FTAG (see AML [DATE *This encodes the identity of the user performing the update and also *targets the time of the update (in decimal day format). * *After successfully moving new strings into these update fields, the *symbols for the selected set of reaches are changed to 3 (green) for *those reaches whose PNAME was updated, 4 (blue) for those reaches *whose OWNAME was updated, and 6 (magenta) for those reaches whose *REACHTYPE was updated. * *The next step in the update program provides a menu from which to *select the source of the update information. This menu allows the *user to select various USGS topographic map series, state maps, *local maps, other, etc. A code representing the selected update *source in then moved into the field UPDTSRC2. * *There are several drawbacks to the above described methodology which *merit discussion. Due to the limitation of update code fields only *the latest update will be archived in the fields UPDATE2 and *UPDTCD2. In other words, if a user updates the PNAME field for a *reach, then later updates the OWNAME field for the same reach, the *date and user id for the second session will be recorded in the *update code fields thus "erasing" the codes from the first session. * * *The fields PNMCD and OWNMCD exist to differentiate like-named *features which are actually different hydrologic units. For *example, there may be several "Oak Creeks" in the same CU. The *PNMCD is used to differentiate one "Oak Creek" from another. These *fields were originally planned to get the time/date/id stamps when *the name was updated. However, if the user fails to correctly *select and update all of the features defining a particular stream *or shoreline at the same time, these date/time/id stamps will *differ. The AML code used to move a date into the fields PNMCD and *OWNMCD when updating occurs has been commented out of MOVEITEM.AML. *A better method for defining or updating these fields must be *developed. * *After updating the selected item, the user returns to the coverage *and is prompted with the first side bar menu to begin the process *again. At any theme the user may leave the program. The coverage *may be saved to the same name or to a new, user-defined name. The *user may also quit without saving changes. * *Returning to the main menu will allow the user to change the edit *coverage, or the field to update. If the edit cover is changed, *and some reaches in the old cover have been modified, the program *asks if the user wishes to save the changes before working on a new *cover. * *It is hoped that these AMLs prove useful in guiding those performing *updates of RF3 data with ARC/INFO. It is also hoped that input to *this update process will be forthcoming from the actual RF3/GIS user *community. These AMLs should serve mostly as a guide to the *processes that should be followed when performing level-1 updates. *Modifications or wholesale revisions of the programs are welcome as *users become familiar with the RF3 data and the update process. * *Comments/suggestions/revisions should be referred to: * *Dick Dulaney *Lockheed Engineering and Sciences Company *1050 E. Flamingo Rd Ste. 126 *Las Vegas, NV 89119 * *FTS 545-3158 *Commercial (702)798-3158 * * ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * Time_Period_of_Content Single_Date/Time Calendar_Date: unknown Currentness_Reference As given. Status Progress: Approved for release by Tim Hale, Georgia District Chief Maintenance_and_Update_Frequency None. Spatial_Domain Bounding_Coordinates West_Bounding_Coordinate: -85.56811793 East_Bounding_Coordinate: -80.73787909 North_Bounding_Coordinate: 35.0041382 South_Bounding_Coordinate: 30.33387974 Keywords Theme Theme_Keyword_Thesaurus: None Theme_Keyword: River reach, RF3, dlg, Hydrography, EPA, RF1 Place Place_Keyword_Thesaurus: None Place_Keyword: State of Georgia Stratum Stratum_Keyword_Thesaurus: None Stratum_Keyword: Temporal Temporal_Keyword_Thesaurus: None Temporal_Keyword: Access_Constraints None. Use_Constraints Some attributes and geometry are still missing from the stream network. Also, as in RF3, geometry may be slightly different from the source 1:100000 DLG. Use at your own risk. Point_of_Contact: See Data_Set_Credit EPA, Office of Water Security_Information Security_Classification_System: None Security_Classification: UNCLASSIFIED Security_Handling_Description: None Native_Data_Set_Environment: dgux UNIX, ARC/INFO version 7.0.4 Cross_Reference Originator: Unknown Publication_Date: Publication_Time: Title: Edition: Geospatial_Data_Presentation_Form: Series_Information Series_Name: Issue_Identification: Publication_Information Publication_Place: Publisher: Other_Citation_Details: Online_Linkage: Larger_Work_Citation: --------------------------------------------------------------------------- Data_Quality_Information Attribute_Accuracy Attribute_Accuracy_Report: See Logical_Consistency_Report: Chain-node topology present. Completeness_Report Data reselected from complete RF3 data set. No additional information added. Positional_Accuracy Horizontal_Positional_Accuracy Horizontal_Positional_Accuracy_Report: See RF3 documentation Quantitative_Horizontal_Positional_Accuracy_Assessment: Horizontal_Positional_Accuracy_Value: 40 meters Horizontal_Positional_Accuracy_Explanation: Resolution as reported Vertical_Positional_Accuracy Vertical_Positional_Accuracy_Report: See RF3 documentation Lineage: See Cloud_Cover NA --------------------------------------------------------------------------- Spatial_Data_Organization_Information Direct_Spatial_Reference_Method: Vector Point_and_Vector_Object_Information SDTS_Terms_Description SDTS_Point_and_Vector_Object_Type: Point Point_and_Vector_Object_Count: 0 SDTS_Point_and_Vector_Object_Type: String Point_and_Vector_Object_Count: 19220 SDTS_Point_and_Vector_Object_Type: GT-polygon composed of chains' Point_and_Vector_Object_Count: 0 --------------------------------------------------------------------------- Spatial_Reference_Information Horizontal_Coordinate_System_Definition Planar Map_Projection: Map_Projection_Name: ALBERS Longitude_of_Central_Meridian: -83.5 Latitude_of_Projection_Origin: 23 Latitude_of_First_Standard_Parallel: 29.5 Latitude_of_Second_Standard_Parallel: 45.5 False_Easting: 0.00000 False_Northing: 0.00000 Geodetic Model Horizontal_Datum_Name: North American Datum of 1983 Ellipsoid_Name: GRS 80 Semi-major_Axis: 6,378,206.4 Denominator_of_Flattening: 294.98 --------------------------------------------------------------------------- Entity_and_Attribute_Information Detailed_Description Entity_Type Entity_Type_Label: RF3MJR.AAT Entity_Type_Definition: Attribute table of RF3MJR. Entity_Type_Definition_Source: ARC/INFO Attribute: Attribute_Label: - Attribute_Definition: Attribute table of RF3MJR. Attribute_Definition_Source: ARC/INFO Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: - Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: FNODE# Attribute_Definition: Internal number of from-node Attribute_Definition_Source: Computed Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Sequential unique positive integer Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: TNODE# Attribute_Definition: Internal number of to-node Attribute_Definition_Source: Computed Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Sequential unique positive integer Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: LPOLY# Attribute_Definition: Internal number of poly to left of arc Attribute_Definition_Source: Computed Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Sequential unique positive integer Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: RPOLY# Attribute_Definition: Internal number of poly to right of arc Attribute_Definition_Source: Computed Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Sequential unique positive integer Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: LENGTH Attribute_Definition: Length of arc in coverage units Attribute_Definition_Source: Computed Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Positive real numbers Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: RF3MJR# Attribute_Definition: Internal feature number Attribute_Definition_Source: Computed Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Sequential unique positive integer Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: RF3MJR-ID Attribute_Definition: User-assigned feature number Attribute_Definition_Source: User-defined Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Integer Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CU Attribute_Definition: See Narrative for description of remaining attributes Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: SEG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: MILE Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UP Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DOWN Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPMI Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: RFLAG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: OWFLAG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: TFLAG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: SFLAG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: REACHTYPE Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: LEVEL Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: JUNC Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DIVERGENCE Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: USDIR Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: TERMID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: TRMBLV Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: PNAME Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: PNMCD Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CNAME Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CNMCD Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: OWNAME Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: OWNMCD Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DSCU Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DSSEG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DSMI Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CCU Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CSEG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CMILE Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CDIR Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ULCU Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ULSEG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ULMI Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: URCU Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: URSEG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: URMI Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: SEGL Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: RFORGFLAG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ALTPNMCD Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ALTOWNMC Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DLAT Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DLONG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ULAT Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ULONG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: MINLAT Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: MINLONG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: MAXLAT Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: MAXLONG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: NDLGREC Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDATE1 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDTCD1 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDTSRC1 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDATE2 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDTCD2 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDTSRC2 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDATE3 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDTCD3 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: UPDTSRC3 Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DIVCU Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DIVSEG Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DIVMI Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DLGID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: FILLER Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: RF3RCHID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DSRF3RCHID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: CURF3RCHID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: ULRF3RCHID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: URRF3RCHID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Attribute: Attribute_Label: DIVRF3RCHID Attribute_Definition: Attribute_Definition_Source: Attribute_Domain_Values Enumerated_Domain Enumerated_Domain_Value: Enumerated_Domain_Value_Definition Enumerated_Domain_Value_Definition_Source: Overview_Description Entity_and_Attribute_Overview See full RF3 documentation under Refreneces. Entity_and_Attribute_Detail_Citation: Not Available --------------------------------------------------------------------------- Distribution_Information Distributor Contact_Person_Primary Contact_Person: Jonathan W. Musser Contact_Organization: U.S. Geological Survey Contact_Position: Hydrologist Contact_Address Address_Type: mailing address Address: U.S. Geological Survey 3039 Amwiler Road Suite 130 City: Atlanta State_or_Province: GA Postal_Code: 30360-2824 Country: USA Contact_Facsimile_Telephone: 770-903-9199 Contact_Electronic_Mail_Address: jwmusser@usgs.gov Standard_Order_Process Digital_Form Digital_Transfer_Information Format_Name: ARCE ARC/INFO Export format File_Decompression_Technique: gzip Format_Name: SDTS Spatial Data Transfer Standards (FIPS 173) File_Decompression_Technique: gzip & tar Digital_Transfer_Option Online_Option Computer_Contact_Information Network_Address Network_Resource_Name: http://csat.er.usgs.gov/statewide/layers/rf3mjr.html --------------------------------------------------------------------------- Metadata_Reference_Section Metadata_Date: 19980109 Metadata_Contact: nybunek Metadata_Standard_Name: FGDC Content Standards for Digital Geospatial Metadata Metadata_Standard_Version: 19940608 Metadata_Time_Convention: Local Time Metadata_Security_Information: Metadata_Security_Classification_System: None Metadata_Security_Classification: UNCLASSIFIED Metadata_Security_Handling_Description: None --------------------------------------------------------------------------- Last modified: 2008-03-20