OGC Testbed-13: 3D Tiles and I3S Interoperability and Performance ER

An overview of the tests is provided in chapter 4.

Some experiments included the use of commercial software, specifically:

There was little prior work to test the interoperability of streaming capabilities relating to the OGC I3S Community Standard ("I3S") and the 3D Tiles specification proposed as a new work item for an OGC Community Standard ("3D Tiles"). The interoperability & performance analysis conducted in the testbed’s 3DTiles and i3s: Interoperability & Performance work package provided a demonstration of 3D data streaming capabilities supporting CDB and CityGML data streamed according to the I3S and 3D Tiles specifications. The work also validated the 3DPS 1.0 interface specification using 3D Tiles and I3S as the content delivery formats. As a proof of interoperability, rendering of I3S in Cesium client has been achieved. Based in the results of the experiments, some change requests for the 3DPS version 1.1 have been identified.

From the 3DPS SWG’s perspective, the main interest is to validate the 3DPS 1.0 interface specification using 3D Tiles and I3S as the content delivery formats.

For OGC in general, this work examines the interoperability and performance characteristics of streaming capabilities relating to the 3D Tiles and I3S specifications. More specifically, it provided a prototype demonstration to test and validate the interoperability of the OGC 3D Portrayal Service standard using the 3D Tiles and I3S data delivery formats in an urban-centric scenario based on CityGML and CDB data stores.

In addition, open data test data sets in CityGML for testing streaming of 3D city models have been defined. It is recommended to use these data sets in future experiments as well to achieve comparable results.

All questions regarding this document should be directed to the editor or the contributors:

The version of GeoRocket that was employed here used the 3D Tiles spatial hierarchy in order to quickly rearrange the data and therefore deliver only the requested subset of the original hierarchy. On the higher levels of the 3D Tiles hierarchy, the delivered elements intersected the queried spatial bounds, so that more data/buildings were visible than was queried, and the 3D Tiles styling feature was used to avoid rendering those intersecting objects. But in the future, it is expected that the returned geometries will be modified to only deliver the requested content. Related to this issue are the extension of the region query in 3DPS towards a polygon with holes. Such region query would enable mixed 3D scenes from different data sources such as a 3D city model with some parts of the model replaced by BIM models served by a BIM server. This is a very interesting use case in urban planning to show future urban developments.

Currently, the tiling strategies are part of external tools developed by different participants. The data delivery formats act as general container of the tiles. A general flexible for the generation of tiles would be very helpful as this is one core elements of streaming 3D and maybe 4D data in future.

The CDB standard provides guidance on storing many other datasets beyond those used here. It is expected that future work will develop representations of the other datasets in suitable 3D Tiles formats. For example, CDB geotypical models could be represented in 3D Tiles "instanced 3D model" (I3DM) format. Also underground structures such as utility networks are of high interest.

Another important topic for future work is a mixed rendering of 3D scenes and image based rendering. With image based rendering, not only bandwidth can be saved, but it has an advantage on data security as well, as the vector data stays on the server side. The 3D Portrayal Service supports image based rendering as well with the conformance class view. However, a 3DPS that supports both scene graph delivery and image based rendering has not been implemented yet.

In general, the link between 3DPS and WFS should be explored in more detail to access attribute data from a 3D scene. Also the integration of sensor measurements and simulation results into a 3D scene is very relevant for the future cities.

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.

presentation of information to humans. NOTE: This term is defined by [ISO 19117].

geometry and texture data that is to be portrayed. The term "3D scene" refers to a digital representation of geographic data that is mainly composed from 3D graphics data (mainly geometry and texture data), which is also often referred to as 3D display elements.

a scene graph is a collection of nodes in a tree like data structure. Each node can have many children and has only one parent. A node refers to a set of 3D display elements.

The root node of a scene graph is the node without a parent node.

A tile is a collection of 3D display elements of a spatial bounding volume along with it’s metadata.

A Tileset is a Scene Graph consisting of tiles.

The visualization pipeline provides the key structure in any visualization system. In [REF_Moreland] Moreland gives a survey of visualization pipelines used in several applications. In this report, the concept of the visualization pipeline for the interactive portrayal of geospatial data was based on [REF_OGC_98-061]. It consists of three main components: Filter, Map, and Render. The Filtering step (sometimes called selecting) selects data from larger geospatial data set that should be displayed on the screen. The Mapping step maps features to display elements such as triangles and material definitions for an illumination model. This mapping can be done based on a style guide or based on individual appearance definitions per feature (see CityGML Appearance module as an example). During the Rendering step, the display elements are rendering into a screen buffer (or into an image) to be displayed on the screen.

User interaction is possible in each step, depending on the system architecture and the purpose of the system. A simple map visualization system may allow interaction in the rendering (zoom, pan, change position of the camera); a visual data analytics system needs to enable user interaction on Mapping and Filtering as well.

The experiments described by this report focused on the use of OGC standards in the Filtering and Mapping step to enable a distributed visualization pipeline. The Rendering is the core of Computer Graphics, libraries such as DirectX, OpenGL, and WebGL are used in this step. It has its own conceptual model, the so-called rendering pipeline. The rendering pipeline has changed tremendously during the last decade, from transformation and illumination models on CPUs to vertex and pixel shaders on GPUs.

The visualization pipeline can be distributed between client and server as follows [REF_OGC_09-104r1].

In the work described in this report, the second case of the distribution of the visualization pipeline (filtering and mapping on the server, rendering on the client), was investigated in more detail. A special focus was placed on the use of CDB and CityGML for the geospatial data sources, the I3S and 3D Tiles specifications for data delivery from server to (web-based) client, and the OGC 3D Portrayal Service Standard as a query interface.

The conformance class scene of the 3DPS standard supports client side rendering and content delivery using a scene graph. A specific data delivery format is not defined by the standard, but is negotiated by the client and server using the 3DPS getCapability operator and defined mime types. For images, the data format itself was not examined; instead, suitable formats (such as jpeg, png, etc.) were selected. The same goal was pursued in 3D. I3S and 3D Tiles were suitable data delivery formats for the 3DPS conformance class scene.

A first example from an experiment done in advance of the Testbed 13 [REF_Koukofikis] illustrates the importance of a good mapping strategy. In the experiment, a CityGML data set was mapped to a X3D scene graph using FME. The X3D scene was displayed in a web browser using the JavaScript library X3DOM as a 3D viewer. Two different mapping strategies were compared:

The average frames per second (FPS) was measured in a web application using CPU Intel Core i5-3210M Processor, Operating System Windows 8.1 Professional (64bit), GPU NVIDIA GeForce GT 620M, RAM 8 GB, Web X3D viewer X3DOM 1.7.1, Web Browser Chrome 48 (64bit), Web Server Apache 2.4.17.

This example clearly showed the impact on the mapping on the rendering performance on the client. In addition, the total time from the user query to the first image on the screen has to be taken into account for a distributed rendering pipeline. For larger scenes, tiling had a significant impact on load time.

To implement the visualization pipeline, several experiments using CityGML and CDB data stores were conducted. AGI created the necessary processing algorithms to convert CityGML into 3D Tiles within its 3D Tiles Processing Tools; Esri created the necessary processing algorithms to convert CityGML into I3S within ArcGIS and by using FME; Fraunhofer and virtualcitySYSTEMS created the necessary processing algorithms to convert CityGML with and without application domain extension into 3D Tiles within GeoRocket. Further, Esri and HFT Stuttgart investigated the ability to convert CityGML into I3S and display it in Cesium to prove interoperability of I3S and Cesium using the 3DPS.

The processing algorithms took into consideration high- versus low-geometrically complex features, textured features, and the geographic distribution of features. 3D clients performed query operations using the 3DPS to return appropriate tiles. Data was streamed according to the 3D Tiles and I3S. In addition, runtime visualization strategies were developed and profiled.

The table below summarizes the experiments conducted.

Experiments 2 and 4 investigated source data management using GeoRocket. For these experiments, a 3DPS instance was implemented on top of GeoRocket. Experiments 1 and 3 investigated source data processing using AGI’s 3D Tiling Pipeline and Esri’s ArcGIS.

A similar workflow was developed by Compusult for data maintained in a CDB-structured data store (experiment 5), and Ecere implemented both 3D Tiles and I3S visualization (Experiments 6 and 8) as well as implementing direct visualization of CDB in their client (Experiment 7).

Input data included textured terrain and textured 3D buildings, and were provided as CityGML and CDB encodings.

The overall Experiment 1 goal was to convert CityGML data into 3D Tiles, which were then visualized using a client (Cesium) that could consume 3D Tiles output.