OGC Requests

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

Status: 
Please note:  This Request is scheduled to close on 19 October 2020.
Open Date: 
Thu, 09/17/2020
Closing Date: 
Mon, 10/19/2020
Description: 

The draft OGC API - Processes Standard specifies a Web API that enables the execution of computing processes and the retrieval of metadata describing their purpose and functionality. For example, these processes could combine raster, vector, coverage and/or point cloud data with well-defined algorithms to produce new raster, vector, coverage and/or point cloud information.

The draft OGC API - Processes Standard builds on the Web Processing Service (WPS) 2.0 standard and defines the processing standards to communicate in a RESTful manner using JSON encodings. This API is a newer and more modern way of programming and interacting with resources over the web while allowing better integration into existing software packages.

In many cases, location data, including data from sensors, must be processed before the information can be effectively used. OGC API - Processes, just like the OGC WPS Interface Standard, provides a standard interface that simplifies the task of making simple or complex computational geospatial processing services accessible via web services. Such services include well-known processes found in GIS software as well as specialized processes for 2D/3D/4D modeling and simulation. The API also makes it easy for developers to implement microservices that can handle location data.

The draft OGC API - Processes Standard provides a similarly robust, interoperable, and versatile protocol for process execution across the Web. OGC API - Processes supports both immediate processing for computational tasks that take little time and asynchronous processing for more complex and time-consuming tasks.

As with other OGC APIs, OGC API - Processes consists of optional parts that each provide extra functionality. This specification, Part 1: Core, is intended to be a minimal useful API for the execution of processes from the geospatial domain. There are no constraints on the types of processes that can be published through the API. Examples of processes that have been demonstrated during the development of the draft API standard include routing, contour generation, buffering, coverage processing and several others. The API is therefore expected to be applicable to several domains.

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 - Environmental Data Retrieval

Status: 
Please note:  This Request is scheduled to close on 28 September 2020
Open Date: 
Thu, 08/27/2020
Closing Date: 
Mon, 09/28/2020
Description: 

The OGC API - Environmental Data Retrieval (OGC API - EDR) standard uses current web technologies and best practices to enable end-users – or anyone with web development experience – to easily identify and retrieve a subset of data from ‘big data’ stores. The idea is to save those users interested in environmental (or other) data from having to transfer and deal with datasets that inevitably contain data concerning areas or time periods that are irrelevant to their interests. In addition, as a web API, it uses a well-understood and -established mode of interaction that comes with a shallow learning curve.

The new OGC API family of standards uses the OpenAPI specification to define modular API building blocks to spatially enable Web APIs in a consistent way. The OGC API - EDR standard specifies the fundamental API building blocks required to access environmental data resources by requesting data at a Position, within an Area, or along a Trajectory, including optional time and/or vertical coordinates.

The OGC API - EDR standard is not just for accessing ‘environmental’ data but can also support more general geospatial data. The versatility of the OGC API - EDR standard makes it useful across many domains and applications. Example use cases could include: 

  1. A tower crane operator wants to know the wind speed and direction at a series of levels between the surface and 75m above from now and for the next 48 hours. The OGC API - EDR standard could be used to access the gridded weather forecast dataset and return those values to their browser in JSON.
  2. An aviator wants access to all the current aerodrome observations of visibility in a specified area. The OGC API - EDR standard could be used to access a certified METAR (METeorological Aerodrome Report) database and to return those values without the user having to decipher all the METAR content.
  3. A hydrologist would like to retrieve both observed and forecast water levels from a network of gauging stations. The OGC API - EDR standard could be used to retrieve those values by station name rather than geographical coordinates.
  4. A Public Safety Official would like to know the predicted wind speeds along several forecast typhoon tracks or in a corridor around such tracks. The OGC API - EDR standard could be used to interrogate in turn several such predictions.
  5. The OGC API - EDR standard can also be used to access data in non-real-world coordinate systems, such as for retrieving bone density from a 3D MRI scan, at a single position or along a track, or to retrieve the color or gray-scale value from a location on a digitised microscope slide.

 

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: Zarr Community Standard Work Item Justification

Status: 
Please note:  This Request is scheduled to close on 11 September 2020.
Open Date: 
Fri, 08/21/2020
Closing Date: 
Fri, 09/11/2020
Description: 

The Open Geospatial Consortium (OGC) is considering the Zarr v2 Storage Specification 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. 

Zarr is an open-source specification for the storage of multi-dimensional arrays of data (also known as 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 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: OGC Abstract Spec Topic 21 - Discrete Global Grid Systems

Status: 
Please note:  This Request is scheduled to close on 4 September 2020
Open Date: 
Wed, 08/05/2020
Closing Date: 
Fri, 09/04/2020
Description: 

The Open Geospatial Consortium (OGC) membership has proposed updates to the OGC Abstract Spec Topic 21 - Discrete Global Grid Systems (DGGS) document and is seeking public comment before approval. This version was jointly developed with ISO TC211 and has the same normative content as ISO/DIS 19170-1:2020.

The goal of a DGGS is to enable rapid assembly of spatio-temporal data without the difficulties of working with projected coordinate reference systems and complex geometries. DGGSs represent the Earth (or other planetary bodies) as hierarchical sequences of tessellations, each with global coverage and with progressively finer resolution. Each cell (or zone) in the tessellations has a unique identifier, so that individual observations can be assigned an identifier corresponding to both the position and size of the phenomenon being observed. This means that the resolution and precision of the data capture is inherently part of the stored data; not something that needs to be explained in metadata and therefore potentially overlooked.

Further, DGGS come with a standard set of topological queries that enable rapid data analysis of very large numbers of zones and, by their very nature, are well suited to parallel processing applications at multiple spatial resolutions - a boon for big data processing.

The changes in this revised edition compared to the previous OGC edition include:

  • Separation of the DGGS standard into common modules and an extension for Equal Area Earth DGGS;
  • Remodelling to incorporate new versions of ISO 19107, ISO 19111 & ISO 19112, and tighter integration with ISO 19115-1
  • Extending the common module to support up to three spatial dimensions and up to one temporal dimension;
  • Additional modelling of temporal geometry and temporal reference systems sufficient for spatio-temporal DGGS, introducing the concept of a zone as a region of space-time equivalent to a location or an era; 
  • Remodelling algebraic functions as spatio-temporal extension of ISO 19107 Query;
  • Explicit handling of Dynamic vs Static datums for Equal Area Earth DGGS.
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: DGIWG 112 Defence Profile of OGC’s Web Map Service 1.3 - Revision

Status: 
Please note:  This Request is scheduled to close on 3 September 2020
Open Date: 
Tue, 08/04/2020
Closing Date: 
Thu, 09/03/2020
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on updates to two Best Practice documents concerning Defence Profiles: DGIWG 122 Defence Profile of OGC’s Web Feature Service 2.0; and DGIWG 112 Defence Profile of OGC’s Web Map Service 1.3 - Revision.

This request is for DGIWG 112 Defence Profile of OGC’s Web Map Service 1.3 - Revision
For DGIWG 122 Defence Profile of OGC’s Web Feature Service 2.0 please see: https://www.ogc.org/standards/requests/211

OGC Web Feature Service (WFS) and Web Map Service (WMS) are two of OGC’s most popular standards and are broadly used in the defence community. OGC WFS provides location-based/geospatial data over the web for visualization or analysis, while OGC WMS provides pre-rendered maps over the web.

The Defence profiles for the standards were created by the Defence Geospatial Information Working Group (DGIWG) in order to address specific requirements, recommendations and guidelines for implementations of the OGC Web Map Service and OGC Web Feature Service standards. Together with the DGIWG profiles for Catalogue Service for the web (CSW), Web Map Tile Service (WMTS) and Web Coverage Service (WCS) they built the basis for NATO STANAG 6523 - Defence Geospatial Web Service Edition 1(2020).

The revisions to the documents:

  • address comments and change requests from OGC testbeds and partners
  • clarify and simplify requirements
  • add informative information to support implementation
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: DGIWG 122 Defence Profile of OGC’s Web Feature Service 2.0

Status: 
Please note:  This Request is scheduled to close on 3 September 2020
Open Date: 
Tue, 08/04/2020
Closing Date: 
Thu, 09/03/2020
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on updates to two Best Practice documents concerning Defence Profiles: DGIWG 122 Defence Profile of OGC’s Web Feature Service 2.0; and DGIWG 112 Defence Profile of OGC’s Web Map Service 1.3 - Revision.

This request is for DGIWG 122 Defence Profile of OGC’s Web Feature Service 2.0.
For DGIWG 112 Defence Profile of OGC’s Web Map Service 1.3 - Revision please see: https://www.ogc.org/standards/requests/212

OGC Web Feature Service (WFS) and Web Map Service (WMS) are two of OGC’s most popular standards and are broadly used in the defence community. OGC WFS provides location-based/geospatial data over the web for visualization or analysis, while OGC WMS provides pre-rendered maps over the web.

The Defence profiles for the standards were created by the Defence Geospatial Information Working Group (DGIWG) in order to address specific requirements, recommendations and guidelines for implementations of the OGC Web Map Service and OGC Web Feature Service standards. Together with the DGIWG profiles for Catalogue Service for the web (CSW), Web Map Tile Service (WMTS) and Web Coverage Service (WCS) they built the basis for NATO STANAG 6523 - Defence Geospatial Web Service Edition 1(2020).

The revisions to the documents:

  • address comments and change requests from OGC testbeds and partners
  • clarify and simplify requirements
  • add informative information to support implementation
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: GeoSPARQL Standards Working Group re-charter

Status: 
Please note:  This Request is scheduled to close on 6th August 2020.
Open Date: 
Thu, 07/16/2020
Closing Date: 
Thu, 08/06/2020
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft updated charter for the OGC GeoSPARQL Standards Working Group (SWG). The GeoSPARQL SWG will revise, and likely extend, the GeoSPARQL standard. Comments are due by August 6, 2020.

GeoSPARQL is a standard for the representation and querying of geospatial linked data for the Semantic Web.

Since the release of GeoSPARQL in 2012, there has been growth of both the Semantic Web and spatial information represented in Semantic Web form, with GeoSPARQL being widely used for spatial Semantic Web data.

As with many standards that see widespread use, suggestions for enhancements and extensions are made by users as they extend beyond the requirements used to define the original standard. Additionally, subsequent technological developments or knowledge gained in the use of the standard leads to new requirements.

The overall mission of the GeoSPARQL SWG is to ensure that the features of GeoSPARQL remain up-to-date with the Semantic Web community whose needs now outstrip the current content of GeoSPARQL.

This revision will likely result in a major update of GeoSPARQL that will form a new base Semantic Web standard for people working with spatial data. The update will include consideration of backwards-compatibility with GeoSPARQL 1.0 as a key requirement.

More information on the need to update GeoSPARQL is contained in the draft charter.

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: Routing Standards Working Group Draft Charter

Status: 
Please note:  This Request is scheduled to close on 2 July 2020.
Open Date: 
Thu, 06/11/2020
Closing Date: 
Thu, 07/02/2020
Description: 

Using geospatial information to plan routes for travel and logistics is among the most common uses of geospatial and location-based technologies, with countless routes being generated daily by smartphone users, logistics companies, and others. In support of this, road network data, routing & navigation algorithms, and route calculation services are now available from many different providers and sources. While this diversity in the marketplace is generally beneficial to consumers of route information, it makes accessing, integrating, overlaying, or comparing routes from different routing services overly complex.

The OGC API - Routes will enable a simple method for an application to query any number of routing and/or data providers, even across multiple modes of transport, and present the resulting routes to the user in a single place. The capability for a client to request and retrieve routes from a routing API provider and share routes between applications will improve interoperability for many users, communities, and enterprises.

  • For providers of routes, the API and route exchange model will provide a simple model to publish and offer those routes as resources for use by other systems.
  • For developers building infrastructures, the API will provide common methods to describe and leverage existing routing engines and algorithms using modern APIs - saving the time and costs associated with developing and deploying custom interfaces.
  • For users, applications, and enterprises, the capability to get routes via a common API, regardless of the underlying routing data, engines, or algorithms will provide a significant step forward in geospatial interoperability and modularity.

The proposed OGC API - Routes will provide the methods and apparatus for the execution of basic commands to retrieve, update, share, and delete routes, and will interface with other geospatial resources that use OGC APIs. The proposed route exchange model will provide a method to share routes, regardless of the underlying proprietary data, routing engine software, or algorithms.

Draft specifications for a routing API and route exchange model were successfully demonstrated in the OGC Open Routing API Pilot, the OGC Smart City Interoperability Reference Architecture (SCIRA) Pilot, and other efforts. Coordination with W3C on OGC API - Routes has begun with discussions in the joint W3C/OGC Spatial Data on the Web Interest Group.

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: Standard SensorThings API Part 1 - Sensing V1.1

Status: 
Please note:  This Request is scheduled to close on 6 July 2020.
Open Date: 
Thu, 06/04/2020
Closing Date: 
Mon, 07/06/2020
Description: 

 

The OGC SensorThings API provides an open, geospatially enabled, unified way to interconnect Internet of Things (IoT) devices, data, and applications over the web. SensorThings is currently being used by organizations around the world in support of logistics, public safety, energy utilities, environmental monitoring, and more.

At a high level, the OGC SensorThings API provides two main functionalities, with each function handled by a specific part of the standard: Sensing and Tasking. 

Under public comment is a new version (v1.1) of the Sensing part, which provides a standard way to manage and retrieve observations and metadata from heterogeneous IoT sensor systems. The separate Tasking part provides a standard way for parameterizing - also called tasking - of taskable IoT devices, such as sensors or actuators.

Version 1.1 of the SensorThings API is mostly backwards compatible with v1.0. The main changes in v1.1 include:

  • An additional field for storing additional metadata that is useful for filtering. 
  • Additions to the service root page that allow users to easily see exactly which extensions and optional features a server implements. Additionally, the MQTT extension can now list the MQTT endpoints on the root page so that a user can discover those endpoints.
  • A fix for inconsistencies and incompatibilities surrounding the transmission of the specification version number in MQTT topics.

The first two changes should not impact clients implemented based on version 1.0. The third change, however, may cause some minor issues for some clients that are not using the version prefix in MQTT topics.

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 seeks public comment on Version 1.3 of GeoPackage Standard

Status: 
Please note:  This Request is scheduled to close on 4 June 2020.
Open Date: 
Tue, 05/05/2020
Closing Date: 
Thu, 06/04/2020
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the latest version of the GeoPackage Standard, v1.3.0. GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. Comments are due by June 4, 2020.

GeoPackage version 1.3.0 is a minor revision to the current version 1.2.1. All of the changes were carefully considered for impact on existing implementations. Any changes considered to have a significant impact on reverse compatibility were rejected or recast in order to limit their impact.

In addition to a number of administrative changes to improve readability, clarity, and correctness, the following substantive changes were incorporated into the draft GeoPackage 1.3 release:

  • Enforce alignment of Spatial Reference System (SRS) Identifiers between tables.
  • Clarify use of views in user-defined tables.
  • Relax Requirement 104 to allow use of schemas with attributes and extensions.
  • Allow metadata scopes to be extended.
  • Create new Requirement 152 to describe empty geometries.

 

Comment: 

Comments can be submitted 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. There are three ways to provide input into the candidate standard:

  1. Edit the document on GitHub: if you are familiar with GitHub, please make your proposed changes directly. Instructions are in the README.md file in that repository.
  2. Submit an "issue" on GitHub: GitHub offers a simple interface for posting an issue/comment. Just click the green "New Issue" button.
  3. Submit your comments requests [at] lists.opengeospatial.org (via email. )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: 

Pages