OGC Requests

Public comment requested: OGC API - Processes Standards Working Group Charter

Status: 
Please note:  This Request is scheduled to close on 8 March 2021
Open Date: 
Mon, 02/15/2021
Closing Date: 
Mon, 03/08/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on a revision to the OGC API - Processes Standards Working Group (SWG) Charter, which introduces new work items for the SWG. 

The OGC API - Processes SWG is the group within the OGC membership responsible for the development and maintenance of the OGC API - Processes core standard and its extensions, as well as for maintaining the WPS standard.

OGC API - Processes provides organizations the opportunity to make available on the web geospatial software libraries and utilities that, up until now, had only been available as standalone desktop products. It forms a crucial part of OGC’s “user-to-the-data” architecture that allows users to not only mine intelligence from their cloud-based data through streamlined analysis, but also to create value-added products for others to use.

OGC API - Processes, like its predecessor (WPS), achieves this by providing a standardized mechanism for computational geospatial processes to be deployed and offered as services within Cloud Computing environments. 

With the initial development of the OGC API - Processes standard now complete, the OGC API - Processes SWG will begin to address extensions that will simplify the deployment and execution of geospatial processing packages and chained processing workflows.

Specifically, the SWG will begin work on the following extensions to Part 1 Core (final names TBA):

Part 2: Transactions for deployment
This extension will enable the dynamic deployment and execution of processes as application packages. An application package is a file that provides a description of a process(es) to be deployed, including the inputs and outputs of the process(es) as well as other ancillary metadata (e.g. reference to a containerized execution unit) necessary for the process to be deployed. An application package can take many forms (e.g. Jupyter notebook, workflow execution document, etc.) and so this extension will not mandate any specific form but will instead include one or more optional conformance classes for application package formats that have been developed via OGC Innovation Program Initiatives (e.g. CWL, MOAW, OGC Application Package, etc.). 

Part 3: Workflows and Chaining
This extension will provide the ability to:

  • chain nested processes,
  • refer to external processes and collections accessible via OGC API standards, and
  • trigger execution of processes through OGC API data delivery specifications (such as OGC API - Features, Tiles, Maps and Coverages).

The SWG will look at different solutions for workflows and chaining to ensure validation of the defined architecture across multiple approaches.

OGC Members interested in staying up-to-date on the progress of this standard, or contributing to its development, are encouraged to join the SWG via this link on the OGC Portal.

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 Coverage Implementation Schema (CIS) - ReferenceableGridCoverage Extension v1.1

Status: 
Please note:  This Request is scheduled to close on 3 March 2021.
Open Date: 
Mon, 02/01/2021
Closing Date: 
Wed, 03/03/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on version 1.1 of the OGC Coverage Implementation Schema (CIS) - ReferenceableGridCoverage Extension. Comments are due by March 3, 2021.

The CIS ReferenceableGridCoverage Extension extends CIS (a supporting standard of the Web Coverage Service Standard) to provide a set of referenceable grid elements to enable an accurate determination of pixel locations in observed imagery. The Extension accomplishes this, in part, by allowing connections to OGC SensorML 2.0+ sensor models from OGC CIS 1.0+ coverages.

Version 1.1 of this standard permits use of the more concise array encoding of sensor model parameters in SensorML 2.1 documents via the new element setEncodedValues, enabling more compact sensor model descriptions.

A referenceable grid enables the location of all points in a simple grid (such as a set of pixels in an image) to be determined in a Coordinate Reference System (CRS), by providing a means to specify additional geometrical information such as a sensor model. A sensor model may describe, for example, the collection of light rays by an Earth Observation (EO) imagery sensor consisting of a rectangular array of light sensing pixels. 

The extension enables OGC imagery standards based on CIS 1.0+ (such as GMLJP2 2.1) to be able to contain sensor models described with OGC SensorML 2.0+. SensorML 2.0+ can be used to describe and share a wide range of sensor models, for example imaging systems located on satellite and airborne platforms. A simple example of such a description would be the location of a camera, the direction in which it is pointing, as well as details of the camera’s imaging system, such as the number of pixels, the principal point offset, the focal length, and the optical distortion parameters. This data is thus available for mapping every imaged pixel to a location in an external CRS.

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: GeoTIFF Standard Working Group charter update

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

The Open Geospatial Consortium (OGC) seeks public comment on the draft updated charter for the GeoTIFF Standard Working Group (SWG), which introduces several new tasks for the SWG. 

The Geographic Tagged Image File Format (GeoTIFF) specification, as an extension to the public domain TIFF format, has been used for sharing geographic image data successfully for years across many platforms and software environments. GeoTIFF defines a set of TIFF tags that describe the "cartographic" information associated with TIFF imagery originating from satellite imaging systems, scanned aerial photography, scanned maps, digital elevation models, or as a result of geographic analyses. 

The initial scope of the GeoTIFF SWG was to incorporate the GeoTIFF specification into the OGC standards suite by updating the specification to bring it into conformance with current OGC practices. The resulting Standard, GeoTIFF v1.1 was adopted as an OGC Standard in 2019. The original scope of the GeoTIFF also specified that the SWG would: provide a forum for evolving the standard in the future; maintain compatibility with existing geoTIFF community implementations and practices; and that future evolution would be done in close cooperation with the existing geoTIFF community.

As a result of that cooperation, the GeoTIFF SWG has updated its charter to include the following additional tasks to support the evolution of this popular standard:

  • GeoTIFF 1.2 - This task will address open issues which were out of scope for version 1.1 but not significant enough for a major revision. GeoTIFF 1.2 shall maintain backward compatibility with GeoTIFF 1.1.
  • BigTiff support - The TIFF file format uses 32 bit offsets. This limits TIFF files to four gigabytes. The BigTIFF format resembles TIFF but uses 64 bit offsets instead. GeoTIFF 1.1 will be extended to enable bigTIFF (in addition to TIFF).
  • Standardize Cloud-Optimized GeoTIFF (COG) - The COG community would like to turn-over management of the COG specification to OGC. OGC shall establish a GeoTIFF/TIFF standard or best practice that fully documents the COG format in the manner of an OGC specification.
  • GeoTIFF / LAS harmonization - This task will examine the overlap between GeoTIFF and LAS. The deliverable will be recommendations on how to keep these two standards synchronized.
  • Data Cubes - This task will explore the potential of GeoTIFF to support analytics including coverages and data cubes.
  • GeoTIFF 2.0 - This task will examine issues which cannot be addressed within the scope of a minor update (GeoTIFF 1.2).

 

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: Features API SWG recharter

Status: 
Please note:  This Request is scheduled to close on 5 February 2021.
Open Date: 
Fri, 01/15/2021
Closing Date: 
Mon, 02/15/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the proposed updated charter for the Features API Standards Working Group (SWG). 

The purpose of the Features API SWG is to: develop new and maintain existing parts of the OGC API - Features multipart standard; develop corrigenda for the related WFS 2.0 and FES 2.0 standards; and review draft Engineering Reports from the OGC Innovation Program related to OGC API - Features.

The recharter adds the following new work items to the SWG:

  • Property selection - the ability to specify which feature properties should be presented in a response document.
  • Geometry simplification - the ability to specify a resolution so that geometries are appropriately simplified (e.g., if you are zoomed out quite far, a polygon may be sufficiently represented as a point).
  • Schema - will specify resources for various schemas related to a feature. For example: presentation schema - the properties that can appear in a response document; query schema - the properties that can be used to formulate query expressions, or; mutation schema - the schema of the feature that can be used to insert/update/delete features.
  • Queries - specify new resources to handle long query expressions, multi-collection queries, and stored queries (with and without parameters).

OGC API - Features is a multi-part standard that offers the capability to create, modify, and query spatial data ‘features’ on the Web (features are simply the digital representations of objects of interest in the real world) and specifies requirements and recommendations for APIs that want to follow a standard way of sharing feature data. 

The new family of OGC APIs are a new set of building blocks for location. The OGC APIs usher in a new age for discovering and accessing location information on the web by enabling a much simpler way to share and access location information that is consistent with the architecture of the Web. The OGC API family of standards defines modular API building blocks to spatially enable Web APIs in a consistent way. Through the OGC APIs, the OGC community is standardizing how location information can be integrated: by any developer, with any other type of information, and into any type of application.

The new OGC APIs make use of the OpenAPI Specification (OAS) – a broadly adopted industry standard for describing modern APIs. APIs that implement OAS provide an interface that enables humans and computers to easily discover and understand the capabilities of a service without having to refer to external documentation or guesswork, greatly improving the accessibility of location data.

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: proposal for revision to Indexed 3D Scene Layers (I3S) Community Standard

Status: 
Please note:  This Request is scheduled to close on 15 February 2021.
Open Date: 
Thu, 01/14/2021
Closing Date: 
Mon, 02/15/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the proposal for a revision to the OGC Indexed 3D Scene Layers (I3S) Community Standard. The proposed revision is defined in the I3S Version 1.2 Community Standard Work Item Justification document. 

I3S enables 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 billions of point cloud data covering vast geographic areas. Designed for performance and scalability, a scene layer enables the efficient encoding and transmission of various types of geospatial content for an interactive visualization experience on web browsers, mobile, and desktop apps for both offline and online access. A Scene Layer can be accessed in the form of a web service or Scene Layer Package (SLPK) – a file-based exchange format.

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. I3S is accessible for efficient client-side filtering. I3S empowers city and local governments, content providers, and GIS professionals to share scene layers consisting of terabytes of nation-wide point cloud coverage, city and site scale 3D mesh data collected at frequent intervals, 3D planning scenarios fusing both ‘as built’ and modeled information, and more. The increased accessibility and ease of consumption of geospatial content by both domain experts as well as casual users is being rapidly accelerated by standards such as I3S.

The proposed revisions for I3S version 1.2 include:

  • Introduction of paged node access pattern – which significantly reduces the client-server traffic by bundling individual node metadata resources into compact pages of nodes.
  • Introduction of a more compact geometry layout for 3D Object and Integrated Mesh layers binary geometry payloads – using a well-known quantization encoding (Draco).
  • Introduction of an advanced material definitions property such as physically based materials.
  • More optimal selection strategy – standardizes on Oriented Bounding Boxes (OBBs) based node selection criterion.
  • Editorial updates/corrections.

These new enhancements are based on the Esri I3S version 1.7 product release.  OGC I3S v1.2 is backwards compatible with OGC I3S v1.1.

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

Status: 
Please note:  This Request is scheduled to close on 2 February 2021
Open Date: 
Tue, 01/12/2021
Closing Date: 
Tue, 02/02/2021
Description: 

The Open Geospatial Consortium (OGC) seeks public comment on the draft updated charter for the CDB Standards Working Group (SWG). The purpose of the CDB SWG is to maintain and improve the OGC CDB Standard and Best Practices documents. Comments are due by the 2nd of February, 2021.

The CDB standard defines an open format for the storage, access, and modification of a synthetic environment database. A synthetic environment is a computer simulation that represents activities at a high level of realism for use in a diverse array of applications, from simulation of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by realistic special effects and accurate behavioral models. Synthetic Environments allow visualization of, and immersion into, the environment being simulated. 

The CDB standard defines the organization and storage structure of a worldwide synthetic representation of Earth, as well as the conventions necessary to support all of the subsystems of a full-mission simulator. CDB makes use of several commercial and simulation data formats endorsed by leaders of the database tools industry.

The modeling & simulation end-user community increasingly requires “plug and play” synthetic environment database re-use and a common synthetic environment local representation to enhance realism and “fair fight” concepts in military simulation. The cost benefit of re-using complex curated synthetic environments is one major objective. In military simulation communities, heterogeneous simulations within Live (using real-world vehicles), Virtual (simulations with human-in-the-loop vehicle controllers), Constructive (simulations within which entity dynamics are computer controlled), and Gaming (LVC-G) are being composed on demand; such federations are severely limited by the current common practice using local proprietary data models and formats.

As such, the following additional tasks are proposed to be undertaken by the CDB SWG:

  1. Development of a minor revision, CDB V1.3, to provide a backwards-compatible capability to encode CDB attribution data in a modernized approach, as recommended in part by OGC Discussion Paper 20-092, which summarizes the experimentation and outcomes of the US SOCOM / SOFWERX sponsored Geospatial Tech Sprint II that was concluded in October 2020.
  2. Continued development of CDB X, a major revision to the OGC CDB Standard.
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: 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: 

Pages