OPEN GEO DATA PROCESSING

Dr Jahid Aybet
University of Luton
Department of Computing and Information Systems
Luton LU1 3JU United Kingdom

INTRODUCTION

One of the great architects of this century, Frank Lloyd Wright, introduced a new architectural thought. He believed that architecture (of buildings) should represent a natural integration with its surrounding environment, create an open structure and meet the users’ requirements. The implementation of his design principles can be seen in his buildings. Simon and Wheeler (1995) pointed out to a similarity between Wright’s architectural principles and the design principles which should be adopted to create an open system processing environment. The architecture of an open information system should be configured to create an open structure with its basic component units (hardware, software, networks, standards, etc.), integrating with the surrounding (other) systems and it should respond to the users’ requirements.

With today’s diversified business requirements and highly specialised software systems, it not thought to be possible to create a total system solution with the products of a single vendor. Geographic Information Systems have so far been vendor specific implementations which have proved to be very costly to integrate with other information systems.

The main handicap for the expansion of geodata usage is that all the spatial data sets are captured and stored in a wide range of vendor proprietary formats, often incompatible with each other. The main problem is, therefore, the non-interoperability of GIS software products which usually results in isolated repositories of geodata and geo-processing. It has been argued that the vendors of GIS products have been historically motivated to keep their systems closed as a marketing strategy to dominate the market and to retain a customer base (Collison RW, 1995). But, at present, there seems to be a pressing market demand for open geo-processing, as various organisations using spatial/ geographical information need to share it with their business partners, parent organisations (or subsidiaries), government departments that the need to exchange spatial information becomes essential for the success of their business. Therefore such a strategy will no longer be regarded as valid successful marketing for any GIS vendor.

Interoperability is defined as a user’s or device’s ability to access a variety of heterogeneous resources by means of a single operational interface. For GIS users, it means the freedom and ability to access local or remote geo-processing environments which may use multiple GIS products and contain multiple format data sets. The first logical step to achieve a full integration of geodata from a variety of sources and within a variety of applications would naturally require the creation and adoption of some standards for the exchange of spatial data and its meta data.

With the publication of "The OpenGIS Guide, OGIS Part I" (Buehler, McKee,1996). specification, such a standard is now in the process of being established, albeit as a de facto standard. The OGIS approach largely depends on object-oriented definitions of geodata. Therefore, the interoperability of spatial objects play a crucial role in the open systems implementation of a GIS.

This paper looks into the object-oriented technology in general and the spatial object definition in particular as a means of achieving an open geoprocessing environment. As an object is encapsulated with the data describing its characteristics and the method (code) defining its behaviour, a spatial information system, in fact, consists of a library of object classes. From this perspective, the interoperability of spatial information systems means the interoperability of spatial objects. And open systems geo-processing can be achieved through object transformation and re-encapsulation.

ASSUMPTIONS FOR SPATIAL INTEROPERABILITY

The current research and development activities on interoperability and open geodata processing are generally based on three premises:

  1. The software is based on the object-oriented technology.
  2. The computing platforms are organised on a client-server architecture.
  3. The geoprocessing is performed as distributed computing.

This paper is also based on these assumption to examine the spatial interoperability issue.

 

Object-oriented concepts and Interoperability

In an object-oriented GIS, all the objects (spatial or non-spatial) belong to certain object classes. Classes have no geometry associated with them when they are created. Object classes are defined within a "Schema" specific to an implementation. Object becomes an instance of its class and each object is identified by a unique Object_ID which remains constant throughout the objects life-cycle. The class of an object determines what messages that object should respond to. An object’s response to a message is determined by its "method", a program encapsulated with the object. The response that an object gives to a message by means of its method is called "behaviour". An object simply inherits the behaviour of its class. Different classes produce different behaviours to the same message. For example, an "area" class would respond to the "display" message by displaying a polygon, whereas a "road" object would respond by displaying a line. This is polymorphism concept of object-orientation. New object classes can be created as sub-classes which inherit the behaviour (method) of their parent class. For example, a new class "road" can be created under "graphic_line" class, in this case the sub-class road inherits the behaviour ( properties, method, references, defaults) of parent class graphic _line (Aybet J, 1994).

In practice, the spatial objects within a GIS belong to the "Base Classes" which are generic object classes such as graphic_point, graphic_line, graphic_area. Therefore, the vendors of object-oriented GIS products, in fact, do not supply GIS software, as it is the case in conventional GIS products, as distinctly separate from data. Instead they supply libraries of base classes which contain all the necessary generic objects. The idea is that user specific applications can be quickly developed, if they can be constructed by using specific objects (or object classes) as units (or sub-components) of the application software construction. Therefore, the integration of different object-oriented GIS systems, or data exchange between them, or accessing distributed geodata and distributed geoprocessing means interoperability of the objects. Because both data and processing are encapsulated in the objects according to their object classes.

In order to support distributed databases as a business solution containing large numbers of spatial objects across a number of servers for different applications, it is absolutely necessary that the spatial objects of various GIS applications should be interoperable.

Client-server architecture and Interoperability

Open systems are built around a processing model that assumes client/ server configurations. The elements of a client/ server architecture in the context of open systems are described in (Simon and Wheeler, 1995). Modern operating systems are designed to provide client/ server computing, so that the applications can request access to specific services by means of predefined operating system calls (Havinga G, 1995).

The way client-server architectures are applied to GIS implementations is explained in various papers as implementation case studies (Aybet, 1993). Within an object-oriented context, we can examine spatial objects as client objects and server objects. In fact, the open geodata/ geoprocessing model as proposed in OGIS Part I (Buehler, McKee, 1996) exploits the general architecture of client-server configurations, in which "client objects" communicate with "service provider objects" requesting data or a processing function. This is slightly different from client-server inter-relationships, because some servers also request service from other servers while providing service to its clients.

Access to a number of different spatial databases is an essential requirement to create an open geoprocessing environment, as the current user community demands are growing for distributed access to spatial databases. Many general purpose databases also contain address and coordinate data which may need to be integrated with a spatial database. Therefore the open geodata paradigm has to provide a common interface to a number of different database systems. Each database normally has its own tools and mechanism to ensure data integrity, security and ownership as well as data search and retrieval functions.

Distributed Computing Platforms

The OSF (Open System Foundation) introduced the DCE (Distributed Computing Environment) as a framework for distributed processing. Distributed processing provides an opportunity to obtain the most efficient use of the available computing resources, including lower cost platforms. It would naturally increase the network data flows and hence the cost of network management and maintenance (Simon and Wheeler, 1995).

The client and service provider architecture can only be implemented on a distributed computing platform which consists of clients and servers. Some servers function as "Data Access Servers". A data access server is a component that provide data access when a request is received from a client object. Data access server is, therefore, a service provider which can also function as a client to a higher order service provider. In order to achieve a smooth interoperability all the transactions between the client and service provider objects need to be performed under a common interface. Requests for geodata and responses returned should be in a common lexicon.

This common interface - which should be the open geoprocessing interface - running locally, needs to be capable of invoking a variety of data manipulation functions from a number of spatial databases residing on different platforms. The common user interface as a client has to communicate with the application servers.

Data access service provider functions as a "Middleware" which enables application servers to access the relevant spatial database management system. Data access provider should also provide access to general purpose Relational Database Management Systems. These databases may be based on proprietary software products. Traditionally the RDBMS products have been used to store attribute data, but nowadays there is an underlying trend for the conventional GIS products to use the relational database to store spatial data as well for faster geoprocessing and presumably for better data security and version control.

However, in object-oriented databases spatial objects reside together with other non-spatial objects in the same database. Considering the co-existence of conventional and object-oriented GIS implementations, the link between a "client" and "service provider" to request and transfer geodata can be in a number of different types as shown in the following diagram.

Conventional client Object client Conventional client Object client

 

Functional API Object API (Conventional) Object

Data wrapper wrapper

 

Conventional Object-oriented Object-oriented Conventional

service provider service provider service provider service provider

Figure 1 Clients and service providers (after OGIS Part I)

Data wrapper or object wrapper is a piece of software which maps an API (Application Programming Interface) to another. The object wrapper provides the object client with an interface. Obviously the data wrapper and object wrapper software plays a pivotal role in providing open geo-processing. This is an implementation issue, it is expected that vendors will supply their own data/ object wrapper software to enable their GIS product to perform in an interoperable way.

OBJECT MODELLING AND ENCAPSULATION

Object Modelling

Spatial objects are described for modelling purposes in two different contexts (i) structural object-orientation, (ii) behavioural object-orientation (Gunther, Lambert, 1994). A structurally object-oriented data model defines the objects within a hierarchy as complex, structured and molecular objects. These are "geometric objects" to describe the geometric features which are composed of elementary geometric objects (Point, Arc, Region) under the Geometry object class. Some objects may be embedded in other objects or some objects may be shared objects included in more than one object simultaneously. A Behaviourally object-oriented model supports user-defined types (and their associated operators) which are objects with special functions and/ or attributes. These are "thematic objects" which refer to the representation of real-world objects. Certain objects may belong to multiple classes, hence have multiple inheritance of behaviour along the object class hierarchy.

Scholl and Voisars (1992) also describes a structural object-oriented model as a collection of geometric base types which include the object classes Point, Arc and Region under their object class Geometry. The corresponding plural classes are Pointset, Arcset and Regionset, the spatial representation of an object is inherited from the type Geometryset.

The models of spatial objects can be built as "entity based" models which deals with identifiable entities (objects) defined with a geographic reference (Egenhofer and Frank, 1992). In general the "field based" models deal with the spatial distribution of certain spatial/ environmental values (such as topographic heights, rainfall or temperatures, etc. data over a grid framework) (Worboys, 1994). Following these developments in GIS research the Open Geodata Model (OGD), put forward by the OGIS Part I, describes the entity based objects as "object types" and the field based objects as "event types".

The Open Geo-data Model is largely based the object-oriented technology. Object-oriented analysis and design, in general, uses three levels of modelling activity in order to create a model of the real-world objects and their behaviours (Cook and Daniel, 1994).

  1. Essential model: describes situations in the real world which is used to establish the facts about objects and events to be modelled. The building blocks of the essential model are ”object types” and ”event types”. It also describes object states and object state changes.
  2. Specification model: describes software in the abstract, ”stimulus- response” behaviour of software.
  3. Implementation model: describes the details of software execution in terms of objects communicating with each other by sending messages, patterns of control flow in the software. This model also includes the constraints imposed by the distributed computing environment, programming languages.

In this paper, object models are discussed at the essential model level.

Encapsulation

Encapsulation, inheritance and polymorphism are the three basic concepts of object-orientation, but encapsulation has a special function as far as interoperability of objects are concerned. It enables the object designer to draw a boundary around a system component, thus a component’s details are insulated from other components. As a result, the complexity of a system is reduced considerably. This is vital in handling spatial objects which usually have complex structures and details in terms of data and processing.

Each object type has "features", which is an abstraction of the real world, usually a digital representation of a real-world object as placed in space and time. Features include object’s properties, associations and operations (Cook and Daniel, 1994). Encapsulation starts by specifying which object types have access to each feature in every object type. This is a language specific function, each object-oriented language provides a facility for access control to individual features of an object. Another useful definition is the "view point" of an object type. View point is a set of features of an object type (class) which can be used by its subtype objects (clients). A view point therefore defines the access to an object type by client (sub-type) objects.

The view point becomes the unit of encapsulation defining the set of features of the object type to be accesses by its client objects. Encapsulation actually takes place when translating an object design into an implementation by using an object-oriented programming language. This activity includes creating the object in that particular language, calling operation using inheritance and defining associations (Rumbaugh, et al, 1991).

Through encapsulation the geodata set belonging to an object is hidden behind the object’s interface together with the object’s methods. Encapsulation enables an extensive data abstraction, enhances data security and facilitates application programming.

Encapsulation plays a vital role in open geodata transactions, it is the mechanism that controls the modifications to the state of an object which include the changes to the object’s data. It appears that the spatial objects of a distributed system solution involving a number of spatial databases, or the objects of the legacy and new systems can be defined as subclasses of a super class object, or of a template real-world object class then encapsulated together. In this way the spatial objects to be integrated can inherit the behaviour of the super class object and use its interface.

Therefore encapsulation becomes a pivotal mechanism in achieving interoperability of spatial objects. The definition of a spatial super class seems to be an efficient way of integrating spatial objects from different object-oriented implementations to achieve the interoperability.

INTEROPERABILITY OF SPATIAL OBJECTS

Interoperability is, generally, defined as an exchange of information and/ or processing made possible by interconnections between a number of different information systems. The difference between "integration" and "interoperability" is not a crystal clear one. Integration is the process that brings system solutions from multiple architectures together and creates a single system interface. It usually refers to programming connections between the implementation of applications and moving data from one system to another. In practice, it is implemented between the new and the legacy systems. Interoperability is, therefore, a level above the system integration (Simon, Wheeler, 1995). Interoperability should enable the users to access information and processing at different nodes in a transparent fashion. Communications, as a system component, plays a crucial part to ensure transparency between the local and remote nodes.

Interoperability is, therefore, " the ability for a system or components of a system to provide information portability, inter-application and cooperative process control". On the other hand, open geodata and geoprocessing entirely depends on satisfactory performance of distributed computing platforms which should provide networking, data security, distributed data storage and retrieval.

In an attempt to provide a common platform for open geodata and geoprocessing, the OGIS proposes and defines a "common data model" and a "behaviour operations" on that data. It is understood that compliance with this common data model becomes a must to achieve interoperability and the responsibility lies with the individual system designers. In order to enable the users of different applications to share geodata, the open geodata and geoprocessing application environments should be based on consistent implementation of the open geodata model. Particularly when comparing and correlating geodata from different sources to avoid any inconsistencies or to reduce them to an acceptable minimum depending on the accuracy level required by the application. Obviously the data models of interoperable applications should be based on a common spatial reference system and geometry, feature and meta data descriptions. The issues like how to store geodata and how to process geodata for a certain purpose are to be addressed by each individual application’s system solution.

The above explanations indicate that there is a strong necessity for a middleware/ componentware software in providing interoperability between object-oriented spatial systems in order to link the spatial objects with each other. The middleware should have the capability to transfer the requested spatial objects to another system and define them as sub-types of a certain super class object and re-encapsulate to create a composite new object. (There are new products emerging in the market to meet this demand such as Object Request Broker and GeoMedia).

OPEN GEODATA MODEL

Current situation

When encountered with the problems of data integration with other existing databases, or data migration from legacy systems various object-oriented GIS applications have been tackling these problems in a different way, due to the lack of a common methodology as a standard (Aybet,1997). However, in an attempt to fill this gap the OGC Technical Committee developed and published the OGIS (Open Geodata Interoperability Specification) Part I, which is an abstract specification as a model for the implementation specifications (McKee,1996). The OGIS put forward the OGM (Open Geodata Model) which at present constitutes a de facto standard to form a common platform for this purpose. The OCG has issued a RFP (Request for Proposals) to the technology providers/ vendors to prepare the implementation specifications for their products to comply with the OGIS. After the first set of implementation specifications have been developed the OCG’s work involves, at a more detailed level, the definition of geographic feature schema, metadata and special geo-processing requirements.

Open Geodata Model

The open geodata model is a representation of a geodata software developer’s understanding of Earth forms, systems and processes.(2) This model simulates the real world situations to be analysed and manipulated by geodata applications. The model considers two types of elements: (i) entities (objects) and (ii) phenomena (events) in space and time.

Entities are the objects with spatial extent at a certain location (e.g. land forms, lakes, landuse, buildings, etc.). Phenomena (events) occur over space and in a time duration. It is only meaningful at a certain point and within a certain time (e.g. temperature, soil composition, water quality, etc). The model uses the element "location" to represent place and time which can be surveyed or measured according to a spatial/ temporal reference system.

 

Figure 2 Location in relation to geometry

Location, in the essential model level, in relation to geometry, this is an object type view which shows that a location can have many coordinate geometries. The "aggregation" symbol in the location-geometry association indicates the relationship as "dependence of existence" that means coordinate geometry can not exist without a real world location.

The open geodata model describes a general mechanism to define "conceptual view" and a more precise "mathematical representation". A conceptual view refers to human perception of the real world objects. A mathematical representation defines the geometry of spatial extent in 2 or 3 dimensions and also in temporal dimension in accordance with a spatial/ temporal reference system.

 

Geometries in Open Geodata Model

The open geodata model defines geometric properties in multi dimensional topology as:

Zero dimensional topology: "Point", geometric location at a point.

One dimensional topology: "Curve", linear entities like line segments.

Two dimensional topology: "Surface", an entity formed by closed curves, area.

Three dimensional topology:"Solid", an entity formed by a set of closed surfaces

 

 

 

 

 

Figure 3, Geometric association in open geodata model, essential model level.

Geometry consists of (i) a sequence of coordinate points, (ii) an interpretation algorithm that constructs a geometric object from these points, and (iii) a spatial/ temporal reference system which links the this object to a real world location. It is important to note that the geometric properties of the OGM is not different from what has, so far, been adopted and used by proprietary systems as a de facto standard, expressing spatial entities as point, line and area in relation to a coordinate system.

 

Features and Coverages

The open geodata model deals with two types of geographic elements called as "Features" and "Coverages". A feature is an abstraction / representation of a real world object which can have a spatial/ temporal domain as its attributes (e.g. cities, buildings, oil wells, etc.). A coverage is a collection of points, each point carrying a value. It is a function which can return a numerical value at a certain point (terrain models, soil maps, satellite images, etc). Coverages are used to represent a phenomenon within a spatial/ temporal domain.

 

Figure 4, Open geodata model elements, features and coverages.

A feature is composed of three main parts, (i) geometry, geometric description to a spatial/ temporal reference system; (ii) semantics, properties referring to how it is defined in the lexicon, and (iii) meta data, information about the object properties data. All of the three components may not be required for each object in the model.

Features can have "sub-features" which may, in turn, contain lower level sub-features. A feature can even contain coverages. Features are recursive elements which is a very important characteristic from interoperability point of view. Because, the interoperability of spatial objects will depend on how their features are defined and how they relate and compare with each other, whether there are any inconsistencies in their contents, accuracy and resolution etc..

 

Figure 5, Open geodata model, essential model level, feature type, (after OGIS Part I).

The property types and variable names for each feature are defined in a Schema which contains feature attributes. Each feature is identified by a unique number known as Object_ID.

 

Figure 6, Open geodata model, essential model level, coverage type, (after OGIS Part I).

Coverage has two properties, one defining a geometry (collection of point locations, grid cells) and the other a function which defines the for point data values. Coverage is a collection of instances of a type according to a geometry such as a grid cell system, triangulated irregular networks, or raster images. Coverage is considered to be a subtype of feature.

CONCLUSIONS

The capability to provide transparent distributed query, information retrieval and update facilities for spatial data across a network of distributed databases is , at present, a market demand, which GIS user organisations require in order to respond rapidly changing business requirements. This capability depends entirely on the implementation of interoperable spatial information systems.

Interoperability of spatial objects, in terms of access to geodata and geoprocessing, has a great significance for a wide variety of GIS applications as business system solutions. In order to achieve an efficient level of interoperability between various spatial information systems, it appears that the software should be based on object-oriented technology, the processing and data stores should organised according to a client-server architecture, and geoprocessing should be performed on distributed computing platforms.

At present, various product developers have developed different ways and means to solve data exchange and data migration problems without any collective efforts and without a coherent direction. In an attempt to fill the lack of a set of standards to constitute a common platform, the publication of the OGIS Part I has brought an Open Data Model which provides a common approach to modelling and design of spatial objects.

The geometric properties of the Open Geodata Model are not very different from those of the conventional ones adopted and used by proprietary GIS products. Although, each product uses different terminology, in essence they refer to point/ line/ polygon entities. From this point of view, the geodata already captured by using other conventional products should be suitable to be integrated into the new systems complying with the OGM. Because protecting the investments the GIS community has committed in data capture is extremely important for the adoption, subsequent use and success of the Open Geodata Model.

We can summarise the argument developed in this paper as follows: in order to create and effectively use interoperable spatial information systems, object-orientation provides the basic tools and models of the applications. Encapsulation concept of object-orientation offers technical possibilities to access geodata of different sources. Encapsulation is also essential in order to ensure correct polymorphic behaviour of spatial objects. The spatial objects of a distributed GIS implementation using multi-vendor products can be constructed as sub-classes of a super class object, or of a template real world object class, then encapsulated together. It seems that the definition of a spatial object super class is a way of integrating spatial objects from different object-oriented implementations to achieve interoperability.

REFERENCES

  1. Aybet J, 1993, ”Use of Client-server System Architecture for the Distributed GIS Databases”, Mapping Awareness, Vol.7, No.9.
  1. Aybet J, 1994, ”The Object-oriented Approach and GIS” Part 1 & 2, GIS Europe, Vol.3, No.s 3 &4.
  1. Aybet J, 1997, ”GIS in an Open System Environment:The Current Situation” GIM, International Journal of Geomatics, Vol.11, No.2. February 1997.
  1. Buehler K, McKee L, 1996, ”The OpenGIS Guide, Part I of the Open Geodata Interoperability Specification, OGIS TC Document 96-001, OGC.
  1. Collison RW, 1995, ”Open Systems from the Perspective of the Information Systems/ Service Provider”, in Open Systems and Interoperability, ed. P Radford, Stanley Thorne Publishers.
  1. Cook S, Daniel J, ”Designing Object Systems, Object-oriented Modelling with Syntropy”, Prentice-Hall, 1994, (p.3-23), (p.313-332).
  1. Egenhofer MJ, Frank A, ”Object-oriented Modelling for GIS”, Journal of the Urban & Regional Information Systems Association (URISA), 4, 3-19, 1992.
  1. Gunther O, Lamberts J, 1994, ”Object-oriented Techniques for the Management of Geographic and Environmental Data”, The Computer Journal, Vol.37, No,1.
  1. Havinga G, 1995, ”Emerging Technologies in Desktop Computing”, in Open Systems and Interoperability, ed. P Radford, Stanley Thorne Publishers.
  1. McKee L, 1996, ”OCG Institutes RFPs for Developers and a Program for Users”, GIS World July, 1996.
  1. Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W, 1991, ”Object-oriented Modelling and Design”, Prentice-Hall, (p.296-340).
  1. Scholl M, Voisard A, 1992, ”Object-oriented Database Systems for Geographic Applications: An Experiment with O2”, in Banchillon F, Delobel C, Kanellakis P, eds. The O2 Handbook, Morgan Kaufman publishers.
  1. Simon AR, Wheeler T, 1995, ”Open Systems Handbook”, AP Professional, Academic Press ltd.
  1. Worboys M, 1994, ”Object-oriented Approaches to Geo-referenced Information”, International Journal of Geographic Information Systems, Vol.8, No.4.p.385-399.