OGC Engineering Report

Testbed-18: 3D+ Data Streaming Engineering Report
Jérôme Jacovella-St-Louis Editor
OGC Engineering Report


Document number:22-035
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

License Agreement

Use of this document is subject to the license agreement at

I.  Keywords

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

3D, space, streaming, GeoPose, moving features, orbit, OGC API, glTF, 3D Tiles, BCRS, NOVAS, SOFA, Solar System, ISS, Voyager, special relativity, general relativity

II.  Abstract

This OGC Testbed 18 3D Plus Data Standards and Streaming Engineering Report (ER) reviews existing specifications that support interoperable descriptions of orbital and non-orbital space-based assets, objects, and observations as well as terrestrial observations. The ER suggests a framework consolidating these specifications as a foundation for modeling, representation, and serialization from space-based assets operating at any location in our solar system (3D+ data). This framework enables the streaming of 3D+ data to visualization devices (displays, AR, VR) for presentation.

III.  Summary

This Engineering Report presents the results of OGC Testbed 18 research performed as a component of the 3D+ Data Standards and Streaming thread. A review of existing standards pertaining to the efficient streaming and visualization of spatiotemporal 3D and 4D data was performed. This review also considered use cases in Space, including objects referenced relative to a spherical body other than Earth, in orbit, or in free flight within the Solar System, the Milky Way, or outside our galaxy.

The relevant standards and candidate standards identified include multiple OGC APIs, Khronos® glTF™ and OGC GeoPose. The OGC GeoPose and OGC API — Moving Features were reviewed, resulting in some recommendations to those standards. Existing coordinate systems for referencing objects in Space were reviewed and conversions were performed between the Barycentric Celestial Reference System (BCRS), the Geocentric Celestial Reference System (GCRS), Ecliptic coordinate systems (heliocentric and geocentric), the International Terrestrial Reference System (ITRS), and GeoPose. The NOVAS C library was used for these conversions and for developing a Solar System visual simulation. The demonstration also tracked and displayed the International Space Station (ISS) as well as the Voyager 1 space probe, integrating glTF™ models provided by NASA and the Gaia Sky in Colour from ESA. The applicability of the theory of special and general relativity to potential scenarios was explored. The concept of time dilation, the Lorentz factor, and Schwarzschild’s exact solution to Einstein’s field equations describing time dilation resulting from both velocity and gravitational fields are briefly introduced.

In addition to the recommendations specific to particular OGC standards that were provided, as an outcome of this work participants recommend the following for the OGC community:

1.  Introduction

This OGC Testbed 18 Engineering Report presents the result of research performed as a component of the 3D+ Data Standards and Streaming thread. A review of existing standards pertaining to the efficient streaming and visualization of spatiotemporal 3D and 4D data was performed. Use cases in space, including objects referenced relative to a spherical body other than Earth, in orbit, or in free flight within the Solar System, the Milky Way, or outside our galaxy were also considered.

The relevant standards and candidate standards identified include the following.

As part of reviewing the GeoPose standard, issues were documented in the GeoPose GitHub repository. The relevant capabilities that would greatly improve the usability of the standard only exist in advanced targets of the standard which were found to be cumbersome and not a natural extension of the core capabilities of the simple target or of the JSON encoding itself. These capabilities include associating time stamps and identifiers with an individual pose, defining sequences of multiple GeoPoses, and defining a pose relative to a parent pose. A recommendation was made to consider defining these capabilities as extensions preserving the basic form of the simple target. Two space scenarios illustrate what this could look like in a JSON encoding. In one scenario, passengers are onboard a spaceship that is in free flight from Earth to Mars, and in the other, passengers are onboard an express train on the surface of Mars.

As part of reviewing the OGC API — Moving Features standard, issues were documented in the GitHub repository, including clarifying the possible synergy with the OGC GeoPose and OGC API — Connected Systems, and use cases for high performance queries.

The research also reviewed existing coordinate systems for referencing objects in Space and experimented with conversions between:

For several of these conversions, as well as for calculating the positions of the Sun, Earth, Moon, and planets in our Solar System at a given time, the NOVAS C library was used. A table summarizing the functions of the library used in this experiment is presented. The SOFA library is also mentioned as a potential alternative. The BCRS is described as the global standard reference system for objects located outside the gravitational vicinity of Earth on Wikipedia.

glTF™ models provided by NASA as well as the Gaia Sky in Colour from ESA were used to provide a situational awareness in space reflecting the camera position and orientation in a visual demonstration. A scenario tracking the position of the International Space Station (ISS) from a sequence of positions returned by a Web API was also demonstrated, using a detailed glTF™ model of the space station provided by NASA. Another scenario which displays and tracks the position of the Voyager 1 space probe along its journey across our Solar System since 1977 illustrates a use case extending deeper into space, again using a NASA glTF™ model as well as historical data.

Finally, the applicability of the theory of special and general relativity to potential scenarios is explored, also noting cases where it may not be applicable. The concept of time dilation is introduced and illustrated with the thought experiment of a light clock, from which the Lorentz factor is derived simply with the well-understood Pythagoras theorem. The scenario of Global Positioning Systems (GPS) is discussed, where the velocity and gravitational fields have opposite effects on time dilation for the on-board clocks compared to clocks on Earth. Schwarzschild’s exact solution to Einstein’s field equations is also presented, describing with a simple equation time dilation resulting from both velocity and gravitational fields.

2.  Terms, definitions and abbreviated terms

No terms and definitions are listed in this document.

2.1.  Abbreviated terms


Application Programming Interface


Augmented Reality


Astronomical Unit (149,597,870,700 meters, the distance from the Sun to Earth’s orbit)


Barycentric Celestial Reference System


Barycentric Coordinate Time


Bounding Volume Hierarchy


Coordinate Reference System


East, North, Up (axes)


Engineering Report


European Space Agency


Ericsson Texture Compression 2


Geocentric Celestial Reference System


Global Positioning System


GL Transmission Format


International Astronomical Union


International Space Station


International Terrestrial Reference Frame


International Terrestrial Reference System


Khronos Texture


Local Tangent Plane


National Aeronautics and Space Administration


Naval Observatory Merged Astrometric Dataset


Naval Observatory Vector Astrometry Subroutines


Open Geospatial Consortium


Standards of Fundamental Astronomy


Virtual Reality


2D Tile Matrix Set

3.  Streaming static data referenced to spherical body

The majority of data collected concerns observations and measurements on or near the surface of a spherical body, in particular planet Earth. A large portion of that data is also static. This static data may provide useful situational context for visualizing both other static content, as well as tracking dynamic objects (e.g., visualizing the position of a satellite in orbit above satellite imagery of the Earth). This section explores data access specifications supporting the interoperable selection and transmission of such static information referenced to a particular spherical body, including Earth, but also other spherical bodies such as the Moon or Mars.

3.1.  Streaming data with OGC API — 3D GeoVolumes

The OGC API — 3D GeoVolumes (draft) Core conformance class defines a mechanism to retrieve 3D content of different resolutions for flexible bounding volumes hierarchies, encoded using OGC specifications such as 3D Tiles or I3S.

Another conformance class supports the retrieval of data based on an implicit tiling scheme, such as a 2D Tile Matrix Set extended to three or more dimensions, based on the method described in the informative annex J of the 2D TileMatrix Set and TileSet Metadata Standard (2DTMS & TSMD).

3.2.  Flexible Bounding Volume Hierarchy

Defining a flexible bounding volume hierarchy enables equal distribution of the amount of data in different tiles based on the data density at different locations. In this case, space partitioning depends upon the data. A disadvantage of this approach compared to implicitly defining the space occupied by tiles (partitioning the space irrespective of its content) is that it is then not possible to determine which tiles cover a pre-determined space volume, such as a view frustum (the region of space in the modeled world visible on the display device).

3.3.  Implicit Tiles

With the implicit tiling scheme for 3D content in GeoVolumes, the orientation and positioning of the content for a particular tile of data is implied from the tile identifier, and a global multi-resolution tile set can be described using the TileSet metadata. The informative description from the 2DTMS & TSMD annex J to extend this TileSet metadata to additional dimensions will be standardized in the draft GeoVolumes standard for describing 3D content.

Three different approaches are supported as to how to handle the vertical dimensions:

  • extending the vertical dimension infinitely from the center of the spherical body to infinity outwards;

  • sub-dividing the vertical dimension based in fixed number of divisions at all resolution levels; and

  • progressively sub-dividing the vertical dimension into more divisions at higher resolution levels.

The OGC 3D Tiles Next Community Standard introduces support for implicit tilesets. However, the 3D Tiles implicit tiling mechanism is not fully aligned with the approach proposed in the 2D Tile Matrix Set and TileSet Metadata standard. This is because an implementation of 3D Tiles cannot express variable width tile matrix capabilities, still relies on complex hierarchies of tileset metadata for explicitly declaring tiles availability, and does not follow the convention of aligning local East, North, Upwards (ENU) axes with a plane tangent to the centroid of a tile. However, it is possible to define a 1.0 or 1.1 3D Tiles tileset declaring those transformations, so that the same 3D models whose local coordinate system is aligned with the ENU axes can be used with both the implicit tiling approach following a TileMatrixSet (including variable widths), as well as a TileSet defining a flexible Bounding Volume Hierarchy.

3.4.  Batched 3D Models vs. points referencing 3D models

Two common approaches exist for storing detailed 3D model content within tiles. One approach is to encode the entire content of each tile as a single 3D model object. This improves streaming performance by avoiding several round-trips to the server when requesting a large number of models. Another approach is to encode for each tile a reference point for everywhere a model is positioned. This reference point can additionally specify an optional orientation and/or scaling parameter to transform the model. This second approach is most useful for instantiating the same model many times such as building a forest from just a few tree models. Another advantage is that these reference points can easily be clamped to the terrain elevation, including when multiple resolutions of terrain are used. This ensures that the models will always be positioned on the ground. However, this clamping mechanism may also be implemented with the first approach if separate object nodes are used within a higher-level object node.