OGC Requests

 Public comment requested: OGC Geo for Open Metaverse Domain Working Group Draft Charter

Status: 
Please note:  This Request is scheduled to close on 29 June 2022
Open Date: 
Wed, 06/08/2022
Closing Date: 
Wed, 06/29/2022
Description: 

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

The Metaverse is perhaps the ultimate distributed digital twin of the world. It has the potential to represent everything in the world alongside imagined spaces. The challenges to Standards Development Organizations (SDOs), technologists, artists, and society are huge, but the payoff is believed to be equally tremendous. The Metaverse is not a single thing but, like the internet, is a collection of platforms and technologies: a world of objects that can be navigated and interacted with.

Everything OGC does can be applied to the Metaverse. Our community can contribute expertise in 3D, Modeling & Simulation, Artificial Intelligence, streaming, Augmented and Virtual Realities, routing, mapping, and more – all at scale.

The OGC Metaverse DWG will work on pieces of the Metaverse that pertain to geospatial applications and Standards by developing Open Standards based on FAIR data principles (making data Findable, Accessible, Interoperable, and Reusable). Given that the Metaverse will be an evolutionary development, the working group will identify both near- and long-term goals that will help ensure interoperability, FAIRness, and openness. Much of the Metaverse is already happening, so collaboration will be key to its success and will be a grounding principle of this OGC Domain Working Group.

3D geospatially anchored data is powering a revolution across a range of industries. This same data – currently relied upon for construction of the real world – is now driving the creation of virtual/digital worlds that will form parts of the Metaverse.

For the Metaverse to succeed, however, all digital and physical world information will have to work in concert at scale. We have a collective responsibility to ensure that the shared future is FAIR and Open. OGC has always focused on interoperability and open Standards – both of which are key to ensuring an open Metaverse. Working together, we can have a positive impact on this future.

For a primer on the Metaverse and the role that OGC and the Geospatial Industry can play, see the blog post ‘The Metaverse is Geospatial’ on ogc.org.

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 Encoding Linked Data Graphs in netCDF Files Standard (netCDF-LD)

Status: 
Please note:  This Request is scheduled to close on 24 June 2022
Open Date: 
Wed, 05/25/2022
Closing Date: 
Fri, 06/24/2022
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on the candidate OGC Encoding Linked Data Graphs in netCDF Files Standard (netCDF-LD). NetCDF-LD is an approach for constructing Linked Data descriptions using the metadata and structures found in netCDF files. 

NetCDF is a format for encoding array-oriented scientific data, particularly in many Earth & Space Science domains. It is common practice to aid interoperability of netCDF files in the Earth sciences by using the Climate and Forecasting (CF) convention and also the Attribute Convention for Data Discovery (ACDD). Several communities are defining additional netCDF conventions for describing the semantics relating to their different domains. As the concurrent use of multiple – and possibly clashing or conflicting – netCDF conventions spreads, the problem of finding a common mechanism to validate and interpret metadata embedded inside netCDF files grows. The candidate netCDF-LD Standard offers a solution to that problem.

Linked Data (LD) is a World Wide Web Consortium best practice for encoding and publishing metadata to expose and connect data both within individual datasets and across multiple datasets. LD also allows dataset descriptions to become more useful by running semantically enabled queries across datasets. Linked Data uses the W3C Resource Description Framework (RDF) to express the information and relationships. Publishing netCDF file descriptions using LD methods presents the user community with an opportunity to benefit from LD’s improved exposure and connection and, in turn, make published data more Findable, Accessible, Interoperable, and Re-usable (FAIR).

The candidate netCDF-LD Standard provides a standard for encoding linked data semantics into netCDF files and interpreting netCDF files as RDF graphs with minimal or little changes to existing netCDF files. NetCDF files adopting the netCDF-LD standard and assembled into RDF graphs can be used with other Linked Data technologies for data fusion, powerful querying and data discovery. NetCDF-LD also enables the capture of enhanced netCDF metadata, enabling information found in netCDF files to be linked with published conventions and controlled vocabularies used to express the content, thus improving semantic interoperability and consistency.

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

Pages