David M. Theobald

The user-friendly interface of desktop GIS provides powerful functionality to a broad set of users. For example, ArcView allows users to easily interact with and query single maps. More complex models can be created using ArcView Spatial Analyst and Avenue consisting of multiple themes and the functions that define their relationships. However, interface tools to construct and visualize these complex models in desktop GIS are lacking. I will demonstrate a prototype extension that enables a user to visualize model logic, automate repetitious tasks, and construct complex models, including temporally-dynamic simulation models, within the ArcView environment.

Generally speaking, there are two prominent trends in the geographic information systems (GIS) industry. First, more sophisticated GIS are being used to address a broader range of problems and in a wider variety of situations. For example, GIS is being applied to problems that require coupling of simulation models with GIS (e.g., Goodchild et al. 1993), the visualization of spatial data (Buttenfield 1996; MacEachren and Taylor 1994), the development of spatial decision support systems, and in situations which require conflict resolution and collaborative decision making (e.g., Faber et al. 1998) and to support public decision making and public policy (e.g., Hobbs et al. 1997).

GIS has evolved to provide solutions in three areas: GIS as an information database, GIS as an analytical tool, and GIS as a decision support system (Eastman et al. 1995). A practical result of pursuing analytical and decision support GIS is a separation between model builder and user, or technician and manager. For example, GIS technicians generally operate the GIS and generate maps largely at the direction of a manager who translates the decision making context into data and information needs to the technician. Occasionally, a single person may play the roles of both technician and manager, but the roles are fairly distinct even here. This separation is simply result of the considerable programming effort required to produce a complex model. Two downfalls to this separation are that the model user must rely on the expertise of the model builder and that it is difficult to revise the model structure to reflect some conceptual shift in thinking about the problem at hand.

A second trend affecting the GIS industry is the result of recent advances of computer technology and graphic user interface operating systems. In particular, desktop GIS has emerged, capitalizing on the advancement of direct manipulation (i.e. "point-and-click") interface software. This recent innovation has brought powerful GIS functionality to a broader group of users because of its relative ease-of-use and intuitiveness. Desktop GIS have arguably narrowed the traditional separation between creator and user of GIS information.

I argue here that there are opportunities to improve GIS interface design that would further narrow this gap between creation and use of GIS-derived information, while simultaneously improving the ability to meet general GIS application needs. In particular, the latter two application domains yield new, derivative maps. GIS interfaces must evolve to facilitate users' understanding of the relationships of these maps and incorporation of the decision making context.

One of the major advantages of Esri's desktop GIS -- ArcView 3.0 -- is that users no longer need to recall commands (from many hundreds to thousands of options) complete with the proper syntax, as they did with the first-generation command-line interfaces found in ArcInfo. The point-and-click interface makes construction of new map and map query more intuitive. However, to support advanced GIS applications, one needs to model a system by building functional relationships between multiple maps, rather than just producing or querying a single map. The chain of reasoning can become quite complex rather quickly, and documenting the logic used to create a series of maps is not automatic, nor re-created easily in ArcView or ArcInfo. In fact, it is ironic that one of the most common methods to display the logic of a model both in teaching, research, and computer programming is to draw a flowchart or flow diagram (e.g, Davis 1996), yet most GIS software do not utilize this visualization tool. Furthermore, visualization of model logic would enable a learning strategy called "concept mapping", which provides a way to enhance meaningful learning by integrating concepts and anchoring relationships to objects (Ault 1985). A few GIS provide some ability to graphically build models, such as Graphic Map Algebra (Kirby and Pazner 1990); the "procedure workbench" in Grassland (LAS 1997); and IMAGINE Model Maker (ERDAS 1998).

In particular, I find that ArcView, and most other desktop GIS, lacks facilities for even basic lineage documentation (sensu Lanter 1994), visualization of model logic, and sensitivity analysis and repetitious tasks. Furthermore, they lack a visual programming language to construct models that describe relationships (operations) between multiple maps. While a simple program can be written using Avenue, the user must revert, essentially, to a command-line interface. Similarly, conducting a "sensitivity analysis"--adjusting a single model parameter through a range of values to see how model results change--is a tedious endeavor. Finally, while some efforts to integrate GIS with simulation models has occurred (Goodchild et al. 1993), the functionality to support even simple spatio-temporal simulation models in ArcView and other desktop GIS has yet to be realized. Simulation modeling can be used to understand how a system functions and to communicate that understanding (Macgill 1986) and are an important function of many decision support systems.

I argue here that a simple extension of the desktop interface overcomes these deficiencies and, furthermore, provides an environment that enables users to build fully integrated, spatio-temporal dynamic simulation models. Below I illustrate this modeling environment using a prototype extension to called "Spatial Modeler."

I designed this prototype extension to explore and demonstrate the utility of providing a visual modeling environment to extend the capabilities of current desktop GIS. In particular, the goals of Spatial Modeler are to provide a means to: (1) document and visualize the relationships of various maps (coverages, themes), that is, their parentage and dependents; (2) automate repetitive tasks; and (3) develope temporally-dynamic simulation models within this modeling environment.

A strong influence on the design is a popular system dynamics software package called STELLA, which provides a graphic interface language that allows complex, non-linear system dynamics to be modeled through various feedback loops (HPS 1998). It is frequently identified as a "model" interface design due to the intuitiveness and ease of constructing models. For example, "...further development of a flexible software environment for ecologists without extensive modeling background is appropriate. To make this accessible, enhancements to existing visual, interactive modeling languages (such as STELLA) are needed (NCEAS, Workshop on Computation in Ecology, 1996, 7)."

Indeed, coupling GIS and systems dynamics modeling provides a method to incorporate spatially-explicit models with temporal dynamics and feedbacks (Theobald and Gross 1994). For example, Costanza et al. (1990) developed a loosely-coupled simulation model using a STELLA-based ecosystem model to examine coastal landscape dynamics. McDonnell and Macmillan (1993) used STELLA to model the changes in hydrology as a result of a new dam. However, in each of these two approaches, the simulation model is disjunct from the GIS, hindering the important process of iterative construction of multiple models (Theobald and Gross 1994).

In the spirit of system dynamics modeling, I define three stages in the modeling process. In the development stage, the conceptual model is developed as a representation of the basic structure and assumptions of the environment studied. In the implementation stage, the conceptual model is formalized through mathematical relationships to rigorously define the model. In the use stage, the implemented model is simulated and model behavior examined. Modeling is best seen as an iterative process, where understanding of a system is accomplished by conceptualization of a system, visual representation of a system, and exploration of model behavior. ArcView Spatial Modeler is designed as a visual programming environment, to provide a "succinct expression of a model’s logic and an iterative mechanism to execute the model under various interpretations" Berry (1993: 22).

The basis of the extension is the "Model Diagram," where icons that represent different types of objects can be manipulated on the diagram. By establishing relationships (operations) between the different model objects, the model logic is simultaneously constructed and expressed through the model diagram. Once the model diagram is completed, the user can "run" the model and view its results. Five model object types parallel the ArcView document types: Theme, View, Table, Chart, and Model.

The theme object represents themes, and can include feature (polygon), grid (raster), and image themes. The icon of a theme is a thumbnail image of the theme. Relationships between themes are described by defining the theme expression in the theme dialog. The expression defines the inputs and functions that will be performed to create the new grid theme. A "Function Wizard" provides an easy-to-use dialog for all ArcView functions and can be used to assist users in defining relationships. Alternatively, the user can type in the Avenue expression directly in the expression edit box.

The view object is similar to the theme object, but it represents multiple, related themes. In a model diagram, the expression defining a new theme is calculated only once, while the expression for a View object is re-calculated for each time step specified by the simulation model. Three types of relationships can be defined here. The view object can simply be the result of an expression, so that each new theme in the view is independent of the previous theme. This is useful in sensitivity analyses, where a parameter in the operation is tweaked, but the resulting themes are independent of one another. Processes where the new theme is dependent on the previous theme, but replace that theme can be modeled as well. This can provide cellular automata functionality, so that the value of the next simulation step depends on the previous simulation step, but replaces the value. Another type of feedback is similar to system dynamics, where feedback occurs in an accumulation model. The value of the next simulation step is dependent on the previous simulation step, but the new value is added or subtracted in a "conserved" flow manner. This is especially useful in modeling population dynamics. Currently only discrete time-step simulation is supported.

Tables contain tabular data representing a single value, time-series data, a neighborhood configuration, a kernel (for image processing-like operations), and a list of objects. Table objects can be either input or output objects in the model diagram.

Data can also be visualized using charts or graphs. The types of charts supported are: time-series, scattergram (x and y), and histogram. Chart objects are not part of the model logic, but rather are ways to visualize model output.

A model object represents a model diagram. Model objects can be part of a model, allowing sub-processes or frequently used operations to be packaged into a model, and then incorporated wholly into new model diagrams. It allows a problem to be broken into logical sub-processes.

Figure 1 shows a simple habitat model based on three input themes, vegetation, elevation, and dist to streams. Figure 2 shows the dialog box that is used to define the relationship (the function) between the theme objects. The function wizard button provides hierarchical access to the numerous functions found in ArcView. Users define an expression by choosing a function, then selecting the various parameters specific to each function from a dialog. Users can then select from a defined set of options, which allows them to recognize the options rather than having to recall them and reducing compilation errors. Also note that the lineage of the Habitat theme can be easily seen. Figure 3 shows how the same model can be modified to automate a repetitive task. In this case, the model runs for each of the selected rows in the table Species-Veg Affinities. The result of this model is a unique theme, for each selected row of the table, and the themes are stored in the "View" object Habitat.

Within this modeling environment the spatial structure of a topological model diagram can be examined to determine influences on system behavior. System dynamic researchers have long been interested in understanding how model structure affects the dynamics of the system. Because the model objects can be mapped to geographical locations, the topological model logic could be spatially geo-referenced. One example would be a model of hydrology, where model objects might represent reservoirs at different locations in a watershed, and the representation of the model objects is geographically referenced.

Ault, C.R., Jr. 1985. Concept mapping as a study strategy in Earth Science. Journal of College Science Teaching 15(1):38-44.

Berry, J.K. 1993. Moving Toward a Humane GIS. GIS World, 22-23.

Buttenfield, B. P. 1996. Scientific visualization for environmental modeling: Interactive and Proactive Graphics. In: GIS and Environmental Modeling: Progress and Research Issues, Goodchild, M.F., Steyaert, L.T., and Parks, B.O., eds. GIS World: Fort Collins, Colorado.

Costanza, R., Sklar, F.H., and White, M.L. 1990. Modeling Coastal Landscape Dynamics. BioScience 40:91-107.

Davis, B. 1996. GIS: A visual approach. Sante Fe, NM: OnWord Press.

Eastman, R.J., Jin, W., Kyem, P.A.K., and Toledano, J. 1995. Raster procedures for multi-criteria/multi-objective decisions. Photogrammetric Engineering & Remote Sensing 61(5): 539-547.

ERDAS 1998. http://www.erdas.com/toc_index.html

Goodchild, M.F., Parks, B.O., and Steyaert, L.T. 1993. Environmental Modeling with GIS. Oxford University Press.

High Performance Systems, Inc. 1998. http://www.hps-inc.com/

Hobbs, N.T., Theobald, D.M., Zack, J., Bearly, T., W.E. Riebsame, T. Shenk^. 1997. Forecasting Impacts of Land Use Change on Wildlife Habitat: Collaborative Development of an Interactive GIS for Conservation Planning. http://www.nrel.colostate.edu/scop/SCoPwww.html

Kirby, K.C. and Pazner, M. 1990 Graphic Map Algebra. Proceedings from Spatial Data Handling, Zurich.

LAS, Inc. 1997. GRASSLAND user's guide. Logiciels et Applications Scientifiques Inc., Laval, Quebec, Canada. (http://205.151.191.131/grassland/)

Lanter, D.P. 1994. A lineage metadata approach to removing redundancy and propagating updates in a GIS database. Cartography and Geographic Information Systems 21(2): 91-98.

Faber, B. G., Wallace, W.W., and Johnson, G. E. 1998. Active Response GIS: For Resource Management Spatial Decision Support Systems. Photogrammetric engineering & remote sensing 64(1):7-.

MacEachren, A.M. and Fraser-Taylor, D.R. 1994. Visualization in modern cartography. Pergammon: Oxford, U.K.

Macgill, S.M. 1986. Evaluating a Heritage of Modelling Styles. Environment and Planning A 18:1423-1446.

McDonnell and Macmillan 1993.

NCEAS, 1996. Workshop on Computation in Ecology. National Center for Ecological Analysis and Synthesis.

Theobald, D.M. and Gross, M.D. 1994. EML: A Modeling Environment for Exploring Landscape Dynamics. Computers, Environment and Urban Systems 18(3): 193-204.

Dr. David M. Theobald

Research Associate

Natural Resource Ecology Laboratory

Colorado State University

Fort Collins, Colorado 80523-1499

davet@nrel.colostate.edu

http://www.nrel.colostate.edu:8080/~davet/home.html

(970) 491-5122; (970) 491-1965 FAX

Figure 1. An example of a simple model built in ArcView Spatial Modeler. The Model "Habitat model" contains a main model that consists of four themes and their relationships. The theme "Habitat" is built from the themes "Vegetation", "Elevation", and "Dist to Streams". These three source themes are in a sense pointers to the themes found in the View "Data Themes" (lower left).

Figure 2. The dialog for the "Habitat" Theme object. This shows other valid input themes that are found in the model. The function that describes the relationships between the input themes is found in the list box at the bottom of the Theme Dialog.

Figure 3. In the previous models, the task would run only once, since the equations were defined in the listbox. Here, the model will run for each of the selected rows in the Species-Veg Affinities table. This shows how tasks can be automated for a number of species easily. Notice that the Habitat object is now a "View" object, which contains the themes that are created by the model, one for each row selected.