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:


 

 

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. However, there is a plan to incorporate the Terms and Definitions and References sections into the community GitHub repository.

 

Note: Some elements (Lines, Polygons, and PointClouds) contained in https://github.com/Esri/i3s-spec have been removed from the OGC document because they are currently in Beta and not broadly implemented outside the Esri community. These elements are identified as future work in this OGC document.

 

iii.          Validity of content

The Submission Team has reviewed and certified that the “snapshot” content in this Community Standard is true and accurate.

 

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

All questions regarding this submission should be directed to the editor or the submitters:

 

Name Affiliation

Keith Ryden

Esri

Allan W. Shearer

UT Austin

Volker Coors

Hochschule für Technik Stuttgart

David Graham

CAE

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

 

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 types are planned for future inclusion in the I3S standard (future work):

 

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. A Scene Layer is characterized by a combination of layer type and profile to fully describe the behavior of the layer and the manner in which it is realized within the standard.

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:

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

2.    Conformance

Not Applicable.

3.    References

Normative

OGC SF [99-036/ISO 19125]: Geographic information - Simple feature access - Part 1: Common architecture. 2005. http://portal.opengeospatial.org/files/?artifact_id=13227. May17, 2017.

OGC WKT CRS [12-063r5/ISO 19162:2015]: Geographic information — Well known text representation of coordinate reference systems. 2015 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
          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.4
          faceRanges

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

4.5
          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.6
          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.7
          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.8
          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.9
          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.10
      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.11
      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. 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.12
      Profile

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

4.13
      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.14
      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.15
      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.16
      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.17
      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.18
      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.19
      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.20
      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.21
      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: Support a positive user experience - high interactivity, fast display, support rendering of visually relevant features first;
  2. Scalability: Support very large scene layers, with global extent and large amounts of features - as well as the ability to handle highly detailed features;
  3. Reusability: Be usable both as a service delivery format as well as a storage/exchange format;
  4. Level of Detail: Have intrinsic support for representing level of detail;
  5. Distribution: Allow efficient distribution of very large data sets;
  6. User-controllable symbology: Support client-side symbology/styling and its efficient rendering;
  7. Extensibility: Be extensible to support new layer and geometry types as well as new platforms;
  8. Web Friendliness: Easy to handle and parse by web clients by using JSON and current web standards;
  9. Compatibility: Have a single structure that is usable across a modern platform spanning web, mobile and desktop clients and cloud and on-premises servers;
  10. Declarative: limit how much specific knowledge is needed by clients for format support;
  11. Follow REST/JSON API best practices: “Hypertext as the Engine of Application State” - make all resources navigable using hrefs from relevant other resources.

6.2    I3S – Overview

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. A single I3S data set, referred to as a Scene Layer, is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. I3S Scene Layers are designed to provide clients access to data. Clients have the ability to then visualize the data for the layer independently 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 that fully describes the behavior of the layer and the manner in which it is realized within the specification.

 

The requirements specified below apply to the following layer types defined in this standard:

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 and Points. 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 : 3D Layer Types Supported in I3S
Layer Type (example) Profile Annex Features with Identity Attributes

3D Object

mesh-pyramids

Annex G

Yes

Yes

Integrated Mesh

mesh-pyramids

Annex G

No

Triangle Attributes (planned)

Point

points

Annex f[14]

Yes

Yes

7.    I3S Specification

This section contains the normative clauses and requirements for implementing I3S.

7.1    Coordinate Reference Systems (CRS)[15]

7.1.1    A note on OGC Standards for CRS and Well Known Text

This document refers to two OGC standards for describing a CRS as Well Known Text. The two standards are referred to as WKT1 and WKT2

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:

These use cases lead to the following implementation requirements.

  1. 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 include: EPSG:4326[21]
  2. 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.
  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 reference system via the spatialReference property in the 3dSceneLayerInfo resource. This property is normative.

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) representations, 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.

 


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]]​]
 
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.5.4) for more information.

 

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, with roughly equal amounts of data, and organized into a hierarchical and navigable data structure - the index - that allows the client to quickly discover which data it actually needs and the server to quickly locate the data requested by any client. Node creation is capacity driven - the smaller the node capacity is, typically the smaller the spatial extent of each node will be.

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.

All Nodes have an ID that is unique within a layer. There are two types of Node ID formats supported by I3S: As string based treekeys or as integers based on a fixed linearization of the nodes.

In the treekey format, which is loosely modeled on binary search trees, the key value is used to indicate both the level and sibling association of a given node, the key 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: “3-1-0” has 3 numeric elements, hence the node is on level 4 (“root” node is at level 1) and the node “3-1” is its parent. The root node always gets ID “root”. An example of this numbering pattern is shown in Figure 1 below.

A Sample Index Tree with Treekeys
Figure : A Sample Index Tree with Treekeys

The information for a node is stored in multiple individually accessible resources. The node index document is a lightweight resource that captures the BVH tree topology for the node, in addition to the node’s bounding volume and meta-data used for [LoD Switching] (LoD Switching Models) metrics. This 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 the node is based on node’s bounding-volume visibility in the current 3D view and a visual quality determination made by the client 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 spheres (MBS) and oriented bounding boxes (OBB) as a node’s bounding volume.

Each interior node logically contains or covers the set of information covered by the nodes below it and participates in a path to the leaf nodes below it. Interior nodes may contain generalized or reduced representation of the information contained in descendant nodes.

The I3S format models node information using a set of resources - Node Index Documents, Feature Data, Geometry, Attributes, Textures and Shared Descriptors, all of which together represent the set of features or data elements for a given node. These resources are always attached to a node.

An I3S profile can choose between 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 accessing the latter do not need to first fetch the feature-data resource in order to interpret them.

Nodes and their attached resources
Figure : Nodes and their attached resources

Per node, there is exactly one Node Index Document and one Shared Descriptors resource document. FeatureData, Geometry, Texture and Attribute resources can be split into bundles for optimal network transfer and client-side reactivity. This allows balancing between index size, feature splitting (with a relatively large node capacity between 1MB and 10MB) and optimal network usage (with a smaller bundle size, usually in the range of 64kB to 512kB).

There are always an equal number n of FeatureData and Geometry resources, and each set contains the corresponding data elements to be able to render a complete feature. Optimal access to all required properties of the geometry data, including the feature to geometry mapping, is available directly from the binary geometry data resource, avoiding unnecessary dependency on the FeatureData document. All vertexAttributes (including position, normal, texture coordinates and color), vertex and feature counts, and mesh segmentation information (faceRanges) are also readily accessible from the geometry resource.

This diagram illustrates the content of an I3S node as stored in its node index document
Figure : This diagram illustrates the content of an I3S node as stored in its node index document

Figure 4 below shows the node tree of an Indexed Scene Layer whose layer type is 3D Object and whose profile is mesh-pyramids. In the figure:

Example Nodes in a Mesh Pyramid
Figure : Example Nodes in a Mesh Pyramid

Figure detail:Orange boxes represent features stored explicitly within the node, the numbers represent feature identifiers. Turquoise boxes represent the geometry instances associated with each node – each geometry instance is an aggregate geometry (a geometry collection) that covers all the features in the node. Blue boxes represent the node ids, the hyphenated numbers represent node ids as string based treekeys.

7.3.2    Geometry Model and Storage

All Scene Layer types make use of the same fundamental set of geometry types:

Geometries use binary storage and consumption representation, controlled by Array Buffer View[26] geometry property declarations. I3s provides full control over those properties, such as per-vertex layout of components (e.g. position, normal and texture coordinates), in order to ensure the same pattern for face and vertex elements across the Scene Layer.

I3S supports storage of triangle meshes via triangles geometry type.

Both 3D Object as well as Integrated Mesh layer type model geometries as triangle meshes using the mesh-pyramids profile. The mesh-pyramids profile uses the triangles geometry type to store triangle meshes with reduced level of detail representations of the mesh, segmented by features, available in the interior nodes as described above.

See Geometry section for more discussion on the geometry format and storage models.

7.3.3    Textures

Textures are stored as a binary resource associated with a node. The texture resource for a node contains the images that are used as textures for the features stored in the node. The mesh-pyramids profile supports either a single texture or a texture atlas per node.

By default, the mesh-pyramids profile allows/supports encoding the same texture resource in multiple formats, catering for bandwidth, memory consumption and optimal performance consideration on different platforms. As a result, the I3S standard supports most commonly used image formats such as JPEG/PNG as well as rendering optimized compressed texture formats such as S3TC[27]. In all cases, the standard provides flexibility by allowing authoring applications to provide additional texture formats via the textureEncoding declarations that use MIME types. For example, most existing I3S services provide “image/vnd-ms.dds” (for S3TC compressed texture) in addition to the default “image/jpeg” encoding.

See Textures section for more on texture format, texture coordinate, texture atlas usage and regions discussion.

7.3.4    Attribute Model and Storage

I3S supports the following two patterns of accessing the attribute data:

  1. From optional paired services that expose query-able and updatable RESTful endpoints that enable direct access to dynamic source data, including attributes. The query in this case uses the unique feature-ID key – which is always maintained within each node and is also available as part of the descriptor for any segmented geometry.
  2. From fully cached attribute information, in binary form, within I3S store. I3S clients can still choose to use both of these modes even if the attributes are fully cached within I3S store.

Cached Attributes use a binary storage representation based on Array Buffers which provide significant performance benefits relative to method 1. The attribute values are stored as a geometry aligned, per field (column), key-value pair arrays.

See Attribute Data section for more on texture format, texture coordinate, texture atlas usage and regions discussion.

7.4    Level of Detail Concept

The concept of Level of Detail (LoD) is intrinsic to the I3S standard. Scene Layers may include levels of detail that apply to the layer as whole and serve to generalize or summarize information for the layer, similar to image pyramids and also similar to raster and vector tiling schemes. A node in the I3S scene layer tree could be considered the analog of a tile in a raster or vector tiling scheme. Scene layers support levels of detail in a manner that preserves the identity of the individual features that are retained within any level of detail.

The I3S Level of Detail model covers several use cases, including, splitting up very heavy features such as detailed building or very large features (coastlines, rivers, infrastructure), thinning/clustering for optimized visualization as well as support for representing externally authored multiple LoDs.

Note that the I3S Level of Detail concept is orthogonal to the concept of consolidated storage for a set of geometries within a level of detail, based on for example, the concatenation of geometries/meshes into larger geometry collections/meshes to assist in optimal rendering. In all such cases the consolidated storage makes use of Geometry Array Buffers that provide access to individual geometries when needed, and include the preservation of feature to geometry element mapping within the consolidated geometries.

7.4.1    Discrete LoDs

I3S supports a Discrete LoD approach, where different Level of Details are bound to the different levels of the index tree. Typically, leaf nodes of such LoD schema contain the original (feature/object) representation with the highest detail. The closer nodes are to the root, the lower the level of detail will be. For each next lower level, the amount of data is typically reduced by employing methods such as texture down-sampling, feature reduction/generalization, mesh reduction/generalization, clustering or thinning, so that all inner nodes also have a balanced weight. Generalization applies to the Scene Layer as a whole and the number of discrete levels of detail for the layer corresponds to the number of levels in the index tree for the scene layer. Here, the level of detail concept is analogous to the level of detail concepts for image pyramids as well as for standard raster and vector tiling schemes.

During navigation and traversal of the I3S tree nodes, clients must decide to either:

  1. Discontinue traversal to node’s children if the node is not visible in the current 3D view; or
  2. Use/render the data within a node if its quality is appropriate to the current 3D view and discontinue further traversal to children nodes; or to
  3. Continue traversal until children nodes with better quality are found.

These decisions are made using the advertised values for LoD selection metrics that are part of the information payload of the node. The I3S standard describes multiple LoD Selection Metrics and permits different LoD Switching Models. An example LoD selection metric is the maximum screen size that the node may occupy before it must be replaced with data from more detailed nodes. This model of discrete LoD rendering (LoD Switching Model) is referred to in I3S as node-switching.

I3S Scene Layers also include additional optional metadata on the LoD generation process (e.g. thinning, clustering and generalization) as non-actionable (to clients) information that is of interest to some service consumers.

7.4.2    Representation of input data that already has explicitly authored multiple representations

I3S Layers can be used to represent input 3D geographic data that already have multiple, semantically authored, levels of detail.

The most common method for doing so is to represent each semantically authored input level of detail as its own I3S Layer with visibility thresholds on the layer that capture the range of distances (from the 3D location of the camera) at which the layer should be used. At further or closer distances applications switch to using a different I3S layer representing a different input semantically authored level of detail. The set of such I3S Layers representing a single modeled, real world phenomena (such as buildings for a city) can be grouped within the same I3S service. For each I3S Layer within the set, the features in the leaf nodes of the index tree represent the modeled features at the level of detail presented in the input. Additional automatically generated levels of detail can optionally be generated extending the viewing range of each semantically input level of detail if so desired.

Tools can also be developed that load all of the input level of detail information for the modeled entities in the input into a single I3S layer. In this case the height of the I3S index tree is fixed to the number of levels of detail present in the input and both the feature identities and geometries in each node are set based upon the input data.

The specific approach taken is influenced by the extent of the data, the number of levels of detail actually present in the input and the need for further additional automatically generated levels of detail.

7.4.3    LoD Switching Modes

Depending on the properties of a 3D layer, a good user experience will necessitate switching out the content for a node with the content of more detailed nodes.

7.4.3.1    Node Switching

Node switching means that the content (features, geometry, attributes, textures) from child nodes is loaded to replace the content of an existing node as the user needs to be presented with more detailed information

As shown in Figure 4 above, each interior node in the I3S tree has a set of features that represent the reduced LoD representation of all of the features covered by that interior node. Not all features may be present in reduced LoD nodes. Omission of a feature at a reduced LoD node indicates that the entire feature has been intentionally generalized away at this level of detail.

The correspondence between a reduced LoD feature in an interior node and the same feature in descendant (children) nodes is based on by feature IDs which are a key part of the storage model. Applications accessing the I3S tree can display all of the features in an internal node and stop there or instead descend further and use the features found in its child nodes, based on desired quality.

The main advantage of this mechanism is that clients can focus on the display criterion associated with nodes as a whole in making the decision to switch representations. node-switching is the default LoD Switching model for layer types that implement the Mesh-pyramids profile.

7.4.4    Levels of Detail – Generation

Integrated Mesh layer types typically come with pre-authored Levels of Detail. For input data that does not come with pre-authored LoDs, different LoD generation models can be employed. For example, 3D Object layers based on the Mesh-pyramids profile may choose to create an LoD pyramid for all features based on generalizing, reducing and fusing the geometries (meshes) for individual features while preserving feature identity. The same approach can also be used with Integrated Mesh layers based on the mesh-pyramid profile - in this case there are no features and each node contains a generalized version of the mesh covered by its descendants.

The first step in the automatic LoD generation process is to build the I3S bounding volume tree hierarchy based on the spatial distribution of the 3D features. Once this has been completed generation of the reduced LoD content for interior nodes can proceed.

As shown in Table 2 below, different models of LoD generation are applicable to different 3D layers.

Table : 3D Layer Types and models of LoD generation they can employ

3D Object

Points

Mesh-pyramids

yes

Thinning

yes

yes

Clustering

yes

yes

Generalization

yes

 

7.4.5    LoD Selection Metrics

A client needs information to determine whether a node’s contents are “good enough” to render in the current 3D view under constraints such as resolution, screen size, bandwidth and available memory and target minimum quality goals. Multiple LoD selection metrics can be included, as in the following example:


“lodSelection”: [
    {
        “metricType”: “maxScreenThreshold”,
        “maxError”: 486.00
    },
    {
        “metricType”: “screenSpaceRelative”,
        “maxError”: 0.0034 
    },
    {
        “metricType”: “distanceRangeFromDefaultCamera”,
        “maxError”: 750.00 
    }
]

These metrics are used by clients to determine the optimal resource access patterns. Each I3S profile definition provides additional details on LoD Selection.

maxScreenThreshold, the default lodSelection metric used for meshpyramids profile, is a per-node value for the maximum pixel size as measured in screen pixels. This value indicates the upper limit for the screen size of the diameter of the node’s minimum bounding sphere (MBS). In other words, the content referenced by this node will qualify to be rendered only when the screen size is below the maximum screen threshold value.

7.5    JSON Resources Schema and Documentation

This section provides a detailed, logical-level specification for each of the resource types.

7.5.1    Basic Value Types

Value schemas are used to ensure that the content of a JSON property follows a fixed pattern. The set of schemas that currently need to be supported iare

7.5.2    Pointers

I3S uses the following Pointer syntax whenever a specific property in the current or another document is to be referenced. The Pointer consists of two elements:

mandatory in-document reference: Relative to the currently evaluated property, or document absolute, reference to a property. References are always slash-separated paths through a document tree and can contain wildcards (\*) to indicate that a set or list of properties is to be matched instead of a single property.

Absolute references start with a slash (/). Absolute references may only contain upstream path elements, i.e. they may only point to properties of objects enclosing the property that is being evaluated and indicated by a name.

Relative references start with a property key (e.g. type). Relative properties may only contain downstream path elements and are evaluated from the value being tested. They may not contain wildcards, as appropriate context is already given through the current element being evaluated. In the case of a property that has containerType set to Array or Object, the reference point for a relative path is the individual value element in the container.

optional URL: The pointer may be prefixed with a URL to a different document. This URL may be relative to the document that is being evaluated or absolute. To identify the URL element of a pointer, it is given in square brackets. Examples:

7.5.3    SceneServiceInfo

The SceneServiceInfo file is a JSON file that describes the capability and data sets offered by an instance of a Scene Service. A Scene Service is a web service that provides access to 3D available in some data store in which 3D content has been authored and is ready for publication (visualization). The SceneServiceInfo has the following structure:

Logical Schema of the 3dSceneServiceInfo document
Figure : Logical Schema of the 3dSceneServiceInfo document

This file is automatically generated by a Scene Server for each service instance and is not part of a scene layer package file. It is included here only for reference.

7.5.3.1    Class SceneServiceInfo

SceneServiceInfo is the major object in the 3dSceneServiceInfo document. There SHALL always be exactly one SceneServiceInfo object in the document, which describes a running SceneService instance.

Table : Attributes of Class SceneServiceInfo within SceneServiceInfo document
Name Type Description

serviceName

String

The type of the service; always SceneService.

serviceVersion

String

The version of the service protocol/REST endpoint.

supportedBindings

String[1..*]

the list of bindings, should we ever need to add new bindings in addition to the REST binding initially supported

supportedOperations

String[1..3]

Supported profiles of the service from the choice {Base, Dynamic, Editing}.

layers

3dSceneLayerInfo[1..*]

The full 3dSceneLayerInfo information.

 

7.5.4    3dSceneLayerInfo

The Class 3dSceneLayerInfo describes the properties of a single layer in a store, including the default symbology to use. It shares the definition of this default symbology with the drawingInfo object, an object which contains styling information for a feature layer, and is specified as part of a web scene specification. For more information on web scene objects, including the drawingInfo object see Clause 7.5.4.8. The Class 3dSceneLayerInfo has the following structure:

Logical schema of the 3dSceneLayerInfo document
Figure : Logical schema of the 3dSceneLayerInfo document

7.5.4.1    Class 3dSceneLayerInfo

The 3dSceneLayerInfo is a major object in the 3dSceneLayerInfo document. A SceneServiceInfo document can contain 1…* 3dSceneLayerInfo documents. Each 3dSceneLayerInfo object describes a Layer.

Table : Attributes of the Class 3dSceneLayerInfo within the 3dSceneLayerInfo document
Name Type Description

id

Integer

Unique numeric ID of the Layer.

href

URL

The relative URL to the 3dSceneLayerResource. Only present as part of the SceneServiceInfo resource.

layerType

String

The user-visible type of this layer, one of {Point, *3DObject*, IntegratedMesh}

spatialReference

spatialReference

The spatialReference of the layer including the vertical coordinate reference system. wkt is included to support custom spatial references. {wkid, latestWkid, vcsWkid, latestVcsWkid, wkt}

heightModelInfo

heightModelInfo

Enables consuming clients to perform quick test to determine whether this layer is compatible (with respect to its horizontal and vertical CRS) with existing content.{heightModel, geoid, heightUnit}

version

String

The ID of the last update session in which any resource belonging to this layer has been updated.

name

String

The name of this layer.

alias

String[0..1]

The display alias to be used for this layer.

description

String[0..1]

Description string for this layer.

copyrightText

String[0..1]

Copyright and usage information for the data in this layer.

capabilities

String[1..3]

Capabilities from the Set {View, Query, Edit} that are possible on this layer.

cachedDrawingInfo

cachedDrawingInfo

Indicates if any stylization information represented as drawingInfo is additionally captured as part of the binary mesh representation for optimal client side access. Currently color component of the drawingInfo is supported.

drawingInfo

drawingInfo

Represents the stylization information of the layer.

fields

fields

A collection of objects that describe each attribute field regarding its field name, datatype and a user friendly name {name,type,alias}. It includes all fields that are included as part of the I3S layer as derived from a source input feature layer.

attributeStorageInfo

attributeStorageInfo

Provides the schema and layout used for storing attribute content in binary format in I3S.

 

7.5.4.2    Class Store

The Class Store object describes the exact physical storage of a Layer and enables the client to detect when multiple Layers are served from the same Store. Storing multiple layers in a single store - and thus having them share resources - enables efficient serving of many layers of the same content type, but with different attribute schemas or different symbology applied.

Table : Attributes of the Class Store within the 3dSceneLayerInfo document
Name Type Description

id

UUID

A Store ID, unique across a SceneServer. Enables the client to discover which layers a part of a common store, if any.

profile

String

Indicates which profile this scene store fulfills. One of {meshes, points, analytics, meshpyramids, symbols}.

resourcePattern

String [1..5]

Indicates the resources needed for rendering and the required order in which the client should load them. Each value is one of {3dNodeIndexDocument, SharedResource, FeatureData, Geometry, Texture}.

rootNode

URL

Relative URL to root node resource.

version

String

Format version of this resource; used here again if this store hasn't been served by a 3D Scene Server.

extent

Float[4]

The 2D spatial extent (xmin, ymin, xmax, ymax) of this store, in the horizontal indexCRS

indexCRS

URL

The horizontal CRS used for all minimum bounding spheres (mbs) in this store, identified by an OGC URL.

vertexCRS

URL

The horizontal CRS used for all "vertex positions" in this store, identified by an OGC URL.

normalReferenceFrame

 

String

Describes the coordinate reference frame used for storing normals. One of {east-north-up, *earth-centered*, vertex-reference-frame}.

A value of *east-north-up* indicates that normals are stored in a node local reference frame defined by the easting, northing and up directions at the MBS center, and is only valid for geographic (WGS84) vertexCRS. A value of *earth-centered* indicates that normals are stored in a global earth-centered, earth-fixed (ECEF) reference frame where the x-axis points towards Prime meridian (lon = 0°) and Equator (lat = 0°), the y-axis points East towards lon = +90 and lat = 0 and the z-axis points North. It is only valid for geographic vertexCRS. A value of *vertex-reference-frame* indicates that normals are stored in the same reference frame as vertices and is only valid for projected vertexCRS.

 

nidEncoding

MIMEType

MIME type for the encoding used for the Node Index Documents; format:
application/vnd.ogc.I3S.json+gzip; version=1.6

featureEncoding

MIMEType

MIME type for the encoding used for the Feature Data Resources; format:
application/vnd.ogc.I3S.json+gzip; version=1.6

geometryEncoding

MIMEType

MIME type for the encoding used for the Geometry Resources; format:
application/octet-stream; version=1.6

textureEncoding

MIMEType[1..*]

MIME type(s) for the encoding used for the Texture Resources

lodType

String

optional field to indicate which LoD Generation Scheme is used in this store. One of {*MeshPyramid*, Thinning, Clustering, Generalizing}.

lodModel

String

optional field to indicate which LoD Switching mode clients have to use. One of {*node-switching*, none}.

indexingScheme

IndexScheme

Information on the Indexing Scheme (QuadTree, R-Tree, Octree, ...) used.

defaultGeometrySchema

GeometrySchema[0..1]

A common, global ArrayBufferView definition that can be used if the schema of vertex attributes and face attributes is consistent in an entire cache; this is a requirement for meshpyramids caches.

defaultTextureDefinition

TextureDefinition[0..1]

A common, global TextureDefinition (see SharedResources) to be used for all textures in this store. The default texture definition uses a reduced profile of the full TextureDefinition, with the following attributes being mandatory: encoding, uvSet, wrap and channels.

defaultMaterialDefinition

MaterialDefinition[0..1]

If a store uses only one material, it can be defined here entirely as a MaterialDefinition (see SharedResources).

 

7.5.4.3    Class GeometryStore

This class is used in stores where all ArrayBufferView geometry declarations use the same pattern for face and vertex elements. This effectively reduces redundancies of ArrayBufferView geometry declarations in a store. Reuses the GeometryAttribute type from FeatureData. However, valueType and valuesPerElement are mandatory and SHALL be implemented.

Table : Attributes of the Class GeometrySchema within the 3dSceneLayerInfo document
Name Type Description

geometryType

String

Low-level default geometry type, one of {triangles, lines, points}; if defined, all geometries in the store are expected to have this type.

topology

String[0..1]

one of {*PerAttributeArray*, Indexed}. When "Indexed", the indices must also be declared in the geometry schema ("faces") and precede the vertexAttribute data.

header

HeaderAttribute[0..\*]

Defines header fields in the Geometry resources of this store that precede the vertex (and index) data

ordering

String[1..\*]

Provides the order of the keys in vertexAttributes and faceAttributes, if present.

vertexAttributes

FeatureData::GeometryAttribute[1..\*]

Declaration of the attributes per vertex in the geometry, such as position, normals or texture coordinates

faces

FeatureData::GeometryAttribute[0..\*]

Declaration of the indices into vertex attributes that define faces in the geometry, such as position, normals or texture coordinates

featureAttributeOrder

String[1..\*]

Provides the order of the keys in featureAttributes, if present.

featureAttributes

FeatureData::GeometryAttribute[0..\*]

Declaration of the attributes per feature in the geometry, such as feature ID or face range

7.5.4.4    Class HeaderAttribute

Headers to Geometry resources SHALL be uniform across a cache and may only contain fixed-width, single element fields. The HeaderDefinition provides the name of each field for later access and the valueType of that header field.

Table : Attributes of the Class HeaderAttribute within the 3dSceneLayerInfo document
Name Type Description

property

String

The name of the property in the header

type

String

The element type of the header property, from {UInt8, UInt16, UInt32, UInt64, Int16, Int32, Int64 or Float32, Float64}

7.5.4.5    Class Field

The Field class is used to provide schema information for this 3dSceneLayer.

Table : Attributes of the Class Field within the 3dSceneLayerInfo document
Name Type Description

name

String

The name of the field.

type

String

The type of the field, from this enum: {FieldTypeBlob, FieldTypeGeometry, FieldTypeDate, FieldTypeFloat, FieldTypeDouble, FieldTypeGeometry, FieldTypeGlobalID, FieldTypeGUID, FieldTypeInteger, FieldTypeOID, FieldTypeSmallInteger, FieldTypeString, FieldTypeGroup}

alias

String[0..1]

The display alias to be used for this field.

 

7.5.4.6    Class attributeStorageInfo

The attributeStorageInfo is another major object in the 3dSceneLayerInfo document. This is an object that describes the structure of the binary attributeData resource of a node.

Table : Attributes of the Class attributeStorageInfo within the 3dSceneLayerInfo document
Name Type Description

key

string

The unique field identifier key.

name

string

The name of the field.

header

String[1..\*]

Declares the headers of the binary attribute data. One of {count, attributeValuesByteCount}. count, should always be present and indicates the count of features in the attribute storage. attributeValuesByteCount will only be present for strings data type and indicates the total byte count of the string data for all features in the binary attribute buffer.

ordering

String[1..*\]

Declares the ordering indicating the order in which the array of attribute byte counts and the array of attribute values are stored in the binary attribute data. One of {attributeByteCounts, attributeValues}. attributeValues, should always be present. attributeByteCounts should only be present when working with string data types.

attributeByteCounts

String

The element type of the attributeByteCounts property, from {UInt32}.

attributeValues

String

The element type of the attributeValues property, from {UInt8, UInt16, UInt32, UInt64, Int16, Int32, Int64 or Float32, Float64}

7.5.4.7    Class IndexScheme

The IndexScheme class declaratively describes computational and structural properties of the index used within an I3S store. This information can be used by clients to better understand how to work with the index.

Table : Attributes of the Class IndexScheme within the 3dSceneLayerInfo document
Name Type Description

name

String

Name of the scheme, selected from {RTree, QuadTree, AGOLTilingScheme}.

inclusive

Boolean

true indicates that the extent and mbs of all children nodes is fully within their parent nodes' extent/mbs

dimensionality

Integer

The number of dimensions in which this index differentiates.

childrenCardinality

Integer[2]

min/max number of children per node.

neighborCardinality

Integer[2]

min/max number of neighbors per node.

 

7.5.4.8    Class DrawingInfo

DrawingInfo and the associated classes contain the default symbology (drawing information) of an Indexed 3D Scene Layer. When the DrawingInfo object is present in the 3dSceneLayerInfo Class, a client application may symbolize an I3S layer by utilizing the *Renderer* information. Indexed 3d Scene Layers also supports capturing the DrawingInfo object as part of the binary I3S representation This is to support applications that may not be able to dynamically symbolize/override a given I3S layer based on its drawing information. Such a behavior, when present, is indicated by the CachedDrawingInfo Class, indicating the component of the DrawingInfo object that’s captured as part of the binary I3S representation. The Class DrawingInfo has the following structure:

 

Table : Attributes of the Class CachedDrawingInfo within the 3dSceneLayerInfo document
Name Type Description

renderer

DrawingInfo::Renderer

The renderer object encapsulates the drawing information of the layer.

7.5.4.8.1    Class Renderer

The Renderer class contains properties that define the drawing symbology of an Indexed 3D Scene Layer, including its type, symbol and any label or descriptions associated with it.

The Class Renderer has the following structure:

 

Table : Attributes of the Class Renderer within the 3dSceneLayerInfo document
Name Type Description

type

String

The renderer type. One of {\*Simple\*, UniqueValue, ClassBreaks}. The default, simple renderer is a renderer that uses one symbol only.

symbol

Renderer::Symbol

An object that represents how all features of this I3S layer will be drawn.

label

String

The text string that may be used to label a symbol when displayed in a table of content of an application.

description

String

The text string that does not appear in the table of contents but may appear in the legend.

7.5.4.8.2    Class Symbol

The Class Symbol represents the render primitive used to symbolize an Indexed 3D Scene Layer. MeshSymbol3D is the only supported type of Symbol.

The Class Symbol has the following structure:

Table : Attributes of the Class Symbol within the 3dSceneLayerInfo document
Name Type Description

type

String

Specifies the type of symbol used. Value of this property must be {\*MeshSymbol3D\*}.

symbolLayers

Renderer::SymbolLayers

An object that represents how all features of this I3S layer will be drawn.

7.5.4.8.3    Class SymbolLayers

A Collection of symbol objects used to visualize the feature.

The Class SymbolLayers has the following structure:

 

Table : Attributes of the Class SymbolLayers within the 3dSceneLayerInfo document
Name Type Description

type

String

Specifies the type of symbol used. Value of this property must be {\*Fill\*}.

material

SymbolLayers::Material

The material used to shade the geometry.

outline

SymbolLayers::Outline

The outline of the mesh fill symbol.

7.5.4.8.4    Class Material

The material used to shade the geometry.

The Class Material has the following structure:

 

Table : Attributes of the Class Material within the 3dSceneLayerInfo document
Name Type Description

color

Material::Color

Color is represented as a three-element array (RGB).

transparency

Integer

Indicates the transparency value associated with the symbol. The value has to lie between 100 (full transparency) and 0 (full opacity).

7.5.4.8.5    Class Outline

The Class Outline defines the outline of the mesh fill symbol. It has properties such as color, size and transparency.

The Class Outline has the following structure:

 

Table : Attributes of the Class Material within the 3dSceneLayerInfo document
Name Type Description

color

Material::Color

Color is represented as a three-element array. The three elements represent values for red, green and blue in that order.

size

Integer

Outline size in points, positive only.

transparency

Integer

Indicates the transparency value associated with the outline of the symbol. The value has to lie between 100 (full transparency) and 0 (full opacity).

7.5.4.8.6    Class Color

The Color class defines the color of a symbol or the outline. Color is represented as a three-element array. The three elements represent values for red, green and blue in that order. Values range from 0 through 255. If color is undefined for a symbol or an outline, the color value is null.

The Class Color has the following structure:

 

Table : Attributes of the Class Color within the 3dSceneLayerInfo document
Name Type Description

color

String

The renderer type. One of {\*Simple\*, UniqueValue, ClassBreaks}. The default, simple renderer is a renderer that uses one symbol only.

symbolLayers

Renderer::Symbol

An object that represents how all features of this I3S layer will be drawn.

7.5.4.8.7    Class CachedDrawingInfo

The Class CachedDrawingInfo is used to indicate if the DrawingInfo object is captured as part of the binary I3S representation.

The Class CachedDrawingInfo has the following structure:

 

Table : Attributes of the Class CachedDrawingInfo within the 3dSceneLayerInfo document
Name Type Description

color

Boolean

Indicates if the color component of the drawingInfo object is captured as part of the binary I3S representation.

7.5.5    3dNodeIndexDocument

The 3dNodeIndexDocument JSON file describes a single index node within a store, with links to other nodes (children, sibling, and parent), links to feature data, geometry data and texture data resources, metadata such as metrics used for LoD selection, and its spatial extent.

Depending on the geometry and lodModel used, a node document can be tuned towards being light-weight or more heavy-weight. This is the means by which clients have to further decide which data to retrieve. The bounding volume information provided for the node, its parent, any neighbors and children present, already provides sufficient data for simple visualization by rendering the centroids as point features for example.

The 3dNodeIndexDocument has the following structure:

Logical schema of the 3dNodeIndexDocument
Figure : Logical schema of the 3dNodeIndexDocument

7.5.5.1    Class Node

The Node is the root object in the 3dNodeIndexDocument. There SHALL always be exactly one Node object in a 3dNodeIndexDocument.

Table : Attributes of the ClassNode within the NodeIndexDocument
Name Type Description

id

String (TreeKey)

Tree Key ID, unique within the store. The root node is always "root", all others follow the pattern "2-4-0-15-2". At each level in a subtree, numbering starts at 0.

level

Integer

Explicit level of this node within the index tree. The lowest level is 1.

version

UUID

The version (store update session ID) of this node.

mbs

Float[4]

An array of four doubles, corresponding to x, y, z and radius of the minimum bounding sphere of a node.

created

Date[0..1]

Creation date of this node in UTC, presented as a string in the format YYYY-MM-DDThh:mm:ss.sTZD, with a fixed "Z" timezone (see http://www.w3.org/TR/NOTE-datetime).

expires

Date[0..1]

Expiration date of this node in UTC, presented as a string in the format YYYY-MM-DDThh:mm:ss.sTZD, with a fixed "Z" timezone (see http://www.w3.org/TR/NOTE-datetime).

transform

Float[16]

Optional, 3D (4x4) transformation matrix expressed as a linear array of 16 values.

parentNode

NodeReference[0..1]

Reference to the parent Node of a Node.

children

NodeReference[0..*]

Reference to the child Nodes of a Node.

neighbors

NodeReference[0..*]

Reference to the neighbor (same level, spatial proximity) Nodes of a Node.

sharedResource

Resource[0..1]

Resource reference describing a shared resource document.

featureData

Resource[0..*]

Resource reference describing a FeatureData document.

geometryData

Resource[0..*]

Resource reference describing a geometry resource.

textureData

Resource[0..*]

Resource reference describing a texture resource.

lodSelection

LodSelection[0..*]

Metrics for LoD Selection, to be evaluated by the client.

features

Feature[1..*]

A list of summary information on the features present in this Node, used for pre-visualisation and LoD switching in featureTree LoD stores.

7.5.5.2    Class NodeReference

A NodeReference is a pointer to another node - the parent, a child or a neighbor. NodeReferences contain a relative URL pointing to the referenced NID, as well as a set of meta information that can be used by the client to determine whether to load that node or not, as well as maintaining store consistency.

Table : Attributes of the Class NodeReference within the NodeIndexDocument

Name

Type

Description

id

String

Tree Key ID (e.g. "1-3-0-5") of the referenced node.

mbs

Float[4]

An array of four doubles, corresponding to x, y, z and radius of the minimum bounding sphere of the referenced node.

href

URL

The relative URL to the referenced node resource.

version

UUID

Version (store update session ID) of the referenced node.

featureCount

Integer

Number of features in the referenced node and its descendants, down to the leaf nodes.

7.5.5.3    Class Resource

Resource objects are pointers to different types of resources related to a node, such as the feature data, the geometry attributes and indices, textures and shared resources.

Table : Attributes of the Class Resource within the NodeIndexDocument
Name Type Description

href

String

The relative URL to the referenced resource.

layerContent

String[1..*]

The list of layer names that indicates which layer features in the bundle belongs to. The client can use this information to selectively download bundles.

featureRange

Integer[2]

Only applicable for featureData resources. Provides inclusive indices of the features list in this node that indicate which features of the node are located in this bundle.

multiTextureBundle

Boolean

Only applicable for textureData resources. true if the bundle contains multiple textures. If false or not set, clients can interpret the entire bundle as a single image.

vertexElements

Integer[0..1]

Only applicable for geometryData resources. Represents the Count of elements in vertexAttributes; multiply by the sum of bytes required for each element as defined in the defaultGeometrySchema.

faceElements

Integer[0..1]

Only applicable for geometryData resources. Represents the Count of elements in faceAttributes; multiply by the sum of bytes required for each element as defined in the defaultGeometrySchema.

7.5.5.4    Class Feature

Features are representations of the geographic objects stored in a layer. In the 3dNodeIndexDocument, these objects define relationships, e.g. for linking feature representations of multiple LoDs.

Table : Attributes of the Class Feature within the NodeIndexDocument
Name Type Description

id

Integer

An ID of the Feature object, unique within the store (important to note when using Features from multiple stores!). The ID SHALL not be re-used e.g. for multiple representation of an input feature that are present in different nodes.

mbs

Float[4]

An array of four doubles, corresponding to x, y, z and radius of the minimum bounding sphere of the referenced node.

lodChildFeatures

Integer[0..*]

IDs of features in a higher LoD level which together make up this feature.

lodChildNodes

String[0..*]

Tree Key IDs of the nodes in which the lodChildFeatures are found

rank

Integer[0..1]

The LoD level of this feature. Only required for features that participate in a LoD tree. The lowest rank SHALL be 1.

rootFeature

String

The Tree Key ID of the root node of a feature LoD tree that this feature participates in. Only required if the feature participates in a LoD tree and if it is not the rootFeature itself.

7.5.5.5    Class LodSelection

A LodSelection object provides information on a given metric determined during the cooking process of an I3S store. This metric can be used by the client to determine whether a representation is of the right quality level for rendering or whether a different representation is needed.

Publishers (aka “cookers”) can add as many LodSelection objects as desired but must provide one as soon as the layer’s lodType is not null. Of the three min/avg/max values, typically only one or two are used.

Table : Attributes of the Class LodSelection within the NodeIndexDocument
Name Type Description

metricType

String

The name of the error metric, one of {maxScreenThreshold, screenSpaceRelative, ...}

maxValue

Float[0..1]

Maximum metric value, expressed in the CRS of the vertex coordinates or in reference to other constants such as screen size

avgValue

Float[0..1]

Average metric value, expressed in the CRS of the vertex coordinates or in reference to other constants such as screen size

minValue

Float[0..1]

Minimum metric value, expressed in the CRS of the vertex coordinates or in reference to other constants such as screen size

 

7.5.6    FeatureData

The FeatureData JSON file(s) contain geographical features with a set of attributes, accessors to geometry attributes and other references to styling or materials. Features have the following structure:

Logical schema of the FeatureData document
Figure : Logical schema of the FeatureData document

7.5.6.1    Class Feature

A Feature is a single object within a geospatial data set, usually representative of a feature present in the real, geographic world.

Table : Attributes of the Class Feature within the FeatureData document
Name Type Description

id

Integer

Feature ID, unique within the Node. If lodType is FeatureTree, the ID SHALL be unique in the store.

position

Float[2..3]

An array of two or three doubles, giving the x,y(,z) (easting/northing/height) position of this feature's minimum bounding sphere center, in the vertexCRS.

pivotOffset

Float[3]

An array of three doubles, providing an optional, "semantic" pivot offset that can be used to, for example, correctly drape tree symbols.

mbb

Float[6]

An array of six doubles, corresponding to xmin, ymin, zmin, xmax, ymax and zmax of the minimum bounding box of the feature, expressed in the vertexCRS, without offset. The mbb can be used with the Feature’s Transform to provide a LOD0 representation without loading the GeometryAttributes.

layer

String

The name of the Feature Class this feature belongs to.

attributes

FeatureAttribute[0..*]

The list of attributes for this feature.

geometries

Geometry[1..*]

The list of geometries the feature has. A feature always SHALL have at least one Geometry.

7.5.6.2    Class FeatureAttribute

A FeatureAttribute is a field carrying a value. This value may also be a list of complete attributes, to be used with reports or metadata.

Table : Attributes of the Class FeatureAttribute within the FeatureData document
Name Type Description

name

String

The name of the attribute.

value

String

The value of the attribute. If group is set and the type of this attribute is set to FieldTypeGroup, the value may be used as a label.

group

FeatureAttribute[0..*]

A list of FeatureAttributes belonging to an attribute value group.

7.5.6.3    Class Geometry

This is the common container class for all types of I3S geometry definitions.

Table : Attributes of the Class Geometry within the FeatureData document
Name Type Description

id

Integer

Reference-able, unique ID of the Geometry in this store.

type

String

The type denotes whether the following geometry is defined by using array buffer views (ArrayBufferView), as an internal reference (GeometryReference), as a reference to a shared Resource (SharedResourceReference) or embedded (Embedded).

transformation

Float[16]

3D (4x4) transformation matrix expressed as a linear array of 16 values.

params

GeometryParams

The parameters for a geometry, as an Embedded GeometryParams object, an ArrayBufferView, a GeometryReference object, or a SharedResourceReference object.

7.5.6.4    Class GeometryParams

This is the abstract parent class for all GeometryParams classes (GeometryReferenceParams, VestedGeometryParamas, SingleComponentParams). It does not have properties of its own.

7.5.6.5    Class GeometryReferenceParams

Instead of owning a Geometry exclusively, a Feature can also reference a (or part of a) Geometry defined for the node. This allows to pre-aggregate Geometries for many features. In this case, a GeometryReferenceParams has to be used.

Table : Attributes of the Class GeometryReferenceParams within the FeatureData document
Name Type Description

$ref

Pointer

In-document absolute reference to full geometry definition (Embedded or ArrayBufferView) using the I3S json pointer syntax.

faceRange

Integer[2]

Inclusive range of faces in this geometry that belongs to this feature.

lodGeometry

Boolean

True if this geometry participates in a LoD tree. This value SHALL always be true for the mesh-pyramids profile.

7.5.6.6    Class VestedGeometryParams

This Class extends GeometryParams and is the abstract parent class for all concrete (“vested”) GeometryParams classes that directly contain a Geometry definition, either as an ArrayBufferView or as an Embedded Geometry.

Table : Attributes of the Class VestedGeometryParams within the FeatureData document
Name Type Description

type

String

The primitive type of the geometry defined through a VestedGeometryParams object. One of {*triangles*, lines, points}

topology

TopologyType

Declares the typology of embedded geometry attributes or those in a geometry resources. One of {"PerAttributeArray", "InterleavedArray", "Indexed"}. When "Indexed", the indices (faces) SHALL be declared.

vertexAttributes

VertexAttribute[1..*]

A list of Vertex Attributes, such as Position, Normals, UV coordinates, and their definitions. While there are standard keywords such as position, uv0..uv9, normal and color, this is an open, extendable list.

faces

FaceAttribute[0..*]

A list of Face Attributes, such as indices to build faces, and their definitions. While there are standard keywords such as position, uv0..uv9, normal and color, this is an open, extendable list.

7.5.6.7    Class SingleComponentParams

Objects of this type extend VestedGeometryParams and use one texture and one material. They can be used with aggregated LoD geometries.

Table : Attributes of the Class SingleComponentParams within the FeatureData document
Name Type Description

material

URI

I3S Pointer reference to the material definition in this node's shared resource, from its root element. If present, used for the entire geometry.

texture

URI

I3S Pointer reference to the material definition in this node's shared resource, from its root element. If present, used for the entire geometry.

Component objects provide information on parts of the geometry they belong to, specifically with which material and texture to render them.

Table : Attributes of the Class Component within the FeatureData document