Open Geospatial Consortium

Submission Date: 2019-09-12

Approval Date: 2020-02-08

Publication Date: 2020-02-08

External identifier of this OGC® document: http://www.opengis.net/doc/CS/i3s/1.1

Additional Formats (informative): F+G2fvLtTjLSr4cADESA7XbHd8gco4fq2dAz0VXYYJMi2DSAeKJh+S1n4d8GPmwVvHdyvi8MNmyvuUrCagAAAABJRU5ErkJggg== wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAIALAAAAAAUABIAAAiIAAUIHEiwoMGBAxIqXHgQYYGHEB8OAGAwAACLGC8CkFiAIsGNESEGeAigpEeBGVMCIMCyAIGTAjR2HInxIQGXMGkWsNjx5c2fMDdqrBngJ06CNFdevLmy5cuPM3eCHAnx6UCqIXs6DaqyZlWYDiOy3HpwQFaxYAUOGMuWbVoBE03KlduwrsGAAAA7

Previous version (informative): https://docs.opengeospatial.org/cs/17-014r5/17-014r5.html

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

Version: 1.1

Category: OGC® Community Standard

Editor: Carl Reed, Tamrat Belayneh

OGC Indexed 3d Scene Layer (I3S) and Scene Layer Package Format Specification

Copyright notice

Copyright © 2020 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

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 for public release

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:

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

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

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

Notices:

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

Table of Contents
picture1

i. Abstract

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 version of this standard is here: https://github.com/Esri/i3s-spec [2].

ii. Source of the content for this OGC document

The majority of the content in this OGC document is a direct copy of the content contained at https://github.com/Esri/i3s-spec . No normative changes have been made to the content. This OGC document does contain content not contained at https://github.com/Esri/i3s-spec. Specifically, while derived from content on the https://github.com/Esri/i3s-spec 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 https://github.com/Esri/i3s-spec website. The Terms and Definitions and References sections may be added into the 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 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 date is June 2019. This version is also known as Esri version 1.6.

iv. Keywords

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

ogcdoc, OGC document, I3S, 3d, visualization, scene, scene layer, slpk

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

vi. Submitting organizations

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

Esri, Inc

vii. Supporting Organizations

The following organizations support the submission of version 1.1 of I3S as an OGC Community Standard:

Name Affiliation

Keith Ryden

Esri

Allan W. Shearer

UT Austin

Volker Coors

Hochschule für Technik Stuttgart

Andreas Wytzisk

52North

Carl Reed

Carl Reed & Associates

Gordon Plunkett

Esri Canada

Vijay Kumar

Esri India Technologies

Clemens Portele

interactive instruments GmbH

Brian Nicholls

AAM Pty Ltd

Bomi Lee

Korea Land & Geospatial InformatiX Corporation

Isaac Zaworski

Vricon, Inc

Thorsten Rietz

Wetransform GmbH

Dale Lutz

Safe Software

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 other organization supporting the submission shall provide the TCC 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 submitted to the OGC. Please submit your comments using the following link: 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

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

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 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 standard 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 (Annex D) endpoints is also described in this standard as open formats.

2. Conformance

Not required in an OGC Community Standard.

3. References

Normative

OGC SF [99-036/ISO 19125]: Geographic information - Simple feature access - Part 1: Common architecture. 2005. https://www.iso.org/obp/ui#iso:std:iso:19162:ed-2:v1:en August 17, 2019.

OGC WKT CRS [12-063r5/ISO 19162:2019]: Geographic information — Well-known text representation of coordinate reference systems. 2019. http://portal.opengeospatial.org/files/?artifact_id=4700 (May 15, 2017)

Informative

"Octree". https://en.wikipedia.org/wiki/Octree. Not Published (N.P.), 2016. Web. 20 Oct. 2016.

"Quadtree". https://en.wikipedia.org/wiki/Quadtree. N.P. 2017. Web. 20 Jan. 2017

"R-Trees". https://en.wikipedia.org/wiki/R-tree. N.P. 2017. Web. 20 Jan. 2017

4. Terms and Definitions

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

4.1 3D Model [4]

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.

4.2 Array Buffers

In JavaScript, the ArrayBuffer object is used to represent a generic, fixed-length raw binary data buffer.

4.3 Community Standard

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

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

4.5 faceRanges

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

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

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

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

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

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

4.11 Minimum Bounding Sphere [5](MBS, mbs)

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.

4.12 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) (https://www.shimadzu.com/an/ftir/support/tips/letter9/nir1.html, March 2019)

4.13 Normal or Normals [6]

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.

4.14 Oriented Bounding Box (OBB) [7]

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.

4.15 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, https://en.wikipedia.org/wiki/Point_cloud, March 2019)

4.16 Profile

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

4.17 S3TC [8]

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.

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

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

4.20 Texture Atlas [9]

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.

4.21 Texture Mapping [10]

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

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

4.23 UV Coordinate [11]

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.

4.24 UV Mapping [12] (aka UV Unwrapping)

UV mapping is the 3D modeling process of projecting a 2D image to a 3D model’s surface for texture mapping.

4.25 Vertex [13]

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

No conventions are specified in this document.

6. Introduction to I3S and SLPK

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

6.1. I3S Design Principles

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

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

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

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

  4. Level of Detail: Have support for multiple levels of detail;

  5. Distribution: Allow efficient distribution of very large data sets;

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

  7. Extensibility: Support new layer, geometry types and new platforms;

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

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

  10. Declarative: Communicate clearly to minimize the amount of required domain knowledge to support the format;

  11. 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 clients to visualize the data according to their needs. Data here refers to vertex geometry, texture as well as any associated attributes.

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 following layer types defined in this standard:

  • 3D Object Scene Layer (e.g., Building Exteriors from geospatial data and 3D models)

  • Integrated Meshes (e.g., an integrated surface representing the skin of the earth including vegetation, buildings and roads from satellite, aerial or drone imagery via dense matching photogrammetry)

  • Points (e.g., hospitals or Schools, trees, street furniture, signs, etc. from GIS data)

  • Point Clouds (e.g. 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

Annex

Features with Identity

Attributes

3D Objects

mesh-pyramids

Annex F

Yes

Yes

Integrated Mesh

mesh-pyramids

Annex F

No

Triangle Attributes (planned)

Point

points

Annex E [14]

Yes

Yes

Point Cloud

pointclouds

Annex G

No

Vertex Attributes

7. I3S Specification

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 (CRS)

[15]

The I3S specification supports specifying the Coordinate Reference System (CRS) as OGC Well Known Text, as originally defined in clause 6.4 in OGC Simple Features 99-036/ISO 19125 standard. I3S also supports specifying CRS in the ISO/OGC WKT standard ISO 19162:2019, 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. A note on OGC Standards for CRS and Well Known Text.

The two standards are referred to as WKT1 and WKT2.

  • 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] [16]. This original definition was extended in OGC Coordinate Transformation Service [01-009];

  • 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] [17]. 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."

OGC 12-063r5 [18] 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 [19] CRSs as well as for geographic [20] CRSs

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

These use cases lead to the following implementation requirements. Note that all I3S profiles support writing 3D content in two modes: global and local. These modes are also known as global and local scenes, respectively. In global scene mode, only the geographic CRS WGS84 (EPSG 4326) is supported for both index and vertex positions. In local scene mode, all other geodetic CRS, including projected coordinate systems, are allowed. In both global and local scenes, the vertex position attributes (x,y,z) are stored with a per-node offset (as a delta from the center point of the node’s minimum bounding volume). Furthermore:

  1. In global mode, 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.[21]

  2. In local scene mode, 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. Both height and bounding volumes are defined using the same xy units.

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

*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]],

VERTCS["EGM2008_Geoid",VDATUM["EGM2008_Geoid"],PARAMETER["Vertical_Shift",0.0],PARAMETER["Direction",1.0],UNIT["Meter",1.0]]}"
  }
*WKT2 description of a compound WGS 84, EPSG 4326 and EPSG 3855*

COMPOUNDCRS ["I3S Compund CRS",
GEODCRS["WGS 84",
  DATUM["World Geodetic System 1984",
    ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]],
  CS[ellipsoidal,2],
    AXIS["latitude",north,ORDER[1]],
    AXIS["longitude",east,ORDER[2]],
    ANGLEUNIT["degree",0.01745329252],
  ID["EPSG",4326]]
VERTCRS["EGM2008 height",
  VDATUM["EGM2008 geoid"],
  CS[vertical,1],
    AXIS["gravity-related height (H)",up],
    LENGTHUNIT["metre",1.0],
  ID["EPSG",3855]]​]

The following is an example for 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 (Clause 7.6.4) for more information on the use of the heightModelInfo object.

7.3. Indexed Scene Layers - 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 following sections define this structure.

7.3.1. I3S - Indexing Model and Tree Structure

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.

I3S is agnostic with respect to the model used to index objects/features in 3D space. Both regular partitions of space (e.g. Quadtrees [22] and Octrees [23]) as well as density dependent partitioning of space (e.g. R-Trees [24]) 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).

Each node has an address and nodes may be thought of as equivalent to tiles. A node has an ID that is unique within a layer. I3S supports two types of node ID formats: string based treekeys or as integers based on a fixed linearization of the nodes.

The treekey format is loosely modeled on binary search trees. The key 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.

Treekeys are strings in which levels are separated by dashes. The root node is at level 1 always gets ID root. For example, take the node with treekey "3-1-0." Since this key has 3 numeric elements 3, 1, and 0, we can conclude that the node is on level 4 ("root" node is at level 1) and the parent node is "3-1." An example of this numbering pattern is shown in Figure 1 below.

figure1
Figure 1. A Sample Index Tree with Treekeys

For example, take the node with treekey "3-1-0." Since it has 3 numeric elements 3, 1 and 0, it can be concluded that the node is on level 4 (The root node is at level 1). Furthermore, the node "3-1" is its parent node.

The information for a node is stored in multiple individually accessible resources. The node index document is a lightweight resource that captures the Bounding Volume Hierarchy (BVH) tree topology for the node. Key components of the document include the node’s bounding volume information, meta-data used for (LoD Switching Models) metrics, as well as parent-child relationships. The node index resource allows for tree traversal without the need to access the more voluminous content associated with a node (geometry, texture data, attributes).

The decision to render a node by the client application is based on node’s bounding-volume visibility in the current 3D view. Once the node’s bounding-volume visibility is determined to be within the current 3D view of the application, then further evaluation is performed by the client application to determine the visual quality of the node. This determination is done using the information included in the node index document. The node’s quality is estimated as a function of current view parameters, node’s bounding volume and LoD selection metric value of the node.

The standard supports both minimum bounding sphere (MBS) and oriented bounding boxes (OBB) as a node’s bounding volume.

Each node includes the set of information covered by the nodes below it and is part of the path of the leaf nodes below it. Interior nodes may have a reduced representation of the information contained in descendant nodes.

The I3S format models node information using a set of resources including NodeIndex Document, FeatureData, Geometry, Attributes, Textures and SharedResource. All these together represent the set of features or data elements for a given node. These resources are always attached to a node.

  • Node Index Document: A lightweight resource representing a node, its topology within the tree and includes references to other sub-resources.

  • Feature Data: A text sub-resource for a node that contains the identifiers for the set of features within a node. It can store the geometry and attributes for all of the features in the node either by value or as references into the geometry and attribute sub-resources for the node.

  • The Geometry, Attribute and Texture sub-resources describe the geometry, attribute and texture for the node. Geometry and attribute sub-resources represent the geometries and attributes of all of the features within the node and include the identifiers of the owning features within the node as well as the mapping between individual feature identifiers and their geometry segments. Vertices within the geometry contain the appropriate texture coordinates.

An I3S profile uses either a single text-based feature-data sub-resource that contains all geometry and attribute information (e.g., Point profile), or separate, binary and self-contained geometry and attribute sub-resources (e.g., mesh-pyramids profile). Applications that use the separate binary sub-resources do not need to first fetch the feature-data resource in order to interpret them. All binary data is stored using a little-endian byte ordering.