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

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.

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: 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.

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: 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.

Downloads: 
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: 
OGC Requests

Public comment requested: OGC API - Processes Standards Working Group Charter

Status: 
Please note:  This Request is scheduled to close on 8 March 2021
Open Date: 
Mon, 02/15/2021
Closing Date: 
Mon, 03/08/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on a revision to the OGC API - Processes Standards Working Group (SWG) Charter, which introduces new work items for the SWG. 

The OGC API - Processes SWG is the group within the OGC membership responsible for the development and maintenance of the OGC API - Processes core standard and its extensions, as well as for maintaining the WPS standard.

OGC API - Processes provides organizations the opportunity to make available on the web geospatial software libraries and utilities that, up until now, had only been available as standalone desktop products. It forms a crucial part of OGC’s “user-to-the-data” architecture that allows users to not only mine intelligence from their cloud-based data through streamlined analysis, but also to create value-added products for others to use.

OGC API - Processes, like its predecessor (WPS), achieves this by providing a standardized mechanism for computational geospatial processes to be deployed and offered as services within Cloud Computing environments. 

With the initial development of the OGC API - Processes standard now complete, the OGC API - Processes SWG will begin to address extensions that will simplify the deployment and execution of geospatial processing packages and chained processing workflows.

Specifically, the SWG will begin work on the following extensions to Part 1 Core (final names TBA):

Part 2: Transactions for deployment
This extension will enable the dynamic deployment and execution of processes as application packages. An application package is a file that provides a description of a process(es) to be deployed, including the inputs and outputs of the process(es) as well as other ancillary metadata (e.g. reference to a containerized execution unit) necessary for the process to be deployed. An application package can take many forms (e.g. Jupyter notebook, workflow execution document, etc.) and so this extension will not mandate any specific form but will instead include one or more optional conformance classes for application package formats that have been developed via OGC Innovation Program Initiatives (e.g. CWL, MOAW, OGC Application Package, etc.). 

Part 3: Workflows and Chaining
This extension will provide the ability to:

  • chain nested processes,
  • refer to external processes and collections accessible via OGC API standards, and
  • trigger execution of processes through OGC API data delivery specifications (such as OGC API - Features, Tiles, Maps and Coverages).

The SWG will look at different solutions for workflows and chaining to ensure validation of the defined architecture across multiple approaches.

OGC Members interested in staying up-to-date on the progress of this standard, or contributing to its development, are encouraged to join the SWG via this link on the OGC Portal.

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: OGC Coverage Implementation Schema (CIS) - ReferenceableGridCoverage Extension v1.1

Status: 
Please note:  This Request is scheduled to close on 3 March 2021.
Open Date: 
Mon, 02/01/2021
Closing Date: 
Wed, 03/03/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on version 1.1 of the OGC Coverage Implementation Schema (CIS) - ReferenceableGridCoverage Extension. Comments are due by March 3, 2021.

The CIS ReferenceableGridCoverage Extension extends CIS (a supporting standard of the Web Coverage Service Standard) to provide a set of referenceable grid elements to enable an accurate determination of pixel locations in observed imagery. The Extension accomplishes this, in part, by allowing connections to OGC SensorML 2.0+ sensor models from OGC CIS 1.0+ coverages.

Version 1.1 of this standard permits use of the more concise array encoding of sensor model parameters in SensorML 2.1 documents via the new element setEncodedValues, enabling more compact sensor model descriptions.

A referenceable grid enables the location of all points in a simple grid (such as a set of pixels in an image) to be determined in a Coordinate Reference System (CRS), by providing a means to specify additional geometrical information such as a sensor model. A sensor model may describe, for example, the collection of light rays by an Earth Observation (EO) imagery sensor consisting of a rectangular array of light sensing pixels. 

The extension enables OGC imagery standards based on CIS 1.0+ (such as GMLJP2 2.1) to be able to contain sensor models described with OGC SensorML 2.0+. SensorML 2.0+ can be used to describe and share a wide range of sensor models, for example imaging systems located on satellite and airborne platforms. A simple example of such a description would be the location of a camera, the direction in which it is pointing, as well as details of the camera’s imaging system, such as the number of pixels, the principal point offset, the focal length, and the optical distortion parameters. This data is thus available for mapping every imaged pixel to a location in an external CRS.

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: GeoTIFF Standard Working Group charter update

Status: 
Please note:  This Request is scheduled to close on 11 February 2021.
Open Date: 
Thu, 01/21/2021
Closing Date: 
Thu, 02/11/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft updated charter for the GeoTIFF Standard Working Group (SWG), which introduces several new tasks for the SWG. 

The Geographic Tagged Image File Format (GeoTIFF) specification, as an extension to the public domain TIFF format, has been used for sharing geographic image data successfully for years across many platforms and software environments. GeoTIFF defines a set of TIFF tags that describe the "cartographic" information associated with TIFF imagery originating from satellite imaging systems, scanned aerial photography, scanned maps, digital elevation models, or as a result of geographic analyses. 

The initial scope of the GeoTIFF SWG was to incorporate the GeoTIFF specification into the OGC standards suite by updating the specification to bring it into conformance with current OGC practices. The resulting Standard, GeoTIFF v1.1 was adopted as an OGC Standard in 2019. The original scope of the GeoTIFF also specified that the SWG would: provide a forum for evolving the standard in the future; maintain compatibility with existing geoTIFF community implementations and practices; and that future evolution would be done in close cooperation with the existing geoTIFF community.

As a result of that cooperation, the GeoTIFF SWG has updated its charter to include the following additional tasks to support the evolution of this popular standard:

  • GeoTIFF 1.2 - This task will address open issues which were out of scope for version 1.1 but not significant enough for a major revision. GeoTIFF 1.2 shall maintain backward compatibility with GeoTIFF 1.1.
  • BigTiff support - The TIFF file format uses 32 bit offsets. This limits TIFF files to four gigabytes. The BigTIFF format resembles TIFF but uses 64 bit offsets instead. GeoTIFF 1.1 will be extended to enable bigTIFF (in addition to TIFF).
  • Standardize Cloud-Optimized GeoTIFF (COG) - The COG community would like to turn-over management of the COG specification to OGC. OGC shall establish a GeoTIFF/TIFF standard or best practice that fully documents the COG format in the manner of an OGC specification.
  • GeoTIFF / LAS harmonization - This task will examine the overlap between GeoTIFF and LAS. The deliverable will be recommendations on how to keep these two standards synchronized.
  • Data Cubes - This task will explore the potential of GeoTIFF to support analytics including coverages and data cubes.
  • GeoTIFF 2.0 - This task will examine issues which cannot be addressed within the scope of a minor update (GeoTIFF 1.2).

 

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: Features API SWG recharter

Status: 
Please note:  This Request is scheduled to close on 5 February 2021.
Open Date: 
Fri, 01/15/2021
Closing Date: 
Mon, 02/15/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the proposed updated charter for the Features API Standards Working Group (SWG). 

The purpose of the Features API SWG is to: develop new and maintain existing parts of the OGC API - Features multipart standard; develop corrigenda for the related WFS 2.0 and FES 2.0 standards; and review draft Engineering Reports from the OGC Innovation Program related to OGC API - Features.

The recharter adds the following new work items to the SWG:

  • Property selection - the ability to specify which feature properties should be presented in a response document.
  • Geometry simplification - the ability to specify a resolution so that geometries are appropriately simplified (e.g., if you are zoomed out quite far, a polygon may be sufficiently represented as a point).
  • Schema - will specify resources for various schemas related to a feature. For example: presentation schema - the properties that can appear in a response document; query schema - the properties that can be used to formulate query expressions, or; mutation schema - the schema of the feature that can be used to insert/update/delete features.
  • Queries - specify new resources to handle long query expressions, multi-collection queries, and stored queries (with and without parameters).

OGC API - Features is a multi-part standard that offers the capability to create, modify, and query spatial data ‘features’ on the Web (features are simply the digital representations of objects of interest in the real world) and specifies requirements and recommendations for APIs that want to follow a standard way of sharing feature data. 

The new family of OGC APIs are a new set of building blocks for location. The OGC APIs usher in a new age for discovering and accessing location information on the web by 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.

The new OGC APIs make use of the OpenAPI Specification (OAS) – a broadly adopted industry standard for describing modern APIs. APIs that implement OAS provide an interface that enables humans and computers to easily discover and understand the capabilities of a service without having to refer to external documentation or guesswork, greatly improving the accessibility of location data.

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: proposal for revision to Indexed 3D Scene Layers (I3S) Community Standard

Status: 
Please note:  This Request is scheduled to close on 15 February 2021.
Open Date: 
Thu, 01/14/2021
Closing Date: 
Mon, 02/15/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the proposal for a revision to the OGC Indexed 3D Scene Layers (I3S) Community Standard. The proposed revision is defined in the I3S Version 1.2 Community Standard Work Item Justification document. 

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 billions of point cloud data covering vast geographic areas. Designed for performance and scalability, a scene layer enables the efficient encoding and transmission of various types of geospatial content for an interactive visualization experience on web browsers, mobile, and desktop apps for both offline and online access. A Scene Layer can be accessed in the form of a web service or Scene Layer Package (SLPK) – a file-based exchange format.

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 proposed revisions for I3S version 1.2 include:

  • Introduction of paged node access pattern – which significantly reduces the client-server traffic by bundling individual node metadata resources into compact pages of nodes.
  • Introduction of a more compact geometry layout for 3D Object and Integrated Mesh layers binary geometry payloads – using a well-known quantization encoding (Draco).
  • Introduction of an advanced material definitions property such as physically based materials.
  • More optimal selection strategy – standardizes on Oriented Bounding Boxes (OBBs) based node selection criterion.
  • Editorial updates/corrections.

These new enhancements are based on the Esri I3S version 1.7 product release.  OGC I3S v1.2 is backwards compatible with OGC I3S v1.1.

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: CDB SWG re-charter

Status: 
Please note:  This Request is scheduled to close on 2 February 2021
Open Date: 
Tue, 01/12/2021
Closing Date: 
Tue, 02/02/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft updated charter for the CDB Standards Working Group (SWG). The purpose of the CDB SWG is to maintain and improve the OGC CDB Standard and Best Practices documents. Comments are due by the 2nd of February, 2021.

The CDB standard defines an open format for the storage, access, and modification of a synthetic environment database. A synthetic environment is a computer simulation that represents activities at a high level of realism for use in a diverse array of applications, from simulation of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by realistic special effects and accurate behavioral models. Synthetic Environments allow visualization of, and immersion into, the environment being simulated. 

The CDB standard defines the organization and storage structure of a worldwide synthetic representation of Earth, as well as the conventions necessary to support all of the subsystems of a full-mission simulator. CDB makes use of several commercial and simulation data formats endorsed by leaders of the database tools industry.

The modeling & simulation end-user community increasingly requires “plug and play” synthetic environment database re-use and a common synthetic environment local representation to enhance realism and “fair fight” concepts in military simulation. The cost benefit of re-using complex curated synthetic environments is one major objective. In military simulation communities, heterogeneous simulations within Live (using real-world vehicles), Virtual (simulations with human-in-the-loop vehicle controllers), Constructive (simulations within which entity dynamics are computer controlled), and Gaming (LVC-G) are being composed on demand; such federations are severely limited by the current common practice using local proprietary data models and formats.

As such, the following additional tasks are proposed to be undertaken by the CDB SWG:

  1. Development of a minor revision, CDB V1.3, to provide a backwards-compatible capability to encode CDB attribution data in a modernized approach, as recommended in part by OGC Discussion Paper 20-092, which summarizes the experimentation and outcomes of the US SOCOM / SOFWERX sponsored Geospatial Tech Sprint II that was concluded in October 2020.
  2. Continued development of CDB X, a major revision to the OGC CDB Standard.
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

Pages