Initial Conceptualizations GIS
In broad terms, GIS have provided environmental modelers with an ideal platform for spatial data integration, parameter estimation, and cartographic visualization, while environmental modeling has allowed GIS profession als to move beyond simple inventory and thematic mapping activities (Sui and Maggio, 1999). In practice, the degree of integration between the two technologies has tended to vary project by project. But, more to the point, what is meant by or how to specify any particular degree of “integration” is not so straightforward. Anselin et al. (1993) suggested a three-tiered classification based on the direction of the interaction between any two technologies: one-directional, two-directional, and dynamic two-directional (flexible data flow). Throughout the 1990s, however, it was generally accepted that for environmental simulation modeling, four levels of integration were possible using the following terminology: independent, loosely coupled, tightly coupled, and embedded (Fedra, 1993; Karimi and Houston, 1996; McDonnell, 1996; Sui and Maggio, 1999), although definitions vary slightly among these authors.
This doesn’t really represent a level of “integration” as such, but is included for completeness to cover those situations where GIS and environmental modeling are used together but independently on projects to achieve some common goal. In this context, GIS might be used to replace manual map measurements as traditionally carried out by modelers. Such measurements were invariably time consuming and prone to errors. Standard GIS functionality for measuring distances and areas could be used instead. GIS could also be used in parameter estimation for lumped models where, for example, dominant classes, spatially averaged, or interpolated values might be derived from relevant GIS coverage. The results from GIS usage would tend to be in the form of summary tables, which would then used as inputs to the environmental model.
At this level of integration, GIS and an environmental model can share data files. GIS interaction with a dynamic simulation model is likely to be more than a once-only set of measurements or parameter determinations, particularly where the outputs of a number of scenarios may need to be visualized or further processed using GIS. Moreover, where parameter estimation is for distributed parameter models, a tabular approach to data exchange becomes extremely cumbersome. It is much better then to have some means by which both GIS and simulation models can share data files. More often than not, this entails exporting data files into some data format that is common to both GIS and environmental modeling software. This might be some formatted text file for attribute tables and raster matrices or, very popular at the time, the.dxf CAD format for vector graphics. One distinct advantage of this approach is that off-the-shelf and industry standard software can be used together, on the same computer, with a minimum of further development costs (even zero development costs if both have built-in compatible data import/export functionality).
As each software becomes upgraded by the vendor, it can be brought into immediate use provided that a hardware or operating system incompatibility is not introduced in doing so (for example, the latest version of the GIS software might now only run under Windows XP or Vista, while perhaps the environmental model hasn’t been upgraded since it was first compiled under Windows 3.11, or more likely, the chip and memory on your faithful workhorse PC cannot take the upgrade; even peripherals such as an older plotter might no longer be supported in the software upgrade). It is also possible to switch software completely as a result of new developments because of the particular characteristics of the problem to be solved or even for compatibility with some third party (research colleagues, client, or other consultants in a consortium). On the other hand, with each software running through its own interface, it becomes necessary to do GIS and simulation tasks one at a time in sequence, exchanging files and switching software at each stage.
Under this level of integration, both software are run through a common interface that provides seamless access to GIS functionality and the envi-
ronmental modeling. They may even share a common file format that avoids the need to translate files to an exchange format, but if not, a file management system provides seamless data sharing. There is a development cost in creating the common interface, but it brings about tangible advantages. First, off-the-shelf and industry standard software can still be used, as in the loosely coupled option, but avoids the need for the exchange files to be dealt with manually. This is important, as on large dynamic modeling projects, the number of these files can extend into hundreds, easily leading to mistakes in using the wrong file. This aspect plus the avoidance of alternately switching from one software to another can save considerable time and adds flexibility in running scenarios. Incremental development of the common interface and file management may be required with each software upgrade, which may not be at the same pace or timing for GIS and the environmental modeling. Also, if for reasons given above a different GIS package or environmental model needs to be substituted, the development effort has to be carried through again. Tight coupling in this way, therefore, tends to be implemented for stable situations where a large amount of work needs to be carried out over a period of time.
A number of authors consider that an embedded level of integration is the same as tightly coupled and might indeed be so if defined as such. However, there is considerable difference in using GIS and environmental modeling through a common user interface and having either GIS functionality embedded in an environmental model or environmental modeling code embedded in a GIS package. For a start, one tends to dominate through the use of its interface as the only one used. Also, some of the embedded implementations can be partial, such as limited GIS functionality inside an environmental model. Embedded environmental models may also be in a simplified form. Often such embedding is carried out by vendors to make their products more attractive. Environmental simulation models are typically developed using mainstream programming languages (e.g., C++, FORTRAN, Visual Basic, Java) or advanced technical languages, such as MATLAB, which are not ideal, but offer a pragmatic solution for environ mental modelers.