Open Geospatial Consortium

Submission Date: 2019-10-14

Approval Date:   2020-01-31

Publication Date:   2020-08-27

External identifier of this OGC® document: http://www.opengis.net/doc/AS/topic-0/9.0

Internal reference number of this OGC® document:    04-084r4

Version: 9.0

Category: OGC® Abstract Specification

Editor:   George Percivall

OGC Abstract Specification Topic 0 - Overview

Copyright notice

Copyright © 2020 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Abstract Specification

Document subtype:   

Document stage:    Approved

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

1. Introduction

The Open Geospatial Consortium (OGC) is a not-for-profit organization committed to making quality open standards for the global geospatial interoperability [1].

OGC offers Global, community-driven, forward-looking expertise in location.

Using location, we connect people, communities, technology, and decision making for the greater good…​

  • by specializing in making location more Findable, Accessible, Interoperable, and Reusable (FAIR); and

  • via a proven collaborative and agile process combining consensus-based standards, innovation projects, and partnership building.

The OGC Standards Development Process [2] creates several types of documents including the Abstract Specification and Implementation Standards. The purpose of the Abstract Specification [3] is to create and document a conceptual model sufficient enough to aid the creation of Implementation Standards. Implementation Standards are unambiguous technology platform specifications for implementation of industry-standard, software application programming interfaces.

The OGC uses a member and community based consensus process to define, test, edit, and approve standards for interfaces and encodings that enable interoperability of geospatial content, services, and applications.

The OGC produces multiple document types. The OGC Standards Baseline consists of the OGC documents at the highest level of consensus with the OGC Library providing additional information.

  • OGC Standards Baseline: The complete set of OGC Member approved Abstract Specifications, Standards including profiles and extensions, and Community Standards.

  • OGC Library: The OGC Standards Baseline, OGC Best Practices, OGC Engineering Reports, OGC White Papers, OGC Discussion Papers, OGC Policies and Procedures, and the OGC Reference Model (ORM).

References for Section 1

2. The OGC Abstract Specification

2.1. Overview of the Topics

The OGC Abstract Specification is comprised of a number of Topic volumes. This document (Topic 0) is an overview of the OGC Abstract Specification. Each Topic addresses a specific set of abstract models, such as for metadata or geometry, as a foundation unit upon which to build OGC standards. The complete set of Topic volumes collectively form the OGC Abstract Specification[2].

OGC Abstract Specification Topics may originate from within the OGC membership or from another authoritative Standards Development Organization (SDO) or may be joint standards activities between OGC and the authoritative SDO. An authoritative SDO is an organization which operates on a consensus basis to develop standards.

The Abstract Specification is broken into Topics in order to enable parallel development and maintenance of different topics by different Standards Working Groups (SWGs) of the OGC membership. Figure 1 shows the Abstract Specification topics grouped into categories.

1
Figure 1. OGC Abstract Specification Topics

The current topic volumes are not all written at the same level of detail. Some are mature and some are less mature. Many have been harmonized with the work of ISO / TC 211 – Geographic Information/Geomatics [1]. The level of maturity of a topic reflects the level of understanding and discussion occurred within the Technical Committee, often in collaboration with ISO / TC 211. Refer to the OGC Technical Committee Policies and Procedures for more information on the OGC standards development process.

OGC Abstract Specifications are available at http://www.opengeospatial.org/standards/as.

In Sections 2.2 – 2.7, below, some Topic Names have no corresponding Topic Number: these Names are recommended for future approval as Abstract Specification Topics.

2.2. AS Topics: Space and Time

AS Topics related to space and time along with the group tasked with maintaining each standard are listed in the following table.

Topic No. Topic Name Maintenance Organization

Topic 2

Spatial Referencing by Coordinates

Joint OGC/ISO / TC 211 document.

OGC CRS SWG

Also known as ISO 19111

Spatial Referencing by ID

ISO / TC 211 document.

ISO 19112

Topic 19

Linear Referencing

ISO / TC 211 document.

ISO 19148

Topic 21

Discrete Global Grid Systems

OGC DGGS SWG

Temporal schema

ISO / TC 211 document.

ISO 19108

2.3. AS Topics: Features, Coverages and Geometries

AS Topics related to features, coverages, and geometries along with the group tasked with maintaining each standard are listed in the following table.

Topic No. Topic Name Maintenance Organization

Topic 1

Feature Geometry (Spatial Schema)

Joint OGC/ISO / TC 211 document.

OGC Simple Features SWG

Also known as ISO 19107

Simple Features Access: Common

OGC Simple Features SWG

Also known as ISO 19125-1

Schema for Moving Features

ISO / TC 211 document.

ISO 19141

Topic 6

Schema for Coverage Geometry and Functions

Joint OGC/ISO / TC 211 document.

OGC Coverages DWG

Also known as ISO 19123-1

Tile Matrix Set

OGC WMS SWG

2.4. AS Topics: Semantics

AS Topic related to semantics along with the group tasked with maintaining each standard are listed in the following table.

Topic No. Topic Name Maintenance Organization

Rules for application schema

ISO / TC 211 document. ISO 19109

Ontology — Part 1: Framework

ISO / TC 211 document.

ISO 19150-1

Features and Geometries - Part 1 - Feature Models

OGC Simple Features SWG

2.5. AS Topics: Metadata and Quality

AS Topics related to metadata and quality along with the group tasked with maintaining each standard are listed in the following table.

Topic No. Topic Name Maintenance Organization

Topic 11

Metadata — Part 1: Fundamentals

ISO / TC 211 document.

ISO 19115-1

Metadata — Part 2: Extensions for acquisition and processing

ISO / TC 211 document.

ISO 19115-2

Topic 9

Data Quality

ISO / TC 211 document.

ISO 19157

2.6. AS Topics: Sensors and Observations

AS Topics related to sensors and observations along with the group tasked with maintaining each standard are listed in the following table.

Topic No. Topic Name Maintenance Organization

Topic 20

Observations and Measurements

Joint OGC/ISO / TC 211 document.

OGC Simple Features SWG

Also known as ISO 19156

SensorML (Conceptual Models)

SensorML SWG

Imagery sensor models for geopositioning

ISO / TC 211 document.

ISO 19130-1

Sensor Web Enablement Architecture

2.7. AS Topics: Services and Interfaces

AS Topics related to services and interfaces along with the group tasked with maintaining each standard are listed in the following table.

Topic No. Topic Name Maintenance Organization

Topic 12

Service Architecture

ISO / TC 211 document.

ISO 19119

Topic 13

Catalog Services

OGC Catalogue Services SWG

Topic 17

Mobile Location Services

OGC Mobile Location Services DWG

Topic 18

Geospatial Digital Rights Management Reference Model

3. Specification Architecting Guidelines

3.1. Purpose of the Abstract Specification

The purpose of the Abstract Specification is to create and document a conceptual model that enables the creation of the consistent, interoperable, and high-quality Implementation Standards.

Specific purposes of the Abstract Specification include:

  • To relate software and system design to real world situations;

  • To capture and precisely state requirements and geospatial domain knowledge so that all stakeholders may understand and agree on them;

  • To describe the necessary elements to define a geospatial information system;

  • To capture design decisions in a mutable form, separate from the requirements;

  • To prompt development of prototypes and proof of concept implementations;

  • To explore multiple derivative solutions economically; and

  • To master complexity inherent in geospatial data and relationships.

The Abstract Specification is used in all of these capacities. Primarily, the Abstract Specification, while being implementation-neutral, provides robust technical concepts for discussing issues of interoperability.

3.2. Relationship to external organizations

The OGC recognizes that the standards it develops depend upon connections with other SDOs. This is exemplified in the Abstract Specification, where several Topics are developed and maintained by external organizations. Of particular note is the relationship between OGC and ISO / TC 211.

ISO / TC 211 is a de-jure[2] SDO whose focus is in the field of digital geographic information. Their work aims to establish a structured set of standards for information concerning objects or phenomena that are directly or indirectly associated with a location relative to the Earth. These standards may specify, for geographic information, methods, tools, and services for data management (including definition and description), acquiring, processing, analyzing, accessing, presenting, and transferring such data in digital/electronic form between different users, systems, and locations. The work must provide links to appropriate standards for information technology and data where possible and provide a framework for the development of sector-specific applications using geographic data.

In the fall of 1998, OGC and ISO / TC211 signed an agreement establishing a Class A Liaison relationship that allows both organizations to take full advantage of the contributions of the other. Since then, the two organizations have collaborated in a number of areas. These include incorporating ISO / TC 211 documents as part of the OGC Abstract Specification as well as OGC providing OGC Implementation Standards to ISO for consideration for adoption as International Standards. The ISO / TC211-OGC coordinating group is called the Joint Advisory Group (JAG). This group meets during either or both OGC Technical Committee and ISO / TC 211 Plenary meetings.

OGC has formal relationships with other SDOs and recognizes that many fundamental principles which are part of the Abstract Specification originate and should be maintained outside the OGC. For instance, OGC Web Service standards rely upon basic web functions codified by the Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C). Thus, OGC Abstract Specification topics may originate in Authoritative Standards Organizations as defined in the OGC Technical Committee Policies and Procedures (TC PnP) [05-020r26 or later].

3.3. Approval of Abstract Specification Topics

Each Abstract Specification Topic is approved by the OGC Technical Committee and Planning Committee for adoption. The Topic might originate from an external organization, in which case members of the OGC propose the Topic for inclusion. A Topic originating in the OGC will be worked through the SWG process per the TC PnP. All Abstract Specification Topics are voted for approval using the same processes as other OGC standards per the TC PnP.

3.4. Modular Spec

The OGC Specification Model - A Standard for Modular specifications (08-131r3) – also referred to as the “Mod Spec” standard – specifies desirable characteristics of a standard that will encourage implementations by minimizing difficulty determining requirements, mimicking implementation structure, and maximizing usability and interoperability.

The Modular Specifications for Modular Systems [3] describes the logical structure behind the design of the OGC Mod Spec. The paradigm used during the writing of the specification was the view of writing a specification as part of a modular design. Most issues raised stem from a lack of understanding of the core paradigm explained in the Mod Spec standard.

3.5. Conceptual Modeling

Conceptual Modeling addresses the following questions.

  • What are the concepts of interest (things of importance) within the scope of the standard (universe of discourse)?

  • What are the relationships between these concepts?

  • What information is significant about each concept? What are their attributes or properties?

  • What are the related concepts from outside the scope?

Conceptual models are independent of implementation technology specifics.

Conceptual modeling provides these benefits:

  • Promotes consensus on the concepts, independent of implementation-specific standards;

  • Communicates the concepts and their intended meanings – easier than reading an encoding; and

  • Helps ensure compatibility between multiple implementations.

The choice of a modeling approach is optional in OGC standards and best practices. The decision is up to a submission team or SWG. The Unified Modeling Language (UML) has been used successfully by many standards developers for conceptual modeling. The OpenAPI approach has been successful in defining APIs with multiple language bindings.

3.6. Core and Simple Standards

OGC recognizes that the best standards are as simple as possible. A luxury would be if “the simple standard” could always be the first standard developed. Ideally, standard development would iterate several standards based on use cases. Less complex use cases used to create simpler standards aimed at satisfying the largest user base possible; While also addressing the need for extensibility to address more comprehensive use cases. The OGC approach to this iterative development is based on the Abstract Specification and the Modular Specification.

The market has to innovate with freedom. Through standardization, multiple organizations facing the same problem solve it in the same way. When this does not occur, this result is a “tension” between the different alternatives. where a common set of requirements must be derived and be as inclusive as possible of the solutions, while still providing the least complex solution to the problem.

The approach of iterative development is reflected in Figure 1. The process recognizes the need for broad understanding of the scope of applications when developing a new standard. Complexity may be needed for some applications. “Simple” is defined based upon the problem a community is addressing. The iterative process develops a well-defined problem space with use cases and a roadmap for standard development. Then the standard developers and initial implementers can focus on “simple first.” This requires discipline to reduce the number the edge cases that are addressed in initial work. Focusing on the main cases while designing for extensibility is an art. A standard that prohibits restrictions as future extensions violates the OGC Modular Specification policy.

2
Figure 2. Simple Ain’t Easy

3.7. OGC Innovation Guidance

In 2014, the OGC Planning Committee endorsed this statement regarding innovation and the development of OGC Standards:

"In order to simplify technical complexity and reduce implementation costs, the OGC strives to ensure harmonization within the OGC standards baseline. In an unchanging world harmonization would be easy.  However, given the realities of the diversity that comes about due to changing technology and markets, OGC must address the innovator’s dilemma of maintaining the current OGC standards baseline while simultaneously developing standards to support evolving and potentially disruptive technologies, community needs and market trends. The OGC must balance maintenance, adaptation and evolution of its standards and associated Best Practices in order to address technology change, market change, and the complexity of collaboration between different communities."

To support this challenging environment, OGC:

  • Will encourage harmonization of its standards;

  • Will extend or adapt its present standards baseline or work with its partners to adapt or extend their standards;

  • May advance new standards that overlap with or diverge from existing standards, along with guidance regarding how to evaluate and select among these options;

  • May develop harmonization techniques such as bridging, brokers, or facades to achieve interoperability within and across communities of interest; and

  • Will foster an environment that encourages fair consideration of all submissions.

The Innovation Guidance impacts the Abstract Specification in two ways.

  1. Abstract Specification Topics must also be reviewed for relevance and currency with respect to current technology trends. The Abstract Specification may not be revised as frequently as implementation standards, but it must not remain static.

  2. The Abstract Specification must be suitably fundamental in concept to provide a consistent foundation for even diverging implementation standards that solve the same problem. For instance, two methods to serve feature data to a Web browser should still both rely upon the same underlying Feature Model.

3.8. OGC Reference Model (ORM)

The OGC consensus process has resulted in the adoption of numerous Abstract Specification topic volumes (described above) and numerous implementation standards. Further, through the work of the membership, much of the ongoing effort of the OGC is harmonized with the work of other standards organizations, such as ISO, IETF, OASIS, and the W3C. In order to capture the essence of the work of the OGC in a structured manner, the OGC has developed and continues to maintain the OGC Reference Model (ORM)

The ORM supersedes the technology and architecture sections of the original 1996 OpenGIS Guide. The ORM provides an architecture framework and reference model that documents the current OGC Technical Baseline. The ORM also documents the current thinking regarding the technology and interoperability for on-going work in the OGC.

The ORM has the following purposes:

  • Provide the basis – or common semantic - for communicating, coordinating and understanding the work of the OGC;

  • Provide the foundation to Update/Replace the OpenGIS Guide;

  • Describe the OGC requirements baseline;

  • Describe the OGC architecture framework through a series of non-overlapping viewpoints: including existing and future elements; and

  • Promote the development of domain-specific interoperability architectures by providing examples.

The ORM is based on the Reference Model for Open Distributed Processing (RM-ODP, ISO/IEC 10746), a widely used international standard for architecting open, distributed processing systems. The RM-ODP provides an overall conceptual framework for building distributed systems in an incremental manner. The ORM provides an overall conceptual framework for building geoprocessing into distributed systems in an incremental manner.

Regular updates of the ORM are required for maintenance in describing the OGC specifications.

4. Future Work

There is much work remaining in the definition and approval of standards that enable interoperability for geospatial content and services. In order to continue this work with a solid foundation, the OGC Abstract Specification will continue to be a living, evolving set of documents.

5. Document History

5.1. Document contributor contact points

All questions regarding this submission should be directed to the editor or the contributors:

Name Organization

George Percivall

OGC

Carl Reed

Carl Reed Associates

Josh Lieberman

OGC

Scott Simmons

OGC

Jeff Yutzler

Image Matters

5.2. Revision History

Date Release Editor Description

1999-03-15

Cliff Kottman

Carried over previous version 98-100r1 and updated for 1999. approved February 9, 1999;

2004-10-15

04-084

Carl Reed

Changes to reflect name change, revised vision, revised mission, changes in TC Policies and Procedures.

2014-07-29

04-084r1

Carl Reed

Correct a few errors, update references, correct license. This version was prepared but never adopted.

2018-12-03

04-084r2

George Percivall

Posted for review in OGC Technical Committee, December 2018

2019-05-16

04-084r3

George Percivall

Prepared for Public Request for Comment

2019-10-14

04-084r4

George Percivall

Updated based on Public RFC. Ready for vote.


1. https://www.iso.org/committee/54904.html
2. De jure, from Medieval Latin, means from law. The term refers not only to legally protected or enforced standards but also to those that have been endorsed by an official standards organization
3. https://portal.opengeospatial.org/files/?artifact_id=68181&version=1