I3S was released publicly in 2015 as an open specification for streaming large, heterogeneous geospatial data sets with 3D content including discrete 3D objects, large continuous meshes, 3D vector points, point clouds, and other 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. I3S supports storage and transmission of very large data sets that may consist of millions of discrete 3D objects with attributes as well as integrated surface meshes that may cover many thousands of square kilometers of the Earth’s surface.
Designed for 3D
I3S is intrinsically designed to support 3D geospatial content and supports the requisite coordinate systems and height models in conjunction with a rich set of layer types.
The specification supports both 3D Global Coordinate Systems as well as locally applicable 3D Map Coordinate systems that are based on well-known map projections for the x-y plane along with additional height information for the z axis.
The specification accommodates declaration of a vertical coordinate system that may be ellipsoidal (elevation/ height defined with respect to a reference ellipsoid) or orthometric (elevation / height defined with respect to a reference geoid / gravity surface). This allows I3S to be applied across a diverse range of fields and applications where the particular definition of elevation/height is of importance.
Designed for Web, Mobile and Cloud
I3S is designed from the ground up to be cloud, web and mobile friendly. It 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 was introduced as an open specification for the purpose of encouraging community adoption, encouraging feedback, and for ensuring that adopting organizations would have flexibility in access to 3D data. The specification is licensed under the Creative Commons Attribution-NoDerivs 3.0 Unported License. Implementers can use the specification in services, clients or processing tools without restrictions.
3D Layer Types
A single I3S data set, referred to as a Scene Layer is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic data. An I3S Layer is characterized by a combination of layer type and profile that fully describe the behavior of the layer and the manner in which it is realized within the specification.
The format is declarative and extendable and has been used to represent different types of 3D data.
The following layer types have been specified and the specifications validated via implementation and production deployments:
example : Building Exteriors
sources : Derived from GIS Data, as well as 3D models in various formats
Example: Mesh surface representing the skin of the Earth, including vegetation, buildings and roads
Sources: Derived from satellite, aerial or drone imagery via dense matching photogrammetry, or calculated
Examples: Hospitals, schools, trees, cars
Sources: feature locations combined with Instanced 3D models generated by hand
The following layer types are in development process with release of the specification in Q4 2016 and release of a production implementation in Q4 2016.
Example: LiDAR data sets
Sources: Typically sensor-collected or Photogrammetrically derived
The following layer types are planned for future inclusion:
Lines (e.g. Roads and Pipes; from GIS Data)
Polygons (e.g. Soil or Forest Cover; from GIS Data)
I3S Scene Layers are designed to provide clients access to data, regulated by visual extent and camera distance and type-dependent indexing. Clients have the ability to adjust or override visualization properties of layers independently according to their needs and according to the nature of the layer’s data. Data here refers to both the geometry and the attributes for 3D Object, Point, Line and Polygon Features as well as the vertex geometry and vertex attributes for vertices within layers that represent geographic fields, like with integrated meshes and point clouds.
The degree of separation between data and implied visualization varies depending on the type of layer – at one extreme an integrated mesh layer, representing [in effect] “3d imagery”, has a strong implication that clients will display the mesh geometry using the textures that are advertised by and available with the layer. At the other end layers representing 3D features/entities including space occupying 3D objects as well as Points carry a full representation of their attributes allowing clients to thematically map and visualize the data according to their needs. In both cases the I3S access API separates access to geometry from access to textures and attributes, giving clients needed flexibility. In many cases the GIS features’ data that is part of the I3S layer will itself be a cached, cooked or preprocessed version (the industry uses a variety of terms to denote the process of generating the 3D access optimized representation) of primary data that resides in a transactional system of record.
The concept of Level of Detail (LOD) is intrinsic to the specification. 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 and representation of the individual features that are retained within any level of detail.
Layers are described using two properties, type and profile. The type of a layer describes its semantic meaning to the consumer as described in the section above. The profile for a layer includes additional detail on the specific I3S implementation for the layer that is exposed to clients. In most cases the relationship between layer and profile is 1:1 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 associated profiles, indicates which layers are used to represent features (entities) vs geographic fields, and also includes information on support for feature or vertex attributes for the layers.
|Layer Type (example)||Profile||Features with Identity||Attributes|
|Integrated Mesh||mesh-pyramids||No||planned : Triangle Attributes|
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.
I3S is agnostic with respect to the model used to index objects / features in 3D space. Both regular partitions of space (eg quadtrees and octtrees) as well as density dependent partitioning of space (e.g. R-Trees) are supported. The specific partitioning scheme is hidden from clients who navigate the nodes in the tree via REST API. 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 based on its tree-key.
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 metrics. This resource allows for tree traversal without the need to access the more voluminous content associated with a node (geometry, texture data, attributes), where 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, the node’s bounding volume, and LOD Selection threshold value of the node.
The specification supports both 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 detail versions of information contained in descendent nodes.
The physical organization of information within nodes is as follows:
The node index document is a lightweight resource that describes the topology of the node within the tree and includes references to other sub-resources.
The feature-data sub-resource for a node is a text resource that contains the identifiers for the set of features within a node. It stores the geometry and attributes for all of the features in the node by value or as references to sub-resources.
The geometry, attribute and texture sub-resources describe the geometry, attribute and texture for the node. Geometry and attribute sub-resources represent the geometries and attributes of all of the features within the node and include the identifiers of the owning features within the node as well as the mapping between individual feature identifiers and their geometry segments. Vertices within the geometry contain the appropriate texture coordinates.
An I3S profile can have either a single text-based feature-data sub-resource that contains all geometry and attribute information, or separate, binary and self-contained geometry and attribute sub-resources. Applications accessing the latter do not need to first fetch the feature-data resource in order to interpret them.