specification or standard consisting of a set of references to one or more base standards and/or other profiles, and the identification of any chosen conformance test classes, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. (ISO/IEC TR 10000-1)

document containing recommendations, requirements, and conformance tests for those requirements

(OGC 08-131r3)

specification that has been approved by a legitimate Standards Body

(OGC 08-131r3)

This document uses Uniform Resource Identifiers (URIs) to identify concept definitions. The URIs follow conventions specified by the OGC Naming Authority Subcommittee (http://www.opengeospatial.org/standards/na).

The definitions of concepts that are presented in the Body of Knowledge are managed by the OGC Naming Authority (OGC-NA), a subcommittee of the OGC Technical Committee. The primary role of the OGC-NA is to ensure an orderly process for Uniform Resource Identifier (URI) and Uniform Resource Name (URN) assignment for OGC resources, such as OGC documents, standards, namespaces, ontologies. The purpose of the OGC-NA is to:

The OGC-NA, therefore, is the most appropriate entity within the OGC to serve as the overseer of the OGC Body of Knowledge. There is a need, however, to recognize that the OGC-NA is not expert in everything that is presented in the OGC Body of Knowledge. Therefore, whereas the OGC-NA may serve as a control body, it will need to delegate the control function for specialist elements of the OGC Body of Knowledge to Domain Working Groups or Standards Working Groups that have expertise in those elements.

The OGC Body of Knowledge sits within the Member Support part of OGC infrastructure, as shown in Figure 1. The blue-filled boxes are those that have been implemented to date, and the grey-filled boxes are those that are under development. The OGC Body of Knowledge is represented in the diagram with a black-filled box. The Inference and Processing Layer represents a series of tools that are used to create, retrieve and update concepts and their relationships that are stored in the Virtual Knowledge Store.

The content presented by the OGC Body of Knowledge is retrieved from the Virtual Knowledge Store and is processed during retrieval to allow for presentation in a document. All of the explicit knowledge that is presented in the OGC Body of Knowledge is formally captured in the Virtual Knowledge Store as knowledge graphs consisting of concepts and their relationships. This approach makes it possible to separate content from presentation, or more specifically, it makes the explicit knowledge independent of the medium through which it is presented. The rationale for this separation of concerns between content and presentation is that the explicit knowledge that is available in the Virtual Knowledge Store can be reused by other systems to address other needs that may not have been foreseen.

OGC staff envisage the OGC Body of Knowledge being updated as follows:

The OGC-NA would consult with the following groups within the OGC before approving major revisions:

There are other Bodies of Knowledge available in related communities. The following is a list of some of those Bodies of Knowledge:

3D Tiles is designed for streaming and rendering massive 3D geospatial content such as Photogrammetry, 3D Buildings, BIM/CAD, Instanced Features, and Point Clouds. It defines a hierarchical data structure and a set of tile formats which deliver renderable content. 3D Tiles does not define explicit rules for visualization of the content; a client may visualize 3D Tiles data however it sees fit. A 3D Tiles data set, called a tileset, contains any combination of tile formats organized into a spatial data structure. 3D Tiles are declarative, extendable, and applicable to various types of 3D data. The following tile formats have been specified as part of this document: Batched 3D Model, Instanced 3D Model, Point Cloud, and Composite. This document also describes 3D Tile Styles, a declarative styling specification which may be applied to tilesets. The 3D Tiles specification for tilesets, associated tile formats, and the associated styling specification are open formats that are not dependent on any vendor-specific solution, technology, or products.

All documents relating to the 3D Tiles standard can be found on the OGC website.

The following is an essential concept in the 3D Tiles standard:

The 3D Portrayal Service Standard is a geospatial 3D content delivery implementation specification. It focuses on what is to be delivered in which manner to enable interoperable 3D portrayal. It does not define or endorse particular content transmission formats, but specifies how geospatial 3D content is described, selected, and delivered. It does not prescribe how aforementioned content is to be organized and represented, but provides a framework to determine whether 3D content is interoperable at the content representation level. More details are available in Design of this standard.

All documents relating to the 3D Portrayal Service standard can be found on the OGC website.

The following is an essential concept in the 3D Portrayal Service standard:

This OGC® Standard defines the Augmented Reality Markup Language 2.0 (ARML 2.0). ARML 2.0 allows users to describe virtual objects in an Augmented Reality (AR) scene with their appearances and their anchors (a broader concept of a location) related to the real world. Additionally, ARML 2.0 defines ECMAScript bindings to dynamically modify the AR scene based on user behavior and user input.

All documents relating to the ARML2.0 standard can be found on the OGC website.

The CDB standard defines a standardized model and structure for a single, “versionable”, virtual representation of the earth. A CDB structured data store provides for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various simulator client-devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime simulation tasks. In this case, a CDB is plug-and-play interoperable between CDB-compliant simulators. A CDB can be readily used by existing simulation client-devices (legacy Image Generators, Radar simulator, Computer Generated Forces, etc.) through a data publishing process that is performed on-demand in real-time. The application of CDB to future simulation architectures will significantly reduce runtime-source level and algorithmic correlation errors, while reducing development, update and configuration management timelines. With the addition of the High Level Architecture - -Federation Object Model (HLA/FOM) and DIS protocols, the application of the CDB standard provides a Common Environment to which inter-connected simulators share a common view of the simulated environment. The CDB standard defines an open format for the storage, access and modification of a synthetic environment database. A synthetic environment is a computer simulation that represents activities at a high level of realism, from simulation of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by super-realistic special effects and accurate behavioral models. SE allows visualization of and immersion into the environment being simulated . This standard defines the organization and storage structure of a worldwide synthetic representation of the earth as well as the conventions necessary to support all of the subsystems of a full-mission simulator. The standard makes use of several commercial and simulation data formats endorsed by leaders of the database tools industry. A series of associated OGC Best Practice documents define rules and guidelines for data representation of real world features.

All documents relating to the CDB standard can be found on the OGC website.

The following is an executable test suite related to the CDB standard:

This document describes the mapping of Earth Observation Products – defined in the OGC® GML 3.1.1 Application schema for Earth Observation products [OGC 06-080r4] (version 0.9.3) – to an ebRIM structure within an OGC® Catalogue 2.0.2 (Corrigendum 2 Release) [OGC 07-006r1].

All documents relating to the Cat: ebRIM App Profile: Earth Observation Products standard can be found on the OGC website.

The following are essential concepts in the Cat: ebRIM App Profile: Earth Observation Products standard:

Catalogue services support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects. Metadata in catalogues represent resource characteristics that can be queried and presented for evaluation and further processing by both humans and software. Catalogue services are required to support the discovery and binding to registered information resources within an information community. OGC Catalogue interface standards specify the interfaces, bindings, and a framework for defining application profiles required to publish and access digital catalogues of metadata for geospatial data, services, and related resource information. Metadata act as generalised properties that can be queried and returned through catalogue services for resource evaluation and, in many cases, invocation or retrieval of the referenced resource. Catalogue services support the use of one of several identified query languages to find and return results using well-known content models (metadata schemas) and encodings.

All documents relating to the Catalogue Service standard can be found on the OGC website.

The following are essential concepts in the Catalogue Service standard:

The following are executable test suites related to the Catalogue Service standard:

CityGML is an open data model and XML-based format for the storage and exchange of virtual 3D city models. It is an application schema for the Geography Markup Language version 3.1.1 (GML3), the extendible international standard for spatial data exchange issued by the Open Geospatial Consortium (OGC) and the ISO TC211. The aim of the development of CityGML is to reach a common definition of the basic entities, attributes, and relations of a 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields.

All documents relating to the CityGML standard can be found on the OGC website.

The following are essential concepts in the CityGML standard:

The OpenGIS® Coordinate Transformation Service Standard (CT) provides a standard way for software to specify and access coordinate transformation services for use on specified spatial data. This standard addresses a key requirement for overlaying views of geodata (“maps”) from diverse sources: the ability to perform coordinate transformation in such a way that all spatial data are defined relative to the same spatial reference system.

All documents relating to the Coordinate Transformation standard can be found on the OGC website.

The following are essential concepts in the Coordinate Transformation standard:

This jointly developed OGC and ISO TC/211 International Standard describes an XML and KVP encoding of a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression. These components are modular and intended to be used together or individually by other standards which reference this International Standard.

All documents relating to the Filter Encoding standard can be found on the OGC website.

The OpenGIS® GML in JPEG 2000 for Geographic Imagery Encoding Standard defines the means by which the OpenGIS® Geography Markup Language (GML) Standard http://www.opengeospatial.org/standards/gml is used within JPEG 2000 http://www.jpeg.org/jpeg2000/ images for geographic imagery. The standard also provides packaging mechanisms for including GML within JPEG 2000 data files and specific GML application schemas to support the encoding of images within JPEG 2000 data files. JPEG 2000 is a wavelet-based image compression standard that provides the ability to include XML data for description of the image within the JPEG 2000 data file.

All documents relating to the GML in JPEG 2000 standard can be found on the OGC website.

The following are essential concepts in the GML in JPEG 2000 standard:

The following is an executable test suite related to the GML in JPEG 2000 standard:

The GeoAPI Implementation Standard defines, through the GeoAPI library, a Java language application programming interface (API) including a set of types and methods which can be used for the manipulation of geographic information structured following the specifications adopted by the Technical Committee 211 of the International Organization for Standardization (ISO) and by the Open Geospatial Consortium (OGC). This standard standardizes the informatics contract between the client code which manipulates normalized data structures of geographic information based on the published API and the library code able both to instantiate and operate on these data structures according to the rules required by the published API and by the ISO and OGC standards.

All documents relating to the GeoAPI standard can be found on the OGC website.

The following are essential concepts in the GeoAPI standard:

A GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage standard describes a set of conventions for storing the following within a SQLite database: vector features tile matrix sets of imagery and raster maps at various scales extensions To be clear, a GeoPackage is the SQLite container and the GeoPackage Encoding Standard governs the rules and requirements of content stored in a GeoPackage container. The GeoPackage standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints. The required and supported content of a GeoPackage is entirely defined in the standard.

All documents relating to the GeoPackage standard can be found on the OGC website.

The following are essential concepts in the GeoPackage standard:

The following are executable test suites related to the GeoPackage standard:

GeoRSS is designed as a lightweight, community driven way to extend existing RSS feeds with simple geographic information. The GeoRSS standard provides for encoding location in an interoperable manner so that applications can request, aggregate, share and map geographically tag feeds.

All documents relating to the GeoRSS standard can be found on the OGC website.

The OGC GeoSPARQL standard supports representing and querying geospatial data on the Semantic Web. GeoSPARQL defines a vocabulary for representing geospatial data in RDF, and it defines an extension to the SPARQL query language for processing geospatial data. In addition, GeoSPARQL is designed to accommodate systems based on qualitative spatial reasoning and systems based on quantitative spatial computations.

All documents relating to the GeoSPARQL standard can be found on the OGC website.

The following are essential concepts in the GeoSPARQL standard:

GeoSciML is a model of geological features commonly described and portrayed in geological maps, cross sections, geological reports and databases. The model was developed by the IUGS CGI (Commission for the Management and Application of Geoscience Information) and version 4.1 is the first version officially submitted as an OGC standard. This specification describes a logical model and GML/XML encoding rules for the exchange of geological map data, geological time scales, boreholes, and metadata for laboratory analyses. It includes a Lite model, used for simple map-based applications; a basic model, aligned on INSPIRE, for basic data exchange; and an extended model to address more complex scenarios. The specification also provides patterns, profiles (most notably of Observations and Measurements - ISO19156), and best practices to deal with common geoscience use cases.

All documents relating to the GeoSciML standard can be found on the OGC website.

The following are essential concepts in the GeoSciML standard:

The OpenGIS® Geography Markup Language Encoding Standard (GML) The Geography Markup Language (GML) is an XML grammar for expressing geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. As with most XML based grammars, there are two parts to the grammar – the schema that describes the document and the instance document that contains the actual data. A GML document is described using a GML Schema. This allows users and developers to describe generic geographic data sets that contain points, lines and polygons. However, the developers of GML envision communities working to define community-specific application schemas [en.wikipedia.org/wiki/GML_Application_Schemas] that are specialized extensions of GML. Using application schemas, users can refer to roads, highways, and bridges instead of points, lines and polygons. If everyone in a community agrees to use the same schemas they can exchange data easily and be sure that a road is still a road when they view it.

All documents relating to the Geography Markup Language standard can be found on the OGC website.

The following are essential concepts in the Geography Markup Language standard:

The following are executable test suites related to the Geography Markup Language standard:

This standard defines a conceptual Geospatial User Feedback (GUF) data model (OGC 15-097) and a practical XML encoding of the conceptual model (OGC 15-098). Geospatial User Feedback is metadata that is predominantly produced by the consumers of geospatial data products as they use and gain experience with those products. The standard allows for documenting feedback items such as ratings, comments, quality reports, citations, significant events, etc. about the usage of the data. Feedback items can be aggregated in collections and summaries of the collections can also be described. This standard complements existing metadata conventions whereby documents recording dataset characteristics and production workflows are generated by the creator, publisher, or curator of a data product. As a part of metadata, the GUF data model reuses some elements of ISO 19115-1:2014 (the updated version of the OGC Abstract Specification Topic 11) but not the general structure. This selective use of ISO metadata elements prioritizes interoperability with developing ISO metadata models. The conceptual encoding is designed to be used combination with an encoding standard. Initially an XML encoding following the ISO 19139 encoding rules is specified in a separate OGC implementation standard (OGC 15-098).

All documents relating to the Geospatial User Feedback (GUF) standard can be found on the OGC website.

The following are essential concepts in the Geospatial User Feedback (GUF) standard:

The Policy Language introduced in this document defines a geo-specific extension to the XACML Policy Language, as defined by the OASIS standard “eXtensible Access Control Markup Language (XACML), Version 2.0” [1]. Due to the similarity of XACML version 2.0 to it’s predecessor versions (e.g. 1.0 or 1.1), the extension described in this document also represents a valid extension for earlier XACML versions. As being an extension to OASIS eXtensible Access Control Markup Language (XACML), GeoXACML provides support for spatial data types and spatial authorization decision functions. Those data types and functions can be used to define additional spatial constraints for XACML based policies.

All documents relating to the Geospatial eXtensible Access Control Markup Language (GeoXACML) standard can be found on the OGC website.

This standard describes a conceptual and logical model for the exchange of groundwater data, as well as a GML/XML encoding with examples.

All documents relating to the GroundwaterML standard can be found on the OGC website.

The following are essential concepts in the GroundwaterML standard:

This OGC® IndoorGML standard specifies an open data model and XML schema for indoor spatial information. IndoorGML is an application schema of OGC® GML 3.2.1. While there are several 3D building modelling standards such as CityGML, KML, and IFC, which deal with interior space of buildings from geometric, cartographic, and semantic viewpoints, IndoorGML intentionally focuses on modelling indoor spaces for navigation purposes. For more information on IndoorGML including developer resources and information on in-progress work, please visit http://www.indoorgml.net/ .

All documents relating to the IndoorGML standard can be found on the OGC website.

The following are essential concepts in the IndoorGML standard:

The following is an executable test suite related to the IndoorGML standard:

Google submitted KML (formerly Keyhole Markup Language) to the Open Geospatial Consortium (OGC) to be evolved within the OGC consensus process with the following goal: KML Version 2.2 has been adopted as an OGC implementation standard. Future versions may be harmonized with relevant OGC standards that comprise the OGC standards baseline. There are four objectives for this standards work: That there be one international standard language for expressing geographic annotation and visualization on existing or future web-based online and mobile maps (2d) and earth browsers (3d). That KML be aligned with international best practices and standards, thereby enabling greater uptake and interoperability of earth browser implementations. That the OGC and Google will work collaboratively to ensure that the KML implementer community is properly engaged in the process and that the KML community is kept informed of progress and issues. That the OGC process will be used to ensure proper life-cycle management of the KML Standard, including such issues as backwards compatibility.

All documents relating to the KML standard can be found on the OGC website.

The following are executable test suites related to the KML standard:

The LAS file is intended to contain LIDAR (or other) point cloud data records. The data will generally be put into this format from software (e.g. provided by LIDAR hardware vendors) which combines GPS, IMU, and laser pulse range data to produce X, Y, and Z point data. The intention of the data format is to provide an open format that allows different LIDAR hardware and software tools to output data in a common format.

All documents relating to the LAS standard can be found on the OGC website.

The scope of the Land and Infrastructure Conceptual Model is land and civil engineering infrastructure facilities. Anticipated subject areas include facilities, projects, alignment, road, railway, survey, land features, land division, and “wet” infrastructure (storm drainage, wastewater, and water distribution systems). The initial release of this standard is targeted to support all of these except wet infrastructure. Land provides the environment upon which infrastructure facilities exist. This standard includes division of land based on administrative (jurisdictions and districts) as well as interests in land (e.g., land parcels, easements, and condominiums). The standard also includes support for topography (terrain) as well as subsurface information. Finally, this standard regards the surveying needed to locate infrastructure facilities on the terrain in compliance with interests in land. This OGC InfraGML Encoding Standard presents the implementation-dependent, GML encoding of concepts supporting land and civil engineering infrastructure facilities specified in the OGC Land and Infrastructure Conceptual Model Standard (LandInfra), OGC 15-111r1. Conceptual model subject areas include land features, facilities, projects, alignment, road, railway, survey (including equipment, observations, and survey results), land division, and condominiums. InfraGML is published as a multi-part standard. Part 0 addresses the Core Requirements Class from LandInfra. Part 1 addresses the LandFeature Requirements Class from LandInfra. Part 2 addresses the Facility and Project Requirements Classes from LandInfra. Part 3 addresses the Alignment Requirements Class from LandInfra. Part 4 addresses the Road and RoadCrossSection Requirements Classes from LandInfra. Part 5 addresses the Railway Requirements Class from LandInfra. Part 6 addresses the Survey, Equipment, Observations and Survey Results Requirements Classes from LandInfra. Part 7 addresses the Land Division and Condominium Requirements Classes from LandInfra.

All documents relating to the LandInfra/InfraGML standard can be found on the OGC website.

The following are essential concepts in the LandInfra/InfraGML standard:

The following is an executable test suite related to the LandInfra/InfraGML standard:

The OpenGIS® Open Location Services Interface Standard (OpenLS) specifies interfaces that enable companies in the Location Based Services (LBS) value chain to “hook up” and provide their pieces of applications such as emergency response (E-911, for example), personal navigator, traffic information service, proximity service, location recall, mobile field service, travel directions, restaurant finder, corporate asset locator, concierge, routing, vector map portrayal and interaction, friend finder, and geography voice-graphics. These applications are enabled by interfaces that implement OpenLS services such as a Directory Service, Gateway Service, Geocoder Service, Presentation (Map Portrayal) Service and others.

All documents relating to the Location Services (OpenLS) standard can be found on the OGC website.

The following are essential concepts in the Location Services (OpenLS) standard:

This OGC® Standard specifies standard encoding representations of movement of geographic features. The primary use case is information exchange.

All documents relating to the Moving Features standard can be found on the OGC website.

The following are essential concepts in the Moving Features standard:

netCDF is a set of software libraries and self-describing, machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data. The conventions for climate and forecast (CF) metadata are designed to promote the processing and sharing of netCDF files. The conventions define metadata that provide a definitive description of what the data represents, and the spatial and temporal properties of the data. The OGC CF-netCDF standard consists of a suite of standards that support encoding of digital geospatial information representing space/time-varying phenomena. Although it was originally developed for the Earth science community, netCDF can be used to communicate and store a wide variety of multidimensional data. The netCDF data model and encodings are particularly well suited to providing data in forms familiar to atmospheric and oceanic scientists, specifically, as sets of related arrays. The OGC CF-netCDF standards and related documents (primer, best practices, engineering reports, etc.) are accessible from the table below. Additional Extensions to the Core standard may be specified in the future. The CF-netCDF Core and Extensions Primer provides an overview of the many possible components of the CF-netCDF suite and explains how those components fit together into a coherent whole.

All documents relating to the NetCDF standard can be found on the OGC website.

The following is an essential concept in the NetCDF standard:

This standard describes the use cases, requirements and conceptual model for the OWS Context encoding standard. The goal of this standard is to provide a core model, which is extended and encoded as defined in extensions to this standard. A ‘context document’ specifies a fully configured service set which can be exchanged (with a consistent interpretation) among clients supporting the standard. The OGC Web Services Context Document (OWS Context) was created to allow a set of configured information resources (service set) to be passed between applications primarily as a collection of services. OWS Context is developed to support in-line content as well. The goal is to support use cases such as the distribution of search results, the exchange of a set of resources such as OGC Web Feature Service (WFS), Web Map Service (WMS), Web Map Tile Service (WMTS), Web Coverage Service (WCS) and others in a ‘common operating picture’. Additionally OWS Context can deliver a set of configured processing services (Web Processing Service (WPS)) parameters to allow the processing to be reproduced on different nodes.

All documents relating to the OWS Context standard can be found on the OGC website.

The following is an executable test suite related to the OWS Context standard:

Information Assurance (IA) Controls for OGC Web Services (OWS) have been implemented for years. However, these implementations break interoperability, as they are not standardized by OGC Web Service standards. Interoperability between secured OGC Web Services and clients is limited to systems custom built to work with an IA implementation. The goal of the OWS Common Security Standard is to allow the implementation of IA controls and to advertise their existence in an interoperable way with minimal impact to existing implementations using a backwards-compatible approach. That goal is being pursued in two ways: Identify and document IA Controls for supporting authentication in a register maintained through the OGC. Specify how a service can advertise their IA controls through the Service Capabilities Document. This OGC standard applies to OWS deployed on HTTPS. It specifies how conformant OWS Services shall advertise their IA Controls and additional security features. The advertisement uses XML elements that are already part of the Capabilities document structure. This ensures that existing client implementations will not break. The standard also describes the governance process for the IA Control registers, examples of register contents, and descriptions on how this information should be used. Next, this standard defines conformance classes and requirements classes to be used for reaching compliance and their validation via conformance tests. Finally, this standard defines client behavior to ensure interoperable processing of advertised security controls.

All documents relating to the OWS Security standard can be found on the OGC website.

This standard specifies an XML implementation for the OGC and ISO Observations and Measurements conceptual model (OGC Observations and Measurements v2.0 also published as ISO/DIS 19156), including a schema for Sampling Features. This encoding is an essential dependency for the OGC Sensor Observation Service (SOS) Interface Standard. More specifically, this standard defines XML schemas for observations, and for features involved in sampling when making observations. These provide document models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities.

All documents relating to the Observations and Measurements standard can be found on the OGC website.

The following are essential concepts in the Observations and Measurements standard:

The following is an executable test suite related to the Observations and Measurements standard:

The OGC Open GeoSMS Standard provides developers with an extended Short Message Service (SMS) encoding and interface to facilitate communication of location content between different LBS (Location-Based Service) devices or applications. SMS is the open text communication service standard most commonly used in phone, web and mobile communication systems for the exchange of short text messages between fixed line or mobile phone devices. The lightweight and easy to implement Open GeoSMS Standard facilitates interoperability between mobile applications and the rapidly expanding world of geospatial applications and services that implement OGC standard interfaces, encodings and best practices.

All documents relating to the Open GeoSMS standard can be found on the OGC website.

The purpose of the Open Modelling Interface (OpenMI) is to enable the runtime exchange of data between process simulation models and also between models and other modelling tools such as databases and analytical and visualization applications. Its creation has been driven by the need to understand how processes interact and to predict the likely outcomes of those interactions under given conditions. A key design aim has been to bring about interoperability between independently developed modelling components, where those components may originate from any discipline or supplier. The ultimate aim is to transform integrated modelling into an operational tool accessible to all and so open up the potential opportunities created by integrated modelling for innovation and wealth creation. This document defines the requirements that a component must meet to achieve OpenMI compliance. These comprise: 1) a very thin core set of requirements covering the information and functions needed to establish a link and make an exchange between two components and 2) a set of optional extensions for handling more complex situations. The document does not describe how to implement the standard. This information together with a range of software tools for creating and running OpenMI-­‐compliant components are provided by the OpenMI Association and third-­‐party software vendors – visit www.openmi.org for further documentation.

All documents relating to the OpenMI standard can be found on the OGC website.

This OGC standard specifies the Geo and Time extensions to the OpenSearch query protocol. OpenSearch is a collection of simple formats for the sharing of search results. The OpenSearch description document format can be used to describe a search engine so that it can be used by search client applications. The OpenSearch description format allows the use of extensions that allow search engines to request a specific and contextual query parameter from search clients. The OpenSearch response elements can be used to extend existing syndication formats, such as RSS and Atom, with the extra metadata needed to return search results. Services that support the OpenSearch Specification, the Geo and Time extensions defined in this document are called OpenSearch GeoTemporal Services.

All documents relating to the OpenSearch Geo standard can be found on the OGC website.

The following are essential concepts in the OpenSearch Geo standard:

The following is an executable test suite related to the OpenSearch Geo standard:

This document is the specification for the OpenSearch extension for Earth Observation collections and products search. This standard is intended to provide a very simple way to make queries to a repository that contains Earth Observation information and to allow syndication of repositories.

All documents relating to the OpenSearch for EO standard can be found on the OGC website.

The following are essential concepts in the OpenSearch for EO standard:

The following is an executable test suite related to the OpenSearch for EO standard:

This OGC® standard specifies the interfaces, bindings, requirements, conformance classes, and a framework for implementing extensions that enable complete workflows for ordering of Earth Observation (EO) data products.

All documents relating to the Ordering Services Framework for Earth Observation Products standard can be found on the OGC website.

This standard defines a protocol for RS232 and Ethernet connected instruments. PUCK addresses installation and configuration challenges for sensors by defining a standard instrument protocol to store and automatically retrieve metadata and other information from the instrument device itself. Most sensor networks require careful manual installation and configuration by technicians to assure that software components are properly associated with the physical instruments that they represent. Instrument driver software, configuration files, and metadata describing the instrument and its capabilities must be manually installed and associated with a physical instrument port. Sometimes these manual procedures must be performed under physically challenging conditions, increasing the chances of human error. PUCK addresses these challenges by defining a standard instrument protocol to retrieve metadata and other information from the device itself. This information can include OGC SWE SensorML and IEEE 1451 Transducer Electronic Data Sheet (TEDS) documents, as well as actual instrument driver code. Computers on the network can use the PUCK protocol to retrieve this information from installed instruments and utilize it appropriately, e.g. to automatically identify, configure and operate the instruments. Thus PUCK enables automatic self-configuring plug-and-work sensor networks. The PUCK standard is relatively simple, and several manufacturers have already implemented the protocol in their instruments' firmware. PUCK augments but doesn’t replace existing instrument command sets, so it can be implemented without abandoning existing firmware and software applications. PUCK was originally developed by the Monterey Bay Aquarium Research Institute (MBARI) for oceanographic applications, but is useful in any sensor network containing RS232 or Ethernet-connected instruments. PUCK-enabled instruments have been deployed on ocean observatories in the USA and Europe, and the protocol is being considered for adoption by other projects as well. With the approval by the OGC membership of the OGC PUCK Protocol Standard, and with the OGC Technical Committee’s PUCK Standards Working Group in place to provide future support, the PUCK standard is expected to be adopted by an even wider sensor community.

All documents relating to the PUCK standard can be found on the OGC website.

Publish/Subscribe 1.0 is an interface specification that supports the core components and concepts of the Publish/Subscribe message exchange pattern with OGC Web Services. The Publish/Subscribe pattern complements the Request/Reply pattern specified by many existing OGC Web Services. This specification may be used either in concert with, or independently of, existing OGC Web Services to publish data of interest to interested Subscribers. Publish/Subscribe 1.0 primarily addresses subscription management capabilities such as creating a subscription, renewing a subscription, and unsubscribing. However, this standard also allows Publish/Subscribe services to advertise and describe the supported message delivery protocols such as SOAP messaging, ATOM, and AMQP. Message delivery protocols should be considered to be independent of the Publish/Subscribe 1.0 standard. Therefore, OGC Publish/Subscribe only includes metadata relating to message delivery protocols in sufficient detail to allow for different implementations of Publish/Subscribe 1.0 to interoperate. This specification defines Publish/Subscribe functionality independently of the binding technology (e.g., KVP, SOAP, REST). Extensions to this specification may realize these core concepts with specific binding technologies.

All documents relating to the PubSub standard can be found on the OGC website.

The Sensor Web Enablement (SWE) Common Data Model Encoding Standard defines low level data models for exchanging sensor related data between nodes of the OGC® Sensor Web Enablement (SWE) framework. These models allow applications and/or servers to structure, encode and transmit sensor datasets in a self describing and semantically enabled way. SWE Common 1.0 was defined in the OGC SensorML 1.0 Standard available at http://www.opengeospatial.org/standards/sensorml.

All documents relating to the SWE Common Data Model standard can be found on the OGC website.

The following are essential concepts in the SWE Common Data Model standard:

The following is an executable test suite related to the SWE Common Data Model standard:

This standard currently defines eight packages with data types for common use across OGC Sensor Web Enablement (SWE) services. Five of these packages define operation request and response types. The packages are: 1.) Contents – Defines data types that can be used in specific services that provide (access to) sensors; 2.) Notification – Defines the data types that support provision of metadata about the notification capabilities of a service as well as the definition and encoding of SWES events; 3.) Common - Defines data types common to other packages; 4.) Common Codes –Defines commonly used lists of codes with special semantics; 5.) DescribeSensor – Defines the request and response types of an operation used to retrieve metadata about a given sensor; 6.) UpdateSensorDescription –Defines the request and response types of an operation used to modify the description of a given sensor; 7.) InsertSensor – Defines the request and response types of an operation used to insert a new sensor instance at a service; 8.) DeleteSensor – Defines the request and response types of an operation used to remove a sensor from a service. These packages use data types specified in other standards. Those data types are normatively referenced herein, instead of being repeated in this standard.

All documents relating to the SWE Service Model standard can be found on the OGC website.

The following are essential concepts in the SWE Service Model standard:

The primary focus of the Sensor Model Language (SensorML) is to provide a robust and semantically-tied means of defining processes and processing components associated with the measurement and post-measurement transformation of observations. This includes sensors and actuators as well as computational processes applied pre- and postmeasurement. The main objective is to enable interoperability, first at the syntactic level and later at the semantic level (by using ontologies and semantic mediation), so that sensors and processes can be better understood by machines, utilized automatically in complex workflows, and easily shared between intelligent sensor web nodes. This standard is one of several implementation standards produced under OGC’s Sensor Web Enablement (SWE) activity. This standard is a revision of content that was previously integrated in the SensorML version 1.0 standard (OGC 07-000).

All documents relating to the Sensor Model Language standard can be found on the OGC website.

The following are essential concepts in the Sensor Model Language standard:

The following are executable test suites related to the Sensor Model Language standard:

The SOS standard is applicable to use cases in which sensor data needs to be managed in an interoperable way. This standard defines a Web service interface which allows querying observations, sensor metadata, as well as representations of observed features. Further, this standard defines means to register new sensors and to remove existing ones. Also, it defines operations to insert new sensor observations. This standard defines this functionality in a binding independent way; two bindings are specified in this document: a KVP binding and a SOAP binding.

All documents relating to the Sensor Observation Service standard can be found on the OGC website.

The following are essential concepts in the Sensor Observation Service standard:

The following are executable test suites related to the Sensor Observation Service standard:

The OpenGIS® Sensor Planning Service Interface Standard (SPS) defines interfaces for queries that provide information about the capabilities of a sensor and how to task the sensor. The standard is designed to support queries that have the following purposes: to determine the feasibility of a sensor planning request; to submit and reserve/commit such a request; to inquire about the status of such a request; to update or cancel such a request; and to request information about other OGC Web services that provide access to the data collected by the requested task. This is one of the OGC Sensor Web Enablement (SWE) suite of standards.

All documents relating to the Sensor Planning Service standard can be found on the OGC website.

The following are essential concepts in the Sensor Planning Service standard:

The following are executable test suites related to the Sensor Planning Service standard:

The OGC SensorThings API provides an open, geospatial-enabled and unified way to interconnect the Internet of Things (IoT) devices, data, and applications over the Web. At a high level the OGC SensorThings API provides two main functionalities and each function is handled by a part. The two parts are the Sensing part and the Tasking part. The Sensing part provides a standard way to manage and retrieve observations and metadata from heterogeneous IoT sensor systems. The Tasking part is planned as a future work activity and will be defined in a separate document as the Part II of the SensorThings API.

All documents relating to the SensorThings standard can be found on the OGC website.

The following is an essential concept in the SensorThings standard:

The following are executable test suites related to the SensorThings standard:

This part of OpenGIS® Simple Features Access (SFA), also called ISO 19125, describes the common architecture for simple feature geometry. The simple feature geometry object model is Distributed Computing Platform neutral and uses UML notation. The base Geometry class has subclasses for Point, Curve, Surface and GeometryCollection. Each geometric object is associated with a Spatial Reference System, which describes the coordinate space in which the geometric object is defined.

All documents relating to the Simple Features standard can be found on the OGC website.

The following are essential concepts in the Simple Features standard:

The three OpenGIS® Simple Features Implementation Specifications (one each for OLE/COM, CORBA, and SQL) define interfaces that enable transparent access to geographic data held in heterogeneous processing systems on distributed computing platforms. The Simple Feature Specification application programming interfaces (APIs) provide for publishing, storage, access, and simple operations on Simple Features (point, line, polygon, multi-point, etc). The purpose of these specifications is to describe interfaces to allow GIS software engineers to develop applications that expose functionality required to access and manipulate geospatial information comprising features with 'simple' geometry using different technologies.

All documents relating to the Simple Features CORBA standard can be found on the OGC website.

The three OpenGIS® Simple Features Implementation Specifications (one each for OLE/COM, CORBA, and SQL) define interfaces that enable transparent access to geographic data held in heterogeneous processing systems on distributed computing platforms. The Simple Feature Specification application programming interfaces (APIs) provide for publishing, storage, access, and simple operations on Simple Features (point, line, polygon, multi-point, etc). The purpose of these specifications is to describe interfaces to allow GIS software engineers to develop applications that expose functionality required to access and manipulate geospatial information comprising features with 'simple' geometry using different technologies.

All documents relating to the Simple Features OLE/COM standard can be found on the OGC website.

This standard consists of the following parts, under the general title Geographic information — Simple feature access, consisting of Part 1: Common architecture, and Part 2: SQL option. This version supersedes all previous versions of OpenGIS® Simple Features Implementation Standard for SQL, including OGC 99-049.

All documents relating to the Simple Features SQL standard can be found on the OGC website.

The following are executable test suites related to the Simple Features SQL standard:

The OpenGIS® Styled Layer Descriptor (SLD) Profile of the OpenGIS® Web Map Service (WMS) Encoding Standard [http://www.opengeospatial.org/standards/wms] defines an encoding that extends the WMS standard to allow user-defined symbolization and coloring of geographic feature[http://www.opengeospatial.org/ogc/glossary/f].

All documents relating to the Styled Layer Descriptor standard can be found on the OGC website.

The following are essential concepts in the Styled Layer Descriptor standard:

The following is an executable test suite related to the Styled Layer Descriptor standard:

This Specification defines Symbology Encoding, an XML language for styling information that can be applied to digital Feature and Coverage data. This document is together with the Styled Layer Descriptor Profile for the Web Map Service Implementation Specification the direct follow-up of Styled Layer Descriptor Implementation Specification 1.0.0. The old specification document was split up into two documents to allow the parts that are not specific to WMS to be reused by other service specifications.

All documents relating to the Symbology Encoding standard can be found on the OGC website.

The following is an essential concept in the Symbology Encoding standard:

This document is the specification for a Table Joining Service (TJS). This OGC standard defines a simple way to describe and exchange tabular data that contains information about geographic objects.

All documents relating to the Table Joining Service standard can be found on the OGC website.

TimeseriesML 1.0 defines an XML encoding that implements the OGC Timeseries Profile of Observations and Measurements [OGC 15-043r3], with the intent of allowing the exchange of such data sets across information systems. Through the use of existing OGC standards, it aims at being an interoperable exchange format that may be re-used to address a range of data exchange requirements.

All documents relating to the TimeseriesML (tsml) standard can be found on the OGC website.

The following is an essential concept in the TimeseriesML (tsml) standard:

This Standard provides an updated version of WKT representation of coordinate reference systems that follows the provisions of ISO 19111:2007 and ISO 19111-2:2009. It extends the earlier WKT to allow for the description of coordinate operations. This International Standard defines the structure and content of well-known text strings. It does not prescribe how implementations should read or write these strings. The jointly developed draft has also been submitted by ISO TC211 for publication as an International Standard document. The version incorporates comments made during both the OGC Public Comment Period as well as the ISO ballot for DIS (ISO TC211 document N3750).

All documents relating to the WKT CRS standard can be found on the OGC website.

The following are essential concepts in the WKT CRS standard:

WaterML 2.0 is a standard information model for the representation of water observations data, with the intent of allowing the exchange of such data sets across information systems. Through the use of existing OGC standards, it aims at being an interoperable exchange format that may be re-used to address a range of exchange requirements, some of which are described later in this document.

All documents relating to the WaterML standard can be found on the OGC website.

The following is an essential concept in the WaterML standard:

The following is an executable test suite related to the WaterML standard:

The OGC® Web Coverage Processing Service (WCPS) defines a protocol-independent language for the extraction, processing, and analysis of multi-dimensional coverages representing sensor, image, or statistics data.

All documents relating to the Web Coverage Processing Service standard can be found on the OGC website.

The following are essential concepts in the Web Coverage Processing Service standard:

A Web Coverage Service (WCS) offers multi-dimensional coverage data for access over the Internet. WCS Core specifies a core set of requirements that a WCS implementation must fulfill.

All documents relating to the Web Coverage Service standard can be found on the OGC website.

The following are essential concepts in the Web Coverage Service standard:

The following are executable test suites related to the Web Coverage Service standard:

The Web Feature Service (WFS) represents a change in the way geographic information is created, modified and exchanged on the Internet. Rather than sharing geographic information at the file level using File Transfer Protocol (FTP), for example, the WFS offers direct fine-grained access to geographic information at the feature and feature property level. This International Standard specifies discovery operations, query operations, locking operations, transaction operations and operations to manage stored, parameterized query expressions. Discovery operations allow the service to be interrogated to determine its capabilities and to retrieve the application schema that defines the feature types that the service offers. Query operations allow features or values of feature properties to be retrieved from the underlying data store based upon constraints, defined by the client, on feature properties. Locking operations allow exclusive access to features for the purpose of modifying or deleting features. Transaction operations allow features to be created, changed, replaced and deleted from the underlying data store. Stored query operations allow clients to create, drop, list and described parameterized query expressions that are stored by the server and can be repeatedly invoked using different parameter values. This International Standard defines eleven operations: GetCapabilities (discovery operation), DescribeFeatureType (discovery operation), GetPropertyValue (query operation), GetFeature (query operation), GetFeatureWithLock (query and locking operation), LockFeature (locking operation), Transaction (transaction operation), CreateStoredQuery (stored query operation), DropStoredQuery (stored query operation), ListStoredQueries (stored query operation), DescribeStoredQueries (stored query operation). In the taxonomy of services defined in ISO 19119, the WFS is primarily a feature access service but also includes elements of a feature type service, a coordinate conversion/transformation service and geographic format conversion service.

All documents relating to the Web Feature Service standard can be found on the OGC website.

The following are essential concepts in the Web Feature Service standard:

The following are executable test suites related to the Web Feature Service standard:

This specification states how a specific grouping of one or more maps from one or more map servers can be described in a portable, platform-independent format for storage in a repository or for transmission between clients.

All documents relating to the Web Map Context standard can be found on the OGC website.

The following are essential concepts in the Web Map Context standard:

The OpenGIS® Web Map Service Interface Standard (WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more geo-registered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. The interface also supports the ability to specify whether the returned images should be transparent so that layers from multiple servers can be combined or not.

All documents relating to the Web Map Service standard can be found on the OGC website.

The following are essential concepts in the Web Map Service standard:

The following are executable test suites related to the Web Map Service standard:

This document defines an OGC standard for a Web Map Tile Service (WMTS) interface standard. A WMTS enabled server application can serve map tiles of spatially referenced data using tile images with predefined content, extent, and resolution.

All documents relating to the Web Map Tile Service standard can be found on the OGC website.

The following are essential concepts in the Web Map Tile Service standard:

The following are executable test suites related to the Web Map Tile Service standard:

The OpenGIS® Web Processing Service (WPS) Interface Standard provides rules for standardizing how inputs and outputs (requests and responses) for geospatial processing services, such as polygon overlay. The standard also defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. The data required by the WPS can be delivered across a network or they can be available at the server.

All documents relating to the Web Processing Service standard can be found on the OGC website.

The following are essential concepts in the Web Processing Service standard:

The following is an executable test suite related to the Web Processing Service standard:

This document specifies many of the aspects that are, or should be, common to all or multiple OGC Web Service (OWS) interface Implementation Standards. These common aspects are primarily some of the parameters and data structures used in operation requests and responses. Of course, each such Implementation Standard must specify the additional aspects of that interface, including specifying all additional parameters and data structures needed in all operation requests and responses.

All documents relating to the Web Service Common standard can be found on the OGC website.

The following are essential concepts in the Web Service Common standard:

A single I3S data set, referred to as a Scene Layer, is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. Scene Layers are designed to be used in mobile, desktop, and server-based workflows and can be accessed over the web or as local files. The delivery format and persistence model for Scene Layers, referred to as Indexed 3d Scene Layer (I3S) and Scene Layer Package (SLPK) respectively, are specified in detail in this OGC Community Standard. Both formats are encoded using JSON and binary ArrayBuffers (ECMAScript 2015). I3S is designed to be cloud, web and mobile friendly. I3S is based on JSON, REST and modern web standards and is easy to handle, efficiently parse and render by Web and Mobile Clients. I3S is designed to stream large 3d datasets and is designed for performance and scalability. I3S is designed to support 3D geospatial content and supports the requisite coordinate reference systems and height models in conjunction with a rich set of layer types. The open community GitHub version of this standard is here: https://github.com/Esri/i3s-spec .

All documents relating to the i3s standard can be found on the OGC website.