8

Hydrologic Modeling
Systematic data storage of geospatial and time series in the ArcGIS Hydro data model allows different levels of integration. Different levels of integration that can be achieved within the ArcGIS Hydro data model are explained in this chapter with examples. This chapter includes Role of the ArcGIS Hydro data model in the context of Hydrologic Modeling Basics for integration of hydrologic models with ArcGIS Hydro data model Levels of integration Description for each type of integration

Introduction Water Resource models perform one kind of function for one kind of environment, for example, hydrologic modeling of watershed, hydraulic modeling of rivers, water quality modeling of lakes and so on. Since the ArcGIS Hydro data model, referred to as Arc Hydro hereafter, describes all of these features, one final goal of the Arc Hydro is to provide a mechanism for integrating hydrologic models with a common base of geospatial and temporal data. In many areas of scientific and engineering research, there is a fundamental need to integrate GIS software with users' own models and programs. GIS provides numerous tools to support hydrologic modeling. They can be broadly classified as data management (manipulation, preparation, extraction, etc.), visualization, and interface development tools. These tools can be used two-ways, that is, GIS can provide its services to hydrologic models, but also, hydrologic models can provide their services to GIS. Difficulty arises from the different types of hydrologic models, methods for data input, user interface, and communication of the hydrologic models with the GIS and also within themselves to perform different hydrologic analysis (Pinde Fu. et al, 2000). These difficulties very often lead to inconveniences and inefficiency defeating the whole purpose of integration of GIS with hydrologic models. Keeping the above facts in mind, it is really difficult to define a procedure or to have a tool in the Arc Hydro that can be used to run different types of hydrologic models.
Role of the Arc Hydro in the context of Hydrologic Modeling

Hydrologic models try to simulate the watershed behavior by solving the equations that govern the physical processes occurring within the watershed. Therefore hydrologic models are usually used to simulate the watershed response for a given input. The hydrologic models take time series data and produce another time series as output. For example, time series of rainfall data is used in rainfall runoff models to predict the discharge at the watershed outlet. On the other hand Arc Hydro describes the hydrologic features that are available in a watershed on a spatial scale and also provides a link between these features by establishing a relationship between

Hydrologic Modeling 1

different features. Thus Arc Hydro and hydrologic model represent two different aspects namely description and prediction respectively and it is difficult to have these two functionalities in one environment. Traditionally GIS has been used as a support tool for hydrologic modeling. Many GIS capabilities can be used at different stages of development of a hydrologic application. These capabilities can be broadly classified as: Data management - In this role, GIS is used for basic spatial data management tasks (data storage, manipulation, preparation, extraction, etc.) and spatial data processing (overlays, buffering, etc.). Parameter Extraction - Obtaining characteristic properties of catchments and river reaches for hydrologic modeling. Visualization - GIS graphical capabilities are used to display the data either before the hydrologic analysis is performed to verify the basic information, or after the analysis to evaluate the results(Djokic et al, 1995). For example, flood plain mapping shows the extent of area damaged by floods and is very easy with GIS to visualize. Surface Modeling - This involves delineation of watersheds and channel shape representation. Interface Development - Hydrologic models often have antiquated user interfaces that can be replaced by user friendly interfaces developed using GIS tools.

Although GIS performs all the above capabilities, it is not configured for complete interaction with complex hydrologic models. These models often come with their own visualization (or, more frequently, no visualization). Data import / export from hydrologic models is difficult and hydrologists very often end up with a dilemma of using a Human Interface rather than using a GIS interface. The systematic data storage in the Arc Hydro offers different ways of using GIS data for hydrologic modeling. The time series data in Arc Hydro is unique for each layer and feature type. All the data in the Arc Hydro is stored in a geodatabase, which is basically a MS Access table. With the evolution of object oriented programming languages such as Visual Basic it has become very easy to exchange data between the geodatabase and other applications such as spreadsheets, ASCII formats etc. The time series data in Arc Hydro provides an easy and secure way of data exchange between GIS and hydrologic models. The time series data can be used to run any type of hydrologic models provided the level of integration between the hydrologic model and the GIS is known. Basics for Integration of hydrologic models with Arc Hydro
COM and ArcGIS

The Component Object Model (COM) is a software architecture developed by Microsoft that allows applications to be built from separate software components. COM is the underlying architecture that forms the foundation for higher-level software services, like those provided by object linking and embedding (OLE). OLE services span various aspects of commonly needed system functionality, including compound documents, custom controls, inter application scripting, data transfer, and other software interactions (Microsoft Technologies). COM enables

2 ArcGIS Hydro Data Model

programmers to develop objects that can be accessed by any COM-compliant application. Both OLE and ActiveX are based on COM. Components developed using Microsofts COM provide a way by which two objects in different object spaces or networks, could talk together by calling each others methods. This excellent technology forces the operating system to see applications as objects. COM forces the operating system to act as a central registry for objects. The operating system takes the responsibility of creating objects when they are required, deleting them when they are not, and handling communications between them, be it in the same or different processes or machines. ArcObjects is the development platform for the ArcGIS family of applications such as ArcMap, ArcCatalog, and ArcScene. The ArcObjects software components expose the full range of functionality available in ArcInfo and ArcView to software developers. ArcObjects is a framework that lets one to create domain-specific components from other components. The ArcObjects components collaborate to serve every data management and map presentation function common to most GIS applications. Thus ArcObjects provides an infrastructure for application customization to meet users specific needs (ESRI, 2001). ArcObjects is built using Microsofts COM technology. Therefore, it is possible to extend ArcObjects by writing COM components using any COM-compliant development language. One can extend every part of the ArcObjects architecture in exactly the same way as ESRI developers do. The most common way that developers can customize the ArcGIS Desktop applications is through Visual Basic for Applications (VBA), which is embedded within ArcCatalog and ArcMap. Through VBA, one can control the application framework that already exists in ArcMap and ArcCatalog for general data management and map presentation tasks and extend ArcGIS with users own custom commands, tools, menus, and modules. Thus using VBA inside ArcGIS Desktop, user can achieve the majority of his/her customization needs with relatively little development effort (ESRI, 2001).
Visual Basic for Applications (VBA)

Visual Basic for Applications is very similar to the stand-alone Visual Basic (VB) programming language. VBA is built from the same source code base as VB providing with a high level of compatibility between the two. VBA also uses the same high-performance language engine and programmer productivity tools enjoyed by millions of Visual Basic developers. VB is a standalone programming language whereas VBA is designed to work with a particular application. Thus VBA is different for different applications. VBA is the macro language for all of Microsoft's major applications. It is the premier development technology for rapidly customizing applications and integrating them with existing data and systems. VBA offers a sophisticated set of programming tools that developers can use to harness the power of packaged and corporate applications. By using VBA to work with one or more of the Office application object models, one can easily modify the functionality of an Office application or enable two or more Office applications to work together to accomplish tasks that no application can complete by itself. With VBA, the user controls only a small portion of the operating system, the part that is available through the functions and objects exposed directly to VBA. Microsoft VBA is built upon COM, Microsofts architecture for software components. In order to customize any application using VBA, the applications architecture must be based on COM. Since ArcObjects used in ArcGIS are based on COM, it has become very easy to customize ArcGIS using any COM compatible programming language. Most developers use VBA to create a COM component that works with ArcMap or ArcCatalog. Since the ESRI applications are COM clients, their architecture supports the use of software components that adhere to the COM

Hydrologic Modeling 3

specification and one can build components with different languages, including Visual Basic and Visual C++. These components can then be added to the applications very easily. More details on how the components can be created and added to ArcGIS can be obtained online at http://arconline.esri.com/arcobjectsonline/.
Object Libraries in ArcGIS

An object library is a file with the .olb extension (some libraries also have .tlb, .exe and .dll extensions) that provides information to Automation controllers (like Visual Basic) about available objects (ESRI, 2001 ). The important ESRI libraries that one needs to load in a visual basic project while designing a visual basic interface are as follows: ESRI Object Library (esriCore.olb)

This library is used for tasks that relate to the Application Framework, ArcCatalog, ArcMap, Dynamic Segmentation, Editing, Geodatabase, Geometry, Importing from ArcView 3.x, Licensing, Metadata, Network, and Spatial Reference. ESRI ArcMap Object Library (esriMx.olb)

This library loads automatically when working with VBA in ArcMap. ESRI ArcCatalog Object Library (esriGx.olb)

This library loads automatically when working with VBA in ArcCatalog. Levels Of Integration The integration of the Arc Hydro and hydrologic models can come in many forms. In the simplest case the Arc Hydro and the hydrologic model just exchange files. The hydrologic model may read some of its input data from geodatabase and produce some of its output in a format that allows processing and display the results within the GIS. This is a common approach, since it requires little if any software modifications. Only the file formats and the corresponding input and output routines, usually of the hydrologic model, have to be adapted. A solution based on files shared between two separate applications may be cumbersome and error prone because of errors in formatting the data transfer files between the GIS and the hydrologic model. In order to have a seamless hydrologic application, a deeper integration is needed. Deeper integration provides a common interface and transparent file or information sharing and transfer between the respective components. One possible way is the use of a higher level application language or application generators built into the GIS. An alternative is the use of tool kits that provide both GIS functionality as well as interface components for simulation models (Fedra, 1994). Based on the deeper integration approach, two broad levels of integration can be envisaged 1. Embedded type 2. Linked type The main difference between the embedded type and linked type of integration is the location of the hydrologic model and its database (Djokic et al, 1995). In the linked type the model is external to the GIS, which contains the data, while for the embedded type, both the database and model are within the GIS environment. The embedded type of integration involves running hydrologic models within the Arc Hydro by directly using the geodatabase and it does not
4 ArcGIS Hydro Data Model

involve any data transfer between the two applications. Thus the hydrologic model becomes one of the analytical functions of the Arc Hydro. This type of integration can be achieved in number of different ways. One way of achieving this is to write a code in Visual Basic using the Arc Object library and the analysis can then be run from the ArcGIS directly. These analyses can be run either as an ArcGIS macro or they can be evoked in any other form defined by the user, for example from a menu bar. Another form of embedded type of integration is the use of dynamic link library (DLL). The DLL contains a list of subroutines that perform a number of hydrologic applications. The user evokes the necessary subroutine within the DLL by passing the required arguments to the DLL. The results can directly be viewed in graphical or tabular form or can be stored in the geodatabase. The linked type of integration involves running hydrologic models by connecting the hydrologic models in some form with the geodatabase. In this case the linking involves an interface between the geodatabase and the hydrologic model. The interface consists of three parts. The first step in running the model is to transfer and convert the time series data needed to run the model into an appropriate format eg. ASCII. Once the input data for the hydrologic model is in the required form, the interface then invokes the hydrologic model, and the model produces an output file. The output file can be in any form, ASCII or spreadsheet etc. The last step is to transfer the output from the hydrologic model to the Arc Hydro in time series format and display the results, mostly in graphical form. The hydrologic model can be any independent complex model or it could be a simple spreadsheet program or a Fortran code. The integration could be with a single hydrologic model or with a series of models that run in a sequential manner depending on the users choice.
Embedded Type of Integration
Using a DLL

A DLL is short for Dynamic Link Library. In programming, a library is a collection of precompiled routines that a program can use. The routines, sometimes called modules, are stored in object format. Libraries are particularly useful for storing frequently used routines because you do not need to explicitly link them to every program that uses them. The program automatically looks in libraries for routines that it does not find elsewhere. In MS-Windows environments, library files have a .DLL extension. Thus a DLL is a library of executable functions or modules that can be used by other programs. Typically, a DLL provides one or more particular functions and a program accesses these functions by creating either a static or a dynamic link to the DLL. A static link remains constant during program execution while a dynamic link is created by the program as needed. DLLs can also contain just data. For example, DLLs of the ArcView GRIDIO library allow users to develop GIS capabilities within their models (Pinde Fu et al, 2000). ArcView GRIDIO is a grid data set input/output library that allows users to read and write ESRI grid data sets directly. Similarly, users can build their models in DLL formats for use within GIS software. Information can be passed back and forth as parameters. For example, one can write a DLL which calculates a water surface profile. In this case the DLL takes the water elevation (stage) data at the monitoring stations of a river reach as the input from GIS and gives back the water surface profile for the entire river reach which can then be displayed in GIS. Application integration through DLLs is tighter and faster than running an external executable program. This method is desirable, but involves considerable programming effort. In the context of Arc Hydro, DLL functionality can be used to do simple as well as complicated hydrologic calculations by designing an interface that allows the user to perform a number of

Hydrologic Modeling 5

hydrologic calculations. This interface allows the user to invoke a particular subroutine within the DLL by passing the exact type and number of arguments to the DLL. Currently the possibility of using the LibHydro DLL designed by Hydrologic Engineering Center, US Army Corp of Engineers (HEC) for use in the Arc Hydro is being explored and a brief introduction is now presented.
LibHydro DLL

LibHydro.DLL is a library developed by HEC containing subroutines that perform the hydrologic calculations contained in the classic HEC-1 watershed simulation model. The subroutines are written in Fortran and most of them conform to the Fortran 77 standard, with selected extensions, which conform to Fortran 90 Standard. The present version of LibHydro (HEC, December 1995) contains routines in the following categories Precipitation Loss rates Unit hydrographs Base flow Routing Utility Error handling SI/English unit conversions

The following paragraph demonstrates the use of LibHydro in the Arc Hydro to route the flow using the Muskingum Method which is a hydrograph routing method that is used for channel flow routing. The input data required by Muskingum method is the inflow hydrograph at the upstream end of a river reach, Muskingum parameters namely K and X and the number of reaches. In the present example only one reach is used and the value of K and X are specified as 1.0 and 0.5 respectively. The illustration shows the flow chart for using LibHydro in Arc Hydro. The most important thing in the entire set up is the design of the interface that interacts with the user, geodatabase and DLL. Once prompted, the interface asks the user to select the routine they intend to use from the DLL, specify the time-series class of the active feature that contains the required time series data, state the length of record to be used for routing and declare the values of the parameters. The declaration statement that will be written in Visual Basic Module and the calling sequence for the LibHydro in Visual Basic is shown below:

6 ArcGIS Hydro Data Model

Declare Sub ROUTEMUSKINGUM Lib "LibHydro.dll" (timeInterval As Long, _ muskingumK As Double, muskingumX As Double,_ numberReaches As Long, initialSubreachOutflow As Double, _ finalSubreachOutflow As Double, numberFlows As Long, _ inflow As Double, outflow As Double, errorCode As Long, _ ByVal errorMessage As String, ByVal L_errorMessage As Long)

ROUTEMUSKINGUM timeInterval, muskingumK, muskingumX, numberReaches, _ initialSubreachOutflow(1), finalSubreachOutflow(1), numberFlows, _ inflow(1), outflow(1), errorCode, errorMessage, Len(errorMessage)

The declare statement refers to the subroutine ROUTEMUSKINGUM in the library named LibHydro.dll and then it specifies the arguments that are needed to be exchanged between the the main program and the DLL. In this case the parameters being exchanged are Muskingum K and Muskingum X, which are the basic parameters of the model. NumberReaches specifies the number of reaches that are considered for routing the flow. InitialSubreachOutflow and finalSubreachOutflow state the amount of flow that is entering initially (at t=0) and leaving the reach respectively. NumberFlows represents the number of time series data values. Inflow and outflow are the inflow and outflow array. The size of array is equal to the NumberFlows. The inflow array is passed from the program to the DLL and the DLL does the computations and exports the outflow array to the main program. The errorCode, errorMessage and the L_errorMessage are the arguments that are used to display error message if any error occurs during the execution of the program. The calling statement just calls the subroutine ROUTEMUSKINGUM by specifying the arguments explained in the Declare statement. It is important to note that the number of arguments in the declare statement and the calling statement should be same.

Hydrologic Modeling 7

Use of LibHydro in Arc Hydro

Once the user specifies the necessary parameters and upon clicking one command button, the interface passes all the parameters and the inflow hydrograph to the DLL and receives back the outflow hydrograph, which can be displayed in the GIS environment. The following figure shows the inflow data used in this illustration and the outflow obtained from the DLL.

Time (Hrs) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Inflow Outflow (cum/s) (cum/s) 2000.00 2000.00 2073.87 2014.77 2293.66 2106.01 2653.96 2328.19 3145.90 2687.19 3757.36 3176.45 4473.29 3784.36 5276.06 4496.06 6145.90 5294.03 7061.39 6158.62 8000.00 7068.56 8938.61 8001.43 9854.10 8934.27 10723.94 9844.10 11526.71 10708.53

Time (Hrs) 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Inflow (cum/s) 12242.64 12854.10 13346.04 13706.34 13926.13 14000.00 13926.13 13706.34 13346.04 12854.10 12242.64 11526.71 10723.94 9854.10 8938.61

Outflow (cum/s) 11506.26 12217.66 12825.20 13313.93 13671.82 13890.04 13963.23 13889.59 13670.93 13312.63 12823.51 12215.63 11503.94 10705.97 9841.38

Time (Hrs) 31 32 33 34 35 36 37 38 39 40 41

Inflow (cum/s) 8000.00 7061.39 6145.90 5276.06 4473.29 3757.36 3145.90 2653.96 2293.66 2073.87 2000.00

Outflow (cum/s) 8931.44 7998.57 7065.73 6155.90 5291.47 4493.74 3782.34 3174.80 2686.07 2328.18 2109.96

8 ArcGIS Hydro Data Model

Muskingum Method flow routing using libHydro DLL

Linked Type of Integration

This is the easiest and most commonly used approach to integrate two sets of programs that use common data files. In this type of linking the Arc Hydro and the hydrologic model share an interface that allows the interchange of data back and forth between the GIS and the external model. This type of integration allows both (Arc Hydro and Hydrologic model) applications to act as a data provider as well as a data user. For example, a rainfall runoff model is a data user when it uses the rainfall data as its input from the Arc Hydro, but is a data provider when it gives back the simulated discharge back to the Arc Hydro. The linked type of integration can be achieved in the following three ways Linking an external hydrologic model with the Arc Hydro Linking the Arc Hydro with external applications Linking a set of external models with the Arc Hydro

Each of these methods is explained briefly in the following paragraphs.

Linking an external hydrologic model with the Arc Hydro

In this approach, the Arc Hydro and the hydrologic model are separate components and there is no direct interaction between them. The Arc Hydro provides the time series data in the standard format with its fields as FeatureID, TSType, TSDateTime and TSValue. The interface converts this data to a specific format that is required by the hydrologic model. The next step is to run the hydrologic model, convert the output to the time series format, and store it in the geodatabase as a different time series class. This approach requires almost no software modification but it requires programming of an interface, which can be simple or complicated depending on the model that is being used in the integration. The flow chart for this kind of integration is shown in the figure below

Hydrologic Modeling 9

Linking an external hydrologic model with the Arc Hydro

As mentioned earlier, the most important part in this type of integration is the design of interface that interacts with the Arc Hydro and the hydrologic model. Most of the hydrologic models (that work independent of GIS) require input data in the form of text files. Therefore the most important part of the interface is the conversion of time series data into text files with appropriate format. Another important factor in the interface design is the transfer of input parameters needed to run the hydrologic model. Most models have their own interface for parameter input, so once the model is called from the interface, the next step for the user is to input these parameters and run the hydrologic model. However, if the hydrologic model does not have its own interface for the input of parameters then the Arc Hydro interface should have the necessary components that will take all the parameters and transfer them into a text file or any other appropriate format that can be read by the hydrologic model. Once this is done, then the main part of calling the model from the Arc Hydro is easy and is demonstrated in the example below. After the model is run, the final step is to read the output and display it in graphical form in the Arc Hydro or the output can be stored as a time series table with an independent time series class, if it has to be used in further analysis. Calling of any executable program is very easy using the Arc Object library. This is done using the SHELL function. The syntax of this function is as follows:

10 ArcGIS Hydro Data Model

Shell(pathname[,windowstyle]) The Shell function syntax has these named arguments: Part Pathname Description Required; Variant (String). Name of the program to execute and any required arguments or command-line switches; may include directory or folder and drive. Optional. Variant (Integer) corresponding to the style of the window in which the program is to be run. If windowstyle is omitted, the program is started minimized with focus.

Windowstyle

Thus if we wish to run a hydrologic model which is an executable file (hydro.exe) then the Visual Basic code to run this program is as follows:
Dim RunHydro RunHydro = Shell("C:\Program Files\hydro.EXE", 1)

Specifying 1 as the second argument opens the application in normal size and gives it the focus i.e., the application window is set as active. This type of integration is very useful for running all kinds of models especially hydrologic models that operate within the DOS environment.
Linking the Arc Hydro with Excel

Sometimes the user may not be interested in running any hydrologic model but may be interested in doing some calculations that cannot be done using GIS functionality. For example, they may be interested in deriving the relationship between the discharge at two stations using regression analysis. In some special cases they may want to produce probability plots for flood frequency analysis or for low flow analysis. Under such circumstances, it is necessary to link the geodatabase to an external application that support these types of functionalities. MS Excel is an excellent example and using VBA it is very easy to link the time series data in the Arc Hydro with an Excel sheet. The following figure shows the flow chart for this type of linking

Hydrologic Modeling 11

Linking the Arc Hydro with Excel

This type of linking can be done in two different ways. In the first case, the interface can be designed using Arc Object library. In the second case, the interface can be designed using VBA and can be evoked from Arc Hydro. In the first case, which is shown in the illustration, the Excel spreadsheet is linked to Arc Hydro as an external application and the interface then transfers the data back and forth between the Arc Hydro and MS Excel. This type of linking offers some flexibility in terms of use of Excel functionality. Since Excel is linked as an external application, once the data is transferred from the geodatabase to Excel, the user has a choice of functions to be performed in Excel and a choice of working with the data in Excel itself. This type of linking is more favorable when more complicated calculations are needed to be performed in Excel, and if the user wants to use Excel to display the output. In the second case, illustrated below, where the interface is designed in VBA, the MS Excel sheet can be embedded as an object within the interface. In this case, the design of interface is complicated and involves substantial programming effort but is more efficient and rapid as compared to the first case as the interface is not interacting with two different applications. The interface is limited to perform only specific calculations that are designed within the interface. The output can either be stored within the geodatabase or only displayed within the interface.

12 ArcGIS Hydro Data Model

Embedding Excel within the interface

Linking a set of external models with the Arc Hydro Linking a set of external models involves the design of interface using VBA. In this case the interface interacts with three different environments namely, the Arc Hydro, a series of hydrologic models and an external database which contains the results of hydrologic models. The interface in this case not only interacts with these environments, but also controls the sequence of flow by keeping a track of series of hydrologic models that are connected and the external database. The external database is the table that stores the output of all the hydrologic models that are called from the interface. The operation of interface can be more clearly understood by referring to the following illustration.

Hydrologic Modeling 13

Linking a set of external models with the Arc Hydro

In the above figure, the rectangles with numbers within them represent the hydrologic/hydraulic models. For the illustration purpose only four models are included but there can be more or less models involved depending on users choice. Model 1 represents a rainfall - runoff model, model 2 represents a hydraulic model that calculates surface water profiles, model 3 is a flood delineating model that gives the extent of flood based on the water surface elevations, and model 4 is a decision making model that is useful for making decisions in planning the area around the waterbody. All the external models are connected to the geodatabase and also there is option of storing the output data to an external database which can be accessed through the interface. The working of the model is better explained when you look to the schematic network as shown in the figure below.

14 ArcGIS Hydro Data Model

Schematic network in Arc Hydro

The basic rule is that the model can only be applied at the junctions of the network. The sequence of the model is as follows: First when the interface is invoked it looks at the data available at the junctions, which are A and B in this case. If these junctions have only rainfall data available in the database then the operation starts from model one and proceeds subsequently to model two, three, and four. After running model one the output, which is discharge, is stored in the geodatabase and the control is passed on to the interface. The interface then looks into the geodatabase and after making sure that the discharge data is stored within the geodatabase, the control is passed on to model two. Model two uses this discharge data and calculates the water surface elevation at each specified cross sections between the two junctions. The output is then stored within the geodatabase and the control so passed on to the interface. The interface then looks for the water surface elevation data and if the data is present then it invokes model three and so on.

It is possible for the user to pass the control from the interface directly to model two or three or any other model depending on the data present. The interface by default works with model one first, and subsequently passes the control to the other models. This type of modeling is very difficult and extreme care has to be taken in the design of interface. Summary This chapter gives an overview of different methodologies that can be used to run the hydrologic or hydraulic models by using the Arc Hydro. The approaches namely the embedded and the linked type, are explained and examples are given wherever applicable. The use of LibHydro DLL presents a whole new world of hydrologic/ hydraulic tools that can be used with the Arc Hydro. Whereas, the linked type of integration gives an idea of running more complicated hydrologic model in more meaningful and seamless way without much modification to the original programs. Also it is also possible to link the geodatabase with Excel and use Excel functionalities without interfering with the original database. This makes the whole effort of mathematical operation on the geodatabase easier and more secure.

Hydrologic Modeling 15

However, it has to be noted that all these methodologies require considerable programming effort and design of the interface is extremely important. References: ArcObjects Developer Help. Environmental Systems Research Institute, Inc. April, 2001. Dean Djokic, Andrew Coates, and James E. Ball (1995). GIS As Integration Tool For Hydrologic Modeling: A Need For Generic Hydrologic Data Exchange Format. Proceedings of the ESRI User Conference, 1995. Dean Djokic, Andrew Coates, and James E. Ball (1995). Integration of GIS and Hydrological Models, Second National Forum on GIS in Geoscience, Canberra, Australia, AGSO Record 1995/46, 110-115. Dean Djokic, Andrew Coates, and James E. Ball (1996). Generic Data Exchange - Integrating Models And Data Providers. Third International Conference/Workshop on Integrating GIS and Environmental Modeling, Santa Fe, New Mexico, January 21-25, 1996. Fedra, K. (1994). GIS and environmental modeling. In: M.F. Goodchild, B.O. Parks and L.T. Steyaert [eds.] Environmental Modeling with GIS. 35-50, Oxford University Press. Fu, Pinde., P.M. Rich, and J. Wang ( 2000). Integration of GIS with user models. Proceedings of the Twentieth Annual ESRI User Conference. LibHydro Users Manual (1995). US Army Corp of Engineers, Hydrologic Engineering Center, CA.

16 ArcGIS Hydro Data Model