OGC Requests

Public comment requested: OGC API - Common - Part 2: Geospatial Data

Status: 
Please note:  This Request is scheduled to close on 5 January 2022.
Open Date: 
Mon, 12/06/2021
Closing Date: 
Wed, 01/05/2022
Description: 

The Open Geospatial Consortium (OGC) is seeking public comment on the OGC API - Common - Part 2: Geospatial Data Candidate Standard. The purpose of OGC API - Common - Part 2: Geospatial Data is to provide a common connection between the API landing page and resource-specific details. 

OGC APIs are OGC’s Building Blocks for Location, and are ushering in a new age for location information on the web by enabling a much simpler, consistent, and familiar way to share and access location information. Through the OGC APIs, the OGC community is improving how location information can be integrated: by any developer, with any other type of information, and into any type of application.

OGC API - Common serves as a foundation upon which all OGC APIs can be built. OGC API - Common - Part 1: Core defines the resources and access mechanisms which are useful for a client seeking to understand the offerings and capabilities of an API. OGC API - Common - Part 2: Geospatial Data builds on Part 1 by providing a common connection between the API landing page and geospatial data collections.

Geospatial data is rarely considered as a single entity. Feature Collections, Coverages, Data Sets, etc. are all aggregations of Spatial or Temporal ‘Things’. It stands to reason that an OGC Web API would also expose its holdings as aggregates of spatial resources. The purpose of the OGC API - Common - Part 2 Standard, then, is to provide a means of organizing these aggregate collections and to define operations for the discovery and selection of individual collections.

The OGC API - Common - Part 2 Standard does not specify the nature of the geospatial data that make up a collection. Rather, it provides a basic capability that should be applicable to any geospatial resource type. Additional OGC Web API standards extend this foundation to define resource-specific capabilities.

In parallel to this public review, the OGC Naming Authority is assessing the naming conventions to be used in the Requirements Modules defined in the candidate Standard. These conventions are important in the continued modularization of the OGC APIs, so careful review by experts is welcomed.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: Two Dimensional Tile Matrix Set and Tile Set Metadata Standard

Status: 
Please note:  This Request is scheduled to close on 3 December 2021.
Open Date: 
Wed, 11/03/2021
Closing Date: 
Fri, 12/03/2021
Description: 

The Open Geospatial Consortium (OGC) is requesting public comment on a revision to the candidate Two Dimensional Tile Matrix Set and Tile Set Metadata Standard. The new revision adds a new data model to describe tilesets and how to encode in XML and in JSON. It also corrects inconsistencies discovered in the first version, introduces some minor changes to the TileMatrixSet conceptual model and encodings, and clarifies the identification and use of registered TileMatrixSet definitions. 

The Two Dimensional Tile Matrix Set and Tile Set Metadata Standard decouples the standardized definition of a “tile matrix set” from the OGC Web Map Tile Service Standard (WMTS), so that other Standards may use it to take advantage of the performance, storage, and processing benefits that tile matrix sets can bring. 

A “tile” is a rectangular pictorial representation of contiguous geographic data (such as a portion of a digital map) that can be uniquely defined by a pair of indices for the column and row along with an identifier for its “tile matrix.” A “tile matrix” is a collection of tiles for a single scale, while a “tile matrix set” is a collection of tile matrices defined at different scales.

In 2007, OGC approved and released the Web Map Tile Service Standard (WMTS), which included a standardized definition of a “tile matrix set.” Over time, other OGC standards with requirements for “tiles” or tiled structures needed to use the same definition. Unfortunately, other OGC standards could not use the tile matrix set definition directly because the definition was formally linked to the WMTS tile service. 

The “OGC Two Dimensional Tile Matrix Set and Tile Set Metadata” Standard decouples the concept of a tile matrix set from the WMTS standard so that other standards may reference the concept directly. As such the standard has relevance to future revisions of other OGC Standards such as GeoPackage and CDB and will be used in future formats and services (such as the new OGC API - Tiles candidate standard) needing tiles for efficient data access, storage, or parallel processing.

 

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: GeoPose

Status: 
Please note:  This Request is scheduled to close on 15 November 2021.
Open Date: 
Thu, 10/14/2021
Closing Date: 
Mon, 11/15/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the candidate OGC GeoPose Standard, which provides a standard for expressing and sharing  geographically-anchored poses (aka GeoPoses) of objects with six degrees of freedom and referenced to one or more standardized Coordinate Reference Systems. 

The combination of position (e.g. x, y, z or longitude, latitude, elevation) and orientation (e.g. pitch, roll, and yaw) with 6 degrees of freedom for objects in computer graphics and robotics is usually referred to as the object’s “pose.” Pose can be expressed as being in relation to other objects, a place, and/or to the user. When a pose is defined relative to the Earth, it is called a geographically anchored pose, or ‘GeoPose’ for short.

The ability to specify and express the GeoPose of any object will aid in interoperability between 3D spatial computing systems such as those for autonomous vehicles, augmented, virtual, and extended reality (AR/VR/XR), 3D map visualization, or any digital representation of the physical world or part therein, such as digital twins. Further, the ability to express the GeoPose of an object will aid applications involving Earth Observation from spacecraft and aircraft with sensors mounted on rotatable gimbals.

Prior to the OGC’s development of the GeoPose Standard, all geospatially anchored poses were proprietary. This has resulted in unnecessary difficulty when sharing GeoPose information between systems. With OGC GeoPose it will be possible to universally express any physical or digital object’s GeoPose in a manner that can be interpreted and used across the range of modern computing platforms and devices. Physical objects may include AR display devices (being a proxy for a user’s eyes), vehicles, robots, or even a park bench, while digital objects may include a BIM model, a computer game asset, the origin and orientation of the local coordinate system of an AR device, or a point-cloud dataset. 

The candidate OGC GeoPose Standard specifies eight standardization targets: two “Basic” forms with no configuration options, for common use cases, an “Advanced” form with more flexibility for more complex applications, and five composite structures that support time series plus chain and graph structures. The candidate GeoPose Standard is modular, flexible, and designed to suit a range of applications and use cases and enable the exchange of GeoPose information between them.

Downloads: 
Comment: 

Comments can be submitted by creating an issue in the OGC GeoPose GitHub Repository

Subscribe: 

Please subscribe via the OGC GeoPose GitHub Repository

OGC Requests: 
OGC Requests

Public comment requested: Simple Features 2021

Status: 
Please note:  This Request is scheduled to close on 26 August 2021
Open Date: 
Tue, 07/27/2021
Closing Date: 
Thu, 08/26/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on an update to the Simple Features Standard. 

Simple Features, OGC’s earliest standard and jointly published with ISO, describes how a user can model the location of “features” (a geometric representation of anything of interest) in a 2-dimensional space representing the surface of a planet as a geoid and any globe or map derived through a projection. 

In technical terms, Simple Features can model geometries which display geographic features of 1-dimension (curves) and 2-dimension (areas) defined by one-dimension boundary curves. If the application requires elevation, then the uses of latitude (φ), longitude (λ) and elevation (h) can be added.

The update brings two major changes (that won’t affect compatibility with existing implementations):

  • Geometric calculations of distance and area using Differential Geometry to directly transform latitude and longitude to meters, enabling to measure lengths or line strings length (as meters) and polygonal area (in square meters). 
  • Programming in both compiled programming (e.g. C++) and web scripting languages such as JSON (JavaScript Object Notation) with dynamic features as well as support for existing data models.

Update of the Simple Features Standard will ultimately result in a multi-part Standard that references the OGC Features and Geometries Abstract Specification (Topic 1) and supports both static and dynamic data models.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: OGC GeoPackage Extension for Tiled Gridded Coverage Data

Status: 
Please note:  This Request is scheduled to close on 15 August 2021.
Open Date: 
Fri, 07/16/2021
Closing Date: 
Sun, 08/15/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on version 1.1 of the OGC GeoPackage Extension for Tiled Gridded Coverage Data (TGCE). 

TGCE defines how to encode and store tiled regular gridded data, such as a digital elevation model, in a GeoPackage. The tiles contain values, such as elevation, temperature or pressure, and the extension defines two encodings: PNG and TIFF. 

GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. For a primer on the capabilities of GeoPackage, read the blog post: #GeoPackageDay 2020 - what is GeoPackage?

There are two substantive changes incorporated into the GeoPackage Tiled Gridded Coverage Version 1.1 extension. These changes do not impact backwards compatibility.

  • Support for additional data types in GeoPackage coverages, specifically: 8/16/32 bit signed integers; 8 bit unsigned integer (16-bit integer is currently supported, but only for PNG); 32-bit floating point (already supported in GeoPackage coverages); and 1 bit (e.g. as a binary mask).
  • Multiple channels in a GeoPackage Coverage can now be specified.

The release notes containing the full list of changes seen in version 1.1 are available at: portal.ogc.org/files/98334.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: Planetary Domain Working Group charter

Status: 
Please note:  This Request is scheduled to close on 4 August 2021.
Open Date: 
Wed, 07/14/2021
Closing Date: 
Wed, 08/04/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft charter for a new Planetary Domain Working Group (DWG).

The objective of the Planetary DWG is to identify requirements to revise or extend OGC standards for celestial bodies other than the Earth. Such bodies include planets, satellites, asteroids, and comets. The overall mission of the Planetary DWG is to ensure that OGC standards remain current with the scientific requirements for celestial bodies established by the planetary science community. 

Geospatial data has been successfully standardized for Earth Observation for many years across various disciplines such as geosciences, the environment, energy, pollution, forestry, or marine sciences. This has allowed scientists to cross-reference data from various themes to broaden their research and understanding in a wider context. 

The OGC interoperability standards for Earth Observation data can be transposed for use with planetary data. The proliferation of planetary data, available in various wavelengths and time scales, is accompanied by an increase in data volume with the use of more and more sophisticated sensors. To cope with this increase in data volume and data sources, it is necessary to extend the Earth OGC standards for use with solar system celestial bodies. 

The Planetary DWG aims to improve the efficiency and effectiveness of spatial data as used in planetary research and education through supporting the propagation of interoperable geospatial products and other information consumables that can be shared across the community. To accomplish this, the Planetary DWG will establish a dialogue within the planetary community to develop, promote, and introduce technology relevant to that community and demonstrate the value of OGC processes and specifications.

The Planetary DWG will serve as a forum within OGC to unite user communities interested in planetary management, such as governments, vendors, industry groups, and other standards organizations.

Downloads: 
Comment: 

Please submit your comments using the following link: charter-requests [at] opengeospatial.org (Click here to submit comments).
Please refer to the following template for the contents of your message: Comments Template.

Subscribe: 

Charter requests are not currently able to be subscribed to.

OGC Requests: 
OGC Requests

Public comment requested: Zarr Storage Specification 2.0 Community Standard

Status: 
Please note:  This Request is scheduled to close on 29 July 2021.
Open Date: 
Tue, 06/29/2021
Closing Date: 
Thu, 07/29/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft Zarr Storage Specification 2.0 Community Standard. 

Zarr is an open-source specification for the storage of multi-dimensional arrays of data (also known as data cubes, N-dimensional arrays, ND-arrays, or tensors). Such arrays are ubiquitous in scientific research and engineering. 

Zarr stores metadata using .json text files and array data as (optionally) compressed binary chunks. Zarr can store data into most storage systems, including databases, standard ‘directory based’ file systems, and cloud object stores, such as Amazon S3. This flexibility allows implementations to experiment with novel storage technologies while maintaining a uniform API for downstream libraries and users.

Zarr arose in genomics research in 2016. It was created by Alistair Miles of Oxford University as a library optimized for massively parallel array analytics. It has since grown into a community project with a range of developers and users from fields such as genomics, bioimaging, astronomy, physics, quantitative finance, oceanography, atmospheric science, climate science, and geospatial imaging. 

Because it can represent very large array datasets in a simple, scalable way, and is compatible with cloud object storage, Zarr is an ideal format for analysis-ready geospatial data in the cloud. Indeed, Zarr has already been adopted by several OGC communities as a format for cloud-optimized, analysis-ready geospatial data. Examples include:

While Zarr is not inherently a geospatial-specific format, it has been put forward by the Zarr Steering Council for adoption as an OGC community standard because of its rapid growth and adoption in geospatial and related fields.

An approved OGC Community Standard is an official standard of OGC that is considered to be a widely used, mature specification, but was developed outside of OGC’s standards development and approval process. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership so that it can become part of the OGC Standards Baseline.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: CoverageJSON Community Standard Work Item Justification

Status: 
Please note:  This Request is scheduled to close on 25 July 2021
Open Date: 
Fri, 06/25/2021
Closing Date: 
Sun, 07/25/2021
Description: 

The Open Geospatial Consortium (OGC) is considering CoverageJSON for adoption as an official OGC Community Standard. A new Work Item justification to begin the Community Standard endorsement process is available for public comment. 

CoverageJSON is a simple, human- and machine-readable format for publishing spatio-temporal data to the Web. It is used for encoding coverage data such as multi-dimensional grids, time series, and vertical profiles, distinguished by the geometry of their spatio-temporal domain. 

The CoverageJSON format supports the efficient download of useful quantities of data from datastores to lightweight clients, such as browsers and mobile applications. It allows local manipulation of the data in a format familiar to, and popular with, web developers, and that is readily usable by e.g. science researchers. It uses linked-data (JSON-LD) to reduce data payload volumes. 

CoverageJSON was developed in 2015 at the University of Reading, as part of MELODIES (Maximizing the Exploitation of Linked Open Data in Enterprise and Science), a EU Framework 7 project, inspired by a demonstration by Joan Masó of CREAF.

The project identified a gap in the capabilities available to the developers of websites and apps who wish to consume scientific data. Existing data formats (e.g. NetCDF, HDF, GRIB, XML) were either highly complex or inappropriate to be used in these environments. Therefore the CoverageJSON format was developed for encoding many kinds of scientific and Earth Observation data in a manner that is friendly for web and app developers. 

CoverageJSON is based on the concepts and standards from ISO and OGC, and the specification is published openly on the web. The specification is supported by a Cookbook, plus a suite of open source tools for producing and consuming the format. Great interest in the format has already been shown by the user community, who are also encouraged to contribute to its development via GitHub.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: Indexed 3d Scene Layer (I3S) and Scene Layer Package (*.slpk) Format Community Standard v1.2

Status: 
Please note:  This Request is scheduled to close on 16 July 2021.
Open Date: 
Wed, 06/16/2021
Closing Date: 
Fri, 07/16/2021
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on version 1.2 of the OGC Indexed 3d Scene Layer (I3S) and Scene Layer Package (*.slpk) Format Community Standard. 

I3S enables the streaming and storage of arbitrarily large amounts of 3D geographic data. An I3S dataset, referred to as a Scene Layer, can consist of millions of discrete 3D objects with attributes, integrated surface meshes, symbolized points, or point cloud data covering vast geographic areas. Designed for performance and scalability, a scene layer enables the efficient encoding and transmission of geospatial content for an interactive visualization experience on web browsers, mobile, and desktop apps for both offline and online access. 

I3S is web and cloud friendly and is rooted in modern standards and technological advancements in the areas of 3D graphics, data structuring, and mesh and texture compression. I3S is accessible for efficient client-side filtering. I3S empowers city and local governments, content providers, and GIS professionals to share scene layers consisting of terabytes of nation-wide point cloud coverage, city and site scale 3D mesh data collected at frequent intervals, 3D planning scenarios fusing both ‘as built’ and modeled information, and more. The increased accessibility and ease of consumption of geospatial content by both domain experts as well as casual users is being rapidly accelerated by standards such as I3S.

The changes included in v1.2 of the OGC I3S Community Standard include:

  • Enhanced performance and scalability.
  • Introduction of paged node access pattern which significantly reduces the client-server traffic by bundling individual node metadata resources into compact pages of nodes.
  • Support for Draco geometry compression. Draco compression of I3S geometry attributes creates more compact nodes, which in turn provides a smaller payload, increasing performance.
  • Support for Basis Universal Texture format in Khronos KTX2 standard.
  • More optimal selection strategy – standardizes on Oriented Bounding Boxes (OBBs) based node selection criterion.
  • Support for advanced material definitions such as physically based materials. Feature compatible with Khronos glTF standard.
  • Numerous editorial updates/corrections.

This version 1.2 of the OGC Community Standard mirrors version 1.7 of the original Esri Scene Layers: Service and Package Standard. For more information visit the Esri I3S Spec GitHub page.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Public comment requested: OGC API - Common - Part 1: Core

Status: 
Please note:  This Request is scheduled to close on 24 May 2021.
Open Date: 
Fri, 04/23/2021
Closing Date: 
Mon, 05/24/2021
Description: 

The Open Geospatial Consortium (OGC) is seeking public comment on the candidate OGC API - Common - Part 1: Core standard.

OGC APIs usher in a new age for location information on the web, enabling a much simpler way to share and access location information that is consistent with the architecture of the Web. The OGC API family of standards defines modular API building blocks to spatially enable Web APIs in a consistent way. Through the OGC APIs, the OGC community is standardizing how location information can be integrated: by any developer, with any other type of information, and into any type of application.

In the course of developing the family of OGC API standards, some elements proved to be common across them all. OGC has documented these common elements in the form of the OGC API - Common candidate standard.

OGC API - Common serves as a solid foundation upon which all OGC APIs can be built. The candidate standard identifies resources, captures compliance classes, and specifies requirements that are applicable to all OGC API standards.

Since OGC API - Common is the foundation for OGC API standards, a stable baseline is required prior to developing those standards. Yet the OGC API - Common standard cannot be finalized until it has been validated against those same standards. Therefore, the OGC API - Common SWG decided that OGC API - Common would go through at least two OGC Public Comment Periods. The initial request, in February 2020, established a “beta” version that was stable enough for use by other OGC API standardization efforts. Now that there is sufficient implementation experience, this final request seeks comment on the OGC API - Common candidate Standard as well as an answer to the question of whether OGC API - Common should be a Standard.

An alternative approach to making OGC API - Common an official OGC Standard has been proposed where OGC API - Common would instead take the form of an official registry of API building blocks fundamental to all OGC API Standards. In order to maintain the interoperability between different OGC APIs, these building blocks are to be reused when developing OGC API Standards. For more information, see this discussion on the OGC API - Common GitHub Repo.

Downloads: 
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 
OGC Requests

Pages