Ling Bian, Hao Sun, Clayton Blodgett, Stephen Egbert, WeiPing Li, LiMei Ran, Antonis Koussis
This project presents results of an interface development that couples GIS (Arc/Info) and an advanced hydrologic model SWAT (Soil and Water Assessment Tool). The SWAT model is designed to predict water and sediment yields for large rural river basins; it has been applied to many major river basins in the United States with promising results. However, extracting spatial parameters and entering a great number of parameters as required by SWAT are tedious processes. The interface system developed in this project is to (1) streamline the GIS processes for preparing spatial parameters required by SWAT, (2) automate the link between Arc/Info and SWAT, and (3) provide a user-friendly data entry and editing environment for the SWAT model. Because both Arc/Info and SWAT are mature and complex systems, the interface, therefore, includes add-on external graphical user interfaces and an object-oriented internal database to couple the two systems. The external graphical user interfaces facilitate spatial parameter extraction and data entry. The object-oriented database is well suited for linking the two systems. Hydrologic components were treated as different classes of objects, and the associations among them were coded to identify internal inconsistency, adding intelligence to data entry and editing.
Presently, the major impediment to progress in hydrologic modeling is not the inability to simulate physical processes mathematically, or to solve the resulting equations, but the inability to explicitly consider the spatial variation of model parameters (Maidment 1993). This task has always been one of the most time consuming, and therefore costly, components of hydrologic modeling. Spatially distributed data and the ability to manipulate such data are essential for detailed hydrologic modeling. In the 90s, hydrologic modeling concentrates on developing model "front ends" (pre-processing of input data to prepare parameters for physically-based models) and "back ends" (post-processing of results visually, statistically, and numerically).
GIS offers precisely the capabilities to account for the spatial variability of hydrologic processes. Although hydrologic parameters can be generated within GIS, the procedures are not sufficiently streamlined to be handled by non-GIS specialists. In many cases, the linkage between GIS and hydrologic models still remains a manual operation. These problems have become a major hurdle in the current effort to enhance the spatial capabilities of hydrologic modeling using GIS. Currently, many GIS data appropriate for water resources management are underutilized due to the absence of a bridge between the raw data and end users.
The need for integrating GIS and hydrology is well understood; the link itself, however, is weak at the operational level and is incompatible with the demands of hydrologic modeling. The primary objective of this study is to develop an interface system to integrate Arc/Info, a widely used comprehensive GIS software package, and SWAT (Soil and Water Assessment Tool, Arnold et al. 1993), a hydrologic model of advanced capabilities. The specific tasks are to provide the following capabilities: (1) to streamline GIS processes tailored toward hydrologic modeling needs; (2) to automate data communication between GIS and the hydrologic model; and (3) to provide a user-friendly data entry and editing environment for the hydrologic model.
The hydrologic model, SWAT, is a semi-empirical and semi-physical model. It has been used as a practical model to predict the effect of agricultural management decisions on water and sediment yields for large ungauged rural watersheds. Moreover, SWAT is an advanced lumped model or a semi-distributed model because it allows a watershed to be divided into hundreds of areal units, either by polygon sub-watersheds or regular grids. This semi-distributed characteristic is well suited for integration with GIS.
SWAT consists of major water budget components such as weather, surface runoff, return flow, percolation, evapotranspiration, transmission losses, pond and reservoir storage, crop growth, irrigation water transfer, groundwater flow, and channel routing. The model runs on a daily time step for short or long term predictions and operates in a semi-distributed manner to account for spatial differences in soils, land use, crops, topography, channel morphology, and weather conditions. Using GIS data, SWAT has been applied to many major river systems in the United States with promising results (Koussis et al. 1994, Srinivasan et al. 1993). The SWAT model has become increasingly popular in recent years.
As an advanced lumped model, SWAT accounts for spatial variability at the expense of data input. SWAT runs as a batch process; a large number of parameter files must be prepared prior to model execution. At the basin level, SWAT can take more than ten separate input files concerning agricultural management, water bodies, basin configuration, and weather information. At the subbasin level, SWAT can use up to nine input files containing detailed information for subbasin characteristics, surface and ground water bodies, channel routing, soils, weather, and agricultural practices. Using SWAT for a ten-subbasin watershed, a user may have to prepare nearly one hundred input files, with each containing ten to thirty parameters. SWAT provides a rather primitive user interface to facilitate data entry and editing and operates only in the DOS environment. All input files are fixed formatted and must be prepared separately. A more integrated, advanced user interface would significantly enhance the capability and usability of SWAT.
A range of approaches has been proposed and implemented for integrating GIS and environmental models (Abel et al. 1994, Maidment 1993, Chou and Ding 1992, Nyerges 1992). Abel et al. (1994) summarized three major integration architectures. A simple two-component architecture allows for one-way data transfer between two independent systems (e.g., a GIS and an environmental model). It promises low cost of implementation but low usability as well. An "embedded" two-component architecture extends capabilities of a master component by using functions of an embedded agent component. This is a more integrated approach, with the usability and costs depending on the capabilities of the master component. A many-component architecture consists two or more master components that share common agent components such as a database management system and/or an end-user interface. This option provides a single external schema for the integrated system yet retains the independence of each master component. The costs of this architecture tend to be high but it is desirable when the component systems are complex.
The two systems being integrated, Arc/Info and SWAT, are mature and complex, each with its own data model and conceptual and external schema for handling database and user interface tasks. In a simple two-component architecture, streamlined GIS procedures are possible and GIS data can be transferred to SWAT; however, it does not alleviate the burden of processing the large number of individual input files. A second scenario, the "embedded" architecture, is virtually impractical in this case. Implementing functions of one of the systems into the framework of the other would involve substantial modifications for one or both systems. This is costly given the complexity of both Arc/Info and SWAT. On this premise, the many-component architecture is adopted for this study. The two systems, Arc/Info and SWAT, are dealt with as two independent master components in the integration system. The conceptual design of the integration system includes an add-on external user interface and a shared internal database to couple the two systems (Figure 1). Supporting hydrologic modeling is the primary function of the interface system; thus the design intends to accommodate the requirements of the SWAT modeling with GIS playing a supporting role.
The integration begins with the external user interface, where the end-user initiates a new database or activates an existing one. AMLs (Arc Macro Language) are activated via the interface to prepare input parameters for SWAT in the Arc/Info environment. The data transition from GIS to the SWAT model is automated through the internal data base shared by both the GIS and the hydrologic model. User-friendly data entry and editing is part of the functionality of the external graphic user interface (GUI), where users can interactively enter and modify model input files and parameters, including non-spatial parameters. The internal database stores the input data and transfers the data into a SWAT compatible format. As the last step, the execution of SWAT is activated through the external user interface. The following sections describe major functions of the AMLs, the GUI, and the internal database.
The primary function of the AMLs is to streamline GIS processes in order to extract spatial input parameters for SWAT. The AMLs are written in such a way that users with minimal GIS experience can easily operate the interface.
The AMLs use source GIS data that are commonly available. The base data sets include streams, hydrologic code unit maps, digital elevation models (DEM), hyposography maps, temperature, precipitation, soils, and administrative boundaries. All the data involved can be obtained from public domain sources such as US Geologic Survey (USGS), Natural Resource Conservation Service (NRCS), and National Climate Data Center (NCDC).
A majority of the spatially explicit parameters required by SWAT are included in six input files: Basin, Subbasin, Precipitation, Temperature, Soils, and Routing. The extraction process is thus organized in six corresponding routines to ensure compatibility with the SWAT file structure that is explicit to end users; this is also compatible with object definitions in the internal database, thus making data passing efficient. During the operation, the user has the option to process the entire basin or selected subbasins. In addition, the user can terminate, proceed, or at times skip a routine as the program allows. An error checking mechanism warns the user whenever proper procedures are violated, while a "help" function provides detailed instructions for operation.
The Basin, Subbasin, and Routing routines extract spatial information such as basin or subbasin area, basin terrain, and channel morphology. Most parameter extractions are automated processes, while those spatial parameters that require users' familiarity with the basin are secured through an interactive mode. For example, users identify interactively on screen the longest channel in a subbasin by selecting a series of stream segments. An error checking mechanism validates the continuity of the selected channel to eliminate possible errors induced during manual selection. The interactive procedure engages users to the spatial data and avoids the complex, lengthy process of automated search.
Terrain parameters, i.e. average slope length and average slope steepness, are calculated using a method described by Williams and Berndt (1976):
l = 0.5 * DA/LCH (1); S = 0.25 * Z (LC25 + LC50 + LC75) / DA (2)
where l is the average slope length; DA is the area of the subbasin; LCH is the total length of channels in the subbasin; S is the average slope steepness; Z is the elevation range in the subbasin; and LC25, LC50, and LC75 are contour lines generated at 25, 50, and 75 percent of the total elevation range in each subbasin, respectively.
Using GIS functions, the temperature and precipitation data at point locations are interpolated into Thiesson polygons. The values of the parameters are averaged over all polygons in a subbasin and weighted by their areal contributions to the subbasin. Because of the spatial scale SWAT is designed for large rural river basins, the State Soils Geographic (STATSGO) database is used as the base data. Soil parameters are weighted by both soil horizon depths and areal percentages of soil series in a soil association. Users have the option to keep or discard any soil series.
The GUI is a Windows-based tool that communicates with the internal database for data entry, editing, query, data validation, and launching the SWAT program. It is designed to overcome many of the most significant hurdles faced by SWAT users, particularly the lack of a user-friendly interface and the tedious input files processing. The development environment for the GUI is Visual Basic Professional operating under Microsoft Windows. Visual Basic is a Rapid Application Development (RAD) tool for interactively creating Windows programs. The GUI, in combination with the internal database, interfaces with Arc/Info and PC SWAT.
The GUI follows the standard Windows single-document interface (SDI) format common to many Windows programs and employs standard Windows controls (menus, frames, command buttons, and radio buttons, etc.). A pull-down menu is used as the basic form for the interface. It best accommodates the existing structure of SWAT input files and parameters. In addition, it provides the user with a familiar graphical user environment that requires minimal training. The operational functions of the interface are organized in a hierarchical structure, where menu items are the top level controls which evoke client windows or dialogue boxes for interactive data processing.
At the top menu level, the GUI allows the user to initiate a new SWAT project or open an existing one for modification. In either case, the user is presented with standard Windows dialogues to guide the process. The interface also provides the user an option to import spatial information extracted from the Arc/Info environment or enter the parameters directly. Data entry, editing, and query are the main functions of the GUI. Once these are complete, the user may save the data to the internal database and execute the SWAT model.
Data entry is divided into two main groups: basin and subbasin. Since many of the forms are similar between the two groups of menus, they are color-coded to provide a visual cue for the user. Both the master basin and the master subbasin forms consist of an array of command buttons, one for each input file type. By selecting a specific input file type, the user can access a data entry form that contains a number of text entry boxes for individual parameters. Alongside each parameter box is the name of the parameter and a brief description of the parameter. Each box is keyed to the data compilation sheets that accompany the SWAT documentation. The user may switch at any time across subbasins and basin, or change between basin (or subbasin), file type, or parameters.
For many SWAT parameters, the user needs to estimate the values based on the hydrologic conditions of the basin. SWAT documentation provides reference tables to assist the user in choosing appropriate values. These are implemented in the GUI as dynamic lookup tables that are accessible by selecting the text entry box for the parameter of interest. The values displayed in the lookup tables can be easily adopted and saved to the internal database. Parameters that have multiple values in a time series (i.e. one value for each month of the year) or multiple components (e.g., a list of pesticides) are entered into a two dimensional spreadsheet-like grid. This allows the user to examine all the values for the parameter at once. Similar to the individual grids, a Subbasin Summary function displays all subbasin data in multiple tables, with each table containing all parameters of a specific input file type across all subbasins. This helps the user to evaluate and compare the parameter values over the entire basin. The remaining file types are organized as separate tables behind the one currently being displayed; the user can easily switch file types by selecting file labels.
The internal database is developed to automate data communication between Arc/Info and SWAT. Through the external graphical user interface, the internal database imports spatial information extracted in Arc/Info and supports all database functions such as data entry, editing, and query. It interfaces with SWAT by transferring input data into required SWAT input files. The database is developed in an object-oriented approach using C++.
Development of the database requires an object-oriented requirement analysis. Typically, the requirement analysis consists of three basic components: an object model, a dynamic model, and a functional model. In the particular case of this database, the object model is the primary concern, while the dynamic model and the functional model are more relevant to hydrologic model development.
The basis of the object model is objects and their relationships, which can be represented by classification, inheritance, association, and aggregation (Khoshafian 1993, Kainz and Shahriari 1993, Milne, et al. 1993, Egenhofer and Frank 1992, Oosterom and Bos 1989). Figure 2 presents an overview of the conceptual design of the database. Each rectangle represents an object while all linear symbols depict how the objects are organized in the database. The arrows indicate the classification hierarchy, in which the superclasses are at the points while the contributing subclasses are at the tails. The straight lines depict association or aggregation relationships among objects. Lines with nodes on both ends indicate associations; objects at both ends are members of an association set. Aggregation is represented by lines with a node and a diamond at either end; objects at the node sides are components of the composite objects adjacent to the diamonds.
There are two main object types, GEOMETRY and MODEL. The spatial objects and parameter objects are dealt with as two distinct objects types, instead of treating parameters as properties of the spatial objects. This is well suited to the design principle of the interface because hydrologic modeling is the primary concern. The design of the object model should accommodate the requirement of the hydrologic model.
The GEOMETRY object type is used primarily to handle spatial information derived from Arc/Info. The actual calculation of areal weighting for spatial parameters of soil and weather data is carried out by the internal database, while Arc/Info only provides intermediate data such as the area of individual Thiessen polygons and areas of subbasins. This object type includes various geometric objects such as point, line, and area features; each of these is in turn a superclass of more specialized spatial objects, which are subclasses of their superclasses. All geometric objects share common operations such as computing percentage and length or area. The point and linear objects are related to linear and areal objects, respectively, in a multiple-component aggregation relationship (Figure 2). Specifically, point objects are components of its composite object: linear object, and the linear objects are components of the areal object.
The MODEL objects are organized as a hierarchy of hydrologic parameters. The objects are so defined that they closely correspond to the real world entities. In the mean time, the definition is closely related but not restricted to the file structure of SWAT, in which many input files correspond to real world entities such as soils, water bodies, weather, and agricultural practices. As part of the model, the GEOMETRY objects are aggregated into the MODEL object.
In the database, individual parameters are treated as properties of the primitive objects, which are the most specialized objects and no longer decomposable. For example, all soils parameters are the properties of primitive object SOIL. The object SOIL inherits all properties and operations of MODEL (e.g., maximum and minimum value checking) in the database and have parameters and operations unique to soils. A particular soil series is an instance of SOIL. As part of a subbasin, most the subclasses of the MODEL object are aggregated to SUBBASIN object, which in turn was aggregated to the BASIN object.
The associations among the subclasses of the MODEL object are implemented according to hydrologic principles that are actually implemented in the SWAT model. Typically, hydrology, weather, soils, and agricultural management are related to each other in simulating hydrologic processes. Implementing such associations validates internally input parameter values. For example, water stress factor is computed by considering evapotranspiration, which is in turn calculated using temperature (Figure 3). Water stress factor can also be entered independently, whose value can be evaluated according to the association and temperature input. This is a more advanced validation mechanism than those available in many other database environments, for example, the relational database. In addition, this validation mechanism can be easily implemented in an object-oriented environment.
The database is implemented in Dynamic Linked Library (DLL) format. An Application Programming Interface (API) is developed to communicate between the GUI and the internal database. Through the API, all operations received at the user interface can be implemented in the database. Once all the data entry, editing, and query are completed, the user activates a save function from the GUI; the internal database updates the input data and transfers them into SWAT ready files.
The interface system described above will allow hydrologists to fully exploit the capabilities of SWAT and GIS systems. With this interface, large amount of GIS data will become readily usable for the hydrologic modeling community. It is also hoped that this research will contribute to the better understanding of integrating hydrologic models and GIS, and ultimately contribute to effective water resources management.
Abel, D.J., Kilby, P.J. and Davis, J.R. (1994) The systems integration problem. International Journal of Geographical Information Systems, 8(1):1-12.
Arnold, J.G., Allen, P.M., and Bernhardt, G. (1993) A comprehensive surface groundwater flow model. Journal of Hydrology, 142: 47-69.
Chou, H.-C., and Ding, Y. (1992) Methodology of integrating spatial analysis/modeling and GIS. Proceedings, 5th International Symposium on Spatial Data handling, Charleston, South Carolina, 514-523.
Egenhofer, M. J., and Frank, A.U. (1992) Object-oriented modeling for GIS. URISA Journal 4(2):3-19.
Kainz, W., and Shahriari, N. (1993) Object-oriented tools for designing topographic databases. Proceedings, GIS/LIS '93, 341-350.
Khoshafian, S. (1993) Object Oriented Databases. John Wiley, New York.
Koussis, A. D., Sophocleous, M., Bian, L., and Zou, S. (1994) Lower republican River Basin: Stream-Aquifer Study, Technical Report, University of Kansas, USA.
Maidment, D. R. (1993) GIS and hydrologic modeling. in Environmental Modeling with GIS, Goodchild, M. F., B. O. Parks, and L. T. Steyaert (ed.) Oxford University Press, New York.
Milne, P., Milton, S., and Smith, J.L. (1993) Geographic object-oriented databases - a case study. International Journal of Geographical Information Systems, 7(1):39-55.
Nyerges, T. (1993) Understanding the scope of GIS: its relationship to environmental modeling. in Environmental Modeling with GIS, Goodchild, M. F., B. O. Parks, and L. T. Steyaert (ed.) Oxford University Press, New York.
Oosterom, P. V., and Bos, J.V.D. (1989) An object-oriented approach to the design of geographic information systems. Computer and Graphics, 13(4):409-418.
Srinivasan, R., Arnold, J., Rosenthal, W., and Muttiah, R.S. (1993) Hydrologic modeling of Texas Gulf Basin using GIS. Proceedings, Second International Conference on Integrating GIS and Environmental Modeling, Breckenridge, Colorado.
Williams, J. R., and Berndt, H.D. (1976) Determining the universal soil loss equation's length-slope factor for watershed. In Soil Erosion: Prediction and Control, the proceedings of a National Conference on soil Erosion, 217-225.