- OGC® Standards
- OGC Standards List
- Specification Profiles
- Abstract Specification
- OGC Reference Model
- OGC Schema Updates
- Public Engineering Reports
- TC Policy Directives
- GeoDRM Reference Model
- Best Practices
- Discussion Papers
- Deprecated Documents
- Retired Documents
- Requests (RFP's, RFQ's...)
- White Papers
- Change Requests
- Submit Change Request or Requirement
OGC Standards
Below is a list of OGC Implementation Standards.
Implementation Standards are different from the Abstract Specification. They are written for a more technical audience and detail the interface structure between software components. An interface specification is considered to be at the implementation level of detail if, when implemented by two different software engineers in ignorance of each other, the resulting components plug and play with each other at that interface.
Any Schemas (xsd, xslt, etc) that support an approved Implementation Standard can be found in the official OGC Schema Repository.
Implementation Standards are different from the Abstract Specification. They are written for a more technical audience and detail the interface structure between software components. An interface specification is considered to be at the implementation level of detail if, when implemented by two different software engineers in ignorance of each other, the resulting components plug and play with each other at that interface.
Any Schemas (xsd, xslt, etc) that support an approved Implementation Standard can be found in the official OGC Schema Repository.
Document Title (click to download) | Version | Document # | Editor | Date |
---|---|---|---|---|
![]() netcdf-data-model-ex |
3.1 | 11-165r2 | Ben Domenico and Stefano Nativi | 2013-01-03 |
The OGC netCDF encoding supports electronic encoding of geospatial data, that is, digital geospatial information representing space and time-varying phenomena.
This standard specifies the CF-netCDF data model extension.
This standard specifies the CF-netCDF data model mapping onto the ISO 19123 coverage schema.
This standard deals with multi-dimensional gridded data and multi-dimensional multi-point data.
In particular, this extension standard encoding profile is limited to multi-point, and regular and warped grids; however, irregular grids are important in the CF-netCDF community and work is underway to expand the CF-netCDF to encompass other coverages types, including irregular gridded datasets.
See more... | ||||
![]() CommonC1 |
11-157 | Jim Greenwood | 2011-10-18 | |
This document being corrected specifies many of the aspects that are, or should be, common to all or multiple OWS interface Implementation Specifications. The Common Implementation Specification aspects specified by this document currently include:
a) Operation request and response contents, most partial
b) Parameters and data structures included in operation requests and responses c) XML and KVP encoding of operation requests and responses See more... | ||||
![]() CommonC2 |
11-158 | Jim Greenwood | 2011-10-18 | |
This document defines the corrigendum change notes for See more... | ||||
![]() WPS 1.0 Corr |
0.0.8 | 08-091r6 | Peter Schut | 2009-09-16 |
This document provides the details for a corrigendum for the existing OpenGIS Standard for the Web Processing Service version 1.0.0 and does not modify that standard. The current OpenGIS Implementation Standard that this document provides revision notes for is 05-007r7. See more... | ||||
![]() |
1.0.1 | 07-110r4 | Richard Martell | 2009-02-05 |
This profile is based on the HTTP protocol binding described in Clause 10 of the Catalogue 2.0.2 specification; it qualifies as a ‘Class 2’ profile under the terms of ISO 19106 since it includes extensions permitted within the context of the base specifications, some of which are not part of the ISO 19100 series of geomatics standards. See more... | ||||
![]() CAT2 ebRIM part2 |
1.0.1 | 07-144r4 | Richard Martell | 2009-02-05 |
Incorporates Corrigendum 1 (OGC 08-102r1). See more... | ||||
![]() om-eo-metadata |
1.0 | 10-157r3 | Jerome Gasperi, Frédéric Houbie, Andrew Woolf, Steven Smolders | 2012-06-12 |
This OGC Implementation Standard defines a profile of Observations and Measurements (ISO 19156) for describing Earth Observation products (EO products).
Although this standard has been developed in the context of the Heterogeneous Mission Accessibility (HMA) project initiated by European Space Agency (ESA), the content is generic to Earth Observation product description. The metadata model described in this document is structured to follow the different types of products (Optical, Radar, …) which are not HMA specific.
See more... | ||||
![]() |
3.0 | 09-083r3 | Adrian Custer | 2011-04-25 |
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 Committee211 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. See more... | ||||
![]() |
1.0.1 | 11-017 | Andreas Matheus, Jan Herrmann | 2011-05-12 |
The OpenGIS® Geospatial eXtensible Access Control Markup Language Encoding Standard (GeoXACML) defines a geospatial extension to the OASIS standard “eXtensible Access Control Markup Language (XACML)” [www.oasis-open.org/committees/xacml/]. This extension incorporates spatial data types and spatial authorization decision functions based on the OGC Simple Features[http://www.opengeospatial.org/standards/sfa] and GML[http://www.opengeospatial.org/standards/gml] standards. GeoXACML is a policy language that supports the declaration and enforcement of access rights across jurisdictions and can be used to implement interoperable access control systems for geospatial applications such as Spatial Data Infrastructures. GeoXACML is not designed to be a rights expression language and is therefore not an extension of the OGC GeoDRM Reference Model (Topic 18 in the OpenGIS® Abstract Specification [http://www.opengeospatial.org/standards/as]). See more... | ||||
![]() GeoXACML extA |
1.0 | 07-098r1 | Andreas Matheus | 2008-02-23 |
This document defines an extension to the GeoXACML Implementation Specification, Verison 1.0 for the GML2 geometry encoding as specified in the GML2 standard. See more... | ||||
![]() GeoXACML extB |
1.0 | 07-099r1 | Andreas Matheus | 2008-02-23 |
This specification is a normative extension to the GeoXACML core Implementation Specification. It defines the GML3 encoding for geometries. See more... | ||||
![]() netcdf-binary |
1.0 | 10-092r3 | Ben Domenico | 2011-04-05 |
This document defines an OGC® Standard for encoding binary representations of space-time varying geo-referenced data. Specifically, this standard specifies the netCDF classic and 64-bit offset file binary encoding formats. This standard specifies a set of requirements that every netCDF classic or 64-bit offset binary encoding must fulfil. See more... | ||||
![]() |
2.0 | 10-025r1 | Simon Cox | 2011-03-22 |
This standard specifies an XML implementation for the OGC and ISO Observations and Measurements (O&M) 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. See more... | ||||
![]() |
2.0 | 12-019 | Gerhard Gröger, Thomas H. Kolbe, Claus Nagel, Karl-Heinz Häfele | 2012-04-04 |
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.
See more... | ||||
![]() |
1.0 | 11-052r4 | Matthew Perry and John Herring | 2012-06-12 |
This standard defines a set of SPARQL extension functions [W3C SPARQL], a set of RIF rules [W3C RIF Core], and a core RDF/OWL vocabulary for geographic information based on the General Feature Model, Simple Features [ISO 19125-1], Feature Geometry and SQL MM. See more... | ||||
![]() csw-ebrim-i15 |
1.0 | 13-084r2 | Uwe Voges, Frédéric Houbie, Nicolas Lesage, Marie-Lise Vautier | 2014-04-28 |
The OGC Catalogue Services 2.0 specification (OGC 07-006r1) establishes a general framework for implementing catalogue services that can be applied to meet the needs of stakeholders in a wide variety of domains.
The ebRIM application profile (OGC 07-110r4) is based on the HTTP protocol binding described in Clause 10 of the Catalogue 2.0 specification; it qualifies as a ‘Class 2’ profile under the terms of ISO 19106 since it includes extensions permitted within the context of the base specifications, some of which are not part of the ISO 19100 series of geomatics standards. The ebRIM application profile also includes a Basic extension package (OGC 07-144r4) of the OASIS ebXML Registry Information Model (ebRIM) providing artefacts of general utility in the geomatics domain.
This document provides an extension package aligned with the ebRIM application profile of CS-W for the cataloguing of ISO 19115, ISO19115-2 and ISO 19119 compliant metadata. It was initially produced during the ESA HMA (Heterogeneous Missions Accessibility) initiative [HMA] and related projects. Some input came from the OGC OWS9 initiative.
This document supersedes the former document OGC Cataloguing of ISO Metadata (CIM) using the ebRIM profile of CS-W, OGC 07-038r3 (Version: 0.1.12).
See more... | ||||
![]() |
2.2.0 | 07-147r2 | Tim Wilson | 2008-04-14 |
KML is an XML language focused on geographic visualization, including annotation of maps and images. Geographic visualization includes not only the presentation of graphical data on the globe, but also the control of the user's navigation in the sense of where to go and where to look. See more... | ||||
![]() |
1.0.0 | 06-024r4 | CS Smyth | 2008-09-08 |
The OpenGIS Tracking Service Interface Standard supports a very simple functionality allowing a collection of movable objects to be tracked as they move and change orientation. The standard addresses the absolute minimum in functionality in order to address the need for a simple, robust, and easy-to-implement open standard for geospatial tracking. See more... | ||||
![]() |
1.0 | 10-090r3 | Ben Domenico | 2011-04-05 |
This document specifies the network Common Data Form (netCDF) core standard and extension mechanisms. The OGC netCDF encoding supports electronic encoding of geospatial data, specifically digital geospatial information representing space and time-varying phenomena.
NetCDF is a data model for array-oriented scientific data. A freely distributed collection of access libraries implementing support for that data model, and a machine-independent format are available. Together, the interfaces, libraries, and format support the crea-tion, access, and sharing of multi-dimensional scientific data.
See more... | ||||
![]() netcdf-enhanced |
1.0 | 11-038R2 | Ben Domenico | 2012-10-02 |
This standard deals with enhancements to the netCDF (Network Common Data Form) data model for array-oriented scientific data..
Two important data models for netCDF are:
the “classic” netCDF model, used for netCDF-3 and earlier versions
an enhanced data model, used in netCDF-4 and later versions.
The netCDF classic data model is defined in OGC 10-091r3, “NetCDF Core.”
This document specifies a netCDF extension standard for the enhanced data model. The OGC netCDF encoding supports electronic encoding of geospatial data, specifically digital geospatial information representing space- and time-varying phenomena.
NetCDF (network Common Data Form) is a data model for array-oriented scientific data. The netCDF classic data model is specified in the netCDF core specification. This standard specifies the enhanced data model. A freely distributed collection of access libraries implementing support for that data model in a machine-independent format are available. Together, the interfaces, libraries, and format support the creation, access, and sharing of multi-dimensional scientific data. See more... | ||||
![]() |
2.0 | 11-014r3 | Stanislav Vanecek, Roger Moore | 2014-05-26 |
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. See more... | ||||
![]() |
1.0 | 12-084r2 | Roger Brackin, Pedro Gonçalves | 2014-01-14 |
This standard describes the Atom encoding of the OWC Context conceptual model. The goal of this standard is to provide a definition of how to encode a context document, which can be extended to allow a context referencing a fully configured service set to be defined and consistently interpreted by clients.
See more... | ||||
![]() |
1.0 | 12-080r2 | Roger Brackin, Pedro Gonçalves | 2014-01-22 |
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.
OWS Context is aimed at replacing previous OGC attempts at providing such a capability (the Web Map Context WMC) which was reasonably successful but limited to WMS. Other work on the ‘Location Organizer Folder (LOF)’ was also taken into consideration. The concept of OWS Context, and the first prototype document was produced as part of OGC testbed OWS-7. See OGC 10-035r1, Information Sharing Engineering Report. In order to achieve mass market appeal, as well as being useful to a wider community, the use of OWS Context support to other existing standards was considered. Multiple encoding formats for OWS Context have been developed (ATOM, JSON). Each of these is described in a separate OWS Context Extensions to the Core model.
This document concentrates on describing the OWS Context Model in abstract terms using UML. The document defines requirements and use cases. It also includes an abstract test suite to verify that encodings are compliant with the core specification. The intent of OWS Context is to allow many types of OGC Data Delivery service to be referenced and therefore exploited (for example, not just WMS but also WFS, WCS and WPS) but it does not explicitly define the encoding of these services in the core (only the general approach to be used for different types of service interface). Service explicit encodings are defined within the extension documents for ATOM and JSON.
The abbreviation owc is used throughout this document for OWS Context.
See more... | ||||
![]() |
2.0.0 | 06-121r9 | Arliss Whiteside Jim Greenwood | 2010-04-07 |
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. See more... | ||||
![]() |
1.0 | 11-030r1 | Kuan-Mei Chen, Carl Reed | 2012-01-19 |
The OpenGIS® Open GeoSMS standard defines an encoding for location enabling a text message to be communicated using a Short Messages System (SMS). See more... | ||||
![]() |
1.0.0 | 06-131r6 | Frédéric Houbie, Lorenzo Bigagli | 2010-02-10 |
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] implementing the CSW-ebRIM Registry Service – part 1: ebRIM profile of CSW [OGC 07-110r4]. This standard defines the way Earth Observation products metadata resources are organized and implemented in the Catalogue for discovery, retrieval and management. See more... | ||||
![]() |
3.3 | 10-129r1 | Clemens Portele | 2012-02-07 |
The Geography Markup Language (GML) is an XML encoding in compliance with ISO 19118 for the transport and storage of geographic information modelled in accordance with the conceptual modelling framework used in the ISO 19100 series of International Standards and including both the spatial and non-spatial properties of geographic features. See more... | ||||
![]() |
1.0 | 12-128r10 | Paul Daisey | 2014-02-10 |
This OGC® Encoding Standard defines GeoPackages for exchange and GeoPackage SQLite Extensions for direct use of vector geospatial features and / or tile matrix sets of earth images and raster maps at various scales. Direct use means the ability to access and update data in a "native" storage format without intermediate format translations in an environment (e.g. through an API) that guarantees data model and data set integrity and identical access and update results in response to identical requests from different client applications. GeoPackages are interoperable across all enterprise and personal computing environments, and are particularly useful on mobile devices like cell phones and tablets in communications environments with limited connectivity and bandwidth.
For the online version of the standard and the developer resources, visit http://www.geopackage.org/ See more... | ||||
![]() wcs_geotiff |
1.0 | 12-100r1 | Stephan Meissl | 2014-05-28 |
This Interface Standard is a profile of the OGC® GML Application Schema –Coverages version 1.0 [OC 09-146r2]. This document specifies the usage of the GeoTIFF data format for the encoding of GML coverages. This encoding is used by several OGC services like the Web Coverage Service (WCS) 2.0 Interface Standard – Core [OGC 09-110r4]. See more... | ||||
![]() |
1.0 | 10-032r8 | Pedro Gonçalves | 2014-04-14 |
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. See more... | ||||
![]() |
1.4 | 09-127r2 | Tom O’Reilly | 2012-01-25 |
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. See more... | ||||
![]() |
2.0 | 12-000 | Mike Botts, Alexandre Robin | 2014-02-04 |
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). See more... | ||||
![]() |
2.0 | 12-006 | Arne Bröring, Christoph Stasch, Johannes Echterhoff | 2012-04-20 |
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. See more... | ||||
![]() |
2.0 | 09-000 | Ingo Simonis, Johannes Echterhoff | 2011-03-28 |
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) [http://www.opengeospatial.org/ogc/markets-technologies/swe] suite of standards. See more... | ||||
![]() SPS EO Tasking Ext |
2.0 | 10-135 | Alexandre Robin, Philippe Mérigot | 2011-03-28 |
The SPS 2.0 Earth Observation Satellite Tasking Extension Standard specifies extensions to the OGC Sensor Planning Service (SPS) 2.0 Interface Standard. The SPS configuration proposed in this extension is intended to support the programming process of Earth Observation (EO) sensor systems. This standard describes a consistent SPS configuration that can be supported by many satellite data providers, most of whom have existing facilities for the management of these programming requests. The resulting extended web service interface can be used for determining the feasibility of an intended sensor planning request, for submitting such a request, for inquiring about the status of such a request, for updating or canceling such a request, and for requesting information on means of obtaining the data collected by the requested task. See more... | ||||
![]() |
2.0 | 08-094r1 | Alexandre Robin | 2011-01-04 |
This 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. See more... | ||||
![]() |
2.0.1 | 10-126r4 | Peter Taylor | 2014-02-24 |
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. See more... | ||||
![]() |
2.0.1 | 09-110r4 | Peter Baumann | 2012-07-12 |
This document specifies how a Web Coverage Service (WCS) offers multi-dimensional cov-erage data for access over the Internet. This document specifies a core set of requirements that a WCS implementation must fulfil. WCS extension standards add further functionality to this core; some of these are required in addition to the core to obtain a complete implementa-tion. This document indicates which extensions, at a minimum, need to be considered in ad-dition to this core to allow for a complete WCS implementation.
This core does not prescribe support for any particular coverage encoding format. This also holds for GML as a coverage delivery format: while GML constitutes the canonical format for the definition of WCS, it is not required by this core that a concrete instance of a WCS service implements the GML coverage format. WCS extensions specifying use of data encod-ing formats in the context of WCS are designed in a way that the GML coverage information contents specified in this core is consistent with the contents of an encoded coverage.
See more... | ||||
![]() |
1.0.1 | 09-147r3 | Peter Baumann | 2013-03-26 |
This document specifies an extension to the OGC Web Coverage Service (WCS) 2.0 core to allow for client/server communication using HTTP GET with key/value pair (KVP) encod-ing. See more... | ||||
![]() |
1.0.0 | 09-148r1 | Peter Baumann | 2010-10-27 |
This document specifies how Web Coverage Service (WCS) clients and servers can commu-nicate over the Internet using HTTP POST with XML encoding. See more... | ||||
![]() WCS XML SOAP ext |
2.0 | 09-149r1 | Peter Baumann | 2010-10-27 |
This document specifies how Web Coverage Service (WCS) clients and servers can commu-nicate over the Internet using SOAP with XML encoding. See more... | ||||
![]() WCS-CRS-extension |
1.0 | 11-053r1 | Peter Baumann, Jinsongdi Yu | 2014-03-11 |
This document specifies parameters to the OGC Web Coverage Service (WCS) GetCoverage request that allows a client, a service, or other application to specify the Coordinate Reference System (CRS) in which coverages are delivered. Note that the CRS of the input bounding box is already defined in the OGC WCS Core Implementation Standard [OGC 09-110r3]. See more... | ||||
![]() WCS Interopolation |
1.0 | 12-049 | Peter Baumann, Jinsongdi Yu | 2014-02-26 |
This OGC standard specifies parameters to the OGC Web Coverage Service (WCS) GetCov-erage request which give control over interpolation of a coverage during its server-side pro-cessing. This allows the client (user) to control and specify the interpolation mechanism to be applied to a coverage during server processing.
This WCS Interpolation extension relies on WCS Core [OGC 09-110r4] and the GML Appli-cation Schema for Coverages [OGC 09-146r2].
See more... | ||||
![]() WCS range subsetting |
1.0 | 12-040 | Peter Baumann, Jinsongdi Yu | 2014-02-26 |
This document specifies parameters to the OGC Web Coverage Service (WCS) GetCoverage request which allow extraction of specific fields, according to the range type specification, from the range set of a coverage during server-side processing of a coverage in a GetCover-age request. See more... | ||||
![]() WCS scaling |
1.0 | 12-039 | Peter Baumann, Jinsongdi Yu | 2014-02-26 |
This document specifies parameters to the OGC Web Coverage Service (WCS) GetCoverage request which allow scaling of a coverage during its server-side processing in a GetCoverage request. See more... | ||||
![]() WCS WCPS |
2.0 | 08-059r4 | Peter Baumann, Jinsongdi Yu | 2014-02-26 |
The OGC Web Coverage Service (WCS)– Processing Extension defines an extension to the WCS Core [OGC 09-110], the ProcessCoverages request type, which allows clients to initi-ate server-side processing and filtering of coverages and to download the resulting coverage or value sets based on the query language defined in the Web Coverage Processing Service (WCPS) interface standard [OGC 08-068]. See more... | ||||
![]() |
2.0.2 | 07-006r1 | Nebert, Whiteside, Vretanos, editors | 2007-04-20 |
The OpenGIS® Catalogue Services Interface Standard (CAT) supports the ability to publish and search collections of descriptive information (metadata) about geospatial data, services and related resources. Providers of resources use catalogues to register metadata that conform to the provider's choice of an information model; such models include descriptions of spatial references and thematic information. Client applications can then search for geospatial data and services in very efficient ways.
See also the OGC Catalogue 2.0 Accessibility for OWS-3 Discussion Paper [http://www.opengeospatial.org/standards/dp], the OWS-4 CSW ebRIM Modelling Guidelines Interoperability Program Report (IPR) [www.opengeospatial.org/standards/dp] and the OpenGIS® Catalogue Service Interface Standard 2.0.1 - FGDC CSDGM Application Profile for CSW (Best Practice) [http://www.opengeospatial.org/standards/bp].
See more... | ||||
![]() |
1.0 | 01-009 | Martin Daly | 2001-01-12 |
The OpenGIS® Coordinate Transformation Service Standard (CTS) 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. See more... | ||||
![]() |
2.0 | 09-026r1 | Panagiotis (Peter) A. Vretanos | 2010-11-22 |
This 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. See more... | ||||
![]() |
3.2.1 | 07-036 | Clemens Portele | 2007-10-05 |
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.
Clients and servers with interfaces that implement the OpenGIS® Web Feature Service Interface Standard[http://www.opengeospatial.org/standards/wfs] read and write GML data. GML is also an ISO standard (ISO 19136:2007) [www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32554 ].
See also the GML pages on OGC Network: http://www.ogcnetwork.net/gml .
See more... | ||||
![]() |
1.0.0 | 05-047r3 | Martin Kyle, David Burggraf, Sean Forde, Ron Lake | 2006-01-20 |
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 [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.
See also the GML pages on OGC Network: http://www.ogcnetwork.net/gml .
See more... | ||||
![]() |
1.2.1 | 06-103r4 | John Herring | 2010-08-04 |
The OpenGIS® Simple Features Interface Standard (SFS) provides a well-defined and common way for applications to store and access feature data in relational or object-relational databases, so that the data can be used to support other applications through a common feature model, data store and information access interface. OpenGIS Simple Features are geospatial features described using vector data elements such as points, lines and polygons. See more... | ||||
![]() |
1.2.1 | 06-104r4 | John Herring | 2010-08-04 |
The OpenGIS® Simple Features Interface Standard (SFS) provides a well-defined and common way for applications to store and access feature data in relational or object-relational databases, so that the data can be used to support other applications through a common feature model, data store and information access interface. OpenGIS Simple Features are geospatial features described using vector data elements such as points, lines and polygons. See more... | ||||
![]() |
1.2.0 | 07-074 | Marwa Mabrouk | 2008-09-08 |
This OpenGIS Interface Standard defines OpenGIS Location Services (OpenLS): Core Services, Parts 1-5, which consists of the composite set of basic services comprising the OpenLS Platform. This platform is also referred to as the GeoMobility Server (GMS), an open location services platform. See more... | ||||
![]() OLSNav |
1.0.0 | 08-028r7 | Gil Fuchs | 2008-09-04 |
This OpenGIS Implementation Standard defines the interfaces for OpenGIS Location Services (OpenLS): Part 6 - Navigation Service (formerly the Full Profile of the Route Determination Service), which is part of the GeoMobility Server (GMS), an open location services platform. See more... | ||||
![]() SensorML Corr 1 |
1.01 | 07-122r2 | Mike Botts, Simon Cox | 2007-11-12 |
Changes to the 1.0 schemas See more... | ||||
![]() |
1.0.0 | 07-000 | Mike Botts | 2007-07-24 |
The OpenGIS® Sensor Model Language Encoding Standard (SensorML) specifies models and XML encoding that provide a framework within which the geometric, dynamic, and observational characteristics of sensors and sensor systems can be defined. There are many different sensor types, from simple visual thermometers to complex electron microscopes and earth observing satellites. These can all be supported through the definition of atomic process models and process chains. Within SensorML, all processes and components are encoded as application schema of the Feature model in the Geographic Markup Language (GML) Version 3.1.1. This is one of the OGC Sensor Web Enablement (SWE) [http://www.opengeospatial.org/ogc/markets-technologies/swe] suite of standards. For additional information on SensorML, see http://www.botts-inc.net/vast.html
See more... | ||||
![]() |
1.0.0 | 06-009r6 | Arthur Na, Mark Priest | 2008-02-13 |
The OpenGIS® Sensor Observation Service Interface Standard (SOS) provides an API for managing deployed sensors and retrieving sensor data and specifically “observation” data. Whether from in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today. This is one of the OGC Sensor Web Enablement (SWE) [http://www.opengeospatial.org/ogc/markets-technologies/swe] suite of standards. See more... | ||||
![]() |
1.0 | 99-054 | Peter Ladstaetter | 1999-06-02 |
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). See more... | ||||
![]() |
1.1 | 99-050 | TC Chair | 1999-05-18 |
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). See more... | ||||
![]() |
1.1.0 | 05-078r4 | Markus Lupp | 2007-08-14 |
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] and coverage[http://www.opengeospatial.org/ogc/glossary/c] data.
SLD addresses the need for users and software to be able to control the visual portrayal of the geospatial data. The ability to define styling rules requires a styling language that the client and server can both understand. The OpenGIS® Symbology Encoding Standard (SE) [http://www.opengeospatial.org/standards/symbol] provides this language, while the SLD profile of WMS enables application of SE to WMS layers using extensions of WMS operations. Additionally, SLD defines an operation for standardized access to legend symbols.
See more... | ||||
![]() |
1.1.0 | 05-077r4 | Dr. Markus Mueller | 2007-01-18 |
The OpenGIS® Symbology Encoding Standard (SES) defines an XML language for styling information that can be applied to digital geographic feature and coverage data. SE is independent of any OGC Web Services descriptions and could therefore be used to describe styling information in non-networked systems such as desktop geographic information systems. See more... | ||||
![]() |
1.0.0 | 08-068r2 | Peter Baumann | 2009-03-25 |
The OpenGIS® Web Coverage Service Interface Standard (WCS) defines a protocol-independent language for the extraction, processing, and analysis of multi-dimensional gridded coverages (see: http://www.opengeospatial.org/ogc/glossary/c ) representing sensor, image, or statistics data. Services implementing this language provide access to original or derived sets of geospatial coverage information, in forms that are useful for client-side rendering, input into scientific models, and other client applications.
Further information about WPCS can be found at the WCPS Service page of the OGC Network(see: http://www.ogcnetwork.net/wcps). See more... | ||||
![]() WCS WCPS |
1.0.0 | 08-059r3 | Peter Baumann | 2009-03-25 |
The OpenGIS® Web Coverage Service Interface Standard (WCS) defines a protocol-independent language for the extraction, processing, and analysis of multi-dimensional gridded [[http://www.opengeospatial.org/ogc/glossary/c | coverages]] representing sensor, image, or statistics data. Services implementing this language provide access to original or derived sets of geospatial coverage information, in forms that are useful for client-side rendering, input into scientific models, and other client applications.
Further information about WPCS can be found at the [[http://www.ogcnetwork.net/wcps | WCPS Service]] page of the OGC Network. See more... | ||||
![]() |
1.1.0 | 04-094 | Peter Vretanos | 2005-05-03 |
The OpenGIS Web Feature Service Interface Standard (WFS) defines an interface[http://www.opengeospatial.org/ogc/glossary/i] for specifying requests for retrieving geographic features [http://www.opengeospatial.org/ogc/glossary/g] across the Web using platform-independent calls. The WFS standard defines interfaces and operations for data access and manipulation on a set of geographic features, including:
• Get or Query features based on spatial and non-spatial constraints
• Create a new feature instance
• Get a description of the properties of features
• Delete a feature instance
• Update a feature instance
• Lock a feature instance
The specified feature encoding for input and output is the Geography Markup Language (GML) [http://www.opengeospatial.org/standards/gml] although other encodings may be used.
See more... | ||||
![]() WFSC |
1.0.0 | 06-027r1 | Panagiotis (Peter) A. Vretanos | 2006-08-22 |
This document is a corrigendum for OGC Document 04-094. Specifically, this document corrects the files referenced in ANNEX A and found in the OGC schema repository. See more... | ||||
![]() |
2.0 | 09-025r1 | Panagiotis (Peter) A. Vretanos | 2010-11-02 |
This International Standard specifies the behaviour of a service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It 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. See more... | ||||
![]() WMC Corr 1 |
1.1.0 | 08-050 | Tom Kralidis | 2008-05-02 |
This document provides the details for a corrigendum for the existing OpenGIS Standard for the Web Map Context Documents version 1.1.0 and does not modify that standard. The current OpenGIS IS that this document provides revision notes for is 05-005. This document is a corrigendum to 05-005. See more... | ||||
![]() |
1.1 | 05-005 | Jerome Sonnet | 2005-05-03 |
This document is a companion specification to the OGC Web Map Service Interface Implementation Specification version 1.1.1 [4], hereinafter "WMS 1.1.1."
WMS 1.1.1 specifies how individual map servers describe and provide their map content. The present Context 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. This description is known as a "Web Map Context Document," or simply a "Context." Presently, context documents are primarily designed for WMS bindings. However, extensibility is envisioned for binding to other services.
A Context document includes information about the server(s) providing layer(s) in the overall map, the bounding box and map projection shared by all the maps, sufficient operational metadata for Client software to reproduce the map, and ancillary metadata used to annotate or describe the maps and their provenance for the benefit of human viewers.
A Context document is structured using eXtensible Markup Language (XML). Annex A of this specification contains the XML Schema against which Context XML can be validated.
See more... | ||||
![]() |
1.3.0 | 06-042 | Jeff de La Beaujardiere | 2006-03-15 |
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. NOTE: WMS 1.3 and ISO 19128 are the same documents. | ||||
![]() |
1.0.0 | 07-057r7 | Joan Masó, Keith Pomakis and Núria Julià | 2010-04-06 |
This Web Map Tile Service (WMTS) Implementation Standard provides a standard based solution to serve digital maps using predefined image tiles. The service advertises the tiles it has available through a standardized declaration in the ServiceMetadata document common to all OGC web services. This declaration defines the tiles available in each layer (i.e. each type of content), in each graphical representation style, in each format, in each coordinate reference system, at each scale, and over each geographic fragment of the total covered area. The ServiceMetadata document also declares the communication protocols and encodings through which clients can interact with the server. Clients can interpret the ServiceMetadata document to request specific tiles. See more... | ||||
![]() |
1.0 | 08-007r1 | Gerhard Gröger, Thomas H. Kolbe, Angela Czerwinski, Claus Nagel | 2008-08-20 |
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.
See more... | ||||
![]() |
1.0 | 10-070r2 | Peter Schut | 2010-11-22 |
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. See more... | ||||
![]() |
2.0 | 09-001 | Johannes Echterhoff | 2011-03-21 |
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. See more... | ||||
![]() |
1.0 | 06-141r6 | Daniele Marchionni, Stefania Pappagallo | 2012-01-09 |
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. See more... | ||||
![]() cat revision notes |
1.0 | 07-010 | Doug Nebert | 2007-06-19 |
This document is a corrigendum for OGC Document 04-021r3. All changes described herein are published in OGC Document 07-006r1. See more... | ||||
![]() |
1.1.4 | 07-068r4 | Arliss Whiteside | 2009-01-15 |
This extension of the WCS standard specifies an additional Transaction operation that may optionally be implemented by WCS servers. This Transaction operation allows clients to add, modify, and delete grid coverages that are available from a WCS server. The Transaction operation request references or includes the new or modified coverage data, including all needed coverage metadata. See more... | ||||
![]() |
1.0.0 | 05-007r7 | Peter Schut | 2007-10-05 |
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. See more... |