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.

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: 

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.

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: 

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.

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: 

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.

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: 

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.

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: 

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.

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: 

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.

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: 

Public comment requested: Sample Markup Language for Artificial Intelligence Machine Learning Standards Working Group Charter

Status: 
Please note:  This Request is scheduled to close on 5 May 2021.
Open Date: 
Thu, 04/15/2021
Closing Date: 
Wed, 05/05/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the formation of the new Sample Markup Language for Artificial Intelligence Machine Learning (SampleML-AI/ML) Standards Working Group (SWG), which will focus on developing the Sample Markup Language for AI/ML candidate standard for consideration by OGC membership for approval as an OGC Standard. Comments are due by May 5, 2021.

Artificial Intelligence (AI) is expected to play a crucial role in many domains and will revolutionize existing technologies. During the last decade, Machine Learning (ML) techniques, especially Deep Learning, have improved significantly due to an abundance of data and advancements in high-performance computing. ML reorients and transforms geographic information systems (GIS) and Remote Sensing (RS). ML-based applications are now being deployed across diverse markets to provide new solutions and increase human efficiency. Increasingly, the science community is also using these techniques to better harness the ever-increasing volume of Earth Observation (EO) data for geospatial analysis in various domains - such as smart cities, environmental management, and disaster management.

A key component of ML techniques and processes is sample data – data with known provenance, consistent metadata, and quality measurements that can be used to consistently tune and train ML applications. A lack of consistent and known sample data is becoming a bottleneck to advanced EO science applications. The lack of sample data is also causing reproducibility issues and making it difficult to compare results across studies.

Therefore, it is expected that the geospatial community should define stricter specifications and policies to enhance discovery and sharing sample data, in particular to develop a standard Sample Markup Language for AI/ML to document, store, and share the geospatial sample data following the FAIR data management principles of Findability, Accessibility, Interoperability, and Reusability.

The SampleML-AI/ML SWG will develop this Sample Markup Language. The geospatial sample data categories will initially include remote sensing imagery, moving features (typically vehicle trajectories), and related spatial content. The SWG will define a model and encodings to exchange and retrieve the sample data across the Web. The SWG will investigate the feasibility and interoperability of OGC standards to use and share geospatial sample data in ML applications and describe gaps and issues that can lead to a new geospatial standard.

Sample data should have sufficient metadata in a machine-readable standard format, include general spatiotemporal information and sample data-specific attributes to facilitate data discovery and query. Where available, the proposed standard will use existing industry standards commonly used by developers.

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: 

Public comment requested: 3D GeoVolumes Standards Working Group Charter

Status: 
Please note:  This Request is scheduled to close on 5 May 2021
Open Date: 
Wed, 04/14/2021
Closing Date: 
Wed, 05/05/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft charter of the new 3D GeoVolumes Standards Working Group (SWG), which will develop and maintain an OGC API - 3D GeoVolumes core Standard and extensions. Comments are due by May 5, 2021.

In recent years several solutions and standards have emerged to access and transfer 3D geospatial content over the internet (e.g., 3D Tiles, I3S, OGC 3D Portrayal Service, glTF, CDB, CityGML). These solutions were developed for various technical and commercial reasons. They use different distribution mechanisms and are optimized for user requirements and bandwidth situations. As each of these co-existing solutions binds the user to an approach, it is challenging to access a variety of 3D content from different providers. 

3D GeoVolumes seeks to address this challenge by providing a resource model and corresponding API to integrate various approaches into a single, open standards-based solution. The proposed API and resource model will allow efficient discovery and access of 3D content in multiple formats based on a familiar space-centric perspective.

The goal of the Standard is not to replace existing distribution methods and models for 3D content, but to enable interoperability between them. For providers of 3D content, the Standard will provide simple methods to publish and offer that content as resources for use by other systems. For software developers, the Standard will provide common methods to describe and leverage existing 3D content using modern APIs - saving development and deployment time and costs. For users, applications, and enterprises, the ability to discover and access 3D content across a common API, regardless of the underlying distribution mechanism, represents a significant step forward in geospatial interoperability.

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: 

Public comment requested: OGC API - Features - Part 3: Filtering and the Common Query Language (CQL)

Status: 
Please note:  This Request is scheduled to close on 19 April 2021
Open Date: 
Tue, 02/16/2021
Closing Date: 
Mon, 04/19/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the candidate OGC API - Features - Part 3: Filtering and the Common Query Language (CQL) standard, which extends the Core Part of OGC API - Features to support data filtering. Comments are due by April 19, 2021.

OGC API - Features provides API building blocks to create, modify, and query features on the Web. The spatial data community uses the term “feature” for things in the real world that are of interest. For more information on what a ‘feature’ is, see the explanations on Spatial Things, Features, and Geometry in the W3C/OGC Spatial Data on the Web Best Practice document.

OGC API Features is comprised of multiple parts, each a separate standard. Part 1: Core specifies the core capabilities and is restricted to fetching features where geometries are represented in the coordinate reference system WGS 84 with axis order longitude/latitude. Part 2: Coordinate Reference Systems by Reference extends the Core with the ability to use coordinate reference system identifiers other than the defaults defined in the core.

This standard, part 3, handles enhanced filtering: a fundamental operation performed on a collection of features in order to obtain the subset of the data that’s relevant to your workflow. 

As such, part 3 of the OGC API - Features Standard defines:

  • Query parameters (filter, filter-lang, filter-crs) to specify filter criteria in a request to an API;
  • A filter grammar called Common Query Language (CQL) for specifying enhanced filtering criteria beyond what is supported in the Core;
  • Two encodings for CQL - a text and a JSON encoding.

In a geospatial data processing workflow, OGC API - Features - Part 3 allows a web call to define a subset of data hosted in the cloud to be used by, say, a processing API (such as OGC API - Processes), or a web or desktop application for analysis or display. Other OGC API standards like OGC API - Records or OGC API - Tiles will reuse the filtering building blocks to allow filtering on records in a catalog or features in vector tiles.

Comment: 

Comments are to be submitted via the ogcapi-features issue tracker on GitHub.

Subscribe: 

Comments can be followed via the ogcapi-features issue tracker on GitHub.

OGC Requests: 

Pages