OGC Requests

Public comment requested: GeoPackage Well Known Text (WKT) for Coordinate Reference Systems (CRS) Extension

Status: 
Please note:  This Request is scheduled to close on 3 June 2022.
Open Date: 
Wed, 05/04/2022
Closing Date: 
Fri, 06/03/2022
Description: 

 

The Open Geospatial Consortium (OGC) on the GeoPackage Well Known Text (WKT) for Coordinate Reference Systems (CRS) Extension candidate standard. 

The candidate standard revises and replaces the GeoPackage WKT for Coordinate Reference Systems Extension that is currently published as Annex F.10 of GeoPackage Encoding Standard 1.3.0. The candidate extension defines how to encode Coordinate Reference Systems (CRS) in GeoPackage using the OGC CRS WKT2 standard. This new revision adds coordinate epochs to the encoding of coordinate reference systems in a GeoPackage to support dynamic CRSs.

In a dynamic CRS, coordinates of a point on the surface of the Earth may change with time. To be unambiguous, the coordinates must always be qualified with the epoch at which they are valid. In 2021, the GeoPackage SWG approved a change adding coordinate epochs to gpkg_spatial_ref_sys. Because this was the only substantive change to the GeoPackage Encoding Standard being considered at the time, the decision was made to split this extension into a separate document so that it could be considered separately.

GeoPackage is an open, platform-independent, portable, self-describing, compact format for transferring geospatial information. The core (unextended) GeoPackage Encoding Standard supports the older OGC CRS WKT standard. Through this extension, both encodings may be used. However, use of the newer encoding is strongly encouraged. GeoPackage clients are expected to use the newer encoding if both encodings are present.

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: GeoPackage Conceptual Model

Status: 
Please note:  This Request is scheduled to close on 27 May 2022
Open Date: 
Wed, 04/27/2022
Closing Date: 
Fri, 05/27/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the GeoPackage Conceptual Model Candidate Standard. 

GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. To date, GeoPackage uses a SQLite database container. The GeoPackage Conceptual Model Candidate Standard documents an OGC Conceptual and Logical Model Standard for encoding geospatial information in other containers, specifically:

  • vector features;
  • tile matrix sets of imagery and raster maps at various scales;
  • attributes (non-spatial data); and
  • extensions.

The Conceptual Model and Logical Model are Platform Independent Models (PIMs). The Conceptual Model is a high-level description of the concepts involved in the standard, while the Logical Model is an abstract representation of an interface or data model that can be used to produce implementations.

As such, neither the GeoPackage Conceptual nor Logical Models can be implemented directly. Rather, they serve as the base for Platform Specific Models (PSM). A PSM adds to the PIM the details needed to fully define the model for use with a specific technology. The PSM can then be used to generate artifacts such as schemas needed to build GeoPackage implementations. These artifacts include table definitions, integrity assertions, format limitations, and content constraints.

The GeoPackage Conceptual Model Candidate Standard was developed retroactively from the GeoPackage Encoding Standard (GES) v1.3.0. At the time, it was not deemed prudent to develop the Conceptual or Logical Models as the GES was intended specifically for the SQLite database format. However, as SQLite’s inherent limitations became more apparent, stakeholders determined that it would be beneficial to the community to standardize the Conceptual and Logical Models so that other PSMs could potentially be supported in the future. As a result, the candidate standard remains agnostic to its potential uses. The submitters of the candidate standard believe that GeoPackage now has the potential to evolve to support use cases and computing environments that go beyond what was originally conceived for the GeoPackage Encoding Standard.

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: proposed v1.1 update to 3D Tiles Community Standard

Status: 
Please note:  This Request is scheduled to close on 25 May 2022
Open Date: 
Mon, 04/25/2022
Closing Date: 
Wed, 05/25/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on a proposed update of the 3D Tiles Community Standard, which is used for sharing, visualizing, fusing, and interacting with massive heterogenous 3D geospatial content across desktop, web, mobile – and now metaverse – applications. 

The proposed v1.1 revision to the 3D Tiles Community Standard, planned for submission to OGC by Cesium, is designed for streaming high-resolution, semantically-rich 3D geospatial data to the metaverse. 3D Tiles 1.1 promotes several 3D Tiles 1.0 extensions to ‘core’ and introduces new glTF™ extensions for fine-grained metadata storage.

The primary enhancements proposed for OGC 3D Tiles 1.1 include:

  • Semantic metadata at multiple granularities
  • Implicit tiling for improved analytics and random access to tiles
  • Multiple contents per tile to support layering and content groupings
  • Direct references to glTF™ content for better integration with the glTF™ ecosystem

3D Tiles 1.1 is backwards compatible with 3D Tiles 1.0 – aside from version number itself, valid 1.0 tilesets are also valid 1.1 tilesets.

3D Tiles 1.1 is expected to be finalized by Cesium in May, 2022 and subsequently submitted to OGC for consideration as a revision to the existing Community Standard. Reference implementers are committed to updating their implementations with the final release of the specification. 

3D Tiles was first announced at SIGGRAPH in 2015, and was published as an OGC community standard in 2019. Since then, the community has built apps, exporters, APIs, and engines with 3D Tiles to grow an open and interoperable 3D geospatial ecosystem. This collective experience building with 3D Tiles, combined with the continued growth of 3D geospatial data availability, especially semantic metadata, and increasing user interest in digital twins and the metaverse, has led to this revision of the 3D Tiles specification.

A Community Standard is an official standard of OGC that is developed and maintained external to the OGC. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership as a stable, widely implemented standard that becomes 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: Climate Resilience Domain Working Group (DWG)

Status: 
Please note:  This Request is scheduled to close on 11 May 2022.
Open Date: 
Wed, 04/20/2022
Closing Date: 
Wed, 05/11/2022
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on the draft charter of the proposed OGC Climate Resilience Domain Working Group (DWG). 

The OGC Climate Resilience DWG will provide an open forum for the discussion and presentation of interoperability requirements, use cases, pilots, and implementations of OGC Standards in the context of cross-sector climate actions. The goal of the DWG is to support the development of a reliable, interoperable foundation for science services that are used in climate change actions.

Producing and providing reliable climate information requires huge volumes of data to be assembled and processed from different scientific ecosystems – requiring standards and collaboration to support evidence-based decision making. Since the looming challenge of achieving climate resilience is global in nature, spatial aspects must therefore be addressed on a global scale. 

OGC’s mission of enabling FAIR (Findable, Accessible, Interoperable, Reusable) data plays a special role in designing Climate Resilience Information Systems, as the entire climate information ecosystem around data will only reach its full potential if participants adhere to the FAIR principles, not only for the data contained within the systems, but throughout the entire climate resilience information systems themselves. This requires agreements on metadata aspects for discovery, application programming interfaces (APIs), and resource models for interaction with the climate resilience information system. 

With this requirement in mind, targeted activities of the Climate Resilience DWG will involve defining, collecting, analyzing, and communicating data streams, and building value from raw data through to effective information visualization and interpretation. 

The OGC Climate Resilience DWG charter defines the DWG’s scope as supporting any action that accelerates our collective readiness to access, fuse, and analyze data from the climate change modeling community with earth observation or any other type of data relevant to climate action (such as social science data) in order to contribute to the global push for achieving climate resilience. 

The OGC Climate Resilience DWG should work in line with the United Nations climate policy frames.

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 - Routes - Part 1: Core Standard and OGC Route Exchange Model Standard

Status: 
Please note:  This Request is scheduled to close on 9 May 2022.
Open Date: 
Thu, 04/07/2022
Closing Date: 
Mon, 05/09/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the candidate OGC API - Routes - Part 1: Core Standard and related candidate OGC Route Exchange Model Standard. The candidate OGC API - Routes Standard specifies the fundamental API building blocks for interacting with on-road route resources, and uses the Route Exchange Model to represent routes. 

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 candidate OGC API - Routes - Part 1: Core Standard enables 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.

The candidate OGC API - Routes - Part 1: Core Standard provides 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. Implementations of this candidate API standard leverage the OpenAPI specification for describing the resources and capabilities they offer. Complementing the API standard, the candidate Route Exchange Model standard provides a standardized method to share routes, regardless of the underlying proprietary data, routing engine software, or algorithms.

  • For providers of routes, the API building blocks and the Route Exchange Model provide a simple model to publish and offer those routes as resources for use by other systems.
  • For developers building infrastructures, the API building blocks provide an abstraction layer to leverage existing routing engines and algorithms using modern APIs - saving development and deployment time and costs.
  • For users, applications, and enterprises, the capability to get routes across a common API, regardless of the underlying routing data, engines, or algorithms, represents a significant step forward in geospatial interoperability.

OGC recognizes that in addition to on-road routing there are many environments for implementing open routing, including off-road, air, sea, Smart Cities, and many others, which may be addressed as future work. In addition, some communities may require specialized parameters in their Routing API. Accordingly, any on-road routing API will accept two waypoints: the start and end position. APIs are, however, free to support additional waypoints between the start and end positions, and be extensible to support parameters required by diverse implementation communities. This too could be addressed as future work or extensions.

Comment: 

Comments on the standard can be submitted via the OGC Routing SWG GitHub Repository.

Subscribe: 

Comments and development can be tracked via the OGC Routing SWG GitHub Repository.

OGC Requests: 

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

Status: 
Please note:  This Request is scheduled to close on 29 April, 2022.
Open Date: 
Wed, 03/30/2022
Closing Date: 
Fri, 04/29/2022
Description: 

OGC API - Tiles uses the latest technologies and spatial data on the web best practices to enable Web APIs to serve tiles of spatially referenced data or of maps. The candidate standard offers additional functionality beyond that offered by the Web Map Tile Service (WMTS) - a well-established and commonly implemented OGC standard first issued in 2007.

OGC API Standards are developed in a modular way, meaning that their functionality can be added to existing web APIs as desired. This is why we call the family of OGC API Standards the ‘Building Blocks For Location.’

The candidate OGC API - Tiles specification, therefore, describes the API building blocks that can enable existing OGC API implementations (as well as other Web APIs) to efficiently serve tiles of spatially referenced data or of maps with predefined content, extent, and resolution. 

As with other OGC API Standards, OGC API - Tiles is delivered in ‘Parts’ that allow developers to pick and choose the functionality they want in the API they are building. This minimizes complexity and development time, and allows future use-cases and technology changes to be added to the Standard as new parts without breaking existing implementations. Part 1: Core provides the minimum functionality required for a Web API to successfully serve spatially-referenced tiles to a client for the most common use-cases.

The candidate OGC API - Tiles - Part 1: Core Standard defines how to: discover which resources offered by a Web API can be retrieved as tiles; get metadata about the available tile sets; and request a tile. Tiles can represent a single collection or multiple collections, as defined in the Web API.

Additionally, the core conformance class describes how to retrieve a tile of an arbitrary resource using tile indices. It is defined in a way that could be easily included in a web API that does not conform to the foundational OGC API - Common standard. A web API can combine some requirements classes of this candidate OGC API standard with other OGC API standards (including OGC API - Common) to add functionality to said web API.

The candidate OGC API - Tiles Standard leverages the concepts of tile matrix sets and tile sets  defined in the candidate OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard, also implicitly used in WMTS and GeoPackage. The candidate OGC API - Tiles Standard can, therefore, be used to publish tiled maps (e.g., PNG, JPEG), tiled feature data (e.g., GeoJSON Vector Tiles, Mapbox Vector Tiles), or tiled coverages (e.g., netCDF, GeoTIFF).

Comment: 

Comments on the standard can be submitted via the OGC API - Tiles GitHub Repository.

Subscribe: 

Comments and development can be tracked via the OGC API - Tiles GitHub Repository.

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.

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

 

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

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: 

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: 

Pages