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.
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:
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)
1. INTRODUCTION
1.1 The Problem: Geoprocessing Non-Interoperability
1.2 OGIS: An Industry-Wide Response to an Industry-Wide Problem
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. OGIS PROJECT TECHNICAL GOALS AND OBJECTIVES
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. IT FOUNDATIONS OF INTEROPERABLE GEOPROCESSING
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.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.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. OGIS INFORMATION COMMUNITIES MODEL û MANAGING DATA HETEROGENEITY
6.1 Introduction
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.1 Overview
7.5.2 The FeatureTranslator Type
7.5.3 The SemanticTranslatorRegistry
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
APPENDIX B. POLICIES AND PROCEDURES OF THE TECHNICAL COMMITTEE
APPENDIX C. OGC BACKGROUND AND MEMBERSHIP INFORMATION
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 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-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
[ Table Of Contents ] [ Using this Book]
Preface
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 ]
Acknowledgments
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 ]
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.
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: