24

GIS interoperability
M SONDHEIM, K GARDELS, AND K BUEHLER

The term ‘interoperability’ has a range of meanings, but all focus on the ability to move
easily from one system to another. This chapter reviews various strategies that may be used
to achieve degrees of interoperability, including common exchange formats, conversions,
common interfaces, and common database models. Geographical data modelling lies at the
core of the interoperability issue, since agreement is needed on the representational
framework. The chapter also covers issues of geographical metadata, common catalogues,
and other tools to support search and retrieval across systems.

1 INTRODUCTION 2 GENERAL NOTION OF INTEROPERABILITY

Interoperability has been a goal of the computer Where applications require more than the operations
industry for years and is essentially one view of the available on a single desktop and dataset, data users
push for open systems. The term ‘open systems’ and providers must achieve a new set of objectives
usually implies the intention to adhere to vendor- regarding heterogeneous data and distributed
neutral computing standards, with the added benefit computing resources.
of producing a more level playing field among
● Data producers must ensure that their data are
software and hardware companies. As a means of
readily accessible and understandable to potential
achieving open systems, interoperability has centred
data consumers.
on common communications infrastructures,
● Users must be able to identify and locate relevant
application programming interfaces in the public
information, and know whether a given set of
domain, and a common architecture for defining
data is germane to their work.
objects and transporting them across networks.
● Queries to dispersed sites must be formulated and
Open computing and interoperability are as vital to
processed in a manner meaningful to both data
geographical information systems as to any other
server and application client.
area of information technology.
● Geodata from one source must be capable of
In the GIS arena interoperability has been a
being integrated with data from another, in terms
serious concern since the late 1970s. Problems with
of both structure and semantics.
incompatible computing environments have been
● Display and analytical functions must be
compounded by the inherent complexity of
associated with particular data models and made
geographical information and the many ways in
available to the requester.
which it can be modelled. Nevertheless, some
interoperability schemes are viable today, and In some situations, meeting these requirements is
more powerful ones are under development. relatively straightforward: a distributed application
This chapter reviews the general notion of may be designed in a top-down fashion across an
interoperability, strategies for GIS interoperability, enterprise, based on common technology and a
geospatial data models, and high-level concepts common semantic framework. The enterprise
about information sharing. standardises on a given technical infrastructure,

347
M Sondheim, K Gardels, and K Buehler

typically provided by a single vendor or systems how given data types and values in the input stream
integrator. Individuals in the enterprise use a should relate to data types and values in the output
distributed database and associated applications, stream (Figure 1). Consequently, where the input
built on a limited set of data models and targeting and output data models are dissimilar, a good match
particular business needs. This approach of common may not be possible, resulting in loss of information.
semantics and technology may be scaled up to Often such translators are most successful when
include a group or community of organisations as tailored for specific datasets.
long as all of the participants are willing and able to A more powerful approach to translation is
adopt the new system. Although such scenarios meet shown in Figure 2. In this case the software
the primary goals of interoperability, they are maintains an internal data model which is
usually described as integrated systems, rather than semantically more rich than either the input or
interoperability solutions. output models. The input data types and values are
Interoperability usually refers to bottom-up mapped to types and values of this internal model.
efforts (Litwin et al 1990), neither imposed by a The transfer data types play essentially the same role
central authority nor driven by a single application. as a common format; however, in this case, the
The systems and data models found among the users intermediary form is a transient in-memory
are heterogeneous, having been developed representation. Once the data are in the transfer data
independently of one another; consequently, systems types, they may be redefined if desired through a
re-engineering may be required to meet basic series of transformations and geoprocessing steps
interoperability requirements. Two significant available in the translation software. The software
challenges must be met: may even support feature redefinition in which a
number of input features define a single output
1 the autonomous systems must be able to
exchange data and to handle queries and other feature, or vice versa. Practically, it becomes possible
processing requests; to consider very different input and output models
2 they must be able to make use of a common and to infer matches impossible with direct
understanding of the data and requests. correlation. This kind of processing may be termed
smart translation or semantic translation.
The first requirement implies that a common set of Consider forest stand data in a given system with
services must be universally available and accessible the attributes stored partly in labels and partly in
through network communications. The second column-aligned ASCII tables, and with the area for
dictates that a common formal language and a each stand represented by a point and a set of
common model representation be used (UCGIS bounding arcs which are also shared by the adjacent
1996). The semantics of the data, as conveyed areas. Now assume that the data are desired in
through the language and model, are either used another system where each area is represented as an
directly by each system, or are transformed to local independent polygon with no inside point, and with
semantic constructs which can be interpreted all attributes in a dbf file (a common standard file
directly by the users’ applications. format for databases). Additionally, users may want
to simplify the line work and amalgamate small
polygons with their most similar neighbours. It may
3 GIS INTEROPERABILITY STRATEGIES also be desired to take a series of forest stand files,
turn them into a seamless coverage, and then clip the
3.1 Direct translation result to a given watershed boundary. To carry out
Over the last two decades, much practical such translations is not possible with the first
interoperability work has boiled down to exchanging architecture, but is with the second.
geographical and computer-aided-design data by
using bi-directional translators operating on vendor-
specific data formats. The architecture of most
translators amounts to a data reader, a correlation Input data Output data
[correlated to, 1+:1]
table defining the correspondence between input and types and values types and values
output data types and a writer. The correlation table,
which may be hard-wired into the translator, defines Fig 1. Simple translation through correlation.

348
 GIS interoperability

Input data Input transfer data

types and values [1+:1]
types and values

[optionally redefined to, 1+:1+]

and/
Output transfer data or Output data
[1+:1]
types and values types and values

Feature manipulation

Fig 2. Semantic translation through feature manipulation and correlation.

Regardless of architecture, direct translation as a government agency receiving topographic data

depends on the ability to read and write commercial from private contractors in a neutral format (IEF in
formats. Some vendors have made their format Israel or MOEP in British Columbia). Some have
specifications publicly available, but others have not. been designed to work within given disciplines or
In the latter case, reverse engineering may be areas of endeavour. The International Association of
possible, but long-term maintenance of the Geodesy and other groups working with the Global
translator may be costly because of undisclosed Positioning System (GPS: see Lange and Gilbert,
format changes by the vendors as their products Chapter 33) recommend use of the receiver
evolve. Another option for vendors is to provide independent exchange format (RINEX) for the
software interfaces (application programming exchange of GPS data for post-processing. The
interfaces, APIs) to their data management International Hydrographic Organisation has
applications, as discussed in section 3.3. developed S–57 as a transfer standard for digital
hydrographic data, with the long-term intention of
replacing traditional nautical charts around the
3.2 Common transfer format
world with electronic navigation charts supplied in
A variation of simple translation is the use of a S–57 format.
basic format such as DXF or DLG (for a more Other loss-less file-based efforts have been much
detailed discussion of exchange standards see Salgé, more general in intent and have included sophisticated
Chapter 50) as part of a two-step process. Data in data models for geographical data. A clean separation
System A format are first translated to the is made between the logical model and the data
intermediate format and from there a second encoding, the physical representation in a file. The
translation converts them to the System B format. Spatial Data Transfer Standard (SDTS) is a standard
As used, these basic formats represent a lowest from the US government (US Geological Survey 1996)
common denominator between the two end systems, that provides a logical data model and a physical
possibly resulting in information loss. Additional encoding (ISO 8211). Sponsored by the Digital
limitations are that there may be no means of Geographic Information Working Group, associated
including the definitions of the types of data within with NATO, the Digital Geographic Information
the file, of handling metadata, of addressing Exchange Standard (DIGEST) is a collection of file
updates, or of translating some kinds of data at all. exchange standards for different types of data (Digital
A number of efforts have centred on developing Geographic Information Working Group 1995a). It
loss-less file exchange standards, based on non- has many similarities to SDTS and also refers to ISO
proprietary file formats. Some of these standards 8211 for encoding. The Spatial Archive and
have been aimed at resolving specific problems, such Interchange Format (SAIF) is a Canadian standard

349
M Sondheim, K Gardels, and K Buehler

based on an extensible, object-oriented paradigm and Work has also been underway to extend the
a formal modelling language (Geographic Data BC data-centric view of files to a more processing-centric
1995). SAIF makes use of a zipped ASCII encoding view. A technical committee of the Comité Européen
which also allows for the direct inclusion of binary de Normalisation (CEN) is examining geographical
data. SDTS, DIGEST, and SAIF all provide support information (CEN/TC 287 1996) with the intent of
to developers through APIs to data files in their developing a transfer method based on a data model
respective data encodings (see section 3.3). and encoding, as with the standards described above.
Using the approach of a common format, each However, it also makes use of EXPRESS
type of data holding is mapped to a common model, (ISO 10303-11), a relationally-oriented language
as manifest in a common format. Figure 3 shows appropriate for handling traditional attributes.
some typical situations where the geometry and Through EXPRESS, query and update operations
traditional attributes may be stored together or may be supported. Another committee (ISO/TC 211)
separately. As well, different data models may exist under the auspices of the International Organisation
in each of these cases; for example, Model 2 and for Standardisation (ISO) is working on an approach
Model B may be quite dissimilar, even though they similar to that of CEN (ISO/TC 211 Secretariat
have similar implementations. The figure also shows 1996), but with the intention to include operators
the common model as implemented in a single file of and services to enable logical model to logical model
a given format. Although this may be the case, an transformations. As a separate endeavour, the
alternative is a series of files in given formats FMEBC (Geographic Data BC 1996) is a
associated with particular types of data. sophisticated translation software package associated
Use of a common format typically involves two with the SAIF standard and specifically SAIFLite
operations: translating a file in a given format to an
(a pared-down version of SAIF for operational use).
intermediary file in a common format, and then
Through a scripting language, the FMEBC supports
translating that intermediary file to a third file in the
model-to-model transformations, geometric
desired format. Only one step is required, of course,
restructuring, geometric and semantic filtering,
if the data are available in the common format, or if
datum and projection transformations, various
the common format is the desired format. Carrying
quality control operations, clipping, overlay etc.
this argument one step further, if the start and end
formats are identical then translation is never
required. In fact, there are many situations where 3.3 Published interfaces
Format X to Common Format to Format X is
worthwhile, if the translation software provides Moving away from files, formats and encoding
quality assurance benefits or simply redefinition entirely, attention now turns to interoperability
within the same format. through interfaces. With such an approach, the

Model 2
Model 1
Associated files Model 3 Model 4
Single file for
for geometry File for geometry File for attributes
all data types
and attributes

Common model, common format, single file

Model B
Model A
Associated files Model C Model D
Single file for
for geometry File for geometry File for attributes
all data types
and attributes

Fig 3. Data exchange through a common data model and format.

350
 GIS interoperability

internal structure of the data is irrelevant; instead, Two significant components comprise the
the emphasis is on the behaviour presented by the OpenGIS Specification: the Open Geodata Model
interface. In other words, the interface is able to (OGM) and the Services Architecture. The OGM is a
provide or accept data in response to a request. How collection of data types and methods, organised into
it does so does not matter. There is no assumption a hierarchical class library. It is comprehensive, in that
that the data behind the interface must match the it embraces fundamental geospatial (and ultimately
data provided to it or by it. Instead of making the spatio-temporal) data types, including their geometric
specification of a proprietary format publicly representation, spatial reference, and semantic
available, vendors may choose to develop an API content. The Services Architecture provides the
and to allow other developers to read and write their mechanism by which individual objects and their
data through the API. An API can hide complexity, associated interfaces may be assembled into complex
provide a number of capabilities supported by the queries, transformations, analytical functions, and
application, and lessen the chances of inadvertently presentation directives. It also enables the
degrading database integrity. Moreover, it can be construction of catalogues that allow users to
designed to respond to queries as part of a data identify, evaluate, and interpret complex geographical
access server. Translation software, as well as other information dispersed throughout a network.
applications, may interface to data holdings through Figure 4 shows a common interface for each of a
an API (see also Worboys, Chapter 26). number of data stores and applications. When a
Although APIs offer obvious advantages, they request is made by an application, it travels to the
also have several disadvantages. They may be very interface of a data store or another application. The
dependent on particular technological environments, interface returns the requested information as
thus limiting their use in general interoperability containers of information (encapsulated objects or
scenarios. Because of marketing and engineering components), in accordance with a distributed
considerations, most APIs cannot operate computing platform (DCP) specification. Such
independently of the main GIS application. Thus, if DCPs have been defined in Unix, Microsoft, and
proprietary data files can be detached or exported operating system independent environments.
from a GIS and shipped to another system, the Examples include the Common Object Request
receiver will not have access to the source vendor’s Broker Architecture (CORBA) from the Object
API to help read the data. Only some GIS products Management Group and the associated OpenDoc
have associated APIs, and typically, those that are component model from the CI Labs consortium;
available have not been created to any standard Object Linking and Embedding (OLE), Common
specification. Data received through different vendor Object Model, Distributed Common Object Model
APIs may conform to very different models, making and Active X from Microsoft; and Java and Java
integration of the data problematic. Beans from SunSoft. Consequently, the OpenGIS
An alternative approach to achieving Specification must be sufficiently abstract to be able
interoperability is to develop an industry-wide to be implemented in very different technical
common interface, based on distributed computing environments (OGC 1996b).
technologies (see also Worboys, Chapter 26). This is The common interface approach will allow
the primary goal of the Open GIS Consortium disparate applications and technologies to
(OGC). Having coined the term OpenGIS, the OGC interoperate as a single system. Ideally, applications
has as its mission ‘the full integration of geospatial can be built with both data and processing
data and geoprocessing resources into mainstream components coming from anywhere on a network.
computing and the widespread use of interoperable However, to define the common interface, to
geoprocessing software and geospatial data products implement it effectively for day-to-day operational
throughout the information infrastructure’ (OGC needs, and to gain widespread acceptance of it will
1996a). The OGC is developing an interface take a long-term, concerted effort. Another potential
definition referred to as the OpenGIS Specification disadvantage is that the common interface may not
(formerly known as the Open Geodata be capable of delivering objects required for a given
Interoperability Specification). Interfaces compliant application; for example, specific data types or
with this specification can be incorporated directly subsets of the data may be of interest, but the
into new systems and built onto legacy systems. interface specification may not have addressed these

351
M Sondheim, K Gardels, and K Buehler

Legacy Legacy
Database
database file system
Common interface Common interface Common interface

Objects flow across the network following distributed computing platform specification

Common interface Common interface Common interface

Browser Catalogue Geoprocessing
application application application

Fig 4. Interoperability through a common interface.

requirements adequately. We may see vendors application area included in SQL/MM is Spatial
supporting a common interface and extending it in (ISO/IEC JTC 1/SC 21 1996). These developments
line with their particular product capabilities. As has are significant because they enable databases to store
happened with SQL (section 3.4 below), the and process a wide variety of data types, including
common interface once established may evolve over spatial data types, all in the same environment. The
time to meet increasingly varied and complex needs. enhancement of extended-relational and object-
relational databases to geospatial applications
parallels the migration of conventional APIs to
3.4 Database developments
more object-oriented designs encapsulating both
There has been a great deal of interest within the data and methods. SQL/MM Spatial and the
database world in managing atypical, non-tabular OpenGIS Specification are compatible
data, which together are considered as multimedia. standardisation efforts which will make it relatively
The SQL language, long the backbone of the easy for database vendors intending to comply with
relational database market, was originally designed the former to also comply with the latter.
to handle only tabular data (Egenhofer and Kuhn, Consequently, connectivity between different
Chapter 28; Worboys, Chapter 26). However, the databases housing geospatial data and between such
latest version, SQL3, is comparable to a full databases and other software products will become
programming language and includes the ability to practical through the common interface defined by
define abstract data types (ADT). An ADT may the OpenGIS Specification.
include functions; a polygon may have one function The different interoperability strategies described
to return its boundary and another to return the above have been developed to meet different
number of holes within the polygon. An ADT is technical objectives. Even so, there is a high degree
roughly equivalent to an object type in object- of commonality in the underlying geospatial models.
oriented technology. Instead of thinking about data STDS, the first of these developments, strongly
in a database as consisting of rows of attributes with influenced aspects of DIGEST, and both influenced
primitive domains (integers, real numbers, character SAIF. SQL/MM Spatial and aspects of the
strings, and the like), we can now include higher- OpenGIS Specification are related to SAIF, which in
level data types such as lines and polygons, each of turn was modified to mesh with new ideas brought
which may have various functions as an inherent forward by these initiatives. Even with the diverse
part of its definition. requirements driving all of these efforts, the
The creation of a standardised set of data types, underlying models have much in common. This is
based on the ADT capability in SQL3, is the basis good news for organisations wishing to use various
for the multimedia extensions known as SQL/MM interoperability strategies (see Bédard, Chapter 29;
and defined in the SQL3 language. One particular Salgé, Chapter 50).

352
 GIS interoperability

4 GEOGRAPHICAL DATA MODELLING 4.1.1 Features

A feature is a representation of a phenomenon in
Data management and analysis demand that basic object space, typically modelled through a series of
notions about data types be established through data attributes, including position. More specifically, it has
models. With geographical data this implies that a set of properties which includes its spatial
general-purpose concepts of geographical representation, manifested through a geometric object
phenomena be available, as well as definitions of and an associated spatial or spatio-temporal reference
space and time. On the one hand, such models must system. The set of properties may also include other
be practical to understand and to implement; on the properties, of a non-spatial nature. A number of these
other, they must be sufficiently sophisticated and properties, in conjunction with the feature type,
robust to describe data types applicable to a wide
establish the semantics of the feature. A road segment
range of geographical applications. The modelling
may be defined as having various attributes including
techniques used will influence the ease with which
the number of lanes, the surface material, average
such concepts can be portrayed and implemented in
different systems. traffic flows, update history, and a spatial
Geographical data modelling may make use of representation as a geometric object such as an arc or
both text-based and graphical techniques. Examples curve. The coordinates of the points defining the
of the former are INTERLIS, for data exchange of geometry, and the implied geometric shape between
cadastral data (GEOHUB 1996), Class Syntax the points, are meaningful in the context of a spatial
Notation, the data modelling language of SAIF reference system, including horizontal and vertical
(Geographic Data BC 1995), and SQL/MM Spatial data and a planar or curvilinear projection.
(ISO 1996), designed specifically for database A feature may also be composed recursively of
applications and under the auspices of the ISO. other features, such as with a road network
Graphical methods in common use include OMT composed of roads or a farm consisting of
(Rumbaugh et al 1991), the Unified Modelling agricultural fields and farm buildings. As described
Language (Booch et al 1996), Syntropy (Cook and in the next section, some types of feature pertain to
Daniels 1994), and extended entity-relationship phenomena which vary continuously over a spatial
methods such as Designer/2000 (Oracle 1996). extent, as with reflectance values in a satellite image,
Bédard (Chapter 29) has also developed an approach forest stand classification across a forest, or
with icon extensions to represent spatial and barometric pressure across a landscape.
temporal constructs. Most of these techniques are Figure 5 provides a more formal definition of a
object-oriented and provide a great deal of flexibility. feature (OGC 1966c), based on the OpenGIS
Specification and using Syntropy. Every feature has
4.1 Abstraction of geographical phenomena an object identity which must be unique over space
and time. It also has a property set, equivalent to a
Fundamental to the interoperability problem is that row in a relational database. The property set contains
different groups of users have different Earth zero to many named properties (i.e. attributes). Each
models, which in turn manifest themselves in the property may be simple (e.g. age represented as an
representation of geographical information (Mark,
integer) or complex (e.g. chemistry represented by a
Chapter 7; Martin, Chapter 6; Peuquet, Chapter 8;
series of chemical attributes), and optionally may
Raper, Chapter 5). Of significance is how perceived
have constraints restricting its possible value. Zero to
elements of the landscape are described and
many properties are geometric; associated with a
modelled, and how queries and analytical services
on such data are defined and implemented. The reference system, they specify the spatial or spatio-
most basic questions concern the conceptualisation temporal extent of the feature. Geometric properties,
of geographical entities and the space and time in which are types of properties, include coordinate
which they reside. Such entities, existing in the real geometry and may include other properties such as
world, are represented in computer systems by units positional accuracy. A feature may be associated with
of data referred to as features or geographical other features, through various relationships,
objects, which in turn may be categorised into a including spatial and temporal relationships. The
general type of object termed Feature (using the association may also indicate containment, as
OGC terminology, and equivalent to previously noted. A user may define feature subtypes
GeographicObject in SAIF). specific to his or her dataset or application.

353
M Sondheim, K Gardels, and K Buehler

Feature
Object identity Spatio-temporal Coordinate geometry
reference system

Property set

Geometric property
Name

{subset of}
Property
Name

Fig 5. Feature, after the OpenGIS Specification.

4.1.2 Coverages value for a simple or complex attribute. Such a

A point of ongoing discussion in the GIS literature function may exist explicitly as a mathematical
has been the distinction between feature concepts expression or it may simply be implied by the data
based on discrete objects, and coverage concepts type and structure.
pertaining to continuous phenomena (Peuquet Housing prices across a city could be represented
1984). In the former case, the discrete object is as a trend surface through a polynomial or thin plate
generally treated as homogeneous with respect to spline function. Breaks may exist on such surfaces,
its attribute values and usually the spatial as with a cliff on an elevation map. With either
boundaries of the object (e.g. the surface of a prices or elevation, values may be displayed as
3-dimensional object) are directly observable. Spatial contour lines or as a field of values at specific
location is often conceived as simply another locations. A typical partitioned coverage of
attribute which distinguishes a geographical object categorical thematic data shows bounded areas
from any other kind of object (Worboys, Chapter 26; treated as internally homogeneous with
1995). Sometimes traditional attributes such as discontinuities (i.e. boundaries) separating one area
average elevation and slope are derived from the from another. Thus, a forest stand map or a map of
geometry and treated as additional dimensions in countries can considered as defined by a discrete-
the multidimensional attribute space characterising valued function.
typical analyses. Error or uncertainty may be an intrinsic part of a
By contrast, a coverage (cf. the concept of a field phenomenon (Fisher, Chapter 13), as with the
discussed by Mark, Chapter 7) is a phenomenon in concentration of a given mineral calculated by a
object space modelled as an attribute range Kriging function, which produces both a predicted
(possibly complex) over some spatio-temporal surface of the concentration and an associated error
domain. Coverage concepts imply a continuous surface. These surfaces may be represented as
surface in 2- or 3-dimensional space, with a given interrelated coverages, or as a single coverage with a
attribute value characterising any point on the pair of predicted and error values as output.
surface. The concept of coverage may also be Geometrically, a simple surface may be expressed as
applied to solids (i.e. volumes), in 3-dimensional contours, as a triangulated irregular network, as a set
space. Mathematically, a coverage implies a of points at locations of interest, etc. Fuzzy
computable function. Input to the function is any boundaries on categorical maps may imply fuzzy
spatial or spatio-temporal position within a given membership; land-use categories across the landscape
spatial or spatio-temporal extent, and output is a may be represented by a set of membership functions,

354
 GIS interoperability

each giving the likelihood of belonging to a given and sixth options pose the problem of representing
category (Fisher, Chapter 13). In this case, the series the analytical functions and their programming
of individual functions may be treated as a single interfaces in a universally acceptable way.
function, with geographical position as input and a Technically this requires that an interface to a
set of likelihood estimates as output. dataset or application must not only be able to
From a modelling perspective the question is: retrieve specific values, but also be able to specify
what is the relationship between feature and parameters for an analytical method used at the
coverage? Instead of treating them as two entirely server to generate the values. Alternatively, the
separate types of objects, coverage may be modelled methods may be returned to the requesting client,
as a specialised type of feature which either explicitly encapsulated with the raw data (see Goodchild and
or implicity stores a function able to provide an Longley, Chapter 40).
attribute value for any point across a given extent.
Figure 6 presents a simplified view derived from the
4.2 Space, time, and object identity
OpenGIS Specification (OGC 1996c). For reasons of
clarity, the figure shows Geometry instead of Concepts of space and time require (1) spatial and
Geometric Property, Coordinate Geometry, and temporal reference systems and (2) geometric and
Spatial Temporal Reference System (which are temporal constructs which define position in the
inherited from Feature). context of these systems (Couclelis, Chapter 2). The
Practically, a coverage and its associated function reference systems define the coordinate space, which
can take on one of several forms: typically has either two or three spatial dimensions
and optionally a temporal dimension (Peuquet,
● a partitioned coverage with each area or patch
Chapter 8).
defined by a discrete value;
A variety of types of spatial coordinate systems
● a set of values at specific point locations and with
are in use around the world for different applications
or without breaks or surface discontinuities;
and in different areas. They include simple
● rasters of images and other similarly structured
rectangular systems used in CAD environments to
data;
Earth-related systems defined through combinations
● networked patches (e.g. triangulated irregular
of the reference ellipsoid, horizontal adjustment
networks) with associated values;
system, vertical adjustment system or surface, and
● purely analytical functions;
projection. Because of extensive standardisation
● combinations of these such as a series of patches
efforts in the geodetic realm, models of spatial
with an analytical routine pertaining to each
reference systems are quite similar in most
or all patches.
geoprocessing applications. A major exception has
From an interoperability perspective, the first four to do with linear referencing systems. Used
options should be reasonably easy to handle because extensively in road networks, they are based on
they relate to well-known data structures. The fifth driven distance from arbitrary reference points.

Feature Property set

Spatial function
Object identity Name

domain range
Coverage (input) (output)

Geometry Any type

Fig 6. Coverage definition after OpenGIS Specification.

355
M Sondheim, K Gardels, and K Buehler

Interoperability with transportation and specifically within the exploration and production
hydrological applications is complicated by the sectors of that industry. Part 4 of DIGEST
proliferation of linear referencing systems and (see section 3.2) defines the Feature and Attribute
discrepancies between positions defined in such Coding Catalogue (FACC; Digital Geographic
systems and their correct geographical positions. Information Working Group 1995b). The FACC
Time may be incorporated in two very different provides standardised definitions and codes for
ways, either as part of a coordinate system, or as a features in ten categories (Culture, Hydrography,
time, a date, a time stamp (time and date together), Hypsography. Physiography, Vegetation,
or as an interval. The time may be specified with Demarcation, Aeronautical Information, Cadastral,
respect to universal time coordinates (UTC) or a Special use, and General). It is the intention of the
local time zone. Less obvious issues of time are to Digital Geographic Information Working Group
distinguish among, and have access to, the actual that all NATO defence forces adopt these definitions
time of an event, the time of observation, the time an and use them with the DIGEST transfer format.
object first entered a data store, the time the object Originally developed by private industry and now
was modified or replaced in a data store, and the time under the auspices of the Comité Européen de
an object was retired or deleted from a data store Normalisation, TC 278, the Geographic Data Files
(Peuquet, Chapter 8). standard (GDF: European Commission DGXIII
Closely tied to those notions of time is the issue 1996) includes models of road network features
of object identity. If a river changes course, we may (Salgé, Chapter 50). GDF is playing a prominent
consider that the geometry of a river segment has role, especially in Europe, in the development of
changed, or alternatively, we may state that the intelligent transportation systems.
original segment has retired and been replaced by a Efforts are under way to create general-purpose
new segment (Veregin, Chapter 12). Such concerns geospatial information communities. Under the
are of fundamental interest to interoperability if Federal Geographic Data Committee, the National
queries about changes in the landscape are to be Spatial Data Infrastructure (FGDC 1996) is a
answered. The problem is compounded by the long-term effort to share geospatial data throughout
requirements of different applications; it may be that the USA. It has been structured around two major
a database must be able to present a number of activities: the Clearinghouse, which is a metadata
views, depending upon the context of the query. cataloguing and searching model for enabling access
to distributed geodata resources, and the Framework,
which is focused specifically on characterising a
collection of datasets that are of national interest
5 SHARING INFORMATION and whose feature attributes may be standardised
(Guptill, Chapter 49).
5.1 Information communities
Information communities (Lake 1996) are groups of 5.2 Schemas, schema fusion, and schema
users, both data providers and consumers, who share
transformation
digital data. To create a Geospatial Information
Community or GIC (OGC 1996c) typically requires A set of data type definitions, i.e. data models,
acceptance of particular feature (and coverage) constitutes a schema. It provides a systematic and
models, reference systems, and geometries. Where coherent description of the content and organisation
models from user to user are divergent, the users of a dataset or collection. It can include the
may still form a community, so long as they have the semantic representation of features, the details of
means to exchange information through an attribute names and types, the dictionary defining
interoperability strategy. the structure of geographical objects and their
A number of organisations have created spatial and non-spatial attributes, metadata
information communities around particular needs. providing a synoptic view of geographical
Three of these are briefly reviewed. The information, and a thesaurus of related terms.
Petrotechnical Open Software Corporation A government agency may define schemas pertaining
(POSC 1995) is a not-for-profit organisation funded to the types of data they collect and distribute, and
by the oil industry with the objective of establishing similarly, members of an information community
and promoting standards for information sharing may define a schema meaningful to them.

356
 GIS interoperability

Key interoperability issues include how schemas data. The catalogue may even control access through
are represented, how a given user-defined schema some sort of authentication process. A significant
relates to standardised geospatial concepts concern with catalogues is to ensure that the
(e.g. feature, reference system, geometry), and how metadata they contain is current. If the catalogue
different user-defined schemas relate to one another. includes descriptions of a large number of active
Geospatial standards provide a high degree of datasets, maintenance requires ongoing cooperation
semantic consistency insofar as fundamental from the data providers. Such cooperation is
geospatial concepts are concerned. Outside these particularly practical if the data providers are all
concepts, however, semantic consistency remains an part of an information community.
issue. Schema fusion involves creation of a common
schema capable of describing all or most
information of interest. At times a more practical 6 CONCLUSIONS
alternative is to establish a series of model-to-model
transformations, such that a given schema is The GIS interoperability strategies described in this
redefined in a way most appropriate to the recipient. chapter are not mutually exclusive. Data managers
This latter approach is more flexible but only and GIS practitioners may use them in
possible with a detailed knowledge of the respective complementary ways, as appropriate for specific
schemas and schema transformation software. environments or data holdings. Initially vendors are
likely to develop interoperability among their own
products. As pressure from specific communities
5.3 Metadata and catalogues grows and as the underlying technology matures,
Metadata, or data about data, may be used to give a both vendors and third parties can be expected to
high-level description of a data collection, including offer true, multi-vendor interoperability solutions. It
such items as the feature types, ownership, quality, is easy to imagine purchasing criteria which include
meeting specific interoperability capabilities.
lineage, spatial referencing, currency, and version
GIS interoperability developments are significant
(Guptill, Chapter 49). Metadata are intended to serve
for another reason as well: they are contributing to
many objectives, ranging from dataset documentation,
the migration away from the monolithic systems
to provision of concise definitions of the dataset’s
which have dominated the GIS market for so long.
structure and organisation, to a basis for browsing
Databases, browsers, smart translators, and
and searching (Goodchild and Longley, Chapter 40).
geoprocessing tools are now being coupled through
One of the more influential developments is the
adherence to open standards and specifications. The
Content Standards for Digital Geospatial Metadata backbone of much GIS activity is likely to be
from the US Federal Geographic Data Committee network-accessible databases, with connectivity
(FGDC 1994). The standard specifies the metadata requirements met by common interfaces. The big
content only; it does not state how such data should winners will be information communities gearing up
be stored or accessed. It also does not require that to take advantage of these new opportunities.
schemas or detailed data dictionaries be available.
A catalogue is a collection of metadata
descriptions which may apply to various levels of References
aggregation or granularity. For example, it may
pertain to collections of datasets (such as all USGS Booch G, Rumbaugh J, Jacobson I 1996 The unified modelling
language for object-oriented development. Documentation set
7.5' quadrangle maps), to a single dataset (all data Version 0.9 addendum. Santa Clara.
on a given map), or to given types of data only http://www.rational.com/ot/uml.html
(all roads on the entire series or on some subset of CEN/TC 287 Secretariat 1996 CEN/TC 287 Geographic
it). Acting as a gazetteer or index, a catalogue serves Information. http://www.statkart.no/sk/standard/cen/
as an authoritative reference on one or more data Cook S, Daniels J 1994 Designing object systems: object-oriented
collections and may include a data dictionary and modelling with syntropy. Englewood Cliffs, Prentice-Hall
formal data models. Potential data users may browse Digital Geographic Information Working Group 1995a Digital
the catalogue to determine the data’s relevance, geographic information exchange standard. Version 1.2a.
extent, cost, etc., as well as valid ways to query the http://132.156.33.161/Engineer/DIGEST_1.2a/cover.htm

357
M Sondheim, K Gardels, and K Buehler

Digital Geographic Information Working Group 1995b Litwin W, Mark L, Roussopoulos N 1990 Interoperability of
Feature attribute and coding catalogue. Version 1.2a. multiple autonomous databases. ACM Computing Surveys
http://132.156.33.161/Engineer/DIGEST_1.2a/covers/part4.htm 22: 265–93
European Commission DGXIII 1996 GDF home page. OGC (Open GIS Consortium) 1996a Vision and mission
http://205.139.128.5/ehq/gdf statements. http://www.opengis.org/vision.html
FGDC 1994 Content standards for digital geospatial metadata, OGC (Open GIS Consortium) 1996b The OpenGIS guide,
Washington DC, Federal Geographic Data Committee. introduction to interoperable geoprocessing, Part 1.
http://www.fgdc.gov/metadata http://ogis.org/guide/guide1.html
FGDC 1996 National Spatial Data Infrastructure, Washington OGC (Open GIS Consortium) 1996c The OpenGIS abstract
DC, Federal Geographic Data Committee. specification. http://www.opengis.org/public/abstract.html
http://www.fgdc.gov/nsdi2.html
Oracle Corporation 1996 Oracle Designer/2000. Release 1.3
Geographic Data BC 1995 Spatial archive and interchange
format: formal definition. Release 3.2. Petrotechnical Open Software Corporation (POSC) 1995
http://www.env.gov.bc.ca/gdbc/saif32 POSC technical information.
http://www.posc.org/technical_toc.html
Geographic Data BC 1996 Feature manipulation engine BC.
http://www.env.gov.bc.ca/gdbc/fmebc Peuquet D J 1984 A conceptual framework and comparison of
spatial data models. Cartographica. 21: 66–133
GEOHUB 1996 INTERLIS.
http://www.geo.unizh.ch/~keller/geohub.html#tagOO2 Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W
1991 Object-oriented modelling and design. Englewood Cliffs,
ISO/IEC JTC 1/SC 21 1996 SQL multimedia and application
Prentice-Hall
packages (SQL/MM) – Part 3: spatial. ISO/IEC JTC 1/SC
21 N 10441, ISO/IEC CD 13249-3:199x (E) US Geological Survey 1996 Spatial data transfer standard.
SQL/MM:MAD005. http://mcmcweb.er.usgs.gov/sdts/standard.html
ftp://speckle.ncsl.nist.gov/isowg3/sqlmm/MADdocs/ UCGIS (University Consortium for Geographic Information
ISO/TC 211 Secretariat 1996 ISO/TC 211 Geographic Science) 1996 The UCGIS research agenda: interoperability.
Information/Geomatic. http://www.statkart.no/isotc211/ http://www.ucgis.org
Lake R W 1996 Information communities support Worboys M F 1995 GIS, a computing perspective. London,
information sharing. GIS World 9(2): 72–3 Taylor and Francis

358