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.

Document Link    

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.

Document Link 

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.

Document Link  

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.

Document Link   

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.

Document Link  

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.

Document Link 

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.

Document Link 

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.

Document Link  

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.

Document Link 

The REM should be used if programs have a requirement to exchange calculated on-road route information between systems. While this can be used online and offline, it is particularly useful in supporting systems that operate in a Denied, Degraded, Intermittent or Low bandwidth (DDIL) environment. REM exchanges information through Geospatial JavaScript Object Notation (GeoJSON); use of GeoJSON rather than eXtensible Markup Language (XML) or other exchange file notations may not provide the same flexibility that is offered by passing information in XML. However, GeoJSON objects can provide the same information as XML files with a smaller file size. File size should be a consideration for systems operating in DDIL environments as smaller files do not require as much bandwidth or length of connectivity to transfer between systems that larger files require.

Document Link 

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.

Document Link 

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.

Document Link 

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.

Document Link 

A program would use 3D Tiles to stream large 3D geospatial datasets, such as point clouds, terrain surfaces, and collections of 3D models (e.g. buildings, trees, vehicles).

Document Link 

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.

Document Link 

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.

Document Link