OGC Requests

Public comment requested: Analysis Ready Data Standards Working Group Charter

Status: 
Please note:  This Request is scheduled to close on 21 December 2022
Open Date: 
Wed, 11/30/2022
Closing Date: 
Wed, 12/21/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft charter for a new Analysis Ready Data Standard Working Group (ARD SWG).  Born from work undertaken in the OGC Disaster Pilot 2021 and Testbed-16, the Analysis Ready Data (ARD) SWG will develop a multi-part Standard for geospatial Analysis Ready Data in partnership with ISO/TC 211.

The concept of ARD was initially developed by the Committee on Earth Observation Satellite (CEOS). CEOS defines ARD as “satellite data that have been processed to a minimum set of requirements and organized into a form that allows immediate analysis with a minimum of additional user effort and interoperability both through time and with other datasets.” Adopting the CEOS-ARD definition as a starting point, the OGC ARD SWG will extend the scope of ARD from satellite data to all geospatial data. 

A major strength of geospatial and location technologies is their ability to integrate and analyze data from diverse providers concerning many different phenomena so as to better understand or predict what is happening in a given area. However, this diversity of data means that preparing the acquired data for integration and analysis remains a time-consuming task. Furthermore, many geospatial data users lack the expertise, infrastructure, and internet bandwidth to efficiently and effectively access, preprocess, and utilize the growing volume of geospatial data available for local, regional, and national decision-making. 

The charter supporters recognize that formal Standardization of the concepts developed through CEOS-ARD is necessary to achieve broad uptake, particularly by the commercial sector. Defining ARD through international standard bodies, such as OGC and ISO, will also help promote the concept and help avoid the divergence that can be caused by various groups working towards different interpretations of the concept.

As such, the OGC ARD SWG will work jointly with the ISO/TC 211 ARD Standard project team to define a multi-part Standard that specifies a set of minimum requirements that a geospatial data product shall meet in order for the product to qualify as an ARD product.

The CEOS ARD concept and specifications were initially tested, evaluated, and assessed by OGC during Testbed-16, results of which were published in the ARD Engineering Report in 2020. Building on this, space agencies participating in the OGC Disaster Pilot 2021, introduced a number of CEOS-ARD products into the disaster decision-making process, greatly simplifying the use of satellite data in disaster-related decision making. 

The Disaster Pilot 2021 concluded with a need to broaden the ARD concepts to cover other types of geospatial data and to create international ARD standards through the formal standard setting processes of ISO and OGC. Therefore, the OGC Disaster Pilot 2022 set an action item to start an OGC ARD Standards Working Group to work jointly with the project team in ISO TC 211 to develop joint ISO-OGC standards on geospatial ARD.

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: Retirement of OGC Moving Features Encoding Extension - JSON Best Practice

Status: 
Please note:  This Request is scheduled to close on 2 January 2023
Open Date: 
Wed, 11/02/2022
Closing Date: 
Mon, 01/02/2023
Description: 

The Open Geospatial Consortium (OGC) Moving Features Standards Working Group (SWG) has recommended that the OGC Best Practice OGC Moving Features Encoding Extension - JSON (16-140r1) document be retired. The document has been superseded by the OGC Moving Features Encoding Extension - JSON Standard (19-045r3). 

The OGC Moving Features SWG has been actively developing Standards and practices for representing the movement of geographically-tied features. These Standards have built upon the ISO 19141:2008 - Schema for moving features Standard to provide practical implementation guidance for managing moving feature data.

The initial Moving Features encoding was standardized in XML. Further work resulted in a Standardized encoding in comma-separated values (CSV). In keeping with sound methodology, the community developing these Standards worked with real and proven implementations before finalizing the Standards. As such, the SWG published a Best Practice document detailing how moving feature data can be encoded in JSON. This Best Practice formed the basis for further work to standardize a JSON encoding: the OGC Moving Features Encoding Extension - JSON Standard.

Now that the JSON encoding is realized as a formal Standard, OGC wishes to retire the out-of-date Best Practice document to ensure that the community is encoding this JSON information in a consistent fashion.

OGC requests that anyone implementing the JSON encoding for moving feature data confirm that they are using the Standard and provide any comments that support or raise concern with retirement of the Best Practice encoding.

Downloads: 

Best Practice Document to be retired: OGC Moving Features Encoding Extension - JSON (16-140r1) (.HTML)

Superceding Implementation Standard: OGC Moving Features Encoding Extension - JSON Standard (19-045r3) (.HTML)

Comment: 

Comments can be submitted to a dedicated email reflector for a sixty 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 City Geography Markup Language (CityGML) Part 2: GML Encoding Standard

Status: 
Please note:  This Request is scheduled to close on 11 November 2022.
Open Date: 
Wed, 09/28/2022
Closing Date: 
Fri, 11/11/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the OGC City Geography Markup Language (CityGML) Part 2: GML Encoding Standard. 

The CityGML 3.0 GML Encoding Standard presents the GML encoding of the concepts defined by the CityGML 3.0 Part 1: Conceptual Model (CM) Standard, which was approved as an OGC Standard in 2021. The GML encoding is compliant to GML versions 3.2 and 3.3, which is defined by ISO 19136. This encoding can be used to store and exchange 3D city models in the GML format as data sets or via web services.

Since its first publication by OGC in 2008, CityGML has been an open standard used for the storage and exchange of virtual 3D city models. CityGML allows the integration of urban geodata for use across a variety of applications, including urban and landscape planning; Urban Digital Twins for Smart Cities; the Metaverse; Building Information Modeling (BIM); mobile telecommunication; disaster management; 3D cadastre; tourism; vehicle & pedestrian navigation; autonomous driving and driving assistance; facility management; and energy, traffic, and environmental simulations.

CityGML defines a “City” in a broad fashion to comprise not just built structures, but also elevation, vegetation, water bodies, city furniture, and more. Despite its name, CityGML is useful for large areas and small regions, not just cities, and can represent the terrain and 3D objects in different Levels Of Detail simultaneously. CityGML enables the consistent representation of 3D urban objects across different Geographic Information Systems and users.

CityGML 3.0 is an evolution of the previous versions 1.0 and 2.0 of CityGML that further enables the cost-effective sustainable maintenance of 3D city models. While previous versions standardized a GML exchange format, CityGML 3.0 standardizes the underlying information model and can thus be implemented in a variety of technologies beyond GML. As a result, governments and companies can increase the Return On Investment (ROI) of their 3D city models by being able to put the same models into play across different technology platforms and application fields. 

Additional benefits of CityGML 3.0 compared to previous versions include much better integration with BIM, the ability to represent indoor spaces in different Levels of Detail (LOD), support for dynamic sensor data, and the capability to extend the information model into Application Domain Extensions using Model Driven Architecture tools.

This Part 2 of the Standard defines how the concepts developed in Part 1 are realized using XML and GML technologies. The CityGML 3.0 GML encoding represents a full mapping of the Conceptual Model and is derived fully automatically from the UML model following the UML-to-GML encoding rules as defined by ISO 19136.

A collection of example data sets for the CityGML 3.0 GML Encoding is available from the OGC CityGML-3.0 Encodings Public GitHub Repository.

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

Status: 
Please note:  This Request is scheduled to close on 23 September 2022
Open Date: 
Wed, 08/24/2022
Closing Date: 
Fri, 09/23/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on version 1.1 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. 

Previously referred to as “3D Tiles Next,” Version 1.1 of the 3D Tiles Community Standard 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 candidate OGC Community Standard is identical to the Cesium release of version 1.1 of the 3D Tiles specification.

The primary enhancements in the candidate 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.
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 Indexed 3d Scene Layer (I3S) and Scene Layer Package Format Community Standard Version 1.3

Status: 
Please note:  This Request is scheduled to close on 18 September, 2022
Open Date: 
Fri, 08/19/2022
Closing Date: 
Sun, 09/18/2022
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on version 1.3 of the OGC Indexed 3d Scene Layer (I3S) and Scene Layer Package Format Community Standard. Version 1.3 adds support for Building Scene Layers. Building Scene Layers are derived from Building Information Models (BIM) and/or other 3D building data. 

I3S is designed to enable the streaming and storage of arbitrarily large amounts of 3D geographic data. An I3S dataset, referred to as a Scene Layer, can consist of millions of discrete 3D objects with attributes, integrated surface meshes, symbolized points, or point cloud data covering small to extensive geographic areas. Designed for performance and scalability, a scene layer enables the efficient encoding and transmission of 3D geospatial content for an interactive visualization experience on web browsers, mobile, and desktop apps for both offline and online access. 

I3S is web and cloud friendly and is rooted in modern standards and technological advancements in the areas of 3D graphics, data structuring, and mesh and texture compression.

Version 1.3 of the OGC I3S Community Standard adds support for Building Scene Layers (BSL). A Building Scene Layer is a 3D representation of a building model. A building model may be derived from 3D construction content, such as BIM data, or from a relational database model that contains 3D spatial information. The I3S BSL capability is designed to model the organization of construction data by grouping content into standard engineering disciplines. Content in a BSL may represent a partial building, an individual building, or multiple buildings on a campus.

An I3S Building Scene Layer also encapsulates the semantic structure of the information in the building model while capturing geometry and attributes that can be used in an application. A BSL captures standard Architectural Engineering and Construction (AEC) disciplines such as Mechanical, Architectural, Piping, Electrical, and Structural. Within each discipline, a BSL groups category layers containing 3D objects representing assets of the building such as doors, windows, pipes and walls. The assets can contain attributes that directly reflect standard and user defined metadata that are stored in the source BIM content or other 3D data source.

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: Cloud Optimized GeoTIFF (COG) Standard

Status: 
Please note:  This Request is scheduled to close on 17 Septebmer 2022
Open Date: 
Thu, 08/18/2022
Closing Date: 
Sat, 09/17/2022
Description: 

The Open Geospatial Consortium (OGC) is seeking public comment on the Cloud Optimized GeoTIFF (COG) Candidate Standard, which aims to formalize, as an OGC Standard, existing practices already implemented by the community, such as the GDAL library or the COG explorer and other implementations

COG allows for efficient streaming and partial downloading of imagery and grid coverage data on the web and enables fast data visualization and geospatial processing workflows. COG-aware applications can efficiently stream/download only the parts of the information they need to visualize or process web-based data. With so much remote sensing imagery available in cloud storage facilities, the benefits of optimizing their visualization and processing will be widespread. COG is one of the preferred formats used in STAC catalogs, and sits alongside other emerging cloud-optimized formats of relevance to OGC, such as Zarr, COPC, and GeoParquet.

The candidate COG Standard specifies how TIFF files can be organized in a way that favors the extraction of convenient parts of the data at the needed resolution while remaining compatible with tradicional TIFF readers. It also specifies how to use HTTP (or HTTPS) to communicate only the part of information needed without downloading the complete file.

This candidate Standard depends on the TIFF specification and the OGC GeoTIFF Standard. For large files, it depends on the BigTIFF specification. The standard takes advantage of some existing characteristics of the TIFF specification and the existing HTTP Range Request specification (IETF RFC 7233) and does not modify them in any way.

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, or by submitting an issue to the OGC COG GitHub public repository. Comments received will be consolidated and reviewed by OGC members for incorporation into the document.

Please submit email 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: Subscribe to Distribution List.
Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

Or follow along on the the OGC COG GitHub public repository.

OGC Requests: 

Public comment requested: SensorThings API SWG recharter

Status: 
Please note:  This Request is scheduled to close on 2 September 2022
Open Date: 
Fri, 08/12/2022
Closing Date: 
Fri, 09/02/2022
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on the draft updated charter for the OGC SensorThings API Standards Working Group (SWG). The update adds a new task for the SWG – to create a new SensorThings API - Plus Extension (STAplus) based on the upcoming 21-068 OGC Best Practice for using Sensor Things API with Citizen Science.

The motivation for the Citizen-Science-focused STAplus extension was born during the EC H2020 project, Cos4Cloud. Whereas the dominant use of the OGC SensorThings data model (and API) can be coined with the use-case “single authority provides sensor readings to consumers,” in Citizen Science there are many contributors (the citizens) that together create the “big picture” with their observations.

The introduced STAplus extension supports a model where the observations are owned by (different) users that may each express the license for re-use; this part of the contribution is called the “ownership concept.” In addition to the ownership and license abilities, the introduced extension allows the expression of explicit relations between observations and the creation of group(s) of observations to containerize observations that belong together. Relations can be created among any individual observations or observations of a group to support performant Linked Data extraction and semantic queries, e.g. expressed in SPARQL.

The SensorThings API SWG believes that the introduced extension is an important contribution to the realization of the FAIR principles perhaps not only in Citizen Science as STAplus strengthens the “I” (Interoperability) through a common data model and API as well as the “R” (Re-usability) by enabling standards-based queries that can consider licensing conditions relevant for the reuse of other users’ observations. The STAplus Data Model and Business Logic also enriches existing deployments as the extension can be seamlessly added and thereby offer new capabilities to create and manage the “big picture” with multi-user capabilities.

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: CoverageJSON Community Standard

Status: 
Please note:  This Request is scheduled to close on 10 September 2022
Open Date: 
Thu, 08/11/2022
Closing Date: 
Sat, 09/10/2022
Description: 

 

The Open Geospatial Consortium (OGC) is seeking public comment on the candidate CoverageJSON Community Standard. CoverageJSON is a format for publishing multi-dimensional data to the Web. 

The primary design goals for CoverageJSON are simplicity, machine and human readability, and efficiency in the storage and use of complex data. While other use cases are possible, the primary CoverageJSON use case is enabling the development of interactive visualizations to display and manipulate spatio-temporal data within a web browser.

CoverageJSON is based on the popular JavaScript Object Notation (JSON), and provides an effective, efficient format that’s friendly to web and application developers, and therefore consistent with the current OGC API developments. CoverageJSON supports the efficient transfer from big data stores of usable quantities of data to lightweight clients, such as browsers and mobile applications. This enables straightforward local manipulation of the data by users such as science researchers. 

The simplest and most common use-case is to embed all the data values of all variables in a Coverage object within the CoverageJSON document to create a self-contained, standalone, document that supports the use of very simple clients.

Another simple use case is to put data values for each variable (parameter) in separate array objects in separate CoverageJSON documents which are linked from a parent CoverageJSON object. This is useful for a multi-variable dataset, such as one with temperature, humidity, wind speed, etc., to be recorded in separate files. This allows the client to load only the variables of interest.

A sophisticated use case is to use tiling objects, where the data values are partitioned spatially and temporally, so that a single variable’s data values would be split among several documents. A simple example of this use case is encoding each time step of a dataset into a separate file, but the tiles could also be divided spatially, like a tiled map server implementation.

This OGC Community Standard was an outcome of a European Union project, “Maximizing the Exploitation of Linked Open Data in Enterprise and Science” (MELODIES), run from 2013 to 2016, and released under a Creative Commons 4.0 License by the University of Reading. There are several widely-used open source implementations and libraries available.

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: adoption of CityJSON v1.1 as Community Standard

Status: 
Please note:  This Request is scheduled to close on 9 September 2022.
Open Date: 
Wed, 08/10/2022
Closing Date: 
Fri, 09/09/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on an updated version (v1.1) of the CityJSON Community Standard. The proposed update contains significant improvements over v1.0, including support for the OGC CityGML data model version 3.0 and support for handling large CityJSON files through streaming. 

CityJSON defines ways to describe, in a JSON encoding, most of the common 3D features and objects found in cities (such as buildings, roads, rivers, bridges, vegetation, and city furniture) and the relationships between them. It also defines how to encode different standard levels of detail (LoDs) for the 3D objects in JSON, which allows users to represent different resolutions of objects for different applications and purposes. A list of applications and use-cases for CityJSON is available on the CityJSON website.

The aim of CityJSON is to offer an alternative to the GML encoding of CityGML, which can be verbose and therefore complex to work with. CityJSON aims at being easy-to-use, both for reading datasets, and for creating them. It was designed with programmers in mind, so that tools and APIs supporting it can be quickly built. It was also designed to be compact, typically compressing publicly available CityGML files by 6x.

A CityJSON file describes both the geometry and the semantics of the city features of a given area. A CityJSON object, representing a city, is as ‘flat’ as possible, i.e., the hierarchy of CityGML has been flattened out and only the city objects which are ‘leaves’ of this hierarchy are implemented. This considerably simplifies the storage of a city model, and furthermore does not mean that information is lost.

CityJSON v1.0 was accepted as an OGC Community standard in August 2021. CityJSON version 1.0 is a JSON-based encoding for a subset of the OGC CityGML data model version 2.0.0.

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: Deprecation of v1.0 of the Geographic Information - Well Known Text Representation of Coordinate Reference Systems Standard

Status: 
Please note:  This Request is scheduled to close on 5 September 2022.
Open Date: 
Thu, 07/07/2022
Closing Date: 
Sat, 08/06/2022
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the Deprecation of v1.0 of the Geographic Information - Well Known Text Representation of Coordinate Reference Systems Standard.

There have been two generations of Well-known text (WKT) representing Coordinate Reference System (CRS) definitions:

  • The first generation was documented over 20 years ago by a number of organizations, including OGC through the Simple Features and Coordinate Transformation Service specifications. Numerous flavors of this generation exist, which are referred to colloquially as “CRS WKT1.”
  • The “CRS WKT2” specification that’s conformant with Abstract Specification Topic 2, Referencing by coordinates. There have been two versions of this WKT2 standard:
    • OGC document 12-063, "Well Known Text Representation of Coordinate Reference Systems" (WKT CRS) version 1.0, which is conformant with Topic 2 (OGC document 08-015) and ISO 19111:2007. It was published in 2015 and submitted to ISO TC / 211 for publication in the same year (ISO 19162:2015).
    • OGC document 18-010, "Well Known Text Representation of Coordinate Reference Systems" (WKT CRS) version 2.0, conformant with revised Topic 2 (OGC document 18-005) and ISO 19111:2019. The revision was primarily to add support for dynamic CRSs and other advances in geodesy. This revision of WKT2 was also submitted to ISO TC / 211 for publication (ISO 19162:2019).

Based on the limitations of CRS WKT1 and WKT2 v1.0, OGC issued Policy Directive 46 in September 2019 requiring all new OGC Standards that require CRS support to reference CRS WKT2 version 2.0 (18-010r7). The maintainers of the Standard, the CRS Standards Working Group (SWG) have assessed that the data and software environments in the geospatial community now rely upon CRSs that cannot be adequately defined using CRS WKT2 v1.0 and thus recommend that the Standard (12-063r5) be deprecated.

Per OGC policy, a deprecated Standard is no longer supported (no longer receives updates and OGC may not provide technical support on the Standard). The Standard is marked as deprecated, but still made available on the OGC website to assist developers in migrating to the new version.

OGC takes great diligence in notifying the community of a proposed deprecation and requests comments regarding this proposed action, including any evidence for why the Standard should not be deprecated.

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