The OpenGIS™ Guide

Introduction to
Interoperable Geoprocessing

Part I of the Open Geodata Interoperability Specification (OGIS)

by the OGIS Project Technical Committee
of the Open GIS Consortium, Inc.

Kurt Buehler and Lance McKee, editors

OGIS TC Document 96-001

The OpenGIS™ Guide

Introduction to Interoperable Geoprocessing

Part I of the Open Geodata Interoperability Specification (OGIS)

by the OGIS Project Technical Committee of the Open GIS Consortium, Inc.

Editors: Kurt Buehler and Lance McKee

Copyright 1996, Open GIS Consortium, Inc.

Open GIS Consortium, Inc.
35 Main Street, Suite 5
Wayland, Massachusetts, USA 01778
Tel: +1 508 655 5858
FAX: +1 508 655 2237

All rights reserved. No part of this document may be copied or reproduced in any manner without the expressed written permission of Open GIS Consortium, Inc.

Comments and requests for information concerning change proposals should be sent to:

Mr. Kurt Buehler
Open GIS Consortium, Inc.
PO Box 299
Spencer, Indiana 47460
Tel: +1 812 829 2248
FAX: +1 812 829 2245

Cover art by William Greenlaw.

Any trademarks used in these materials are the property of their respective owners.

The Open GIS Consortium, Inc. bears no responsibility for errors or omissions, or damages resulting from the use of information contained herein.

ISBN: (pending)

This book is dedicated to Kenn Gardels. One of the founding directors of OGC and OGC's director of academic programs, Kenn coined the term "Open GIS," which became the highest level of the specification effort described in this book. He also has provided from the beginning the high perspective of one who has devoted his life to the humane and democratic uses of GIS. For years one of the GRASS community's most helpful gurus, Kenn has brought that same spirit of community and purpose to the OGIS Project.

Table of Contents






1.1 The Problem: Geoprocessing Non-Interoperability

1.2 OGIS: An Industry-Wide Response to an Industry-Wide Problem


2.1 What Will OGIS Do?

2.2 How will OGIS Benefit Developers, Managers, and Users?

2.3 What is the Scope of OGIS?

2.4 An Open Model for Geodata, Services, and Information Sharing


3.1 Introduction

3.2 Technical Goals

3.3 How to Achieve the Technical Goals

3.3.1 Objectives for Unification of Geodata Models

3.3.2 Objectives for Unification of Geoprocessing Services

3.3.3 Objectives for Support of Inter-Community Resource Sharing


4.1 Introduction

4.2 What is Interoperability by Means of Specification?

4.2.1 OGIS is Independent of Distributed Computing Platform (DCP)

4.3 Open Geodata Model Provides a Common Spatial Language

4.4 Object-Orientation

4.4.1 Encapsulation and Interfaces

4.4.2 Implementation Inheritance versus Interface Inheritance

4.5 Clients and Service Providers in the OGIS Context

4.5.1 Introduction

4.5.2 OGIS in the Context of Evolving Client-Server Models

4.6 The Pluggable Computing Model OGIS in the Overall IT Context

4.6.1 Introduction

4.6.2 Technology Context How OGIS Relates to Non-Geoprocessing Software 4.6.3 Benefits of the Pluggable Computing Model


5.1 Introduction

5.2 An Earth Model for OGIS

5.3 Location: Place and Time

5.4 Features and Coverages

5.4.1 Feature: The More Formal Definition

5.4.2 Coverage: The More Formal Definition

5.5 Semantic Properties Attributes of OGIS Features

5.6 Open Geodata Model is Implementable with Well Known Structures

5.7 Metadata Properties of Features and Feature Collections

5.8 Geometries in OGIS Features

5.8.1 Geometry: The More Formal Definition

5.9 Spatial Temporal Reference Systems

5.9.1 Reference Systems and Coordinate Geometries: The More Formal Model

5.9.2 Transformations: The More Formal Model

5.10 Base Information Definitions and Information Communities


6.1 Introduction

6.2 Basic Assumptions

6.3 Catalogs, Traders, and Semantic Translators

6.4 The Information Community Concept - Like Human Language

6.4.1 Data Sharing Examples

6.5 Conclusions


7.1Features, Their Schema, and The Feature Registry

7.2 Access to Geodata via the Catalog

7.3 Master Catalogs and Bootstrapping

7.4 Spatial/Temporal Reference System Access and Translation

7.4.1 Spatial/Temporal Reference System Access

7.4.2 Spatial/Temporal Reference System Transformation

7.5 Semantic Translation

7.5.1 Overview

7.5.2 The FeatureTranslator Type

7.5.3 The SemanticTranslatorRegistry

7.6 Operation Registry

7.6.1 Overview

7.6.2 The OperationRegistry Type

7.7 Type Registry

7.7.1 Overview

7.7.2 The TypeFactory Type

7.7.3 The TypeRegistry Type

7.8 Traders

7.9 Queries

7.9.1 The Collection Type

7.9.2 The Iterator Type

7.9.3 The QueryEvaluator Type

7.9.4 The Query Type

7.9.5 The QueryManager Type

7.10 The Query Model

7.11 Query Service Issues

7.11.1 Query Languages

7.11.2 Query Schema






[Table Of Contents]

Table of Figures

Figure 1-1 The quantity of geodata and rate of geodata collection are increasing rapidly.

Figure 1-2 How OGIS will help structure the geoprocessing channel.

Figure 2-1 OGIS-compliant interfaces will enable geoprocessing interoperability.

Figure 3-1 OGIS removes the barriers that have confined geoprocessing in isolated, monolithic systems.

Figure 4-1 OGIS is an Abstract Specification.

Figure 4-2 With OGIS, geoprocessing can track progress in distributed computing.

Figure 4-3 Conventional and object-oriented clients and service providers.

Figure 4-4 The Pluggable Computing Model depicts interfaces essential to OGIS.

Figure 4-5 Each Pluggable Tool has algorithms, data, and interfaces to services

Figure 5-1 Location and geometric representation essential model

Figure 5-2 Open Geodata Model abstractions accommodate any conceptual view

Figure 5-3 OGIS feature essential model

Figure 5-4 More detailed essential model of OGIS Feature Type

Figure 5-5 Coverage Type essential model

Figure 5-6 Geometry essential model

Figure 5-7 Simple spatial/temporal reference system transformation example.

Figure 5-8 Spatial Temporal Reference System and Coordinate Geometry essential model

Figure 5-9 Spatial temporal transformations essential model

Figure 6-1 Catalogs list feature collections held by an Information Community.

Figure 7-1 Features, Schemas, and the Feature Registry

Figure 7-2 An abstract Catalog example

Figure 7-3 Relationships between Catalogs, Catalog Entry Schemas, and Catalog Entries.

Figure 7-4 Catalog Registry

Figure 7-5 Spatial/Temporal Reference System Access

Figure 7-6 Spatial/Temporal Reference System Translation

Figure 7-7 Semantic Translator

Figure 7-8 Semantic Translator and Registry Model

Figure 7-9 Use model for Operation Registry interaction

Figure 7-10 Operation and Operation Registry Specification Model

Figure 7-11 Use model Type Registry interaction

Figure 7-12 TypeFactory and Type Registry Specification Model

Figure 7-13 Query Service Specification Model

Figure 7-14 The Collection Specification Model

Figure 7-15 Query Model

[ Table Of Contents ] [ Using this Book]


The members of the Open GIS Consortium, Inc. (OGC) see GIS, remote sensing, automated mapping and facilities management, traffic analysis, geopositioning systems, and other geospatial technologies entering a period of radical integration.

This book is for people who want to understand how this integration will happen. It is for technology builders and technology managers working in the geospatial domain, and for technology builders and technology managers working in the larger Information Technology domain that is about to receive geospatial capabilities.

"Geodata interoperability"refers to the ability of digital systems to 1) freely exchange all kinds of spatial information about the Earth and about objects and phenomena on, above, and below the Earth's surface; and 2) cooperatively, over networks, run software capable of manipulating such information. The term "Open GIS" is the highest level of OGC's specification for geodata interoperability and the briefest summation of the work of the Open GIS Consortium, Inc. (OGC). This book, The OpenGIS Guide, is the next level of the specification, Part I of the Open Geodata Interoperability Specification (OGIS).

The Guide is not a programming manual or a pseudocode-level specification document, but it provides the conceptual foundation needed by programmers and technical managers who may soon begin, or who have already begun, implementing software to the detailed programming specification that will comprise Part II and subsequent parts of OGIS. The detailed programming specification is already available in parts and in draft form to members of OGC. Final drafts of parts of the specification become publicly available approximately six months after they are released confidentially within the Consortium. Subsequent parts of OGIS will be detailed software specifications that will give software developers explicit instructions for writing software that will exchange heterogeneous geodata and interoperate with OGIS-based software written by other developers around the world. The Guide describes the new specification model underlying those detailed software specifications.

OGIS represents the collective wisdom of the OGIS Project Technical Committee, a group of top-level geodata modellers and computer scientists whose companies and organizations send them to OGIS Project Technical Committee meetings with this mission: collaborate in building the technical foundation for 1) solving today's critical geodata sharing problems and 2) lifting geoprocessing out of its old-fashioned monolithic processing environments and closed databases up into the rapidly expanding world of componentware and distributed computing.

Kurt Buehler, OGC's chief technology officer, compiled The Guide from meeting reports and from technical papers submitted by Technical Committee members. Lance McKee, OGC's vice president of corporate communications, edited The Guide. We hope that you find it useful.

If your organization can contribute to or benefit from interoperable geoprocessing, and if your organization is not already a member of OGC, we invite you to learn more about the benefits of being part of this dynamic technical and commercial forum.

[ Table Of Contents ] >] [ Acknowledgments ]

Using This Book

The OpenGIS Guide is meant to be read by technology builders and technology managers, as stated in the Preface, who want to understand how geoprocessing fits into the emerging world of distributed objects. We hope that those knowledgeable in object technology, geometry, and geoprocessing will get from this book a clear notion of how to begin forming their distributed geoprocessing plans. For readers who are not experts in these areas, we hope that our brief explanations of the relevant aspects of these technologies will suffice to give them a clearer idea about OpenGIS and how it fits into the larger world of distributed computing.

The Preface and Acknowledgments describe the authoring of the book.

Chapter 1, the Introduction, provides an overview of the missions of OGC and the OGIS Project.

Chapter 2 gives an overview of OGIS, including a high level description of the specification, its scope and benefits, and a brief summary of the OGIS Specification Model.

Chapter 3 details the technical goals and objectives of OGIS.

Chapter 4 presents general Information Technology concepts and OGIS concepts that must be understood by anyone seeking to implement OGIS applications. OGIS-based applications will rely on underlying distributed computing architectures summarized here.

Chapter 5 presents the Open Geodata Model. Every geoprocessing system has a geodata model, a formalized system for representing geodata. OGIS defines geographic data types in the Open Geodata Model, a digital geographic lingua franca which forms the basis for interfaces that enable interoperability between systems with different geodata models. Chapters 5 and 7 are the most technical chapters in the book.

Chapter 6 presents the OGIS Information Communities Model, a set of concepts that form the basis for data integration between groups whose geographic feature definitions are based on different metadata schemas. This is an important chapter for readers interested in metadata issues and data integration.

Chapter 7 presents the OGIS Services Model, which describes client-server services that enable data transfer across OGIS interfaces, and other services and software constructs that implement concepts in the OGIS Information Communities Model.

Appendix A is a glossary of terms.

Appendix B contains the Policies and Procedures of the OGIS Project Technical Committee, originally adopted on December 20, 1994 with amendments through May 19, 1995, detailing the rules of action for the OGIS Project Technical Committee.

Appendix C contains details about OGC's organization, standards strategy, and membership policies.

Appendix D is a bibliography.

[ Table Of Contents ] >] [ Using this Book ] >] [ Chapter 1 ]


This book is a result of work done by the members of the OGIS Project Technical Committee. Their written proposals and formal discussions were recorded in the OGIS Base Document by Kurt Buehler, chairman of the Technical Committee. The Base Document provided the technical material and many of the explanations that Kurt and Lance McKee worked into the content of this Guide, and the Base Document itself will become Part 2 of OGIS, the formal specification. Every written proposal and formal discussion, of course, is preceded by hours of informal discussion and email correspondence.

John Herring, before and since joining Oracle Corporation, has been one of the Technical Committee's guiding lights. John has applied his background in mathematics, geodata modeling, and computer science to the problem of creating a comprehensive Open Geodata Model (OGM). He has led the OGM Working Group with expertise, diligence, and patience. OGIS is full of his knowledge and ideas.

Cliff Kottman, until recently Intergraph's OGIS Project Management Committee representative, and now MITRE's OGC contact, was an early Open GIS proponent whose industry perspective and enthusiasm were critical in getting OGC started. We all owe a great debt of gratitude to him and to the others at Intergraph who continue to contribute their expertise and enthusiasm to the OGIS Project. Cliff combines great creativity and solid business sense with an encyclopedic knowledge of geodata modeling and geodata standards, and he has brought both technical knowledge and breadth of experience to the Technical Committee. Cliff, Ron Lake of Affine Systems, Ron Carlson of MITRE, Robin Fegeas of USGS, and Jim Farley of OGC and the University of Arkansas/CAST were the main creators of the Information Community model which outlines the ways in which data sharing and data integration will take place in a world of high bandwidth networks linking OGIS-enabled software resources.

Harry Niedzwiadek, Director of Technology, Intelligence, Information and Imagery Systems at GTE Government Systems, helped give OGIS the software engineering foundation it needs to be solidly implementable. Also, Harry has carried the torch for the Earth imaging community in the OGIS Project. As chair of the OGIS Project Management Committee's new Earth Imaging Subcommittee, which he organized, he has the platform he needs to lead the initiative for OGIS-leveraged integration of Earth imaging with other geoprocessing technologies as well as with emerging distributed computing technologies.

Allan Doyle has been BBN's OGC connection, and Allan's clear and accurate view of how geoprocessing becomes integrated into information systems has been very important to the process. Carl Reed, President of Genasys and a veteran GIS programmer, besides being a strong Technical Committee contributor, has been responsible for Genasys' strong support of OGC from the beginning. Allan and Carl are the Technical Committee's representatives on the Management Committee.

John Davidson of Genasys has done a yeoman's job of chairing the OGIS Services Architecture Working Group, and has himself made a number of significant proposals to that working group.

Edmund Mesrobian of UCLA's mathematics department has contributed greatly to the OGIS Project through the early prototyping he and his colleagues have done to develop OGIS capabilities for their NASA-funded digital library project.

Joe Cardinale of Autometric contributed time, expertise, and enthusiasm.

Dave Case of Applied Research Corporation is the chair of the Technical Committee's new Earth Imaging Working Group. A special thanks to Dave, also, for compiling the glossary for this book.

The Technical Committee formed an Editorial Board to review the Guide. Dave Abel, Carl Cargill, Dave Case, Jim Farley, Kenn Gardels, John Herring, Cliff Kottman, Ron Lake, Harry Niedzwiadek, Steve Van Scoyk, and Charles Roswell provided valuable input on three drafts of the book.

Cliff Behrens, principal investigator for geospatial technologies at Bellcore, is responsible for the creation of the USDAC, an OGIS-centered consortium to build interoperability capabilities for NASA. Cliff has been an important and dependable participant in the work of the Technical Committee.

Paul Scarponcini of GDS and J.P. Lauzon of ESRI have contributed important working papers to the Technical Committee, and their participation in the process has been extremely valuable.

Steve Van Scoyk of Lockheed Martin joined the effort recently, bringing technical understanding, years of relevant experience, and a solid ability to get things done.

A special thanks, also, to all those at Genasys, Autometric, BBN, SAIC, Intergraph, UC Berkeley, SAIC, MacDonald Dettwiler, NOAA, Sun, Oracle, GDS, and MITRE who hosted Technical Committee meetings, providing hospitality for an itinerant band of technologists. This book is a product of the meetings that they made possible.

[ Table Of Contents ] [ Next Chapter ] [ Next Section ]

1. Introduction

1.1 The Problem: Geoprocessing Non-Interoperability

Geographic data, or "geodata," data which describes phenomena directly or indirectly associated with a location (and time, and orientation) relative to the surface of the Earth, has been collected in digital form for more than 25 years. The overall rate of collection increases rapidly with advances in technologies such as high resolution satellite-borne imaging systems and global positioning systems, and with the growing number of people and organizations who are collecting and using geodata. That number will continue to grow with the growing awareness among information technologists that indexing data by location is a fundamental way to organize and use digital data.

Figure 1-1 The quantity of geodata and rate of geodata collection are increasing rapidly.

During these 25 years, many different methods for acquiring, storing, processing, analyzing, and viewing geodata have been developed, mostly independently from one another. "Geodata" refers in this book to the full spectrum of digital geographic data. Examples include:

Geodata formats tend to be complex, more complex than other kinds of digital data formats, because of the range of information they must be able to represent. Usually, the complexity that begins with the underlying digital format imposed by a particular software application or acquisition method is incremented by the complexity of higher level descriptions, conventions, and rules imposed by the individuals, organizations, and disciplines using the software.

The software that uses and produces geodata is itself varied and complex. We define geoprocessing to be any kind of digital computing that uses geodata, including: geographic information systems (GIS), land information systems (LIS), Earth imaging and image processing, storage of geodata in databases of all kinds, digital surveying methods, navigation, meteorology, seismology, CAD that uses geodata (as in facilities management and civil engineering), transportation management, digital cartography, business geographics, flight simulation, and others. Geoprocessing software helps users answer questions such as: Where is something located? Where is a certain condition or pattern of spatial relationships found? What has changed in a given span of time? What is the best route? What if certain conditions were changed?

Integrating geodata from various sources is increasingly important because of growing environmental concerns, pressures on governments and businesses to perform more efficiently, and simply because of the existence of a rapidly growing body of useful geodata and geoprocessing tools. Data sharing makes sense for the simple reason that there is only one Earth, and we share it. All the examples of geodata listed above could refer to geographic features within the same city. There is only one Spain in terms of geographic region, but there are many Spains in terms of digital thematic maps representing different physical, cultural, and economic themes. In many areas of human endeavor, people want to acquire specific thematic maps and combine them with other thematic maps in a GIS to accomplish tasks like those suggested in the examples above. We must share data, but sharing data is a cumbersome, daunting, frustrating, error-prone, sometimes totally impractical task.

Consider this hypothetical but realistic example: If the U.S. Environmental Protection Agency (EPA) collects information about soil pollution at sites in Worcester, Massachusetts, why shouldn't the Worcester Heath Department (WHD) or the Massachusetts Environmental Protection Department (MEPD) be able to get that information and use it for their own analyses and reports, using their own computers?

Here are some reasons:

  • 1) The three agencies might use three different GIS software platforms that produce and use three different digital data formats. That is, the digital formats are different in much the same way that AutoCADª and Microsoft Excelª graphics formats are different. This is the "data transfer" problem. In this "heterogeneous GIS platforms" scenario, it's cumbersome to translate the EPA's data into a format that the MEPD or WHD can use, but it can be done (today, in the pre-OGIS world) using translators supplied by one or more of the three software platform vendors. Some of the information in the EPA's data will probably be lost, in the same way that information would be lost in translating between AutoCAD and Excel, because there is not a perfect union between the two systems' sets of representational capabilities.
  • 2) Suppose all three agencies are happily running the same version of the same GIS software (on the same operating system on the same hardware platform, just to rule out some other potential technical obstacles). We can be almost certain that the EPA will have gathered its information using methods and standards at least slightly different from those of the state and local agencies. So, unfortunately, if the MEPD and the WHP have independently gathered site pollution information, they cannot responsibly merge it immediately with the EPA data. Perhaps temperature and soil moisture content are routinely recorded by the MEPD but are not recorded by the EPA, though all other sampling parameters are the same. The MEPD recipients of the data will need to adjust their analyses to account for this deficiency. Or perhaps the temperature is recorded in Celsius by the EPA, but the WHD uses Fahrenheit measurements, and the EPA has standardized on a longitude/latitude coordinate reference system, and the MEPD has standardized on a state plane coordinate reference system. Coordinate reference system conversion can be executed by the software, and so can temperature conversion (perhaps with a bit of macro programming), but this will nevertheless be tedious and it may introduce errors. Perhaps the EPA begins collecting soil moisture data, and documents its method, but there are several ways to measure and represent soil moisture, and the collection method for the data collected previously by the WHD was not documented. How does this affect the WHD's estimation of possible error in their data?
  • 3) Institutional, economic, and legal obstacles: Does the EPA maintain and publish "metadata," (data about its data) including reference system, soil sampling parameters, and method of measuring soil moisture? Does the EPA expect recipients of their data to have half-inch tape drives, CD-ROM, or World Wide Web access? Should the EPA charge a price that reflects the cost of acquiring and managing the data, and after the WHD buys the data, can it share that data with a private consultant?

    This simple example suggests why governments in the U.S. spend more than $4 billion yearly on data conversion. The European Community, more heterogeneous in its institutions than the U.S., faces data sharing difficulties even more perplexing. We broadly refer to these obstacles as "non-interoperability." Around the globe, wherever geodata is produced and used, people face these problems.

    [ Table Of Contents ] [ Previous Section ] [ Next Chapter ]

    1.2 OGIS: An Industry-Wide Response to an Industry-Wide Problem

    The Open GIS Consortium, Inc. (OGC), a not-for-profit trade association dedicated to promoting new technical and commercial approaches to interoperable geoprocessing, was founded in 1994 in response to wide-spread recognition of the problem of non-interoperability and its many negative ramifications for industry, government, and academia. The members of OGC share a positive vision of a national and global information infrastructure in which geodata and geoprocessing resources move freely, fully integrated with the latest distributed computing technologies, accessible to everyone, "geo-enabling" a wide variety of activities that are currently outside the domain of geoprocessing, opening new markets and giving rise to new kinds of businesses and new benefits to the public. Geoprocessing software vendors, database software vendors, visualization software vendors, system integrators, computer vendors, telecommunications companies, universities, information providers, and federal agencies have joined the Consortium to participate in creating a software specification and new business strategies that will help solve these problems and fulfill these potentials.

    OGC's software specification is the Open Geodata Interoperability Specification (OGIS), a comprehensive specification of a software framework for distributed access to geodata and geoprocessing resources. OGIS will give software developers around the world a detailed common interface template for writing software that will interoperate with other OGIS-compliant software written by other software developers. As explained in the remaining chapters of this book, the OGIS framework includes three parts:

    OGIS will be developed and released in parts over several years. Part 1 is this book, The OpenGIS Guide. Subsequent parts are and will be more detailed programming specifications. Various members of OGC are interested in distributed computing based on various current and competing distributed computing platforms (DCPs), including the Common Object Request Broker (CORBA) from the Object Management Group (OMG) and the associated OpenDoc component model from the CI Labs consortium; Object Linking and Embedding/Common Object Model (OLE/COM) from Microsoft; Distributed Computing Environment (DCE) from the Open Software Foundation (OSF); Java from SunSoft; and others. For this reason, OGIS must remain abstract enough to be implementable in all of these environments. OGIS provides an extremely fine-grained description of what must be implemented, but it does not specify, in reference to any particular DCP, how the software is to be implemented. In this sense it is an abstract specification rather than an implementation specification.

    Figure 1-2 How OGIS will help structure the geoprocessing channel.

    Figure 1-2 illustrates how OGIS builds on a base of telecommunication technology and client-server technology (which includes DCP technology). The OGC consensus process produces OGIS, a standard interface that enables software vendors to produce "plug and play" geodata access and geoprocessing tools that integrators can use to build tailored geoprocessing functions into information systems. The world of computing is moving towards componentware and network-based computing, and OGIS interfaces make it possible for geoprocessing to be part of this progress.

    Under the guidance of its board of directors, OGC's staff manages the OGIS Project, in which business and technical decisions are made by a formal consensus process involving a Management Committee, a Technical Committee, and a Testbed Program. Organizational details and membership information are included in Appendix C, along with details describing how OGIS is on track to become a formal international information technology standard.

    Prior to OGIS becoming a de jure standard, vendors and OGIS participants will have implemented it widely in commercial software products, commercial integration projects, government data centers, and academic research settings, making OGIS a de facto standard for interoperable geoprocessing. Because it addresses geoprocessing transactions and geodata sharing in a comprehensive and basic fashion, it is likely that OGIS will be the basis for interoperable geoprocessing for a very long time into the future.