Development of a Computer Aided Geographic

Development of a Computer Aided Geographic Database Design System Marcos Antonio Vaz Salles, Fatima Pires, Claudia Bauzer Medeiros fmarcovaz,fpires,[email protected]

IC - UNICAMP - CP 6176 13081-970 Campinas SP Brazil

Juliano Lopes de Oliveira

[email protected] Instituto de Informatica - UFG - CP 131 Goi^ania, GO Brazil Abstract

This paper presents a prototype being developed at IC-UNICAMP to help environmental planners specify their application databases. The ultimate goal of the system presented is to reduce the impedance mismatch between the end-user's view of the geographic reality and its implementation in Geographic Information Systems (gis). The prototype oers users the possibility of specifying their application databases using concepts closer to their view of the world, by means of an object oriented geographic data model. This speci cation is mapped by the system to an intermediate object oriented schema, which can then be transformed into dierent underlying target geographic DBMS. The prototype was implemented using C and O2C on the O2 object oriented DBMS.

1 Introduction A Geographic Information System { gis, for short { is a software that performs data management and retrieval operations for georeferenced data. The term refers to data about geographic phenomena associated with its location, spatially referenced to the Earth [Car89]. gis are being increasingly used for a variety of purposes, serving as a development platform for a wide range of applications { from urban to environmental planning. Each type of application deals with dierent features, scales and spatio-temporal properties. gis normally rely on a dbms for most data management operations. However, the dbms is totally encapsulated within a proprietary system. More often than not, such systems require from users training in database design and in management of low level data structures. Since users seldom have a computer science background, this hampers considerably the ecient 1

use of gis. The gis database is frequently poorly designed, disregarding data sharing and database evolution. This, in turn, increases the cost of developing geographic applications, since users keep creating an entirely new database and duplicating data sources every time a new application is needed, even when basically the same data and schema could be used. In order to diminish this problem, the database research group at UNICAMP is developing an object oriented database-centered environment, called UAPE (geo-User Analysis and Project Environment) [OPM97]. The name of the environment re ects its functionalities. UAPE is an indian Guarany word for a water lily of the Amazon area under whose huge leaves thrives a complex ecosystem. Analogously, UAPE presents to its users a nice interface to help manipulate the complex structures of gis. UAPE allows users which work in environmental planning (e.g., geographers, biologists, ecologists) to design their application databases using concepts closer to their understanding of the world, and to reuse available databases. The result of the design phase is mapped to an intermediate object oriented database which, in turn, can be transformed into dierent target gis geographic dbms, by means of special purpose translators. UAPE is based on three main building blocks:  a geographic object oriented data model, GMOD, which allows users to de ne their databases in terms closer to their daily work concepts;  an environmental application design methodology, which guides the user through the database speci cation steps. This methodology for designing environmental applications has been developed at UNICAMP and validated by end-users, for distinct application domains, in 1996-1997  an object oriented database, which represents an intermediate storage and speci cation level between the user de nitions and the underlying geographic dbms. This paper presents the rst version of the implementation of UAPE. This prototype basically consists of a set of tools for helping the user (1) design a geographic database using GMOD and (2) browse existing data sources, to integrate them into the design. The methodology, embedded into the system, prompts the user along design steps, helping ensure proper documentation of design decisions. UAPE was proposed as part of a PhD. thesis [Pir97]. The design and development of UAPE's interface is part of another PhD thesis [Oli97, OM95] The prototype integrates results from several MSc dissertations { [CM97, Cer96, MB96, MC95]. The remainder of this paper is organized as follows. Section 2 outlines the GMOD data model. Section 3 introduces the UAPE architecture and the prototype. Section 4 shows, through a real application, how UAPE can be used. Section 5 presents conclusions and future work.

2 The geographic data model GMOD This section describes GMOD { the object oriented geographic data model adopted in UAPE. Spatial data modeling is still a challenge (e.g., [Fed93, Goo92]). The early models emphasized

primarily the structures to support data geometry and topology. More recently, models try to abstract features related to a given geographic area, with preponderance of object oriented proposals (e.g., [PMP93, Wor94, RL95]). Most models, however, are static and, furthermore do not take temporal evolution into account. Dynamic modeling is treated from a purely mathematical point of view (e.g., [Fed93]), without considering the existence of a database. GMOD is the result of several years working with users in the area of environmental applications. It was conceived having in mind letting environmental users de ne their applications using concepts closer to their view of the world. It diers from the majority of the geographic data models recently proposed in the literature (e.g., [Wor94, Pim95]) for the following reasons:  it allows not only the usual static modeling, but also process and dynamic modeling, essential to implement the constraints and functions necessary to manage data evolution in georeferenced applications;  it supports the speci cation of spatio-temporal data and their relationships;  following [Cam95, CFS+ 94], it makes a clear distinction between conceptual modeling of geographic data and their dierent representation schemes. GMOD is based on three main concepts: classes (in the sense of an object oriented model); relationships, which allow connecting the classes in several ways; and constraints, which are imposed on classes, relationships and their instances. Classes may be temporal or atemporal, according to whether or not their instances are allowed to vary with time. Figure 1 shows the basic class structure using OMT notation [Rum91]. Three additional (shaded) classes appear in the gure. They are not part of GMOD. Rather, they are added to support some of the needs of UAPE. These classes are discussed in Section 3. Instances of classes Rule, Process and Document may be associated with instances of all other classes. This is denoted in the gure by the thicker association lines, thus simplifying the notation.

2.1 Static Modeling

The class structure of GMOD extends the proposal of [Cam95] with relationships and temporal facilities. There are two basic classes: Geo-Classes, whose instances are objects with some spatial component (Geo-Regions), and Conventional classes, that describe real world entities that are not georeferenced. For instance, an agricultural planning application may need to handle information about about sugar cane species (e.g., genealogy), or fertilizers (e.g., nitrate content). This information, not georeferenced, is stored in Conventional classes. Eventually, instances of these classes may be associated with instances of geo-classes (e.g. a sugar cane plantation will be described by an instance of a complex geo-class which has a conventional component describing crop properties). This distinction between conventional and geo-classes allows dierent applications to share non-spatial data, and helps application design and data reuse. The spatial dimension of Geo-Class instances is modeled by instances of the Geo-Region class, which describes regions of the Earth surface. Geo-Classes can be further specialized into classes of Geo-objects and Geo- elds, which allow users to model the world according to

Project Document Study Area

1+ InfoLayer Relationship

P

Conventional

P

1+

1+ Geo-Region

Representation

Geo-Class Aggregation Relat.

Atemporal Conventional

Time

Generalization

Atemporal Geo-Class

Association Geo-Object

Geo-Field Version

Process

Causal

Rule

Figure 1: GMOD - basic classes a respectively discrete or continuous perspective of the phenomena. An instance of a GeoClass may be associated to many instances of the class Geo-Region and their Representations. This allows, for example, dierent spatial descriptions for one given real world entity, varying on scale, projection, accuracy or even type of device used in the data capture phase. In order to allow modeling of time, GMOD introduces another class hierarchy (not shown in the gure), rooted at class Time. Subclasses of this class model distinct types of time characteristics (e.g. discrete versus continuous, stepwise versus line variation and so on). Atemporal data may acquire temporal properties by composition with Time hierarchy objects. Most geographic data models ignore the possibility of modeling relationships among real world phenomena. GMOD is concerned with ve main relationship types that can be expressed by the user: generalization/specialization, aggregation, association, versioning and causal. The causal relationship will be described within dynamic modeling (section 2.2). The model covers the following user relationships:  scalar - those that associate entities in a prede ned ratio;  conceptual or qualitative - those that are considered in a conceptual level, and,  mathematical or quantitative - those that are de ned as formulae or functions. Generalization/specialization and aggregation relationships are directly supported by the object oriented notions of the same name. Users treat aggregations as \part-of" relationships. Associations correspond to general relationships in ER models, allowing users to establish dierent types of connections among entities { e.g., woods and paths across them. Versioning relationships allow users to determine connections among versions of a single concept (e.g., historical evolution). Furthermore, versioning allows connecting distinct scenarios which have been derived, for the same region, for a given planning project.

2.2 Dynamic Modeling

Dynamic modeling is the key issue in simulations executed by environmental applications users. However, data model proposals ignore this requirement. Dynamic modeling abstracts the temporal behaviour of the geographic phenomena considered in an application. Users generally state this modeling in terms of a chain of events that trigger changes in geographic entities through pre-de ned actions, under certain conditions. This, in most cases, can be supported by active database mechanisms. Thus, dynamic modeling in GMOD is based on the class Rule. A rule instance is represented by a tuple with three components: event, condition and action. This is coherent with the classical approach that represents dynamic modeling aspects using nite state machines. Besides supporting speci cation of the world dynamics, rules can also be used for speci cation of integrity constraints [MC95]. Causal relationships are de ned during design modeling. They model cause-eect chains among modeled phenomena. For instance, the soil type of a given area directly aects vegetation characteristics. Causal relationships are common in environmental studies where the in uence of human activities is studied according to their impact on nature. Causal relationships may be global or local, and their speci cation is fundamental to an appropriate process model. In some cases, they correspond to (dynamic) integrity constraints.

2.3 Process Modeling

Environmental processes in the real world are typically temporal and complex. Processes are de ned by a set of operations that perform computations or updates over stored data. Environmental processes are mainly embedded in mathematical or quantitative relationships. For instance, land surface rainfall-runo modeling relies heavily on ow mechanics equations, which are stated to formalize the corresponding processes. After a storm, the parameters that describe the current water ow must be revised and updated. This is accomplished by the execution of mathematical models that consider the water ow in the surface before and after the rain (temporal evolution), besides considering other factors like declivity and evaporation potential. GMOD uses class Process for the speci cation of these processes. A Process instance is de ned basically as a tuple with the name of the process, the input and output data parameters, the function that has to be executed and the constraints that ensure the process' reliability and usefulness. Class InfoLayer allows modeling (process-derived) views of a study area, according to dierent user needs. Instances of InfoLayer are derived from instances of Conventional and Geo-classes, indicated in gure 1 by symbol P (i.e., they are obtained by Process modeling). For instance, land use may be computed by combining data on vegetation, hidrography, man-made constructions, relief and economic activity of a region.

3 UAPE - architecture and implementation

3.1 Database organization

UAPE has been conceived as a software layer to be coupled to a gis (see gures 2 and 3). This layer has its own database (UAPEDB), which corresponds to an intermediate storage system, allowing translation between the underlying gis database (GISDB) and user concepts and data modeled using GMOD. UAPEDB can be shared by several gis, by means of import/export drivers (see bottom of gure 3). UAPEDB is logically partitioned into three databases:  ImpDB - contains data and schema imported upon user request from the gis database GISDB. This allows reuse of previously entered data and schemata.  ApDB - contains data and schema de ned for the new application, to be eventually migrated into GISDB.  AmbDB - contains data and schema speci c to UAPE (e.g., GMOD class de nitions). In order to design an application database using GMOD in UAPE, it is necessary to add three new database classes to document the context of the application being designed (see shaded boxes of Figure 1). These classes are part of AmbDB. They are not inherent to user modeling procedures, which is why they are treated apart from GMOD basic classes. Class Project instances store the description of the problem and the objectives of the application. Class Study area instances describe the spatial extension over which the geographic application shall act. A project is associated with only one study area. Class Document allows users to record documentation about modeling decisions. For instance, environmental users will want to describe the mathematical models employed and assumptions made in using these models. UAPE

ImpDB

GIS

ApDB

AmbDB

UAPEDB

GISDB

Figure 2: UAPE database partitions The classes in ImpDB and ApDB are de ned as subclasses of those in AmbDB. Import Drivers translate UAPE requests into queries to the particular gis. Export Drivers map the ApDB schema into that of GISDB. Two points must be made here. First, drivers are gis dependent and thus must be hard-coded into the interface between UAPEDB and GISDB. Second, GMOD is semantically rich and allows de ning several properties which may not be supported by the underlying gis (e.g., temporal data). In this case, the user is warned by UAPE at export time.

3.2 Software modules and their implementation

Figure 3 outlines the software architecture of UAPE, which consists of six basic modules. The architecture is organized in three layers. The rst one, the user interface, deals with higher level abstractions, enabling the dialog between the user and the environment. The second layer encapsulates the modules responsible for supporting user activities of database Modeling and design and data Retrieval and Manipulation. Both activities are coordinated by the Methodology Advisor, which encapsulates the application design methodology designed for UAPE. Finally, the third layer encapsulates UAPEDB and the data and schema translation drivers responsible for the communication with the underlying gis.

User

User Interface

Modeling and Design

GIS

Import/Export Drivers

Retrieval and Manipulation

Methodology Advisor

UAPEDB

Figure 3: UAPE modules - logical view In the present implementation, UAPEDB is built using the O2 OODBMS. Implementation characteristics are as follows: 



Interface module: oers a direct manipulation interface. Its main task is to provide facilities to model and design the application database using GMOD, under the methodology. Some of the graphical characteristics of the interface are shown in the screen shots described in section 4. The architecture of the interface is based on [Oli97], and was implemented extending the work of [OA93]. Modeling and design module: it is responsible for managing static, dynamic and process modeling. In the present implementation, the user can perform static modeling and InfoLayer speci cation. Dynamic and process modeling is still restricted to speci cation of Rule and Process class instances, their association to other existing classes, and de nition of object oriented methods. Temporal classes are not supported by the prototype, but the temporal data management feature has already been nished and will be incorporated [FMN98]. Users are prompted to specify the schema through help of an interactive tool (see Section 4).







Retrieval and manipulation module: responsible for retrieving and manipulating data imported into ImpDB from GISDB. The retrieval module was implemented by coupling the open interface GOODIES [OA93] to O2. Two main types of interaction are presently available: extension (instance) queries, that permit the visualization of the data in UAPEDB, and exploratory queries, that permit the navigation over the database schema and instances. Both conventional and spatial (cartographic) presentations are available. Data manipulation operations (e.g., updates or spatial analysis operations) are not yet implemented. Methodology advisor module: responsible for aiding the user in modeling and design activities, according to the methodology described in [Pir97, OPM97]. This module was not implemented apart. Instead, in this rst version, it was embedded into the Modeling and design module. Thus, it is the latter module that directly guides users through the design steps, prompting them to provide relevant information (e.g., by requesting instantiation of Document instances or to provide Relationship information). Since the methodology applies only to modeling and design, this simpli cation is not as harmful to the modularity of the architecture as it may seem. Export/import driver modules: responsible for translating UAPEDB schema and data to/from DBGIS. Not yet implemented. All tests of UAPE have so far been conducted by importing available geographic data directly into UAPEDB.

UAPE prompts the user to design UAPEDB (ApDB) according to the steps of the environmental application design methodology de ned in [Pir97]. The methodology re ects the work patterns of users that work in environmental applications, mapping them into software engineering application design procedures. It considers four basic phases: planning, inventory, development and evaluation. Planning corresponds to all activities performed prior to any software use, and which are documented as objects of the Document class { de nition of objectives, determination of area to be studied, speci cation of an environmental analysis methodology etc. Inventory is the phase of speci cation of data to be collected, their quality parameters and is complemented by data gathering. Inventory is partially supported in the prototype by letting users browse through existing data sources, thereby enabling data reuse. Furthermore, users may also go through other projects' documentation instances, which helps de ning their databases when similar problems are found. Development corresponds to database modeling followed by running simulation (process) models on the gis. This second activity is not expected to be performed by UAPE, since it would imply that UAPE is itself a gis, which is not the case. Monitoring is not automatable, since it corresponds to cross checking the result of an application with real life situations, and changing the application when needed. This last part, in UAPE, implies updates to data and schema of of ApDB (and thus GISDB). As mentioned before, updates were not implemented in the prototype.

4 Case study This section brie y describes how UAPE can be used in geographic database modeling and design. The test case application corresponds to a real life problem, developed at ESALQ (Agriculture Research Center) State University of S. Paulo [FV96]. Basically, the goal of the application is to develop a methodological strategy to forecast forest re risks in a particular area, the Experimental Station at Tupi, S. Paulo State. First, the user is prompted to instantiate an instance of Project (Modeling and Design module), de ning data such as project description, date, etc. Appropriate Document and Study area instances were also created. Next, the user is prompted to browse (Retrieval and Manipulation) through the existing database, to check data availability. Figure 6 shows an example of browsing screens. The topmost screen window in the gure shows the visualization of a class instance { in this case, the Project instance created in the beginning of the session. Other (overlayed) windows allow visualization of schema details and named objects. Once this initial browsing activity is performed, the user can start de ning the database. This process basically involves specializing the Conventional, Representation and Geo-Class classes, and identifying Relationships among them. At the same time, the user can use instances of these classes to de ne InfoLayer instances, by specifying the corresponding derivation Process. Constraints and application dynamics are modeled as objects of the class Rule. The actions de ned in each Rule reference instances of the class Process. During schema de nition, the user is again prompted by the system to instantiate appropriate Document instances. Figure 4 shows a screen shot taken of the de nition of a Document instance which describes particularities of the Process which creates the Land use (Uso Terra) class instances. Figure 5 shows the basic class structure for this application. In particular, Soil use corresponds to an InfoLayer { i.e., it is a subclass of class InfoLayer. Since InfoLayer instances correspond to derived data, Soil use instances must be de ned during process modeling. Thus, the documentation required from the user includes de nition of a Process instance (and not merely of a Document instance). The classes identi ed by the user for the application (and subsequently mapped to O2) were:  Conventional classes: Family { to contain data about families living in the area.  Geo-objects: River, Soil, Dam, Construction, Power Line, Local Path and Highway. These classes were created as subclasses of Geo-object. Instances correspond to discrete real world objects (the end-user's object view of the world).  Geo- elds: Relief, Air Temperature, Air Humidity and Basic Map. These classes were created as subclasses of Geo- eld. Instances are represented as matrices (images or grids of sampled values). They correspond to either satellite images (Basic Map) or to values obtained from remote sensors (e.g., Air Temperature) which are interpolated for the surface of the area (Study area instance) being studied. The following relationships were identi ed:

Figure 4: De ning Document properties for a Process

between Power Line and Local Path: causal relationship, with the restriction that wherever there is a power line, there is a local path.  between Highway and Soil Use: association relationship indicating that there is a land buer parallel to the road cannot be used for plantation or constructions  between Air Humidity and Air Temperature: causal relationship to trigger the computation of re risk factors whenever there is a dry day. Dynamic modeling abstracted the following constraints:  wherever there is a Power line, then a Local path is to be found, whose 2D description geographically coincides to that of the Power line instance;  if rainy day (event) always (condition) compute the new re risk index (action); The rst constraint is here speci ed in user vocabulary, whereas the second constraint already uses Rule instance speci cation. The prototype does not yet allow transformation of constraints into Rule instances. Finally, process modeling was performed. The information layers were de ned, together with the processes that generate them (in the gure, InfoLayers are identi ed by P):  Land Use: instances combine data from River, Dam, Soil Use and Construction.  Neighborhood: constructed by applying the neighborhood operator, using a 1 km distance along the Study Area represented by Basic Map geo- eld.  Access Paths: computed by combining Highway and Local Path.  Declivity and Exposure: determined by computations on Relief. Fire risk is also de ned by process modeling, but does not correspond to any InfoLayer class, just a Process instance. It combines several InfoLayer instances together with Air Humidity and Air Temperature. 

5 Conclusions and future work This paper presented UAPE - a modeling and design environment geared towards environmental applications. The main idea of this software is to reduce the diculty found by users when developing geographic applications over gis. UAPE is the result of over three years' work with users who work with environmental planning, especially researchers from the Faculties of Geosciences, Agriculture Engineering and Civil Engineering of UNICAMP. Unlike other systems, UAPE allows both static and dynamic modeling, and takes advantage of an intermediate storage system to grant independence from a speci c gis. The GMOD data model, on which UAPE is based, allows users to de ne their databases in terms closer to their daily work concepts, thereby decreasing the gap between user mental models and gis implementation. The system is being validated by end-users, for distinct application domains.

Figure 5: Application database classes

In the present implementation, only a subset of GMOD classes has been implemented. In particular, the user does not still have access to the Time class and to causal relationships. Even then, the implementation covers the speci cation of models of reasonable complexity, as shown in section 4. The implementation of the spatio-temporal data handling facilities has already been nished [FMN98] and is going to be incorporated into the next version of the prototype. Dynamic and process modeling are restricted to guiding the user through creating Rule and Process class instances. Enhancing these facilities will require adapting and extending the work of [MC95] already developed at IC-UNICAMP, and which is restricted to handling rules in the context of geographic integrity constraints. Finally, though users can communicate with UAPEDB to design databases and browse existing data sources, there is no connection with an underlying gis. In other words, no Import/Export driver has been yet developed, though preliminary tests have been simulated for the IDRISI gis. Thus, another extension will be to implement such drivers, which requires writing code dedicated to each gis. This project is being developed within the PRONEX SAI (Sistemas Avancados de Informaca~o) program. The research reported in this paper was partially supported by research grants from FAPESP, UNICAMP and CNPq, as well as grants from the PROTEM-GEOTEC project. The O2 DBMS was bought with a grant from the GeoTOOLs ICDT 116 project nanced by the European Community.

Acknowledgements

Figure 6: Browsing through UAPEDB

References [Cam95] G. Camara. Models, Languages and Architectures for Geographic Databases. PhD thesis, INPE, December 1995. In Portuguese. [Car89] J. Carter. Fundamentals of Geographic Information Systems: A Compendium, chapter On De ning the Geographic Information System, pages 3{8. American Society for Photogrammetry and Remote Sensing, 1989. [Cer96] N. Cereja. Vis~oes em Sistemas de Informac~oes Geogra cas - modelo e mecanismos. Master's thesis, UNICAMP, Dezembro 1996. [CFS+94] G. Camara, U. Freitas, R. Souza, M. Casanova, A. Hemerly, and C. B. Medeiros. A Model to Cultivate Objects and Manipulate Fields. In Proc 2nd ACM Workshop on Advances in GIS, pages 20{28, 1994. [CM97] L. M. Cura and C. B. Medeiros. Vers~oes em Bancos de Dados para SIGs. In SBC, editor, Anais, XII Simposio Brasileiro de Bancos de Dados, pages 29{43, 1997. [Fed93] K. Fedra. GIS and Environmental Modelling. In M. Goodchild, B. Parks, and L. Steyaert, editors, Environmental Modelling with GIS, pages 35{47. Oxford University Press, 1993. [FMN98] G. Faria, C. B. Medeiros, and M. A. Nascimento. An Extensible Framework for Spatio-Temporal Scienti c Database Applications. In Proc. Tenth Intl Conf. on Scienti c and Statistical Database Management SSDBM, 1998. [FV96] S. F. B. Faray and C. A. Vettorazzi. Evaluation of Fire Risks in Forest Areas using a GIS. Technical report, ESALQ-USP, Department of Rural Engineering, 1996. In Portuguese. [Goo92] M. F. Goodchild. Geographical Data Modelling. Computers and Geosciences, 18(4):401{408, 1992. [MB96] C. B. Medeiros and M. Botelho. Managing Time in GIS. In Proc. GIS Brasil, pages 534{544, 1996. (in portuguese). [MC95] C. B. Medeiros and M. Cilia. Maintenance of Binary Topological Constraints through Active Databases. In Proc 3nd ACM Workshop on Advances in GIS, pages 127{134, 1995. [OA93] J. L. Oliveira and R. O. Anido. Browsing and Querying in Object Oriented Databases. In Proc. 2nd Intl Conf. on Information and Knowledge Management, pages 364{373, 1993. [Oli97] J. Oliveira. Design and Implementation of User Interfaces for Geographic Application Systems. PhD thesis, IC-UNICAMP, december 1997. In Portuguese.

[OM95] J. Oliveira and C. B. Medeiros. A Direct Manipulation User Interface for Querying Geographic Databases. In Proc. Int. Conference Applications of Databases, pages 249{258, 1995. [OPM97] J. Oliveira, F. Pires, and C. B. Medeiros. An Environment for Modeling and Design of Geographic Applications. GeoInformatica, 1(1):29{58, 1997. [Pim95] F. L. Pimentel. Uma Proposta de Modelagem Conceitual para Dados Geogra cos { o Modelo MGeo+. Master's thesis, UFPE, october 1995. [Pir97] F. Pires. An Automated Environment for Modelling Geographic Applications. PhD thesis, IC-UNICAMP, december 1997. In Portuguese. [PMP93] N. Pissinou, K. Makki, and E. Park. Towards the Design and Development of a New Architecture for Geographic Information Systems. In Proc. 2nd Intl Conf. on Information and Knowledge Management- CIKM, pages 565{573, 1993. [RL95] J. Raper and D. Livingstone. Development of a Geomorphological Spatial Model Using Object-oriented Design. Intl. Journal of Geographical Information Systems, 9(4):359{383, 1995. [Rum91] J. Rumbaugh. Object Oriented Modeling and Design. Prentice Hall, New Jersey, 1991. [Wor94] M. Worboys. A Uni ed Model for Spatial and Temporal Information . The Computer Journal, 37(1):26{33, 1994.