| The latest developments...promise to take GIS to dramatic new levels of functionality. |
The earliest modeling tools were macro-scripting languages (e.g., Arc/Info AML, ERDAS EML and IDRISI IML).Macro languages allow one to develop and save a sequence of GIS operational commands, either as sequences of command line statements or through the use of a special-purpose macro language, in some cases incorporating some of the control and interface design elements of a programming language (e.g., ArcView Avenue).Macro languages can be very powerful, but the sequences are often tedious to construct.In addition, each scripting language tends to be system specific, requiring a substantial investment of learning when several systems are used.
|
| A typical map calculator tool.Map calculators are excellent for the implementation of models that can be expressed as equations using the operations typically associated with a scientific calculator. |
The next tool to be developed was the map calculator (Figure 1).Using the analogy of a scientific calculator, these tools offer the ability to enter and save algebraic or
| Dynamic modeling - a somewhat new but extremely important development in the history of GIS modeling. |
Most recently we have seen the development of two new modeling approaches that offer not only the ability to automate complex tasks, but the promise of profoundly changing the nature of GIS modeling itself.These are the COM client/server model and the graphical modeling medium.
COM is Microsoft's acronym for the Component Object Model - a language independent specification for the manner in which software components communicate.COM is an outgrowth of the developments in Object Linking and Embedding (OLE) and the component model that underlies most visual programming languages (VBX/OCX/ActiveX).Today it provides the very foundation of Windows software development.Significantly, we are seeing the transformation of most major GIS software systems into COM servers.
|
| A typical sequence in accessing the exposed procedures of a COM server.Once the server (IDRISI32 in this example) has been registered with your programming software (in this case, Microsoft's Visual Basic for Applications), typing the server reference followed by a dot is enough to list the available properties and methods (top illustration).Then, when a method has been selected, code completion lists the parameters and their data types (bottom illustration). |
A COM server, such as IDRISI32 or the latest release of ArcGIS, is an application that exposes elements of its functionality to other applications (clients).Through the standardized interfaces of COM technology, it is possible to use a visual programming language such as Visual Basic, Delphi or Visual C++ to write programs that control the server application like a puppet.Although there is some investment in learning one of these languages, the payoff is substantial - the ability to create complex models with customized interfaces based on the capabilities of the host GIS software (Figures 2 and 3).Further, since the interface is standard across many applications (unlike system specific scripting languages), it is possible to marshal the capabilities of several tools in a single model.The advantages for third-party software developers are clear.However, for the individual user and agency workgroup, the potential is also significant.With only the most fundamental knowledge of visual programming (something that can be gained from a self-help book in a couple of days) it is possible to construct models of a complexity that would be almost inconceivable to do by hand.
|
| The land cover change prediction module illustrated here was developed as a COM client program - a program that makes calls to modules in the COM server to do the actual work.In this case, the program code associated with the OK button simply serves to direct the sequence of operations among standard IDRISI32 modules exposed by the COM interface.The model is complex (a typical run might involve more than two thousand GIS operations), but the programming knowledge required to develop it is minimal. |
While COM gets at the internals of the system, graphical modeling tools go in a very different direction (Figure 4).By placing an additional layer onto the top of the system they provide a very simple and powerful medium for expressing the relationship between operations that form the sequence of a model.They also offer a very flexible means of model development: add a step; test it; add another; test it; modify it if necessary; and so on.
|
| Graphical modeling environments provide a very direct means of visualizing the sequence of operations in a model.This example illustrates a cellular automata process of urban growth using a feedback loop (the red link).The result is a dynamic model - a major new phase in GIS model development.The continued development of control structures in graphical modeling environments (such as conditional branches of control and iteration structures) suggest that graphical programming environments may rival current programming environments for many modeling activities. |
Current graphical modeling environments in GIS are largely confined to the tree structure of traditional cartographical modeling (although those built on scripting structures do sometimes offer non-graphical control structures).However, it is perhaps not surprising that we are beginning to see the introduction of alternative control structures.For example, the illustration in Figure 4 shows the use of a Dynalink in IDRISI32 - a feedback loop that replaces input layers with the outputs of previous iterations.The result is a form of dynamic modeling - a somewhat new but extremely important development in the history of GIS modeling.
Perhaps the surprising thing about graphical modeling in GIS is that the direction in which these tools are heading promises to replicate much of the power of COM-based visual programming in the not too distant future.We are already seeing the introduction of feedback and iteration structures that allow for elementary dynamic modeling and highly flexible iteration and batch processes.However, the introduction of true graphical conditional branches of control and other basic elements of programming languages are not far on the horizon.Coupled with suitable interface development tools, it is not beyond reason to expect that these may replace conventional programming languages for model development for the majority of GIS professionals.