Exploring the Decision Space: Spatial Decision Support Systems

In Chapter 5, Figure 5.6 showed how there is a range of alternative, even complementary strategies that could be put forward to reduce the level of

risk depending on the degree of prevention or preparedness that society is willing to pay for and accept. We also noted that mitigation in terms of prevention or preparedness was a spectrum from maximum risk reduction usually at a high financial cost to much smaller levels of risk reduction at a much reduced financial cost. What is more, they are not mutually exclusive. Given the magnitude and frequency relationship of natural hazards, it may be prohibitively expensive or technically impossible, for example, to prevent loss from higher magnitude events, in which case some form of preparedness through zoning or early warning may be prudent.

Lower magnitude events that happen more frequently, on the other hand, may indeed be preventable at an economic cost and allow land to be kept in productive use. Such decisions may well change from one area to another depending on the local level of risk. Decisions on where and when to employ structural or nonstructural measures of mitigation and the mix that may represent a good, affordable strategy need to be based on an assessment of realistic alternative scenarios. SDSSs allow such assessments to be structured.

Decision support systems (DSS) began their technical development in the 1960s at the Massachusetts Institute of Technology (MIT) as computer-based solutions to support complex decision making and problem solving. The classic DSS tool comprised of the following components:

• Database management system for accessing internal and external data, information, and knowledge.
• Modeling functions.
• User interface designs for interactive queries, graphical display, and reporting.

The main focus of DSS research has been on how information technology (IT) can improve both the efficiency with which decisions are made and the effectiveness of those decisions (Shim et al., 2002). A structured problem is one that is fully specified in terms of the objective of the decision and the nature of the problem to be solved. They, therefore, tend to be problems that are routine, repetitive, and easily solved. Structured problems clearly don’t need the aid of IT to effect a solution. The bath is overflowing, so turn off the tap. But, there are a whole range of problems that are ill-structured in which the nature of the problem itself may not be known or cannot be fully and coherently specified; the objective of the decision may not be clear. These may be new, novel problems or ones that are difficult to solve. A heightened incidence of lung cancer is identified on the south side of the town. Sure, cancers are a problem, but are they a consequence of some hidden cause in that part of town (asbestos in the building materials?), caused nearby and wafted in (that new incinerator?) or caused entirely elsewhere (they all work in the same factory in the next town?). What is the real problem, how do we find it, and when we’ve found it, how are we going to solve it? Semi-structured problems would have a mix of characteristics of structured and ill-structured problems.

DSS are designed to assist in solving semi- and ill-structured problems. The decision process that DSS try to mimic is based on intelligence, design, and choice (Simon, 1960) where intelligence is the means by which we search for and clarify problems; design involves the development of alternatives and choice consists in analyzing the alternatives and choosing one for implementation. Another way of putting this is illustrated in Figure 10.2 and concerns methods and goals. DSS provide structure and assistance in moving through the contingency table in a counterclockwise direction (and never the other way), first in defining goals through a proper definition of the problem to be solved and then in defining methods first through the development of candidate solutions and then through the design and delivery of the solution to be implemented.

SDSS are not fundamentally different from DSS other than a focus toward the solution of complex spatial problems. Because of the spatial dimension, SDSS will need to have additional capabilities that:

• allow handling of spatial data.
• allow representation of spatial relations (e.g., topology);
• include spatial analysis techniques (e.g., buffering, overlay);
• provide visualization of spatial data.

Of course, most of what is required in terms of these additional capabilities can be provided by GIS, though GIS on their own do not constitute SDSS, as most semi- and ill-structured problems of a spatial nature have a complexity that cannot be solved purely by query and recombination of geographic data alone. Moreover, GIS only have a narrow set of modeling capabilities falling short of what would be desirable in SDSS. From the same perspective, environmental simulation models are not DSS either (spatial or otherwise). Bring the two together and you start to have the minimum configuration for an SDSS, the ability to carry out “what if”-type analyses that provide multiple outcomes that characterize the decision space being explored for implementable solutions.

The architecture then of an SDSS is not dissimilar to those discussed in Chapter 7 for the coupling of technologies where one would expect at least a loose coupling for multiple “what ifs” to be tractable. While the ideal for an SDSS would be a tool coupling (Figure 7.10) to form a modeling framework with subsystems for data management, spatial data processing, model building and management, model execution, quality management and visualization, this is not always feasible. SDSS are often implemented for specific problem domains that, in a spatial context, often means within a finite geographical area. The up-front cost and time to implement a tool coupling may not be justified and instead a lower order of integration may be chosen. Also, if each of the basic tools being brought together are in themselves sophisticated with extensive user-interface and a range of industry “standard” input and output formats, then there is often little incentive in working toward a fuller integration, especially when GIS analyst and professional modeler are separate individuals working extensively with their own tools.

In the Hong Kong basin management planning example given in Chapter 6, the initial phase was characterized by a loose coupling with GIS and hydraulic modeling activities being carried out in different locations (university and consultants offices) with a two-way data transfer every few days. It was only in subsequent phases of the project (it ran its course over several years) that a closer coupling was achieved. Furthermore, as we discussed in Chapter 9, many environmental simulation models have a long life span due to the cost of development and testing and working toward closer integration of the so-called legacy software can seriously detract from getting on with the project in hand unless such integration is a longer-term goal to be achieved incrementally.

Share this post