Despite the scientific separation between the way GIS and environmental simulation models are constructed and used, the continuing need to establish some level of integration beyond just being used together is driven by the growing recognition that integrated assessments of all aspects of the physical, biotic, social, and economic environment are required if sustainable solutions to problems are to be achieved (Clayton and Radcliffe, 1996; Aspinall and Pearson, 2000). One important change is a reconceptualization of where GIS and environmental simulation models stand in relation to each other (Clark, 1998). It should no longer be the case that one or the other represents the technological “heart” of the project. Rather, it should be the database or, more accurately, databases that form from which GIS hubs or portals, other geocomputational tools, and simulation models draw input data and submitprocessed output data. Such databases are increasingly accessible across networks and it is networks, particularly the Internet, that has become the key to the integrated use of diverse tools and data sets.
Integration versus Interoperability
First we need to make the subtle but important distinction between integration and interoperability. As we have seen above, the act of integration was to bring two rather different technologies or set of tools into closer proximity so they can work together, even perhaps as one. This could be done through sharing data and interfaces. Lilburne (1996) has suggested measuring the level of integration between GIS and another system with respect to three key components: user interface, data, and functionality. Of 104 cases studied, higher scores tended to be achieved for the integration of interface and data, but that, in general, these achieved poor scores when assessed on the integration of functionality. Given the arguments of the previous section, this should not come as a surprise.
Interoperability on the other hand is the ability of client-side software applications to access a service (e.g., some specific functionality) from a server-side implementation such that it will respond as expected (Albrecht, 1996a). This is to do with software components that are interchangeable so that, within a specific hardware and operating system environment, groups of software can seamlessly operate together. Thus, for example, I can call MapInfo as an ‘Insert, Object …’ right now as I am typing this chapter from within Microsoft Word (Figure 7.6). The toolbar becomes that of MapInfo and I have within Word some GIS functionality. Thus, interoperability is the bringing together of software at a more structural, software developmental level than is usually achieved through the integration of independently developed software.
The dominance in the marketplace of a small number of operating systems, such as Microsoft Windows and Linux, together with the current prevalence of object-oriented (OO) programming and a high degree of standardization of Internet protocols for the access and communication of
data, have all very much eased the convergence of once separate software types (database, spreadsheets, statistical packages, GIS, and so on) toward an environment of mutual interoperability. This brings with it three important advantages. The first is that much of the software tends to have the same look and feel, a shared principle of interface design using pull-down menus that have a common vocabulary and functionality as well as a familiar array of icons. For example, this icon: almost universally means “open a file.” Second, data access over networks is eased as the communication protocols, data extraction, and data transformation services have become largely transparent to the user. Data transformation services are important for environmental simulation modeling where the time steps and spatial scale of a data set in a data repository need to be transformed to that expected by the simulation model to be used. Thirdly, by using OO high-level languages, such as Visual Basic or Java, it is possible to construct programs that use selected services from one or more existing software and wrap them in a common user interface.
The GIS vendor community is comparatively small and in 1994 a number of them, together with some university research laboratories, established the Open GIS Consortium as a way of fostering interoperability, so that spatial data and its processing could become part of mainstream computing and, thus, of more widespread use. The goal is for GIS to become embedded in the main IT (information technology) infrastructure that supports today’s information society. “Our vision is a world in which everyone benefits from geographical information and services made available across any network, application or platform” (OGC, 2002).
GIS, as software, had been developed by each of the vendors with their own particular data models, data structures, and variants of the basic functionality. The further development of the industry was not being aided by the need to be continually transforming data (despite data transfer standards) and by having to understand the nuances in similarly named functionality. At the same time, the overall rate at which spatial data were being collected by a growing number of technologies threatened to overload the vendors and the user community with the need to have a growing number of tools to transform and upload each new data type. Thus, an Open GIS Specification has been devised and is a framework by which conformant software can be written. The framework includes:
- A common means for digitally representing the Earth and Earth phenomena, mathematically and conceptually.
- A common model for implementing services for access, management, manipulation, representation, and sharing of geodata between information communities.
- A framework for using the Open Geodata Model and the Open GIS Services Model to solve not only the technical noninteroperability problem, but also the institutional noninteroperability problem.
The environmental simulation modeling community, on the other hand, is much larger and more diverse (multidisciplinary, in fact) and has not come together in the same way that the GIS community has. That is not to say that simulation modelers are not adopting open systems architecture or looking for greater interoperability with mainstream databases, spreadsheets, and statistical packages, it is more of an individual choice rather than an industry effort. Where does this leave GIS and environmental modeling? Both are working in increasingly interoperable environments with a growing commonality in their structural aspects. This makes deeper levels of integration more practicable particularly where multiple databases and models might be used in a computational framework.