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

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

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.

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.

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.

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.

Each node has exactly one NodeIndexDocument and one SharedDescriptors document. The 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 of FeatureData and Geometry resources. 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.

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:

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.

All Scene Layer types make use of the same fundamental set of geometry types: points, lines, and triangles.

Array Buffer View ^[26] geometry property declarations control geometries storage and consumption representation. I3S provides full control over those properties, such as per-vertex layout of components (e.g. position, normal and texture coordinates). This orders the vertex position, normal and texture coordinates to ensure the same pattern 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.

For more details regarding 3D objects and point scene layer, see Geometry.

For more details regarding point cloud scene layer, see defaultGeometrySchema.

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. Both integrated mesh and 3D object profile support textures. Authoring applications can provide additional texture formats using textureEncoding declarations.

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.

I3S supports the following two patterns of accessing attribute data. They can be accessed as follows.

Clients can use either method if the attributes are cached. The attribute values are stored as a geometry aligned, per field (column), key-value pair arrays.

For more details regarding point cloud scene layer, see AttributeInfo.

For more details on all other scene layer types, see Attribute.

I3S supports a Discrete LoD approach, where different Level of Detail 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.

By using only information found in the node index document, such as bounding volume and level of detail selection metrics, a client application traversing an I3S tree can readily decide if it needs to:

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.

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 levels of detail can optionally be automatically generated by extending the viewing range of each semantically input level of detail.

Tools can also be developed that load all the input level of detail information for the modeled entities in the input into a single I3S layer. In this case the depth of the I3S index tree is fixed to the number of levels of detail present in the input. 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 present in the input and the need for further additional automatically generated levels of detail.

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

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 a 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, the method used to create the levels depends on the Scene Layer type..

A client needs information to determine whether a node’s contents are "good enough" to render in the current 3D view. This metric can be used by the client to determine whether a representation is of the correct quality. Publishers can add as many LodSelection objects as desired but must provide one if the layer’s lodType is not null. Of the three min/avg/max values, typically only one or two are used. Selection criteria include 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:

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

maxScreenThreshold: 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). Typically, a client application consuming a node resource will project the nodes bounding volume (in this case sphere) on screen plane and compute its radius in pixels. The application can then switch the LoD to children node if this radius is bigger than the value defined for the maxError of the maxScreenThreshold metric. Used by mesh pyramids.

maxScreenThresholdSQ: is the metric type used when the bounding volume of a node is Oriented Bounding Box (OBB). This metric is equivalent to maxScreenThreshold and is calculated as:

maxScreenThresholdSQ = PI * 0.25 * maxScreenThreshold * maxScreenThreshold

screenSpaceRelative: The scale of the node’s minimum bounding volume. used by the points profile.

distanceRangeFromDefaultCamera: Normalized distance of the node’s minimum bounding volume from the camera. Used by the points profile.

effectiveDensity: Estimation of the point density covered by the node. Used by Point Clouds.

A value schema ensures that the JSON properties follow a fixed pattern and support the following data types.

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:

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 data available in some data store in which 3D content has been authored and is ready for publication (visualization). This file is automatically generated by the Scene Server for each service instance and is not part of a Scene Layer Package (SLPK) file. The SceneServiceInfo has the following structure:

This file is automatically generated by a Scene Server for each service instance and is not part of a Scene Layer Package (SLPK) file. It is included here only for reference.

The Class 3dSceneLayerInfo describes the properties of a single layer in a store, including the default symbology to use. Every scene layer contains 3DSceneLayerInfo. 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:

The 3dNodeIndexDocument JSON file describes a single index node within a store. This includes 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, provides sufficient data for simple visualization by rendering the centroids as point features for example. This can help the user understand the overall distribution of the data. The 3dNodeIndexDocument has the following structure:

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

The SharedResource class collects Material definitions, Texture definitions, Shader definitions and geometry symbols that need to be instanced.

The number and volume of textures tends to be the limiting display factor, especially for web and mobile clients. Thus, this standard provides several recommendations and requirements on texture resources that are delivered as part of an Indexed 3D Scene.

I3S supports multiple texture formats. The choice of format depends on the use case. For example, a client application might prefer consuming the more compact JPEG (and/or PNG) formats over low bandwidth conditions since they are very efficient to transmit and have a widespread adoption. However, client applications that might be constrained for memory or computing resource might prefer to directly consume compressed textures such as S3TC for scalability and performance reasons.

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. The only requirement is the authoring application needs to provide the appropriate textureEncoding declaration by using MIME types such as, "image/jpeg" (for Jpeg) and "image/vnd-ms.dds" (for S3TC).

This standard allows the combination of multiple textures into a single resource by using array buffer views. However, we generally recommend using large atlases (e.g. 2048x2048px) and then to use exactly one texture per bundle.

Individual textures should be aggregated into texture atlases. Each individual texture becomes a subtexture. As with all texture resources, the atlas has to be 2n-sized on both dimensions, with n being in the range [3,12]. Width and height dimensions do not have to be equal, e.g. 512px x 256px. Subtextures contained within an atlas also need to be 2n-sized, with n being in the range [3,12]. Otherwise if their width or height dimension is not 2n, border artifacts are likely to appear when filtering or MIP-mapping. If source subtexture dimensions do not match this requirement, they need to be padded (with nearest/interpolated pixels) or scaled to the nearest lower 2n size. An image that is 140px x 90px would thus be rescaled to 128px x 64px before being inserted into the atlas or padded to 256px x 128px.

Subtexture pixels are identified by the subimageRegion: [umin, vmin, umax, vmax] attribute. Region information is passed on to the shader using a separate vertex attribute so that every vertex UV coordinate becomes a UVR coordinate, with the R encoding the [umin, vmin, umax, vmax] of the region in 4 UInt16 values.

Client capabilities for handling complex UV cases vary widely, so texture coordinates are used. Texture coordinates do not directly take atlas regions into account. They always range from 0…​1 in U and V, except when using the "repeat" wrapping mode, where they may range from 0…​n (n being the number of repeats). The client is expected to use the subimageRegion values and the texture coordinates to best handle repeating textures in atlases. This approach has been selected since client capabilities in dealing with more complex UV cases vary greatly.

The Id of an image is generated using the following method:

Clients can use the key property (layers[id].attributeStorageInfo[].key) of the attributeStorageInfo to uniquely identify and request the attribute resource through a RESTful API, called attributes. Clients use the attributeStorageInfo metadata to decode the retrieved attribute binary content.

The attribute resource header contains:

An example JSON encoding for a 3dSceneLayer mesh pyramid can be found at the example here. This is a scene layer resource illustrating the metadata information found in the fields (layers[id].fields[id]) and attributeStorageInfo arrays (layers[id].attributeStorageInfo[id]).

A client application will be able to find the URI of any attribute resource through its href reference from the attributeData array of the Node Index Document (similar access patterns exist for resources such as 'features', 'geometries', etc …). See Figure 12 below:

Detail: A node resource document illustrating attribute data content access URLs (href).

The attributes REST API allows client apps to fetch the attribute records of a field using its key property directly from a scene service layer. As a result, every scene node (with the exception of 'root' node), exposes available attribute fields as discrete attribute resources. These resources are accessible thru a relative URL to any Node Index Document.

The attributes REST API syntax: URL: http://\<sceneservrice-url\>/attributes/\<field\_key\>/\<id\>;

Note: properties in bold are required

Note that the key property (with values such as f_0, f_1, etc…​) is automatically computed and that there shouldn’t be any relationship assumed to the field index of the source feature class (especially important when a user adds or deletes fields during the lifetime of a layer).

Detail: Figure 13 is an expanded view of a scene layer resource showing the content of an attributeStorageInfo resource. The example shows 5 objects each corresponding to the 5 objects of the fields resource (as matched by the 'key' and 'name' properties present in both arrays).The JSON representation of the example is located in 3D Scene Layer examples section.

The following example below shows the attributes REST request signature:

In Example 2.a we are requesting the attributes of all features for a field named 'NEAR_FID', as identified by its field key (f_1) in Figure 13. This field resource contains the attribute values of all features that are present in node 0-0-0-0. Similarly, Example 2.b will fetch the attributes of all features associated with the field called ('NEAR_DIST') using its key (f_2).

A numeric attribute resource is a single, one dimensional array. A string attribute resource is two, sequential, one dimensional arrays. The structure of each attribute resource is declared upfront in the scene layer resource thru the attributeStorageInfo object. The client application (as stated above in the typical usage pattern) is expected to read the attributeStorageInfo metadata to get the header information, the ordering of the stored records (arrays) as well as their value types before consuming the binary attribute resource.

Consider a sample scene service layer and its field types (see Figure 14). This layer has 6 fields named 'OID', 'Shape', 'NEAR_FID', 'NEAR_DIST', 'Name' and 'Building_ID'.

More detail: A typical attribute (table) info of a feature class. The fields array that’s shown as an example in Figure 11 and the attributeStorageInfo array in Figure 14 is derived from the attribute value of the above feature class.

As it could be inferred from Figure 11 and Figure 14, a scene service layer exposes/includes only supported attribute field value types of a feature class. As a result, the 'Shape' field (see Figure 14), which is of FieldTypeGeometry type, will not be included in the attribute cache of a scene layer.

The table below lists a feature layer’s field data types (including its values and description). The I3S valueTypes column indicates the value types of the fields that are supported for attribute based mapping/symbology.

Note: String — using UTF-8 Unicode character encoding scheme.

The following types of attribute value arrays are supported: Int32-Array, UInt32-Array, UInt64-Array, Float64-Array, Float32-Array, String-Array

Using our example feature class shown in Figure 14 let’s see how it maps to the different types of attribute resources.

The attributes REST API of a scene layer gives access to all scene cache operations supported feature attribute data as attribute value arrays that are stored in binary format. As a result, the scene cache of the example feature class in Figure 14 has 5 binary resources, as identified by keys f_0, f_1_, f_2_, f_3__ and f_4 and are accessible by their respective rest resource URLs (_…​/nodes/<nodeID>/attributes/0/f_0, …​/nodes/<nodeID>/attributes/0/f_1, etc..).

Point scene layers contain point features and their attributes. Point scene layers are often used to visualize large amounts of 3D data like trees or buildings. Most phenomena that can be visualized by 3D symbols can be displayed with a point scene layers. The point scene layer is structured into a tree of multiple JSON files. Besides storing information in the JSON format, some are also provided as binary buffer. Point scene layers can be used to create a scene layer package (\*.slpk) or an I3S service. A point scene layer SHALL contain profiles of the following classes:

Please visit I3S Scene Layer Profile for Points for details on the Point Scene Layer Profile as well as a full JSON example.

The following API methods are available for the I3S Point Scene Layer:

The Integrated Mesh scene layer is structured into a tree of multiple JSON files. Besides storing information in the JSON format, some are also provided as binary buffer. Integrated mesh scene layers can be used to create a scene layer package (\*.slpk) or an I3S service. An Integrated Mesh scene layer SHALL contain profiles of the following classes:

Integrated mesh scene layer packages can optionally contain a hash table for faster indexing.

Please visit I3S Scene Layer Profile - Mesh-pyramids (MP) for more details on the Integrated Mesh Layer Profile as well as a JSON example.

The following API methods are available for Integrated Mesh Scene Layer:

Scene layer document

Node Document

Textures

Geometry

Shared resources

The 3D object scene layer is structured into a tree of multiple JSON files. Besides storing information in the JSON format, some are also provided as a binary buffer encoding. A 3D object scene layer can be used to create a scene layer package (\*.slpk) or an I3S service. A 3D object scene layer contains the following:

The following API methods are available for the 3D Objects scene layer:

Scene layer document

3D node index document

Textures

Geometry

Attributes

Statistics

Shared resources

The point cloud scene layer is structured into a tree of multiple JSON files. Besides storing information in the JSON format, some are also provided as binary buffer. Point cloud scene layers can be used to create a scene layer package (*.slpk) or an I3S service. Since an \*.slpk file can contain millions of documents, an [SLPK hash table] improves performance when scanning the .slpk file. A point cloud scene layer contains the following:

<<_i3s_point_cloud_scene_layer_profile,Annex G> has more information on the point cloud scene layer profile.

The following API methods are available for accessing a point cloud scene layer:

Every SLPK archive has a metadata.json file. The following entries are required and must be of the specified type. The default is in bold.: