Open Geospatial Consortium

Submission Date: 2021-05-11

Approval Date:   2021-11-02

Publication Date:   2021-12-15

External identifier of this OGC® document:

Internal reference number of this OGC® document:    17-014r8

Version: 1.2

Category: OGC® Community Standard

Editors:   Carl Reed, Tamrat Belayneh

OGC Indexed 3d Scene Layer (I3S) and Scene Layer Package (*.slpk) Format Community Standard Version 1.2

Copyright notice

Copyright © 2021 Open Geospatial Consortium

To obtain additional rights of use, visit


This document is an OGC Member endorsed international Community Standard. This Community Standard was developed outside of the OGC and the originating party may continue to update their work. However, this document is fixed in content. This document is available on a royalty free, non-discriminatory basis.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Community Standard

Document subtype:   

Document stage:    Approved

Document language:  English

Esri (Environmental Systems Research Institute, Inc.)

The companies listed above have granted the Open Geospatial Consortium (OGC) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version under a Creative Commons ShareAlike (CC BY-SA) license (see below).

License Agreement

The standard is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).[1] You can implement this standard in services, clients or processing tools without restrictions.

You are directed to the License for specific details.

This is a human-readable summary of (and not a substitute for) the license.

You are free to:

Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material for any purpose, even commercially.

The licensor cannot revoke these freedoms as long as you follow the license terms.

Under the following terms:

  1. Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

  2. ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

  3. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.


You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation.

No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material.


i. Abstract

The Indexed 3D Scene Layer (I3S) format is an open 3D content delivery format used to rapidly stream and distribute large volumes of 3D GIS data to mobile, web and desktop clients. I3S content can be shared across enterprise systems using both physical and cloud servers.

A single I3S data set, referred to as a Scene Layer, is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. Scene Layers are designed to be used in mobile, desktop, and server-based workflows and can be accessed over the web or as local files.

The delivery format and persistence model for Scene Layers, referred to as Indexed 3d Scene Layer (I3S) and Scene Layer Package (SLPK) respectively, are specified in detail in this OGC Community Standard. Both formats are encoded using JSON and binary ArrayBuffers (ECMAScript 2015). I3S is designed to be cloud, web and mobile friendly. I3S is based on JSON, REST and modern web standards and is easy to handle, efficiently parse and render by Web and Mobile Clients. I3S is designed to stream large 3D datasets and is designed for performance and scalability. I3S is designed to support 3D geospatial content and supports the requisite coordinate reference systems and height models in conjunction with a rich set of layer types.

The open community GitHub source for this Community Standard is here.

ii. Source of this document

The majority of the content in this OGC document is a direct copy of the content contained at . No normative changes have been made to the content. This OGC document does contain content not in source Esri GitHub repository. Specifically, while derived from content on the Esri I3S repository, the Abstract, Keywords, Preface, Submitting Organizations, Endorsers, Terms and Definitions, and References sections and Annex B (Bibliography) in this document are not found on the Esri I3S repository. The Terms and Definitions and References sections may be added into the Esri community GitHub repository in the future.

Please note that the Esri I3S Github repository includes a Building Scene Layer (e.g. comprehensive building model including building components). This layer type is not included in this OGC Community Standard but may be proposed for inclusion in a future version.

iii. Validity of content

The Submission Team has reviewed and certified that the snapshot content in this Community Standard is true and accurate. The snapshot for OGC I3S Version 1.2 was taken on February 8, 2021.

iv. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, i3s, 3d, point clouds, visualization, scene, scene layer, slpk

vi. Preface

I3S originated from investigations into technologies for rapidly streaming and distributing large volumes of 3D content across enterprise systems that may consist of server components, cloud hosted components, and a variety of client software from desktop to web and mobile applications.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Organization name(s)

Esri, Inc.

v. Supporting Organizations

The following organization support the submission of the I3S Community Standard version 1.2 to the OGC:

Name Affiliation

Keith Ryden


Carl Reed

Carl Reed & Associates

Jerome Jacovella-St-Louis


Gordon Plunkett

Esri Canada

Vijay Kumar

Esri India Technologies

Anneley Hadland

Helyx Secure Information Systems Ltd

Howard Butler

Hobu Inc.

Volker Coors

Hochschule für Technik Stuttgart

Clemens Portele

Interactive Instruments

Jeongeun (Bomi) Lee

KoreaLand & Geospatial InformatiX Corporation

Cesar Suarez, Hermann Brassard


Dean Hintz

Safe Software

Ib Green


Note on supporting organizations. As per the OGC Technical Committee Policies and Procedures:

  • Any Community Standard submission requires that three or more distinct Member organizations support the submission. In addition to the submission team lead, each organization supporting the submission shall provide the OGC with an email stating their organization’s support of the submission.

Please note that all questions and/or comments regarding this OGC Community Standard should be documented by submitting a GitHub issue in the OGC I3S GitHub repository.

vi. Future Work The I3S community anticipates that revisions to this Community Standard will be required to prescribe content appropriate to meet new use cases. These use cases may arise from either (or both) the external user and developer community or from OGC review and comments. Further, future revisions will be driven by any submitted change requests that document community uses cases and requirements.

Currently, the following layer type may be considered for future inclusion in the I3S standard (future work):

  • Building Scene Layer (e.g. comprehensive building model including building components)

1. Introduction

A single I3S data set, referred to as a Scene Layer, is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. Scene Layers provide clients access to data and allow them to visualize it according to their needs. The definition of "data" in this case includes the geometry, attributes, and vertex geometry. I3S organizes information into node hierarchies that contain features with geometry, textures and attributes.

A Scene Layer is characterized by a combination of layer type and profile. The layer type describes the kind of geospatial data stored within it. The layer profile includes additional details on the specific I3S rules for implementation.

The I3S format is declarative and extendable and can be used to represent different types of 3D data. The following layer types have been specified and the validated via implementation and production deployments:

3D Objects such as Building Exteriors from geospatial data and 3D models.

Integrated Meshes such as a mesh surface with high resolution imagery textures representing the skin of the Earth, typically created from satellite, aerial or drone imagery.

Point Features such as geolocated hospitals or schools, trees, street furniture, and signs.

Point Clouds such as large point data from LiDAR.

The Indexed 3d Scene Layer (I3S) and Scene Layer Package (*.slpk) are open formats and not dependent on any vendor specific solution, technology, or products.[3] The specification for accessing I3S resources as Scene Service REST endpoints is also described in this standard as open formats.

2. Conformance

Not required in an OGC Community Standard.

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.


OGC SF [99-036/ISO 19125]: Geographic information - Simple feature access - Part 1: Common architecture. 2005. August 17, 2019.

OGC WKT CRS [12-063r5/ISO 19162:2019]: Geographic information — Well-known text representation of coordinate reference systems. 2019. (May 15, 2017)


"Octree". Not Published (N.P.), 2016. Web. 20 Oct. 2016.

"Quadtree". N.P. 2017. Web. 20 Jan. 2017

"R-Trees". N.P. 2017. Web. 20 Jan. 2017

4. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms and definitions apply.

3D Model [1] Three-dimensional (3D) models represent a physical body using a collection of points in 3D space, connected by various geometric entities such as triangles, lines, curved surfaces, etc. ArrayBuffer In JavaScript, the ArrayBuffer object is used to represent a generic, fixed-length raw binary data buffer. ArrayBuffer is an abstract type that is the base for the following types: DataView, Float32Array, Float64Array, Int8Array, Int16Array, Int32Array, Uint8Array, Uint8ClampedArray, Uint16Array, Uint32Array.

Bounding Volume (BV) [2] A closed volume that completely contains the union of the objects in the set. Bounding volumes are used to improve the efficiency of geometrical operations by using simple volumes to contain more complex objects.

Bounding Volume Hierarchy (BVH) [3] A tree structure on a set of geometric objects. All geometric objects are wrapped in bounding volumes that form the leaf nodes of the tree.

Community Standard An OGC Community Standard is an official position of the OGC endorsing a specification or standard developed external to the OGC.

Face In solid geometry, a face is a flat (planar) surface that forms part of the boundary of a solid object; a three-dimensional solid bounded exclusively by flat faces is a polyhedron.

faceRanges Indicates the range of triangles associated with a particular object (feature).

Gravity-related height Height dependent on the Earth’s gravity field. NOTE: This refers to in particular orthometric height or normal height, which are both approximations of the distance of a point above the mean sea level. (ISO 19111)

Height Distance of a point from a chosen reference surface measured upward along a line perpendicular to that surface. NOTE: A height below the reference surface will have a negative value.

Integrated Mesh An Integrated Mesh is a type of I3S layer that belongs to the mesh-pyramids profile. An Integrated Mesh layer type is typically used to represent and visualize geographic data captured as ‘3D Image’ representing the landscape in a seamless, highly scalable, textured mesh. Such ‘3D Image’ can integrate within its content a multitude of landscape elements including terrain surface, ground imagery, vegetation, man-made objects and structures, and water surfaces. This type of data is typically produced by automated extraction solutions operating on input data from satellite, aerial and/or drone imagery.

Level of Detail (LoD) Using different LoDs involves decreasing the complexity of a 3D model representation as it moves away from the viewer or according to other metrics such as object importance, viewpoint-relative speed or position. There are numerous approaches to defining LoDs. In GIS, LoDs typically refer to maps defined at given scales and resolutions. Typically higher levels of detail provide greater fidelity. A number of OGC standards define approaches to LoD. LiDAR Light Detection and Ranging, is a remote sensing method that uses light in the form of a pulsed laser to measure ranges (variable distances) to the Earth.

Minimum Bounding Sphere (MBS, mbs) [4] In mathematics, given a non-empty set of objects of finite extension in n-dimensional space, for example a set of points, a bounding sphere, enclosing sphere or enclosing ball for that set is an n-dimensional solid sphere containing all of these objects.

Near Infrared Light Generally refers to light within the wavenumber range of 12,500 to 4,000 cm-1 (wavelengths from 800 to 2,500 nm) (, March 2019)

Normal or Normals [5] The normal vector, often simply called the "normal," to a surface is a vector which is perpendicular to the surface at a given point. When normals are considered on closed surfaces, the inward-pointing normal (pointing towards the interior of the surface) and outward-pointing normal are usually distinguished.

Oriented Bounding Box (OBB) [6] In geometry, the minimum or smallest bounding or enclosing box for a point set (S) in N dimensions is the box with the smallest measure (area, volume, or hyper-volume in higher dimensions) within which all the points lie. An oriented bounding box is simply a bounding parallelepiped whose faces and edges are not parallel to the basis vectors of the frame in which they’re defined. In many applications the bounding box is aligned with the axes of the coordinate reference system and is known as an axis-aligned bounding box (AABB). To distinguish the general case from an AABB, an arbitrary bounding box is called an oriented bounding box (OBB) when an object’s local coordinate reference system is used.

Point Cloud A point cloud is a set of data points in space. Point clouds are generally produced by 3D scanners, which measure a large number of points on the external surfaces of objects around them. (Wikipedia,, March 2019)

Profile In I3S, specific implementation instances for specific layer definitions (point, mesh, etc.)

S3TC [7] S3TC is a technique for compressing images for use as textures. Standard image compression techniques like JPEG and PNG can achieve greater compression ratios than S3TC. However, S3TC is designed to be implemented in high-performance hardware. JPEG and PNG decompress images all-at-once, while S3TC allows specific sections of the image to be decompressed independently.

Scene Layer A scene layer is a type of layer that is optimized for displaying large amounts of 3D data in a scene. A scene layer displays one of four data types: points, a point cloud, 3D objects, or an integrated mesh.

Shader A small program or set of algorithms that determines how 3-D surface properties of objects are rendered, and how light interacts with the object within a 3-D computer program.

Texture In 3D graphics, the digital representation of the surface of an object. In addition to two-dimensional qualities, such as color and brightness, a texture is also encoded with three-dimensional properties, such as how transparent and reflective the object is. Once a texture has been defined, it can be wrapped around any 3-dimensional object. This is called texture mapping.

Texture Atlas [8] A large image containing a collection, or "atlas", of sub-images, each of which is a texture map for some part of a 2D or 3D model.

Texture Coordinates Texture coordinates define how an image (or portion of an image) gets mapped to a geometry. A texture coordinate is associated with each vertex on the geometry, and it indicates what point within the texture image should be mapped to that vertex.(SAFE Software, 4/2021)

Texture Mapping [9] Texture mapping is a method for defining high frequency detail, surface texture, or color information on a computer-generated graphic or 3D model.

Texture Maps A texture map is an image applied (mapped) to the surface of a shape or polygon. This may be a bitmap image or a procedural texture. They may be stored in common image file formats, referenced by 3d model formats or material definitions, and assembled into resource bundles.

Treekey Indicates both the level and sibling association of a given node. The key also directly indicates the position of the node in the tree, allowing sorting of all resources on a single dimension. In OGC Version 1.2, node ids are linearized integers converted to strings. This does not change the format of a node index document (was string and remains string). The concept of Treekeys was utilized by the node index neighbor property which was deprecated at 1.0

UV Coordinate [10] UV coordinates are 2D coordinates that are mapped onto a 3D model. UV coordinates are a texture’s x and y coordinates and always range from 0 to 1. Let’s take for example a 800×600 image. When we use a UV coordinate with u=0.5 and v=0.5 then the pixel at x=400 and y=300 is targeted.

UV Mapping (aka UV Unwrapping) [11] UV mapping is the 3D modeling process of projecting a 2D image to a 3D model’s surface for texture mapping.

Vertex [12] In computer graphics, a vertex is not only associated with three spatial coordinates but also with other graphical information necessary to render the object correctly, such as colors, reflectance properties, textures, and surface normals. These properties are used in rendering by a vertex shader, part of the vertex pipeline.

5. Conventions

There are no mandatory conventions defined in this Community Standard.

6. Introduction to I3S and SLPK

This section provides background information on the design principals and background for I3S

6.1. I3S Design Principals

The Indexed 3d Scene layer (I3S) format and the corresponding Scene Layer Package format (*.slpk) are specified to fulfill this set of design principles:

  • User Experience first: Provide a positive user experience, including high interactivity and fast display;

  • Scalability: Support very large scene layers, including scenes with a global extent and many detailed features;

  • Reusability: Use as a service delivery format, storage format, and exchange format;

  • Level of Detail: Have support for multiple levels of detail;

  • Distribution: Allow efficient distribution of very large data sets;

  • User-controllable symbology: Support efficient rendering of client-side symbology/styling;

  • Extensibility: Support new layer, geometry types and new platforms;

  • Web Friendliness: Provide easy to handle data using JSON and current web standards;

  • Compatibility: Provide a single structure that is compatible across web, mobile, and desktop clients. Support is also included for cloud and servers;

  • Declarative: Communicate clearly to minimize the amount of required domain knowledge to support the format; Follow REST/JSON API best practices: Provide navigable links to all resources.

6.2. I3S Overview

A single I3S data set, referred to as a Scene Layer, is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. Scene Layers provide clients access to data and allow them to visualize it according to their needs. Data here refers to vertex geometry, texture as well as any associated attributes.

An I3S data set is organized as nodes and layers. Nodes are structured into node pages. The node page includes the bounding volume, child reference, count and the level of detail selection. Nodes contain all the information to describe features including geometry, attributes and textures. Scene Layers can be created in cartesian 3D or in global 3D world coordinate reference systems. I3S Scene Layers can be delivered to web, mobile and desktop clients. Most users will interact with Scene Layers using applications with cloud or server-based information. In these cases, the scene layer content is on the server and is provided to clients through a RESTful interface. These web addressable resources provide access to the scene layer, nodes, and associated resources. Alternatively, a scene layer can be delivered as a Scene Layer Package. This is a single file that includes the complete node tree and all necessary resources in an archive.

An I3S Layer is characterized by a combination of layer type and profile. The layer type describes the kind of geospatial data stored within it. The layer profile includes additional details on the specific I3S implementation.

The requirements specified below apply to the current scene layer profile types:

  • 3D Object such as Building Exteriors from geospatial data and 3D models.

  • Integrated Meshs such as a mesh surface with high resolution imagery textures representing the skin of the Earth, typically created from satellite, aerial or drone imagery. A profile for integrated meshes is described in I3S Scene Layer Profile - Mesh-pyramids (MP)

  • Points such as geolocated hospitals or schools, trees, street furniture, and signs.

  • Point Clouds such as LiDAR data.

Layers are described using two properties: type and profile. The type of a layer describes the type of geospatial data stored within it drawing from terms including 3D Objects, Points, Lines, Polygons, and Point Clouds. The profile for a layer includes additional detail on the specific I3S implementation for the layer that is exposed to clients. Each layer has a canonical profile, but in certain cases multiple layers that represent semantically different types of information can make use of the same underlying profile. In other cases the same layer type can support multiple profiles optimized for different use cases.

The following table shows the layer types and profiles. For each row the table indicates if the layer type represents features (geographic entities) with identity (as opposed to a geospatial field described by a mesh or cloud of geometry elements) and if the specific profile for the layer supports storage of attributes (either feature attributes or attributes of individual geometry elements, depending on the type of the layer).

Table 1. 3D Layer Types Supported in I3S
Layer Type (example) Profile Features with Identity Attributes

3D Object




Integrated Mesh



Triangle Attributes (planned)





Point Cloud



Vertex Attributes

7. I3S Standard - Normative

This section contains the normative clauses and requirements for implementing I3S. In the property tables, any property highlighted with a bold font is mandatory.

7.1. Coordinate Reference Systems

The I3S standard supports specifying the Coordinate Reference System and refers to two OGC standards for describing a CRS as Well Known Text. These are WKT1 as defined in the OGC Coordinate Transformation Service Standard (01-009) and WKT2 as defined in OGC Geographic Information – Well known text representation of coordinate reference systems (12-063r5). CRS as OGC Well Known Text was originally defined in clause 6.4 in the OGC Simple Features 99-036/ISO 19125 standard.

I3S also supports specifying CRS in the ISO/OGC WKT standard ISO 19162:2015, Geographic information – Well-known text representation of coordinate reference systems. This new ISO/OGC Standard specifies an update to the original WKT representation. The two standards are referred to as WKT1 and WKT2 respectively.

7.1.1. (Was 7.1.1 in Version 1.1) A note on OGC Standards for CRS and Well Known Text.

The two standards are referred to as WKT1 and WKT2

  1. WKT1: Refers to Well Known Text (WKT) for expressing a CRS as originally defined in clause 6.4 in OGC Simple Features [99-036/ISO 19125. This original definition was extended in OGC Coordinate Transformation Service [01-009];

  2. WKT2: Refers to WKT as defined in OGC WKT CRS/ISO 19162:2015 Geographic information — Well-known text representation of coordinate reference systems [12-063r5]. From the document, “This Standard provides an updated version of WKT representation of coordinate reference systems that follows the provisions of ISO 19111:2007 and ISO 19111-2:2009. It extends the earlier WKT to allow for the description of coordinate operations.”

The text in this paragraph is extracted verbatim from 12-063r5. OGC 12-063r5 makes several references to backward compatibility. “Backward compatibility means that an implementation of the text strings in this International Standard would be able to read CRS WKT strings conforming to the old (ISO 19125-1:2004) syntax. It does not mean that a parser of a string compliant to ISO 19125-1:2004 could read WKT strings written in conformance with this International Standard. It also does not require an implementation of the text strings in this International Standard to be able to output an object according to the old syntax. Annex B.8 gives guidance on determining the version of a CRS WKT string. A mapping of older syntaxes to this International Standard is given in Annex C.”

Please note that in an I3S implementation the CRS MAY be represented using either WKT1 or WKT2. While WKT1 has been in use for many years, WKT1 has been superseded by WKT2. Although implementations of OGC standards using WKT2 are not yet widely available the guidance from the OGC/ISO community is to implement WKT2. Important Note: WKT1 does not support explicit definition of axis order.

Therefore, *I3S implementers need to note for their implementations if they support WKT1 only or both (as WKT2 requires continued support of WKT1)*.

7.1.2. CRS Use and Requirements in I3S

Indexed 3D Scene Layers have to fulfill a number of requirements when it comes to the selection of Coordinate Reference Systems (CRS) to use:

  • Minimize the need for re-projection on the client side

  • Support data sets with a global extent

  • Render easily in coordinate reference systems for projected CRSs as well as for geographic CRSs

  • Support local and global data with very high positional accuracy.

NOTE: A Projected CRS is defined on a flat, two-dimensional surface. Unlike a Geographic CRS, a Projected CRS has constant lengths, angles, and areas across the two dimensions. A Projected CRS is always based on a Geographic CRS that is based on an ellipse. Geographic CRSs are based on a Geodetic datum. The EPSG dataset contains three subtypes of Geodetic CRS: Geocentric, Geographic 3D, Geographic 2D. ISO 19111 Compliance Note: In ISO19111, geog2D, geog3D and geocentric are all considered to be "geodetic CRSs".

These use cases lead to the following implementation requirements. Note that all I3S profiles support writing 3D content in two modes: global and local. In global mode, only the geographic CRS WGS84 (EPSG 4326) is supported for both index and vertex positions.

  • The location of all index-related data structures such as node bounding spheres SHALL be specified using a single, global geographic WGS 84 CRS. Coordinate bounds for such structures SHALL be in the range (-180.0000, -90.0000, 180.0000, 90.0000). Height and node minimum bounding sphere (MBS) radius SHALL be specified in meters. Allowed CRS specified using an EPSG code is EPSG:4326

  • All vertex positions SHALL be specified using a geodetic CRS (including Cartesian coordinate reference systems), where x,y,z axes are all in same unit, and with a per-node offset (from the center point of the node’s minimum bounding sphere) for all vertex positions.

  • Axis Order: Axis order explicitly defined by the CRS SHALL be used when present. When the axis order is not defined by the CRS, Easting, Northing, Height axis order SHALL be used. The Height axis SHALL always point upwards towards the sky (away from the center of the earth).

All I3S layers indicate the coordinate system used by the layer with the spatialReference property in the 3dSceneLayerInfo resource. This property is normative.

The spatial reference object is common to all I3S profile types.

7.2. Height Models

The I3S standard accommodates declaration of a vertical coordinate reference system that may either be ellipsoidal (height defined with respect to a reference ellipsoid) or gravity-related height (height defined with respect to a reference geoid/gravity surface). This allows the I3S approach to be applied across a diverse range of fields and applications where the particular definition of height is of importance.

The Well-known Text (WKT) string representation of the CRS now includes the vertical coordinate reference system utilized by the layer. The spatialReference property also includes a well-known Id (wkid) and a Vertical Coordinate Reference System Well-known ID (vcsWkid) representation, which could alternatively be utilized by a client application consuming the layer instead of the WKT. In addition to the detailed spatialReference property that describes the layers horizontal and vertical CRSs, the 3dSceneLayerInfo resource also includes a coarse metadata property called heightModelInfo, which can be used by a client application to quickly identify if the layers' height model is either gravity-related or ellipsoidal.

The following is a WKT1 description of WGS 84, EPSG 4326.

"spatialReference": // the horizontal and vertical coordinate reference system of the layer
        "wkid": 4326,
        "latestWkid": 4326,
        "vcsWkid": 3855,
        "latestVcsWkid": 3855,
        "wkt": "GEOGCS[\"GCS_WGS_1984\",DATUM[\"D_WGS_1984\",SPHEROID[\"WGS_1984\",6378137,298.257223563]],PRIMEM[\"Greenwich\",0],UNIT[\"Degree\",0.017453292519943295]],

The following is a WKT2 description of a compound WGS 84, EPSG 4326 and EPSG 3855.

  DATUM["World Geodetic System 1984",
    ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]],
VERTCRS["EGM2008 height",
  VDATUM["EGM2008 geoid"],
    AXIS["gravity-related height (H)",up],

The following is an example of heightModelInfo.


    "heightModelInfo":  // a coarse metadata indicating the layers height Model
        "heightModel": "gravity_related_height", //one of {*" gravity_related_height"*, "ellipsoidal"};
        "ellipsoid": "wgs84 (G1674)/", //datum realization
        "heightUnit": "meter" //units

The above examples illustrate the coordinate reference system and height model of a layer in an I3S payload. The spatialReference object includes a Well-known Text (WKT) string representation of the CRS for both horizontal and vertical coordinate reference systems. The examples provided above show both WKT1 and WKT2 WKT encodings as defined in OGC 12-063r5 - either may be encoded in the spatialReference object. The heightModelInfo object is coarse metadata that could be used by client application to quickly determine if the layers' horizontal and vertical coordinate reference systems align with that of any base map data used by the application.

See Class 3DSceneLayerInfo (Formerly Clause 7.5.4 in version 1.1) for more information on the use of the heightModelInfo object.

8. Organization and Structure

I3S organizes information using a hierarchical, node-based spatial index structure in which each node’s payload may contain features with associated geometry, textures and attributes.

The purpose of any index is to allow fast access to blocks of relevant data. In an Indexed 3D Scene layer, the spatial extent of the data is split into regions, called nodes. Each node has roughly equal amounts of and is organized into a hierarchical and navigable data structure. The node index allows the client to quickly determine which data it needs and allows the server to quickly locate the data requested by any client. Node creation is capacity driven. For example, the smaller the node capacity is, typically the smaller the spatial extent.

The following clauses detail this structure.

8.1. Tree Structure

To ensure high performance when visualizing 3D content, data are spatially grouped into nodes. The grouping process is repeated recursively to create a tree of nodes. The spatial extent of a given node encompasses all its children to create a bounding volume hierarchy.

I3S is agnostic with respect to the model used to index objects/features in 3D space. Both regular partitions of space (e.g. Quadtrees and Octrees) as well as density dependent partitioning of space (e.g. R-Trees) are supported. The specific partitioning scheme is hidden from clients who navigate the nodes in the tree exposed as web resources. The partitioning results in a hierarchical subdivision of 3D space into regions represented by nodes, organized in a bounding volume tree hierarchy (BVH).

The bounding volume hierarchy (BVH) is based on minimum bounding spheres (MBS) or oriented bounding boxes (OBB). The mesh-pyramids profile supports specifying the bounding volume in either MBS or OBB representation. OBB is the more optimal representation and implementers are encouraged to output node bounding volume in OBB format. Point cloud profile supports OBB representation only.

3D objects enclosed in minimum bounding spheres.