CRWR Online Report 04-06 
 
 
Arc Hydro Developments for the Lower Colorado River Basin 
 
 
 
by 
 
 
Daniel R. Obenour, M.S.E. 
 
Graduate Research Assistant 
 
 
and 
 
 
David R. Maidment, PhD. 
 
Principal Investigator 
 
May 2004 
 
 
 
CENTER FOR RESEARCH IN WATER RESOURCES 
 
Bureau of Engineering Research ? The University of Texas at Austin 
J.J. Pickle Research Campus ? Austin, TX 78712-4497 
 
This document is available online via World Wide Web at 
http://www.crwr.utexas.edu/online.shtml 
 
 
 
 
Acknowledgements 
 
I would like to thank my advisor, Dr. David Maidment, for his guidance, and for 
the enthusiasm he has shown towards this project.  I would also like to thank the whole 
team at CRWR for their friendship and their teaching.  Additionally, I would like to thank 
my friends and associates at the LCRA who have supported me throughout this project.  
Specifically, I would like to thank Daniel Yates for his dedication to this project?s 
successful completion. 
 
 
 
 
 
 
 
 
 
 
May 2004 
 
Table of Contents 
LIST OF TABLES ...................................................................................................... X 
LIST OF FIGURES.................................................................................................... XI 
CHAPTER 1:  INTRODUCTION...................................................................................1 
1.1 Background...............................................................................................1 
1.2 Study Objectives .......................................................................................3 
1.3 Thesis Outline ...........................................................................................4 
CHAPTER 2:  LITERATURE REVIEW .........................................................................5 
2.1 Arc Hydro Data Model .............................................................................5 
2.2 Other GIS Applications for Hydrology...................................................10 
2.3 Flood Damage Studies ............................................................................11 
2.4 Summary of Existing Research...............................................................13 
CHAPTER 3:  DATA AND MODELS REVIEW ...........................................................14 
3.1 GIS Data..................................................................................................14 
3.2 Hydrologic and Hydraulic Models..........................................................15 
3.3 Introduction to HEC-HMS......................................................................17 
3.4 Introduction to HEC-RAS ......................................................................20 
3.5 Time Series Data.....................................................................................20 
CHAPTER 4:  METHODOLOGY................................................................................25 
4.1 Populating the Arc Hydro Framework....................................................25 
4.1.1 Llano River Background Information.........................................25 
4.1.2 Arc Hydro Raster Processing......................................................28 
4.1.3 The Arc Hydro Framework.........................................................31 
4.1.4 Arc Hydro Time Series Development.........................................40 
4.1.5 Arc Hydro for Microsoft SQL Server.........................................45 
4.2 Creating an Interface Data Model (IDM) ...............................................49 
4.2.1 IDM Theory ................................................................................49 
4.2.2 Introduction to Data Model Design ............................................52 
 iii
4.2.3 An IDM for HEC-HMS ..............................................................54 
4.2.4 IDM Database Structure .............................................................57 
4.2.5 IDM Scenario Management........................................................64 
4.2.6 Linking the IDM with HMS data................................................67 
4.3 Creating a GIS-Based Flood Damage Evaluation System......................71 
4.3.1 System Objectives.......................................................................71 
4.3.2 Flood Map Generation ................................................................74 
4.3.3 Damage Report Generation.........................................................82 
4.3.4 Flood Data Model Development.................................................84 
4.3.5 Model Builder Application .........................................................87 
CHAPTER 5:  RESULTS ...........................................................................................97 
5.1 Arc Hydro Results...................................................................................97 
5.1.1 Arc Hydro Framework................................................................97 
5.1.2 Arc Hydro Time Series Format.................................................100 
5.1.3 Arc Hydro Toolset ....................................................................107 
5.2 HMS IDM Results ................................................................................111 
5.3 Flood Damage Evaluation System Results...........................................116 
CHAPTER 6:  CONCLUSIONS AND RECOMMENDATIONS .....................................121 
6.1 Project Summary...................................................................................121 
6.2 Project Conclusions ..............................................................................122 
6.3 Future Research Opportunities .............................................................124 
6.4 Over-All Project Significance...............................................................125 
 iv
APPENDIX A:  ?LCRA WORLD? GIS REPOSITORY .............................................126 
APPENDIX B:  LCRA HYDROMET DATABASE DIAGRAM ...................................134 
APPENDIX C:  LCRA HYDROMET FLOW DIAGRAM............................................136 
APPENDIX D:  LCRA WATER QUALITY DATABASE DIAGRAM..........................138 
APPENDIX E:  INSTRUCTIONS ? ?POPULATING AN ARC HYDRO DATASET? ......140 
APPENDIX F:  HMS IDM DATABASE DIAGRAM .................................................162 
APPENDIX G:  INSTRUCTIONS ? ?POPULATING A HMS IDM?............................165 
APPENDIX H:  INSTRUCTIONS ? ?PREPARATION OF FLOODPLAIN MAPPING DATA?
.....................................................................................................................174 
APPENDIX I:  MODEL BUILDER LAYOUTS...........................................................180 
REFERENCES ........................................................................................................194 
VITA 196 
 v
List of Tables 
Table 3.1:  Common HMS file types and descriptions.................................18 
Table 4.1:  Source data for the Llano River Arc Hydro Framework ............32 
Table 4.2:  Feature classes in the LCRA Arc Hydro Framework.................38 
Table 4.3:  DSS pathname metadata.............................................................61 
Table 4.4:  IDM identification codes ............................................................63 
Table 4.5:  Summary of LCRAfloodTools ...................................................94 
Table 4.6:  LCRAfloodTools input and output data .....................................95 
Table 5.1: Arc Hydro time series format: standard and compacted............106 
 
 vi
List of Figures 
Figure 1.1 ? Hydrologic Modeling System (Maidment, 2002) ......................2 
Figure 1.2 ? Lower Colorado River site map (adapted from LCRA website)
................................................................................................................3 
Figure 2.1 ? Arc Hydro Framework with Time Series (Maidment, 2002).....9 
Figure 3.1 ? LCRA/Halff H&H modeling effort..........................................16 
Figure 3.2 ? HEC-HMS flow diagram ? data storage files in blue, control files  
in green.................................................................................................19 
Figure 3.3 ? Transferring gridded rainfall data to watersheds......................23 
Figure 4.1 ? Map of the Llano River Basin ..................................................27 
Figure 4.2 ? DEM of the Llano River Basin.................................................29 
Figure 4.3 ? Vectorized catchments, lines, and points for the Llano River Basin
..............................................................................................................30 
Figure 4.4 ? The geodatabase structure ........................................................34 
Figure 4.5 ? HydroJunctions and MonitoringPoints.....................................35 
Figure 4.6 ? HydroEdges with properly assigned flow directions................36 
Figure 4.7 ? Two NEXRAIN coverage areas ...............................................41 
Figure 4.8 ? NEXRAIN flat file for September 3, 2002...............................42 
Figure 4.9 ? Example TSType and TimeSeries tables..................................43 
Figure 4.10 ? An ArcCatalog view of GIS data on SQL Server...................47 
Figure 4.11 ? IDM and hydrologic modeling for the LCRA (adapted from 
Maidment, 2002)..................................................................................51 
Figure 4.12 ? Example UML diagram (taken from the HMS IDM) ............53 
Figure 4.13 ? HMS/IDM data connectivity ..................................................56 
Figure 4.14 ? Data blocks from a HMS basin file ........................................58 
Figure 4.15 ? Table for Initial+Constant LossRate parameters....................59 
Figure 4.16 ? Coded value domains in ArcMap...........................................62 
Figure 4.17 ? Program for transferring a HMS basin file to the IDM..........68 
Figure 4.18 ? Program for transferring GIS shape data to the IDM.............69 
Figure 4.19 ? Program for transferring DSS paired data to the IDM ...........70 
 vii
Figure 4.20 ? LCRA/Halff flood shapefiles for return-frequency storms (Lake 
Travis)..................................................................................................72 
Figure 4.21 ? Floodplain structures over a 20-foot raster.............................75 
Figure 4.22 ? Coves extending beyond hydraulic cross sections on Lake Travis
..............................................................................................................76 
Figure 4.23 ? The ?fill sinks? solution to mapping cove inundation............77 
Figure 4.24 ? Original cross sections (top) and modified cross sections (bottom)
..............................................................................................................78 
Figure 4.25 ? Lake Travis, a particularly sinuous stretch of the Lower Colorado 
River.....................................................................................................79 
Figure 4.26 ? Toeing cross sections to prevent errors caused by river sinuosity
..............................................................................................................80 
Figure 4.27 ? Clipping cross sections on the inside of a river bend .............81 
Figure 4.28 ? Data model for flood damage evaluation ...............................84 
Figure 4.29 ? Classes and fields required for the flood damage evaluation 
system ..................................................................................................86 
Figure 4.30 ? Toolkit for the flood damage evaluation system ....................88 
Figure 4.31 ? GUI for the GenerateALL tool...............................................89 
Figure 4.32 ? GenerateALL model layout....................................................90 
Figure 4.33 ? Generate floodplain map model .............................................91 
Figure 4.34 ? GUI for the ArchiveNew model.............................................92 
Figure 4.35 ? GUI for the DeleteArchivedFloodPlain model.......................93 
Figure 5.1 ? Finished model, HydroJunctions & MonitoringPoints.............98 
Figure 5.2 ? Finished model, feature Names/HydroCodes...........................98 
Figure 5.3 ? Finished model, lengths from basin outlet ...............................99 
Figure 5.4 ? Finished model, watershed areas & cumulative area upstream for 
junctions...............................................................................................99 
Figure 5.5 ? Upstream trace from a ?flag? placed southwest of Junction, Texas
............................................................................................................100 
Figure 5.6 ? Screen captures of a storm event moving over the Llano Basin102 
Figure 5.7 ? Time series query performance under various conditions......105 
Figure 5.8 ? Arc Hydro toolbar...................................................................107 
Figure 5.9 ? Progress Bar............................................................................108 
viii
Figure 5.10 ? Prototype ?Transfer Flow Direction? GUI...........................110 
Figure 5.11 ? ArcMap view of the Llano at Junction HEC-HMS Basin....111 
Figure 5.12 ? ArcMap view of initial loss values for Llano at Junction Basin112 
Figure 5.13 ? ArcMap view of Snyder peaking times values for Llano at 
Junction Basin....................................................................................112 
Figure 5.14 ? A query of a paired data routing table for a reach in the Llano at 
Junction Basin....................................................................................113 
Figure 5.15 ? Query of time series data for a particular HMS Subbasin....114 
Figure 5.16 ? Time series animation of IDM data (1 hour time step) ........115 
Figure 5.17 ? Comparison of Halff floodplain (red line) to research results (blue 
polygon) at different scales, Lake Travis...........................................117 
Figure 5.18 ? Comparison of different floodplain maps at large scale, Lake 
Travis .................................................................................................118 
Figure 5.19 ? Flood statistics and a portion of the inundated structures list for 
the 2-year flood of the Colorado River at Bastrop.............................119 
Figure 5.20 ? 3-D visualization of inundated structures on Lake Travis....120 
 ix
Chapter 1:  Introduction 
1.1 BACKGROUND 
A geographic information system (GIS) provides an effective method for 
managing, viewing, and editing spatial data.  Hydrology is the study of the movement of 
water throughout the Earth, and it is generally spatial in nature.  Therefore, the merger of 
hydrology with GIS is a natural goal for many watershed analysts.  Over the past decade, 
this goal has been proven both possible and effective for a variety of analyses including 
flood studies, water quality studies, and water rights management.   
A ?hydrologic information system? results from the synthesis of time series, 
geospatial data (GIS data), and hydrologic modeling and analysis (Maidment, 2002), as 
illustrated in Figure 1.1.  It is important to realize that such a system contains two 
different types of models.  A ?data model? is used to store important geospatial and time 
series data within a standardized framework; and a ?computational model? (or 
?simulation model?) contains the algorithms necessary to simulate natural processes.  
Therefore, a hydrologic information system combines the predictive capabilities of a 
computational model with the data management capabilities of a data model.   
Arc Hydro, which was developed by the Center for Research in Water Resources 
(CRWR) at the University of Texas in Austin, is a data model for storing general 
hydrologic geospatial and time series data.  A standardized data model is important 
because it allows for interoperability between various water agencies, and it provides a 
framework around which for future computational programs can be designed.  Therefore, 
many water agencies are now interested in converting their water resources data into an 
Arc Hydro compliant form.  
 
 1
 
Figure 1.1 ? Hydrologic Modeling System (Maidment, 2002) 
The Lower Colorado River Authority is the agency that regulates the Texas 
Colorado River System from Lake O.H. Ivie to the Gulf coast, as shown in Figure 1.2.  
One of the organization?s primary responsibilities is management of the Colorado River 
floodplain.  This responsibility includes determining the flood risk associated with 
various structures located along the river.  The LCRA also attempts to minimize flood 
damages during storm events through the careful operation of the river system?s dams 
and reservoirs.  To assist in this work, the LCRA maintains an extensive collection of 
geospatial and hydrologic time series data for the river basin.  The LCRA also maintains 
a set of hydraulic and hydrologic computational models (H&H models) that help to 
predict the river?s water surface elevation profile during rain events.   
 2
 
Figure 1.2 ? Lower Colorado River site map (adapted from LCRA website) 
1.2 STUDY OBJECTIVES 
The purpose of this research was to determine how Arc Hydro could be applied to 
the hydrologic data and computational models of the LCRA.  Through a collaborative 
effort, CRWR and LCRA developed a series of project objectives that have helped guide 
this research.  A summary of these objectives is as follows: 
1. Review of the LCRA?s existing computational models and data.   
2. Creation of a prototype Arc Hydro data model for the Llano River Watershed 
(a tributary area of the Colorado River Basin), including relevant time series 
data. 
3. Development of an ?Interface Data Model? that will act as an interface 
between Arc Hydro and the hydrologic program, HEC-HMS.   
 3
4. Development of a system for generating floodplain maps and determining 
inundated structures based on H&H model results.   
The purpose of item #1 is to provide an inventory of the LCRA?s river operations 
data and models and how they work together.  Item #2, the Arc Hydro data model, is 
important because it provides an organized, connected, and standardized container for the 
LCRA?s hydrologic data.  Item #3 creates an archive for storing and viewing the data 
used in a hydrologic computational program, and it provides a platform for future 
integration of hydrologic modeling with GIS.  Finally, item #4 gives the LCRA an 
optimized system for comparing the results of different HEC-RAS models, and thus 
provides a method for comparing different flood control alternatives. 
1.3 THESIS OUTLINE 
Chapter 2 is a literature review that covers the Arc Hydro data model, flood 
damage analyses, and other applications involving GIS and water resources.  Chapter 3 
includes an overview of the existing data and models considered throughout the course of 
this project.  In effect, Chapter 3 accomplishes the first of the project objectives (as listed 
in the previous section).  Chapter 4 presents the methodologies used to develop objectives 
two through four.  Chapter 5 discusses the results of this research.  Chapter 6 includes 
conclusions and recommendations for future work.   
 4
 
Chapter 2:  Literature Review 
As discussed in the last chapter, this research involves the connection of 
hydrologic data and models to GIS.  A significant amount of past effort has been put 
forth to accomplish this goal.  This chapter is primarily a review of such efforts, 
including an introduction to the Arc Hydro data model.  The chapter also briefly 
discusses methods used for calculating economic damages that result from flooding 
events. 
2.1 ARC HYDRO DATA MODEL 
The Arc Hydro data model was introduced to the public in 2002.  It is the result of 
three years of development by Dr. David Maidment?s research team at the Center for 
Research in Water Resources (CRWR), The University of Texas at Austin.  The 
Environmental Systems Research Institute (ESRI), maker of the ArcGIS software 
package, has also played a role in the Arc Hydro design.  Throughout the development 
process, the Arc Hydro concept has held the interest of many public and private water-
related organizations.  Now that the Arc Hydro data model is available, these 
organizations would like to employ the model for their benefit.  To assist these 
organizations in implementing the data model, the book ?Arc Hydro, GIS for Water 
Resources? was published by ESRI in 2002. 
Arc Hydro is a geospatial and temporal GIS data model that can be used to 
maintain the water resources data necessary for hydrologic modeling and analysis 
(Maidment 2002).  In general, Arc Hydro was created with three primary components: 
1. A standardized format for storing geospatial and temporal hydrologic data. 
 5
2. Logical data relationships among geospatial features based on hydrologic 
principles 
3. A set of tools for creating, manipulating, and viewing hydrologic data. 
The first two of these components were created using the Unified Modeling 
Language (UML) to design a standard ?Arc Hydro? geodatabase.  The Arc Hydro 
geodatabase includes a number of tables that represent different hydrologic themes.  
Tables that represent spatial entities, such as watersheds and monitoring points, are called 
?feature classes?.  Tables that represent non-spatial data, such as time series, are called 
?object classes?.  Inside these tables (or ?classes?) are standardized field names such as 
?JunctionID?, ?HydroCode?, and ?FlowDir?.  Fields with an ?ID? or ?Code? suffix are 
used for identifying individual hydrologic objects. Fields with the ?ID? suffix are integer 
fields, and fields with the ?Code? suffix are text fields.  In addition to identification 
fields, there are also fields that store hydrologic characteristics, such as ?FlowDir? (which 
stores the direction of flow in a stream line) and ?AreaSqKm? (which stores the area of a 
watershed). 
Arc Hydro?s data relationships were also created using UML.  These relationships 
are used to associate hydrologicaly related entities.  For instance, a watershed may be 
related to an outlet point (to which the watershed drains); and a stream gage may be 
related to a point along a river; and a set of precipitation records may be related to a rain 
gaging station.  With these relationships established, the user may easily query related 
hydrologic information. 
The third component of Arc Hydro is the Arc Hydro Toolset, which runs within 
the ArcMap environment.  This toolset can be used for a number of hydrologic 
processing routines including raster processing and the assignment of feature attributes.  
 6
Furthermore, Arc Hydro makes use of a number of other ArcGIS toolsets including 
ESRI?s Spatial Analyst and Network Analyst. 
GIS Data Types Used by the Arc Hydro Data Model 
The two most common types of GIS data are raster and vector.  Vector data 
include points, lines, and polygons and their associated attributes.  Vector data is ideal for 
representing streams, watersheds, and monitoring points.  The Arc Hydro is made up 
almost entirely of feature classes, which are vector data.  Rasters are  gridded data, where 
each cell of a raster grid possesses one unique value.  Raster data are not typically 
considered to be a part of the Arc Hydro data model.  Raster data can, however, be used 
to generate vector data used by the Arc Hydro model.  In fact, much of the Arc Hydro 
toolset focuses on using land surface elevation rasters to generate streams and catchments 
for the data model. 
Three Versions of the Arc Hydro Geodatabase 
 To accommodate the varying demands of Arc Hydro users, three different 
versions of the Arc Hydro Geodatabase were created.  They contain many of the same 
tables and field names, and only vary in their level of complexity.  They are described 
below: 
1. Arc Hydro Framework ? contains only the feature classes that are necessary 
to create a useable Arc Hydro flow network (watersheds, rivers, junctions, 
waterbodies, and monitoring points). 
2. Arc Hydro Framework with Time Series ? contains all of the classes found 
in the Arc Hydro Framework, plus tables for storing time series data. 
 7
3. Arc Hydro Full Model ? contains all of the classes found in the Arc Hydro 
Framework with Time Series, plus additional classes that describe river 
schematics, channels, and flow exchange points. 
These three versions are not rigid; they can be modified to fit the needs of 
individual organizations. This research involved the ?Arc Hydro Framework with Time 
Series? data model.  However, the concepts discussed in this report apply equally to all 
three models.  A diagram of the Arc Hydro Framework with Time Series is shown in 
Figure 2.1. 
 
 8
 
            Figure 2.1 ? Arc Hydro Framework with Time Series (Maidment, 2002) 
 9
2.2 OTHER GIS APPLICATIONS FOR HYDROLOGY 
While Arc Hydro has helped to formalize the concepts essential to connecting 
GIS with hydrologic modeling, it is not the beginning or the end of this development 
process.  For instance, it should be emphasized that Arc Hydro is a data model, and 
further development is generally required to connect it with computational (simulation) 
models: 
Arc Hydro is a data structure that supports hydrologic simulation models, but it is 
not itself a simulation model.  Hydrologic simulation is accomplished by 
exchanging data between Arc Hydro and an independent hydrologic model, by 
constructing a simulation model attached to Arc Hydro using a dynamic linked 
library, or by customizing the behavior of Arc Hydro objects. (Maidment, 2002) 
How tightly to couple GIS and computational models is an important 
consideration when designing a hydrologic information system.  A loose coupling means 
that the necessary hydrologic data is stored both by the GIS and the computational model, 
and that the data must be passed back and forth between the two.  A tight coupling means 
that the data for the GIS and computational model share the same database, and possibly 
even the same ?manipulation framework? (McKinney and Cai, 2002). 
A tightly coupled hydrologic information system is advantageous because it 
requires less data transfer, and it can be more easily managed by a single user interface 
such as ArcMap.  In such a system, the geographic information system may: (1) prepare 
the necessary computational model data, (2) have the ability to compile this data into 
model input files, (3) run the computational model, and (4) present the models results 
(McKinney and Cai, 2002). 
Some computational models, however, are of such a complex design, that it may 
prove cumbersome to tightly couple them to a GIS.  In these cases, the GIS is often only 
used for preprocessing or post processing of the data required by the computational 
model.  In the case of GIS preprocessing, the modeling data is created as part of a GIS 
 10
database, and then transferred to a computational model database.  CRWR-PREPRO was 
one of the first systems developed to perform hydrologic preprocessing.  This GIS 
program, which was the predecessor of HEC-GeoHMS, could derive input files for the 
hydrologic modeling program, HEC-HMS (Hellweger, 1999).   
More recently, a number of specialized data models have been developed around 
the more general Arc Hydro data model.  These data models are specific to particular 
computational programs, but were developed using the Arc Hydro model as a template.  
Thus, these data models often share data structures and naming conventions similar to 
that of Arc Hydro.  One such model, BASINS Hydro, was designed to store the data 
found in the Environmental Protection Agency?s Better Assessment Science Integrating 
Point and Nonpoint Source (BASINS) program.  This data model was designed primarily 
for viewing and analyzing the data found in the BASINS database.  This project also 
presented the concept of creating a data model that incorporates two or more 
geodatabases, so that the data may be handled more efficiently (Schneider, 2002). 
A GIS preprocessor and data model for the Texas Water Rights Analysis Package 
(WRAP) has also been developed.  The WRAP Hydro data model was designed based on 
Arc Hydro principles and stores the data necessary to run the WRAP program.  Also of 
interest, the WRAP Hydro model makes use of the data and tools included in the more 
general Arc Hydro model (Gopolan, 2003). 
2.3 FLOOD DAMAGE STUDIES 
A long-term goal of this research is to find ways of making flood mapping and 
damage analysis more efficient, and possibly even more accurate.  Over the past decade, 
the use of GIS in flood mapping applications has greatly increased, but GIS methods for 
determining flood damages (economic dagames) are still not well established. The 
existing methods used to determine flood damages are based on procedures developed by 
 11
the U.S. Army Corps of Engineers.  These procedures are quite elaborate, and a thorough 
review of them would be beyond the scope of this research.  Nonetheless, it is interesting 
to examine how a GIS-based system could offer advantages over the traditional methods 
of damage analysis. 
In 2000, the National Research Council (NRC) published ?Risk Analysis and 
Uncertainty in Flood Damage Reduction Studies?.  Among the material in this report is 
an outline of the procedures used by the U.S. Army Corps of Engineers when estimating 
flood damages.  The report also discusses the limitations in these procedures and makes 
recommendations regarding how they might be improved.  Under the current system, the 
Corps aggregates structures and damages over ?damage reaches?.  In this system, a graph 
relating total economic damage to river stage is calculated for each reach.  According to 
the NRC report, aggregating the structures in this way can lead to inaccuracies when 
considering the uncertainties associated with various flood control alternatives.  
Therefore, the NRC report recommends that damage analyses be conducted on a 
structure-by-structure basis.  Similarly, the report recommends that levee performance 
should be evaluated as a spatially distributed system. 
Using GIS to automate the flood map production process has been found to have 
many advantages over the traditional, manual methods of floodplain delineation.  
Automated delineation procedures can potentially improve map accuracy, as well as the 
speed of map generation (Noman, 2001).  GIS floodplain delineation requires two 
primary inputs: a land surface layer and a water surface layer.  Inundation occurs 
wherever the elevation of the water surface layer exceeds the elevation of the land 
surface.  To ensure quality flood maps, the land surface data must be of sufficient 
accuracy and resolution.  Triangular irregular networks (TINs) and grids (rasters) are the 
two primary methods for representing land surfaces.  TINs are more effective for 
 12
capturing small details in the land surface, however, rasters can usually be processed at a 
faster rate.  Care must also be taken to ensure that the generated water surface layer 
(interpolated from hydraulic model results) is an accurate representation of flood 
conditions.  In general, the further removed from the centerline of the hydraulic model 
(assuming a one-dimensional model), the more difficult it is to predict water surface 
elevations.  Water surface layers generated from cross sections with assigned flood 
elevations tend to be more accurate than water surface layers generated from individual 
flood point elevations.  Also, in many cases, it is important to account for natural and 
man-made barriers to water flow when determining the water surface layer (Noman, 
2001). 
2.4 SUMMARY OF EXISTING RESEARCH 
Arc Hydro has the capability to store the general data that describes a hydrologic 
system.  In addition to Arc Hydro, a number of more specific GIS data models have been 
developed to store the contents of particular hydrologic computational programs.  These 
data models have demonstrated the effectiveness of managing and analyzing data from 
within the GIS environment.  Furthermore, many of these data models have associated 
tools for the creation and processing of relevant hydrologic data.  However, the existing 
data models do not, generally, provide a thorough coupling of GIS with computational 
modeling.  Most of the existing data models do not store all of the data required to run 
their associated computational models, and little effort has been put forth to create a 
system that can continually pass data back and forth between the computational model 
and GIS. 
 
 13
 
Chapter 3:  Data and Models Review 
The previous chapters discussed how GIS data and computational models may be 
synthesized into hydrologic information systems.  This chapter discusses the details of 
the data and models used at the LCRA.  Extra attention is given to those data and models 
that were central to the objectives of this research. 
3.1 GIS DATA 
The Lower Colorado River Authority is a large organization with considerable 
data needs.  The LCRA runs the Colorado River dams, a series of power plants, 
transmission lines, and local water systems.  Because of these responsibilities, 
maintaining a set of quality GIS data is very important to the organization.  Of particular 
interest to this project is the LCRA?s existing hydrologic data. 
Much of the LCRA?s GIS data resides on a Microsoft SQL Server that is known 
to its users as ?LCRA World?.  The LCRA World stores over one hundred GIS files, 
many of which are related to hydrology.  These data include rivers, lakes, bridges, dams, 
gaging stations, watersheds, high water marks, and aquifers.  A complete listing of files 
stored in the ?LCRA World? is included in Appendix A. 
In addition to the LCRA World, the LCRA maintains a considerable amount of 
GIS data that are specific to particular projects or computational models.  Often, these 
data are maintained by particular individuals or departments within the LCRA.  Since 
these data are not available on the LCRA World, only certain employees have access to 
them.  The GIS results of hydrology and hydraulic studies are typically stored in this 
manner.  Model-specific data particularly relevant to this research project is discussed in 
greater detail in Chapter 4. 
 14
3.2 HYDROLOGIC AND HYDRAULIC MODELS  
A primary mission of the LCRA?s river modeling staff is to perform flood 
simulations.  These simulations can either be run using real-time or historical (archived) 
data.  Real-time data are used when modeling current storm events.  Historical data are 
used for calibration and to determine statistical flood information, such as 100-year 
floodplain elevations.  In either case, it is computer-based hydrology and hydraulic 
(H&H) models that are used to calculate the results. 
Typically, separate software programs are used for hydrology and hydraulics.  
The hydrology program is run first, and calculates stream flows based on precipitation 
and watershed characteristics.  The hydraulic program is run second, and calculates 
floodplain elevations based on stream flows (typically calculated by the hydrology 
program) and river channel characteristics. 
For real-time flood modeling, the LCRA uses an automated set of US Army 
Corps of Engineers, Hydraulic Engineering Center (HEC) modeling programs.  The 
hydrology program is HEC1 and the hydraulic program is UNET.  Both of these 
programs are relatively old, and are no longer under development at the HEC.  Because 
speed is an important factor for real-time modeling, the LCRA contracted with a private 
consulting firm to automate and build a user-friendly interface for these programs.  The 
resulting application is called the Catchment Forecasting System (CFS).   
The LCRA plans to replace CFS with a more modern system in the near future.  
The HEC?s Corps Water Management System (CWMS) is the program the LCRA has 
selected for this purpose.  This system was developed by the HEC specifically for use at 
the Corps? district and division offices (HEC, 2003).  The system includes programs for 
hydrology, reservoir operation, river channel hydraulics, and flood analysis (but not flood 
 15
mapping).  More recently, the Corps has attempted to market this system to large water 
management agencies such as the LCRA.   
For historic flood modeling, the LCRA uses a set of HEC models developed by 
the consulting firm Halff & Associates.  CRWR also played a role in this project by 
delineating a set of watersheds for use in the hydrology model (Stone, 2001).  The 
hydrology program is HEC-HMS, and the hydraulic program is HEC-RAS.  After 
calibrating these models, Halff and Associates used them to perform an extensive review 
of floodplain elevations resulting from various return-frequency storms (Halff, 2002).  
Figure 3.1 shows the spatial extent of the LCRA/Halff modeling effort.  It is anticipated 
that these models will also be incorporated into the LCRA?s new flood forecasting 
system (CWMS). 
 
 
 Figure 3.1 ? LCRA/Halff H&H modeling effort 
 16
3.3 INTRODUCTION TO HEC-HMS 
 The HEC?s Hydrologic Modeling System (or HMS for short) was very central to 
this research effort, and a thorough understanding of this program was essential.  
Generally, the input to HMS is precipitation, and the output is flow.  This conversion 
takes place using a model of the river basin in question.  The primary basin elements are 
subbasins (watersheds) and reaches (streams).  Precipitation is converted to run-off over 
the subbasins, and the run-off is then routed through the reaches, providing storm flows at 
locations along the stream network. 
 HMS is a somewhat complex program that provides many options for calculating 
run-off and flows.  These options include a variety of different methods for determining 
base flows, loss rates, transforms, and routing.  In addition to this, there are a number of 
methods available for distributing precipitation, and HMS can perform these calculations 
over gridded (spatially distributed) or lumped (catchment) basins. Furthermore, a given 
HMS project can store information for multiple storm events and multiple basins.  And 
finally, HMS has an elaborate scenario-control structure capable of keeping track of all of 
these options. 
 A typical HMS project includes a number of data files and control files.  With the 
exception of time series and paired data, most HMS data are stored in text files, which 
can be easily viewed and edited by the user (however, the manual editing of text files is 
not necessary since HMS comes with a standard Windows graphical user interface 
(GUI)).  Time series and paired data are stored in the HEC?s Data Storage System (DSS).  
This is a binary system, and it is not easily edited without the aid of specialized HEC 
software.  Nonetheless, it is an effective storage system because it is compact in size and 
allows quick data queries.  The most common and important HMS file types are shown in 
Table 3.1.   
 17
The DSS file is the central repository for both input and output data.  Figure 3.2, 
which was created as part of this project, presents a conceptual view of the HMS file 
structure and also shows the flow of DSS data through HMS.  The DSS data used in a 
given scenario (run) are selected based on the control and meteorological files, and then 
processed using the parameters found in the basin file.  The results of the run (flow 
hydrographs) are returned to the DSS file for storage. 
 
File Extension Files per project Description 
      
hms 1 list of basin, met, and control files 
   
dss 1 or more time series and paired data 
dsc 1 or more catalog of dss file 
   
gage 1 defines all project gages 
run 1 defines all project run scenarios 
   
control 1 per storm event defines timing information for event 
basin 1 per basin model basin model information 
  
met 1 per met model meteorological model information 
            Table 3.1:  Common HMS file types and descriptions 
  
 18
.met
.hms
.basin
.basin
.met
.control
.control
.dss
HMS Data Flow Diagram
.run
.log
.out
.gage
.log
A list of  rain
gages referenced
to DSS
Distributes
gaged
rainfall over
subbasins
Timeseries
and Paired
Values
Routing Data (Input)
Rainfall Data (Input)
The basin's
physical
characteristics
Selects start
and end
times for run
A list of scenarios - each
specifying  a specific .basin,
.met, and .control file
List of input & output
DSS from last run
Status of most recent run,
one file for every scenario
listed under .run file
Calculated Flows (Output)
.dsc
(catalog)
 
Figure 3.2 ? HEC-HMS flow diagram ? data storage files in blue, control files in green 
HEC-GeoHMS 
HEC-GeoHMS is the HEC?s system for GIS preprocessing of HEC-HMS input 
data.  The current version of HEC-GeoHMS is limited because it only works with the 
older (though still used) ESRI ArcView 3.2 software.  However, a newer version of 
HEC-GeoHMS is currently under development.  GeoHMS uses shapefile and raster input 
data to generate HMS input files, including a base map, lumped or distributed (gridded) 
basin model, and a grid cell parameter file.  This program is not typically used at the 
LCRA. 
 19
3.4 INTRODUCTION TO HEC-RAS 
The HEC?s River Analysis System (HEC-RAS or RAS) is not as central to this 
research as HEC-HMS, but it is still important to have an understanding of how the 
program operates.  RAS calculates river stage elevations based on flow data and river 
channel characteristics.  Flow data can be obtained from river gages or from hydrologic 
program results.  Channel data are defined in terms of cross sections and are typically 
generated from survey or digital terrain data.  The RAS file structure is quite complex, 
but like HMS, all file manipulation is typically handled through the program?s GUI.  Like 
HMS, time series data are stored in DSS files, though in a somewhat different format.  
HEC-RAS model results can be exported using a number of methods, including an SDF 
text file, designed specifically for GIS applications.  This file includes the location, 
geometry, and calculated water surface elevation for each RAS cross section. 
HEC-GeoRAS 
HEC-GeoRAS is the GIS processing program for HEC-RAS.  As with HEC-
GeoHMS, the current version of HEC-GeoRAS only works with the older ESRI ArcView 
software.  However, an ArcGIS beta version, under development at ESRI, has been 
released to CRWR for testing.  The HEC-GeoRAS system is used as both a preprocessor 
and a postprocessor.  As a preprocessor, HEC-GeoRAS is used to calculate river channel 
geometry data.  As a postprocessor, the program calculates flood inundation maps.  This 
program is sometimes used at the LCRA for floodplain map generation. 
3.5 TIME SERIES DATA 
LCRA Hydromet System 
For H&H modeling, the primary time series inputs are stage, stream flow, and 
rainfall data.  At the LCRA, these data are collected though the ?Hydromet? system.  The 
 20
term ?Hydromet system? encompasses many things.  First of all, the Hydromet is a series 
of gages that measure stream flow, rainfall, and other data throughout the Lower 
Colorado River Basin.  Second, the Hydromet includes a system that collects and 
transfers (polls) these data.  Finally, ?Hydromet? is also the name of the database where 
these data ultimately reside. 
Data are polled from the gaging stations approximately once every hour under 
normal conditions, once every half-hour during storm events, and manually as needed.  
Once the data are polled, they are transferred into the Hydromet database.  In this 
database, every poll is recorded as a unique time series record.  The record includes the 
date and time of the poll, the ID of the sensor (gage) that was polled, the data type, the 
data?s source, a comment, and two values.  Having two values is important for the 
LCRA?s stream flow and rainfall data.  A stream flow record stores a stage value and 
flow value (based on a rating curve), and a rainfall record stores a counter value and an 
incremental rainfall value (rainfall is calculated based on the number of times a tiny 
scoop fills and tips within a tipping-bucket rain gage).   
The structure of the Hydromet database is somewhat complex, and it is 
diagrammed in Appendix B.  The primary time series table is called ?Datachron?, which 
contains a complete history of Hydromet records.  In addition to Datachron, there are a 
series of smaller time series tables that store records over short time periods of specific 
interest (i.e. the table ?Data_Recent? stores the latest two weeks of Hydromet records).  
Because of their limited size, these small time series tables can be queried and 
manipulated more quickly than the larger ?Datachron? table.  Records in the time series 
tables are related to a ?SensorDef? table that stores information about the instrument that 
took the reading.  The SensorDef table is related to a ?Site? table that stores information 
about the location where the sensor (instrument) is located.  Datachron, SensorDef, and 
 21
Site make up the primary Hydromet time series data structure.  However, there are other 
miscellaneous tables, most of which are shown in the Hydromet diagram located in 
Appendix B.  It is important to note, however, that the LCRA does not fully populate this 
database.  Many fields are left empty.  According to Chris Riley, an LCRA hydrologist, 
(personal communication, 2003) some of these empty fields may be used in the future.  
Also, however, the LCRA is currently considering upgrading the Hydromet, and this 
could result in a different database structure.   
For the purposes of H&H modeling, it is best to have regular interval time series 
data.  This is not accomplished in the Datachron table because the original data polls do 
not occur exactly at even one-hour intervals.  Therefore, regular one-hour interval data 
must be calculated through interpolation, and stored in a separate location from the raw 
data.  In the Hydromet system, the ?Interval? table is used to store this regular data.  
In addition to Hydromet gages, the LCRA also makes use of radar-generated 
rainfall maps.  Although these maps are effective for viewing the spatial distribution of 
rainfall, they are not always accurate in the total volume of rainfall they predict.  
Therefore, radar generated rainfall is usually calibrated using physical rainfall gages.  The 
LCRA has out-sourced the radar data collection and calibration process to a private firm 
? the NEXRAIN Corporation.  NEXRAIN calibrates the radar rainfall maps based on 
data they receive real-time (one-hour time interval) from the LCRA?s Hydromet rainfall 
gage system.  According to LCRA engineer, Daniel Yates, about twenty minutes elapse 
between the time the LCRA sends their gaged data to NEXRAIN, and the time the 
calibrated rainfall data are sent back to the LCRA (personal communication, 2003).   
NEXRAIN stores radar-generated rainfall data on a 2km x 2km grid, but this is 
not directly applicable to the LCRA?s ?lumped? hydrologic model (the HEC1 component 
of CFS).  To accommodate this difference, NEXRAIN lumps the gridded rainfall data 
 22
onto the LCRA?s HEC1 watersheds.  After being sent to the LCRA, these lumped rainfall 
data are stored as ?virtual rain gages? in the Interval table.  The Interval table is then used 
to drive the CFS real-time flood-forecasting model.  An example of lumping gridded 
rainfall data onto watersheds is shown in the Figure 3.3. 
 
 
              Figure 3.3 ? Transferring gridded rainfall data to watersheds 
 In general, the LCRA?s river modeling engineers rely on a continuous feed of 
rainfall and stream flow data to drive their real-time models.  The results of their 
modeling efforts include reservoir elevations, stream stages, and flows.  A diagram, 
detailing this flow of data, is included in Appendix C. 
LCRA Water Quality Data 
 Although hydrologic and hydraulic modeling data are the primary focus of this 
project, water quality data have also been examined.  One of the reasons for this 
examination is that the Arc Hydro data model may eventually be used not only by the 
river modeling department, but by the entire LCRA.  Other divisions of the LCRA that 
have an interest in Arc Hydro include the water resources management group and the 
water quality management group. 
 23
The LCRA began collecting water quality data as a service to the Texas 
Commission on Environmental Quality (TCEQ).  By doing this, the LCRA agreed to 
follow the TCEQ format for archiving water quality data, which is diagrammed in 
Appendix D.  The LCRA also uses these data to perform water quality modeling 
throughout the basin.  However, unlike the CFS H&H system, the water quality models 
do not pull data directly from a database.  Instead, the data are manually queried and 
exported from the water quality database in the form of flat-files (text files).  The flat-file 
often has to be modified into a format that is acceptable to the water quality modeling 
program.   
 24
 
    Chapter 4:  Methodology 
The previous three chapters covered the background of this research project.  This 
chapter discusses the methodologies used to accomplish the project?s objectives.  There 
are three primary sections in this chapter: (1) Arc Hydro Framework with Time Series 
Development, (2) Interface Data Model Development, and (3) Flood Damage Evaluation 
System Development. 
4.1 POPULATING THE ARC HYDRO FRAMEWORK 
Building an Arc Hydro data model requires the gathering, compiling, and 
modifying of significant amounts of data, often from unrelated sources.  For this project 
the data discussed in Chapter 3 were the primary data used in the Arc Hydro model.   
During the development, these data were modified and related to each other to form a 
complete and connected picture of a prototype river basin.   
4.1.1 Llano River Background Information 
To determine the applicability of the Arc Hydro data model to the Lower 
Colorado River basin, it was determined that a pilot project should be conducted on a 
portion of this basin.  The rational for selecting a portion of the basin, and not the basin as 
a whole, was that work on a smaller dataset could be performed more quickly, allowing 
more time to test different design alternatives.  Furthermore, the procedures and results 
developed by the pilot project can be used as a guide when applying Arc Hydro to the 
entire Lower Colorado River Basin. 
The Llano River Basin was chosen for this pilot project because it is a well-
known, moderately sized tributary of the Colorado River System.  The north and south 
branches of the Llano River begin in the central Texas hill country, about 45 miles (72 
 25
km) west of the town of Junction.  At Junction, the two branches merge together into one 
river.  From Junction, the river continues to wind its way east-northeast, until it outlets 
into the Colorado River just upstream of Lake LBJ.  The basin is roughly rectangular, and 
is approximately 125 miles long by 40 miles wide (200 km x 65 km).  A map of the basin 
is shown in Figure 4.1.   
The Llano River is known for the rapid rise of its waters during storm events.  
During such events, water quickly runs off of the Llano?s hard, rocky watershed, making 
the river a challenge to both monitor and to control.  In the summer of 1997 a storm hit 
the Llano causing the river to surge to over 300,000 cfs, a very impressive event, 
considering the average flow for the previous year, 1996, was only 70 cfs (LCRA, 1998). 
Typically, the floodwaters are not subdued until they enter the Highland Lakes.  During 
the 1997 flood, many homes along the Llano River, Pedernales River, Colorado River, 
and Lake Travis were flooded, but fortunately, no lives were lost. 
 
 26
 
 
Figure 4.1 ? Map of the Llano River Basin 
 27
H&H Models for the Llano River Basin 
The Llano River is part of the LCRA?s CFS real-time flood model.  The CFS 
system includes a simple hydrologic model for the entire Llano Basin.  CFS does not, 
however, include a hydraulic model for the entire Llano River.  Only a small stretch of 
the river (from the City of Llano to the confluence with the Colorado River) is modeled 
with UNET.  This means that flows can be calculated along the entire Llano River, but 
flood elevations can only be calculated downstream of the City of Llano. 
As discussed in Chapter 3, the study by Halff & Associates has provided the 
LCRA with a new set of H&H models.  The Halff hydrologic model for the Llano Basin 
is much more refined than the CFS hydrologic model.  However, as with the CFS system, 
the Halff system provides no comprehensive hydraulic model for the Llano River.  
According to Daniel Yates, a LCRA river operations engineer, (personal communication, 
2003) there is no comprehensive hydraulic model for the Llano River currently available.  
The existing UNET model covers only a fraction of the Llano River and it is not very 
sophisticated (it uses eight-point cross sections).  The creation of a more complete model 
is, however, currently under consideration at the LCRA.   
4.1.2 Arc Hydro Raster Processing 
 Raster processing is an optional, but common first step in Arc Hydro data model 
development.  As discussed in Chapter 2, raster data can be used to generate vector data 
essential for the Arc Hydro model.  The raster shown in Figure 4.2 is a digital elevation 
model (DEM) for the Llano River basin.  This model was created from existing raster 
data for the state of Texas, available at CRWR.  The cell size is 30-meter. 
 
 28
 
Figure 4.2 ? DEM of the Llano River Basin 
Raster Processing 
The theory behind the raster development process has been well documented in a 
number of past reports (Stone, 2001), and the tools needed for the process are all 
available within the Arc Hydro toolset.  Most of these tools start with an existing raster, 
perform an algorithm on the raster, and generate a new raster that contains the algorithm 
results.  A summary of the raster processing tools used for this project is included in the 
following list.  An example of raster-derived vector data for the Llano River basin is 
shown in Figure 4.3.  
1.  DEM Reconditioning ? modifies the raster to more closely match a set of 
vector streams.   
2. Fill Sinks ? modifies the raster by filling pits in the landscape.  Pits are a 
problem because all cells must be able to drain to the basin?s outlet. 
3. Flow Direction ? calculates the direction that water will flow from a given 
cell.  The calculation is based on the slopes between adjacent cells. 
 29
4. Flow Accumulation ? calculates the number of cells that are upstream of a 
given cell. 
5. Stream Definition ? determines which cells are ?stream cells?.  Stream cells 
are cells that have a sufficient amount (arbitrarily set) of flow accumulation. 
6. Stream Segmentation ? divides streams into unique segments.  Streams are 
segmented at locations where they intersect. 
7. Catchment Grid Delineation ? determines the watershed of each stream 
segment. 
8. Catchment & Stream Vector Processing ? converts stream segments and 
catchments into vector features (shapes and lines).   
9. Drainage Point Processing ? places drainage points at the intersection of 
streams and catchments. 
 
 
Figure 4.3 ? Vectorized catchments, lines, and points for the Llano River Basin 
Using Raster Derivatives 
Raster derivatives (including vectorized catchments, drainage lines, and points) 
can serve multiple purposes.  All of the derivatives can be used in the Arc Hydro data 
model.  Also, catchments can be used in hydraulic models, such as HEC-HMS, and 
 30
drainage lines can be used as rivers in maps.  A set of the rasters and raster derivatives for 
the Llano River Basin can be found in the CD in the back of this report. 
4.1.3 The Arc Hydro Framework  
Development of the Arc Hydro Framework for the Llano River Basin was a major 
aspect of this research effort.  As discussed in Chapter 2, the Arc Hydro Framework 
provides a spatial data model that describes basic information about the basin, and around 
which H&H models and time series applications may be constructed.  This section covers 
the various steps that were followed in order to create the Arc Hydro Framework.  It 
should be emphasized that the procedure outlined in this section is based on methods 
previously developed by CRWR, but which have been significantly modified by the 
author to provide the fastest and most efficient development procedure for the data under 
consideration.  A tutorial, developed as part of this project is included in Appendix E, and 
gives step-by-step instructions for the framework development process.   
Step 1.  Acquiring Source Data 
 To build a complete Arc Hydro Framework, one must have GIS data for streams, 
waterbodies, watersheds, and monitoring points.  These data can be obtained from a 
number of sources.  The most common sources for these data are probably the USGS and 
EPA.  Local governments and regional water authorities are also often a source for such 
data.  The vectorized results of raster processing could also be used (for this project, the 
raster derivatives discussed in Section 4.1.2 have been included in the Arc Hydro 
geodatabase, but were not incorporated into the Arc Hydro Framework).  Table 4.1 
describes the data used in the Arc Hydro Framework for the Llano Basin. 
 31
 
        
Hydrologic Arc Hydro  Data 
Feature Type Feature Class Data Source Generation 
  Name   Process 
    
Stream HydroEdge National Hydrography Dataset Map digitization 
  
     USGS 1:100,000 scale 
Waterbody Waterbody National Hydrograpy Dataset Map digitization 
  
     USGS 1:100,000 scale 
 
Watershed Watershed CRWR/Halff HMS Watersheds Raster processing
  
     from 30 meter DEM?s 
Monitoring point MonitoringPoint LCRA Hydromet GIS shapefile LCRA survey 
Table 4.1:  Source data for the Llano River Arc Hydro Framework 
Step 2.  Data Preparation 
 Considerable data preparation was required so that the GIS data could be 
effectively loaded into the Arc Hydro Framework.  First, data was organized and 
condensed into single files for each of the feature types listed in the table above.  The 
National Hydrography Dataset (NHD) is divided into separate files for different 
hydrologic regions known as Hydrologic Unit Codes (HUCs).  There are three HUCs in 
the Llano River basin, and so these files were merged together using ArcGIS tools.  It 
was also important to select an appropriate projection for the data.  Albers Equal Area 
was used for this project since it accurately maintains the areas of polygon features.  The 
details of this projection and the relevant geographic coordinate system are included 
below: 
 
Projection: Albers 
Parameters: 
  False_Easting: 1000000.000000 
  False_Northing: 1000000.000000 
  Central_Meridian: -100.000000 
 32
  Standard_Parallel_1: 27.416667 
  Standard_Parallel_2: 34.916667 
  Latitude_Of_Origin: 31.166667 
 
Linear Unit: Meter (1.000000) 
 
Geographic Coordinate System:  
Name: GCS_North_American_1983 
Angular Unit: Degree (0.017453292519943295) 
Prime Meridian: Greenwich (0.000000000000000000) 
Datum: D_North_American_1983 
  Spheroid: GRS_1980 
    Semimajor Axis: 6378137.000000000000000000 
    Semiminor Axis: 6356752.314140356100000000 
    Inverse Flattening: 298.257222101000020000 
Data also needed to be corrected wherever it did not accurately reflect the hydrologic 
reality of the basin under consideration.  For this project, the most common errors were 
missing stream segments, causing certain sections of the NHD river network to be 
unconnected.  
Step 3.  Creating the Arc Hydro Geodatabase 
 As discussed in Chapter 2, all Arc Hydro vector and time series data are stored in 
a geodatabase.  The name of the geodatabase is left to the user?s discretion; for the Llano 
project, it was simply named ?ArcHydro?.  Inside the geodatabase is a series of classes, 
and the most common type of class is a ?feature class?.  Feature classes store the spatial 
(vector) data for the project, and they may be organized into ?feature datasets?.   Feature 
datasets store a common spatial reference frame for a series of feature classes with related 
themes.   In addition to feature classes and datasets, the geodatabase may also include 
relationship classes, networks, and tables, which will be discussed in more detail later in 
this report.  The first data to be loaded into the Llano River geodatabase were the feature 
classes listed in Table 4.1.  Other elements of the Arc Hydro Framework are added in 
 33
later steps.  Figure 4.4 shows an example of the completed Arc Hydro Framework 
geodatabase structure.   
 
 
Figure 4.4 ? The geodatabase structure 
Step 4.  Creating HydroJunctions 
 HydroJunctions are used to mark all points of interest along the stream network 
(HydroEdge feature class).  In the case of the Arc Hydro Framework model, 
HydroJunctions are used to mark waterbody outlets, watershed outlets, and stream 
monitoring locations.  They can be created in a number of ways, but some methods are 
more efficient than others.  For this project, MonitoringPoint features were copied into 
the HydroJunction feature class and snapped to the nearest HydroEdge.  Once created, 
HydroJunctions were related to their associated feature classes (watersheds, waterbodies, 
and monitoring points) through relationship classes.  The Figure 4.5 shows monitoring 
 34
points (located at their surveyed location) and their associated HydroJunctions (located 
exactly on the stream network) for Llano River basin.   
  
 
  Figure 4.5 ? HydroJunctions and MonitoringPoints 
Step 5.  Creating the HydroNetwork 
 Once the HydroEdge and HydroJunction feature classes were built, the creation of 
a HydroNetwork involved two main steps.  The first was the creation of a geometric 
network within ArcCatalog.  This was a simple process, but all HydroEdges had to be 
connected, and all HydroJunctions had to lie directly on HydroEdges for it to function 
properly.  The second step was to set correct flow direction for each HydroEdge in the 
geometric network.  This was not a tedious process, and only a minimal amount of 
manual editing was required to set these directions.  The tutorial includes the details of 
the methods used to set flow directions.  Figure 4.6 shows properly assigned flow 
directions for a section of the Llano River. 
 
 35
 
      Figure 4.6 ? HydroEdges with properly assigned flow directions 
Step 6.  Implementing the ArcHydro Schema  
 As discussed in Chapter 2, the Arc Hydro data model is a standardized database 
format for hydrologic elements.  By this phase in the Arc Hydro development process, 
many of these standardized elements (feature classes and fields) had already been 
created.  Nonetheless, many other elements still had to be added.  This was accomplished 
by applying an Arc Hydro Schema (in this case the ?Arc Hydro Framework with Time 
Series? schema).  The schema automatically checks to see what classes and fields already 
exist, and then creates empty classes and fields for whatever elements do not yet exist.  
These empty fields and classes were filled by methods detailed in the tutorial, as 
discussed in Step 7. 
Step 7.  Assigning Arc Hydro Attribute Values  
 As mentioned in Step 6, the schema created many empty fields within the various 
feature classes.  Some of these fields are necessary in order for the schema relationships 
to be complete.  Other fields are simply informational, such as attribute fields containing 
the areas of the watersheds or the distances HydroJunctions are located from the basin 
 36
outlet.  The Arc Hydro toolset provides methods for filling many of these fields.  These 
methods are described in the tutorial. 
Step 8.  Finishing  
 Upon completion, it was necessary to ?clean up? the geodatabase.  Any fields and 
feature classes that were not required by Arc Hydro and the LCRA were removed.  Table 
4.2 shows the feature classes and fields used in the completed Arc Hydro Framework 
data model.   
 
 37
 
    
Field Description Populated by
        
    
HydroEdge Feature Class   
 Enabled part of network: yes/no ArcGIS/ArcHydro tools 
 HydroID numeric identifier for feature ArcGIS/ArcHydro tools 
 HydroCode text identifier for feature NHD COM_ID 
 ReachCode text identifier for reach NHD RCH_COM_ID 
 Name geographic name NHD common name 
 LengthKm length of edge ArcGIS/ArcHydro tools 
 LengthDown length to basin outlet ArcGIS/ArcHydro tools 
 FlowDir flow direction ArcGIS/ArcHydro tools 
 Ftype type of HydroEdge NHD FTYPE 
 EdgeType type: flowline/shoreline ArcGIS/ArcHydro tools 
    
HydroJunction Feature Class  
 AncillaryRole type of network junction ArcGIS/ArcHydro tools 
 Enabled part of network: yes/no ArcGIS/ArcHydro tools 
 HydroID numeric identifier for feature ArcGIS/ArcHydro tools 
 HydroCode text identifier for feature (empty) 
 NextDownID HydroID for next Junction ArcGIS/ArcHydro tools 
 LengthDown length to basin outlet ArcGIS/ArcHydro tools 
 DrainArea total area draining to point ArcGIS/ArcHydro tools 
 Ftype type of HydroJunction ArcGIS/ArcHydro tools 
    
MonitoringPoint Feature Class  
 HydroID numeric identifier for feature ArcGIS/ArcHydro tools 
 JunctionID related HydroJunction H.ID ArcGIS/ArcHydro tools 
 HydroCode text identifier for feature LCRA Site ID 
 Ftype type of monitoring point LCRA Gage Type 
 Name geographic name LCRA Location N 
 LONG_DD longitude of site LCRA LONG_DD 
 LAT_DD latitude of site LCRA LAT_DD 
 X_COORD state plane horizontal LCRA X_COORD 
 Y_COORD state plane vertical LCRA Y_COORD
    
            Table 4.2: Feature classes in the LCRA Arc Hydro Framework 
(continued on following page) 
 38
 
    
Field Description Populated by
        
    
Waterbody Feature Class   
 HydroID numeric identifier for feature ArcGIS/ArcHydro tools 
 JunctionID related HydroJunction H.ID ArcGIS/ArcHydro tools 
 HydroCode text identifier for feature NHD COM_ID 
 Ftype type of waterbody NHD FTYPE 
 Name geographic name NHD common name 
 AreaSqKm area in squre kilometers ArcGIS/ArcHydro tools 
    
Watershed Feature Class   
 HydroID numeric identifier for feature ArcGIS/ArcHydro tools 
 JunctionID related HydroJunction H.ID ArcGIS/ArcHydro tools 
 HydroCode text identifier for feature HEC-HMS subbasin name 
 DrainID related drainage area H.ID (empty) 
 NextDownID HydroID for next Watershed ArcGIS/ArcHydro tools 
 
AreaSqKm 
 
area in squre kilometers 
 
ArcGIS/ArcHydro tools 
 
     Table 4.2:  Feature classes in the LCRA Arc Hydro Framework (continued) 
HydroID Options  
 HydroID?s are assigned to every feature in the Arc Hydro data model except 
HydroNetwork_Junctions.  The HydroID serves as a unique identifier for each feature 
and is necessary for establishing Arc Hydro?s feature relationships.  The allowable range 
of HydroID values is from 1 to 2,000,000,000.  For this project, HydroID?s were assigned 
as a normal counting series (1,2,3,4?) up to a value of about 2,500.  This assignment 
scheme was very generic, and worked well for this project because of its limited scope.  
However, for larger projects, the user may wish to assign certain ranges of HydroID?s to 
certain features.  For instance, HydroEdges might be assigned a HydroID range of 
1,000,0000 to 1,999,999 and HydroJunctions a range of 2,000,000 to 2,999,999.  Another 
option is to assign HydroID?s based on location.  An example of this would be assigning 
a unique range of HydroID?s to each tributary area in the Lower Colorado River Basin 
 39
(Llano Basin, Pedernales Basin, etc.).   Assigning different areas different ranges of 
HydroID?s allows those areas be easily selected, and to be maintained in separate 
geodatabases.  
4.1.4 Arc Hydro Time Series Development 
Once the Arc Hydro Framework has been completed, features such as 
HydroEdges and MonitoringPoints can be related to timeseries data.  Water quality, flow, 
lake level, and precipitation are all examples of time-varying data that are can be related 
to specific spatial features.  These data are also the primary input and output of many 
hydrologic, hydraulic, water management, and water quality models.  Because of the 
apparent value of such data, a time series component was included in the Arc Hydro data 
model.  This section discusses how that component was utilized for this project. 
Source Data 
 The primary source for time series data was the LCRA?s Hydromet database.  As 
discussed in Chapter 3, this database stores the data collected from a number of gaging 
stations, located throughout the Lower Colorado River Basin.  Of primary interest to this 
project were stage, flow, and precipitation records for the Llano River Basin.  As a test 
case, approximately eleven years of these data (Nov. 1991 - Dec. 2002) were extracted 
from the Hydromet in the form of flat files.  The time interval for this dataset was one 
hour.   
 A second source of time series data was the gridded radar data developed by the 
NEXRAIN Corporation.  NEXRAIN data is collected in 15-minute intervals over a two-
kilometer square grid.  As discussed in Chapter 3, the gridded rainfall is typically lumped 
onto CFS watersheds, and sent to the LCRA in this form (the LCRA does not typically 
receive the gridded version of this data).  The LCRA and CRWR have requested samples 
 40
of the gridded rainfall, though, and the data has been provided in the form of flat files 
(tab or comma delimited).  For this project, there were two gridded NEXRAIN datasets to 
work with.  The first of these covered 10 days in October of 1998.  The coverage area for 
this dataset was the Lower Colorado River Basin (pink area in Figure 4.7).  The second 
dataset covered the entire month of September, 2003, over a large square region of 
central Texas (blue area in Figure 4.7).  Figure 4.8 shows example NEXRAIN flat file.  
Note that time varies horizontally across the file and location varies vertically.  A value is 
recorded for every time-location combination, although most values are zero. 
 
 
Figure 4.7 ? Two NEXRAIN coverage areas 
 41
 
Figure 4.8 ? NEXRAIN flat file for September 3, 2002 
Conversion to the Arc Hydro Format 
 The Hydromet and NEXRAIN data were converted to the standard Arc Hydro 
time series format.  This format consists of two tables, a TSType table and a TimeSeries 
table.  The TSType table stores metadata for the different time series types, including the 
variable measured, the units of measurement, how the data were generated, and other 
descriptors.  The TimeSeries table stores the actual time series values, as well as the 
location of where the time series takes place, the date-time of the measurement, and the 
TSTypeID ? which relates to the TSType table.  Figure 4.9 shows example TimeSeries 
and TSType tables that were created for LCRA Hydromet data.  These time series data 
are related to Hydromet gages (MonitoringPoint features). 
 Conversion of the Hydromet data was a relatively simple process because the 
Hydromet and Arc Hydro time series formats are quite similar.  For both formats, 
 42
generally, every time series value is assigned to a unique record (although, the Hydromet 
can sometimes store two directly related values in the same record ? i.e. stage and flow).  
Conversion of NEXRAIN data was somewhat more complicated because the NEXRAIN 
flat file format, shown in Figure 4.8, is very unlike the Arc Hydro time series format.  A 
Visual Basic program developed at CRWR was used to accomplish this conversion.  The 
Arc Hydro format proved to be an efficient method for storing NEXRAIN data because 
all records with a TSValue of zero could be omitted.  Because of this, the amount of disk 
space saved by using the Arc Hydro format instead of the flat file format varied 
depending upon the number of non-zero rainfall values.  For typical NEXRAIN data that 
includes some rainfall but no major storm events, the Arc Hydro format could result in a 
97% reduction in the required disk space. 
 
TSType Table 
 
TimeSeries Table 
 
     Figure 4.9 ? Example TSType and TimeSeries tables 
 43
Time Series Evaluation Procedure 
To evaluate the effectiveness of the Arc Hydro time series format, goals for time 
series usability had to be established.  These goals were based on the demands a typical 
GIS analyst is likely to put on a time series dataset.  A set of time series functionality 
goals is listed below.  
1. The ability to select from the TimeSeries table based on querying the table?s 
fields (i.e. TSValue > 5) 
2. The ability to query the TimeSeries table through the Arc Hydro relationship 
classes.  (i.e. select the time series values related to a given MonitoringPoint) 
3. The ability to load and delete data from the TimeSeries table. 
4. The ability to map the data over various spatial datasets (time series 
animations). 
Various time series data sets were tested against these four goals.  Limitations in 
performance were discovered under some scenarios.  These results are discussed in 
further detail in Chapter 5. 
 
 
 44
4.1.5 Arc Hydro for Microsoft SQL Server 
Up to this point, the Arc Hydro data model has only been considered in terms of 
the personal database (.mdb), and indeed, the personal database is the most common GIS 
storage container.  The use of personal databases has many advantages.  First of all, 
personal databases may be easily copied and distributed between different users.  Second, 
these geodatabases may be edited using Microsoft Access, with which many users are 
very familiar.  Third, their relatively simple structure, availability, and ease of use means 
that a staff of highly trained database technicians is not required. 
There are, however, two problems with personal databases.  First, only one user 
can access a personal database at a time.  This means that separate copies of a database 
must be created for each user.  With several copies of a database in existence, it is 
difficult to keep track of which contains the most recent and most accurate set of data.  A 
second problem with personal databases is that they are not an efficient way to store large 
quantities of data.  In fact, a personal geodatabase cannot be larger than two gigabytes. 
A relational (or multi-user) database, such as Microsoft SQL Server, is the answer 
to the limitations of personal databases.  In general, a relational database can be accessed 
by a number of independent users through a network system.  Also, relational databases 
can handle datasets of almost unlimited size; which can be particularly beneficial when 
dealing with large time series data sets.  For these reasons, a goal of this project was to 
establish the Arc Hydro data model on the LCRA?s ?Hyperion? SQL Server.   
Implementing the Arc Hydro Framework in SQL Server 
The key to storing GIS data within a relational database is ESRI?s ArcSDE 
(Spatial Data Engine).  ArcSDE sets up a series of tables within the relational database in 
 45
order to maintain GIS-specific data and functions.  According to ESRI, ArcSDE 
accomplishes the following tasks (ESRI website, 2003): 
1.  Provides the infrastructure required to manage multiple users editing the 
same spatial database with long transactions, alternate versions, and history.  
2. Provides the business logic software for not only creating simple geometric 
data, but also technology for supporting advanced GIS data types such as 
images, networks, features with integrated topology and shared geometry, and 
associating these with rules, behavior and other object properties.  
3. Allows GIS data to be directly maintained in the format of "spatial types" 
supported by the DBMS vendors (building on their parallel efforts to develop 
spatial extensions).  
4. Integrates the spatial (geometric) search capability provided by the DBMS 
vendors within the ArcGIS client software applications.  
The primary challenge to working with ArcSDE was the initial setup of the SQL 
Server.  Only directly through the server can geodatabases and users be created.  Users 
must be created with appropriate permission levels that allow or block them from 
viewing, editing, and creating new tables and feature classes.  Someone with expertise in 
servers and ArcSDE is generally required to complete this initial setup.  For this reason, 
the GIS database specialists at the LCRA provided essential assistance to CRWR during 
this part of the research project. 
Once a geodatabase and user permission levels were established on the SQL 
Server, the Arc Hydro Framework data for the Llano River basin were successfully 
transferred into that geodatabase.  This was accomplished through a fairly simple process.  
First, the Llano Basin Arc Hydro Framework was built in a personal geodatabase (see 
Chapter 7).  Second, the Arc Hydro Framework schema was applied to an empty SQL 
 46
Server geodatabase.  Third, using ArcCatalog and ArcMap, data were loaded from the 
completed personal geodatabase into the empty SQL Server geodatabase.   The resulting 
ArcCatalog structure is shown in Figure 4.10.  Note the elaborate naming conventions for 
SDE database connections and feature classes. 
Although Arc Hydro data have been successfully loaded onto the LCRA?s SQL 
Server, there are a few administrative questions that must be answered before such data 
can be used organization-wide.  One question concerns how user permission levels will 
be assigned.  The lowest permission level allows the user to view, but not edit the data.  
A higher level of permission allows the user to edit existing tables (or feature classes) 
within the geodatabase.  The highest level allows the user create new tables, as well as 
edit existing ones. 
 
   Figure 4.10 ? An ArcCatalog view of GIS data on SQL Server 
 47
Another issue involves the question of versioning.  Versioning allows multiple 
users to concurrently edit a geodatabase.  Each editor is assigned their own ?version? of 
the geodatabase.  Each editor?s version records all of the edits that he or she has made to 
the geodatabase.  Eventually, however, in order to make these edits permanent, the edits 
must be incorporated back into the over-all geodatabase (this is termed ?compressing?).  
This raises the question of how often versions should be compressed back into the 
geodatabase, and also, what procedure should be taken if different versions are found to 
have conflicting edits. 
 48
4.2 CREATING AN INTERFACE DATA MODEL (IDM) 
4.2.1 IDM Theory  
 The term ?hydrologic modeling? is meant to include all types of computational, 
water-related modeling efforts including hydraulic, hydrology, water resources, and water 
quality analysis.  Using GIS to aid in hydrologic modeling is not a new concept.  The 
research team at CRWR has pursued this goal for many years.  In fact, the Arc Hydro 
data model is one important step toward reaching this goal.  The concept of connecting 
Arc Hydro to a hydrologic model to form a ?hydrologic information system? was 
illustrated in Figure 1.1. 
To many, Figure 1.1 implies that the Arc Hydro data model can be used as the 
primary data storage system for hydrologic modeling.  However, this is only partially 
true.  Arc Hydro was not designed to store many of the parameters required by 
hydrologic models (i.e. curve number, time of concentration, etc.).  It is possible to 
expand the Arc Hydro data model to store these parameters, but this is only practical for 
simple models.  For more complex hydrologic models, like HEC-HMS, Arc Hydro is not 
an effective method of storing model parameters.   
For more complex hydrologic models, an Interface Data Model (IDM) may be the 
most efficient way to store hydrologic model data within GIS.  An IDM is designed to 
store the parameters and data required for a specific hydrologic modeling program, 
including both input and output time series data.  In addition to this, the goals of an IDM 
are as follows: 
1.  Provide a database capable of storing all model data, so that the data may be 
queried and retrieved efficiently. 
 49
2. Store data in a manner so that they are readily transferable between the 
geodatabase format and the format required by the computational model. 
3. Store the model?s spatial data in a manner that can be easily viewed in 
ArcMap. 
4. Store data in a format compatible with the Arc Hydro naming conventions. 
5. Provide a link between the IDM spatial data and the associated Arc Hydro 
spatial data, thus providing a connection between the IDM and Arc Hydro 
geodatabases.  
6. Provide a data storage structure that is intuitive to the user. 
7. Minimize the size of the geodatabase (in terms of disk space). 
With an IDM, the conceptual image of a hydrologic information system changes, 
as shown in Figure 4.11.  The most important link is between the IDM and the hydrologic 
model.  This link is responsible for the flow of input and output data, as well as the 
modification of model parameters.  The link between the IDM and Arc Hydro is not 
always necessary, but it is advantageous from a data management standpoint.  At CRWR, 
the Arc Hydro data model is used to coordinate data transfer between different 
hydrologic models, making the IDM-Arc Hydro link essential for managing data 
connectivity within GIS (Robayo, 2004).  The link between the IDM and Arc Hydro is 
also important if model results are to be translated back into the Arc Hydro format, for 
use with time series viewing tools. 
 50
 
 
Figure 4.11 ? IDM and hydrologic modeling for the LCRA (adapted from Maidment, 
2002) 
 51
4.2.2 Introduction to Data Model Design 
UML Design 
 Most data models are the result of an intensive design process.  GIS data models 
are typically created using the Unified Modeling Language (UML).  UML is an intuitive 
method of design that does not involve coding, but rather the creation of database 
diagrams.  These diagrams must be created in specialized programs, such as Visio, so that 
they may be transformed into actual database formats (repositories) when finished. 
 Reading a UML diagram can be difficult at first.  Understanding the terminology 
used in these diagrams is the key thing.  It is important to note that many of the terms 
have overlapping definitions.  For instance, a feature class is a type of object class.  A list 
of UML/GIS terminology follows below: 
1. Class ? A database entity, such as a table. 
2. Object ? A record in a table. 
3. Attribute ? A field in a table. 
4. Feature ? A record with spatial data; a ?GIS object?. 
5. Object Class ? A table of records, typically used when referring to a table 
without spatial data. 
6. Feature Class ? An object class with spatial data.   
7. Abstract Class ? Only appears in UML.  It stores a list of fields that apply to 
all tables inheriting from it. 
For an example, consider the UML diagram in Figure 4.12.  This UML would 
create a geodatabase with two feature classes: HMSReach and HMSSubbasin.  As shown 
in the diagram, the HMSReach is a polyline feature class and the HMSSubbasin is a 
polygon feature class.  Also listed inside the feature class elements are attributes (table 
fields) specific to the individual feature classes.  For instance, all HMSSubbasins have an 
 52
?Area? attribute, meaning that there is an ?Area? field in the HMSSubbasin table.  As 
shown, HMSReach features do not have an ?Area? attribute.  Immediately above the two 
feature classes is an abstract class, HMSFeature.  This class will not actually exist within 
the database, but all of the attributes listed in it are inherited by both the HMSSubbasin 
and HMSReach feature class.  Therefore, both HMSSubbasin and HMSReach will have a 
?FeatureID? field.  Above HMSFeature is another abstract class, simply named Feature.  
This abstract class is ESRI-specific, and it assigns a ?shape? field to all classes inheriting 
from it.  Without Feature, HMSReach and HMSSubbasin would not be feature classes, 
instead they would just be regular object classes. 
Figure 4.12 ? Example UML diagram (taken from the HMS IDM) 
 53
Abstract Classes 
 
Feature Classes 
Converting the UML Diagram to a Geodatabase 
When the UML diagram is finished, it is exported as a database repository.  Using 
the schema generation process in ArcCatalog (see Section 4.1.3, Step 6), the repository 
may be applied to any geodatabase.  In this way, the geodatabase will receive all of the 
feature classes, object classes, relationships, etc. that were included in the UML diagram.  
The HMS IDM, as well as the original Arc Hydro data model, were created in this 
fashion. 
4.2.3 An IDM for HEC-HMS  
The ArcGIS Interface Data Model for HEC-HMS (HMS IDM) has a very 
complex design, but this is not unexpected since HEC-HMS is a very complex program.  
Fortunately, the research team at CRWR has considerable experience with database 
design, and their assistance proved very valuable.  The HEC also took considerable 
interest in this project, and assisted by providing program documentation, and codes and 
instructions for dealing with DSS data.  A large diagram of the IDM is included in 
Appendix F. 
One purpose of creating the HMS IDM was to prove that the components of a 
hydrologic model could be effectively translated into a geodatabase format.  An 
?effective? IDM is one that accomplishes the list of goals outlined in Section 4.2.1.  (It 
was not within the scope of this project, however, to create a new software product that is 
capable of building new HMS models.)  Another goal of the IDM was to provide a 
system for archiving the LCRA?s existing HMS model data.  For this reason, codes were 
written to transfer this data from the LCRA?s HMS models into the IDM.  These codes 
were only developed for HMS routines used by the LCRA; other data transfer codes still 
must be developed.  A conceptual view of how data are translated back and forth between 
HMS files and the current IDM design is shown in the Figure 4.13.   
 54
The remainder of this section will discuss the details and rational behind the IDM 
development process.  First, the design of the IDM database structure is presented.  
Second, scenario management inside the IDM is discussed.  Finally, the process of 
transferring data from an existing HMS project to the IDM is presented. 
 55
 
Figure 4.13 ? HMS/IDM data connectivity 
Figure 4.13 ? HMS/IDM data connectivity 
 56
 
4.2.4 IDM Database Structure 
 As discussed in Chapter 12, a HMS project is made up of a number of unique file 
types.  These files store time series, watershed parameters, and model controls.  During 
the IDM design process, each file type was examined individually in order to determine 
how it could best be translated to geodatabase format.  The first file to be examined was 
the basin file. 
IDM Basin File Components 
 Except for perhaps DSS files, basin files are typically the largest and most 
complex files found in a HMS project.  They store the structure of the hydrologic 
network as well as all parameters used for base flow, initial loss, transform, and routing 
calculations.  Inside each basin file, data are arranged in blocks, as shown in the Figure 
4.14.  Each line in a block includes a description followed by a value, separated by a 
colon. 
It was decided that each geographic entity (junction, reach, etc.) should be 
represented as a record in a feature class.  It was also decided that each description (text 
preceding the colon in Figure 4.14) in the basin file should become a field name in the 
IDM.  Originally, it was desirable to use the HMS descriptions as field names.  However, 
this was not practical due to the length requirements; field names should have 10 
characters or less to ensure compatibility with other database types.  Therefore, 
descriptions were often reduced, (i.e.  ?Percent Impervious Area? was reduced to 
?Impervious?). 
It was also decided that there would need to be a unique feature class for each 
basin element (subbasin, junction, reach, etc.) so that each feature would have the correct 
 57
geometry type.  Subbasins would be represented by a polygon feature class, junctions by 
a point feature class, reaches by a line feature class, and so on.   
 
 
 Figure 4.14 ? Data blocks from a HMS basin file  
In a HMS model, the user may choose from a number of calculation routines for 
each feature.  Every subbasin, for example, has a loss rate routine that calculates the 
amount of rainwater lost to the subsurface.  In the subbasin block of Figure 4.14, there is 
a section for ?LossRate? parameters.  This section includes the type of LossRate routine 
being used (?Initial+Constant?) followed by all of the parameters required for the routine.  
Similarly, there is also a section in the Subbasin block for Transform and Baseflow 
parameters.  It was eventually decided that there should be a separate table (object class) 
for each routine.  In this fashion, routine tables not used by the model can be easily 
deleted at the user?s discretion.  Also, a set of relationships was created to associate these 
 58
tables to their corresponding feature class.  This system provides an effective structure for 
data organization and querying within ArcGIS.  Figure 4.15 shows an example parameter 
table. 
 
 
Figure 4.15 ? Table for Initial+Constant LossRate parameters 
IDM Gage File Components 
 Each HMS project has only one gage file, which stores all of the project?s 
precipitation and discharge gages.  They can be used for time series data input 
(precipitation) or model calibration (stream flow).  However, the gage file does not store 
time series data directly, but instead, the gages are related to time series data stored in 
DSS files.  In the HMS program, gages can be assigned latitude and longitude for 
calculation purposes, but they cannot be viewed spatially.  In the IDM, gages are stored 
as a point feature class, so that spatial viewing is an option. 
IDM Meteorological File Components 
 HMS meteorological models control how rainfall data is distributed over the 
HMS basin.  For example, a typical meteorological model could associate various HMS 
rainfall gages with various HMS subbasins.  There are other meteorological methods too, 
and the user must select which method to use for a particular HMS scenario.  
Meteorological models relate spatial rainfall data to spatial watershed data.  Therefore, 
meteorological methods are analogous to sophisticated relationship classes, and the 
 59
 60
meteorological file defines the details of this relationship.  Inside the IDM, each 
meteorological method is represented by a set of tables (one to three tables). 
IDM DSS File Components 
The HEC?s Data Storage System (DSS) provides an effective way of storing time 
series, paired data, and gridded data.  Time series DSS data include input precipitation 
data, output stream flow data, model calibration data, etc.  DSS paired data include, 
among other items, stream and reservoir routing data.  DSS grid cell data generally stores 
precipitation input data.   
DSS stores records in ?blocks? (similar to tables).  These blocks are referenced by 
their DSS pathnames, which have six unique parts, listed A through F, separated by 
forward slashes (/).  Each part contains a piece of information (metadata) about the DSS 
block.  Table 4.3 includes a description of each pathname part for the three main types of 
DSS data.  Example pathnames for the Llano HMS project include:  
 ?//R2590/STORAGE-FLOW///LR_MASON/? ? for time series
 ?//R3380W3360/FLOW-DIRECT/01NOV2000/15MIN/LR_JUNCTION/? ? for time series 
 
Pathname Time series 
Grid Cell 
Paired Data Paired Data 
Part metadata 
metadata 
metadata metadata 
    
 
HMS Version 2.1 HMS Version 2.2
A (blank) 
Grid type 
(blank) (blank) 
B Location 
Source/Location 
Location Location & Basin
C Variable type 
Variable type 
Variable type Variable type 
D Start of time block
Interval start time
(blank) (blank) 
E Time interval 
Interval end time
(blank) (blank) 
F Source 
(blank) 
Basin Format 
Table 4.3:  DSS pathname metadata 
 61
In addition to the DSS pathnames, there are additional DSS metadata stored in 
?DSS headers?.  Each DSS block can have its own unique header data.  Unlike pathname 
metadata, however, header metadata cannot be easily accessed and queried using HEC 
software.  Unlike the rigid structure of pathnames, the structure of header data is more 
flexible and varies considerably between the different types of DSS data.  Both 
?pathname? and common ?header? metadata are stored in ?Catalog? tables in the IDM. 
IDM Project Index and Control File Components 
 In addition to data storage files, a HMS project also has a number of files 
containing project and scenario management information.  These data are not spatial in 
nature, and fit readily into tables.  They are discussed further in Section 4.2.5. 
Coded Value Domains 
 A coded value domain is a list of user-defined values that may be used to populate 
a field within a database.  For example, a field named ?sky conditions? might have a 
coded value domain that includes the possible values: ?cloudy?, ?partly cloudy?, and 
?sunny?. Coded value domains were established for fields in the IDM that should only 
accept certain, HMS-defined values.   For example, the LossRate field in the 
HMSSubbasin feature class stores the type of LossRate calculation the model uses.  
?Initial+Constant? is an acceptable value, so is ?Green and Ampt?.  However, 
?InitialPlusConstant? would not be acceptable because it is not recognized by the HMS 
program.  By creating a coded value domain in UML, the user is restricted to selecting 
from a list of predefined, acceptable values.  Figure 4.16 shows how a user selects from a 
coded value domain. 
 
           
                   Figure 4.16 ? Coded value domains in ArcMap 
IDM Object Identification 
In the Arc Hydro data model, features are identified by a ?HydroID? and a 
?HydroCode?, which are an integer field and a text field respectively.   The HydroID is 
an arbitrary numeric identifier that is used as a basis for the model?s relationships.  The 
HydroCode is a text identifier that gives the feature a name meaningful to the GIS user.  
In the IDM, basin features are identified by a ?HMSCode?, which is a text field.  
HMSCodes are the IDM equivalent of the HydroID and HydroCode together.  
HMSCodes, therefore, serve a dual purpose.  Like HydroID?s, HMSCodes are the basis 
for IDM relationships; like HydroCodes, they provide a naming system that is 
meaningful to the user.   HMSCodes are equivalent to the names given to the elements 
within the HMS program.  For instance, a reach element named ?R300? in the HMS 
project, will translate into a reach feature with HMSCode = ?R300? in the IDM.   
As discussed previously, Arc Hydro data relationships are based on an integer 
field named ?HydroID?.  Therefore, in the GIS-HMS IDM, use of an equivalent integer 
field named ?HMSID? was considered.  The primary advantage of the ?HMSID? was that 
integer fields may be queried more quickly than text fields, thus improving IDM 
performance.  The disadvantage of using the ?HMSID? was that it would require 
 62
intensive ID management and maintenance because these values are not maintained by 
the HMS program.  The advantage of ?HMSCode? is that it requires little maintenance 
because the field is simply populated by the names of the HMS elements.  In the end, the 
?HMSID? concept was abandoned because the increase in performance that it allowed 
was minimal. 
HMSCodes are used only for HMS basin elements, but many other HMS 
elements also have a ?code? field.  Gage features, for instance, are identified by the 
attribute ?GageCode?.  Furthermore, there are a series of identification codes used in 
scenario management.  A ?RunCode?, for example, is the name of a particular HMS 
project scenario.  As with HMSCodes, the values of identification codes in the project 
geodatabase translate directly into the names of these elements in the HMS project.  
Table 4.4 gives a description of the code fields in use by the IDM. 
 
      
Code  Description 
      
   
HMSCode  Name of an individual HMS basin feature 
 
GageCode  Name of an individual HMS gage 
 
BasinCode  Name of a basin model 
 
MetCode  Name of a meteorological model 
 
ContrlCode  Name of a set of control specifications 
 
RunCode  Name of a project model run (scenario) 
      
 Table 4.4:  IDM identification codes  
 63
In addition to identification codes, all features in the IDM have a ?FeatureID? 
attribute.  This attribute is an integer field that has the capability of linking IDM features 
to Arc Hydro features.  The IDM FeatureID field is populated with the HydroID?s of 
equivalent Arc Hydro features.  Populating this field is optional, but it is the most 
effective way to create a link between features in the IDM and the corresponding features 
in Arc Hydro. 
4.2.5 IDM Scenario Management 
A HMS project can include multiple basin files, meteorological files and control 
files.  Scenarios, known as HMS ?runs?, are created by taking different combinations of 
these three file types.  Therefore, a HMS model with two basin files, two meteorological 
files, and two control files could have a maximum of 8 (2
3
) unique runs.  In the IDM, the 
run information is stored in the ?Project_Runs? table.  Every record in this table 
represents a unique run and points to a specific basin, meteorological, and control model. 
Whether or not to include scenario management tables within the IDM was a 
major design option.  Because scenario management information does not have a spatial 
component, the advantages of storing it within GIS seemed minimal.  Nonetheless, it was 
eventually decided to include these tables for the following reasons: 
1.  One of the goals of the IDM is that it be a data archive.  This archive would not 
be complete without the inclusion of scenario management data. 
2. All HMS time series results are referenced by the HMS run (scenario) in which 
they were created.  Therefore, scenario information must be maintained so that 
these time series results may be understood and related within the IDM. 
3. A future goal is to run HMS model calculations from within the GIS environment.  
The scenario management data must be maintained in order to perform these 
calculations. 
 64
IDM Structure for Multiple Basins 
 As discussed previously, a single HMS project may include an unlimited number 
of basin files.  Each of these basin files includes a number of spatial features (junctions, 
reaches, etc.).  Some of these basin files may represent the same geographic watershed, 
but with different versions of parameter values.  Other basin files may represent entirely 
different geographic locations.   
How to store data for multiple basin files within the same data model was a 
subject of much debate during the IDM development process.  It was at this point in the 
research that the concept of using more than one geodatabase was first considered.  There 
were three obvious alternatives for how the IDM might store these spatial features: 
1. Store all of the basin features in a single feature dataset (in the same geodatabase). 
2. Store the features of each basin file in a unique feature dataset (in the same 
geodatabase). 
3. Store the features of each basin file in a unique geodatabase. 
The first option, although certainly possible, had one severe disadvantage.  
Storing the features of multiple basin files within the same feature class, could lead to 
overlapping features when basin files represent similar geographic areas.  Overlapping 
features in GIS can be very confusing to the user, especially if the features share exactly 
the same spatial coordinates.  This option would also force all DSS time series to be 
stored in one geodatabase, which may not be desirable based on performance issues.  The 
one advantage of this approach is that it would allow all HMS project data to be stored in 
a single geodatabase.   
The second option proved to be much less feasible than the first.  The reason for 
this is that no two tables in the same geodatabase can have the same name, even if they 
are in separate feature datasets.  Therefore, if this method were employed, standardized 
 65
table names like ?HMSJunction? could no longer be used.  Furthermore, because 
standardized table names could not exist, standardized data relationships could not exist.  
To solve this problem, codes would need to be written to create feature classes with 
unique names (i.e. HMSJunction1, HMSJunction2, HMSJunction3?). This would be no 
trivial task and it would greatly complicate the IDM.  Therefore, this option was 
discarded. 
The third option was originally thought to be too cumbersome to be practical.  It 
involved the creation of a separate basin geodatabase for every basin file.  Eventually, 
however, it was determined to be the best way to prevent overlapping features, and at the 
same time, allow standardized table and relationship class names.   
It was eventually decided that option #3 would be the most effective way to store 
multiple basin files.  However, a modification was made to allow basin files with 
identical geographies, but different watershed parameters to be stored in the same 
geodatabase.  In this case, because the features are identical, they would be stored only 
once in their respective feature classes.  Parameter tables, however, would store a unique 
record for each basin file, which would be recognized by a ?BasinCode? attribute.  In this 
manner, multiple calibrations of the same watershed could be stored within the same 
geodatabase. 
IDM Structure for Multiple Meteorological Files 
Meteorological models describe how gaged rainfall data are distributed over a 
watershed.  Although the rainfall data are spatial and the watershed data are spatial, the 
meteorological data are not spatial.  Meteorological data are simply a set of instructions 
that define the relationship between rain gages (or rain grids) and the watershed.  Because 
of this, there are no concerns regarding overlapping features.  Therefore, multiple 
meteorological models can be satisfactorily stored in one set of tables (similar to option 
 66
#1 for basin files).  Storing each meteorological model in a unique geodatabase is 
unnecessary. 
4.2.6 Linking the IDM with HMS data 
To make the IDM functional, there has to be a method for transferring data back 
and forth between it and the HMS file structure.  This has been accomplished to a limited 
degree by this thesis (and further progress is being made at Texas A&M University).  The 
primary focus, for this project, has been on transferring data from the LCRA?s existing 
HMS models to the IDM.  Therefore, codes have been developed for transferring the 
types of HMS elements that exist within the LCRA?s models.  In general, codes have 
been written to import data into the IDM, but not to export them back to HMS. 
Visual Basic (VB) was the chosen method for moving data from HMS files to the 
IDM.   VB provides all of the functionality necessary for this task, and it is the program 
most familiar to the CRWR research team.  There has been some discussion of using 
XML, but based on a discussion with Dean Djokic (personal communication, 2003), 
XML would only provide an advantage for exporting data from the IDM, not for 
importing them.  In the future, when codes are written to export the data back into HMS 
files, XML should be further considered.  A set of the VB codes are included on CD in 
the back of this report, and a brief tutorial on how to use them is included in Appendix G. 
Transferring HMS Text Files to the IDM 
As discussed previously, all HMS files except DSS files are text files.  Therefore, 
the codes developed to transfer these files are basically text parsers.  They search the text 
file for key words, get the value associated with that word, and transfer that value to the 
appropriate geodatabase location.  Separate codes were written for the various types of 
HMS text files.  Figure 4.17 shows the GUI interface for one of these programs. 
 67
 
 
           Figure 4.17 ? Program for transferring a HMS basin file to the IDM 
Transferring Shape Data to the IDM 
Shape data must come from a source other than the text files.  In the case of the 
LCRA/Halff HMS models, shape data are available in the form of GIS files created by 
Halff & Associates.  The original data were shapefiles, but they were converted to 
geodatabase feature classes for this project.  Therefore, a code was written to transfer 
these shape data from a geodatabase made from Halff GIS files to the IDM geodatabases.  
The GUI for this code is shown in Figure 4.18.  Note that shape data are transferred from 
?source? feature classes to ?target? feature classes based on matching attribute values in 
the ?Match Fields?. 
 68
 
Figure 4.18 ? Program for transferring GIS shape data to the IDM 
Transferring HMS DSS Files to the IDM and Back 
 The transfer of DSS data is a slightly more complicated task.  To begin with, DSS 
has a binary storage structure that requires specialized HEC routines in order to 
manipulate.  Therefore, the VB program must call these routines, which are stored in a 
dynamic link library (the name of the file is ?heclib50.dll? and it is typically stored under 
the ?System32? folder in Windows).  Another complication involves the sheer size of 
DSS files.  The DSS file (HEC binary format) for the Halff/LCRA historical model of the 
Llano River Basin is nearly 60 megabytes in size.  Therefore, the DSS transfer program 
was designed to handle these large files as efficiently as possible.  Nonetheless, 
transferring complete DSS files to the IDM can be a time-consuming effort.  Unlike for 
the other data types, programs were written to transfer time series data in both directions:  
IDM to HMS, as well as HMS to IDM.  As shown in Figure 4.19, data from a DSS file 
 69
may be selected for importation to the IDM based on a query of the A through F parts of 
the DSS pathname. 
 
 
           Figure 4.19 ? Program for transferring DSS paired data to the IDM 
Once completed, these tools were used to populate a prototype IDM with data 
from one of the LCRA?s existing HEC-HMS models.  For this purpose, the tools proved 
very satisfactory.  The populated model that resulted is discussed in Chapter 5. 
 70
4.3 CREATING A GIS-BASED FLOOD DAMAGE EVALUATION SYSTEM 
This section discusses how GIS and the concepts developed by this report can be 
applied to performing water resources calculations.  In this case, the application is for 
flood mapping and the determination of flood damages.  This section of the report is 
divided into three main parts.  First, the objectives of this work will be discussed.  
Second, the flood map generation process will be presented, followed by the flood 
damage assessment process.  Next, a data model developed specifically for this work will 
be discussed.  Finally, the development of an ArcGIS Model Builder process, designed to 
automate these calculations, will be presented. 
4.3.1 System Objectives 
Flood Maps 
Flood maps are developed primarily as a visual aid for flood analysis.  The 
resolution of these maps vary depending upon the needs of the user and the quality of the 
input data.  To develop high-resolution flood maps, the user must possess sufficiently 
detailed terrain elevation data, and sufficiently accurate and robust hydraulic models.  
Based on discussions with Melinda Luna, an LCRA engineer specializing in river 
hydraulics, uncertainty in the hydraulic model is generally more of a limiting factor than 
the availability of quality terrain data (personal communication, 2004). 
The LCRA currently has no standardized routine for developing floodplain maps.  
When maps are generated, HEC-GeoRAS is usually the method of choice.  However, 
HEC-GeoRAS has been found to have a number of limitations that greatly reduce the 
quality and/or speed of map generation.  These limitations include problems caused by 
river sinuosity and river coves, which are discussed in greater detail in the next section.  
 71
In many cases, the results of HEC-GeoRAS require many hours of hand editing to 
produce a map of sufficient quality. 
As a result of the Halff/LCRA H&H study discussed in Chapter 3, the LCRA now 
posses a set of ?official? floodplain maps for various return-frequency storms (2-year, 5-
year, etc.) as shown in Figure 4.20.  These flood maps were calculated using extremely 
detailed terrain TINs (around 300 megabytes each) that were too large to be used with 
HEC-GeoRAS.  To work around this problem, Halff and Associates developed a custom 
program to intersect the water surface TINs with the very-detailed terrain TINs.  
According to Erin Atkinson of Halff and Associates, this program would take around 12 
hours to execute (personal communication, 2004). 
 
 
Figure 4.20 ? LCRA/Halff flood shapefiles for return-frequency storms (Lake Travis) 
 72
The goal of this research effort is to develop a procedure for generating floodplain 
maps at a much faster rate, so that flood map generation could potentially become a part 
of the real-time flood forecasting system.  These maps would be used primarily as a 
visual aid, and are not necessarily intended for use in further calculations.  Nonetheless, a 
goal is to make these maps comparable in quality to the maps generated by Halff and 
Associates. 
Damage Reports 
The LCRA does not calculate flood damage reports on a regular basis.  As with 
floodplain maps, however, they do have detailed damage assessments for the various 
return-frequency storms.  These damage reports were generated using the HEC?s Flood 
Damage Assessment (FDA) procedure discussed in Chapter 2.   
There were two primary goals for the damage report procedures developed by this 
research.  First, these reports need to be generated quickly so that, like floodplain maps, 
they could become part of real-time flood analysis.  Second, it was desired that these 
calculations be performed on a spatially distributed basis, for the reasons discussed in 
Chapter 2. 
The damage report system developed by this research currently returns only the 
number of structures inundated and the depth of inundation for each structure.  The 
damage report system does not currently provide the economic value of these damages.  
However, assuming that economic data is available for the various floodplain structures, 
then calculating total economic damage would be a straightforward extension of the 
procedure presented here. 
 73
Results Archive 
It was also determined that there needs to be a procedure for archiving the results 
generated by this flood evaluation process.  Therefore, a data model was developed to 
facilitate calculations and to store results.  The Arc Hydro data model was considered, but 
due to the nature of the results data, Arc Hydro was determined not be an appropriate 
repository.  Arc Hydro generally stores permanent watershed information; not temporary 
and arbitrary model results.  
  4.3.2 Flood Map Generation 
The flood map generation process is well established, relatively simple, and well 
documented by programs such as HEC-GeoRAS.  In general, flood maps are created by 
comparing the calculated water surface elevation to the land surface elevation 
continuously across the floodplain.   Where the water surface elevation is greater than the 
land surface elevation, inundation occurs.  The remainder of this section focuses on areas 
where the standard method of floodplain generation had to be modified to meet the 
unique needs of the LCRA. 
Land Surface Representation 
As discussed in the previous section, the terrain TINs used by the Halff study are 
too large to be used in real-time flood forecasting operations.  Therefore, it was decided 
that these TINs must be converted into a more useable format.  One option was to try to 
decrease the resolution of the TINs.  However, there is no method for accomplishing this 
using standard ArcGIS tools, and it was eventually decided that TIN modification was 
not a useful approach in this research.   
The other option was to convert the TINs to rasters (grids) of reasonable 
resolution.  It was decided that a 20-foot cell size would be appropriate since this is 
 74
comparable to the size of most floodplain structures, as shown in Figure 4.21.  This 
resulted in rasters of approximately 30 megabytes in size ? an order of magnitude smaller 
than their associated TINs. 
 
 
Figure 4.21 ? Floodplain structures over a 20-foot raster 
The LCRA/Halff H&H study includes twenty original TINs, which cover the 
entire floodplain of the main stem of the Lower Colorado River Basin.  Through the 
remainder of this report, these twenty TINs will be referred to as ?LCRA DEM regions?, 
where DEM stands for digital elevation model.  For this project, five of these TINs were 
converted to rasters, and some of them were merged together.  It was assumed that the 
LCRA will be responsible for converting and merging the remaining TINs.   
Water Surface Generation 
Water surface elevations are generally represented by a TIN, formed from cross 
section lines with calculated water surface elevations.  The cross sections used for TIN 
generation are typically the same cross sections used by the hydraulic model.  Despite the 
fact that this method of TIN generation is well established, it does have some potential 
limitations.  The two major limitations were insufficient cross section widths and errors 
 75
resulting from river sinuosity.  A tutorial that provides detailed instructions for dealing 
with these limitations is included in the Appendix H. 
(A) Insufficient cross section width. 
Sometimes the hydraulic cross sections may not be wide enough to span the entire 
region that needs to be mapped.  This is especially true when there are large coves in the 
river system that extend far beyond the main river channel, as shown in Figure 4.22.  In 
the past, manual editing has been used to extend the inundation polygon into these coves. 
 
Figure 4.22 ? Coves extending beyond hydraulic cross sections on Lake Travis 
Two options were considered for solving this problem.  The first option, termed 
the ?fill sinks? option and illustrated in Figure 4.23, was to generate a water surface 
based on the existing hydraulic cross sections.  This water surface would be converted 
into a grid and then merged with the land elevation grid based on the maximum value of 
the two grids.  The resulting raster has pits wherever coves exist outside of the main 
channel.  Using the Arc Hydro ?fill sinks? command, the elevation in these coves is then 
raised to the lowest adjacent water surface elevation (so that all water can ?flow? to the 
 76
basin outlet).  The resulting ?fill grid? represents the land/water surface that exists during 
flooding.  The land surface grid is then subtracted from the ?fill grid? to determine flood 
depths and the resulting floodplain. 
 
 
Figure 4.23 ? The ?fill sinks? solution to mapping cove inundation 
The primary advantage of the ?fill sinks? method is that it requires no alteration of 
existing GIS data.  It does, however, have some considerable drawbacks.  First, the fill 
sinks command takes approximately 15 minutes to run for a typical LCRA DEM region.  
Second, this method assigns the lowest adjacent water surface elevation (most 
downstream elevation) to the coves, and this may not be desirable in areas with steep 
water surface slopes. 
 77
The second method was the manipulation of the hydraulic cross sections to 
adequately cover the area of inundation.  This method, illustrated in Figure 4.24, requires 
the extension of existing cross sections, and occasionally the addition of new cross 
sections around large cove features.  The only disadvantage of this method is that it 
requires a considerable initial time investment in order to manually edit the cross 
sections.  The advantages of this method are very considerable, however, because this 
method does not result in any extra processing time during the flood map generation 
process.  Also, this method gives the user more control over the elevation assigned to the 
water surface in coves.  For these reasons, this was the method used by this research 
project. 
 
Figure 4.24 ? Original cross sections (top) and modified cross sections (bottom) 
 78
 
(B) Errors caused by river sinuosity 
River sinuosity refers to the degree that a river?s centerline winds and bends along 
its path.  Lake Travis, shown in Figure 4.25, is one of the extremely sinuous regions in 
the lower Colorado River System.  HEC-RAS is a one-dimensional model, and so these 
bends are largely ignored.  However, for floodplain mapping, these bends must be 
considered, and they can potentially cause inaccuracies when generating the water 
surface TINs. 
 
Figure 4.25 ? Lake Travis, a particularly sinuous stretch of the Lower Colorado River 
In areas where the river has a high level of sinuosity, cross sections located on one 
side of a sinuous bend may have an impact on the water surface elevations on the other 
side of the bend.  An example of this is illustrated in the top half of Figure 4.3.7.  As 
shown in this figure, the water surface elevations on one side of the river bend are 
influenced by cross sections on the other side of the bend. 
 79
To remedy this problem, a series of minor modifications were tested on the cross 
sections.  It was eventually decided that the most effective manipulation was to toe the 
cross sections along the inside of the river bend.  These toes, shown in the bottom-left of 
Figure 4.26, are small approximately 90 degree bends the ends of cross sections.  In 
general, these toes could be almost infinitely small, except where the cross sections on 
the opposite side of the river were more closely spaced (more dense).  These toes forced a 
break in the water surface TIN between one side of the bend and the other, as shown in 
the bottom-right of Figure 4.26. 
 
Figure 4.26 ? Toeing cross sections to prevent errors caused by river sinuosity 
 80
It was also decided that cross sections converging on the inside of a bend could 
create an unrealistic water surface profile.  As shown in the top of Figure 4.27, these 
cross sections could create an unnatural ?wall of water? (area of high water surface 
slope).  For this reason, the cross sections were clipped and spread to create a more 
natural water surface profile. 
 
 
Converging 
Cross Sections 
Figure 4.27 ? Clipping cross sections on the inside of a river bend 
Other methods were also tested to correct the river sinuosity problem.  One of 
these methods was the placement of hard break lines down the center of the bend 
 81
(between the cross section ends), which would be used in TIN generation.  Another 
method was to create the TIN with a clip, so that the center of the bend would be a data 
void.  However, neither of these methods produced satisfactory results. 
Generating a Floodplain Polygon 
Once the cross sections have been satisfactorily modified using the procedure 
outlined above (and detailed in the report?s appendix), these sections and the land surface 
DEM can be used to create a floodplain polygon.  This procedure is straightforward and 
can be accomplished using tools found in the ArcGIS 2-D (Spatial) and 3-D Analyst 
Extensions.  A summary of this process is listed below: 
1. Convert cross sections to a water surface TIN 
2. Convert water surface TIN to a raster 
3. Subtract land surface raster from water surface raster 
4. Create new raster from all cells that have a positive value (Grid Value > 0) 
5. Convert new raster to a polygon feature class 
6. Dissolve polygons into one record (if desired) 
4.3.3 Damage Report Generation 
 Unlike flood map generation, there were no established procedures for generating 
flood damage reports on a structure-by-structure basis.  Despite this, developing such a 
procedure was not found to be a particularly difficult endeavor.  Virtually all of the tools 
required to calculate structure inundation depths can be found in ArcMap and the 3-D 
Analyst Extension.  It should be noted that the floodplain map plays no role in the 
creation of a damage report, the two processes are completely independent. 
As shown in Figure 4.21, LCRA structure data is stored in a polygon feature 
class.  Each structure in this feature class has an attribute that records the structure?s 
 82
surveyed first-floor elevation.  It is this elevation that must be compared to the water 
surface elevation in order to determine depth of inundation.  Therefore, for this project, it 
was essential to extract the water surface elevation at the location of each structure.   
A number of different methods for extracting the water surface elevation were 
considered.  In the end, two important decisions were made.  First, it was decided that 
structure polygons should be converted to points to make calculations simpler and 
execute more quickly.  Second, it was decided that water surface elevations should be 
extracted from the water surface TIN, not the water surface raster.  The reason for the 
second decision was that due to an inadequacy in the ArcGIS zonal statistics function, if 
two (very small) structures were located within the same raster cell, then the water 
surface would only be computed for one of the structures. 
In the end, a complete procedure for calculating structure inundation depths was 
established.  That procedure is outlined below: 
1. Convert cross sections to a water surface TIN 
2. Calculate the water surface elevation at each structure location 
3. Subtract the first-floor elevation from the water surface elevation for each 
structure. 
4. Export all records with a positive inundation to a flood damage table.  (This 
table is a list of all inundated structures, and their depth of inundation) 
Once the inundated structure table has been created, then statistics can be 
calculated to determine the total flood damage.  These statistics are stored in a separate 
table where one record includes all of the statistics for the given flood event.  For this 
research, only the number of structures inundated and the average depth of inundation 
were calculated.  Economic data could be calculated in a similar manner. 
 83
4.3.4 Flood Data Model Development 
Unlike Arc Hydro and the HMS IDM, this data model was not created using 
UML.  Instead, it was created by manipulating the feature classes provided by the LCRA.  
The goal of this data model was to provide a repository for the maps and data calculated 
by the flood damage evaluation process, and to provide a location to archive these results 
at the user?s discretion.  An ArcCatalog view of this data model is shown in Figure 4.28.  
This data model was designed to work with the Model Builder procedure discussed in the 
following section. 
 
 
Figure 4.28 ? Data model for flood damage evaluation 
Most input data are arranged into feature datasets, where the name of the feature 
dataset equals the name of the corresponding HEC-RAS modeling area.  The only 
essential data for these datasets are the StructurePoint and CrossSections feature classes.  
All other feature classes inside the datasets are used only for reference.  Figure 4.28 
 84
includes only one feature dataset (Bastrop), but a complete model of the entire Lower 
Colorado River would include many more. 
Output data reside in the six feature classes and tables that reside in the 
geodatabase, but outside of any feature dataset.  The FloodPlain, FloodStatistic, and 
FloodStructure classes store the data resulting from the most recent calculations.  When 
new calculations are performed, the data in these classes will be overwritten.  The 
AFloodPlains, AFloodStatistics, and AFloodStructures classes store archived data.  These 
classes include the results of many calculations, and individual scenarios are identified by 
the ModelID and EventID attributes.  Figure 4.29 includes all of the classes and fields 
required by the flood damage evaluation system.  Note that the CrossSections and 
StructurePoint feature classes have three-letter prefixes designating the study area (in this 
case, ?trv? represents the Lake Travis study area). 
 
 85
Simple feature class
trvCrossSections
Contains Z values
Contains M values
Geometry Polyline
No
No
Data typeField name
Prec-
ision Scale LengthDescription
Allow
nulls
OBJECTID Object ID
Shape Geometry Yes
STREAM_ID String Yes 16HEC-RAS stream name
REACH_ID String Yes 16HEC-RAS reach name
STATION Double Yes 0 0Cross section station location
type String Yes 20Cross section type - main stem or cove
Shape_Length Double Yes 0 0
Max_WS Double Yes 0 0Maximum water surface elevation for storm event
Simple feature class
trvStructurePoint
Contains Z values
Contains M values
Geometry Point
No
No
Data typeField name
Prec-
ision Scale LengthDescription
Allow
nulls
OBJECTID Object ID
Shape Geometry Yes
STRUC_NAME String Yes 10
LCRA structure name
CALCELEV Float Yes 0 0
Calculated first floor elevation
STATION Double Yes 0 0
Structure station location (optional)
Simple feature class
FloodPlain / AFloodPlains
Contains Z values
Contains M values
Geometry Polygon
No
No
Data typeField name
Prec-
ision Scale LengthDescription
Allow
nulls
OBJECTID Object ID
SHAPE Geometry Yes
GRIDCODE Double Yes 0 0
EventID Long integer Yes 0
ModelID Long integer Yes 0
Description String Yes 255
SHAPE_Length Double Yes 0 0
SHAPE_Area Double Yes 0 0
Table
FloodStatistic / AFloodStatistics
Data typeField name
Prec-
ision Scale LengthDescription
Allow
nulls
OBJECTID Object ID
FREQUENCY Long integer Yes 0Number of inundated structures
MEAN_Depth Double Yes 0 0Average depth of inundation
MAX_Depth Double Yes 0 0Maximum depth of inundation
EventID Long integer Yes 0
ModelID Long integer Yes 0
Description String Yes 255
Table
FloodStructure / AFloodStructures
Data typeField name
Prec-
ision Scale LengthDescription
Allow
nulls
OBJECTID Object ID
STRUC_NAME String Yes 10
CALCELEV Float Yes 0 0
STATION Double Yes 0 0
Depth Float Yes 0 0Calculated depth of inundation
Spot Double Yes 0 0Calculated water surface elevation
EventID Long integer Yes 0
ModelID Long integer Yes 0
Description String Yes 255
Grid code (from raster)
Storm event identifier
Model run identifier
Description of event/model
Storm event identifier
Model run identifier
Description of event/model
Storm event identifier
Model run identifier
Description of event/model
LCRA structure name
Calculated first floor elevation
Structure station location (optional)
 
Figure 4.29 ? Classes and fields required for the flood damage evaluation system 
 86
4.3.5 Model Builder Application 
Model Builder is a GIS graphical programming system available in ArcGIS 9.  
This system can be used to string together data, ArcGIS tools, scripts, and external 
programs into a single application.  According to Tim Whitaker, a senior member of the 
CRWR research team, Model Builder can be used to create elaborate GIS applications in 
a fraction of the time that it would have taken using older programming systems 
(personal communication, 2004).   
Model Builder uses a number of graphical symbols to represent different items in 
the modeling system.  It is important to be familiar with these symbols to understand the 
modeling process.  A list of these symbols follows: 
1.   Toolbox.  All tools, models, and scripts must reside in a toolbox. 
2.    Toolset.  Tools, models, and scripts may be organized into toolsets. 
3.   Model.  All Model Builder processes are created as models. 
4.   Script.  A script is written by the user; may be used as part of a model. 
5.   Tool.  ArcToolbox processes; may be used as part of a model. 
Model Builder can be used to create a customized toolbox where each tool is a 
user-defined model.  The completed toolbox for this project is shown in Figure 4.30.  As 
shown, the contents of this toolbox are arranged into five toolsets.  The first three 
toolsets, which are numbered, include the primary tools which the LCRA would use on a 
regular basis.  The ?Components? and ?Scripts? toolsets include sub-models and scripts 
that are called by the first three toolsets.  All of these tools were designed in the ?Pre-
Release? version of ArcGIS 9.  The remainder of this section describes these toolsets in 
greater detail. 
 87
 
Figure 4.30 ? Toolkit for the flood damage evaluation system 
Generate New Results Toolset 
This toolset includes the tools necessary to generate new results from the input 
data illustrated in Figure 4.28.  These tools were designed to give the user the ability to 
generate a floodplain, a damage report, or both.  By double-clicking on the GenerateALL 
tool, the GUI interface shown in Figure 4.31 appears.  The inputs for this GUI are the 
four files necessary to create a floodplain map and damage report. 
 
 88
 
Figure 4.31 ? GUI for the GenerateALL tool 
The user can also view the inner workings of these models.  For example, Figure 
4.32 shows the layout of the GenerateALL model.  As illustrated in this figure, data are 
represented as ovals, and processes are represented as rectangles.  The four blue ovals on 
the left side of the diagram are the four model inputs.  The green ovals are intermediate 
and permanent data products created when the model is run.  In this model, each of the 
processes (yellow rectangles) represents another model (a sub-model) which is called by 
the GenerateALL model.  These other models are stored in the Components toolset, as 
discussed previously. 
Each of the sub-models may also be viewed.  Figure 4.33 shows the insides of the 
LCRA_XStoFloodMap model.  This model takes cross sections with assigned water 
surface elevations and the land surface DEM, and creates the floodplain map.  In this 
model, each process is a Arc-GIS defined tool; this model has no sub-models. 
 
 89
 
Figure 4.32 ? GenerateALL model layout 
The complete flood damage evaluation system toolbox contains many additional 
models.  The general theory behind all of these models is very similar, however, and the 
concepts behind these models were defined in Sections 4.3.2 and 4.3.3.  Therefore, a 
complete set of model layouts is not included in the body of this report, but is available in 
Appendix I. 
 
 90
 
Figure 4.33 ? Generate floodplain map model 
 91
Manage New Results Toolset 
Once new results have been created, they are temporarily stored in the FloodPlain, 
FloodStatistic, and FloodStructure classes.  At this point, the user has the option to delete 
these results or to archive them.  The ?Delete? models clear all records from the tables, 
but do not delete the tables themselves.  The archive model moves the results into the 
more-permanent AFloodPlains, AFloodStatistics, and AFloodStructures classes.  It is at 
this point that the user can assign EventID, ModelID, and Description attributes in order 
to identify the particular set of results.  In general, an EventID represents a storm event, 
and a ModelID represents a particular model run.  Therefore, many unique ModelIDs can 
correspond to the same EventID.  The description field is a text field that is arbitrarily 
populated by the user.  The ArchiveNew GUI is shown in Figure 4.34.  Because this 
model moves data from one standardized set of tables to another standardized set of 
tables, the user is not required to input the locations of these tables.  This proved to be 
one significant advantage of using a standardized data model. 
 
 
Figure 4.34 ? GUI for the ArchiveNew model 
 92
Manage Archived Results Toolset 
The user may occasionally wish to delete archived results.  To accommodate this, 
models were developed to delete records based on a query of the geodatabase.  Because 
individual result sets are identified by the EventID and ModelID, it was assumed that 
most deletes would be based on these two fields.  The GUI interface used for deleting 
archived floodplains is shown in Figure 4.35.  By clicking on the file icon to the right of 
the text box, the user can build custom queries. 
 
 
Figure 4.35 ? GUI for the DeleteArchivedFloodPlain model 
Components and Scripts Toolsets 
These toolsets contain the most inner workings of this Model Builder system.  
Many of the models in the first three toolsets call the sub-models and scripts located 
within the Components and Scripts toolsets.  These sub-models and scripts can be called 
by multiple higher-level models; and they thus reduce the need to create the same 
processes over and over again for each application.  The scripts are used to take water 
surface elevations from the HEC-RAS SDF file, and assign them to the cross section 
feature class.  They were developed by ESRI and modified at CRWR. 
 93
Toolbox Summary 
Table 4.5 is a summary of the various models and scripts included in the 
LCRAfloodTools toolbox.  This table includes the toolkit in which each model and script 
belong, and a list of sub-models that are called by these models.  Table 4.6 lists the input 
data, output data, and purpose of each tool. 
 
# Model Name Toolset Sub-Models/ 
      Scripts Called
1 GenerateAll 1. Generate New Results 11,12,13,14,15 
    
2 GenerateDamageReportOnly 1. Generate New Results 11,13,14,15 
    
3 GenerateFloodPlainOnly 1. Generate New Results 11,12 
    
4 ArchiveNew 2. Manage New Results  
    
5 DeleteNewAll 2. Manage New Results  
    
6 DeleteNewDamageReport 2. Manage New Results  
    
7 DeleteNewFloodPlain 2. Manage New Results  
    
8 DeleteArchivedDamageReport 3. Manage Archived Results 17 
    
9 DeleteArchivedFloodPlain 3. Manage Archived Results 16 
    
10 FCtoTable Components 
    
11 LCRA_RAStoXS Components 18,19
    
12 LCRA_XStoFloodMap Components 
    
13 LCRA_XStoStructP Components 
    
14 LCRA_StructPtoDamage Components 
    
15 LCRA_DamagetoStats Components 
    
16 ReplaceFC Components
    
17 ReplaceTable Components 
    
18 SDF2XML Scripts
    
19 XML2XSElev Scripts
 Table 4.5:  Summary of LCRAfloodTools 
 94
         
# Model Name Inputs Ouputs Purpose 
          
1 GenerateAll DEM, SDF, FloodPlain Creates new flood map and 
 StructurePoint FloodStructure damage report
 CrossSection FloodStatistic  
 
2 GenerateDamageReportOnly SDF, CrossSection FloodStructure Creates new damage report 
 StructurePoints FloodStatistic
 
3 GenerateFloodPlainOnly DEM, SDF FloodPlain Creates new flood map 
 CrossSection  
 
4 ArchiveNew FloodPlain AFloodPlains Archives all new data 
 FloodStructure AFloodStructures
 FloodStatistic AFloodStatistics  
 
5 DeleteNewAll FloodPlain n/a Deletes all new data 
 FloodStructure
 FloodStatistic  
 
6 DeleteNewDamageReport FloodStructure n/a Deletes new damage report data 
 FloodStatistic
 
7 DeleteNewFloodPlain FloodPlain n/a Deletes new flood map 
    
8 DeleteArchivedDamageReport AFloodStructures n/a Deletes archived damage report(s) 
  AFloodStatistics  based on query 
 
9 DeleteArchivedFloodPlain AFloodPlains n/a Deletes archived flood map(s) 
        based on query 
Table 4.6:  LCRAfloodTools input and output data  
(continued on following page) 
 95
 
         
# Model Name Inputs Ouputs Purpose 
          
10 FCtoTable any any Converts feature class to table 
    (not used by any other model) 
 
11 LCRA_RAStoXS CrossSection CrossSection2 Extracts RAS SDF water surface 
  SDF  elevations, assigns to cross sections 
  
12 LCRA_XStoFloodMap CrossSection2 FloodPlain Converts cross sections to a 
 DEM floodplain map
  
13 LCRA_XStoStructP CrossSection2 StructurePoint2 calcluates water surface elevation 
  StructurePoint  at all structures 
 
14 LCRA_StructPtoDamage StructurePoint2 FloodStructure calculates depth of inundation 
    for all structures 
  
15 LCRA_DamagetoStats FloodStructure FloodStatistic calculates flood statistics 
    for inundated structures 
 
16 ReplaceFC any any replaces an existing feature class 
    with a modified feature class 
  
17 ReplaceTable any any replaces an existing table 
    with a modified table 
 
18 SDF2XML SDF XML converts .SDF file to .XML file 
  
19 XML2XSElev XML CrossSection converts .XML file to crosssection 
        water surface elevations 
 
Table 4.6:  LCRAfloodTools input and output data (continued) 
 
 96
Chapter 5:  Results 
In many respects, the methodologies developed in Chapter 4 are some of the most 
important results of this research.  Nonetheless, through these methodologies, a number 
of important end results were also created.  These final products are the subject of this 
chapter.  The three sections that follow discuss the results of the Arc Hydro data model, 
the HMS interface data model, and the GIS-based flood damage evaluation system.  
5.1 ARC HYDRO RESULTS 
This section discusses the results of applying the Arc Hydro system to the Lower 
Colorado River, and the Llano River specifically.  First, the results of the Arc Hydro 
Framework for storing geospatial data are presented.  Second, the Arc Hydro time series 
format is tested and evaluated.  Finally, the Arc Hydro toolset is assessed. 
5.1.1 Arc Hydro Framework 
 The development of the Arc Hydro Framework for the Llano River Basin was 
successful.  All of the source data fit readily into the Arc Hydro data model, and although 
the development process was slow at first, once the author became familiar with the 
methods and theory behind the process, it went much more quickly.  For an experienced 
user, the creation of an Arc Hydro Framework for an area the size of the Llano Basin 
should take days, not weeks.  Figures 5.1 through 5.4 show ArcMap screenshots of the 
completed Arc Hydro data model. 
 
 97
 
Figure 5.1 ? Finished model, HydroJunctions & MonitoringPoints 
 
Figure 5.2 ? Finished model, feature Names/HydroCodes 
 98
 
 
Figure 5.3 ? Finished model, lengths from basin outlet 
 
 
Figure 5.4 ? Finished model, watershed areas & cumulative area upstream for junctions 
 99
Arc Hydro Network 
According to Arc Hydro ? GIS for Water Resources, ?The hydro network is the 
backbone of Arc Hydro? The topological connection of its HydroEdges and 
HydroJunctions in a geometric network enables tracing of water movement upstream and 
downstream through streams, rivers, and water bodies.?  (Maidment, 2002).  The network 
also provides a means of river addressing using the flow length between various points on 
the river network.  The result of a trace upstream on the Llano HydroNetwork is shown in 
Figure 5.5. 
 
 
Figure 5.5 ? Upstream trace from a ?flag? placed southwest of Junction, Texas 
5.1.2 Arc Hydro Time Series Format 
 For datasets of limited size, there are no functional limitations associated with the 
Arc Hydro time series format.  However, for time series of larger sizes, computer 
software and hardware limitations become a problem.  Most of the work in this project 
was performed on a computer with a 2.5-gigahertz processor and 1 gigabyte of random 
access memory (RAM).  Nonetheless, the problems associated with large TimeSeries 
 100
tables (generally 1,000,000 records or larger) became very apparent throughout the 
course of this project.  These problems included error messages, computer lock-up, and 
even inaccurate sort and query results.  The full Hydromet Interval table (3,000,000 
records) was successfully loaded into the Arc Hydro personal geodatabase but it had no 
functionality using standard ArcGIS tools due to its large size. 
 Similar problems were experienced when working with the NEXRAIN data.  
Only for small datasets, could NEXRAIN data can be successfully imported into 
ArcHydro and viewed using the Time Series Viewer animation tool.  Figure 5.6 shows 
snapshots from an animation of NEXRAD (similar to NEXRAIN) data over the Llano 
River watershed.  The time series used for this animation consisted of 5,000 records.  
Larger time series can be used, but they require considerable time to prepare and can 
result in choppy animations. 
 
 101
 
 
 
Figure 5.6 ? Screen captures of a storm event moving over the Llano Basin 
Arc Hydro Time Series in SQL Server 
Originally, it was anticipated that storing time series in SQL Server would prove 
much more efficient than storing time series in the personal database format.  However, 
due to imperfections in ESRI?s ArcSDE software, this has yet to be verified.  One 
problem is a SDE log table that creates a record for every object queried (selected) by the 
ArcMap user.  When querying a large selection of time series data, this log table grows to 
an immense size that causes the server to crash.  Another problem is the slow 
 102
performance of queries made through the ArcMap/SDE interface.  (An example query: 
Select from the TimeSeries table all records that have a FeatureID equal to 16.)  A query 
made through the ArcMap/SDE interface can take many times longer than an identical 
query made through a non-SDE database connection (i.e. a MS Access ODBC 
connection).  The staff at CRWR, as well as at the LCRA, has put forth considerable 
effort attempting to resolve these problems, but so far, no solution has been found.  A 
dialogue between ESRI and CRWR was initiated with the purpose of resolving these 
ArcMap/SDE time series issues.  The ESRI staff believes that ArcSDE can be used 
effectively, and can meet the needs of CRWR (personal communication, Hugh Keegan - 
ESRI, 2003).  Therefore, this issue will continue to be investigated. 
Testing Arc Hydro Time Series Performance 
To quantify these findings, a thorough analysis was conducted using LCRA 
Hydromet data and the computers at CRWR.  The Hydromet data included 11 years of 
flow, stage, and precipitation data with a one-hour time interval, recorded at various 
locations throughout the Lower Colorado River basin.  This dataset included 
approximately 3,000,000 time series records (stored in the Arc Hydro time series format). 
The personal computer used for this analysis had a 3.2 GHz processor and 1.5 GB 
of RAM.  The SQL Server used for this analysis had dual 2.4 GHz processors and 1 GB 
of RAM.  The Hydromet data was loaded onto a personal geodatabase on the personal 
computer and onto an ArcSDE geodatabase on the SQL Server.  Once loaded, both of 
these data sources could be queried either from the Microsoft (MS) Access environment 
or the ArcGIS environment. 
Two queries were used to test the performance of these data sources.  The first 
query was a selection of all records whose FeatureID=14 that resulted in approximately 
 103
64,000 records.  The second query was a selection of all records whose TSTypeID=11 
that resulted in approximately 700,000 records. 
These queries were attempted using a number of different methods, which are 
listed below: 
1. ArcMap ?Select by Attribute? query 
2. ArcCatalog ?Load Data? query 
3. ArcToolbox/Model Builder ?Select Table? query 
4. MS Access ?Make Table? query 
5. Visual Basic query script 
As discussed previously, the first two methods, which represent the most common 
ArcGIS methods for querying data, were not successful under any circumstances.  The 
ArcGIS software crashed when either of these methods was attempted.  The third, fourth, 
and fifth, methods were successful.  However, it was determined that the fourth and fifth 
methods were effectively the same because query times for these two methods were 
virtually identical, and both methods used MS Access functionality.  In summary, there 
were two methods that were successful: 
1. ArcToolbox/Model Builder ?Select Table? query 
2. MS Access query 
Figure 5.7 shows query times for the two methods listed above: ?ArcToolbox? 
and ?MSAccess? queries.  These queries were performed on both the personal and SQL 
Server geodatabases.  In general, queries using the MS Access method were faster than 
queries using the ArcToolbox method.  Also, queries on the SQL server were faster than 
queries on the personal geodatabase.  For the large query (700,000 records) the advantage 
of using SQL Server appears to be relatively small, but this could be a result of the fact 
that the CRWR SQL Server has less RAM than the personal computer. 
 104
0
5
10
15
20
25
30
35
40
45
50
personal GDB personal GDB SQL GDB SQL GDB
ArcToolbox MSAccess ArcToolbox (SDE) MSAccess
Query Time (seconds)
64,000 Record Query
700,000 Record Query
 
Figure 5.7 ? Time series query performance under various conditions  
Evaluation of the Arc Hydro Time Series Format 
The Arc Hydro format was used extensively by this research.  In this format, all 
time series time/value combinations are stored in one table along with their geographic 
reference (FeatureID) and data type (TSTypeID).  The ability to relate time series data 
directly to their corresponding features proved to be one major advantage of the Arc 
Hydro time series format, especially when attempting to create time series animations. 
There are, however, limitations associated with the Arc Hydro time series format.  
One difficulty arises from the Arc Hydro concept of storing all time series data within 
just one table.  This creates two potential problems.  First, if all data must be stored 
within just one table, then that table may grow to a size that that hinders system 
performance.  Also, attempting to store permanent archived time series data in the same 
table where new time series data are being generated could produce a tenuous situation.  
If an error occurs while the new data is being generated, then potentially, the entire table 
of data could be lost (this is a particularly significant concern in the research 
 105
environment).  Therefore, for most time series work performed during this project, 
multiple time series tables were created in order to improve the stability and performance 
of the data model. 
In order to create time series animations using the Tracking Analyst, each unique 
time series type must be stored in a unique table.  If time series data of multiple types 
(multiple TSTypeIDs) are stored in the same table and related to the same feature, the 
Tracking Analyst will not be able to differentiate between the different data types.  
Therefore, when creating time series animations, it was generally necessary to export the 
relevant time series data into a unique, temporary time series table. 
Another limitation of the Arc Hydro time series is that it is not optimized to meet 
the needs of specific datasets.  In order to accommodate the widest range of data possible, 
each time series record uses data types that require considerable amounts of memory.  If 
the time series format was compacted, as shown in Table 5.1 (for example), using smaller 
data types, then the amount of disk space required would be cut by one third.  However, 
this format limits the accuracy and range of some of these variables. 
 
 
  Table 5.1:  Arc Hydro time series format: standard and compacted 
 106
 
5.1.3 Arc Hydro Toolset 
The Arc Hydro toolset includes many different sets of commands located under 
different menus.  Figure 5.8 shows the toolbar menu options.  For this research, only the 
?Terrain Processing?, ?Attribute Tools?, and ?Network Tools? were used extensively.  
An evaluation of these three sets of tools is included in this section.  In general, all of 
these tools yielded correct results.  However, this section discusses ways in which tools 
can be modified to make them more intuitive and useable. 
 
 
Figure 5.8 ? Arc Hydro toolbar 
Terrain Processing Tools 
These tools take a raster DEM and covert it into a set of vectorized watershed 
features, as discussed in Section 4.1.2.  The primary difficulty with these tools is the 
amount of time that they take to execute.  Many of these tools can take on the order of 
one-hour to complete.  At times, it is difficult to tell whether the tool is operating 
correctly or whether the program has crashed.  Also, because these tools require little user 
input, it would be advantageous to have the option to run these tools while the user is 
away (i.e. nights and weekends).  For these reasons, the following improvements to the 
terrain processing tools could be very beneficial: 
1. Create progress bars (Figure 5.9) that track the operation of these tools 
2. Create a ?master? tool that will run the entire series of individual terrain 
processing tools without the user present. 
 
 107
 
Figure 5.9 ? Progress Bar 
Attribute Tools 
These tools are used to assign Arc Hydro attributes such as HydroIDs and 
downstream lengths.  In general, these tools were very useable and very important to this 
project.  Most of the tools are discussed in further detail in the tutorial of Appendix D.  
One tool that could potentially be improved is the ?Store Area Outlets? tool, used to 
assign the HydroIDs of Watershed/Waterbody features to their respective 
HydroJunctions.  Using the current version of this tool, a search is performed in the 
vicinity of each Watershed/Waterbody to determine which HydroJunction most 
accurately reflects the area?s outlet.  However, this tool sometimes makes inaccurate 
HydroJunction assignments (i.e. a HydroJunction that is supposed to be assigned to a 
Waterbody ends up assigned to a Watershed instead).  If the tool was modified so that it 
only searches through HydroJunctions of a specific FType (which records whether the 
HydroJunction represents a Waterbody or Watershed), then many inaccurate assignments 
could be avoided. 
Another limitation of these tools is that they are not well documented in any 
publicly available literature.  Such documentation would be very important for users who 
are not familiar with Arc Hydro concepts.  Some documentation of these tools is included 
in Appendix D of this report. 
Network Tools 
 108
The network tools can be used to create schematic networks and to assign 
network flow directions.  For this project, no schematic network was created, but flow 
directions were assigned to the HydroEdge/HydroJunction network.  In general these 
flow directions are stored in two places: the ?FlowDir? field of the HydroEdge feature 
class and inside the geometric network class.  In addition to these sources of flow 
direction, the direction in which the HydroEdge lines were digitized may also represent 
the correct flow direction. The two tools used for assigning/transferring flow direction 
values are listed below: 
1.  ?Store Flow Direction? takes the flow direction values stored in the geometric 
network, and transfers these values to the FlowDir field in the HydroEdge 
feature class. 
2. ?Set Flow Direction? assigns flow direction values to the geometric network.  
This assignment may be based on the values stored in the FlowDir field, or it 
may be based on the direction in which the HydroEdges were originally 
digitized. 
The names ?Store Flow Direction? and ?Set Flow Direction? do not provide the 
user with an intuitive understanding of what each tool does.  In fact, confusion between 
the purposes of these two tools proved to be a nuisance throughout the course of this 
project.  It would be advantageous to replace these two tools with one concise and 
intuitive tool named ?Transfer Flow Direction?, which would have the ability to perform 
all desired flow direction value transfers.  The GUI for such a tool might look something 
like Figure 5.10 
 
 109
 
Figure 5.10 ? Prototype ?Transfer Flow Direction? GUI 
 110
 
5.2 HMS IDM RESULTS 
Data from the LCRA/Halff HEC-HMS model for the ?Llano River at Junction? 
were imported into the IDM to test its functionality.  Data from HMS text files, such as 
the basin and control files, could be imported into the IDM almost instantly.  DSS data 
could take longer, primarily due to the quantity of data that needed to be written to the 
geodatabase.  Figure 5.11 to 5.14 show ArcMap screen captures of the completed IDM. 
 
 
Figure 5.11 ? ArcMap view of the Llano at Junction HEC-HMS Basin 
 
 111
 
Figure 5.12 ? ArcMap view of initial loss values for Llano at Junction Basin 
 
Figure 5.13 ? ArcMap view of Snyder peaking times values for Llano at Junction Basin 
 112
 
Figure 5.14 ? A query of a paired data routing table for a reach in the Llano at Junction 
Basin 
The ability to use DSS time series within GIS was another important result of this 
project.  The time series component of this project has already been used in other 
research, including the Map2Map application, developed at CRWR, which takes a 
precipitation map and uses the HEC models to generate the resulting floodplain map 
(Robayo, 2004).  A query of time series in the HMS IDM is shown in Figure 5.15. 
 
 113
 
Figure 5.15 ? Query of time series data for a particular HMS Subbasin 
Using the HMS IDM and ESRI?s Tracking Analyst Extension, a time series 
animation was developed to display the changing level of rainfall and stream flow 
occurring during a storm event.  This was a relatively straightforward process, requiring 
little data manipulation.  Although, the relevant time series data did have to be selected, 
and extracted into a smaller table, with a HMSCode field.  Screenshots from this 
animation are shown in Figure 5.16 
 114
 
Figure 5.16 ? Time series animation of IDM data (1 hour time step) 
 115
 
5.3 FLOOD DAMAGE EVALUATION SYSTEM RESULTS 
The flood damage evaluation system was evaluated using two unique sections of 
the Lower Colorado River.  The first section tested was Lake Travis, which is a reservoir 
with a virtually flat water surface profile, relatively high sinuosity, and a large number of 
coves.  The second section tested was the Colorado River near Bastrop, which is an 
uncontrolled section of river with a relatively steep water surface profile (3/10,000 for 
100-year flood), moderate sinuosity, and a large number of coves.  
Floodplain maps 
The floodplain maps generated by this project are based on the same hydraulic 
modeling data used by Halff and Associates for the creation of their maps.  However, the 
land surface DEMs and cross sections were different.  The DEMs used by this project 
were derived by converting the TINs created by Halff and Associates into rasters of 
considerably lower resolution.  The cross sections used by this project were similar to 
those used by Halff, but modified as discussed in Section 4.3. 
A comparison of the floodplain maps generated by this project to the floodplain 
maps generated by the Halff project is shown in Figure 5.17.  This figure shows that at 
small scales, there is virtually no difference between the two floodplain maps.  However, 
at relatively large scales, slight variations in the lines can be discerned.  In fact, 
differences between the two maps can be as great as 8 meters (but are generally less than 
4 meters), as shown in Figure 5.18.   Also, when viewed at larger scales, the rough 
gridded edges of the floodplain polygon begin to show.  These rough edges are a result of 
the fact that the floodplain polygon was created based on a raster.  Rough edges can be 
avoided, however, as shown in Figure 5.18, by using the ArcGIS ?generalize? option.  
 116
The LCRA has the option to produce these maps using either the gridded or generalized 
method; there was no significant difference in performance. 
 
Figure 5.17 ? Comparison of Halff floodplain (red line) to research results (blue polygon) 
at different scales, Lake Travis 
 117
 
Figure 5.18 ? Comparison of different floodplain maps at large scale, Lake Travis 
As demonstrated by the preceding figures, the floodplain maps generated by the 
Halff method tend to be smoother and of slightly higher resolution.  However, it is 
suspected that any large differences between the maps (over 5 meters), is more a result of 
different grid orientations, than errors in the mapping procedures.  The primary advantage 
of the system developed by this research is the time that is saved in the map production 
process.  First, these maps are generated in around 3 minutes (depending upon computer 
hardware) compared to the many hours required by the Halff method of TIN intersection.  
Second, the method developed by this research does not require manual editing of cove 
areas.   
 118
Damage Reports 
Damage reports were also generated using the procedures developed by this 
research.  These results have not yet been compared to other damage studies.  However, 
the functionality of this Model Builder procedure has been well tested.  Lists of inundated 
structures were generated, and statistics tables were calculated to summarize the results.   
Figure 5.19 shows an example of results for the 2-year flood at Bastrop.  The fields 
shown in these tables are described in Figure 4.29. 
 
 
 
 
 
Figure 5.19 ? Flood statistics and a portion of the inundated structures list for the 2-year 
flood of the Colorado River at Bastrop 
 119
Visualization of Results 
The data that results from the flood damage evaluation system can be used in a 
number of ways.  It can be used in analysis of different flood control alternatives and in 
reports.  It can also be used to create effective GIS visualizations.  An example of such a 
visualization is shown in Figure 5.20.  This graphic was created using ESRI?s ArcScene, 
and required relatively little data manipulation. 
 
 
Figure 5.20 ? 3-D visualization of inundated structures on Lake Travis 
 120
 
Chapter 6:  Conclusions and Recommendations 
6.1 PROJECT SUMMARY 
This project examined different ways to apply Arc Hydro concepts to the Lower 
Colorado River basin.  First, the Arc Hydro Framework was populated with general 
information that describes the Llano River basin.  This process included the collection 
and transformation of existing GIS data and time series data maintained by the LCRA.  
The result of this work is a connected and manageable data repository based on the 
standardized Arc Hydro data format, which is now recognized nationwide. 
Next, an interface data model was developed to store information specific to a 
particular hydrologic computational model, HEC-HMS.  The resulting ?HMS IDM? is 
considerably more complex than the standard Arc Hydro data model because it reflects 
the entire HMS program.  Once developed, the IDM was tested with data from the 
LCRA?s existing HMS models.   
Finally, a GIS-based flood damage evaluation system was developed in order to 
provide a method for calculating flood analysis results based on terrain, structure, cross 
section, and HEC-RAS output data.  Furthermore, a new data model was developed in 
order to store the input, output, and archived data that are a part of this system.  ESRI?s 
Model Builder system was utilized to develop the routines necessary to automate the 
analysis and archiving process. 
To improve the results of the flood damage evaluation system, it was 
recommended that cross section geometries be modified to produce smoother, more 
accurate, and more complete water surface DEMs.  This report includes the methods and 
concepts behind this modification process.  In fact, this modification was completed for 
 121
the Lake Travis and Bastrop study areas of the Lower Colorado River basin.  Finally, the 
flood maps generated by this research were compared to flood maps generated by a 
previous study. 
6.2 PROJECT CONCLUSIONS 
A number of conclusions were reached throughout the course of this project.  A 
summary of these conclusions is included as follows: 
Arc Hydro Framework and Time Series 
1. The Arc Hydro Framework provides considerable advantages over the 
traditional, structureless methods of storing GIS hydrological data.  It provides a 
method of stream addressing, querying of related data, and the ability to trace 
and select upstream and downstream on the stream network.  The framework 
also provides a basic data structure which H&H models and other analysis tools 
may be designed in the future.    
2. There is no reason to believe that the implementation of an Arc Hydro model for 
the entire Lower Colorado River basin would not also be successful.  The 
methodologies developed for the Llano River basin are equally applicable to a 
basin of larger-scale.  Throughout this project, it was determined that the Arc 
Hydro data model was most effective for storing permanent, general data 
describing the river basin, but not as effective for storing the more particular and 
dynamic data produced by computational models. 
3. Limitations were discovered when working with time series data.  For small data 
sets (generally less than 1,000,000 records in size) the Arc Hydro format was 
effective,in that the data could be queried and manipulated efficiently.  However, 
time series datasets of larger size could not be used in the ArcMap environment, 
 122
regardless of whether the data were stored the personal database the server 
database (SQL).  Hardware limitations were the primary reason for these 
deficiencies, although in the case of the server database, a shortcoming in the 
ArcSDE software was the greatest problem.  Queries outside of the ArcMap 
environment, using either ArcToolbox or MS Access proved to be successful 
methods for working with these larger datasets.  
4. The Arc Hydro time series format is effective because it can store a wide range 
of different time series types.  Conversely, because of the generality of this 
format, it is not optimized for any particular type of data.  Storing all time series 
data within one table provides a simple data structure, but it can also decrease 
system performance, reliability, and ease of use.   
5. The Arc Hydro tools produce accurate results and perform reasonably well.  
However, a few modifications have been suggested in order to make the tools 
more intuitive and require less user input. 
Interface Data Model  
6. This was one of the first times that a computational model designed 
independently of GIS has been fit entirely into the ArcGIS world.  The interface 
data model (IDM) has the ability to store all of the information required to run a 
HMS project.  It also has the ability to store all of a project?s results. 
7. At the present, the primary benefit of the IDM is the ability to maintain and 
archive model results within a geodatabase format.  The geodatabase format is 
useful because data within it can be easily queried and manipulated by the user, 
and because spatial data can be visualized using ArcMap. 
 123
Flood Damage Evaluation System 
8. Modification of cross section geometry was found to be the most efficient way 
of correcting inadequacies in floodplain mapping.  Cove areas could be mapped 
by the extension of existing cross sections and/or the addition of new cross 
sections.  River sinuosity problems could be corrected by the clipping and toeing 
of existing cross sections on the inside of river bends. 
9. ESRI?s new Model Builder system proved effective for generating floodplain 
maps and damage reports, and for managing and archiving these results.   
10. Use of a standardized data model greatly reduced the complexity of the Model 
Builder routines.  This resulted in simple GUI interfaces that require only 
minimal amounts of user input in order to perform calculations. 
6.3 FUTURE RESEARCH OPPORTUNITIES 
This project has demonstrated the potential for further research in a number of 
areas.  One issue that needs further exploration is how to handle large time series datasets 
within the GIS environment.  Whether these datasets are stored directly in a geodatabase, 
or in some other format that is accessible by GIS, these data are necessary for performing 
hydrologic simulations, and thus for creating a hydrologic information system. 
In the long term, the HMS IDM could be used for performing simulations as well 
as for storing model data.  The IDM is a potential platform from which new HMS models 
could be created and from which existing models could be run and results visualized.  To 
accomplish these goals, however, data transfer procedures and codes must be developed.  
An even more ambitious goal would be to modify the HMS program to run directly on 
the geodatabase instead of the text files and DSS files currently used. 
The development of a more formal data model for the flood damage evaluation 
system could also be an important goal.  This development would include a UML model, 
 124
and more standardized field names.  If multiple organizations would agree to use a 
standardized data model for flood studies, then the results of these studies would be more 
comparable.  Furthermore, programs like the Model Builder routines developed by this 
project, would be applicable to all organizations that use the same data model.   
 Further study of the advantages of using a spatially distributed system to 
determine flood damages could also be revealing.  As discussed in Chapter 2, the 
National Research Council believes that a spatially distributed damage analysis could be 
an improvement over the traditional lumped model.  A more thorough comparison of the 
two methods could potentially verify this recommendation. 
6.4 OVER-ALL PROJECT SIGNIFICANCE 
Although this project involved three different research goals: (1) an Arc Hydro 
data model, (2) a HMS interface data model, and (3) a GIS-based flood damage 
evaluation system; the underlying concepts are the same.  This project involved GIS and 
standardized data models.  Standardized data models provide a data format around which 
computational programs can be designed, and GIS provides an effective method for 
viewing and analyzing the spatial variation in the data.  These are the reasons Arc Hydro 
was created, and these are the principles that guided this research.  This project has 
verified, utilized, and expanded the potential of these underlying concepts. 
 125
 
 
Appendix A:  ?LCRA World? GIS Repository 
 126
ArcMap ?LCRA World? data menu 
 
 
 
LCRA GIS Repository Layer List 
Name 
Aerial Mapping Extent This data set shows the extent of the contour data which was produced from the 
Riverfront aerial images by the Aerial Photography Reduction Company (ADR). The outline is defining the 
contract line.  
Index Transmission Line Imagery This is a polygon index of Transmission Services Aerial imagery.  
Aquifer Major This major aquifers of Texas are delineated according to the Hydrologic Monitoring Section of 
the Texas Water Development Board. The map originates from 1:250,000 Geology maps of Texas published 
by the Bureau of Economic.  
Aquifer Minor This major aquifers of Texas are delineated according to the Hydrologic Monitoring Section of 
the Texas Water Development Board. The map originates from 1:250,000 Geology maps of Texas published 
by the Bureau of Economic.  
Parcels - Austin County Austin County Parcels from The Austin Central Appraisal District..  
Parcels - Bastrop County  
Black-capped Vireo Zone A habitat assessment for the Black-Capped Vireo was conducted by PBS&J as part 
of an Environmental Impact Statement conducted for the Northern Hays County Service Area of the LCRA.  
Parcels - Burnet County The dataset was created in congruence with the Phase I Mapping Project of the 
upper river basin by WaterCo within the Lower Colorado River Authority (LCRA). The Data was created from a 
combination of digitizing final tax plats and Microstation line data from the Burnet County Appraisal District 
(BCAD). The Polygons were attributed with a seventeen (17) digit Parcel ID number (PID). that references a 
Tax Reference number or Tax Rnumber. The scale of the microstation data was recieved in 1:200 and 1:400 
formats. The final tax plats varied from 1:50 to 1:200 foot scales. Contact the Burnet County Appraisal 
District for Dates concerning their data.  
Parcels ? Caldwell County  
 127
CAPCO Imagery 2002 REQUIRED: A brief narrative summary of the data set.  
Census Block Groups ESRI (100k) U.S. Block Groups represents the Census block groups of United States. 
Census Tracts ESRI (100k) U.S. Tracts represents the U.S. Census tracts of the United States.  
Texas City Boundaries The city limits were selected from the TNRIS.  
Texas City Points The GNIS contains locative information about almost 2 million physical and cultural 
features located throughout the US. TX_GNIS contains a clipped out segment of these names for Texas.Texas 
city points were obtained from this data.  
Parcels - Colorado County The dataset was created in congruence with the Phase II Mapping Project of the 
lower river basin by WaterCo within the Lower Colorado River Authority (LCRA). The Data was created from a 
combination of digitizing hard copy maps from Colorado County Appraisal District (CCAD). The Polygons were 
attributed with a thirteen (13) digit Parcel ID number (PID). that references a Tax Reference number or Tax 
Rnumber. The Hard copy maps are 1978 Soil Conservation Service aerials with parcels hand drawn on the 
photos.  
Parcels - Comal County  
US 108th Congressional Districts ESRI (100k) U.S. 108th Congressional Districts represents an interim 
version of the political boundaries for the U.S. 108th Congressional Districts. The U.S. Census Bureau will 
release the official 108th Congressional District boundaries later in 2003.  
Contour Mapping Extent This data set shows the extent of the contour data which was produced from the 
Riverfront aerial images by the Aerial Photography Reduction Company (ADR). The outline is defining the 
contract line.  
DOQQs 1 meter REQUIRED: A brief narrative summary of the data set.  
USGS Quads (24k) REQUIRED: A brief narrative summary of the data set.  
Ecological Regions Coverage of the Ecoregions are based on perceived patterns of a combination of causal 
and integrative factors including land use, land surface form, potential natural vegetation, and soils (Omernik, 
1987).  
Electric Service Area The LCRA service area is an area that is determined by the area of 11 Electric 
Cooperatives-. LCRA Wholesale customers. The coverage contains 33 cities and the areas that are certified to 
other companies inside the LCRA electric service area.  
Colorado River EPA (100k) This coverage represents the Colorado River located in the State of Texas.  
Lakes EPA (100k) The lakes data was clipped from reg12_83, a rf3 file from the EPA. 1:100,000. This 
coverage represents lakes located in the State of Texas within the LCRA Service Area.  
Parcels - Fayette County The dataset was created in congruence with the Phase II Mapping Project of the 
lower river basin by WaterCo within the Lower Colorado River Authority (LCRA). The Data was created from a 
combination of digitizing hard copy maps from Fayette County Appraisal District (FCAD). The Polygons were 
attributed with a 6 (6) digit Parcel ID number (PID). This references a Tax Reference number or Tax Rnumber 
on the Appraisal database. The Hard copy maps appear to be Oil and gas maps with parcels and the owners 
name on the maps.  
Golden Cheek Warbler Zone A habitat assessment for the Golden-Cheeked Warbler was conducted by 
PBS&J as part of an Environmental Impact Statement conducted for the Northern Hays County Service Area of 
the LCRA.  
LCRA Harn Network This coverage was developed to aid in mapping all LCRA Survey Projects to a consistent 
GPS derived coordinate base. This GPS network is constrained to 12 NGS A&B order GPS Points and over 100 
NGS Benchmarks. This network will support mapping accuracies of +- 2cm horizontal positioning and +- 5cm 
vertical positioning. This sub HARN network cover most of LCRA's Central Texas Service Area.  
High Water Marks (June 1997) These points were surveyed by LCRA. They are high water and debris 
marks on the Llano and Colorado Rivers as a result of the flooding of the communities along the Llano and 
Colorado rivers in June of 1997.  
High Water Marks (Llano 2000) These points were surveyed by LCRA. They are high water and debris 
marks on the Colorado River as a result of the flooding of the communities along the Colorado River in 2000.  
High Water Marks (October 1998) These points were surveyed by LCRA. They are high water and debris 
marks on the Colorado Rivers as a result of the flooding of the communities along the Colorado river in 
October 1998.  
High Water Marks (Walnut Creek 1995) These points were surveyed by Terry Nygaard with the Surveying 
and Mapping Department (LCRA). They are high water and debris marks in the Walnut Creek area as a result 
from the flooding of the community of Sandy Harbor in 1995.  
High Water Marks (December 1991) HIGH WATER MARKS CHRISTMAS FLOOD OF 1991 NOTE 1 : Files 
LCOL013A and LCOL014A have **TBM's set to locate high water marks by Sean Maijala or George Fears. 
NOTE 2 : The file names shown are Surveying & Mapping project files and should be used when requesting 
Mapping. NOTE 3 : Coordinates shown are NAD 83 Texas Central Zone (4203) State Plane coordinates in US 
Survey Feet. NOTE 4 : Vertical Datum is NGVD 29 NOTE 5 : Coordinates derived using Real Time DGPS (+-1 
Meter)  
 128
Hydro GDT Arcs REQUIRED: A brief narrative summary of the data set.  
Hydro GDT Polys REQUIRED: A brief narrative summary of the data set.  
Hydro Arcs Txdot (24k) Stream and shoreline arcs within the state of Texas. Lines digitized by Texas Dept. 
of Transportation (TxDOT) and extracted from county map series files by Texas General Land Office (GLO) 
personnel. Attribute values added by GLO personnel.  
Hydro Polys Txdot (24k) Stream and shoreline arcs within the state of Texas. Lines digitized by Texas Dept. 
of Transportation (TxDOT) and extracted from county map series files by Texas General Land Office (GLO) 
personnel. Attribute values added by GLO personnel.  
Hydromet Stations LCRA The Hydromet data is a point coverage of gauge stations within the Colorado River 
watershed. Hydromet allows remote interrogation of a networked system of twent-one self-reporting rainfall 
gages, twenty-one remotely monitored streamflow gages, and six reservoir elevation gages. Twenty of the 
streamflow gages also gather rainfall information, giving a total of forty-one rainfall sites. This system covers 
the Lower Colorado River, its three major and three minor tributaries, as well as the Highland Lakes. 
Hydromet allows each station to be polled both on a user-set interval, usually every hour, and independently 
at any other time. The real time data is logged and maintained on an on-line historical database for one year. 
This data is accessible for operations models, historical analyses or other needs. Data set was acquired from 
David Murdock.  
Index DOQQ 1m (24k) This index is used to access the DOQQ images.  
Index Quads USGS (24k) This file shows the position of the 7.5 minute USGS quads over Texas. 4376 
quads cover the state.  
Parcels - Kendall County Kendall County Parcel Information. Data Was Acquired from Kendall Central 
Appraisal District. Origin projection State plane South Central Zone Nad 83 feet.  
Parcels - Kerr County Kerr County Appraisal District Parcel and Owner information.  
LCRA Parks LCRA Parks is a composite layer created from a variety of sources. It primarily comes from the 
LIUP (LCRA parcels), but it has been adjusted according to the LCRA Parks Department information. The final 
product adequately displays the park boundaries and accurately corresponds with the Parks Department's 
non-spatial databases.  
Parcels - Lee County A brief narrative summary of the data set. REQUIRED.  
Parcels - Llano County The dataset was created in congruence with the Phase I Mapping Project of the 
upper river basin by WaterCo within the Lower Colorado River Authority (LCRA). The Data was created from a 
combination of digitizing final tax plats and Microstation line data from the LLano County Appraisal District 
(LCAD). The Polygons were attributed with a seventeen (16) digit Parcel ID number (PID). that references a 
Tax Reference number or Tax Rnumber. The final tax plats varied from 1:50 to 1:200 foot scales. Contact the 
Llano County Appraisal District for Dates concerning their data.  
Parcels - Matagorda County The dataset was created in congruence with the Phase II Mapping Project of 
the lower river basin by WaterCo within the Lower Colorado River Authority (LCRA). The Data was created by 
acquiring hard copy maps from the Matagorda County Appraisal District. The CAD Hard copy maps contain 
linework andand parcel numbers for each parcel at a scale of 1" = 500' or 1" = 1000'.  
Index Metcalfe Surveys A brief narrative summary of the data set. REQUIRED.  
NHD Hydro Arcs (100k) The National Hydrography Dataset (NHD) is a feature-based database that 
interconnects and uniquely identifies the stream segments or reaches that comprise the nations surface water 
drainage system. It is based initially on the content of the U.S. Geological Survey 1:100,000-scale Digital Line 
Graph (DLG) hydrography data, integrated with reach-related information from the U.S. Environmental 
Protection Agency Reach File Version 3.0 (RF3). More specifically, it contains reach codes for networked 
features and isolated lakes, flow direction, names, stream level, and centerline representations for areal water 
bodies. Reaches are also defined to represent waterbodies and the approximate shorelines of the Great Lakes, 
the Atlantic and Pacific Oceans, and the Gulf of Mexico. The NHD also incorporates the National Spatial Data 
Infrastructure framework criteria set out by the Federal Geographic Data Committee.  
NHD Hydro Polys (100k) The National Hydrography Dataset (NHD) is a feature-based database that 
interconnects and uniquely identifies the stream segments or reaches that comprise the nations surface water 
drainage system. It is based initially on the content of the U.S. Geological Survey 1:100,000-scale Digital Line 
Graph (DLG) hydrography data, integrated with reach-related information from the U.S. Environmental 
Protection Agency Reach File Version 3.0 (RF3). More specifically, it contains reach codes for networked 
features and isolated lakes, flow direction, names, stream level, and centerline representations for areal water 
bodies. Reaches are also defined to represent waterbodies and the approximate shorelines of the Great Lakes, 
the Atlantic and Pacific Oceans, and the Gulf of Mexico. The NHD also incorporates the National Spatial Data 
Infrastructure framework criteria set out by the Federal Geographic Data Committee.  
Original Texas Land Surveys (24k) This dataset is the Railroad Commission's interpretation of the Original 
Texas Land Surveys boundaries and bay tracts. The dataset was derived from the Texas General Land Office 
(GLO) county maps, the GLO Abstract of Original Land Titles: Volumes and Supplements, and the GLO maps 
of State-Owned Submerged Lands of the Texas Gulf Coast (bay tracts). The GLO county maps, showing the 
boundaries of the original land grants of the State of Texas, were compiled and drawn by General Land Office 
 129
draftsmen. This dataset is a digital interpretation of the geographic placement of the original land grants and 
bay area tracts depicted on these GLO maps and is not a legal survey product.  
Parks GDT REQUIRED: A brief narrative summary of the data set.  
Phone Area Codes ESRI (100k) U.S. Telephone Area Code Boundaries represents the telephone area codes 
for United States. They are also known as Numbering Plan Areas (NPA).  
Railroads GDT REQUIRED: A brief narrative summary of the data set.  
Railroads Txdot (24k) The Rail Network is a comprehensive database of the nation's railway system at the 
1:100,000 scale.  
Recreational Areas GDT REQUIRED: A brief narrative summary of the data set.  
Riverfront Bridges (2400) The scope of the project is to map the Colorado river corridor from San Saba 
County to Matagorda County Texas. Contour mapping includes: 1) Obtaining aerial photographs (Flight Scale: 
1"=1400' and mapping scale is 1" = 200') of the Colorado River (2-19-98 thru 2-19-99); 2) In non-urban 
areas, preparing digital mapping to national map accuracy standards (4-foot contours up to one contour 
beyond the 500-year flood zone) and interpolating this to 2 - foot contours; 3) In five urban areas prepare 
digital mapping to national map accuracy standards (2-foot contours interpolated to 1-foot); 4) Producing a 
digital elevation model for the area extending 1,000 feet beyond the 500-year flood zone; Preparing digital 
orthophotography for the entire area; 6) Preparing planimetrics (bridge outlines) for all visible structures.  
Riverfront Buildings (2400) The scope of the project is to map the Colorado river corridor from San Saba 
County to Matagorda County Texas. Contour mapping includes: 1) Obtaining aerial photographs (Flight Scale: 
1"=1400' and mapping scale is 1" = 200') of the Colorado River (2-19-98 thru 2-19-99); 2) In non-urban 
areas, preparing digital mapping to national map accuracy standards (4-foot contours up to one contour 
beyond the 500-year flood zone) and interpolating this to 2 - foot contours; 3) In five urban areas prepare 
digital mapping to national map accuracy standards (2-foot contours interpolated to 1-foot); 4) Producing a 
digital elevation model for the area extending 1,000 feet beyond the 500-year flood zone; Preparing digital 
orthophotography for the entire area; 6) Preparing planimetrics (building outlines) for all visible structures.  
Riverfront Contours REQUIRED: A brief narrative summary of the data set.  
Riverfront Docks (2400) The scope of the project is to map the Colorado river corridor from San Saba 
County to Matagorda County Texas. Contour mapping includes: 1) Obtaining aerial photographs (Flight Scale: 
1"=1400' and mapping scale is 1" = 200') of the Colorado River (2-19-98 thru 2-19-99); 2) In non-urban 
areas, preparing digital mapping to national map accuracy standards (4-foot contours up to one contour 
beyond the 500-year flood zone) and interpolating this to 2 - foot contours; 3) In five urban areas prepare 
digital mapping to national map accuracy standards (2-foot contours interpolated to 1-foot); 4) Producing a 
digital elevation model for the area extending 1,000 feet beyond the 500-year flood zone; Preparing digital 
orthophotography for the entire area; 6) Preparing planimetrics (Dock & Pier outlines) for all visible 
structures.  
Riverfront Drainage (2400) The scope of the project is to map the Colorado river corridor from San Saba 
County to Matagorda County Texas. Contour mapping includes: 1) Obtaining aerial photographs (Flight Scale: 
1"=1400' and mapping scale is 1" = 200') of the Colorado River (2-19-98 thru 2-19-99); 2) In non-urban 
areas, preparing digital mapping to national map accuracy standards (4-foot contours up to one contour 
beyond the 500-year flood zone) and interpolating this to 2 - foot contours; 3) In five urban areas prepare 
digital mapping to national map accuracy standards (2-foot contours interpolated to 1-foot); 4) Producing a 
digital elevation model for the area extending 1,000 feet beyond the 500-year flood zone; Preparing digital 
orthophotography for the entire area; 6) Preparing planimetrics (Linear drainage, e.g. creeks & streams) for 
all visible features.  
Riverfront Imagery REQUIRED: A brief narrative summary of the data set.  
Riverfront Index A brief narrative summary of the data set. REQUIRED.  
Riverfront Roads (2400) The scope of the project is to map the Colorado river corridor from San Saba 
County to Matagorda County Texas. Contour mapping includes: 1) Obtaining aerial photographs (Flight Scale: 
1"=1400' and mapping scale is 1" = 200') of the Colorado River (2-19-98 thru 2-19-99); 2) In non-urban 
areas, preparing digital mapping to national map accuracy standards (4-foot contours up to one contour 
beyond the 500-year flood zone) and interpolating this to 2 - foot contours; 3) In five urban areas prepare 
digital mapping to national map accuracy standards (2-foot contours interpolated to 1-foot); 4) Producing a 
digital elevation model for the area extending 1,000 feet beyond the 500-year flood zone; Preparing digital 
orthophotography for the entire area; 6) Preparing planimetrics (roads & centerlines) for all visible features.  
Riverfront Spots (2400) The scope of the project is to map the Colorado river corridor from San Saba 
County to Matagorda County Texas. Contour mapping includes: 1) Obtaining aerial photographs (Flight Scale: 
1"=1400' and mapping scale is 1" = 200') of the Colorado River (2-19-98 thru 2-19-99); 2) In non-urban 
areas, preparing digital mapping to national map accuracy standards (4-foot contours up to one contour 
beyond the 500-year flood zone) and interpolating this to 2 - foot contours; 3) In five urban areas prepare 
digital mapping to national map accuracy standards (2-foot contours interpolated to 1-foot); 4) Producing a 
digital elevation model for the area extending 1,000 feet beyond the 500-year flood zone; Preparing digital 
orthophotography for the entire area; 6) Preparing planimetrics Spot Elevations).  
 130
Riverfront Waterbodies (2400) The scope of the project is to map the Colorado river corridor from San 
Saba County to Matagorda County Texas. Contour mapping includes: 1) Obtaining aerial photographs (Flight 
Scale: 1"=1400' and mapping scale is 1" = 200') of the Colorado River (2-19-98 thru 2-19-99); 2) In non-
urban areas, preparing digital mapping to national map accuracy standards (4-foot contours up to one contour 
beyond the 500-year flood zone) and interpolating this to 2 - foot contours; 3) In five urban areas prepare 
digital mapping to national map accuracy standards (2-foot contours interpolated to 1-foot); 4) Producing a 
digital elevation model for the area extending 1,000 feet beyond the 500-year flood zone; Preparing digital 
orthophotography for the entire area; 6) Preparing planimetrics Water Body outlines) for all visible features.  
Roads ESRI - Interstate Hwys U.S. Major Roads represents interstate, U.S. and state highways, major 
streets, and other major thoroughfares within the United States.  
Roads ESRI - State and Minor Hwys U.S. Major Roads represents interstate, U.S. and state highways, 
major streets, and other major thoroughfares within the United States.  
Roads ESRI - US Hwys U.S. Major Roads represents interstate, U.S. and state highways, major streets, and 
other major thoroughfares within the United States.  
Roads GDT - Statewide REQUIRED: A brief narrative summary of the data set.  
Roads 911 - New World Systems REQUIRED: A brief narrative summary of the data set.  
Texas School District Boundaries 2003 Texas public school district boundaries.  
Texas Public School Locations 2003 All public schools in Texas  
Stratmap Cities (24k) The statewide Texas boundary dataset is one component of the Texas Strategic 
Mapping Program (StratMap). The StratMap program developed seven digital base map, or " Framework," 
layers for Texas. StratMap is managed by the Texas Natural Resources Information System (TNRIS), a 
division of the Texas Water Development Board (TWDB). All data produced through StratMap are available in 
the public domain. The StratMap boundary dataset produced files corresponding to multi-county councils of 
government across Texas as well as a statewide dataset. Each boundary file has five themes including state, 
county, city, parks, and other (i.e. federal lands, landmarks, country clubs). The data sources for each council 
of government coverage vary but could include digital orthophoto quads (DOQs), USGS digital raster graphics 
(DRGs), Texas Department of Transportation data, and local data from the council of governments or its 
component governments. The attribute coding scheme is designed to accommodate several basic cartographic 
data categories such as feature type, feature name, jurisdiction entity, data source used in feature collection, 
data source date and revision date(s) if applicable.  
Stratmap COGs (24k) The statewide Texas boundary dataset is one component of the Texas Strategic 
Mapping Program (StratMap). The StratMap program developed seven digital base map, or " Framework," 
layers for Texas. StratMap is managed by the Texas Natural Resources Information System (TNRIS), a 
division of the Texas Water Development Board (TWDB). All data produced through StratMap are available in 
the public domain. The StratMap boundary dataset produced files corresponding to multi-county councils of 
government across Texas as well as a statewide dataset. Each boundary file has five themes including state, 
county, city, parks, and other (i.e. federal lands, landmarks, country clubs). The data sources for each council 
of government coverage vary but could include digital orthophoto quads (DOQs), USGS digital raster graphics 
(DRGs), Texas Department of Transportation data, and local data from the council of governments or its 
component governments. The attribute coding scheme is designed to accommodate several basic cartographic 
data categories such as feature type, feature name, jurisdiction entity, data source used in feature collection, 
data source date and revision date(s) if applicable.  
Stratmap Counties (24k) The statewide Texas boundary dataset is one component of the Texas Strategic 
Mapping Program (StratMap). The StratMap program developed seven digital base map, or " Framework," 
layers for Texas. StratMap is managed by the Texas Natural Resources Information System (TNRIS), a 
division of the Texas Water Development Board (TWDB). All data produced through StratMap are available in 
the public domain. The StratMap boundary dataset produced files corresponding to multi-county councils of 
government across Texas as well as a statewide dataset. Each boundary file has five themes including state, 
county, city, parks, and other (i.e. federal lands, landmarks, country clubs). The data sources for each council 
of government coverage vary but could include digital orthophoto quads (DOQs), USGS digital raster graphics 
(DRGs), Texas Department of Transportation data, and local data from the council of governments or its 
component governments. The attribute coding scheme is designed to accommodate several basic cartographic 
data categories such as feature type, feature name, jurisdiction entity, data source used in feature collection, 
data source date and revision date(s) if applicable.  
Stratmap Other Boundaries (24k) The statewide Texas boundary dataset is one component of the Texas 
Strategic Mapping Program (StratMap). The StratMap program developed seven digital base map, or " 
Framework," layers for Texas. StratMap is managed by the Texas Natural Resources Information System 
(TNRIS), a division of the Texas Water Development Board (TWDB). All data produced through StratMap are 
available in the public domain. The StratMap boundary dataset produced files corresponding to multi-county 
councils of government across Texas as well as a statewide dataset. Each boundary file has five themes 
including state, county, city, parks, and other (i.e. federal lands, landmarks, country clubs). The data sources 
for each council of government coverage vary but could include digital orthophoto quads (DOQs), USGS digital 
raster graphics (DRGs), Texas Department of Transportation data, and local data from the council of 
 131
governments or its component governments. The attribute coding scheme is designed to accommodate 
several basic cartographic data categories such as feature type, feature name, jurisdiction entity, data source 
used in feature collection, data source date and revision date(s) if applicable.  
Stratmap Parks (24k) The statewide Texas boundary dataset is one component of the Texas Strategic 
Mapping Program (StratMap). The StratMap program developed seven digital base map, or " Framework," 
layers for Texas. StratMap is managed by the Texas Natural Resources Information System (TNRIS), a 
division of the Texas Water Development Board (TWDB). All data produced through StratMap are available in 
the public domain. The StratMap boundary dataset produced files corresponding to multi-county councils of 
government across Texas as well as a statewide dataset. Each boundary file has five themes including state, 
county, city, parks, and other (i.e. federal lands, landmarks, country clubs). The data sources for each council 
of government coverage vary but could include digital orthophoto quads (DOQs), USGS digital raster graphics 
(DRGs), Texas Department of Transportation data, and local data from the council of governments or its 
component governments. The attribute coding scheme is designed to accommodate several basic cartographic 
data categories such as feature type, feature name, jurisdiction entity, data source used in feature collection, 
data source date and revision date(s) if applicable.  
Stream Segments Stream segments of the Colorado River Basin. The EPA developed the stream 
identification numbers and boundaries.  
Substations LCRA This coverage contains LCRA facilities associated with the Department of Tensco, and all 
intrests in Cooperative substaions in the LCRA Electric Service area. The point coverage contains Substations, 
Switches, Taps. This data is of Current data and Does not reflect Historical facilities that no longer exist, no 
longer have metering points, or materials present in the facility.  
Substations LCRA Owned This coverage contains LCRA Substation properties in the LCRA Electric Service 
area.  
Hospitals TDH Hospital Locations in Texas  
Transmission Easements LCRA This data set includes those electric transmission line easements owned by 
Transmission Services Corporation.  
Transmission Easements Amendments LCRA This data set includes those electric transmission line 
amendments owned by Transmission Services Corporation.  
Transmission Lines LCRA This dataset represents those electric transmission lines considered part of the 
LCRA electric transmission system. Included in this data set are both LCRA owned/operated lines and Coop 
owned/operated lines.  
Transmission - T136 REQUIRED: A brief narrative summary of the data set.  
Transmission - T146 REQUIRED: A brief narrative summary of the data set.  
Transmission - T150 REQUIRED: A brief narrative summary of the data set.  
Transmission - T201, T205, T233 REQUIRED: A brief narrative summary of the data set.  
Transmission - T266 REQUIRED: A brief narrative summary of the data set.  
Transmission - T270 REQUIRED: A brief narrative summary of the data set.  
Transmission - T315 REQUIRED: A brief narrative summary of the data set.  
Transmission - T358 REQUIRED: A brief narrative summary of the data set.  
Transmission - T359 REQUIRED: A brief narrative summary of the data set.  
Transmission - T360 REQUIRED: A brief narrative summary of the data set.  
Transmission - T374 REQUIRED: A brief narrative summary of the data set.  
Transmission - T381 REQUIRED: A brief narrative summary of the data set.  
Transmission - T391 REQUIRED: A brief narrative summary of the data set.  
Transmission - T392 REQUIRED: A brief narrative summary of the data set.  
Transmission - T400 REQUIRED: A brief narrative summary of the data set.  
Transmission - T413 REQUIRED: A brief narrative summary of the data set.  
Transmission - T438 REQUIRED: A brief narrative summary of the data set.  
Transmission - T459 REQUIRED: A brief narrative summary of the data set.  
Parcels - Travis County The dataset was created in congruence with the Phase I Mapping Project of the 
upper river basin by WaterCo within the Lower Colorado River Authority (LCRA). The Data was created from 
1:100 and 1:400 raster based Travis County Appraisal District tax maps. Heads up digitizing was used to 
capture the parcel boundries.  
Texas House Districts 2002 Texas House districts for the year 2002 elections, as ordered by US District 
Court for the Eastern District of Texas  
Texas Senate Districts Texas Senate districts for the year 2002 elections, as adopted by the Texas 
Legislative Redistricting Board  
County Boundaries Txdot - Coast Lines (24k) Source data was obtained from the Texas Department of 
Transportation and processed into a state-wide coverage by TNRIS.  
Councils of Government Txdot (24k) Texas counties digitized from Texas department of Transportation 
 132
county highway maps. These include roads, rivers, and city boundaries. Originally digitized from USGS quads 
and continuously updated. Coverages do not include features such as contours, fence lines, small creeks, 
electrical lines, and pipelines. Number of files range fron 4 to 25+ per county. Amount of storage needed per 
county is 150 kb to 30 mb.  
County Boundaries Txdot (24k) Texas counties digitized from Texas department of Transportation county 
highway maps. These include roads, rivers, and city boundaries. Originally digitized from USGS quads and 
continuously updated. Coverages do not include features such as contours, fence lines, small creeks, electrical 
lines, and pipelines. Number of files range fron 4 to 25+ per county. Amount of storage needed per county is 
150 kb to 30 mb.  
LCRA Service Area Txdot (24k) Texas counties digitized from Texas department of Transportation county 
highway maps. These include roads, rivers, and city boundaries. Originally digitized from USGS quads and 
continuously updated. Coverages do not include features such as contours, fence lines, small creeks, electrical 
lines, and pipelines. Number of files range fron 4 to 25+ per county. Amount of storage needed per county is 
150 kb to 30 mb.  
LCRA Statutory District Txdot (24k) Texas counties digitized from Texas department of Transportation 
county highway maps. These include roads, rivers, and city boundaries. Originally digitized from USGS quads 
and continuously updated. Coverages do not include features such as contours, fence lines, small creeks, 
electrical lines, and pipelines. Number of files range fron 4 to 25+ per county. Amount of storage needed per 
county is 150 kb to 30 mb.  
State of Texas Txdot (24k) Texas counties digitized from Texas department of Transportation county 
highway maps. These include roads, rivers, and city boundaries. Originally digitized from USGS quads and 
continuously updated. Coverages do not include features such as contours, fence lines, small creeks, electrical 
lines, and pipelines. Number of files range fron 4 to 25+ per county. Amount of storage needed per county is 
150 kb to 30 mb.  
Parcels - Washington County Washington Central Appraisal District Parcels acquired from the Washington 
County IMS website connection clear.tamu.edu  
Water Service Area LCRA (24k) This coverage represents the Lower Colorado River Authorities water 
service boundary at a resolution of 1:24,000. The boundary is a composite area described by the boundaries 
of the watershed that contributes inflow to the Colorado River below the intersection of Coleman, Brown and 
McCulloch counties, and the LCRA 10-County statutory district which include the counties of Blanco, Burnet, 
Llano, Travis, Bastrop, Fayette, Colorado,Wharton, San Saba and Matagorda. Within this boundary, the LCRA 
has the rights to control, store and preserve the waters of the Colorado River.  
WTC Imagery The data set provides color aerial photography.  
Watersheds - Colorado River Based on the USGS Hydrologic Unit Code maps prepared in conjunction with 
the U.S. Water Resources Council at a scale of 1:500,000. Subbasins, as defined by USGS, have been 
combined to create 11 subwatersheds within the Colorado River watershed. Watershed boundaries have been 
edited by EP Staff.  
Watersheds - Sub - Colorado River Based on the USGS Hydrologic Unit Code maps prepared in conjunction 
with the U.S. Water Resources Council at a scale of 1:500,000. Subbasins, as defined by USGS, have been 
combined to create 11 subwatersheds within the Colorado River watershed. Watershed boundaries have been 
edited by EP Staff.  
Parcels - Wharton County The dataset was created in congruence with the Phase II Mapping Project of the 
lower river basin by WaterCo within the Lower Colorado River Authority (LCRA). The Data was created from 
Microstation line and annotation data from the Whartoon County Appraisal District (WCAD). The Polygons 
were attributed with a six (6) digit Parcel ID number (PID). This references a Tax Reference number or Tax 
Rnumber. The scale of the microstation data was recieved in a unknown formats. Contact the Wharton County 
Appraisal District for Dates concerning their data.  
Parcels - Williamson County Williamson County Parcels was obtained by The Appraisal District of 
Williamson County. The data was converted from Microstation files to An ArcGIS Coverage. Steps will be 
explained in the Process Step section of Data Quality.  
Zipcode Boundaries ESRI (100k) U.S. ZIP Code Areas represents five-digit ZIP Code areas used by the 
U.S. Postal Service to deliver mail more effectively. The first digit of a five-digit ZIP Code divides the country 
into 10 large groups of states numbered from 0 in the Northeast to 9 in the far West. Within these areas, each 
state is divided into an average of 10 smaller geographical areas, identified by the 2nd and 3rd digits. These 
digits, in conjunction with the first digit, represent a sectional center facility or a mail processing facility area. 
The 4th and 5th digits identify a post office, station, branch or local delivery area.  
 
 
 
 
 133
 
Appendix B:  LCRA Hydromet Database Diagram 
 134
Table
comment
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
A list of time series record comments
comment_code String Yes 6 Unique code identifying a specific comment
comment_desc String Yes 255 Timeseries comment
OBJECTID Object ID
Table
data_archive
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
An archive of raw, unedited
timeseries data
sensor_id Integer Yes 0 0 Database sensor identification number
date_time Date Yes 0 0 8 Date and time of the data poll
data_value Double Yes 0 0 Primary reading taken from the sensor
data_value_2 Double Yes 0 0 Secondary reading/calculation
data_type String Yes 2 Class of data
source String Yes 2 Data feed source (not currently populated)
comment_code String Yes 6 Unique code identifying a specific comment (rarely used)
OBJECTID Object ID
Table
data_previous
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Contains the second to most recent
data poll for each sensor
sensor_id Integer Yes 0
date_time Date Yes 0 0 8
data_value Double Yes 0 0
data_value_2 Double Yes 0 0
data_type String Yes 2
source String Yes 2
comment_code String Yes 6
OBJECTID Object ID
Table
data_recent
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Contains the last two weeks of
timeseries data (for faster querying)
sensor_id Integer Yes 0
date_time Date Yes 0 0 8
data_value Double Yes 0 0
data_value_2 Double Yes 0 0
data_type String Yes 2
source String Yes 2
comment_code String Yes 6
OBJECTID Object ID
Table
datachron
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
The primary timeseries data
repository
sensor_id Integer Yes 0
date_time Date Yes 0 0 8
data_value Double Yes 0 0
data_value_2 Double Yes 0 0
data_type String Yes 2
source String Yes 2
comment_code String Yes 6
OBJECTID Object ID
Table
datavalid
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Contains the most recent data poll for
each sensor
sensor_id Integer Yes 0
date_time_valid Date Yes 0 0 8
data_valid Double Yes 0 0
data_valid_2 Double Yes 0 0
date_time Date Yes 0 0 8
data_value Double Yes 0 0
data_value_2 Double Yes 0 0
suspect String Yes 50
OBJECTID Object ID
Table
gage_brand
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
A list of gage brand names
gage_brand String Yes 6 Unique code identifying a gage manufacturer
gage_brand_name String Yes 20 Name of the gage manufacturer
OBJECTID Object ID
Table
sensor_brand
Data typeField name
Prec-
ision Scale LengthDomainDefault value
Allow
nulls
List of sensor brand names
sensor_brand String Yes Unique code identifying a sensor manufacturer
sensor_brand_name String Yes 20 Name of the sensor manufacturer
OBJECTID Object ID
Table
sensor_type
Data typeField name
Prec-
ision Scale LengthDomainDefault value
Allow
nulls
List of sensor types
sensor_type String Yes 6 Unique code identifying a specific type of sensor
sensor_type_description String Yes 20 The name or description associated with a sensor type
shef_pe_code String Yes 2 NWS shef paramter code associated with a specific sensor type
OBJECTID Object ID
Table
sensordef
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
A "Type" table for the various LCRA
sensors
site_id Integer Yes Database site identification number
sensor_id Integer Yes Database sensor identification number
sensor_number Integer Yes 0 LCRA end-user sensor identification number
sensor_type String Yes 6 Unique code identifying a specific type of sensor
in_service bit Yes 0 Boolean-style field, recording if sensor is active
datum Double Yes 0 0 Sensor elevation
tag_name String Yes 30 Dynamic data exchange tag for datachron data_value
tag_name_2 String Yes 30 Dynamic data exchange tag for datachron data_value_2
sensor_brand String Yes 6 Unique code identifying a gage manufacturer
calculation_type String Yes 10 Describes calculation to convert from value to value_2
adder Double Yes 0 0 Added to values in the datachron table
OBJECTID Object ID
Table
site_type
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
A list of site type descriptions
site_type String Yes 6 Unique code identifying a specific type of station
site_type_description String Yes 20 The name or description associated with a station type
OBJECTID Object ID
Table
site
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
A "Type" table for the various LCRA
monitoring locations
site_id Integer Yes 0 Database site identification number
site_number Integer Yes 0 LCRA end-user site identification number
site_name String Yes 50 LCRA name for site, based on town or waterbody name
in_service bit Yes 0 Boolean-style field, recording if sensor is active
site_type String Yes 6 Unique code identifiying a specific station type
site_order Integer Yes 0 Number to order the site from upstream to downstream
city_name String Yes 20 Name of associated city (closest city)
county_name String Yes 20 Name of county
reservoir_name String Yes 20 Name of associated reservoir
river_name String Yes 20 Name of associated river
river_mile Double Yes 0 Location along river where site is located
latitude Integer Yes 0 7 Latitude of site (DDD/MM/SS)
longitude Integer Yes 0 Longitude of site (DDD/MM/SS)
elevation Double Yes 0 0 Site elevation
drainage_area Double Yes 0 0 Site drainage area (sqmi)
nws_id String Yes 6 National Weather Service unique ID
usgs_id String Yes 10 US Geological Survey unique ID
operator String Yes 6 Operating party responsible for site
owner String Yes 6 Unique code used to identify a site property owner
site_phone_number String Yes 25 Site phone number
gage_brand String Yes 6 Unique code identifying a gage manufacturer
tcpip_address String Yes 15 tcpip address of gaging station
lid_id String Yes 4 Trunked radio system radio identifier
max_retry Double Yes 0 0 Gage-specific maximum transmission retry limit
site_picture String Yes 50 Path to site picture file
watershed_basin String Yes 35 Name of associated watershed
Tower String Yes 50 Name of transmission tower (not currently used)
Power_Source String Yes 10 Power source (AC or solar)
Communication_Type String Yes 30 Type of transmission
OBJECTID Object ID
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
DatachronHasComment
Origin table Destination table
Simple
One to one
None
comment
datachron
datachron
comment_code
comment_code
commentName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
SensordefHasSensor_brand
Origin table Destination table
Simple
One to one
None
sensor_brand
sensordef
sensordef
sensor_brand
sensor_brand
sensor_brandName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
SensordefHasSensor_type
Origin table Destination table
Simple
One to one
None
sensordef
sensor_type
sensordef
sensor_type
sensor_type
sensor_typeName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
SiteHasGage_brand
Origin table Destination table
Simple
One to one
None
gage_brand
site
site
gage_brand
gage_brand
gage_brandName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
SiteHasSensordef
Origin table Destination table
Simple
One to many
None
sensordef
site
site
site_id
site_id
sensordefName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
SiteHasSite_type
Origin table Destination table
Simple
One to one
None
site_type
site
site
site_type
site_type
site_typeName
0
0
7
0
Database sensor identification number
Date and time of the data poll
Primary reading taken from the sensor
Secondary reading/calculation
Class of data
Data feed source (not currently populated)
Unique code identifying a specific comment (rarely used)
Database sensor identification number
Date and time of the data poll
Primary reading taken from the sensor
Secondary reading/calculation
Class of data
Data feed source (not currently populated)
Unique code identifying a specific comment (rarely used)
Database sensor identification number
Date and time of the data poll
Primary reading taken from the sensor
Secondary reading/calculation
Class of data
Data feed source (not currently populated)
Unique code identifying a specific comment (rarely used)
Database sensor identification number
Date and time of the data poll
Primary reading taken from the sensor
Secondary reading/calculation
Primary reading taken from the sensor
Secondary reading/calculation
Records a comment
Date and time of the data poll
Primary Tables of the LCRA Hydromet Database Structure
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
SensordefHasDatachron
Origin table Destination table
Simple
One to many
None
datachron
sensordef
sensordef
sensor_id
sensor_id
datachronName
Monitoring Site Information
Sensor Type Information
Timeseries
 
Appendix C:  LCRA Hydromet Flow Diagram 
 136
LCRA Hydromet Flow Diagram
Hydromet
Gages
NWS Radar
Sutron
processing
hydromet
interval (.csv)
NEXRAIN
(.csv)
NEXRAIN Corp.
processing
datachron
datavalid
data_previous
data_archive
data_recent
interval
Extract last two
weeks of
datachron TS
Convert
irregular to
regular TS
(1hr intervals)
CFS
(HEC1 & UNET)
Model Results
NWS QPF
(Quantitative
Precipitation
Forecasts)
RFC
(River
Forecasts)
NEXRAIN
Corporation data
process
Data acquisition
from Hydromet
gages
LCRA SQL Server 7
hydrometB
Hydrologic and Hydraulic
Modeling
Outside data sources
Legend:
Source (Raw)
Data
Data Product
Process
Model Results
Notes:
gaged rainfall
"virtual rain gage" data
sensor_id (nu
m[6,0])
date_time (d.t)
data_value  (num[9,2])
data_value_2
(num[9,2])
data_type  (txt[2])
source  (txt[2])
comment_code  (txt[6])
datachron fields
datachron fields
datachron fields
datachron fields +
data_valid (num[9,2])
data_valid_2 (num[9,2])
date_time_valid (d.t)
sensor_id (nu
m[6,0])
date_time (d.t)
data_value  (num[9,2])
data_value_2
(num[9,2])
int_count(num[2,0])
Extract sensor
poll from
datavalid before
it is replaced
Extract last
sensor poll
Table definitions:
datachron -- the primary data storage table
datavalid and data_previous -- stores the most recent (and
  second most recent) data polls of the hydromet system
interval -- stores data that has been adjursted to regular,
  1 hour intervals, for use in modelling
data_recent -- stores the last two weeks of data in a smaller
  table, allowing for faster data querying
data_archive -- back-up of raw data (no QA/QC performed)
Associated tables:
The hydromet timeseries tables are related to a series of
TSType-style tables , as shown in the graphic below:Perform QA/QC
datachron
primary timeseries
storage table
sensor_id (num[
6,0])
date_time (d.t)
data_value  (num[9,2])
data_value_2 (num[9,2])
data_type  (txt[2])
source  (txt[2])
comment_code  (txt[6])
sensordef
describes the monitoring
instrument that took the
reading
sensor_id (num[
6,0])
site_id (num[8,0])
sensor_number(num[8,0])
sensor_type  (txt[6])
in_service  (bit)
tag_name  (txt[30])
tag_name_2  (txt[30])
sensor_brand  (txt[6])
sensor_type and
sensor_brand
are related to a
"sensor_type" and
"sensor_brand" table,
which give long (20
character) descriptions.
comment_code is related
to a "comment" table that
gives long (255
character) descriptions.
sensor_id
is related to extensive
"quality_limits",
"flood_level", and
"alarm limits" tables.
site
describes the
monitoring location
site_id (num[8,0])
site_number (num[8,0])
site_name (txt[50])
site_name_abbr (txt[30])
in_service (bit)
site_type (txt[6])
site_order (num[4,0])
city_name (txt[20])
county_name (txt[20])
reservoir_name (txt[20])
river_name (txt[20])
river_mile (num[6,2])
latitude (num[7,0])
longitude (num[7,0])
elevation (num[6,2])
drainage_area (num[7,2])
nws_id (txt[6])
usgs_id (txt[10])
operator (txt[6])
owner (txt[6])
site_phone_number (txt[25])
gage_brand (txt[6])
tcpip_address (txt[15])
lid_id (txt[4])
max_retry (num[2,0])
site_picture (txt[50])
gage_brand and site_type
are related to a
"gage_brand" and
"site_type" table, which
give long (20 character)
descriptions.
owner is related to an
extensive "site _owner"
table
obtained from
website,
entered into
CFS manually
 
Appendix D:  LCRA Water Quality Database Diagram 
 138
Table
Event
Data typeField name
Prec-
ision Scale LengthDomainDefault value
Allow
nulls
Conditions under which a sampling
event was cunducted
Tag_ID String Yes 7 Link between Event and Results tables
Station String Yes 9 Combination of Station_ID and sequence of a site within a segment
Station_ID String Yes 5 Unique identifier for station
EndDate String Yes 10 The date the sample was collected (MM/DD/YYYY)
EndTime String Yes 5 The time the sample was collected (HH:MM)
EndDepth String Yes 6 The depth (meters) at which the sample was collected
StartDate String Yes 10 Starting date (composite samples only)
StartTime String Yes 5 Starting time (composite samples only)
StartDepth String Yes 6 Starting depth (for composite samples only)
Category String Yes 1 Code corresponding to the type of composite sample taken
Calculatn String Yes 1 --no longer used, should be left blank--
Type String Yes 2 Code corresponding to the number of samples taken in a composite
Comment String Yes 135 A record of any observational data included with the sample
Source1 String Yes 2 A TNRCC assigned code for the agency submitting the sample
Source2 String Yes 2 An optional field that further identifies the sample
Program String Yes 2 An optional field that further identifies the sample
OBJECTID Object ID
Table
Results
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Water quality data obtained from a
sampling event
Tag_ID String Yes 7 Link between Event and Results tables
EndDate String Yes 10 The date the sample was collected (MM/DD/YYYY)
StoretCode String Yes 5 A 5-digit code identifying the type of measurement
Gtlt String Yes 1 ">" or "<" depending on whether the value is above or below detection limits
Value String Yes 8 Value of measurement (in units specified by the Storet table)
OBJECTID Object ID
Table
Station
Data typeField name
Prec-
ision Scale LengthDomainDefault value
Allow
nulls
Information about the locations
where sampling events occur
Basin_ID String Yes 2 Unique identifier for basin in which site is located
Station_ID String Yes 5 Unique identifier for station
Station_Num String Yes 9 Unique identifier based on segment and station sequence
USGS_Gage String Yes 8 Unique identifier assigned by the USGS
ShortDescrip String Yes 30 Text describing the site's location
LongDescrip String Yes 135 Text describing the site's location
EPA_Type1 String Yes 6 Code corresponding to the type of water feature the site is on
EPA_Type2 String Yes 6 Code corresponding to the water conditions at the site
County String Yes 20 Full name of county in which site is located
County_ID String Yes 3 Code for the county
Segment_ID String Yes 4 Code assigned to a classified stream segment
Stream String Yes 4 Code assigned to the site, placing it in sequence with other sites
Region String Yes 2 Code corresponding to the TCEQ region in which the site is located
Latitude Double Yes 0 0 Latitude of sampling site
Longitude Double Yes 0 0 Longitude of sampling site
HUC String Yes 8 Hydrologic Unit Code assigned by the USGS
On_Segment String Yes 1 Indicates whether or not the site is located on a segment
OBJECTID Object ID
Table
Storet
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Description of the water quality
parameter measured, and the
technique used to measure it
StoretCode String Yes 5 A 5-digit code identifying the type of measurement
ShortDescrip1 String Yes 8 Short descriptions including the water quality parameter
measured, the units of measurement, and the
measurement technique.
ShortDescrip2 String Yes 8
ShortDescrip3 String Yes 8 }
LongDescrip String Yes 50 Includes all of the metadata found in the 3 short descriptions
MinValue Double Yes 0 0 The lowest possible measurment
MaxValue Double Yes 0 0 The highest possible measurment
OBJECTID Object ID
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
EventHasResults
Origin table Destination table
Simple
One to many
None
Results
Event
Event
Tag_ID
Tag_ID
ResultsName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
StationHasEvent
Origin table Destination table
Simple
One to many
None
Event
Station
Station
Station_ID
Station_ID
EventName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
StoretHasResults
Origin table Destination table
Simple
One to many
None
Results
Storet
Storet
StoretCode
StoretCode
ResultsName
LCRA/TCEQ Water Quality Database Structure
Bi-Monthly Water Quality Sampling Data
taken at designated monitoring locations throughout the LC River
Basin
 
Appendix E:  Instructions ? ?Populating an Arc Hydro Dataset? 
 140
 
Populating The Arc Hydro data Model 
 
Developed by:  Daniel Obenour, CRWR; and Daniel Yates, LCRA 
 
 
 
Created:  November, 2002  
Updated:  January, 2003  
 
 
Introduction: 
The following outline is an instruction set for preparing hydrological data for 
use in the Arc Hydro data model.  The instructions assume that the user has a 
working knowledge of ArcGIS, Access, and Excel.  It is recommended that you 
save backups of your database at various times throughout the data preparation 
process.  Text appearing in italics is included to help explain and enhance the 
instructions.   
 
 
1. Acquiring the Required Input Data. 
It is up to the designer to determine what data will be required for a given 
Arc Hydro project.  River Reaches are required for all projects.  
Watersheds and Monitoring Points are generally included because they 
add functionality to the Arc Hydro model.  Waterbodies (representing 
lakes and reservoirs) are not always required.  Other data types may also 
be included at the designer?s discretion, but are not discussed in detail in 
this paper.  However, the procedures described in this paper are 
applicable to all data types.   
a. River Reaches ? available for the U.S. through the National Hydrography 
Dataset (NHD) (http://nhd.usgs.gov). 
b. Waterbodies ? available for the U.S. through the NHD. 
c. Watersheds ? available through the NHD, other sources, and raster 
watershed delineation.  Use watersheds that are of appropriate size for the 
basin being studied. 
d. Monitoring Points ? available through the NHD or other agencies that 
monitor stream flow, water quality, rainfall, or water level. 
 141
e. Other Points of Interest ? available though the NHD and other sources.  
May include structures, water users, water discharges, etc. 
2. Preparing the Input Data. 
a. If your data for the River Reaches (item ?a? of section 1) are in a number 
of separate shapefiles, open ArcMap and use the Geoprocessing Wizard to 
merge these files. 
b. Repeat step ?a? for all of your other data types.  When you finish you 
should have only one shapefile for each data type.  
 
The Geoprocessing Wizard 
 
 
 
The merger of three different NHD HUC river files 
 
3. Creating a Database. 
 142
a. In ArcCatalog, create a new personal geodatabase and assign it a name 
appropriate for your project. 
 
 
 
b. Launch ArcToolbox and convert your river reach shapefile into a 
projected coordinate system that is appropriate for your project. 
(Generally, use Albers Equal Area since it will maintain the accurate areas 
of watersheds.) 
 
 
 
 143
c. Export your river reach shapefile into your personal geodatabase and name 
it ?HydroEdge?.  During this process, you will be required to create a 
feature dataset.  Give it the name ?ArcHydro?.  (Make sure to add the 
shapefile with the largest spatial extents first; the first shapefile imported 
sets the spatial extent for the entire feature dataset.) 
 
 
 
d. Import all of the other shapefiles into the newly created feature dataset.  
As you import them, assign them the following names: 
i. River Reaches => HydroEdge (already added) 
ii. Waterbodies (that intersect river reaches) => Waterbody 
iii. Watersheds => Watershed 
iv. Monitoring Points => MonitoringPoint 
 
 144
 
 
 
e. Inside the feature dataset create a new feature class named 
?HydroJunction?.  (When creating this feature class you will be presented 
with a number of dialogue boxes that let you adjust the parameters of the 
feature class.  Use all of the default values, EXCEPT, under the Geometry 
Field you must change the Geometry Type from Polygon to Point). 
 
 145
 
 
 
 
Resulting Arc Hydro Geodatabase 
 
 
 146
4. Loading Monitoring Locations into the HydroJunction. 
The HydroJunction feature class is created to mark important locations along 
the Arc Hydro geometric network (created in Section 9).  It will eventually 
include all watershed outlets, waterbody outlets, stream monitoring sites, etc.  
The following procedure details how to incorporate the stream monitoring 
points into the HydroJunction feature class.  Note that the HydroJunction 
features will be snapped to the nearest HydroEdge feature, but the 
corresponding MonitoringPoint features will stay at their exact location.  
Also, note that the GageID field is only temporary; and is only used to ?join? 
the MonitoringPoint and HydroJunction attribute tables. 
a. Load MonitoringPoint, HydroEdge, and HydroJunction into ArcMap. 
b. Open the MonitoringPoint attribute table and add the following fields:  
HydroID, GageID, JunctionID (data type = ?long integer? for all fields). 
c. Open the HydroJunction attribute table and add the following fields:  
HydroID, GageID, FType (data type = ?string? for Ftype and ?long 
integer? for the others). 
d. Use ArcHydro attribute tools to assign HydroID values to 
MonitoringPoint. 
 
 
 
e. Copy the MonitoringPoint HydroID field values to the MonitoringPoint 
GageID field (Use the ?calculate values? command in the attribute table).  
f. Select all of the MonitoringPoint features that measure stream flow 
characteristics (i.e. do not select MonitoringPoint features that represent 
rainfall gages because these are not associated with the river network). 
g. Export this selection as a new feature class.  Give it a name such as 
?StreamMPoint?.  (This is only a temporary feature class and will be 
deleted later.) 
 147
h. Add the ?Load Objects?? tool: {Tools>Customize>Commands>Data 
Converters>Load Objects?}  
 
The ?Load Objects...? command is used to load one or more feature 
classes into a specified ?target? feature class.  The ?target? is the feature 
class selected in the Editor toolbar.  This command also allows for 
location adjustment of loaded features based on the Editor?s snap settings.  
?Loading? objects transfers data from one feature class to another.  
(?Importing?, as done in Part 3, creates a new feature class). 
i. Start Editing and set Target to HydroJunction. 
j. In the Editor, set Snapping to ?edges? of HydroEdge and select 
?perpendicular to sketch?.  Set the Editors snap tolerance to 10,000 map 
units (maximum). 
k. Use the Load Objects? tool (with snapping) to load the StreamMPoint 
layer into the HydroJunction Layer.   For the ?matching source fields? 
choose GageID to match the target GageID, but chose ?<None>? for the 
other fields. 
l. Use ArcHydro attribute tools to assign HydroID values to HydroJunction. 
m. Assign the value ?MonitoringPoint? to the Ftype field of all 
HydroJunction features. 
n. Copy the HydroID values from HydroJunction to the JunctionID field of 
MonitoringPoint using the following steps (or using Microsoft Access): 
i. Join HydroJunction to MonitoringPoint based on GageID. 
ii. Turn on the Editor and open the MonitoringPoint attribute table. 
iii. Copy HydroJunction.HydroID to MonitoringPoint.JunctionID 
o. The HydroJunction Layer should now include all of the StreamMPoint 
points.  Make sure that all of these points have successfully snapped to the 
HydroEdge layer (you could use a ?select by location?? command to 
determine this).  
p. Wherever the HydroJunction points did not snap to HydroEdge, use the 
Editor to move and snap them to the HydroEdge layer manually. 
q. Delete GageID fields from HydroJunction and MonitoringPoint. 
 
 148
 
Resulting HydroJunctions and MonitoringPoints 
 
5. Breaking HydroEdges at Locations of Interest. 
The ultimate goal of Sections 5, 6, & 7 is to create HydroJunction features 
that represent watershed and waterbody outlet points.  These features will 
originally be created as network junctions.  When a network is created, it 
places generic network junctions at the intersections (breaks) of all network 
edges (HydroEdges in our case).  Since network junctions are required at the 
outlet of each watershed and waterbody, make sure that the HydroEdge 
features are broken at these locations. 
a. Load HydroEdge and Watershed into ArcMap. 
b. Use the Geoprocessing Wizard to intersect HydroEdge with Watershed.  
Give the output file a name such as ?HydroEdgeI? 
c. If you are using NHD river reaches and waterbodies go to section 6.  
(NHD river reaches are already broken at waterbody intersections).  If you 
are not using NHD data, repeat steps ?a? and ?b? for HydroEdgeI and 
Waterbody.   
 
 149
 
A HydroEdge broken at a watershed outlet 
 
6. Creating WshOutlet (watershed outlets) and WbdOutlet (waterbody outlet) Features. 
The networks created in this section are only intermediary networks and will 
be deleted later, in Section 8.  The networks in this section are only being 
formed in order to help create the WshOutlet and WbdOutlet feature classes. 
a. In ArcCatalog, select to create a new geometric network in your project?s 
feature dataset.  Follow through the dialogue boxes:   
   
    
 
  
i. Select ?Build from existing Features 
ii. Select HydroEdgeI 
 150
iii. Give the network a name such as ?NetworkIYes? 
iv. Select Yes for complex edges 
v. Select No for snapping 
vi. Select No for assigning weights 
vii. Finish 
b. Create a 2
nd
 network: 
i. Select ?Build from existing Features 
ii. Select HydroEdge 
iii. Give the network a name such as ?NetworkINo? 
iv. Select Yes for complex edges 
v. Select No for snapping 
vi. Select No for assigning weights 
vii. Finish 
c. Load NetworkIYes, NetworkINo, Watershed, and Waterbody into 
ArcMap. 
d. Select by location NetworkIYes_Junctions that intersect 
NetworkINo_Junctions. 
e. Open the attribute table for NetworkIYes_Junctions. 
f. Switch the selection and close attribute table. 
g. Export selected data to the feature dataset and name it ?WshOutlet? 
h. Zoom in at each watershed outlet location.  Turn on the Editor and make 
the necessary adjustments.  Make sure that (from most to least important, 
conditions i, ii, & iii must always be met): 
i. each watershed has only one outlet point. 
ii. watersheds do not share the same outlet point. 
iii. no outlet point is located at the intersection of streams. 
iv. each outlet point is located on the primary stream of the watershed 
it represents.  
v. each outlet is located inside or on the border of the watershed it 
represents. 
 
 151
        
 
i. Select NetworkIYes_Junctions that intersect Waterbody using an 
approximately 10 unit buffer. 
j. Export selected data to the feature dataset and name it ?WbdOutlet? 
k. Zoom into each waterbody and delete excess outlet points (each 
waterbody should have only one outlet point).  If necessary, use the 
network analyst to determine which point is the downstream outlet 
(perform a trace between the waterbody of interest and the basin outlet). 
l. Add the field ?Ftype? to both WshOutlet and WbdOutlet.  Assign the 
value ?WshOutlet? to the Ftype field of all WshOutlet features.  Assign 
the value ?WbdOutlet? to the Ftype field of all WbdOutlet features.   
7. Loading Outlets into HydroJunction. 
a. Load HydroJunction, HydroEdge, WshOutlet, and WbdOutlet into 
ArcMap 
b. Start Editing and set Target to HydroJunction. 
c. In the Editor, set snapping to ?edges? in HydroEdge and select 
?perpendicular to sketch?.  Set the Editors snap tolerance to 10,000 map 
units (although this shouldn?t be necessary since WshOutlet and 
WbdOutlet features should already be snapped to HydroEdge). 
d. Use the Load Objects? tool (snapping optional) to load the WshOutlet 
and WbdOutlet layers into the HydroJunction Layer.   For the ?matching 
source fields? choose Ftype to match the target Ftype, but chose 
?<None>? for the other fields. 
Unlike the MonitoringPoint feature class, once the WshOutlet and WbdOutlet 
have been loaded into HydroJunction they may be discarded.  However, it is 
not recommended that they be deleted because they are good back-up data.  
 152
 
 
Symbolic view of outlets being loaded into the HydroJunction feature class. 
 
8. Preparing Data for the Arc Hydro Network. 
This is the time to find any errors that may still exist within your feature 
classes.  The networks created in Section 6 can be used to aid in this process.  
Then they must be deleted. 
a. Load NetworkIYes into ArcMap. 
b. Use Network Analyst to perform a trace to ?find disconnected?. 
i. Place a flag on any junction in the network  
ii. Run the trace  
c. Use the Editor to manually connect the disconnected river reaches.  Close 
ArcMap. 
d. In ArcCatalog delete the existing networks. 
e. Load HydroJunction, Watershed, Waterbody, and HydroEdge into 
ArcMap. 
f. Use ArcHydro toolset to assign HydroID to all of the feature classes listed 
above.  Make sure to NOT overwrite the existing HydroID values in 
HydroJunction. 
9. Creating the Arc Hydro Network. 
It is now time to create the final Arc Hydro Geometric Network!   
a. In ArcCatalog, create a new geometric network: 
i. Select ?Build from existing Features? 
ii. Select HydroEdge and HydroJunction 
iii. Preserve existing Enabled values (although, this shouldn?t really 
matter) 
iv. Give the network the name ?HydroNetwork? 
v. Select Yes for complex edges 
vi. Select Yes for snapping (use a tolerance of 1 map unit to be safe) 
vii. Select Yes for sinks/sources 
 153
viii. Select No for assigning weights 
ix. Finish 
b. Load HydroNetwork into ArcMap. 
c. Use the Network Analyst to check network integrity. 
i. Do a trace task to ?find connected? (all network elements should 
be selected). 
ii. Do a trace task to ?find disconnected? (no elements should be 
selected.) 
iii. If there were any problems with the network, fix the problem, 
delete the network and go back to step ?9.a?) 
10.  Setting Flow Directions. 
Every HydroEdge feature can be either Enabled or Disabled.  If a feature is 
Disabled, it will no longer be treated as part of the network.   In most cases, 
all features should be kept enabled.  Every HydroEdge also needs to be 
assigned a flow direction value.  These values include: Uninitialized, With 
Digitized, Against Digitized, and Indeterminate.   After completing this 
section, there should be no data left Uninitialized.  Edges should only be set to 
Indeterminate if the designer cannot decide which way the flow is moving. 
a. Load HydroNetwork into ArcMap 
b. If there are any shorelines, select them and use the Editor and set these 
features? Enabled value to False. 
 
c. Display flow direction based on Network Connectivity: 
i. Turn on the Editor and select the basin?s over-all outlet junction. 
ii. Using the attribute editor, set this junction?s Ancillary Roll to Sink.   
 
 154
 
 
iii. From the Network Analyst toolbar select the ?set-flow-direction? 
button.   Turn off Editor.  
iv. From the Network Analyst toolbar select ?Display Arrows?  
d. Go to the Arc Hydro Network tools and select ?Store Flow Direction?.  
(This stores the edges? flow directions as per the arrows shown on the 
screen.  Directions are stored in the FlowDir field of HydroEdge.)   
e. Use Network Traces Upstream to determine where the flow direction has 
not been assigned (these are the locations of ?loops? in your network, and 
are the areas where no flow direction has yet been assigned). 
f. IF a given loop is the result of an erroneous HydroEdge feature, turn on 
the Editor and set the feature?s Enabled value to False. 
g. IF a given loop is the result of multiple river paths that truly exist, you will 
need to assign the flow direction manually using one of the following two 
methods: 
i. To assign flow direction values to ONE or MULTIPLE 
HydroEdge features: 
1. Select the features of interest. 
2. Change the HydroEdge symbology to ?Arrow at End? (If 
the arrows are pointing the correct direction you want to 
assign the flow direction to ?With Digitized?.  If the arrows 
are incorrect you want ?Against Digitized.?   
 155
3. Select ?Set Flow Direction?? from the Arc Hydro 
Network Tools.  Select either With Digitized or Against 
Digitized  
 
4. Select ?Store Flow Direction? from the ArcHydro Network 
Tools. 
 
 156
 
ii. Use the Editor to manually assign flow direction to the FlowDir 
field of HydroEdge  (FlowDir = 1 = With Digitized;  FlowDir = 2  
= Against Digitized) 
 
 
 
h. To determine that all flow directions have been logically assigned: 
i. Under {Network Analyst>Analysis>Options>Results} change the 
format from ?drawing? to ?selected?. 
ii. Perform an upstream trace from the basin outlet. 
iii. Open the HydroEdge attribute table and switch the selection.  (This 
will select any HydroEdge that does not have a logical flow 
direction assigned). 
 
 
 
Properly Assigned Flow Directions 
 
11. Implementing the Arc Hydro Schema. 
 157
Before the Schema can be applied, it is important to make sure all Arc Hydro 
fields have the correct data type assigned to them.  Typically, the EdgeType 
and ReachCode fields must have their data types changed (to long integer and 
text, respectively).  The following instructions are for changing EdgeType, but 
can be applied to any field. 
a. Load HydroEdge into ArcMap. 
b. Turn on the Editor and open the HydroEdge attribute table. 
c. If the EdgeType field has unique values assigned to it, create a new field 
?EdgeType2? and copy the EdgeType values to it.  (In most cases this 
isn?t necessary) 
d. Delete ?EdgeType? 
e. Add a new ?EdgeType? field, and give it the correct data type (long 
integer).   
f. If necessary, copy the values from EdgeType2 back to Edgetype and 
delete EdgeType2. 
The Arc Hydro Schema applies a standardized database format to your Arc 
Hydro data.  Most importantly, it creates relationships between feature 
classes (i.e. HydroJunctionHasMonitoringPoint).  If your dataset is missing 
essential feature classes, the schema will create these as well (but, of course, 
they will be empty of data).  In the future, the schema will need to be reapplied 
whenever data is revised or appended.  It is also important to note that there 
are three types of schemata (framework, framework-w/timeseries, and full 
model).  Here, we will just discuss the Arc Hydro Framework Schema, but the 
other schemas can be applied in a similar fashion. 
g. Open ArcCatalog and add the ?Schema Wizard? tool: 
{Tools>Customize>Commands>Case Tools>Schema Wizard}  
h. Make sure your feature dataset is named ArcHydro.  If necessary, rename 
it. 
i. Select your geodatabase so that the ArcHydro feature dataset is visible, 
and click the Schema Wizard Button . 
j. Continue through the dialogue boxes: 
i. Database Path =  ?\ArcHydroFrameworkSchema.mdb 
ii. Object Model = ArcHydroFramework Data Model :: 
ArcHydroFramework 
iii. For spatial reference, select ?Use default values? 
iv. A tree-view of the dataset will be presented.   
1. Feature classes outlined in red have been automatically 
detected because they have the correct Arc Hydro standard 
name.   
2. Feature classes outlined in gray have not been detected.  
These feature classes can be assigned an existing feature 
class manually (Properties>Exists>Feature Class Already 
Exists?>Select). 
 158
3. If no data for a given feature class yet exists, leave the 
feature class outlined in gray. 
4. Add fields to each feature class as necessary (this will 
create empty fields that can be filled in the future). 
a. Select the feature class. 
b. Select Properties>Exists 
c. Select each cell in the ?In existing object? column 
that has the value ?click to select?.  Change the 
value to ?<Add field>? 
v. Finish 
 
 
An example of a properly developed Arc Hydro Framework 
 
12. Assigning Arc Hydro Attribute Values. 
The Arc Hydro Toolset and ArcMap Editor can be used to assign values to the 
empty attribute fields added at the end of section 11. 
a. Load HydroNetwork, Watershed, Waterbody, and MonitoringPoint into 
ArcMap. 
b. Turn on Editor.  Add length and area values (in kilometers) to appropriate 
fields: 
i. In HydroEdge, compute: LengthKm = [Shape_Length/1000] 
ii. In Watershed, compute: AreaSqKm = [Shape_Area]/1000000] 
iii. In Waterbody, compute: AreaSqKm = [Shape_Area]/1000000] 
c. Select all of the HydroEdge features representing shore lines and set their 
EdgeType attribute value to 2. 
d. Select all of the HydroEdge features representing flow lines and set their 
Edge Type attribute value to 1.  (This should be the majority, if not all of 
the HydroEdge features.) 
 159
e. Select ?Compute Length Downstream for Edges? from the Arc Hydro 
toolset.  Select to compute the downstream values for HydroEdge using 
LengthKm.  (This fills the LengthDown field of HydroEdge.) 
 
 
 
f. Select ?Compute Length Downstream for Junctions? from the Arc Hydro 
toolset.  Select to compute the downstream values for HydroJunction 
using LengthKm.  (This fills the LengthDown field of HydroJunction.) 
g. Select ?Find Next Downstream Junction? from the Arc Hydro toolset.  
(This fills the NextDownID field of HydroJunction.) 
The ?Store Area Outlets?? command is used to fill the JunctionID fields 
for Waterbody and Watershed.  JunctionID values are assigned based on 
the HydroID of the HydroJunction that represents the feature?s outlet.  To 
accomplish this, the ?Store Area Outlets?? command provides several 
different methods for automatically determining which 
waterbody/watershed is associated with which HydroJunction.  
Experiment with these different methods to determine which is most 
appropriate for your model.  In most cases, some JunctionID values will 
have to be assigned manually. 
h. Select ?Store Area Outlets?? from the Arc Hydro toolset.  Select 
HydroJunction and Waterbody, to assign JunctionID?s to Waterbody. 
i. Label the HydroJunction features with their HydroID. 
j. Label the Waterbody features with their JunctionID. 
k. Use Editor to manually assign JunctionID?s to Waterbody wherever the 
?Store Area Outlets?? command was not successful.   
l. Repeat steps ?h? and ?k? for Watershed. 
13. Finishing Up. 
a. Delete extraneous fields and feature classes. 
 160
b. Use ArcCatalog to develop Metadata for each feature class. 
c. Step back and admire your work.  You?re done! 
 161
 
 
Appendix F:  HMS IDM Database Diagram 
 162
Simple feature class
HMSDiversion Contains Z valuesContains M values
Geometry Point
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Diversion Features
Shape Geometry Yes
OBJECTID Object ID
FeatureID Long integer Yes 0
HMSCode String Yes 20
Canvas_X Double Yes 0 0
Canvas_Y Double Yes 0 0
Label_X Long integer Yes 16 0
Label_Y Long integer Yes 0 0
GageCode String Yes 20
Descrip String Yes 255
MaxDivVol Double Yes 0 0 Maximum volume to be diverted (ac-ft / cm)
MaxDivFlo Double Yes 0 0 Maximum flow to be diverted (cfs / cms)
TableInDSS String Yes 3 Records if diversion table is stored in DSS
DownCode String Yes 20 HMSCode of downstream element
Simple feature class
HMSJunction Contains Z valuesContains M values
Geometry Point
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Junction Features
Shape Geometry Yes
OBJECTID Object ID
FeatureID Long integer Yes 0
HMSCode String Yes 20
Canvas_X Double Yes 0 0
Canvas_Y Double Yes 0 0
Label_X Long integer Yes 16 0
Label_Y Long integer Yes 0 0
GageCode String Yes 20
Descrip String Yes 255
DownCode String Yes 20 HMSCode of downstream element
Simple feature class
HMSReach Contains Z valuesContains M values
Geometry Polyline
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Reach Features
Shape Geometry Yes
OBJECTID Object ID
FeatureID Long integer Yes 0 HydroID of the associated ArcHydro element
HMSCode String Yes 20
Canvas_X Double Yes 0 0
Canvas_Y Double Yes 0 0
Label_X Long integer Yes 16 0
Label_Y Long integer Yes 0 0
GageCode String Yes 20
Descrip String Yes 255
From_X Double Yes 0 0 Upstream X-locator  withing the HMS basin map
From_Y Double Yes 0 0 Upstream Y-locator within the HMS basin map
Route String Yes RouteType 50 Reach routing method
DownCode String Yes 20 HMSCode of downstream element
Shape_Length Double Yes 0 0
Simple feature class
HMSReservoir Contains Z valuesContains M values
Geometry Point
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Reservoir Features
Shape Geometry Yes
OBJECTID Object ID
FeatureID Long integer Yes 0 HydroID of the associated Arc Hydro element
HMSCode String Yes 20 Permenant HMS identifier for the element
Canvas_X Double Yes 0 0 X-locator of element within the HMS basin map
Canvas_Y Double Yes 0 0 Y-locator of element within the HMS basin map
Label_X Long integer Yes 16 0 X-locator of element label relative to element
Label_Y Long integer Yes 0 0 Y-locator of element label relative to element
GageCode String Yes 20 Discharge gage related to the element
Descrip String Yes 255 Description of the element stored in HMS
Route String Yes ResCurveType 50 Reservoir routing method and curve type
TableInDSS String Yes BooleanYesNo 3 Curve associated with reservoir routing (DSS)
RouteTable String Yes 50 Table associated with reservoir routing (DSS)
DownCode String Yes 20 HMSCode of downstream element
Simple feature class
HMSSink Contains Z valuesContains M values
Geometry Point
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Sink Features
Shape Geometry Yes
OBJECTID Object ID
FeatureID Long integer Yes 0
HMSCode String Yes 20
Canvas_X Double Yes 0 0
Canvas_Y Double Yes 0 0
Label_X Long integer Yes 16 0
Label_Y Long integer Yes 0 0
GageCode String Yes 20
Descrip String Yes 255
Simple feature class
HMSSource Contains Z valuesContains M values
Geometry Point
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Source Features
Shape Geometry Yes
OBJECTID Object ID
FeatureID Long integer Yes 0
HMSCode String Yes 20
Canvas_X Double Yes 0 0
Canvas_Y Double Yes 0 0
Label_X Long integer Yes 16 0
Label_Y Long integer Yes 0 0
GageCode String Yes 20
Descrip String Yes 255
Constant Double Yes 0 0 Constant inflow value (cfs / cms)
FlowGage String Yes 20 Gage representing inflow
Area Double Yes 0 0 Area (sqmi /sqkm)
DownCode String Yes 20 HMSCode of downstream element
Simple feature class
HMSSubbasin Contains Z valuesContains M values
Geometry Polygon
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Subbasin Features
Shape Geometry Yes
OBJECTID Object ID
FeatureID Long integer Yes 0
HMSCode String Yes 20
Canvas_X Double Yes 0 0
Canvas_Y Double Yes 0 0
Label_X Long integer Yes 16 0
Label_Y Long integer Yes 0 0
GageCode String Yes 20
Descrip String Yes 255
Area Double Yes 0 0 Area (sqmi / sqkm)
LossRate String Yes LossRateType 50 LossRate method
hTransform String Yes TransformType 50 Transform method
BaseFlow String Yes BaseflowType 50 Baseflow method
DownCode String Yes 20 HMSCode of downstream element
Shape_Length Double Yes 0 0
Shape_Area Double Yes 0 0
Table
DSSPairedData
Data typeField name
Prec-
isionScaleLengthDomainDefault value
Allow
nulls
Paired Data
OBJECTID Object ID
DSSPDID Long integer Yes 0 Unique identifier for pathname
PairedValue1 Double Yes 0 0 Paired value 1
PairedValue2 Double Yes 0 0 Paired value 2
Table
DSSPDCatalog
Data typeField name
Prec-
isionScaleLengthDomainDefault value
Allow
nulls
Paired Data Type
OBJECTID Object ID
DSSPDID Long integer
Yes
0
HMSCode of related elementRelateCode String
Yes 80 DSS pathnamePathName String
Yes
20
Unique identifier for pathname
A_Part String Yes 50 Pathname A-part
B_Part String Yes 50 Pathname B-part (HMSCode & BasinCode)
C_Part String Yes 50 Pathname C-part (Variable type)
D_Part String Yes 50 Pathname D-part
E_Part String Yes 50 Pathname E-part
F_Part String Yes 50 Pathname F-part
Curves Long integer Yes 0 Number of curves
Ordinates Long integer Yes 0 Number of ordinates per curve
Horiz Long integer Yes 0
Unit1 String Yes 8 Variable 1
Type1 String Yes AxisType 8 Axis 1 type
Unit2 String Yes 8 Variable 2
Type2 String Yes AxisType 8 Axis 2 type
CurveLYN String Yes BooleanYesNo 3 Records if curve labels will be used
CurveLabel String Yes 12 Records curve labels
DSSFPath String Yes 255 Location of DSS file
Table
Gridcell
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Gridcells
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related element (subbasin)
XCoord Long integer Yes 0 X-locator of cell within HMS basin map
YCoord Long integer Yes 0 Y-locator of cell within HMS basin map
Travel Double Yes 0 0 travel length from gridcell to subbasin outlet (km)
Area Double Yes 0 0 Area of the gridcell within subbasin (sqkm)
SCSCN Double Yes 0 0 SCS curve number for gridcell
SMAUnit String Yes 50 SMA unit for grid cell
Table
GridcellHeader
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Gridcell Header
OBJECTID Object ID
Parameter1 String Yes GridParameterType 20 Gridcell parameter-1 type
Parameter2 String Yes GridParameterType 20 Gridcell parameter-2 type
Parameter3 String Yes GridParameterType 20 Gridcell parameter-3 type
Parameter4 String Yes GridParameterType 20 Gridcell parameter-4 type
Parameter5 String Yes GridParameterType 20 Gridcell parameter-5 type
Table
HMSBasin_Header
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Basin Header
OBJECTID Object ID
BasinCode String Yes 20 Name of basin file
Descrip String Yes 255 Description of basin
LastDate String Yes 20 Last date modified
LastTime String Yes 8 Last time modified
Version String Yes 20 HMS program version
DSSFPath String Yes 255 Location of DSS file
Units String Yes UnitType 7 Default model units
MapFPath String Yes 255 Location of basin map file
GridFPath String Yes 255 Location of basin grid file
DBasinUnit String Yes UnitType 7 Default basin unit
DMeteoUnit String Yes UnitType 7 Default meteorological unit
DLossRate String Yes LossRateType 50 Default LossRate method
DTransform String Yes TransformType 50 Default Transform method
DBaseflow String Yes BaseflowType 50 Default Baseflow method
DRoute String Yes RouteType 50 Default Routing method
DeleteWarn String Yes BooleanYesNo 3 Records if user will be warned when deletingelements
ChangeWarn String Yes BooleanYesNo 3 Records if user will be warned when changingelements
FlowRatio String Yes BooleanYesNo 3 Enables flow ratio calculations
JuncFlow String Yes BooleanYesNo 3 Enables junction flow calculation
Evap String Yes BooleanYesNo 3 Enables evapotranspiration calculations
NoFlowTo0 String Yes BooleanYesNo 3 Sets no-flow values to zero
Table
LossRate_DeficitConstant
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Deficit/Constant
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
Impervious Double Yes 0 0 Percent impervious area
IDeficit Double Yes 0 0 Initial deficit (in / mm)
MaxDeficit Double Yes 0 0 Maximum deficit (in / mm)
LossRate Double Yes 0 0 Constant loss rate (in/hr / mm/hr)
RRate1 Double Yes 0 0 Jan recovery rate (in/dy / mm/dy)
RRate2 Double Yes 0 0 Feb recovery rate
RRate3 Double Yes 0 0 Mar recovery rate
RRate4 Double Yes 0 0 Apr recovery rate
RRate5 Double Yes 0 0 May recovery rate
RRate6 Double Yes 0 0 Jun recovery rate
RRate7 Double Yes 0 0 Jul recovery rate
RRate8 Double Yes 0 0 Aug recovery rate
RRate9 Double Yes 0 0 Sep recovery rate
RRate10 Double Yes 0 0 Oct recovery rate
RRate11 Double Yes 0 0 Nov recovery rate
RRate12 Double Yes 0 0 Dec recovery rate
Table
LossRate_GreenAndAmpt
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Green & Ampt
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
Impervious Double Yes 0 0 Percent impervious area
ILoss Double Yes 0 0 Initial loss (in / mm)
WetDeficit Double Yes 0 0 Moisture deficit
WFSuction Double Yes 0 0 Wetting front suction (in / mm)
HyConduct Double Yes 0 0 Hydraulic conductivity (in/hr / mm/hr)
Table
LossRate_GriddedSCS
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Gridded SCS
(Soil Conservation Service)
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
PRetention Double Yes 0 0 Potential retention scale factor
IAbstract Double Yes 0 0 Initial abstraction ratio
Table
LossRate_GriddedSMA
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Gridded SMA
(Soil Moisture Accounting)
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
MoistUnit Double Yes 0 0 Soil moisture unit
ICanopy Double Yes 0 0 Initial canopy storage percent
ISurface Double Yes 0 0 Initial surface storage percent
ISoil Double Yes 0 0 Initial soil storage percent
IGw1 Double Yes 0 0 Initial storage percent of groundwater layer 1
IGw2 Double Yes 0 0 Initial storage percent of groundwater layer 2
Table
LossRate_InitialConstant
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Initial/Constant
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
Impervious Double Yes 0 0 Percent impervious area
ILoss Double Yes 0 0 Initial loss (in / mm)
LossRate Double Yes 0 0 Constant loss rate (in/hr / mm/hr)
Table
LossRate_SCS
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
SCS
(Soil Conservation Service)
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
Impervious Double Yes 0 0 Percent impervious area
IAbstract Double Yes 0 0 Initial abstraction (in / mm)
CN Double Yes 0 0 Curve number
Table
LossRate_SMA
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
SMA
(Soil Moisture Accounting)
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
Impervious Double Yes 0 0 Percent impervious area
MoistUnit Double Yes 0 0 Soil moisture unit
ICanopy Double Yes 0 0 Initial canopy storage percent
ISurface Double Yes 0 0 Initial surface storage percent
ISoil Double Yes 0 0 Initial soil storage percent
IGw1 Double Yes 0 0 Initial storage percent for groundwater layer 1
IGw2 Double Yes 0 0 Initial storage percent for groundwater layer 2
Table
Route_KinematicWave
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Kinematic Wave
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related reach
Shape String Yes 9
Length Double Yes 0 0 Length (ft / m)
Energy Double Yes 0 0 Energy slope
Width Double Yes 0 0 Width (ft / m)
SideSlope Long integer Yes 0 Side slope
ManningsN Double Yes 0 0 Mannings "n"
Increments Long integer Yes 0 Number of increments
Table
Route_Lag
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Lag
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related reach
Lag Double Yes 0 0 Lag time (min)
Table
Route_ModifiedPuls
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Modified Puls
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related reach
Subreaches Long integer Yes 0 Number of subreaches
OutIsIn String Yes BooleanYesNo 3 Records if initial outflow equals inflow
TableInDSS String Yes BooleanYesNo 3 Records if table is stored in DSS
TableName String Yes 50 Name of routing table
Table
Route_Muskingum
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Muskingum
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related reach
MuskingumK Double Yes 0 0 Muskingum K (hr)
MuskingumX Double Yes 0 0 Muskingum X
MuskingumS Long integer Yes 0 Muskingum Steps
Table
Route_MuskingumCunge
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Muskingum Cunge
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related reach
Length Double Yes 0 0 Length (ft /  m)
Energy Double Yes 0 0 Energy slope
Shape String Yes 8
Width Double Yes 0 0 Width (ft / m)
SideSlope Long integer Yes 0 Side slope
ManningsN Double Yes 0 0 Mannings "n"
Table
Transform_Clark
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Clark unit hydrograph
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
TOC Double Yes dblDomain0-1000 0 0 Time of concentration (hr)
StoreCoeff Double Yes dblDomain0-1000 0 0 Storage coefficient (hr)
Table
Transform_ModClark
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
ModClark (gridded)
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
TOC Double Yes dblDomain0-1000 0 0 Time of concentration (hr)
StoreCoeff Double Yes dblDomain0-1000 0 0 Storage coefficient (hr)
Table
Transform_SCS
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
SCS
(Soil Conservation Service)
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
Lag Double Yes dblDomain0-30000 0 0 Lag time (min)
Table
Transform_Snyder
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Snyder unit hydrograph
OBJECTID Object ID
HMSCode String Yes 20 HMSCode of related subbasin
SnyderTp Double Yes dblDomain0-500 0 0 Snyder time to peak (hr)
SnyderCp Double Yes dblDomain0-1 0 0 Snyder peaking coefficient
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
DSSPDCatalogHasDSSPairedData
Origin table Destination table
Simple
One to many
None
DSSPairedData
DSSPDCatalog
DSSPDCatalog
DSSPDID
DSSPDID
DSSPairedDataName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSDiversionHasDSSPDCatalog
Origin feature class Destination table
Simple
One to many
None
DSSPDCatalog
HMSDiversion
HMSDiversion
HMSCode
RelateCode
DSSPDCatalogName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasDSSPDCatalog
Origin feature class Destination table
Simple
One to many
None
DSSPDCatalog
HMSReach
HMSReach
HMSCode
RelateCode
DSSPDCatalogName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasRoute_KinematicWave
Origin feature class Destination table
Simple
One to one
None
R_KinematicWave
Reach
HMSReach
HMSCode
HMSCode
Route_
KinematicWave
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasRoute_Lag
Origin feature class Destination table
Simple
One to one
None
Route_Lag
Reach
HMSReach
HMSCode
HMSCode
Route_LagName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasRoute_ModifiedPuls
Origin feature class Destination table
Simple
One to one
None
Route_Modified
Puls
Reach
HMSReach
HMSCode
HMSCode
Route_
ModifiedPuls
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasRoute_Muskingum
Origin feature class Destination table
Simple
One to one
None
Route_Muskingum
Reach
HMSReach
HMSCode
HMSCode
Route_
Muskingum
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasRoute_MuskingumCunge
Origin feature class Destination table
Simple
One to one
None
Route_MuskCunge
Reach
HMSReach
HMSCode
HMSCode
Route_
Muskingum
Cunge
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReservoirHasDSSPDCatalog
Origin feature class Destination table
Simple
One to many
None
DSSPDCatalog
HMSReservoir
HMSReservoir
HMSCode
RelateCode
DSSPDCatalogName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSbasinHasLossRate_DeficitConstant
Origin feature class Destination table
Simple
One to one
None
LR_Deficit
Constant
Subbasin
HMSSubbasin
HMSCode
HMSCode
LossRate_Deficit
Constant
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSbasinHasLossRate_GreenAndAmpt
Origin feature class Destination table
Simple
One to one
None
LR_Green+Ampt
Subbasin
HMSSubbasin
HMSCode
HMSCode
LossRate_Green
AndAmpt
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasLossRate_GriddedSCS
Origin feature class Destination table
Simple
One to one
None
LR_GriddedSCS
Subbasin
HMSSubbasin
HMSCode
HMSCode
LossRate_
GriddedSCS
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasLossRate_GriddedSMA
Origin feature class Destination table
Simple
One to one
None
LR_GriddedSMA
Subbasin
HMSSubbasin
HMSCode
HMSCode
LossRate_
GriddedSMA
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSbasinHasLossRate_InitialConstant
Origin feature class Destination table
Simple
One to one
None
LR_InitialConstant
Subbasin
HMSSubbasin
HMSCode
HMSCode
LossRate_
InitialConstant
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasLossRate_SCS
Origin feature class Destination table
Simple
One to one
None
LR_SCS
Subbasin
HMSSubbasin
HMSCode
HMSCode
LossRate_SCSName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasLossRate_SMA
Origin feature class Destination table
Simple
One to one
None
LR_SMA
Subbasin
HMSSubbasin
HMSCode
HMSCode
LossRate_SMAName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasTransform_Clark
Origin feature class Destination table
Simple
One to one
None
Tr_Clark
Subbasin
HMSSubbasin
HMSCode
HMSCode
Transform_ClarkName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasTransform_ModClark
Origin feature class Destination table
Simple
One to one
None
Tr_ModClark
Subbasin
HMSSubbasin
HMSCode
HMSCode
Transform_
ModClark
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasTransform_SCS
Origin feature class Destination table
Simple
One to one
None
Tr_SCS
Subbasin
HMSSubbasin
HMSCode
HMSCode
Transform_SCSName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasTransform_Snyder
Origin feature class Destination table
Simple
One to one
None
Tr_Snyder
Subbasin
HMSSubbasin
HMSCode
HMSCode
Transform_
Snyder
Name
Coded value domain
BaseflowType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
None None
SMA Groundwater SMA Groundwater
Recession Recession
Monthly Constant Monthly Constant
Bounded Recession Bounded Recession
Coded value domain
BooleanYesNo
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Yes Yes
No No
Coded value domain
GriddedPrecipPathType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
A= B= C= F= A= B= C= F=
Coded value domain
GridParameterType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
XCoord XCoord
YCoord YCoord
TravelLength TravelLength
Area Area
SCSCN SCSCN
SMAUnit SMAUnit
None None
Coded value domain
KinematicWaveShapeType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Trapezoid Trapezoid
Deep Deep
Circular Circular
Coded value domain
LossRateType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
None None
Green and Ampt Green and Ampt
Initial+Constant Initial+Constant
Deficit Constant Deficit Constant
Soil Moisture Account Soil Moisture Account
Gridded Soil Moisture Account Gridded Soil Moisture Account
SCS SCS
Coded value domain
MissingRecordActionType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Undefined Undefined
Set data to zero Set data to zero
Coded value domain
MuskingumCungeShapeType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Prism Prism
Circular Circular
Coded value domain
RouteType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
None None
Kinematic Wave Kinematic Wave
Lag Lag
Modified Puls Modified Puls
Muskingum Muskingum
Muskingum Cunge 8 Point Muskingum Cunge 8 Point
Muskingum Cunge Standard Muskingum Cunge Standard
Straddle Stragger Straddle Stragger
Coded value domain
TransformType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Clark Clark
Modified Clark Modified Clark
SCS SCS
Snyder Snyder
Kinematic Wave Kinematic Wave
User-Specified S-Graph User-Specified S-Graph
User-Specified UH User-Specified UH
MuskingumCungeShapeType
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasGridcells
Origin feature class Destination table
Simple
One to Many
None
Gridcells
Subbasin
HMSSubbasin
HMSCode
HMSCode
GridcellName
HydroID of the associated Arc Hydro element
Permenant HMS identifier for the element
X-locator of element within the HMS basin map
Y-locator of element within the HMS basin map
X-locator of element label relative to element
Y-locator of element label relative to element
Discharge gage related to the element
Description of the element stored in HMS
BooleanYesNo
Permenant HMS identifier for the element
Downstream X-locator within the HMS basin map
Downstream Y-locator within the HMS basin map
X-locator of element label relateve to element
Y-locator of element label relative to element
Discharge gage related to the element
Description of the element stored in HMS
KinematicWaveShapeTy
pe
Routing Methods
LossRate MethodsTransform Methods
Channel shape
Channel shape
Variable that goes on horizontal axis (1 or 2)
HydroID of the associated Arc Hydro element
Permenant HMS identifier for the element
X-locator of element within the HMS basin map
Y-locator of element within the HMS basin map
X-locator of element label relative to element
Y-locator of element label relative to element
Discharge gage related to the element
Description of the element stored in HMS
HydroID of the associated Arc Hydro element
Permenant HMS identifier for the element
X-locator of element within the HMS basin map
Y-locator of element within the HMS basin map
X-locator of element label relative to element
Y-locator of element label relative to element
Discharge gage related to the element
Description of the element stored in HMS
HydroID of the associated Arc Hydro element
Permenant HMS identifier for the element
X-locator of element within the HMS basin map
Y-locator of element within the HMS basin map
X-locator of element label relative to element
Y-locator of element label relative to element
Discharge gage related to the element
Description of the element stored in HMS
HydroID of the associated Arc Hydro element
Permenant HMS identifier for the element
X-locator of element within the HMS basin map
Y-locator of element within the HMS basin map
X-locator of element label relative to element
Y-locator of element label relative to element
Discharge gage related to the element
Description of the element stored in HMS
ArcGIS HEC-HMS Interface Data Model (Draft)
Center for Research in Water Resources
Basin Geodatabase
ArcCatalog View
May 2004
CRWR
Paired Data Tables
Reach Routing Parameters
Gridcell Tables
Watershed Transform Parameters
Watershed LossRate Parameters
InitialIn Double Yes 0 0 Initial inflow (cfs / cms)
Coded value domain
TSsDType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Regular Regular
Irregular Irregular
Coded value domain
TSsType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
per-cum per-cum
per-aver per-aver
inst-cum inst-cum
inst-val inst-val
The University of Texas at Austin
Created by:  Dan Obenour, obenour@mail.utexas.edu
Gridded SCS Gridded SCS
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
Table
Route_MuskCunge8Pt
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Muskingum-Cunge 8-Point
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
ReachL Long integer Yes 0 Reach length (ft / m)
EnergyS Double Yes 0 0 Energy slope
LeftOBN Double Yes 0 0 Manning's number for left overbank
RightOBN Double Yes 0 0 Manning's number for right overbank
ChannelN Double Yes 0 0 Manning's number for channel
Sta1 Double Yes 0 0 Station location 1 (ft / m)
Elev1 Double Yes 0 0 Elevation at station 1 (ft / m)
Sta2 Double Yes 0 0 Station location 2 (ft / m)
Elev2 Double Yes 0 0 Elevation at station 2 (ft/m)
Sta3 Double Yes 0 0 Station location 3 (ft / m)
Elev3 Double Yes 0 0 Elevation at station 3 (ft/m)
Sta4 Double Yes 0 0 Station location 4 (ft / m)
Elev4 Double Yes 0 0 Elevation at station 4 (ft/m)
Sta5 Double Yes 0 0 Station location 5 (ft / m)
Elev5 Double Yes 0 0 Elevation at station 5 (ft/m)
Sta6 Double Yes 0 0 Station location 6 (ft / m)
Elev6 Double Yes 0 0 Elevation at station 6 (ft/m)
Sta7 Double Yes 0 0 Station location 7 (ft / m)
Elev7 Double Yes 0 0 Elevation at station 7 (ft/m)
Sta8 Double Yes 0 0 Station location 8 (ft / m)
Elev8 Double Yes 0 0 Elevation at station 8 (ft/m)
Table
Route_StraddleStagger
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Straddle Stagger
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
Lag Double Yes 0 0 Lag (hr)
StraddleStg Double Yes 0 0 Straddle duration (hr)
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasRoute_MuskCunge8Pt
Origin feature class Destination table
Simple
One to one
None
R_MuskCunge8Pt
Reach
HMSReach
HMSCode
HMSCode
Route_Musk
Cunge8Pt
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSReachHasRoute_StaddleStagger
Origin feature class Destination table
Simple
One to one
None
R_Staddle
Stagger
Reach
HMSReach
HMSCode
HMSCode
Route_Straddle
Stagger
Name
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
BasinCode String Yes 20 Name of basin file
Table
Transform_KinematicWave
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Kinematic Wave
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
P1Length Double Yes 0 0 Plane 1 length (ft / m)
P1Slope Double Yes 0 0 Plane 1 slope
P1Rough Double Yes 0 0 Plane 1 roughness
P1PerArea Double Yes 0 0 Plane 1 percent of subbasin area
P1MinSteps Long integer Yes 0 Plane 1 minimum distance steps
P2Length Double Yes 0 0 Plane 2 length (ft / m)
P2Slope Double Yes 0 0 Plane 2  slope
P2Rough Double Yes 0 0 Plane 2 roughness
P2PerArea Double Yes 0 0 Plane 2 percent of subbasin area
P2MinSteps Long integer Yes 0 Plane 2 minimum distance steps
C1Length Double Yes 0 0 Collector channel 1 length (ft / m)
C1Slope Double Yes 0 0 Collector channel 1 slope
C1MN Double Yes 0 0 Collector channel 1 roughness
C1Shape String Yes 10 Collector channel 1 shape
C1WidDia Double Yes 0 0 Collector channel 1 width/diameter (ft / m)
C1SideS Double Yes 0 0 Collector channel 1 side slope
C1ConArea Double Yes 0 0 Collector channel 1 contributing area (sqmi / sqkm)
C1MinSteps Long integer Yes 0 Collector channel 1 minimum number of distancesteps
C2Length Double Yes 0 0 Collector channel 2 length (ft / m)
C2Slope Double Yes 0 0 Collector channel 2 slope
C2MN Double Yes 0 0 Collector channel 2 roughness
C2Shape String Yes 10 Collector channel 2 shape
C2WidDia Double Yes 0 0 Collector channel 2 width/diameter (ft / m)
C2SideS Double Yes 0 0 Collector channel 2 side slope
C2ConArea Double Yes 0 0 Collector channel 2 contributing area (sqmi / sqkm)
C2MinSteps Long integer Yes 0 Collector channel 2 minimum number of distancesteps
CMLength Double Yes 0 0 Main channel length (ft / m)
CMSlope Double Yes 0 0 Main channel slope
CMMN Double Yes 0 0 Main channel roughness
CMShape String Yes 10 Main channel shape
CMWidDia Double Yes 0 0 Main channel width/diameter (ft / m)
CMSideS Double Yes 0 0 Main channel side slope
CMMinSteps Long integer Yes 0 Main channel minimum number of distance steps
CMRouteUS String Yes BooleanYesNo 3 Main channel, route upstream hydrograph
Table
Transform_UserSpecSGraph
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
S-Graph
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
SGraph String Yes 20 Name of S-graph
Lag Double Yes 0 0 Time lag (hr)
Table
Transform_UserSpecUHGraph
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Unit Hydrograph
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
UHGraph String Yes 20 Name of unit hydrograph
KinematicWaveShapeTyp
e
KinematicWaveShapeTyp
e
KinematicWaveShapeTyp
e
Table
Baseflow_BoundedRecession
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Bounded Recession
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
Recession Double Yes 0 0 Recession constant
FlowToArea Double Yes 0 0 Flow per area
FlowLimit1 Double Yes 0 0 Jan maximum baseflow (cfs /cms)
FlowLimit2 Double Yes 0 0 Feb maximum baseflow (cfs /cms)
FlowLimit3 Double Yes 0 0 Mar maximum baseflow (cfs /cms)
FlowLimit4 Double Yes 0 0 Apr maximum baseflow (cfs /cms)
FlowLimit5 Double Yes 0 0 May maximum baseflow (cfs /cms)
FlowLimit6 Double Yes 0 0 Jun maximum baseflow (cfs /cms)
FlowLimit7 Double Yes 0 0 Jul maximum baseflow (cfs /cms)
FlowLimit8 Double Yes 0 0 Aug maximum baseflow (cfs /cms)
FlowLimit9 Double Yes 0 0 Sep maximum baseflow (cfs /cms)
FlowLimit10 Double Yes 0 0 Oct maximum baseflow (cfs /cms)
FlowLimit11 Double Yes 0 0 Nov maximum baseflow (cfs /cms)
FlowLimit12 Double Yes 0 0 Dec maximum baseflow (cfs /cms)
Table
Baseflow_LinearReservoir
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Linear Reservoir
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
GW1Storage Double Yes 0 0 Groundwater 1, storage coefficient (hur)
GW1Resvs Long integer Yes 0 Groundwater 1, number of reservoirs
GW2Storage Double Yes 0 0 Groundwater 2, storage coefficient (hur)
GW2Resvs Long integer Yes 0 Groundwater 2, number of reservoirs
Table
Baseflow_MonthlyConstant
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Monthly Constant
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
Flow1 Double Yes 0 0
Flow2 Double Yes 0 0
Flow3 Double Yes 0 0
Flow4 Double Yes 0 0
Flow5 Double Yes 0 0
Flow6 Double Yes 0 0
Flow7 Double Yes 0 0
Flow8 Double Yes 0 0
Flow9 Double Yes 0 0
Flow10 Double Yes 0 0
Flow11 Double Yes 0 0
Flow12 Double Yes 0 0
Table
Baseflow_Recession
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Recession
OBJECTID Object ID
HMSCode String Yes 20 Permenant HMS identifier for element
BasinCode String Yes 20 Name of basin model
Recession Double Yes 0 0 Recession constant
InitialFlo Double Yes 0 0 Initial flow
IFloType String Yes InitialFlowType 15 Initial flow type
Threshold Double Yes 0 0 Threshhold flow (cfs / cms)
ThresType String Yes ThresholdType 15 Threshhold type
Jan baseflow (cfs /cms)
Feb baseflow (cfs /cms)
Mar baseflow (cfs /cms)
Apr baseflow (cfs /cms)
May baseflow (cfs /cms)
Jun baseflow (cfs /cms)
Jul baseflow (cfs /cms)
Aug baseflow (cfs /cms)
Sep baseflow (cfs /cms)
Oct baseflow (cfs /cms)
Nov baseflow (cfs /cms)
Dec baseflow (cfs /cms)
Baseflow Methods
Watershed Baseflow Parameters
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasTransform_SGraph
Origin feature class Destination table
Simple
One to one
None
Tr_UserSpecS
Graph
Subbasin
HMSSubbasin
HMSCode
HMSCode
Transform_User
SpecSGraph
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasTransform_UHGraph
Origin feature class Destination table
Simple
One to one
None
Tr_UserSpec
UHGraph
Subbasin
HMSSubbasin
HMSCode
HMSCode
Transform_User
SpecUHGraph
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasTransform_KW
Origin feature class Destination table
Simple
One to one
None
T_KW
Subbasin
HMSSubbasin
HMSCode
HMSCode
Transform_Kinemat
icWave
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HasBaseflow_BoundedRecession
Origin feature class Destination table
Simple
One to one
None
Bf_BoundedR
Subbasin
HMSSubbasin
HMSCode
HMSCode
Baseflow_Bounded
Recession
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HasBaseflow_LinearReservoir
Origin feature class Destination table
Simple
One to one
None
Bf_Linear
Reservoir
Subbasin
HMSSubbasin
HMSCode
HMSCode
Baseflow_Linear
Reservoir
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HasBaseflow_MonthlyConstant
Origin feature class Destination table
Simple
One to one
None
Bf_Monthly
Constant
Subbasin
HMSSubbasin
HMSCode
HMSCode
Baseflow_Monthly
Constant
Name
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSSubbasinHasBaseflow_Recession
Origin feature class Destination table
Simple
One to one
None
Bf_Recession
Subbasin
HMSSubbasin
HMSCode
HMSCode
Baseflow_
Recession
Name
Coded value domain
BaseflowType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
None None
SMA Groundwater SMA Groundwater
Recession Recession
Monthly Constant Monthly Constant
Bounded Recession Bounded Recession
Coded value domain
InitialFlowType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Flow per Area Flow per Area
Total Flow Total Flow
Coded value domain
UnitType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
English English
SI SI
Coded value domain
ThresholdType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Flow Flow
Ratio of Peak Ratio of Peak
Coded value domain
ResCurveType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Storage-Elevation-Outflow (MP) Storage-Elevation-Outflow (MP)
Storage-Outflow (MP) Storage-Outflow (MP)
Elevation-Area-Outflow (MP) Elevation-Area-Outflow (MP)
Elevation-Storage (CO) Elevation-Storage (CO)
Elevation-Area (CO) Elevation-Area (CO)
InEqualOut String Yes BooleanYesNo 3 Records whether initial inflow equals outflow
InitialStr Double Yes 0 0 Initial storage value (ac-ft / cm)
InitialFlo Double Yes 0 0 Initial flow value (cfs / cms)
Timeseries Tables
Table
DSSTimeSeries
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Time Series
OBJECTID Object ID
DSSTSID Long integer Yes 0 Unique identifier for pathname
TSDateTime Date Yes 0 0 8 Date and time for time series value
TSValue Double Yes 0 0 Time series value
Table
DSSTSCatalog
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Time Series Catalog
OBJECTID Object ID
PathName
Long integer Yes 0DSSTSID
String Yes 80
A_Part String Yes 50
B_Part String Yes 50
C_Part String Yes 50
D_Part String Yes 50
E_Part String Yes 50
F_Part String Yes 50
sUnits String Yes 7
sType String Yes TSsType 8
sDType String Yes TSsDType 9
DSSFPath String Yes 255
DSS pathname
Unique identifier for pathname
Units of measurement
Data type
Regular or irregular timeseries
Location of DSS file
Pathname A-part (Optional)
Pathname B-part (HMSCode)
Pathname C-part (Variable type)
Pathname D-part (Block start time)
Pathname E-part (Time interval)
Pathname F-part (Source/Run)
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
DSSTSCatalogHasDSSTimeSeries
Origin table Destination table
Simple
One to many
None
DSSTimeSeries
DSSTSCatalog
DSSTSCatalog
DSSTSID
DSSTSID
DSSTimeSeriesName
ArcGIS HEC-HMS Interface Data Model (Draft)
Center for Research in Water Resources
Table
Project_BasinGeoPaths
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Basin Geodatabases
OBJECTID Object ID
BasinCode String Yes 20 Basin file name
BGeoPath String Yes 255 Basin geodatabase location
Table
Project_Controls
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Controls
OBJECTID Object ID
ContrlCode String Yes 20 Name of control
FileWExt String Yes 50 File name with extension
LastDate String Yes 20 Last date control was run
LastTime String Yes 8 Last time control was run
StartDate String Yes 20 Start date of model run
StartTime String Yes 5 Start time of model run
EndDate String Yes 20 End date of model run
EndTime String Yes 5 End time of model run
CInterval String Yes 20 Time interval between calculations
Descrip String Yes 255 Description of control
Table
Project_HMSIndex
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
HMS File Index
OBJECTID Object ID
Code String Yes 20 Appropriate MetCode, BasinCode, or ControlCode
FileWExt String Yes 50 File name with extension
Type String Yes FileType 20 File type
Descrip String Yes 255 File description
Table
Project_Runs
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Runs
OBJECTID Object ID
RunCode String Yes 20 Name of run
BasinCode String Yes 20 Name of basin used in run
MetCode String Yes 20 Name of meteorological model used in run
ContrlCode String Yes 20 Name of control used in run
LastDatePr String Yes 20 Last date precipitation model was run
LastTimePr String Yes 8 Last time precipitation model was run
LastDateBs String Yes 20 Last date basin model was run
LastTimeBs String Yes 8 Last time basin model was run
LogFile String Yes 50 Name of the run's log file
Descrip String Yes 255 Description of run
Project Geodatabase
ArcCatalog View
May 2004
CRWR
Project Indices
The University of Texas at Austin
Scenario Management
Table
DSSTimeSeries
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Time Series
OBJECTID Object ID
DSSTSID Long integer Yes 0 Unique identifier for pathname
TSDateTime Date Yes 0 0 8 Date and time for time series value
TSValue Double Yes 0 0 Time series value
Table
DSSTSCatalog
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Time Series Catalog
OBJECTID Object ID
PathName
Long integer Yes 0DSSTSID
String Yes 80
A_Part String Yes 50
B_Part String Yes 50
C_Part String Yes 50
D_Part String Yes 50
E_Part String Yes 50
F_Part String Yes 50
sUnits String Yes 7
sType String Yes TSsType 8
sDType String Yes TSsDType 9
DSSFPath String Yes 255
DSS pathname
Unique identifier for pathname
Units of measurement
Data type
Regular or irregular timeseries
Location of DSS file
Pathname A-part (Optional)
Pathname B-part (HMSCode)
Pathname C-part (Variable type)
Pathname D-part (Block start time)
Pathname E-part (Time interval)
Pathname F-part (Source/Run)
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
DSSTSCatalogHasDSSTimeSeries
Origin table Destination table
Simple
One to many
None
DSSTimeSeries
DSSTSCatalog
DSSTSCatalog
DSSTSID
DSSTSID
DSSTimeSeriesName
Time Series Tables
Simple feature class
HMSGage Contains Z valuesContains M values
Geometry Point
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Gage Features
OBJECTID Object ID
Shape Geometry Yes
FeatureID Long integer Yes 0
GageCode String Yes 20
Descrip String Yes 255
Latitude Long integer Yes 0
Longitude Long integer Yes 0
GageType String Yes GageType 15
PrecipType String Yes PrecipType 15
Units String Yes GageUnitType 7
IsLocal String Yes BooleanYesNo 3
StartTime String Yes 50
EndTime String Yes 50
DSSFPath String Yes 255
PathName String Yes 80
Simple feature class
HMSGrid Contains Z valuesContains M values
Geometry Polygon
No
No
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Grid Cell Features
OBJECTID Object ID
Shape Geometry Yes
GridID Long integer Yes 0 User defined grid identifier
CellID Long integer Yes 0 Array value of grid cell
XCoord Long integer Yes 0 X coordinate of cell, west-most column  = 0
YCoord Long integer Yes 0 Y-coordinate of cell, south-most row = 0
Shape_Length Double Yes 0 0
Shape_Area Double Yes 0 0
HydroID of the associated ArcHydro element
Permenant HMS identifier for the element
Description of the element stored in HMS
Latitude of gage location
Longitude of gage location
Records if gage measures precipitation or flow
Records if gage data is instantaneous or cumulative
Units of measurement
Records if default DSS file should be used
Starting date & time of gage recording
End date & time of gage recording
DSS file location
DSS pathname
Table
DSSGridCatalog
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Grid Time Series
Catalog
OBJECTID Object ID
DSSGridID Long integer Yes 0 Unique identifier for pathname
PathName String Yes 80 DSS pathname
A_Part String Yes 50 Pathname A-part
B_Part String Yes 50 Pathname B-part
C_Part String Yes 50 Pathname C-part
D_Part Date Yes 0 0 8 Pathname D-part (beginning of time step)
E_Part Date Yes 0 0 8 Pathname E-part (end of time step)
F_Part String Yes 50 Pathname F-part
CellSize Double Yes 0 0 Cell Area
MinDatVal Double Yes 0 0 Minimum Data Value
MeanDatVal Double Yes 0 0 Mean Data Value
MaxDatVal Double Yes 0 0 Maximum Data Value
Units String Yes 255 Units of measurement
XCellLL Long integer Yes 0 X Coord. of lower left hand cell (based on a recognized system)
YCellLL Long integer Yes 0 Y Coord. of lower left hand cell (based on a recognized system)
XCellCount Long integer Yes 0 Number of columns in grid
YCellCount Long integer Yes 0 Number of rows in grid
GridType Long integer Yes 0 Unique identifier for a recognized geographic system
DataType Long integer Yes 0 Unique identifier for data type
RangeCount Long integer Yes 0 Number of ranges (range statistics)
HRAPSource String Yes 255 HRAP only, data source
SHGDatum Long integer Yes 0 SHG only, datum
SHGUnits String Yes 255 SHG only, units
SHGOnePll Double Yes 0 0 SHG only, first standard parallel
SHGTwoPll Double Yes 0 0 SHG only, second standard parallel
SHGCentral Double Yes 0 0 SHG only, central meridian
SHGLatOrig Double Yes 0 0 SHG only, lattitude of origin
SHGFalseE Double Yes 0 0 SHG only, false easting
SHGFalseN Double Yes 0 0 SHG only, false northing
SHGXCellLL Double Yes 0 0 SHG only, X coordinate of Cell (0,0)
SHGYCellLL Double Yes 0 0 SHG only, Y coordinate of Cell (0,0)
Table
DSSGridData
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Grid Time Series
OBJECTID Object ID
DSSGridID Long integer Yes 0 Unique identifier for pathname
CellID Long integer Yes 0 Array value of grid cell
TSValue Double Yes 0 0 Time series value
Table
DSSGridRange
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Grid Data Ranges
OBJECTID Object ID
DSSGridID Long integer Yes 0 Unique identifier for pathname
LowerLimit Double Yes 0 0 Lower limit threshold value
CellsAbove Long integer Yes 0 Number of cells with a value greater than LowerLimit
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
DSSGridCatalogHasDSSGridData
Origin table Destination table
Simple
One to many
None
DSSGridData
DSSGridCatalog
DSSGridCatalog
DSSGridID
DSSGridID
DSSGridDataName
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
DSSGridCatalogHasDSSGridRange
Origin table Destination table
Simple
One to many
None
DSSGridRange
DSSGridCatalog
DSSGridCatalog
DSSGridID
DSSGridID
DSSGridRangeName
Grid Series Tables
Relationship class
Name
Primary key
Foreign key
Type
Cardinality
Notification
Forward label
Backward label
No relationship rules defined.
HMSGageHasDSSTSCatalog
Origin feature class Destination table
Simple
One to many
None
DSSTSCatalog
HMSGage
HMSGage
PathName
PathName
DSSTSCatalogName
Table
SMAUnits
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Soil Moisture Accounting
OBJECTID Object ID
SMACode String Yes 50 Name of SMA System
CanopySt Double Yes 0 0 Canopy storage capacity (in / mm)
SurfaceSt Double Yes 0 0 Surface storage capacity (in / mm)
SurfaceIn Double Yes 0 0 Infiltration rate (in/hr / mm/hr)
SoilSt Double Yes 0 0 Soil storage capacity (in / mm)
SoilTZ Double Yes 0 0 Soil tension zone storage capacity (in / mm)
SoilPercRt Double Yes 0 0 Soil percolation rate (in/hr / mm/hr)
GW1St Double Yes 0 0 Groundwater layer 1 storage capacity (in / mm)
GW1PercRt Double Yes 0 0 Groundwater layer 1 percolation rate (in/hr / mm/hr)
GW1StCoeff Double Yes 0 0 Groundwater layer 1 storage coefficient (hr)
GW2St Double Yes 0 0 Groundwater layer 2 storage capacity (in / mm)
GW2PercRt Double Yes 0 0 Groundwater layer 2 percolation rate (in/hr / mm/hr)
GW2StCoeff Double Yes 0 0 Groundwater layer 2 storage coefficient (hr)
Evap1 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Jan
Evap2 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Feb
Evap3 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Mar
Evap4 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Apr
Evap5 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in May
Evap6 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Jun
Evap7 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Jul
Evap8 String Yes BooleanYesNo 3
Evap9 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Sep
Ev ap10 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Oct
Ev ap11 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Nov
Ev ap12 String Yes BooleanYesNo 3 Records whether to consider ET in tension zone in Dec
Records whether to consider ET in tension zone in Aug
Table
Meteorological_Evapotranspiration
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Evapotranspiration Zone
Data
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
EvapTCode String Yes 50 Name of evapotranspiration zone
Ev apT1 Double Yes 0 0 Jan evapotranspiration (in / mm)
Coeff1 Double Yes 0 0 Jan modification coefficient
Ev apT2 Double Yes 0 0 Feb evapotranspiration (in / mm)
Coeff2 Double Yes 0 0 Feb modification coefficient
Ev apT3 Double Yes 0 0 Mar evapotranspiration (in / mm)
Coeff3 Double Yes 0 0 Mar modification coefficient
Ev apT4 Double Yes 0 0 Apr evapotranspiration (in / mm)
Coeff4 Double Yes 0 0 Apr modification coefficient
Ev apT5 Double Yes 0 0 May evapotranspiration (in / mm)
Coeff5 Double Yes 0 0 May modification coefficient
Ev apT6 Double Yes 0 0 Jun evapotranspiration (in / mm)
Coeff6 Double Yes 0 0 Jun modification coefficient
Ev apT7 Double Yes 0 0 Jul evapotranspiration (in / mm)
Coeff7 Double Yes 0 0 Jul modification coefficient
Ev apT8 Double Yes 0 0 Aug evapotranspiration (in / mm)
Coeff8 Double Yes 0 0 Aug modification coefficient
Ev apT9 Double Yes 0 0 Sep evapotranspiration (in / mm)
Coeff9 Double Yes 0 0 Sep modification coefficient
EvapT10 Double Yes 0 0 Oct evapotranspiration (in / mm)
Coeff10 Double Yes 0 0 Oct modification coefficient
EvapT11 Double Yes 0 0 Nov evapotranspiration (in / mm)
Coeff11 Double Yes 0 0 Nov modification coefficient
EvapT12 Double Yes 0 0 Dec evapotranspiration (in / mm)
Coeff12 Double Yes 0 0 Dec modification coefficient
Evapotranspiration
Table
Project_HMSHeader
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Project Header
OBJECTID Object ID
PName String Yes 20
PFPath String Yes 255
Version String Yes 20
Descrip String Yes 255
DRoute String Yes RouteType 50
DSSFPath String Yes 255
DLossRate String Yes LossRateType 50
DBasinUnit String Yes UnitType 7
DMeteoUnit String Yes UnitType 7
DBaseflow String Yes BaseflowType 50
DTransform String Yes TransformType 50
DPrecip String Yes PrecipDistributionType 25
Evap String Yes BooleanYesNo 3
JuncFlow String Yes BooleanYesNo 3
FlowRatio String Yes BooleanYesNo 3
NoFlowTo0 String Yes BooleanYesNo 3
Table
Project_HMSPData
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Project Tables Index
OBJECTID Object ID
GraphCode String Yes 20 Place a succinct description of the field in this text
GraphType String Yes GraphType 20 Type of data
ExtnlDSS String Yes BooleanYesNo 3 Records if data is stored in an external DSS file
Descrip String Yes 255 Description of data
Units String Yes GageUnitType 7 Units of measurement
DSSFPath String Yes 255 Location of external DSS file
Pathname String Yes 80 DSS pathname
Project name
Project file location
HMS program version
Description of HMS project
Default Route method
Default DSS file location
Default LossRate method
Default basin file unit
Default meteorological file unit
Default Baseflow method
Default Transform method
Default precipitation distribution type
Enables evapotranspiration calcula tions
Enables junction flow calculations
Enables flow ratio calcula tions
Sets no-flow values to zero
Table
Meteorological_DistanceWeightedGage
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Distance Weighted Gage
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
GageCode String Yes 20 GageCode of related precipitation gage
GageType String Yes WeightingType2 15 Type of weighted gage
IndexPrecp Double Yes 0 0 Optional/alternate precipitation value
Table
Meteorological_DistanceWeightedSubbasins
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Distance Weighted
Subbasin/Nodes
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
HMSCode String Yes 20 HMSCode of related subbasin
NodeCode String Yes 50 Name of node
IndexPrecp Double Yes 0 0 Optional/alternate precipitation value
NodeWeight Double Yes 0 0 Weight of node (relative to subbasin)
Latitude Long integer Yes 0 latitude of node
Longitude Long integer Yes 0 longitude of node
EvapTCode String Yes 50 Evapotranspiration zone of subbasin
Table
Meteorological_FreqStorm
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Frequency Storm
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
ExceedFreq String Yes StormExceedType 4 Storm exceedence probability
SingleStm String Yes BooleanYesNo 3 Records if this is a single storm
ToAnnual String Yes BooleanYesNo 3 Records if this is an annual series storm
TimeIntrvl String Yes StormMaxDurType 6 Duration of maximum storm intensity
TimeTotal String Yes StormTotalDurType 5 Total storm duration
PeakLoctn String Yes StormDurToPkType 6 Percentage of storm occuring prior to peak
StormArea Double Yes 0 0 Storm area (sqmi / sqkm)
Precip5m Double Yes 0 0 Maximum precipitation to occur in 5 min
Precip15m Double Yes 0 0 Maximum precipitation to occur in 15 min
Precip1h Double Yes 0 0 Maximum precipitation to occur in 1 hr
Precip2h Double Yes 0 0 Maximum precipitation to occur in 2 hr
Precip3h Double Yes 0 0 Maximum precipitation to occur in 3 hr
Precip6h Double Yes 0 0 Maximum precipitation to occur in 6 hr
Precip12h Double Yes 0 0 Maximum precipitation to occur in 12 hr
Precip24h Double Yes 0 0 Maximum precipitation to occur in 24 hr
Table
Meteorological_FreqStormSubbasins
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Frequency Storm Subbasins
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
HMSCode String Yes 20 HMSCode of related subbasin
EvapTCode String Yes 50 Evapotranspiration zone of subbasin
Table
Meteorological_GriddedPrecip
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Gridded Precipitation
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
DSSFile String Yes 255 DSS file location
A_Part String Yes 50 Pathname A-part of DSS grid record
B_Part String Yes 50 Pathname B-part of DSS grid record
C_Part String Yes 50 Pathname D-part of DSS grid record
F_Part String Yes 50 Pathname F-part of DSS grid record
MissingTo0 String Yes BooleanYesNo 3 Sets missing data values to zero
TimeLag Long integer Yes 0 Time adjustment (hr)
Table
Meteorological_SCSStorm
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
SCS Storm
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
StormType String Yes StormSCSType 10 SCS storm type
Depth Double Yes 0 0 Total storm depth
Table
Meteorological_SCSStormSubbasins
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
SCS Storm Subbasins
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
HMSCode String Yes 20 HMSCode of related subbasin
EvapTCode String Yes 20 Evapotranspiration zone of subbasin
Table
Meteorological_StdProjectStorm
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Standard Project Storm
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
IndexPrecp Double Yes 0 0 Optional/alternate precipitation value
StormArea Double Yes 0 0 Storm area (sqmi / sqkm)
SWD String Yes BooleanYesNo 3 Place a succinct description of the field in this text
Table
Meteorological_StdProjectStormSubbasins
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
Standard Project Storm
Subbasins
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
HMSCode String Yes 20 HMSCode of related subbasin
TranspoF Double Yes 0 0 Place a succinct description of the field in this text
EvapTCode String Yes 50 Evapotranspiration zone of subbasin
Table
Meteorological_UserHyetograph
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
User Hyetograph
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
HMSCode String Yes 20 HMSCode of related subbasin
GageCode String Yes 20 Place a succinct description of the field in this text
EvapTCode String Yes 50 Evapotranspiration zone of subbasin
Table
Meteorological_UserWeightedGage
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
User Weighted Gage
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
GageCode String Yes 20 GageCode of related precipitation gage
GageType String Yes WeightingType 15 Type of weighted gage
IndexPrecp Double Yes 0 0 Optional/alternate precipitation value for gage
TotalPrecp Double Yes 0 0 Optional precipitation value, adjusts DSS proportionally
Table
Meteorological_UserWeightedSubbasin
Data typeField name
Prec-
ision ScaleLengthDomainDefault value
Allow
nulls
User Weighted Subbasins
OBJECTID Object ID
MetCode String Yes 20 Name of meteorological model
HMSCode String Yes 20 HMSCode of related subbasin
SubIndex Double Yes 0 0 Optional/alternate precipitation value for subbasin
GageCode String Yes 20 GageCode of related precipitation gage
VolWeight Double Yes 0 0 Determines effect of precip. gage on storm volume
TDistribute Double Yes 0 0 Determines effect of precip. gage on storm temporal distr.
EvapTCode String Yes 50 Evapotranspiration zone of subbasin
Meteorological Parameters
Coded value domain
AxisType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
UNT UNT
LOG LOG
PROB PROB
Coded value domain
BaseflowType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
None None
SMA Groundwater SMA Groundwater
Recession Recession
Monthly Constant Monthly Constant
Bounded Recession Bounded Recession
Coded value domain
BooleanYesNo
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Yes Yes
No No
Coded value domain
FileType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Basin Basin
Control Control
Precipitation Precipitation
Coded value domain
GageType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Precipitation Precipitation
Flow Flow
Coded value domain
GageUnitType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Inches Inches
MM MM
CFS CFS
M3/S M3/S
Coded value domain
GraphType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
S-graph S-graph
Unit Hydrograph Unit Hydrograph
Coded value domain
GraphUnitType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
cfs cfs
cms cms
Coded value domain
GriddedPrecipPathType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
A= B= C= F= A= B= C= F=
Coded value domain
GridParameterType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
XCoord XCoord
YCoord YCoord
TravelLength TravelLength
Area Area
SCSCN SCSCN
SMAUnit SMAUnit
None None
Coded value domain
LossRateType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
None None
Green and Ampt Green and Ampt
Initial+Constant Initial+Constant
Deficit Constant Deficit Constant
Soil Moisture Account Soil Moisture Account
Gridded Soil Moisture Account Gridded Soil Moisture Account
Gridded SCS Gridded SCS
Coded value domain
MissingRe cordActionType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Undefined Undefined
Set data to zero Set data to zero
Coded value domain
PrecipDistributionType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Gridded Precipitation Gridded Precipitation
Specified Average Specified Average
Weighted Gages Weighted Gages
Coded value domain
PrecipType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Incremental Incremantal
Cumulative Cumulative
Coded value domain
RouteType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
None None
Kinematic Wave Kinematic Wave
Lag Lag
Modified Puls Modified Puls
Muskingum Muskingum
Muskingum Cunge 8 Point Muskingum Cunge 8 Point
Muskingum Cunge Standard Muskingum Cunge Standard
Straddle Stragger Straddle Stragger
Coded value domain
StormDurToPkType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
25 25%
33 33%
50 50%
67 67%
75 75%
Coded value domain
StormExceedType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
0.2 0.2%
0.4 0.4%
1 1%
2 2%
4 4%
10 10%
20 20%
50 50%
Coded value domain
StormMaxDurType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
5 5 min
15 15 min
50 1 hr
120 2 hr
180 3 hr
360 6 hr
Coded value domain
StormSCSType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Type I Type I
Type Ia Type Ia
Type II Type II
Type III Type III
Coded value domain
StormTotalDurType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
50 1 hr
120 2 hr
180 3 hr
360 6 hr
720 12 hr
1440 24 hr
2880 2 dy
5760 4 dy
10080 7 dy
14400 10 dy
Coded value domain
TransformType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Clark Clark
Modified Clark Modified Clark
SCS SCS
Snyder Snyder
Kinematic Wave Kinematic Wave
User-Specified S-Graph User-Specified S-Graph
User-Specified UH User-Specified UH
Coded value domain
UnitType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
English English
SI SI
Coded value domain
WeightingType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Recording Recording
Total Storm Total Storm
Coded value domain
WeightingType2
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Recording Recording
Non Recording Non Recording
Coded value domain
TSsDType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
Regular Regular
Irregular Irregular
Coded value domain
TSsType
Description
Field type
Split policy
Merge policy
String
Default value
Default value
DescriptionCode
per-cum per-cum
per-aver per-aver
inst-cum inst-cum
inst-val inst-val
 
Appendix G:  Instructions ? ?Populating a HMS IDM? 
 165
 
Populating the GIS-HMS Interface Data Model 
 
Dan Obenour (8/30/03) 
 
 
 
Introduction: 
 
The GIS-HMS Interface Data Model (IDM) is a geodatabase format for storing the 
information found in a HEC-HMS project.  The following instructions describe how to 
create the IDM and how to populate it using existing GIS and HMS files.  The 
instructions assume that the user has a working knowledge of ArcMap and ArcCatalog. 
 
Unlike the Arc Hydro data model, the IDM requires two or more geodatabases.  One 
geodatabase represents data relevant to the entire HMS project; the other geodatabases 
represent data particular to individual basin files.  The first part of these instructions 
describes how to develop a ?Basin? geodatabase.  The second part describes how to 
develop a ?Project? geodatabase. 
 
The repository and executable files referenced in these instructions are included in the 
report CD?s, or they may be obtained from the following website: 
http://civilu.ce.utexas.edu/stu/obenoudr/ahtohms.html 
 
 
Part I ? Basin Geodatabase 
 
1. Apply the IDM Basin schema: 
a. Open ArcCatalog 
b. Create a new geodatabase.  Any name is fine, but the following naming 
structure is suggested:  ProjectName_BasinNameBasin.mdb 
c. Select the geodatabase, and press the ?Case Schema Creation? tool.  This 
tool can be accessed through the following selections:  
{Tools>Customize> Commands>Case Tools>Schema Wizard} 
i. Select the repository file (Basin.mdb) 
ii. Proceed through dialogue boxes, no changes are necessary 
until the user arrives at the ?Select the feature datasets to 
create? box. 
iii. Select the ?HMSFeatures? feature dataset.  Click on 
?Properties?. 
iv. Edit the spatial reference frame so that it is appropriate for 
your project?s location. 
v. Continue through the dialogue boxes.  Finish. 
d.  Exit ArcCatalog 
 
 166
 
 
2. Import HMS .basin file data 
a. Open BasinToGeo.exe program.  (see image below) 
i. Top text box:  Navigate to HMS .basin file 
ii. Bottom text box:  Navigate to Basin Geodatabase 
b. Click ?Transfer Parameters? 
 
 
 
 
3. Import GIS shape data 
a. Verify that a geodatabase exists with all necessary shape data 
b. Verify that the geodatabase has a field with HMSCodes (so that the 
features in it can be matched with features in the IDM Basin Geodatabase) 
c. Open ShapesToGeo.exe program (see image below) 
i. Top, left text box:  Navigate to geodatabase with shape data 
ii. Top, right text box:  Navigate to Basin Geodatabase 
iii. Activate data transfer options, based on the Target Feature Classes 
you want to fill 
iv. Enter the names of the Source Feature Classes. 
v. Enter the names of the Source Fields that contain HMSCodes 
d. Click ?Transfer Shape Data? 
 
 167
 
 
4. Import HMS paired data 
a. Open PDToGeo.exe program. (see image below) 
i. Top text box:  Navigate to HMS .dss file 
ii. Bottom text box:  Navigate to Basin Geodatabase 
iii. Click ?Query Setup? 
1. Enter appropriate query information: 
a. For HMS Version 2.1, enter basin name in F-Part 
text box.  All other boxes should be empty. 
b. For HMS Version 2.2, enter basin name in B-Part 
text box.  Check ?Check Basin name only?.  All 
other boxes should be empty 
2. Click ?Finished? 
b. Click ?Transfer Parameters? 
 
 168
 
 
 
 
Part II ? Project Geodatabase 
 
5. Apply the IDM Project schema: 
a. Open ArcCatalog 
b. Create a new geodatabase.  Any name is fine, but the following naming 
structure is suggested:  ProjectName_Project.mdb 
c. Select the geodatabase, and press the ?Case Schema Creation? tool.  This 
tool can be accessed through the following selections:  
{Tools>Customize> Commands>Case Tools>Schema Wizard} 
vi. Select the repository file (Project.mdb) 
 169
vii. Proceed through dialogue boxes, no changes are necessary 
until the user arrives at the ?Select the feature datasets to 
create? box. 
viii. Select the ?HMSGage? feature class.  Click on 
?Properties?. 
ix. Edit the spatial reference frame so that it is appropriate for 
your project?s location. 
x. Continue through the dialogue boxes.  Finish. 
d.  Exit ArcCatalog 
6. Import HMS .control, .run, and .hms file data 
a. Open ControlsToGeo.exe program.  (see image below) 
i. Top text box:  Navigate to HMS .hms file 
ii. Bottom text box:  Navigate to Project Geodatabase 
b. Click ?Transfer Parameters? 
 
 
 
 170
 
7. Import HMS .met file data 
a. Open MetToGeo.exe program.  (see image below) 
i. Top text box:  Navigate to HMS .met file 
ii. Bottom text box:  Navigate to Project Geodatabase 
b. Click ?Transfer Parameters? 
c. Repeat for additional .met files. 
 
 
 
 
 
 
8. Import HMS .gage file data 
a. Open GageToGeo.exe program.  (see image below) 
i. Top text box:  Navigate to HMS .gage file 
ii. Bottom text box:  Navigate to Project Geodatabase 
b. Click ?Transfer Parameters? 
c. Optional:  Follow the steps outlined in (Section 3) to import HMS gage 
shape data. 
 
 
 
 
 171
 
9. Import HMS timeseries data 
a. Open TSToGeo.exe program. (see image below) 
i. Top text box:  Navigate to HMS .dss file 
ii. Bottom text box:  Navigate to Basin Geodatabase 
iii. Click ?Query Setup? 
1. Enter appropriate query information.  Note:  Because of the 
large size of DSS timeseries, attempting to import all data 
at once may not be possible.  An alternative is to import 
data in a series of unique queries.* 
2. Click ?Finished? 
b. Click ?Transfer Parameters? 
c. Repeat until all timeseries data has been imported.* 
 
 
 
 
 172
10. Finishing 
a. View all geodatabases in ArcMap to confirm that data is correct. 
b. Compact geodatabases in ArcCatalog to conserve disk space. 
 
 173
 
Appendix H:  Instructions ? ?Preparation of Floodplain Mapping Data? 
 174
 
Preparation of Floodplain Mapping Data 
 
Dan Obenour 
1/21/04 
 
 
I. Required Data: 
a. Halff land surface TINs 
b. Halff TIN boundary layer 
c. Halff RAS cross section layer 
d. Halff/LCRA  floodplain layers 
e. Halff/LCRA HEC-RAS model 
II. Preparation Procedure: 
a. In ArcCatalog prepare a geodatabase: 
i. Select a region of interest (i.e. Bastrop) 
ii. Create a personal geodatabase with an appropriate name (i.e.Bastrop) 
iii. Create a feature dataset, and assign it a spatial reference equal to the 
extents of the LCR basin.  Assign it an appropriate name (i.e. Bastrop) 
iv. Leave geodatabase empty 
b. In ArcMap prepare TIN boundaries and cross sections: 
i. Load the TIN boundary layer and RASS cross section layer. 
ii. Select the TIN boundary polygon(s) relevant to the area of interest (i.e. 
Bastrop) 
iii. Export the selected polygon(s) to your personal geodatabase.  Display 
this new layer.  Remove the original TIN boundary layer from ArcMap 
iv. Select by location those cross sections that intersect the TIN boundary 
polygon(s). 
v. Export the selected cross sections to your personal geodatabase.  
Display this new layer.  Remove the original cross section layer from 
ArcMap. 
c. Prepare example water surface elevations: 
i. Open the relevant HEC-RAS project 
1. View the output table for a representative storm event (i.e. 
100yr flood) 
2. Under the File menu, select Copy Data and Headings to Clip 
Board 
ii. Open an empty Excel Spreadsheet 
1. Paste Data 
2. Delete all fields except ?Station? and ?W. S. Elev? (maximum) 
3. Make sure that there is only one heading row.  (delete units 
row and any other extra heading rows) 
4. Delete any records that do not have a value for W.S. Elev 
5. Delete any text appended to station values in the station field 
(all values should be integer values) 
 175
6. Create a third field that equals [W.S. Elev]*100 (only a .dbf 
file can be imported into a geodatabase, and .dbf files do not 
support decimals) 
7. Copy the values in this new field to clipboard 
8. ?Paste Special? these values into the ?W.S. Elev? field.  Delete 
the third field created in step 4. 
9. Save spreadsheet as a dBase (.dbf) file. 
iii. Open ArcCatalog 
1. Select the .dbf file and export this ?Table to Geodatabase? 
2. Export to the geodatabase created in part a. 
iv. Open ArcMap; load cross sections and water surface elevation table. 
1. Join the water surface elevation table to the cross section table 
2. Open the cross section attribute table 
3. Select all cross sections that have a ?WSElev? of Null (these 
should be only the most upstream and most downstream 
sections) 
4. Close the attribute table.  Turn on the Editor and delete these 
cross sections.  Turn off the Editor. 
5. Reopen the cross section attribute table, add a field with data 
type = <double> and name = ?WSElev? 
6. Add another field, with data type <text> and name = ?Type?  
7. Calculate WSElev = water surface values from joined table 
divided by 100 (i.e. WSElev = 
[Bastrop100.W_S__ELEV]/100) 
8. Calculate Type = ?main stem? 
9. Remove Join 
10. Use Symbology (color ramp) to display the variation in water 
surface between cross sections 
d. In ArcMap, clip ?tails? off TINs: 
i. Load the TIN boundary feature class into ArcMap 
ii. If this includes more than one TIN boundary, select and export the 
individual TIN boundaries into unique feature classes. 
iii. Load one TIN into ArcMap  
iv. Change the TIN symbology for faster viewing. 
1. In Properties>Symbology, turn off ?Elevation? and ?Edge 
types? 
2. Add? ?Faces with the same symbol? 
v. Set the display of the TIN boundary feature class to 50% transparent 
vi. Verify that the relevant TIN boundary does not lie outside the TIN at 
any location.  Where necessary, edit the TIN boundary.  Buffering the 
TIN boundary (i.e. -20 feet) is often an effective solution. 
vii. Turn off the TIN display, but don?t remove. 
viii. Clip the TIN.  From the 3D Analyst, select Create/Modify TIN > Add 
Features To TIN 
 176
1. Select your input tin, and select the appropriate tin boundary 
layer.  For the tin boundary layer, select height source = none, 
triangulate as = soft clip, Tag value field = none. 
2. Select ?Save changes into the input TIN specified above?. 
Okay. 
3. Repeat steps for each relevant TIN 
e. Convert TINs to raster (DEM). 
i. Open ArcMap 
ii. From 3D Analyst, select Convert > TIN to Raster 
1. Select an appropriate input TIN 
2. Attribute = Elevation, Z-factor = 1, Cell Size = 20?, 
3. Assign an appropriate name: (i.e. ?dem9?) 
4. repeat steps for each relevant TIN 
iii. If there are multiple relevant TINs/rasters, then the rasters should 
probably be merged together.  Open ArcInfo Workstation, type the 
following: 
1. grid <enter> 
2. path\newgridname = merge(path\grid1, path\grid2, ?) 
(i.e?c:\temp\bastropdem = merge(c:\temp\dem9, 
c:\temp\dem10)) 
f. Modify Cross Sections in ArcMap: 
i. Load the 500yr, 100yr, and 2yr floodplain layers into ArcMap (for 
reference) 
ii. Load the relevant DEM into ArcMap (for reference) 
iii. Turn on the Editor, and select the Modify Feature Task 
iv. Select and modify cross sections so that they extend beyond the extent 
of the 500 yr floodplain (see figure) 
v. Where large coves exist, add new cross sections.  Assign these cross 
sections the station number, steam ID, reach ID, and elevation of an 
appropriate nearby cross section.  In the Type field, assign a value of 
?cove? (see figure) 
vi. Where the river is sinuous, add tails to the end of cross sections that 
approach each other (see figure) 
vii. Where original cross sections converge to nearly a single line, clip 
these lines (see figure) 
 
 177
 
 
 178
III. Procedure for testing the modified cross sections. 
a. Load modified cross sections, tin boundary, DEM, and Halff 100yr and 500yr 
floodplains into ArcMap 
b. From 3D Analyst, select ?Create TIN From Features? 
i. Select tin boundary, no values, soft clip 
ii. Select cross sections, WSElev, soft line 
c. Examine the resulting TIN relative to the 100yr and 500yr floodplains.  Make 
sure that the floodplains are assigned appropriate water surface elations.  Pay 
particular attention to coves and sinuous areas.  If necessary, modify cross 
sections and recreate TIN. 
d. From 3D Analyst, select Convert > TIN to Raster 
i. Select the water surface TIN 
ii. Attribute = Elevation, Z-factor = 1, Cell Size = 20?, 
e. From Spatial Analyst, select Raster Calculator 
i. Use the expression [waterSurfaceRaster] > [DEMraster] (the resulting 
Boolean raster will have a cell value of 1 where inundation occurs, and 
a cell value of 0 where the land stays ?dry?) 
f. From Spatial Analyst, select ?Convert Raster to Features? 
i. Input Raster = previous Calculation 
ii. Field = Value, Geometry = Polygon 
g. Delete ?dry? features 
i. Open feature class attribute table 
ii. Select by attribute GridCode = 0 
iii. Exit attribute table 
iv. Turn on Editor 
v. Delete selected features 
vi. Finish Editing 
Compare the resulting 100yr floodplain polygon to the Halff 100yr floodplain. 
 179
 
  
Appendix I:  Model Builder Layouts 
 180
Model:  GenerateFloodPlainOnly 
Toolset:  Generate New Results 
 
Model:  GenerateDamageReportOnly 
Toolset:  Generate New Results 
 
 181
Model:  GenerateAll 
Toolset:  Generate New Results 
 
Model:  ArchiveNew 
Toolset:  Manage New Results 
 
(See following pages for higher resolution graphics) 
 182
Model:  ArchiveNew (sheet 1 of 2) 
 
 183
Model:  ArchiveNew (sheet 2 of 2) 
 
 184
 
Model:  DeleteNewAll 
Toolset:  Manage New Results 
 
 
 185
Model:  DeleteArchivedFloodPlain 
Toolset:  Manage Archived Results 
 
 186
Model:  DeleteArchivedDamageReport 
Toolset:  Manage Archived Results 
 
 187
Model:  LCRA_RAStoXS 
Toolset:  Components 
 
Model:  LCRA_XStoStructP 
Toolset:  Components 
 
 188
Model:  LCRA_StructPtoDamage 
Toolset:  Components 
 
Model:  LCRA_RAStoXS 
Toolset:  Components 
 
 189
Model:  LCRA_XStoFloodMap 
Toolset:  Components 
 
 190
Model:  ReplaceTable 
Toolset:  Components 
 
 191
Model:  SDF2XML 
Toolset:  Scripts 
 
 
 
 192
Model:  XMLtoXSElev 
Toolset:  Scripts 
 
 
 
 
 193
References 
 
ESRI, 2003.  ArcSDE Information. Internet Site:  
<http://www.esri.com/software/arcgis/arcinfo/arcsde/> 
Gopalan, H., D. Maidment. 2003.  WRAPHydro Data Model: Finding Input Parameters 
for the Water Rights Analysis Package.  CRWR Online Publication 03-3.  
<http://www.crwr.utexas.edu/online.shtml> 
Halff & Associates.  2002. Colorado River Flood Damage Evaluation Report.  Fort 
Worth, Texas. 
Hydraulic Engineering Center (HEC).  2003.  CWMS Website.  U.S. Army Corps of 
Engineers.  <http://www.hec.usace.army.mil/cwms/cwms.html>   
Lower Colorado River Authority (LCRA). 1998.  LCRA Marks One-Year Anniversary of 
Near-Record Flood while Monitoring Region?s Dry Conditions.  Internet Site 
Press Release:  <http://static.lcra.org/newsarchive/1998/06/flooddry.htm> 
Maidment, D. R. 2002.  Arc Hydro ? GIS for Water Resources. ESRI Press.  Redlands, 
California.  
McKinney, D. and Cai Ximing. 2002. Linking GIS and Water Resources Models: an 
Object-Oriented Method. Environmental Modeling and Software, Vol. 17, pp. 
413-425. 
National Research Council.  2000.  Risk Analysis and Uncertainty in Flood Damage 
Reduction Studies.  National Academy Press, Washington, D.C.  
Noman, S., E.J. Nelson, A. Zundel.  2001.  Review of Austomated Floodplain Delineation 
from Digital Terrain Models.  Journal of Water Resources Planning and 
Management. Nov/Dec, Vol. 127, No. 6, pp. 394-402.  
Robayo O., T. Whiteaker, D. Maidment. 2004. Converting a NEXRAD Map To a 
Floodplain Map.  Submitted to AWRA Spring Specialty Conference. 
Schneider, K.  2002. ArcBASINS: A GIS Model for the BASINS Database.  CRWR 
Online Publication 02-5. <http://www.crwr.utexas.edu/online.shtml> 
 194
Stone, S. and D. Maidment. 2001. Geospatial Database and Preliminary Flood 
Hydrology Model For the Lower Colorado River Basin. CRWR Online 
Publication 01-4.  <http://www.crwr.utexas.edu/online.shtml> 
USGS, 2003.  National Hydrography Dataset. Internet Site: <http://nhd.usgs.gov/> 
 195
 196
Vita 
 
Daniel Redd Obenour, the son of James and Martha Obenour, was born in 
Oberlin, Ohio on February 7
th
, 1979.  Dan graduated with honors from Wellington High 
School in 1997, and received his B.S. in Civil Engineering from the University of Akron, 
Ohio in 2002.  Throughout his college years, Dan gained technical experience working 
for a civil engineering consulting firm in Akron, Ohio; and for the U.S. Public Health 
Service at various locations throughout the country.  He entered the University of Texas 
at Austin in the fall of 2002.  After graduation, Dan will ride a bicycle from Austin, 
Texas to Anchorage, Alaska to raise money and awareness for the fight against cancer.  
Once this journey is completed, he will begin his professional career at Freese and 
Nichols, Inc. in Austin, Texas. 
 
 
Permanent address: 646 Meadow Lane, Wellington, Ohio 44090 
This thesis was typed by the author.