Geospatial Modelling:
A Case Study for a Statewide Land Information Strategy
 
Dr. David Pullar
The University of Queensland
Brisbane, QLD 4072. AUSTRALIA
email: d.pullar@mailbox.uq.edu.au
 
Ms. Kristin Stock
Queensland University of Technology
Brisbane, QLD 4001. AUSTRALIA
email: k.stock@qut.edu.au

 

Abstract

Most information applications are built on an underlying business model that includes a semantic description of the information content for a system. Using expressive and powerful modelling techniques is imperative to accurately capture this business model. This paper examines modelling techniques with regard to developing spatial information products for a statewide land information system. These information products convert spatial data held by state government agencies into useful and timely information that may be accessed by users in a networked computer environment. Handling of spatial information requires special application software, such as a geographical information system (GIS). Likewise application modelling techniques for GIS applications impose special modeling requirements. The paper reviews geomodeling approaches in terms of (1) special spatial modelling languages, and (2) extending general modelling languages to incorporate spatial requirements. The latter approach is adopted to describe a geomodel for spatial domains in terms of the abstract syntax (metaclasses, relationships, and constraints), well-formedness rules (rules and constraints on valid models) and semantics (model usage). This is applied to one spatial information product, namely for dealing with land pest infestations, to describe an information model from primary data collection in the field to networked access to information.

1. Introduction

This paper goes beyond the exchange of spatial information to look at how tools for manipulating that spatial information are commonly understood and transferred across application boundaries. In this respect interfaces for spatial information systems are examined at a conceptual level. We are more concerned with the expression of user requirements and system structure than the component level interfaces between system modules.

The paper reviews data modeling methodologies for GIS-specific applications. In everyday terms we are interested in specifications, design artifacts, and database schemas for land information systems. Two forces motivate our work. Firstly, we believe appropriate attention has not been given to design and analysis methodologies within the spatial information industry. A great deal of attention within the GIS scientific community has focused on spatial query operators and spatial access methods. By account, the amount of research into application level design has been lacking. This is despite the fact that a larger number of people would be drawn into defining system requirements and design objectives for a normal application than those people tasked with building the system. While many papers espouse the virtues of capturing user intent, the fact is there are very few tools or guides to assist in GIS conceptual modeling. A second motivating force is that most user requirements are either expressed or understood to relate to a small set of concepts, e.g. maps, coverage's, networks, etc. While new paradigms will eventuate, we believe most applications can be expressed in terms of a key set of design concepts. These design elements define high-level type systems with application specific semantics.

The contribution of this paper is to:

This paper looks at interoperability from an application perspective. The next section describes the setting for the development of information products in a statewide land information system. This is called the Queensland Spatial Information Infrastructure Strategy (QSIIS). Section 3 discusses object-oriented design and analysis (OODA) methodologies in relation to modeling techniques. Section 4 reviews specific OODA modeling languages for spatial classes. Section 5 describes how a general OODA modeling language may be extended to include spatial requirements. It describes this in the context of information products being developed for QSIIS. The conclusion describes a proposal to test the usability of our geomodel and its applicability to providing interoperable tools in a statewide networked information system.

 

2. QSIIS Interoperability Environment

The Queensland Spatial Information Infrastructure Strategy (QSIIS) is a plan for providing spatial information services to Queensland. It is largely driven by State Government departments, and its aim is to provide 40 information products that are defined by the collection, maintenance, and use of spatial data sets by each department. This is based on the assumption that the departments involved (13 out of a total of 18) are representative of the main purchasers and providers of spatial information (Alexander-Tomlinson, 1997).

Each of the 40 information products is developed to fulfil a particular set of requirements. For example, the property interests analysis product (currently under development) is concerned with land administration. Currently, to obtain full information about a property, users must search across multiple sites holding land information records, with related issues in timeliness; incomplete or non existent electronic records and difficulties in knowing where to search. The property interests analysis information product aims to allow single point access to all property based information. This is expected to provide benefits including:

The immediate concern of system designers is to make information available across a number of different sources by providing interoperability. However, as indicated by the above list of requirements, for users the concern is more focused on the outcomes of the availability of information, in terms of what economic and administrative impact it might have.

3. Information Modeling

We need to build a model for a geographic information system when it is too difficult to comprehend the system in its entirety. As the complexity of the system increases, so does the importance of good

modeling techniques. Some essential factors for geographical application development are the use of a standard application design methodology (Hadzilacos and Tryfona, 1996) and a model specification using a rigorous modeling language. Geographical applications make use of mathematical models of space and their representation, including geometry, map projections, cost surfaces, statistical rendering, etc. If modeling space from a mathematical perspective is considered to be an open problem then it is not surprising that geographic application methodologies are also open to various interpretations. This is evident in the constant tension between users who want semantically expressive models for their particular application domain and vendors who need to provide general purpose tools. So given that it is a fallacy to believe in the existence of a universal data model for geographic reality (Morehouse, 1990), it seems appropriate that we concentrate our energies on describing metamodels from which we can build different models.

So what are metamodels? If models are representations of some reality then metamodels are descriptions of models. Metamodels use a rule language to define all well-formed models that may be represented. Likewise to flexibly describe a metamodel, in theory, sometimes requires a meta-metamodel. Architecturally this is shown in Figure 1. A meta-metamodel defines an abstract language for specifying metamodels. A metamodel is an instance of a meta-metamodel, which is a language for specifying models. As with any modeling process, the model cannot be expected to provide complete knowledge of its subject but a good model should provide a reasonable interpretation of the real situation.

Figure 1: Meta-metamodel, Metamodel, Model Architecture (Source: Crawley et al., 1997)

The meaning of the abstract concepts in Figure 1 may be understood using some real world illustrations. These examples are adapted from Crawley et al. (1997) A meta-metamodel would be a type system for CORBA IDL, then the metamodel would contain schemas of CORBA IDL types and relationships between them, and the entities in the model would be CORBA objects. Alternatively, if the meta-metamodel defined a language system for design notations, then the metamodel elements would be specific notations, and the entities in the model would be design diagrams.

We want users to construct object models for geographic applications. The metamodel language we chose to describe these models is the Unified Modeling Language (UML). It represents the best practices in the object technology industry derived from leading object-oriented methods, including OMT (Rumbaugh et al., 1991). UML (1997) is "a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems." UML's modeling language includes:

The most prominent aspect of UML is its visual notation. It includes a methodology to capture the dynamic aspects of a model, such as interactions, collaborations, and state histories of objects in a system. A static class diagram is used as an integrating framework for the system specification. The class diagram shows a collection of declarative (static) model elements, such as classes with their contents and relationships. UML has the advantage that it is relatively easy for professionals to understand and to facilitate their involvement in the design process. But still includes formal definitions for the structural aspects of class diagrams and a set-theoretic language for expressing well-formedness constraints.

A brief description of some modeling elements for UML class diagrams is shown in figure 2. Class symbol is a composition of a class name, its attributes and operations. A binary association is shown as a line connecting class symbols. The end of an association where it connects to a class is called an association role. Roles signify important aspects of associations including multiplicity, ordering, qualification, navigation, and aggregation relationships between classes. Association paths are adorned with an association name and constraints. A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true. It is shown as a text string in braces {}. All model elements that include text strings (such as class names, attributes, association names, constraints, etc.) represent information that has both syntax and interpretation. We have presented just a small subset of UML notations, a detailed description can be found in the UML documentation set (UML, 1997). Our experience suggests that UML's combination of a visual notation and some formal language rules provide a reasonable balance between expressiveness and readability.

Figure 2: Notations for several model elements in UML

UML supports some core model elements that are used to define models. It also includes language extensions for specifying process-specific models, for instance to define a special type of association between classes. These metamodel constructs are sufficient for a user to create a customized specification of an application specific domain (without having to resort to a meta-metamodeling layer). The next section describes GIS specific models that have been proposed. Section 5 describes the extension mechanisms in UML and develops GIS application specific models.

4. Literature Review

Although a number of modelling methods have been used since conceptual modelling first became a distinct step in the application design process, recent years have seen a general acceptance of the object oriented method as suitable for GIS modelling (De Oliveira et al., 1997). However, a recent criticism of object-oriented modelling is that there are no standard practices or commonly accepted conventions. Worboys (1994) examines the causes for the proliferation of competing models, all claiming to represent a true object oriented modelling methodology. The main cause is the lack of general consensus on the key features and definitions that constitute an object oriented model.

In recent times, the debate over object oriented data models has been diffused somewhat by distinguishing between object oriented analysis and design (OOAD) methods, and object oriented programming (OOP) languages and databases (Booch, 1996). It is important to make the distinction between modelling concepts and implementation tools. OOAD provides the method for analysing problems and framing them in terms of objects. The benefits of OOAD for an application can be realised without the need for an OOP implementation, but using OOP to build system applications has obvious advantages. Similarly OOAD can be implemented on a non-object oriented database management system.

Although the segregation of OOAD and OOP has gone some way towards identifying a standard set of characteristics of an object oriented model, the model has been applied to GIS in a number of different ways. Four such applications are described here:

• GeoOOA, which is an extension of the object oriented model (Kosters et al., 1997);

• GISER, which is an extension of the Enhanced Entity Relationship Model, itself an extension of the Entity Relationship Model to include some object oriented concepts (Shekhar et al., 1997);

• USM*, which is an extension of the Unifying Semantic Model, and is specifically distinguished from the object oriented model by the authors, although it exhibits many similar characteristics to the object oriented model (Park, 1997) and

• GMOD, which is an extension of Camara et al. model, itself an extension of the object oriented model (De Oliveira et al., 1997).

The remainder of this section reviews these four models in terms of five basic questions: • What problems are the models intended to solve (that is, why were they developed)?

• What representational semantics do the models include?

• How do the models handle space and time?

• What mechanisms do the models have for interchange and repository?

• What metamodel characteristics do the models provide?

4.1 Problems addressed by the Models

The four models differ in the problems they are intended to solve, or the justification for their existence. GeoOOA defines the following problems of the conventional object oriented model, defining an extended model to solve them:

• there is no easy way to distinguish between spatial and non-spatial classes;

• there is no obvious way to determine the type of a spatial class (that is, point, line or region);

• there is no distinction between topological and conventional relationships;

• important topological constraints are hidden in textual specifications and

• frequently occurring topological constraints lead to redundant textual specifications (Kosters et al., 1997).

GISER's main contribution is to address the problem of the unification of field-based and object-based spatial data model approaches. It includes concepts for the discretization of field-based models using an interpolation technique (Shekhar et al., 1997), as well as procedure valued attributes and support for the entire GIS process (input, modelling, manipulation and presentation) (Shekhar et al., 1997).

USM* focuses on the provision of tools as part of a problem solving environment for ecological issues. Its main aim within this is to promote model reusability and provide a tool for high-level (semantic) specification of models. The solutions the model provides include:

• model management tools, incorporating access and assistance in modelling (to increase reusability);

• the ability to specify and store simulation models for ecological processes and

• visualisation services (Park, 1997).

Finally, GMOD's contribution to the use of object oriented modelling for geographic objects has some of its justification in common with GISER. It attempts to isolate users from implementation details, allowing the inclusion of semantics (De Oliveira et al., 1997).

 

4.2 Representational Semantics provided by the Models

The representational semantics provided by GeoOOA directly mirror the criticisms of the object oriented model made by the authors and outlined above. The model defines a syntax and semantics for all GeoOOA primitives and their standard attributes, services, topological relationships and constraints. It is visually explicit in that it ensures the object and their intent are visible (Kosters, Pagel and Six, 1996).

GISER provides a functional view of geographic phenomena as input, data modelling to extract spatial information content, manipulation and result presentation. Special notations are provided for non-entity information (in particular, field based model elements) (Shekhar et al., 1997).

USM*'s main contribution is its use of the semantic model to represent concepts which describe observations and the logical relationships that hold them together (Park, 1997). It does this by providing a number of multidimensional constructs (Park, 1997).

USM* is distinct from the other models in that its authors explicitly reject the object oriented model, saying that it is typically tailored to a specific implementation system. Despite this, it exhibits many of the characteristics that are typically object oriented (for example, encapsulation and aggregation) (Ram and Park, 1996).

GMOD's representational semantics define classes for both spatial and non-spatial objects. The spatial objects are not immediately obvious from the example diagrams (refer to GeoOOA's justification for existence). GMOD allows progressively more detailed models to be developed in the typical style of OOAD (Rumbaugh, 1991). Spatial representational details are invisible at the conceptual level (hence the inability to identify them from non-spatial entities in the absence of specific notation differences) (De Oliveira et al., 1997).

4.3 Model Concepts of Space and Time

GeoOOA defines geoclasses for point, line, region and raster. These classes encapsulate specific geometric behaviour and topological constraints. The model defines special composition notations for the network structure (including edge links and node junctions). In addition, it provides a particular association relationship: the whole-part composition, which can have a covering, containment or partition structure (Kosters et al., 1997). Spatio-temporal objects are also supported using a timestamping function (Kosters et al., 1997).

GISER represents the continuous field class using space/time extents, from which features (both names and unnamed) are identified in space. These may then be discretized to spatial objects in a coverage. The model also supports derived features and relationships (Shekhar et al., 1997).

USM* supports spatio-temporal and dynamic classes. The dynamic classes are specifically designed to incorporate the simulation models that are the focus of the ecological decision making system for which it was designed. Relationship constructs that are provided by the model include spatio-temporal and causal relationships (Ram and Park, 1996).

GMOD divides its classes into conventional classes and geoclasses. Geoclasses can be either geoobjects (object-based view) or geofields (field, or continuous view) (Camara et al., 1994). Both geoobjects and geofields have an attribute which describes their georegion (geometric location). Time is included through the definition of a time class, which any other object can have as a component (De Oliveira et al., 1997). GMOD includes two temporally based relationships: versioning and causation (De Oliveira et al., 1997).

4.4 Interchange and Repository Mechanisms provided by the Models

Of the literature reviewed for the four models, only the discussions of USM* explicitly identified a repository mechanism. The USM* repository has three components:

• a metadata directory, which includes the USM* model created by users;

• a mapping directory, which maps the metadata to the underlying database and

• a model description, which describes the various simulation models (Ram and Park, 1996).

GMOD provides interchange mechanisms, and is intended to be an open model. A method for connection of the model system to a commercial GIS using an interface is provided. An External Driver layer is responsible for conversion between the underlying GIS and GMOD, so that the user has the benefit of GMOD's semantics (De Oliveira et al., 1997).

4.5 Metamodeling Characteristics Provided by the Models

All of the models reviewed (based on the literature examined) were very much focused at the model level (see Section 3), but also included discussion of the application of the model at the object level. None of the models addressed metamodeling or meta-metamodeling.

The questions examined above in relation to each model indicate that there are significant similarities between the models in terms of the problems they hope to solve, the representational semantics they use and their concepts of space and time. The differences in these three areas relate mostly to specific details of dealing with individual spatial classes and relationships.

There is more variation in the mechanisms provided for interchange, including tools like the repository. Some models do not address them at all, while others include detailed allowances for such uses. None of the models provide a metamodeling level.

The intention of this paper is not to suggest that these models (and many others that are similar) do not provide adequately for the modelling of geographic data. A large body of literature, including that reviewed here, indicates that these extensions are useful to some degree. Instead, this paper points out that none of the models reviewed here (and no other geographic models that we are aware of) provide metamodeling tools. The provision of metamodeling tools (like UML) is significant in that it removes the need for explicit extended models to be developed, as geographic models are supported by the tools provided at the metamodel level.

The next section shows how UML (a metamodeling tool) can be used to define geographic models without any need for extension to the tool itself, since the metamodel level provides for definition of particular stereotypical constructs.

5. GIS Application Specific Extensions to UML

The UML metamodel includes built-in mechanisms to facilitate domain-specific extensions to its metamodel without needing to resort to a meta-metamodeling layer. These are essentially variants of the core modeling elements (i.e. class and association) and their semantics (constraints) that can be tailored for specific application areas. UML supports extension mechanisms using stereotypes, tagged values, and constraints (UML, 1997):

Stereotypes may extend the semantics, but not the structure, of pre-existing types and classes in the metamodel. Certain stereotypes are predefined in the UML, others may be user defined. The general presentation of a stereotype is to place the name of the stereotype within matched guillemets «stereotype name» or depict it by a graphic icon appropriate for the model element being described.

Tagged Value is an explicit definition of a property as a name-value pair. In a tagged value, the name is referred as the tag. Certain tags are predefined in UML, others may be user defined. A tag is attached to a model element as a comma-delimited sequence of property specifications with the format {keyword1 = value1, keyword2 = value2, .. }.

Constraints are semantic conditions on the relationship between model elements expressed as a text string. Certain constraints are predefined in the UML, others may be user defined. UML does not prescribe the language in which the constraint is written, but ideally a process-specific constraint is described in a formal language with a specified syntax and interpretation. A constraint is shown as a text string in braces { }.

It is very conceivable that the models described in Section 3 may be specified using the process-specific extensions from UML. Taking GeoOOA for example. Stereotypes may be used to describe geoclasses with an identical graphical syntax. Topological whole-part structures, including specialization’s for covering, containment, and partition, may be defined as association stereotypes. This would appear as a text string (as yet there is no graphical syntax in UML for user defined association stereotypes). The abstract network structure may be expressed as a constraint between association paths for network-link classes and network-node classes. The semantics for geometric standard services may be completely specified using behavioral model aspects of UML.

Therefore UML is capable of expressing concepts of space and time using special geomodeling constructs. It provides the same desirable features as GeoOOA; such as visible distinction of spatial classes and explicit topological constraints. Both syntax and semantics can be expressed in a mathematical language to enforce domain information. UML also considers a supplementary methodology (i.e. guidelines) as an essential part of building models for complex systems. The additional benefits of using UML are that it allows tailoring of the metamodel to allow for variant models, and provides a mechanism for model interchange and interoperability.

5.1 Example of a UML Geomodel

As an example of a UML metamodel we will relate our own experience of developing geographical applications. One of the more surprising aspects we have encountered is that users make explicit reference to very few spatial concepts in their requirements. Often the spatial concepts are implicit in the business case for the system of interest. Spatially explicit requirements (dimension, scale, and accuracy) are collected during the final stage in the requirements process. In the initial stages we found that users frequently make reference to (1) the scope or realm of spatial information and (2) to its thematic qualities. The notion of a realm appears to be important in several phases of the application development methodology. At a conceptual level a realm defines the sphere of influence of geographical information. This eventually is refined in the design phase to a map view control with a map projection, area-of-interest, display rendering, etc. A theme class represents a set of spatial entities with similar properties that are part of the realm, it corresponds closely to a map theme. Users often make reference to semantically rich descriptions of spatial themes without explicitly namely their spatial characteristics. This eventually is refined in the design phase to express spatial properties such as dimension, topological relations, scale, accuracy, scale-dependent display characteristics, etc. Figure 3 shows stereotypes for realm and theme classes with an aggregation relationship.

Figure 3: Class Stereotypes for Geomodel

5.2 Pest Information Application

We describe a sample application dealing with land pest infestations to demonstrate the use of these geomodeling elements. The requirements for the pest infestation information system are as follows. Plant and animal pest infestations are recorded by an inspection in relation to land ownership properties. Land resource officers, who each have an assigned district, make the on-site inspection and enters it into their field system. Besides entering infestation details they may optionally enter the extent of the infestation from a GPS traverse or by a free hand sketch. Periodically, each land resource officer connects to the central office system and synchronizes its records, the main office maintains a registrar for each district. The central system is used for decision support on remedial activities and for answering public queries on infestations. Figure 4 shows part of the class diagram. A full specification would include attributes and operations in the class diagrams, and behavioral modeling diagrams for interactions and collaborations between objects.

 

Figure 4. Geomodel for Sample Pest Information System

 

Even this simple example embodies several complex interactions and interoperable aspects of the application. Firstly the inspection record acts as an event to record the current state of a pest infestation. These are modeled as a stereotype based upon concepts for temporal systems (Langran, 1992). The spatial extent for an infestation may be measured in the field using a GPS device. Presently this is handled by an "import facility." Periodically the field system is synchronized with the central office system using a "connection facility" or an "interchange facility". The former uses an RPC connection, and the later uses transfer via a file format. Aspects of synchronization are explored further in the system design phase. It is modeled as a replicated database with a replication manager to control authorization and upload/download of data.

The sample application described was developed using Arcview from ESRI. Our work suggests that the extended geomodel from the system design can be translated in a very mechanical fashion into a prototype application. This includes map displays, tables, interface menus, and code scripts. It would then be the responsibility for the system implementers to add operational code consistent with the specification from class diagrams, data dictionary, and the operation dictionary.

We have defined several metamodel elements used in the system analysis and system design. We are currently undertaking a usability study and end-user surveys to ascertain their utility. It is our belief that application design operates in a collaborative environment between end-users, experts, and software engineers. The usability tests will indicate how intuitive and readable models are. We are using four criteria to judge overall readability: usefulness, effectiveness, learnability, and likeability. These criteria are used to determine the success of computer systems (Rubin, 1996).

5.3 Land Information as a "Yellow Page" Service

The development of an information application is often subdivided into several stages: requirements analysis, design and implementation. There is a progression in considerations from conceptual descriptions of the problem, to the computing environment needed, and finally an operational application. UML compels a system level view of application problems. Their definition of a model is semantically closed abstraction of a system. Therefore even during requirements analysis system specific terminology is introduced. This bias is well suited to a requirement analysis for information products described in the Queensland Spatial Information Infrastructure Strategy (QSIIS). Unlike environmental planning and control applications where there is a high level of semantic information related to the real world process (De Oliveira et al., 1997), most of the applications for QSIIS reflect fiscal and institutional systems. In fact most the requirements relate to access of information products and services within a state government organizational structure.

Future developments of applications, like the pest information system, will be part of an online directory. A trial technology architecture was explored in 1996 that linked directory access to several GIS databases. The objective of the trial linkage was to help identify standards and protocols to support interoperable access to spatial information systems (QLIS, 1996). It is simple to connect two sites, but adding several sites with various client users and service problems adds significantly to the complexity. The trial architecture explored linking several sites through a "yellow page" directory. This is implemented as a broker that maintains a directory catalogue of services and providers, which it can look-up in response to user requests. Subscribers, such as Pest_Info, would advertise the services they offer and unadvertise services being withdrawn. This is a very dynamic environment where the QSIIS broker adds and removes Yellow Pages listings as instructed, and also knows how to dispatch user requests to the appropriate service. All user requests are processed through the QSIIS directory and not directly to the service’s application. The connected client broker and server broker communicate service transactions. The transaction protocol begins by a user request. The QSIIS broker sets up a communication session to the listed service. The client broker will advise if it can answer the request giving the cost, in time and monetary units, to fulfill the request. The server broker relays this information back to the user, once accepted the server broker using the same session identifier communicates again with the client broker to complete the request. The QSIIS directory records the details of the transaction for business accounting purposes. Figure 5 shows this scenario with a the sample Pest_Info application.

 

Figure 5: Client-Server Object Classes to list Pest_Info services with "Yellow Page" directory
 

A prototype technology architecture was built by the Queensland Government in 1996. The system was implemented in C++ and used middleware software, TUXEDO on a UNIX Server, to control multidatabase access. Arcview's SHAPEFILE format was used for interchange of spatial information. It is understood that a proposed system would provide greater dynamics for providers to list and deploy services. A review of this trial confirmed the need for high level interoperable components that adhere to standard protocols. In particular addressing the particular needs of spatial information, its access methods and interpretation, were seen as relying upon future standards efforts like OpenGIS (QLIS, 1996).

It is our belief that OpenGIS will deliver the standard interface specifications, which are in turn implemented by vendor software, for spatial data access and spatial operator interfaces. But it also our firm conviction that there does not exist one geomodel to suit all user communities. We recognize the need for a metamodeling on which service providers can build their own geomodels. Interoperability between these geomodels will rely upon well defined standards and protocols, just as interchange of data relies upon standard formats. A model interchange format should try and balance its formal specification with readability.

To test how well models may be communicated we are in process of conducting usability tests. The tests are based upon the assumption that interoperability of metamodels is qualified in terms of readability and how well it communicates the model semantics between several parties.

6. Conclusion

The future of QSIIS is to support an open system marketplace for access to spatial information and special information services. This will include an interoperable environment where providers list new and integrate existing information products. The machinery for building such a system is not available today, or at least the technology is in its infancy. The strategic development of QSIIS, and similar land information systems, will depend upon communicating meaningful data models that are still readable.

This paper discusses spatial data models with regard to application development methodologies. We have reviewed several methodologies each addressing slightly different problems and user requirements. Each has advanced a geomodel they feel incorporates the necessary concepts for space and time, and representational semantics. But each again is slightly different. Therefore it is apparent there is not one geomodel for all information communities. We have explored how metamodels can be defined using an industry accepted modeling language. We are currently testing the usability of a geomodel for system analysis and system design purposes.

We believe the standards effort for interoperability should progress at two ends of the software engineering spectrum. As is occurring now, the lower end will deliver common data types used to define spatial information classes. Specifications for such data types rely upon mathematical principles for spatial data types. They will provide the basic building blocks to describe the spatio-temporal characteristics of spatial information. The middle part of the spectrum includes defining spatial data models to suit real world situations. This part should retain a high level of user input. In other words system designers should have the opportunity to define their own geomodels (or metamodels) for an information community. This challenges the standards effort to adopt meta-metamodeling facilities to allow designers to describe their own metamodels.

Bibliography

Alexander-Tomlinson (1997). Queensland Land Information Strategy (QLIS) Benefit Study. Volume II: Situation Report (Assessment of Government and Industry Spatial Information Requirements).

Booch G. (1996). Object Solutions: Managing the Object-Oriented Project. Addison-Wesley, Menlo Park, California.

Camara, G., Freitas, U.M., Souza, R.C.M., Casanova, M.A., Hemerly, A.S. and Medeiros, C.B. (1994). A Model to Cultivate Objects and Manipulate Fields. Proceedings 2nd ACM Workshop on Advances in GIS.

Crawley S., Davis S., Indulska J., McBride S., and Raymond K. (1997). Meta Information Management. Formal Methods for Open Object-based Distributed Systems (FMOODS) Conference, Canterbury, UK, July 1997.

De Oliveira, J.L., Pires, F. and Medeiros, C.B. (1997). An Environment for Modeling and Design of Geographic Applications. GeoInformatica 1, 29-58

Hadzilacos T., and Tryfona N. (1996). Logical Data Modelling For Geographical Applications. International Journal of Geographical Information Systems, 10(2).

Kosters, G., Pagel, B. and Six, H. (1996). GeoOOA: Object-Oriented Analysis for GIS-Applications. Proceedings 2nd IEEE International Conference on Requirements Engineering, Colorado Springs.

Kosters, G., Pagel, B. and Six, H. (1997). GIS-application development with GeoOOA. International Journal of Geographical Information Science 11(4), 307-335

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

Morehouse, S.D. (1990). The Role Of Semantics In Geographic Data Modelling. Proceedings 4th International Symposium on Spatial Data Handling, Zurich, 689-698

Park, J. (1997). Geographic Information Systems and Problem Solving Environment. Crossroads Vol. 4(1), 3-8.

QLIS (1996). QLIS Project Report: Technology Architecture Research & Development Project. The Queensland Land Information Council, The State of Queensland Department of Natural Resources.

Ram, S. and Park, J. (1996). Modeling Spatial and Temporal Semantics in a Large Heterogeneous GIS Database Environment. Proceedings of the 2nd Americas Conference on Information Systems (AIS '96), Phoenix, Arizona, August, 16-18

Rubin J. (1996). Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests. John Willey & Sons, New York.

Rumbaugh J., Blaha M., Premerlani W., Eddy F., and Lorensen W. (1991). Object-Oriented Modeling and Design. Prentice-Hall.

Shekhar, S., Coyle, M., Goyal, B., Liu, D. and Sarkar, S. (1997). Data Models in Geographic Information Systems. Communications of the ACM 40(4), 103-111

UML (1977) Universal Modeling Language (UML) Document Set, http://www.rational.com/uml. Rational, Software Corporation, Santa Clara.

Worboys M.F. (1994). GIS: A Computing Perspective. Taylor & Francis, London.