Dean Djokic, Andrew Coates, and James E. Ball
GIS provides numerous tools for hydrologic modeling. They can be broadly classified as data management (manipulation, preparation, extraction, etc.), visualization, and interface development tools. These tools can be two-way, that is, GIS can provide its services to hydrologic models, but also, hydrologic models can provide their services to GIS. This kind of operational synergy has been already successfully obtained through several GIS-model-GIS interfaces.
The major problem in advancing the usefulness of such operations, and expanding the scope by integrating several models into a unified modeling environment, is the lack of a consistent and standard way of exchanging data between GIS and models, and between the models themselves. This is a longstanding problem that has hindered integration of different hydrologic models. A solution is proposed in a form of a generic, non-proprietary, data exchange file format that would allow different 'users' of hydrologic data (GIS, hydrologic or economic models, etc.) to exchange data regardless of the source, type, or nature of the data, or the platform on which they were generated. The exchange file format would be open-ended and flexible to accommodate expanding data types and supported programs. It would be maintained on-line to enable easy and timely access, and would be open for discussion to users and developers.
Geographic information system (GIS) is a useful tool for hydrologic modeling. Many of GIS capabilities can be used at different stages of development of a hydrologic application. These capabilities can be broadly classified as:
Many examples exist in the literature showing different uses of GIS tools for support of hydrologic and in general, environmental and water resources modeling (NCGIA, 1993, AWRA, 1993, IAHS, 1993). In them, the level of complexity of GIS use varies, but they all indicate significant capabilities and potential of GIS for increase in modeling efficiency and usefulness.
Interaction between GIS and hydrologic models can be two way (Ball, 1994); that is, GIS can provide its services to the hydrologic model, but also, the hydrologic model can provide its services to GIS. For example, a model can take spatial data from GIS, perform certain hydrologic or hydraulic computations (e.g. floodplain delineation, groundwater flow computations) and then return the computed values back to GIS for further spatial (non-hydrologic) analyses. This kind of operational synergy has been already successfully obtained through several GIS-model interfaces.
GIS-model interfaces can be classified as being:
Each of these types of interfaces have their benefits and drawbacks. At present stage, most of the embedded applications are of simple hydrologic nature. More complex hydrologic analyses (such as solutions to time variant, 3D problems) are usually either linked or integrated with GIS.
Linkage and integration of GIS and models requires development of data and command interfaces. A typical GIS-model-GIS interface (Djokic et al., 1994) is presented in Figure 1.
This type of interface requires a number of programs that exchange data from one application to the other, and possibly a number of intermediate transfer files. Interfaces developed in such a manner are specific to the two programs that are being integrated. If another hydrologic application is to be integrated, new interface programs need to be developed. With careful programming, some of the previous interface code can be reused, but in principle, a new set of data conversion programs is needed.
In hydrology, it is often necessary to share the data between several models/programs. The applications can be of different character, such as GIS, image processing, statistical analysis package, hydrologic model, etc. Each of these programs can be looked upon as a data provider or a data user. Often, a single program is both a data provider and a user. If integration of these programs is to be achieved in a conventional way, a two way interface needs to be developed for each pair of applications. For N data providers and M data users there are NxM interface programs. Figure 2 depicts such a system.
Rationalization of the interface can be achieved by developing a generic data exchange format that all of the data providers and users would be able to read from and write to. In this case, only N+M interface models would be needed, significantly reducing programming effort. Figure 3 presents such a case.
The shared data do not necessarily have spatial character only, but can include information that does not lend itself well to GIS representation (temporal data, model parameters, etc.). This type of data make GIS to model, model to GIS, and model to model data transfer difficult, and preclude reliance on spatial data transfer standards for full data exchange. These standards though (SDTS in USA and similar in other countries) can be used for transfer of large amounts of spatial data.
A generic transfer method is proposed to facilitate data exchange between different data providers and users. It is called GHODEM - generic hydrologic object data exchange method. There are several requirements on the method to make it generic and portable:
In order to satisfy the above requirements the following structure is proposed: transfer files are in delimited ASCII format, and there are three transfer files: hydrologic exchange data file (*.hxd), hydrologic exchange header file (*.hxh), and auxiliary information file (*.aux). HXD and HXH files follow .ini' format with section headings in square brackets, and entries that appear below the heading. Section headings, entries and definitions are not case sensitive. HXD and HXH files are required, while AUX file is optional. The extensions .hxh, .hxd, and .aux are not mandatory.
This file contains description of hydrologic object structure of the data that are being transferred. It contains the class definitions for the data file and can be thought as a header file in C programs. Class definitions should be in sections, the components of that class as entries below the sections. Class headings should be unique. Components of the class are defined as the variable name, data type, length, precision, and nature of the information. An example of a header file is presented in appendix 1.
The nature of the information is important since it defines the character of that type of data and adds some "intelligence" to the datum. (The example uses the following nature descriptors: A-assigned, O-observed, P-parameter, and D-derived). An A indicates that the values have been assigned to variable, P, that it is a parameter of a model, D, that it has been derived, etc. By combining the nature of the component with the source program that created it, better understanding of the meaning of the datum can be achieved and passed on to the other programs that might use that information.
This file contains the actual data to be exchanged (an example is provided in appendix 2). It consists of a [Global] section that contains information about the data, including the version of GHODEM used, date when the data were translated to GHODEM format, the origin of the data, the format used for the dates, comments about the file, and the location (name) of header and auxiliary files if necessary (by default .hxh and .aux files of the same name and in the same local directory are assumed).
All other sections in this file contain the data to be transported. The section heading is the (unique) identifier of the data object, one entry called Type is the name of the class to which this object belongs (and is defined in the .hxh file), and the reminder of the entries are the values specified in the header file.
This file is a free format file containing any pertinent or interesting information related to the data transfer. For example, a detailed description of classes and properties can be provided here, or a description of the methodology used for calculation of some of the parameters. Here would also be a place to provide detailed definition of nature descriptor.
This file can also be used to provide additional control for particular drivers. For example, it can contain some keywords that will instruct a particular driver to translate data using some of the driver's available options. Appendix 1 and 2 show and example of transfer of data stored in ArcInfo GIS to SWMM stormwater modeling program. Only the first object of a class is presented.
Auxiliary file provides flexibility in how much additional information is being included with the transfer data. In an organization, where transfer between certain models/GIS is used every day, and there are well defined classes, methods, or variable names (maybe standardized across the organization) there will be little or no need for an auxiliary file. When the data are transferred to an external organization, a large auxiliary file might be included to clarify the data being transferred and the way they were generated. This freedom of additional information inclusion/exclusion can be easily accomplished by drivers and standard descriptor files.
The method is developed at the University of New South Wales, and will be used as the basis for model integration. The latest comments, suggestions, enhancements, and specifications are going to be available on Internet via email, users group, and WWW page. Initial contacts with industry (hydrologic/hydraulic software developers) have been encouraging. It is envisioned that the software developers would adopt the method and provide drivers (interfaces) to and from their software to GHODEM file structure.
GIS provides many useful tools for hydrologic modeling. One of the major obstacles for their more extensive use in hydrologic modeling is the difficulty of interfacing GIS and models, that is, the need to develop a specific set of data conversion programs for each GIS or modeling package. A method (GHODEM) is proposed that would enable generic and flexible transfer of relevant information from a data provider to a data user. The method is platform and product independent and allows transfer of data as well as additional information that describes the data generation method and its character. Not only spatial data, but also temporal data, could be transferred by this method, making it more appropriate for type of problems encountered in water resources.
It is expected that product developers would accept the method and provide "drivers" for import and export of data from their software to GHODEM format. Acceptance of such an exchange file format would enable the model or GIS developers to concentrate efforts on interfacing with only one file structure instead of developing a data interface for every model-model or model-GIS interface task. The users would then have a benefit of using industry-developed and maintained data exchange module that would let them concentrate on the model applications instead of model interfacing.
[catchment] SubArea=C,3,0,A ; Sub-area ID Area=N,12,5,D ; Area of sub-area (sq.m) HydLength=N,6,1,P ; Hydraulic length of sub-catchment in which sub-area is located (m) DrainageInlet=C,2,0,A ; Drainage inlet manhole ID RainGaugeID=C,2,0,D ; ID of rain gauge for this sub-area LandUse=C,2,0,O ; Land use code for this sub-area SoilType=C,2,0,O ; Soil type code for this sub-area [conduit] ConduitID=C,4,0,A ; Conduit ID Length=N,10,2,O ; Length (m) Shape=C,3,0,O ; Shape code Slope=N,5,3,D ; Bed slope Barrels=N,1,0,O ; Number of barrels Mannings=N,5,3,P ; Mannings roughness coefficient Dimension1=N,5,3,O ; First dimension for this shape type Dimension2=N,5,3,O ; Second dimension for this shape type Dimension3=N,5,3,O ; Third dimension for this shape type [non-conduit] ConduitID=C,4,0,A ; Conduit ID DSManholeID=C,3,0,O ; Downstream manhole ID USManholeID=C,3,0,O ; Upstream manhole ID DSManholeType=C,3,0,O ; Downstream manhole type code USManholeType=C,3,0,O ; Upstream manhole type code DSManholeNumber=N,3,0,O ; Number of downstream manholes USManholeNumber=N,3,0,O ; Number of upstream manholes
[Global] Version=1.0a Date=09/04/95 DataOrigin=ArcInfo DateFormat=British Comments01=This transport file was produced to send information to SWMM Comments02=for urban drainage analysis AuxDescFile=d:\ghodem\data\powells.aux [CAT001] Type=Catchment SubArea=1 Area=2572.03849 HydLength=119.5 DrainageInlet=1 RainGaugeID=2 LandUse=22 SoilType=1 [CON001] Type=Conduit ConduitID=5001 Length=46.28 Shape=15 Slope=0.76 Barrels=1 Mannings=0.011 Dimension1=2.001 Dimension2=3.200 Dimension3=4.200 [MAN001] Type=non-conduit ConduitID=5001 DSManholeID=1 USManholeID=2 DSManholeType=19 USManholeType=19 DSManholeNumber=1 USManholeNumber=1
AWRA, 1993, Symposium on GIS and Water Resources, Mobile, AL, March 14-17, 1993, American Water Resources Association Technical Publication TPS-93-1, AWRA, Bethseda, MD.
Ball, J.E., 1994, Hydroinformatics - Are we Repeating Past Errors, Proc. First Int.Conf. on Hydroinformatics, Delft, The Netherlands, September 19-23, 1994, pp 25-30.
Djokic, D., Beavers, M.A., and Deshakulakarni, C.K., 1994. ARC/HEC2: an ArcInfo - HEC-2 Interface. Proc. 21th Water Resources Planning and Management Division Annual Specialty Conference, ASCE, New York, N.Y., pp 41-44.
IAHS, 1993, HydroGIS 93: Application of GIS in Hydrology and Water Resources, International Association of Hydrological Sciences Publication No. 211, IAHS Press, Wallingford, UK.
NCGIA, 1993, Proc. Second International Conference/Workshop on Integrating GIS and Environmental Modeling, Brackenridge, CO, September 26-30, 1993.