OGC Requests

Public comment requested: OGC API - Environment Data Retrieval v1.1

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

The Open Geospatial Consortium (OGC) seeks public comment on the candidate Version 1.1 of the OGC API - Environmental Data Retrieval (EDR) Standard.

The OGC API - EDR Standard provides a family of lightweight query interfaces to access spatiotemporal data resources by requesting data at a Position, within an Area, along a Trajectory, or through a Corridor. An API compliant with the OGC API - EDR Standard will return only the data needed by the user or client, reducing data transfer time and costs.

The OGC API - EDR Standard makes it easier to efficiently access a wide range of geospatial ‘big data’ through a uniform, well-defined, simple Web interface that shields the user from the complexities of data storage. An example use case of the Standard could be to retrieve, say, weather forecasts for a local area from a much larger national or global forecast dataset – though many other types of data can be accessed through the API.

By defining a small set of query patterns (and no requirement to implement all of them), OGC API - EDR helps to simplify the design and performance-tuning of systems, making it easier to build robust, scalable infrastructures.

Version 1.1 of the OGC API - EDR Standard brings the following improvements:

  1. The optional use of HTTP POST as well as the HTTP GET verb. This will allow longer queries, such as when specifying a complicated, detailed area with very many points. The query payload is also encrypted and therefore more secure.
  2. Custom dimensions are allowed. As well as the usual 4 dimensions of space and time, (x,y,z,t), other dimensions could be offered by a data collection, such as frequency. The dimensions could also be categorical: that is, not necessarily continuous like space and time. For example, a list of wave or frequency bands, or any enumerated type. A meteorological example would be to allow data retrieval from individual ensemble members.

 

Comment: 

Comments on the standard can be submitted via the OGC API - Environmental Data Retrieval GitHub Repository  OR 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 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 email 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: GeoParquet Standards Working Group Charter

Status: 
Please note:  This Request is scheduled to close on 15 February 2023.
Open Date: 
Wed, 01/25/2023
Closing Date: 
Wed, 02/15/2023
Description: 

The Open Geospatial Consortium (OGC) is in the process of forming a new GeoParquet Standards Working Group (SWG). Public comment is sought on its draft charter. Comments are due by 15 February, 2023.

The OGC GeoParquet SWG will work to advance the GeoParquet encoding format to an OGC Encoding Standard for cloud-native vector data. GeoParquet adds geospatial types to Apache Parquet, described by Apache as "an open source, column-oriented data file format designed for efficient data storage and retrieval. It provides efficient data compression and encoding schemes with enhanced performance to handle complex data in bulk." For an introduction to the GeoParquet format, see this blog post.

GeoParquet started 3 years ago as a community effort by different Open Source Projects and organizations that have committed to its implementation and support. 

OGC is advancing a number of Standards to enable cloud-native geospatial ecosystems. GeoParquet fits in the group of data encoding Standards that are highly performant for large, cloud-based data stores, such as Cloud Optimized GeoTIFF for tiled rasters and Zarr for datacubes. GeoParquet will, in time, enable vector datasets to be as readily accessible from the cloud as the other formats already well-used in the community.

The GeoParquet SWG will take the initial efforts incubated in OGC’s GeoParquet GitHub repository as a draft specification from which a candidate Standard will be developed. As with many other recent OGC Standards, the repository will remain open to contributions from outside OGC and documentation will evolve in concert with prototype implementations.

GeoParquet will be another encoding of the OGC Simple Features Standard, and as such will handle all Simple Feature geometries. While other OGC Standards also encode Simple Features, GeoParquet is intended to be optimized for native use in cloud environments. It is expected that GeoParquet will be tested as an encoding to be accessed by the OGC APIs. The proposed SWG expects to have a candidate Standard ready for review and approval within one year of creation of the SWG.

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: 

OGC Seeks Public Comment on adoption of new version of CityJSON as Community Standard

Status: 
Please note:  This Request is scheduled to close on 1 February 2023.
Open Date: 
Wed, 12/21/2022
Closing Date: 
Wed, 02/01/2023
Description: 

 

The Open Geospatial Consortium (OGC) seeks public comment on an updated version (v1.1) of the CityJSON Community Standard. Comments are due 1 February, 2023.

The CityJSON v1.1 Community Standard Justification Document outlining the many changes is available for review and comment on the OGC Portal. The complete CityJSON v1.1 specifications are available on the CityJSON website.

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. The candidate version 1.1 encodes the OGC CityGML 3.0 Conceptual Model Standard.

The candidate CityJSON v1.1 standard is available for review and comment on the OGC Portal. Comments are due by 1 Febuary, 2023

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: 

OGC Seeks Public Comment on Creating new GeoDataCube Standards Working Group

Status: 
Please note:  This Request is scheduled to close on 19 January 2023.
Open Date: 
Mon, 12/19/2022
Closing Date: 
Thu, 01/19/2023
Description: 

 

 

The Open Geospatial Consortium is seeking public comment on the creation of a GeoDataCube Standards Working Group (SWG). The GeoDataCube SWG will enhance the interoperability between existing datacube solutions, simplify the interaction with different datacubes, and facilitate the integration of data from multiple datacube sources. By following a user-centric approach, the SWG will develop solutions that meet the needs of scientists, application developers, and API integrators.

The goal of the OGC GeoDataCube SWG is to create a new API specifically to serve the core functionalities of GeoDataCubes such as access and processing and to define exchange format recommendations, profiles, and a metadata model. The SWG also aims to analyze usability of already existing Standards and identify use cases.

Similar to other OGC APIs, the GeoDataCube SWG will create this new standard from existing building blocks such as existing geospatial Standards, previous OGC innovation initiatives, and other developer resources in a very use-case driven approach, i.e., with a small core and possible extensions. This will allow for interoperability across future OGC Standards.

With regards to existing and emerging OGC standards, the working group may look specifically at:

  • OGC API - Environmental Data Retrieval: A family of lightweight interfaces to access Environmental Data resources.

  • OGC API - Coverages: Defining a Web API for accessing coverages that are modeled according to the Coverage Implementation Schema.

  • OGC Analysis Ready Data SWG products: proposed Standards to describe specific product types that are often implemented as Geodatacubes.

  • OGC API - Processes: Supporting the wrapping of computational tasks into executable processes that can be offered by a server through a Web API. 

  • Zarr: An OGC Community Standard for the storage of multi-dimensional arrays of data.

  • GeoTIFF and Cloud Optimized GeoTIFF: A format used to share geographic image data.

  • Hierarchical Data Format (HDF5): A set of formats designed to store and organize large amounts of data.

The GeoDataCube SWG will follow an agile methodology with the goal to create a first core standard within the first year. Subsequent iterations may add additional functionality. The GeoDataCube SWG will start with a use case collection and analysis phase that further informs the selection of additional starting points or other work to be considered. The targeted use cases shall reflect real world scenarios, though should allow for a rapid implementation of the GeoDataCube standards without adding unnecessary complexity.

The OGC GeoDataCube SWG plans to meet at the OGC Member Meeting in Frascati, Italy, hosted by the European Space Agency (ESA) during the week of 20 February, 2023. Additional information about the meeting will be provided through OGC mailings.

The public comment period for the GeoDataCubes SWG will end 19 January, 2023. 

 

 

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: update to GeoSPARQL Standard

Status: 
Please note:  This Request is scheduled to close on 13 February 2023.
Open Date: 
Mon, 12/12/2022
Closing Date: 
Mon, 02/13/2023
Description: 

The Open Geospatial Consortium (OGC) is seeking public comment on the adoption of GeoSPARQL v1.1 as an OGC Standard. OGC GeoSPARQL extends W3C’s SPARQL to provide a geographic query language for RDF data.

Version 1.1 of GeoSPARQL extends the originally published standard in 2012 that is used for representation and querying of geospatial linked data for the Semantic Web in new ways. 

SPARQL is one of several key technologies that enable the “Semantic Web” or “Web of data,” where data is published to the Web so that it can be accessed, shared, and reused across applications and users. In other words, in a manner aligned with the FAIR data principles (Findable, Accessible, Interoperable, and Reusable). SPARQL specifications provide languages and protocols to query and manipulate RDF graph content on the Web or in an RDF store.

Other technologies identified by the W3C Semantic Web Activity as being key to the Semantic Web include the Resource Description Framework (RDF) data model, which provides a directed, labeled graph data format for representing data on the Web, and the OWL 2 Web Ontology Language, which provides an ontology for the consistent naming and identification of data.

The OGC GeoSPARQL draft specification complements these technologies by providing a geographic query language for RDF data that contains a spatial component.

The OGC GeoSPARQL Standard comprises multiple parts, with the Standard defining:

  • A formal profile;

  • The Standard document;

  • A core RDF/OWL ontology for geographic information representation;

  • A set of SPARQL extension functions;

  • A Functions & Rules vocabulary, derived from the ontology;

  • A Simple Features geometry types vocabulary;

  • SHACL shapes for RDF data validation.

GeoSPARQL does not define a comprehensive vocabulary for representing spatial information. Instead GeoSPARQL defines a core set of classes, properties, and datatypes that can be used to construct query patterns. Many useful extensions to this vocabulary are possible, and the chairs of the OGC GeoSPARQL Standards Working Group intend for the Semantic Web and Geospatial communities to develop additional vocabularies for describing spatial information. 

GeoSPARQL v1.1 adds the following changes to the existing v1.0 Standard:

Support for several now common geometry formats such as GeoJSON have been added as well as many simple non-topological functions, such as one to calculate area. A novel addition is support for Discrete Global Grid System geometry representations.

The GeoSPARQL ontology has been updated with Ontology properties for metric and non-metric measurements using properties and with classes to represent FeatureCollections and GeometryCollections. Also, a set of SHACL shapes allows validation of the GeoSPARQL 1.1 formatted graphs.

Many major updates to GeoSPARQL in this release though are not changes to the core standard but great improvements in the documentation and exemplification. Mappings to other models and query languages are also now included as well as data validators and support vocabularies, all of which are presented as a formal profile of multiple, related, resources with defined roles.

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

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

Pages