03/03/2022 New Emerging Standard Updated to the DISR in 22-1
This document is one part of the OGC Catalogue Services version 3.0 Implementation Standard. Unlike previous versions, Catalogue 3.0 is now divided in multiple parts, with this part specifying the abstract model and another to describe the HTTP protocol binding known as Catalogue Service for the Web (CSW). This standard specifies the model for data resources, query language and properties for interfaces between clients and catalogue services, through the presentation of abstract and extendibility for profiles and implementation-specific models.
This document is the second part of the OGC Catalogue Services version 3.0 Implementation Standard. Unlike previous versions, Catalogue 3.0 is now divided in multiple parts, with this document specifying the HTTP profile of the CSW General Model part (see OGC 12-168r6). The General Model specifies the abstract interfaces between clients and catalogue services. This standard specifies the mapping of the Catalogue abstract model interface into the HTTP protocol binding. In this HTTP protocol binding, operation requests and responses are sent between clients and servers using the HTTP GET and/or HTTP POST methods. Two equivalent request encodings are defined in this standard. The first using keyword-value pairs (KVP) which is suitable for use with the HTTP GET method. The second using XML which is suitable for use with the HTTP POST method.
This document is one part of the OGC Catalogue Services version 3.0 Implementation Standards. Unlike previous versions, Catalogue 3.0 is now divided in multiple parts, with this document specifying the Abstract Test Suite (ATS) for the HTTP Protocol Binding (OGC 12-176r7), a profile of the Catalog Services General Model (part 1, OGC 12-168r6). The HTTP Protocol Binding defines a set of conformance classes each of which has a similarly named requirements class. This document lists each requirements class from the HTTP Binding and then describes the set of abstract tests that must be passed to claim conformance to the requirements class and the corresponding conformance class.
Like in GML, all coverage types in CIS 1.1.1 (as in GMLCOV/CIS 1.0) are derived from a common AbstractCoverage type. GMLCOV/CIS 1.0.1 is strictly derived from the corresponding GML type, so it is a GML Application Profile. CIS 1.1.1 is structurally equivalent, but embodies novel concepts which do not allow a formal derivation in all cases; further, modeling has been simplified over GML to make coverages easier to handle. Further, having JSON and RDF next to GML had a design impact. As a consequence, CIS 1.1.1 formally speaking is not a GML Application Profile. CIS 1.1.1 adds further coverage types over GMLCOV/CIS 1.0.1 - in particular, for more grids and encoding options. CIS 1.1.1 adds further coverage types over GMLCOV/CIS 1.0.1 - in particular, for more grids and encoding options.
This document specifies the WCS core; every implementation of a WCS shall adhere to this standard. This standard thus defines only basic requirements. Extensions to the core will define extensions to meet additional requirements, such as the response encoding. Indeed, additional extensions are required in order to completely specify a WCS for implementation. WCS 2.1 is a complete replacement for the previously released OGC WCS 2.0.1 Interface Standard. WCS 2.1 extends WCS 2.0 (which establishes how to offer coverages as per CIS 1.0) so that 2.1 servers may additionally offer coverages as per CIS 1.1.1. This WCS 2.1 standard extends WCS 2.0 in a backwards compatible manner by accommodating coverages as per the OGC Coverage Implementation Schema (CIS) 1.1.1 in addition to CIS 1.0.1 coverages as addressed by WCS 2.0.
New Mandated Standard Updated to the DISR in 22-1
This document specifies the use of the Geography Markup Language (GML) within the XML boxes of the JPEG 2000 data format and provides an application schema for JPEG 2000 that can be extended to include geometrical feature descriptions and annotations. The document also specifies the encoding and packaging rules for GML use in JPEG 2000.
Retired Standard Updated to the DISR in 22-1
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.
Existing Mandated Standard Updated to the DISR in 22-1
This corrigendum document specifies a GML coverage structure extending the definition of GML 3.2.1 [07-036] in a compatible way. This enhanced coverage type is used by the Web Coverage Service (WCS) Standard version 2.0 and higher, but is independent from WCS service. This augmented coverage structure can serve a wide range of coverage application domains and service types, thereby contributing to harmonization and interoperability.
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.
This Standard is an XML encoding for the transport and storage of geographic information modeled according to the conceptual modeling framework used in the ISO 19100 series of International Standards including both the spatial and non-spatial properties of geographic features.
08/18/2021 21-2 GWS FG Changes to Standards Baseline
The GeoVolumes API was developed from the OGC 3D Data Container and Tiles API initiative completed in June 2020. This API allows for application clients to request a variety of 3D content in a common interoperable manner according to a nested hierarchy of 3D geospatial volumes termed 'GeoVolumes'. The API is consistent with the OGC API-Common core building blocks and provides linkages to serving 2D content. The three data formats identified in the SIG are: 3D Tiles, I3S, and glTF. The former two are geospatial community standards and the latter is a 3D modeling open standard.
The RAPI defines minimum requirements to provide a common interface to programs to pass a start point, end point and waypoint information to the routing engine, and to provide a resulting route back to the requestor that is encoded in GeoJSON, which is supported in the Route Exchange Model (REM). RAPI may be used with any dataset/solver and focuses on accessing the data/solver and how the response is exchanged. RAPI is based on Open Geospatial Consortium (OGC) and OpenAPI principles and provides a single interface for requesting and receiving routes across the NSG. It allows applications to request routes from different providers, data sets, routing engines and algorithms in an interoperable and standardized way, eliminating the need for system proprietary API's and data formats. The RAPI SIG extends the NSG Routing Exchange Model (REM) SIG, by providing a method of accessing and requesting a route from any routing dataset and routing algorithm/solver that a user has available to them. REM then allows the results to be shared in an interoperable manner with other systems. RAPI can be used in all types of connectivity situations, including Denied, Degraded, Intermittent and Limited (DDIL) situations.
New Emerging Standard Updated to the DISR in 21-2
This document specifies an extension to the OGC API - Features - Part 1: Core standard that defines the behavior of a server that supports the ability to present geometry valued properties in a response document in one from a list of supported Coordinates Reference Systems (CRS). The OGC API - Features - Part 1: Core standard defines support for only two coordinate reference systems: WGS 84 longitude, latitude; and WGS 84 longitude, latitude, ellipsoidal height.
I3S is needed if there is a need to stream and store large amounts of 3D geospatial data. Scene Layers provide clients access to data and allow them to visualize it according to their needs. This can work on web browsers, mobile, and desktop apps for both offline and online access.
glTF is needed if program managers need to transmit and load 3D scenes and models. This is a 3D format that was designed for compact file size, fast loading, run-time independence, and complete 3D scene representation. It is often described as the JPEG of 3D.