Integration of GIS and Spatio-temporal Simulation Models: Interoperable Components for Different Simulation Strategies

1

Integration of GIS and Spatio-temporal Simulation Models:Interoperable Components for Different Simulation Strategies

Lars Bernard, Thomas Krüger

Institute for Geoinformatics (http://ifgi.uni-muenster.de)

University of Münster, Germany

Robert-Koch-Str. 26-28

D - 48 149 Muenster

fon.: +49 251 83-33924

fax.: +49 251 83-39763

e-mail: {bernard,krugert}@ifgi.uni-muenster.de

Keywordsinteroperable GIS, interoperable simulation, spatio-temporal simulation, modelintegration, atmospheric modeling

Short title for running head

Integration of GIS and Spatio-temporal Simulation Models

2

Integration of GIS and Spatio-temporal Simulation Models:Interoperable Components for Different Simulation Strategies

Lars Bernard, Thomas Krüger

Abstract

New technologies for distributed object computing (DOC) challenge new approaches tointegrate Geographical Information Systems (GIS) and simulation tools for spatio-temporal modeling. Several standardization initiatives work on specifying interfacesand defining service architectures for appropriate components. Currently, the mostpromising attempts are represented by the OpenGIS and the High Level Architecture.

This paper gives a brief survey of the current state of the emerging standards,highlights the advantages and shortcomings of these attempts, and defines a possibleframework for GIS-integrated simulation of spatio-temporal processes. Two abstractionlayers provide interfaces for different GIS kernels and allow the integration of differentsimulation models. A prototype implementation of the specified interfaces shows theintegration of analysis tools and two different simulation strategies: a mesoscaleboundary layer model based on the Navier-Stokes equation and a cellular automata tosimulate air pollutant dispersion.

3

1 Introduction

Previous investigations on GIS and environmental modeling showed various usefullinks between GIS and spatio-temporal simulation models (Goodchild et al. 1993,Goodchild et al. 1996, Fortheringham and Wegener 2000). However, a system thatenables planners to plug in different simulation models easily and to combine them withtheir analysis tools is still hard to find.

During the last decade technical infrastructures for the implementation and integrationof interoperable software components arose and opened a wide range of possibilitiesto create improved plugable GIS and simulation models.

Nevertheless a gap exists between the efforts to achieve GIS interoperability andinteroperable simulation models. Initiatives that specify interoperable GIS are still in astarting phase and focus on geographic data services. Approaches towards theexchange of analysis services, especially in support of spatio-temporal analysis arehard to find. On the other hand specifications for interoperable simulation componentsdo not consider spatial databases or linkage to analysis tools for spatio-temporalanalysis.

This paper will give a brief overview and an analysis on the current state ofinteroperable GIS and simulation models and discusses strategies for their linkage.This discussion is followed by the description of a framework that offers approaches toovercome some of the concluded shortcomings. A final presentation of integratedapplications will demonstrate the reached efficiency of the prototype and lead to theconclusions.

2 Integration and Interoperability

Different strategies to link GIS and simulation models have been discussed. In generalCoupling and Integration of these applications can be distinguished as the two mainstrategies to achieve linked applications (Goodchild et al. 1996).

Coupling means the linkage of two stand-alone systems by data transfer. Categorizedby the way of data transfer several degrees of coupling systems can be distinguished(Nyerges 1992, Fedra 1996). Integration means the implementation of GIS tools andsimulation models on top of a common data and method base. The latter has beenshown as the suitable strategy to avoid inconsistency due to data and methodredundancy and to prevent information loss due to non-appropriate data exchangeformats and heterogenous data models (Bernard et al. 1998b). But integration basedon the existing closed and monolithic GIS and simulation models includes a high risk indesigning systems, being again closed, monolithic, and therefore costly (Fedra 1996).For that reason coupling of separate systems is still preferred when linking GIS and

4

simulation models. But these approaches normally offer very specialized and isolatedsolutions and thus do not lead to a general and generic linkage.

The paradigm of object-orientation and the idea of interoperability became widelyaccepted as concepts to prevent these disadvantageous developments (Buehler andMcKee 1998).

Object-orientation has been discovered as a concept to realize thin components, whichencapsulate their data and their specific details. A component is able to offer serviceswhich guarantee a secure usage of the object data. To avoid the risk of designing newmonoliths, the interoperability of different object-oriented components is claimed.Interoperability means the ability of two or more systems or components to exchangeinformation and to use the information that has been exchanged (IEEE 1990).

The employment of layered architectures is well established for the design ofinteroperable systems. Successful examples are the Java platform (SUN 1999) and thearchitectures allowing a Distributed Object Computing (DOC), as DCOM (Microsoft1998), CORBA (OMG 1998) or the Java based RMI (SUN 1999). See Szyperski (1999)for a comprehensive discussion of current component technologies. Layeredarchitectures are a principal technical basis for bringing object-oriented components ofdifferent application areas together. Separate and interoperable components enable acomplete system integration and at the same time minimize the risk of developing newmonoliths. To guarantee interoperability of the application services that are built on topof these architectures, common interfaces have to be specified. These interfaces mustbe implemented by application frameworks that are intended to provide interoperablecomponents.

In GIS and simulation system development labs, the design of interoperablecomponents sharing their services has been the consequent next step. The OpenGISConsortium (OGC, http://www.opengis.org) and the Simulation InteroperabilityStandards Organization (SISO, http://www.sisostds.org) belong to the well-knowninitiatives coordinating specifications for interoperable GIS components andinteroperable simulation components respectively.

The following overview shows the opportunities and shortcomings of OpenGIS and theHigh Level Architecture (HLA) as the most promising emerging standards in the contextof geoprocessing and simulation regarding the above requirements.

2.1 OpenGIS

The objective of the OGC, as a common organization of GIS developers and users, isthe development of a unique specification for geoinformation services. The vision is theestablishment of a global infrastructure for geoinformation services, which enables aneasy integration of these services into standard applications. To achieve an institutionalinteroperability the OGC tries to initialize the dialog between the developer and theuser of the services in order to solve also non-technical interoperability problems (e.g.conflicts concerning copyrights on data).

5

The OpenGIS specifications should serve as a framework for programmers in thesense of a generic programming interface (Buehler & McKee 1998) and allowinteroperation of different GIS components. The OpenGIS specifications are separatedinto three parts:

• The Open Geodata Model describes general classes for modeling spatial objectsin the sense of an universal geodata model.

• On top of the specifications of the Open Geodata Model access and processing

services are specified within a Service Architecture, which enables the use andexchange of OpenGIS services through the Internet.

• The Informations Community Model focuses on a common catalog and

documentation of spatial objects within their application domain. That should bethe basis for exchanging geoobjects between different domains. In this contextnot only the technical interoperability but also the institutional interoperability isdiscussed.

Within the open abstract specification different task forces are developing platformindependent reference models for each of the three mentioned parts (OGC 1999a).Within the implementation specifications the abstract specifications are realized asinterface definitions in the sense of black box abstractions for different platforms.

The Service Architecture defines OpenGIS conform access paths to geo-databasesusing so called Catalog Services. The Information Communities Model should serve asbasis for semantic mapping (Bishr 1997) and will extend the Catalog Services. But adetailed description for this issue is not yet available. The specification ofGeoprocessing Services as a basis for analytical tools also only exists as a first draft.Altogether the existing specifications are limited mainly to data retrieval, data access,and elementary geometric queries. Moreover the current specifications neither focus onmethods required by simulation tools nor on methods for the analysis of spatio-temporal processes.

The abstract specification of the Open Geodata Model is the most sophisticated. Thefirst implementation specifications for SQL, OLE/DCOM and CORBA describe data andmethods of 2D vector geometries and are already implemented by commercialapplications (OGC 1998, OGC 1999b, OGC 1999c). The implementation specificationsof the Catalog Services exist in a first draft.

Considering the current status of the OGC specifications it should be mentioned thatthe individual specification parts generated by the separate task forces do not fitseamless to a consistent entire specification. Therefore a further coordination andunification of the OGC specifications might be required in future (Cuthbert 1999).

Nevertheless the ongoing work of the OGC on specifying a general interface and aservice architecture for exchanging geodata is essential for the design anddevelopment of interoperable GIS components. Some details of the specificationsconcerning GIS-integrated simulation are reviewed in chapter 3.

6

2.2 High Level Architecture (HLA)

The High Level Architecture (HLA) was developed by the US Department of Defenseand is sent to the IEEE for standardization by the Simulation Interoperability StandardsOrganisation (SISO 1998). HLA is intended to be the de facto standard for thedevelopment of interoperable simulation components in the future.

The HLA enables the execution of distributed simulations and allows single simulationcomponents to join a simulation at runtime, to exchange information with the entiresimulation and to exit it if appropriate. In the context of HLA simulation components canbe numerical models as well as real-time measurements or user interfaces.

The HLA is separated into three parts:

• The Federation Rules describe the basic rules for the development of simulation

models (federations) and their components (federates). The rules define howcomponents have to be specified and how data flow, control flow and timemanagement have to be organized.

• The Interface Specification defines a Run-Time Infrastructure (RTI) for thetechnical realization of the HLA in the sense of a black box abstraction. Theinterface specification describes classes which have to be implemented by thefederates for the interaction with each other and with the federation. Freereference implementations of the RTI are available in Java and in C++ (DOD1999).

• The Object Model Template (OMT) defines a meta language for the

documentation of the objects exchanged between Federates and Federations orused for simulation management.

A complete description of the HLA is published within the documentations of the USDepartment of Defense (DOD 1998a, DOD 1998c, DOD 1998b).

The specifications of the HLA are much more generic than the OpenGIS specifications.Basically, the current version of the HLA is comparable to a DOC architecture, whichprovides a sophisticated time and execution management for simulation components.This flexibility otherwise requires an expensive extension to support concreteapplication areas like simulation of spatio-temporal processes.

Moreover Page (1998) states, that the OMT does not enforce a structured descriptionof the meta-information of a simulation model. Exchange and use of meta-informationare not supported explicitly within HLA-based applications. Considering thedevelopment of secure-to-use and self describing simulation models further work isnecessary. This issue will be tackled by the planned implementation of a ConceptualModel of the Mission Space (CMMS, comparable to the OpenGIS InformationCommunities Model).

7

2.3 Integration of interoperable simulation and GIS components

Modern system architectures for distributed computing enable an object-orientedintegration of infrastructures for distributed simulation and service architectures fordistributed geoprocessing. However, the analysis of existing interface specifications forcorresponding service architectures shows a gap between the offered interfaces andservices in the GIS area and the requirements of the simulation area - and vice versa.

Existing GIS and emerging geodata standards are not capable of supporting three-dimensional, time-dependent processes. Concepts for modeling proceeding of timeand synchronization of data sets are missing. Whereas supporting time-variantprocesses means not only the extension of current data models and data structures -see Peuquet (1999) for an overview - but also support to formulate temporal functionaldependencies between different proceeding processes.

On the other hand known simulation tools and upcoming simulation standards neitherdeal with geodata access services nor interoperate with GIS originated processingfunctions.

Another crucial point is a possible contradiction in combining the postulation ofinteroperability with the integration approach. Integration should lead to a common,non-redundant data and method base. Interoperable components do not claim non-redundancy, but on the contrary mostly generate highly redundant data and methodpools.

A successful integration of simulation and geoinformation components only works, ifthere are common and suitable interfaces to exchange data and methods (= objects)between different frameworks and if the underlying architecture allows interoperabilityof separate components, otherwise the integration approach runs the risk of generatingnew monolithic applications. The remainder of this paper proposes a systemarchitecture and interface specifications for applications in atmospheric modeling. Thechosen application area serves as a test bed that deals with highly dynamic processesand combines the necessity of elaborated simulation techniques, the need to processhuge amounts of geodata, and the requirement of various geodata processingmethods.

3 An integrated Approach to GIS-based Simulation

The framework presented in the following sections is designed and realized in a projectthat tries to bridge the mentioned gap between interoperable GIS and simulationcomponents. This project (1996-2000) is part of a German initiative for interoperableand open geoscientific systems funded by the German Science Foundation.

After the study of user requirements and different workflows in the application area ofatmospheric modeling for environmental planning (Bernard et al. 1998b) an object-oriented framework for interoperable GIS and simulation components was designed. A

8

first prototype has been presented in Bernard et al. (1998a). A subsequent testingphase including the integration of different simulation models and the development ofanalysis tools helped to reinvestigate and reshape the system's design. This firstredesign phase is especially used to synchronize the system with the new arisen OGCabstract specifications and implementation specifications. The following passages willdocument the current concepts and components of the framework.

3.1 Architecture

The system components are organized in a layered architecture (figure 1). The grayshaded layers VirGIS and AtmoGIS are the essential parts of the proposed frameworkand will be discussed in more detail.

GIS-Kernel 1 GIS-Kernel 2 GIS-Kernel n

VirGISAbstract classes specifying a

virtual GIS API

SimulationModel 1

SimulationModel 2

SimulationModel n

Integrated Application

AtmoGISBase classes for atmospheric

simulation models and analysis tools

Figure 1: System architecture

The VirGIS layer specifies a virtual GIS application programming interface (API) to theunderlying GIS-Kernel. A GIS-Kernel is considered as a component, which managesspatio-temporal information and supports geometrical and topological queries.

VirGIS consists of a set of interface classes (abstract classes) which must beimplemented by an integrated GIS-Kernel. This way the integrated GIS-Kernelbecomes interoperable. All components which are based on the VirGIS implementationof an integrated GIS-Kernel operate on a common data and method base. As a resultan integration of the components without data redundancy or method redundancy isfeasible.

AtmoGIS is built on top of VirGIS. AtmoGIS provides base classes for the developmentof microscale and mesoscale atmospheric models and for the implementation ofanalysis tools. Following the design rules of a strictly layered architecture (Szyperski1999) AtmoGIS objects access the GIS-Kernel exclusively by the interfaces defined in

9

the VirGIS layer. Thus the VirGIS layer guarantees far reaching independence of theconcrete GIS-Kernel implementation: An exchange of the GIS-kernel does not requirean adaptation of the AtmoGIS classes or the models and tools built within AtmoGIS.

Regarding the previously discussed conflict between interoperability and integrationthis approach demonstrates a solution, but: To assure consistent data and methodmanagement the proposed framework only allows the usage of one GIS-Kernel for oneVirGIS implementation. Therefore a kind of hot plug and play - meaning the exchangeof the GIS-Kernel during runtime or the simultaneous usage of various GIS-Kernels -can hardly be realized. However, this drawback seems to be acceptable, consideringthe integration advantage of avoiding data and method redundancy in the application ofspatio-temporal simulation models. Furthermore the application of modern GIS-Kernelsthat support consistent distributed data management (e.g., ESRI's SDE or Oracle'sSpatial) helps to get around the mentioned restriction.

3.2 VirGIS

VirGIS specifies several interface classes to handle spatio-temporal data. The VirGISspecification is meant as a starting point for the development of GIS-based scientificsimulation models and provides a test bed for prototypes realizing interoperable andobject-oriented GIS-components. The presented VirGIS framework and itsspecifications do not claim to be a complete GIS environment, but are intended toprovide an understandable and extendable GIS development environment. VirGISconsists of a set of specified interface classes and of a simple referenceimplementation. Considering the application of atmospheric models the current VirGISprototype is restricted to field data. The reference implementation is intended to be apractical guideline showing how the specifications may be realized on different GIS-Kernels.

10

VgFieldInterface

VgGeometryInterface VgFeatureInterface

VgObject

VgFeatureCollectionInterface VgIteratorInterface

Figure 2: VirGIS Object Model

The class diagram (figure 2) presents an overview of the fundamental VirGIS objectmodel using the Unified Modeling Language (UML; see Fowler (1997) for an overview).The object model mirrors the OpenGIS Geodata Model as the new de facto standard:VgFeatureInterface defines the base for all classes to model spatial, temporal orspatio-temporal geoinformation and is associated with VgGeometryInterface todescribe the feature's extension in space and time. VgFeatureCollectionInterfaceextends the VgFeatureInterface and offers a container class to aggregate severalinstances of VgFeatureInterface.

VgGeometryInterface

VgFeatureInterface

VgFeatureDescriptorInterface

VgSpatioTemporalReferenceSystemInterface

VgGeometryDescriptorInterface

Figure 3: VirGIS descriptor interfaces

VgFeatureInterface and VgGeometryInterface are associated with so called descriptorsto manage elementary meta-information of the features and their geometry (figure 3).

11

VgFeatureDescriptorInterface specifies methods to query for instance the scale, therange and the units of the feature attributes. VgGeometryDescriptorInterface specifiesmethods to query information about the dimensions and associates an object todescribe the spatial and temporal reference system of a geometry. This straightforward approach allows the application to present the semantic meta-information of afeature which normally it is not capable of by using the base types (character, float,etc.) of current programming languages or database systems. TheVgSpatioTemporalReferenceSystemInterface matches the corresponding object modelfor spatial reference systems proposed in the abstract specification of the OGC (OGC1999a).

VgFieldInterface specializes VgFeatureInterface and is the base class for allrepresentations of continuous phenomena in either 2D, 3D or 4D (= 3D in space +time). According to the physical view the spatial dimensions and the temporaldimension of a field are considered equivalent. VgFieldInterface specifies two samplemethods to access the attribute values of the modeled field:

• sample(VgPoint p) returns the field's attribute value at the given point (the pointmay be 2D, 3D or 4D)

• sample(VgCell c) returns the field's attribute value aggregated for the given cellgeometry (the cell may be 2D, 3D or 4D)

Different implementations can realize the specified VgFieldInterface. Possiblesubclasses of the VgFieldInterface may realize the commonly used irregulartessellations (e.g. TIN) or regular tessellations (e.g. raster) of point sets (Laurini andThompson 1992, Burrough and McDonnel 1998, Kemp and Vckovski 1998, Molenaar1998, Streit 1999). Moreover subclasses that realize adaptive grids used in numericalfluid simulation are conceivable (Griebel and Zumbusch 1998).

The VirGIS nomenclature of field - as known from physics - differs by intention from theOGC abstract specifications that defines a coverage to describe spatial phenomena.The term coverage strongly implies the presentation of 2D phenomena, whereespecially in the context of geoscientific modeling also 3D and 4D phenomena have tobe considered.

12

VgFieldInterface

VgGridInterface

VgGeometryInterface

VgPointSamplerInterface

VgIteratorInterface

VgGridGeometryInterface

VgGridIteratorInterface

VgCellSamplerInterface

Figure 4: VirGIS grid classes

Considering the application area of atmospheric modeling our current developmentsfocus on regular grids. A grid is derived from VgFieldInterface and specified by theVgGridInterface (figure 4). A grid geometry is 2D, 3D or 4D and is described inVgGridGeometryInterface, which itself is derived from the VgGeometryInterface.VgGridGeometryInterface specifies methods to query corner coordinates and sizes ofgrid cells and methods to localize a grid cell corresponding to a given real world point.Cell sizes may be equidistant or non-equidistant in any combination. A 3D grid, forinstance, can be defined equidistant in the horizontal dimensions and non-equidistantin the vertical dimensions.

Grid implementations may use either the snapshot model or the time-stamped gridmodel to represent time-variant attributes (Langran 1992, O'Conaill et al. 1994,Voigtmann 1998, Peuquet 1999). Concentrating on the application area of geoscientificnumerical models the snapshot model seems to be preferable. Most numerical modelscalculate a new value for each grid cell in each iteration step. Thus normally all cellvalues change every time step of a simulation. Therefore the advantage of a time-stamped model concerning memory efficiency become meaningless and ispredominated by the access efficiency of the snapshot model.

Aside from these technical aspects, there is a more general consideration. Using thetime-stamped model implies that a timestamp marks a point in time where a relevantattribute change takes place. This interpretation cannot be warranted on the basis ofthe modeled continuous simulation results. It can only be warranted after the analysesof the continuous results, especially the feature extraction. Consider a grid containingsimulated air temperature as an example: It is reasonable to use the time-stampedmodel for representing the evolution of the inversion layer, once this feature isextracted from the grid of simulated air temperatures. Consequently - and in analogy tothe dualism in the raster-vector debate - as the raster model is more appropriate to

13

represent spatially continuous phenomena, the snapshot model is more suited torepresent temporal continuous phenomena.

Grids may be either cell-based or corner-based. In cell-based grids the thematicattributes are geometrically associated with the center of a grid cell and interpreted asan averaged cell value. Cell-based grids are mostly - but not only - used for categoricalinformation (Laurini & Thompson 1992, Molenaar 1998). In corner-based grids thethematic attributes are geometrically associated with a cell corner and interpreted as avalue being valid for the specific point. Thus corner-based grids are mainly used tomodel rational scaled information.

A grid is associated with an iterator object to iterate the grid's values and two samplerobjects to implement the field's sampling methods. Implementations of the samplerinterfaces should use the meta-information about the grid's semantic informationspecified in VgFeatureDescriptorInterface and VgGridGeometryDescriptorInterface. Forinstance the methods of the descriptor objects can be used to prove whether the scaleof the grid attributes is appropriate for the applied interpolation technique (figure 5).Thus misinterpretations can be prevented. Even these simple plausibility checks arerare in current GIS and mostly not easy to add (Pundt et al. 1996). However, plausibilitychecks like these are highly important to realize the often claimed intelligent GIS(Burrough et al. 1996).

14

Figure 5: Semantic plausibility checks in VirGIS

The OpenGIS grid coverage implementation specification are just available in a firstunofficial draft. So a comparison between the proposed VirGIS grid specification andthe OGC approach is not yet possible.

3.3 AtmoGIS

AtmoGIS specifies several classes to manage the input and output variables of thesimulation model and the analysis tools (AtmoLandUseGrid, AtmoDEM, etc.). Theseclasses implement the VirGIS interfaces and encapsulate the specific properties foratmospheric modeling, like the use of terrain following coordinates (Pielke 1984).

Furthermore AtmoGIS offers an extendable implementation of a simulation enginewhich organizes the simulation control. Simulation models are constructed using ascenario and a simulation engine to manage the simulation components (figure 6).

Missing semantic plausibility check in current GIS:

Incorrect visualization as a result of a linear interpolation on categorical land usedata:

Semantic plausibility check in VirGIS:

template <class T>class LinearGridPointSampler : public VgPointSamplerInterface<T> {

public:

bool init(VgGridInterface<T> gridIn) {

if (grid->descriptor()->scale() != VgFeatureDescriptorInterface::Ratio){ error ("Using linear interpolation requires ratio scaled data"); return false; }

...

15

AtmoSimulationEngineAtmoSimulator

AtmoScenario

VgGridCollectionInterfaceAtmoEngineParameter

AtmoParameter VgFeatureCollectionInterface

Figure 6: AtmoGIS scenario and engine classes

To execute a simulation an instance of AtmoScenario is created. An AtmoScenarioorganizes the initialization of the AtmoSimulationEngine. The engine manages acentral simulation timer and iterates the simulation time according to the minimalpossible timestep of all involved AtmoSimulator objects. The engine informs everyAtmoSimulator object about a time iteration by an update message. Receiving anupdate message a simulator object needs to decide whether a recalculation of theoutput variables is necessary or not. Moreover a simulator object needs to determine anew time increment, which corresponds with the stability criteria of the simulator.

AtmoSimulator

VgGridCollectionInterface

AtmoComplexSimulator

AtmoParameter

input /output

Figure 7: AtmoGIS simulator classes

An AtmoSimulator object manages input and output variables that are derived from theVgGridCollectionInterface and therefore directly access the GIS-Kernel via the VirGISinterface (figure 7). AtmoGIS contains a pool of specialized simulator classes (grid-based numerical solvers, boundary treatment, etc.). Simulator objects can be groupedin an AtmoComplexSimulator to represent model hierarchies.

16

AtmoSimulator

AtmoReporter

AtmoSimulationEngine

AtmoDescriptor AtmoScenario

Figure 8: AtmoGIS descriptor and reporter classes

The AtmoGIS simulation objects are associated with a descriptor object (figure 8). Inthe current version the characteristics of the AtmoGIS objects are described in a textualform only. These meta-information describing the simulation components can becollected by an AtmoGISReporter and document the simulation model to the modeluser. Future work focuses on the formal description of the properties. Thus meta-information about the semantics of the simulation components will becomeinterpretable inside an application and usable for appropriate consistency andplausibility checks (e.g. for constraints like: simulator X assumes a spatial resolutiongreater than Y, etc.).

4 A prototype - Applications using the Framework

A prototype implementation of the framework is realized as a C++ class library. Severalprototype applications using atmospheric models with different simulation strategieshave been developed to prove the achieved interoperability of the AtmoGIS layer. Afirst example application to evaluate nocturnal cold air flows integrates a mesoscalehydrostatic boundary layer model. A second application for emission assessment hasbeen realized by the integration of a dispersion model based on cellular automata.

The interoperability of the VirGIS layer is demonstrated by two different prototypes.One implementation interfaces a GIS-kernel based on a flat file system. A secondimplementation uses an object-oriented geodata model on top of a commercialOODBMS (Becker et al. 1998). The file system based implementation supports theNetCDF format (Rew et al. 1997), a platform independent, generic interchange fileformat for atmospheric data sets. This implementation uses the factory pattern(Gamma et al. 1995) to create instances of the interface objects and to ease theaddition of other file formats.

The VirGIS interface is also used to integrate the visualization toolkit MAM/VRS(Döllner and Hinrichs 1997). The use of mediator classes enable the visualizationobjects to directly interact on VirGIS and AtmoGIS objects and to minimize dataconversion.

17

4.1 S_KIMO – a cold air flow model based on Eulerian equations

S_KIMO is a dynamic 3D mesoscale boundary layer model. The model is intended tostudy nocturnal ventilation of urban areas and to asses different urban planningscenarios.

The model is based on the simple formulation of the equations of motion, assuminghydrostatic and incompressible flows. The equations are formulated in terrain followingcoordinates. S_KIMO simulates the temporal and spatial distribution of the nocturnalwind speed, wind direction, temperature, humidity and turbulence. The model variablesare placed on a staggered 4D grid. The equations are solved using explicit differences.S_KIMO uses the variables and simulation management offered by AtmoGISextensively and thus demonstrates the use of object-orientation for the development ofatmospheric models.

The following sample code shows how the integration of S_KIMO components inAtmoGIS is realized:

18

The class SkimoImpulsConservation specializes the AtmoComplexSimulator. Theexample shows the initialization of different simulation components which realize theimpulse conservation equation in S_KIMO. The replacement of a simulator componentin SkimoImpulsConservation only requires the exchange of the simulator object in theshown init() method (e.g., to use another boundary scheme replaceAtmoNeumannBoundaries by AtmoRadiationBoundaries). Thus the sample codeshows how the idea of a plugable - and therefore easily modifiable and extendible -simulation model is realized on base of AtmoGIS. Furthermore the example indicates

class SkimoImpulseConservation : public AtmoComplexSimulator {

//...

bool SkimoImpulseConservation::init() {

// The simulators are created and added in the order they should be // updated in the incrementTime method.

// Pressure Gradient in X (dp/dx):

simulators_.append(new SkimoPressureGradient( inputVariables_, ouputVariables_, new SkimoGradientParameters(AtmoThemes::PressurePerturbation, AtmoThemes::U, parameters_.borderCells(),parameters_) ) );

// Coriolis force in X:

simulators_.append(new SkimoCoriolisForce( inputVariables_, ouputVariables_, new SkimoGradientParameters(AtmoThemes::V,AtmoThemes::U, parameters_.borderCells(), parameters_) ) );

// Advection Of U (u * du/dx), using an AtmoGIS solver:

simulators_.append(new AtmoDonorCellSchemeStaggered( inputVariables_, ouputVariables_, new AtmoGradientParameters(AtmoThemes::U,AtmoThemes::U, parameters_.borderCells())) );

//....

// Neumann boundaries are applied:

simulators_.append(new AtmoNeumannBoundaries( inputVariables_, ouputVariables_, new AtmoGradientParameters(AtmoThemes::V,AtmoThemes::V, parameters_.borderCells())) );

//...

// Check simulators init() methods:

VgListIterator< AtmoSimulator > simIterator = simulators_.newIterator();

do { if (! simIterator.current().init() ) { return false; // initializing failed } simIterator.next(); } while (simIterator.valid());

return true // initializing succeeded;

}

//...

}

19

how the simulation model becomes transparent by the applied object-orientedapproach.

Figure 9: S_KIMO results for an idealized valley

Figure 9 shows S_KIMO results for the simulation of air flows in an idealized valley.The vertical slice maps the simulated air temperatures. The simulated nocturnal nearground drainage wind flows are shown by the arrows. The results are visualized in ananalysis and visualization tool developed utilizing AtmoGIS.

4.2 PDCA – a cellular automata based air pollutant dispersion model

Cellular automata first introduced by von Neumann (1966) are composed of a gridconsisting of cells, a set of possible states of one cell, a neighborhood surrounding onecell and a local transition function determining the next state of a cell dependent on theneighboring cells within an update step (Wolfram 1984a, Toffoli and Margolus 1987).These completely discrete components are well suited to be used for computersimulations and are at the same time capable to represent a great variety of spatio-temporal processes (Hogeweg 1988, Barca et al. 1994, Itami 1994, Goncalves andDiogo 1995, Couclelis 1999).

To model the dispersion of air pollutants a special class of cellular automata is used,called lattice gases (Hardy et al. 1976, d'Humieres et al. 1986, Frisch et al. 1986)(Boghosian 1999). Lattice gases model a gas by particles of a uniform mass, which are

20

moving on a grid from one cell to another. On a two-dimensional orthogonal grid aparticle may move to the four adjacent neighbor cells. On a three-dimensional gridthere are six possible directions, respectively. A moving particle changes its directiononly by a collision with another particle entering a cell out of the opposite direction. Thisdiscrete microscopic behavior of particles on a lattice is able to simulate continuousmacroscopic properties of a real gas, such as diffusion and streaming, byapproximating the hydrodynamic laws (Wolfram 1986, Rivet et al. 1988). The initial flowof the lattice gas is reproduced by increasing the number of particles following thegiven wind direction of a superior wind field. Modeling a two phase gas, like a mixtureof a gas and a pollutant, is enabled by marking the emitted pollutant particles (Appert etal. 1995). All possible states of a cell in a lattice gas are represented by a small set ofbinary values and all actions of the particles are performed by simple binary operations.

The generic integration of cellular automata with AtmoGIS is performed by subclassingthe AtmoSimulator class of AtmoGIS (figure 10) and inherits the update controlimplemented within AtmoGIS. The class CACellularAutomata is composed of the classVgGridInterface storing the current and the next state of the cellular automata, theclass CAStateSet as a container for the possible cell states, the classCANeighborIterator for iterating the states of the neighbor cells of a current cell and theclass CALocalFunction, realizing the update of one cell.

AtmoSimulator

CaCellularAutomata

CALocalFunction CAStateSet

CANeighborIterator

CAStaten

VgGridInterface

PDCALatticeGas PDCAParticleCellPDCAParticleMotion

VgGridIteratorInterface

Figure 10: Subclassing of AtmoGIS base classes for integration of cellularautomata

The implementation of the update method by the class CellularAutomata applies theabstract execute method of the class CALocalFunction to each cell of the owned grid inorder to compute the next state of all cells. The implementation of the execute methodshould use the CANeighborIterator to detect the states of the neighbor cells and to findthe new state out of the CAStateSets container. A complete synchronous update of the

21

whole grid executing the update method of the class CACellularAutomata is shown bythe following code segment:

In contrast to other concepts of coupling cellular automata with GIS (Park and Wagner1997), which are use an operation handler and a data translator to pass informationfrom a hosting system to the cellular automata simulator, this approach is completelyintegrated within AtmoGIS by using the same data access methods and the same timemanagement as other simulators in AtmoGIS. As a result cellular automata could easilybe synchronized with instances of various additional simulators in AtmoGIS.

The time processing of the whole system within a simulation is managed by aninstance of the class AtmoSimulatorEngine (see 3.3). Normally the real-time step of acellular automata simulator is not known, because it computes discrete step afterdiscrete step independently from the passed real-time. Therefore, to synchronize acellular automata with other simulators it is necessary to compute an appropriate realtimestep by evaluating initial or boundary values of the simulation. Considering theapplication area of atmospheric pollutant dispersion and using the Courant-Friedrich-Levi criterion the maximum timestep is given by the resolution of the grid and themaximum speed of the corresponding wind field.

The generic integration of cellular automata with AtmoGIS realized by the describedpackage can be easily used to develop a lattice gas for atmospheric pollutantdispersion (PDCALatticeGas). The special properties and the behavior of particles on alattice are realized by defining the possible states of a cell (PDCAParticleCell) andimplementing the execute method of CALocalFunction by its subclassPDCAParticleMotion. This method performs the movement and the collision step of a

VgGridInterface<T> grid_; //simulation grid

CALocalFunction<T> function_; //local function (abstract)

CANeighborIterator<T> gridItr_; //iterator for cell neighbors

...

template <class T>

void CACellularAutomata<T>::update(const AtmoSimulationTime& time){

gridItr_->restart();

... //set iterator to current step

VgIndex cur(grid_->dataDimension());

do{

cur = gridItr_->currentIndex(); //detect the current cell

T state = function_->execute(); //computing the next state

... //increment time index

grid_->setRawData(cur, state); //set new state to grid

gridItr_->next(); //next cell

}

while(gridItr_->valid());

}

22

particle on the lattice. Instances of these specialized classes are able to compute thedevelopment of particle distributions based on the initial state of the system.

Different representations of the gathered quantities (e.g. pollutant concentrations)within the context of the cellular automata (particles as bits) and the values normallyused for analysis (quantities as floating point values) require an extension of thecellular automata. In order to bridge the gap between the continuous input and outputvariables and the binary simulation grid, an adapter for aggregation and disaggregationof the quantities is introduced. The adapter represents a control volume of thecontinuous grid by a predefined number of cells of the cellular automata grid (Toffoli1984). Using this relationship the adapter is able to map between particle dispersionsand pollutant concentrations.

Figure 11: PDCA results for an idealized city

Figure 11 shows a pollution scenario simulated by PDCA for an idealized city. Theresults are again visualized in an AtmoGIS application. The emission source is placedsouth-west of the tall building. The superior wind direction is west with a speed of

20.0 m⋅s-1. The results show the channeling of the emission plume due to the buildings

distribution.

23

5 Conclusions

There are several upcoming standards and technologies, which promote the integrationof simulation tools with services for geodata management and processing. Thechallenge of the next decade will be to put them together and to develop interoperable,distributed, reusable and scaleable software components based on the specifiedinterfaces. Thus the arising architectures and service infrastructures will make it mucheasier and more flexible to model spatio-temporal processes.

This paper shows the usability of the object-oriented paradigm even for atmosphericmodeling, where traditionally procedural simulation models prevail. Considering thebenefits of distributed reusable and interoperable simulation components with thepotential to access a GIS service architecture this approach could be an alternative toconventional strategies for modeling and simulation within geoscientific applications.

Existing specifications do not completely match the requirements of GIS-integratedprocess modeling. The OpenGIS specifications should pay more attention to threedimensional, time-dependent processes while the HLA specifications should beextended for support of geodata interfaces as a domain specific object model.

The proposed VirGIS and AtmoGIS frameworks encourage the consideration of specialissues for the integration of GIS and simulation models. This will lead to basic typesand strategies required by interoperable and extendable components for GIS-integrated process modeling and simulation.

Our future work is directed to the development of a distributed system based on theprototype, the concepts and interfaces described in this paper. One precondition is todesign and implement patterns for a hot plug and play of distributed GIS kernels andsimulation models as envisaged by HLA federates and federations.

Consequently a next step in our research will be the support of model development in adistributed environment including the use of visual languages to plug in existingsimulation models and to design hierarchical models. The extensive use of meta-information describing the simulation components and the involvement of formalsimulation component descriptions will enable the development of intelligent simulationtools in the future.

24

Acknowledgement

The presented works were carried out under the "(3+1)D-GIS" project, funded by theGerman Science Foundation grant no. STR 172/8-1.

Furthermore, we would like to thank Yaser Bishr, Sven Fuhrmann, Hardy Pundt, BennoSchmidt, Kristian Senkler and the anonymous reviewer for their advice and time.

25

References

Appert C, Olsen J F, Rothman D H, and Zaleski S 1995 Phase separation in a three-dimensional, two-phase, hydrodynamic lattice gas. Journal of Statistical Physics 81(1/2): 181-

197.

Barca D, Crisci G M, Gregorio S, and Nicoletta F 1994 Cellular automata for simulating lavaflows: A method and examples of Etnean eruptions. Transport Theory and Statistical Physics

23(1-3): 195-232.

Becker L, Ditt H, Döllner J, Hinrichs K, Reiberg J, and Voigtmann A 1998 Building an

Interoperable GIS: Integration of an Object-Oriented GIS Database Kernel and a VisualizationFramework. In Proceedings of the 8th International Symposium on Spatial Data Handling.

Vancouver, International Geographical Union: 386-395.

Bernard L, Schmidt B, and Streit U 1998a AtmoGIS - Integration of Atmospheric Models andGIS. In Proceedings of the 8th International Symposium on Spatial Data Handling. Vancouver,

International Geographical Union: 267-276.

Bernard L, Schmidt B, Streit U, and Uhlenküken C 1998b Managing, Modeling, and Visualizing

High-Dimensional Spatio-Temporal Data in an Integrated System. Geoinformatica 2(1): 59-77.

Bishr Y 1997 Semanic Aspects of Interoperable GIS. Enschede, Wageningen

Landwirtschaftliche Universität.

Boghosian B M 1999 Lattice Gases and Cellular Automata. http://xxx.lanl.gov/abs/comp-

gas/9902002.

Buehler K and McKee L, (eds) 1998. The OpenGIS Guide. Wayland, Open GIS Consortium

Technical Committee.

Burrough P A and McDonnel R A 1998 Principles of Geographical Information Systems. New

York, Oxford University Press.

Burrough P A, van Rijn R, and Rikken M 1996 Spatial Data Quality and Error Analysis Issues:

GIS Functions and Environmental Modeling. In M F Goodchild, L T Steyaertand B O Parks (eds)GIS and Environmental Modeling: Progress and Research Issues. Fort Collins, GIS World

Books: 29-34.

Couclelis H 1999 Space, Time, Geography. In P A Longley, M F Goodchild, D J Maguireand DW Rhind (eds) Geographical Information Systems - Principles and Technical Issues. New York,

John Wiley 1: 29-38.

Cuthbert A 1999 OpenGIS. Tales from a Small Market Town. In Proceedings of the International

Conference "Interoperating Geographic Information Systems" INTEROP'99. Zurich, Springer:

17-28.

d'Humieres D, Lallemand P, and Frisch U 1986 Lattice gas models for 3D hydrodynamics.

Europhysics Letters 2(4): 291-297.

DOD 1998a High-Level Architecture, Interface Specification, Version 1.3. U.S. Department of

Defense. IEEE P1516.1.

DOD 1998b High-Level Architecture, Object Model Template Specification, Version 1.3. U.S.

Department of Defense. IEEE P1516/D2.

26

DOD 1998c High-Level Architecture, Rules, Version 1.3. U.S. Department of Defense. IEEE

P1516.

DOD 1999 RTI 1.3-Next Generation Programmer’s Guide. U.S. Department of Defense.

Döllner J and Hinrichs K 1997 Object-oriented 3D Modeling, Animation, and Interaction. The

Journal of Visualization and Computer Animation 8(1): 33-64.

Fedra K 1996 Distributed Models and Embedded GIS: Integration Strategies and Case Studies.In M F Goodchild, L T Steyaertand B O Parks (eds) GIS and Environmental Modeling: Progress

and Research Issues. Fort Collins, GIS World Books: 413-418.

Fortheringham A and Wegener M, (eds) 2000. Spatial Models and GIS - New Potential and

New Models. GISDATA. London, Taylor & Francis.

Fowler M 1997 UML Distilled. Reading, Addison Wesley.

Frisch U, Hasslacher B, and Pomeau Y 1986 Lattice-gas automata for the Navier-Stokes

Equation. Physical Review Letters 56(14): 1505-1508.

Gamma E, Helm R, Johnson R, and Vlissides J 1995 Design Patterns - Elements of Reusable

Object-Oriented Software. Reading, Addison Wesley.

Goncalves P and Diogo P M 1995 Geographic information systems and cellular automata: Anew approach to forest fire simulation. In Proceedings of the European Conference on

Geographical Information Systems: 702-711.

Goodchild M F, Parks B O, and Steyaert L T 1993 Environmental Modeling with GIS. New York,

Oxford University Press.

Goodchild M F, Steyaert L T, and Parks B O 1996 GIS and Environmental Modeling: Progress

and Research Issues. Fort Collins, GIS World Books.

Griebel M and Zumbusch G 1998 Hash-Storage Techniques for Adaptive Multilevel Solvers and

Their Domain Decomposition Parallelization. Contemporary Mathematics 218: 279-286.

Hardy J, de Pazzis O, and Pomeau Y 1976 Molecular dynamics of a classical lattice gas:

Transport properties and time correlation functions. Physical Review A 13(5): 1949-1961.

Hogeweg P 1988 Cellular automata as a paradigm for ecological modelling. Applied

Mathematics and Computation 27: 81-100.

IEEE I o E a E E 1990 IEEE Standard Computer Dictionary: A Compilation of IEEE Standard

Computer Glossaries. New York.

Itami R M 1994 Simulating Spatial Dynamics: Cellular Automata Theory. Landscape and Urban

Planning 30: 27-47.

Kemp K and Vckovski A 1998 Towards an ontology of fields. WWW document, CD-ROM

Langran G 1992 Time in Geographic Information Systems. London, Taylor & Francis.

Laurini R and Thompson D 1992 Fundamentals of Spatial Information Systems. London,

Academic Press.

Microsoft 1998 Distributed Component Object Model Protocol. Microsoft Corporation.

27

Molenaar M 1998 An Introduction to the Theory of Spatial Object Modeling for GIS. London,

Taylor & Francis.

Nyerges T L 1992 Coupling GIS and Spatial Analytic Models. In Proceedings of the 5th

International Symposium on Spatial Data Handling. Charleston, USA, IGU Comission on GIS:

524-533.

O'Conaill M A, Mason D C, and Bell B M 1994 Spatiotemporal GIS techniques for environmentalmodelling. In P M Mather (eds) Geographical Information Handling - Research and Applications.

West Sussex, John Wiley & Sons: 103-113.

OGC 1998 OpenGIS Simple Feature Specification for CORBA, Revision 1.0. WWW document,

http://www.opengis.org

OGC 1999a The OpenGIS Abstract Specification. WWW document, http://www.opengis.org

OGC 1999b OpenGIS Simple Feature Specification for OLE/COM, Revision 1.1. OpenGIS

Project Document 99-049. WWW document, http://www.opengis.org

OGC 1999c OpenGIS Simple Feature Specification for SQL, Revision 1.1. OpenGIS Project

Document 99-049. WWW document, http://www.opengis.org

OMG 1998 The Common Object Request Broker: Architecture and Specification, Revision 2.2.

WWW document, http://www.omg.org

Page E 1998 The rise of web-based Simulation: Implications for the High Level Architecture. In

Proceedings of the Winter Simulation Conference. Washington: 1663-1668.

Park S and Wagner D F 1997 Incorporating cellular automata simulators as analytical engines

in GIS. Transactions in GIS 2(3): 213-231.

Peuquet D J 1999 Time in GIS and geographical databases. In P A Longley, M F Goodchild, DJ Maguireand D W Rhind (eds) Geographical Information Systems - Principles and Technical

Issues. New York, John Wiley 1: 91-103.

Pielke R A 1984 Mesoscale Meteorological Modeling. London, Academic Press.

Pundt H, Hitchcock A, Bluhm M, and Streit U 1996 A GIS supported Freshwater InformationSystem including a Pen-Computer Component for digital field data recording. In Proceedings of

the HydroGIS 96 - Application of GIS in Hydrology and Water Resources Management. Vienna,

IAHS: 703-711.

Rew R, Davis G, Emmerson S, and Davies H 1997 NetCDF User's Guide for C. WWW

document, http://www.unidata.ucar.edu/packages/netcdf/guidec/

Rivet J-P, Henon M, Frisch U, and d'Humieres D 1988 Simulating fully three-dimensional

external flow by lattice gas methods. Europhysical Letters 7(3): 231-236.

SISO 1998 Simulation Interoperability Standards Organisation. WWW document,

http://siso.sc.ist.ucf.edu/

Streit U 1999 Einführung in die Geoinformatik. WWW document, ifgi.uni-muenster.de

SUN 1999 The Java Tutorial. WWW document, http://java.sun.com/docs/books/tutorial

Szyperski C 1999 Component Software - Beyond Object-Oriented Programming. Harlow,

Addison-Wesley.

28

Toffoli T 1984 Cellular Automata as an alternative to (rather than an approximation of)

differential equation in modelling physics. Physica D 10D: 117-127.

Toffoli T and Margolus N 1987 Cellular automata. A new environment for modelling. Cambridge,

Ma, MIT Press.

Voigtmann A 1998 An Object-Oriented Database Kernel for Spatio-Temporal Geo-Applications.

Institut für Informatik. Münster, Westfälische Wilhelms-Universität.

von Neumann J 1966 Theory of self-repoducing automata. Urbana, London, University of Illinois

Press.

Wolfram S 1984a Cellular automata as models for complexity. Nature 311: 419.

Wolfram S 1986 Cellular automaton fluids: Basic theory. Journal of Statistical Physics 45: 471-

526.