OGC Requests

Public comment requested: CityJSON Community Standard

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

The Open Geospatial Consortium (OGC) seeks public comment on its adoption of CityJSON as an OGC Community Standard.

CityJSON is a JSON-based encoding for a subset of the OGC CityGML data model (version 2.0.0). CityJSON defines ways to describe 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 different standard levels of detail (LoDs) for the 3D objects, which allows different resolutions of objects for different applications and purposes.

A CityJSON file describes both the geometry (an object’s form) and the semantics (an object’s function) of the features in a given area, such as the buildings, roads, rivers, vegetation, and city furniture.

The aim of CityJSON is to offer an alternative to the GML encoding of CityGML, which can be verbose and complex to read and manipulate. 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.

The differences between the CityJSON v1.0 implementation and the XML-based implementation are described in more detail on this webpage.

Please note that the CityGML 3.0 Conceptual Model specification is also currently open for public comments. CityGML 3.0 is a data model that has been re-structured to be independent of particular encodings; it may have a JSON encoding in the future. CityJSON 1.0 provides a directly implementable JSON encoding based on the CityGML 2.0 data model, an OGC standard since 2012. GML encodings and JSON encodings address different use cases – different communities looking to achieve different things, each useful in their own right. Hence, the OGC community sees value in offering both CityGML 3.0 and CityJSON 1.0.

CityJSON has been submitted to OGC for adoption as a Community Standard by the following organizations: Geonovum, Delft University of Technology, Kadaster International, virtualcitySYSTEMS, National University of Singapore, Forum Virium Helsinki Oy, and Ordnance Survey.

An OGC Community Standard is an official Standard of OGC that is considered to be a widely used, mature specification, but was developed outside of OGC’s standards development process. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership so that it can become part of the OGC Standards Baseline.

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

Public comment requested: Features and Geometries JSON SWG draft charter

Status: 
Please note:  This Request is scheduled to close on 11 January 2021.
Open Date: 
Mon, 12/21/2020
Closing Date: 
Mon, 01/11/2021
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on the draft charter for the new OGC Features and Geometries JSON Standards Working Group (SWG). 

The OGC Features and Geometries JSON SWG is chartered to develop a JSON encoding for geospatial feature data. This encoding is intended to build upon the foundational OGC standards (such as Simple Features), be inclusive of other geospatial JSON encodings (such as GeoJSON), and support content delivery per the OGC API family of standards. 

More specifically, OGC Features and Geometries JSON will build on the widely used GeoJSON standard and extend it with minimal extensions to support additional concepts that are important for the wider geospatial community and the OGC API standards.

JSON as an encoding format for geospatial data continues to grow in popularity thanks to its lightweight, simple syntax, and clear human (and machine) readability. GeoJSON has become a very popular encoding, but has limitations that prevent its use in some use cases. At a minimum, a more-inclusive JSON encoding for geospatial feature data should:

  • include the ability to use Coordinate Reference Systems (CRSs) other than WGS84,
  • support other non-Euclidean metrics, in particular ellipsoidal metrics,
  • support more geometry types, in particular solids, and
  • provide guidance on how to represent feature properties, including relation to time, consistent with the General Feature Model in JSON.

Given the popularity of GeoJSON, the SWG will ensure that OGC Features and Geometries JSON will be specified as a superset of GeoJSON so that valid GeoJSON is also valid OGC Features and Geometries JSON.

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: Abstract Specification: Geographic information - Observations and Measurements

Status: 
Please note:  This Request is scheduled to close on 18 January 2021.
Open Date: 
Thu, 12/17/2020
Closing Date: 
Mon, 01/18/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on a revision to the joint ISO and OGC Standard, Observations and Measurements (O&M). 

The O&M Standard defines a conceptual schema for observations, including for features involved in the observation process, and for features involved in sampling when making observations. These provide models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities.

O&M enables other Standards and specifications for capturing information originating from sensors as well as various environmental prediction models, using shared semantic concepts. Application areas can be as diverse as scientific devices capturing water and air quality measures, to cameras on drones, to tracking devices on commercial transport.

The O&M standard arose from work originally undertaken through OGC’s Sensor Web Enablement (SWE) activity. A set of interfaces and protocols was standardized, through which applications and services are able to access sensors of all types, and observations generated by them, over the Web. O&M now forms the foundation for a number of other OGC Standards, such as TimeseriesML and GroundwaterML.

A new generation of geospatial standards is now emerging, based on general Web standards, architecture, and current practice, as described in the W3C/OGC Spatial Data on the Web Best Practices and exemplified by the OGC API family of standards. This includes several new standards for describing and publishing sensors and observations, such as OGC SensorThings API and W3C/OGC Semantic Sensor Network Ontology. This new version of the O&M Standard is informed by these recent developments and is aimed at enabling the publication of observation data as part of the Web of Data, while also supporting other means of data exchange.

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: CityGML 3.0 Conceptual Model

Status: 
Please note:  This Request is scheduled to close on 28th January, 2021.
Open Date: 
Mon, 12/14/2020
Closing Date: 
Thu, 01/28/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on version 3.0 of the CityGML Conceptual Model, used for the storage and exchange of virtual 3D city models.

A key goal for the development of the CityGML Conceptual Model is to provide a common definition of the basic entities, attributes, and relations of a semantically rich 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields.

CityGML 3.0 creates a foundation of integrated 3D built environment data working towards digital twins and connected, smarter cities across multiple application areas. 

An increasing number of cities and companies are building virtual 3D city models for different purposes like urban planning, disaster management, 3D cadastre, energy modeling, environmental analysis & simulation, tourism, and more. 

The previous version, CityGML 2.0, has been widely adopted to create, maintain, and publish city models all around the world. CityGML 3.0 keeps key concepts of the previous version and makes the implementation of CityGML more versatile. 

Specifically, CityGML v3.0 now allows:

  • Data encodings other than GML
  • Updated LoD concept supporting a greater variety of indoor representations, covering simple floorplans as well as detailed 3D room details 
  • Easier integration with Building Information Models (BIM)
  • The integration of dynamic sensor feeds
  • Quicker implementation through a developer-friendly, modular specification
  • Faster extension by making user-specific additions to published UML model  

The CityGML Conceptual Model Standard defines a common information model for the representation of 3D urban objects that can be shared over different applications. The latter capability is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing governments and companies to reap the benefits of their investment in 3D city models by using the same models across different application fields and integrating data from separate sources. 

Application areas explicitly targeted by CityGML 3.0 include city planning, architectural design, tourist & leisure activities, environmental simulation, mobile telecommunication, disaster management, homeland security, real estate management, energy modelling, vehicle and pedestrian navigation, and training simulators.

CityGML is applicable for large areas and small regions, and can represent the terrain and 3D objects in different levels of detail simultaneously. Since anything from simple, single scale models to very complex multi-scale models can be represented, CityGML enables the consistent representation of 3D urban objects across different geographic information systems and users.

The CityGML 3.0 Conceptual Model is a Platform Independent Model (PIM). It defines concepts in a manner that is independent of any implementing technology. As such, it serves as the base for Platform Specific Models (PSM) where a CityGML model can be implemented with a specific technology or encoding. A complete GML encoding is available as an informative resource. The OGC CityGML Standards Working Group has started work to formalise a CityGML 3.0 Implementation Specification for GML and intends to publish this as a related standard in due course. The creation of further implementation specifications, particularly for databases and JSON as well as a harmonization with the OGC CityJSON Community Standard is highly encouraged and envisaged to be part of the future work programme. 

Future CityGML 3.0 Implementation Standards will be developed to define implementable source formats for 3D portrayal or transformation into dedicated portrayal formats such as the OGC I3S or the OGC 3D Tiles Community Standards, OGC KML, COLLADA or glTF. The OGC API - Features or OGC 3D Portrayal Service (3DPS) may be used for content delivery.

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

Status: 
Please note:  This Request is scheduled to close on 17 November 2020
Open Date: 
Wed, 10/28/2020
Closing Date: 
Tue, 11/17/2020
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on a revision of the Geopackage Standards Working Group (SWG) charter. 

The Geopackage Standards Working Group (SWG) provides a consensus forum for revisions to the GeoPackage Encoding Standard including approved extensions as well as the development of new GeoPackage extensions. The SWG adopted a new charter outlining plans for future development of the Standard.

GeoPackage was originally developed with three main goals in mind: 

  1. To be a convenient, efficient, and interoperable container for geospatial information; 
  2. To enable operations in all computing environments, including those with Disconnected, Degraded, Intermittent, or Limited (DDIL) network connectivity; 
  3. For GeoPackage to be extensible, allowing it to evolve to meet future operational needs.

For a good primer on Geopackage please read the post entitled #GeoPackageDay 2020 - what is GeoPackage? on the OGC Blog.

The revised charter outlines the new objectives for the SWG:

  • Develop a logical model for GeoPackage so that future implementations can be separated from the current requirement to use SQLite.
  • Revise existing GeoPackage standards and extensions, namely the GeoPackage Encoding Standard 1.3.0, the GeoPackage Tiled Gridded Coverage Extension, and the GeoPackage Related Tables Extension. In particular, the SWG will review all outstanding Change Request Proposals submitted before the adoption of this charter.
  • Develop new GeoPackage extensions that have been requested by OGC Domain Working Groups.
  • Perform outreach to promote GeoPackage understanding and use.

Revisions to the version 1.3.0 of the GeoPackage Encoding Standard will improve the interoperability, capability, and clarity of the Standard. The Tiled Gridded Coverage and Related Tables Extensions have not been revised since their initial release and will likely benefit from additional review. New extensions would enable new capabilities that have been requested by the OGC community.

The Geopackage SWG plans to perform these activities by the end of calendar year 2022.

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: Indoor Mapping Data Format (IMDF) Community Standard

Status: 
Please note:  This Request is scheduled to close on 18 November 2020
Open Date: 
Mon, 10/19/2020
Closing Date: 
Wed, 11/18/2020
Description: 

The Open Geospatial Consortium (OGC) is seeking public comment on the draft Indoor Mapping Data Format (IMDF) before seeking adoption as a Community Standard. This draft standard was originally developed and submitted to OGC by Apple. 

OGC Members Apple, Autodesk, Esri, Google, New York City Department of Information Technology and Telecommunications (DOITT), Ordnance Survey Limited, and Safe Software support the submission.

Apple developed IMDF to deliver indoor maps for venues all around the world, making it possible for users of the Apple Maps app to find their way indoors and discover attractions, services, shopping, and dining. IMDF provides a mobile-friendly, compact, human-readable, and highly extensible data model for any indoor space, providing a basis for orientation, navigation, and discovery.

Developers around the world have already created apps and services that offer indoor positioning with automatic floor level switching, seamless outside to indoor navigation, and location based experiences using IMDF tools developed by Apple. These tools include the online IMDF Sandbox, Indoor Survey app, and Apple MapKit and MapKit JS for cross platform rendering of IMDF.

Adoption of IMDF by OGC and the wider mapping community would make it possible to create apps and services using the same highly accurate and detailed map data on any app, website, or operating system. 

Examples include government agencies using an electronic standard of indoor maps data for efficient response to events, hospitals providing mapping guidance to patients, doctors, and visitors, and airports creating a single map that can be easily styled by partners without altering the accuracy of the underlying data.

An OGC Community Standard is an official standard of OGC that was already available as a widely used, mature specification, but was developed outside of OGC’s standards development and approval process. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership so that it can become part of the OGC Standards Baseline.

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

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

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

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

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

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

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

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

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

Public comment requested: OGC API - Environmental Data Retrieval

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

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

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

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

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

 

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

Public comment requested: Zarr Community Standard Work Item Justification

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

The Open Geospatial Consortium (OGC) is considering the Zarr v2 Storage Specification for adoption as an official OGC Community Standard. A new Work Item justification to begin the Community Standard endorsement process is available for public comment. 

Zarr is an open-source specification for the storage of multi-dimensional arrays of data (also known as N-dimensional arrays, ND-arrays, or tensors). Such arrays are ubiquitous in scientific research and engineering. 

Zarr stores metadata using .json text files and array data as (optionally) compressed binary chunks. Zarr can store data into most storage systems, including databases, standard ‘directory based’ file systems, and cloud object stores, such as Amazon S3. This flexibility allows implementations to experiment with novel storage technologies while maintaining a uniform API for downstream libraries and users.

Zarr arose in genomics research in 2016. It was created by Alistair Miles of Oxford as a library optimized for massively parallel array analytics. It has since grown into a community project with a range of developers and users from fields such as genomics, bioimaging, astronomy, physics, quantitative finance, oceanography, atmospheric science, climate science, and geospatial imaging. 

Because it can represent very large array datasets in a simple, scalable way, and is compatible with cloud object storage, Zarr is an ideal format for analysis-ready geospatial data in the cloud. Indeed, Zarr has already been adopted by several OGC communities as a format for cloud-optimized, analysis-ready geospatial data. Examples include:

While Zarr is not inherently a geospatial-specific format, it has been put forward by the Zarr Steering Council for adoption as an OGC community standard because of its rapid growth and adoption in geospatial and related fields.

An approved OGC Community Standard is an official standard of OGC that is considered to be a widely used, mature specification, but was developed outside of OGC’s standards development and approval process. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership so that it can become part of the OGC Standards Baseline.

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

Public comment requested: OGC Abstract Spec Topic 21 - Discrete Global Grid Systems

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

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

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

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

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

  • Separation of the DGGS standard into common modules and an extension for Equal Area Earth DGGS;
  • Remodelling to incorporate new versions of ISO 19107, ISO 19111 & ISO 19112, and tighter integration with ISO 19115-1
  • Extending the common module to support up to three spatial dimensions and up to one temporal dimension;
  • Additional modelling of temporal geometry and temporal reference systems sufficient for spatio-temporal DGGS, introducing the concept of a zone as a region of space-time equivalent to a location or an era; 
  • Remodelling algebraic functions as spatio-temporal extension of ISO 19107 Query;
  • Explicit handling of Dynamic vs Static datums for Equal Area Earth DGGS.
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

You may wish to be added to the distribution list to receive comments as they are submitted


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

Pages