3D Data Container and Tiles API Pilot Summary Engineering Report

This Engineering Report summarizes the purpose and key results of the 3D Data Container and Tiles API Pilot, an OGC Innovation Program initiative conducted between October 2019 and July 2020. In the context of both existing and emerging 3D and 2D standards, the focus of the Pilot was on the exchange and visualization of 3D data using open standards.

A variety of solutions and standards co-exist to access and transfer 3D geospatial content over the internet (e.g. 3D Tiles, I3S, glTF, CDB, CityGML). These solutions were developed for various technical and commercial reasons. They use different distribution mechanisms and are optimized for particular user requirements and bandwidth situations (e.g. image stream, scenes, or raw vector data delivery). As each of these co-existing solutions binds the user to a particular approach, it is challenging to access a variety of 3D content from different providers. The 3D Data Container and Tiles API Pilot addressed this challenge. The Pilot achieved its goal to develop a resource model and corresponding Application Programming Interface (API) to integrate various approaches into a single, open standards based solution. The developed GeoVolumes API and 3D Container resource model allow efficient discovery and access of 3D content based on a space-centric perspective.

The goal of the 3D Data Container and Tiles API Pilot was not to replace existing APIs and distribution models for 3D data, but to develop an integration concept for existing OGC 3D delivery standards to:

To achieve these goals, the Pilot developed a 3D geospatial data container and a corresponding draft OGC API - GeoVolumes providing browse and query access to 3D geospatial content. GeoVolumes (aka 3D Containers) can be hierarchically defined with nesting support. The 3D data resources supported by the GeoVolumes API include feature geometries, feature attribute values, elevation models, texture data, and other resource types. The API provides both link-follow and bounding-box query methods of access to 2D and 3D content in a manner independent of the underlying data store. Multiple standard geospatial distribution formats such as 3D Tiles, I3S, CDB, and CityGML are supported for streamed data delivery by means of the GeoVolumes API.

Multiple data server and client implementations were developed during the Pilot in order to test interoperable 3D content delivery via the GeoVolumes API. The API was defined using the OpenAPI 3.0 definition language and conforms to the building blocks of the draft OGC API - Common – Part 1: Core specification. Thus, the Pilot developed and tested the GeoVolumes API in order to advance open standards-based and unified approaches for delivering 3D content using state of the art API practices that work across different data formats, streaming protocols, and model types.

This summary first outlines a high-level architecture with different distribution levels, bandwidth options, and required capabilities. This approach helps to better understand where the GeoVolume (also known as 3D Container) and its corresponding API actually exist and integrate with other established or emerging standards. The summary then briefly introduces differences between existing solutions to further illustrate the challenge described above.

Once the context is set, the summary outlines the technical challenges that had to be addressed, defines the GeoVolume/3D Container (3DC), describes its capabilities and constraints, and introduces the API that uses the GeoVolume as its resource model. The summary describes how wide-spread tools have been used to document the building blocks of the API and provides further insights into taken design decisions using statements from the Pilot participants on initial challenges, tested approaches, and final solutions. The summary briefly illustrates the developed prototypes and ends with an assessment of the commercial potential of the proposed solutions, their future path in the standardization process, and required next steps towards a fully interoperable, space-centric 3D data exchange and exploration environment.

From a standardization perspective, the Pilot developed a draft API and resource model that have been proven mature enough to be introduced to OGC’s Standards Program. The next steps now include generating a new OGC Standards Working Group (SWG), which requires defining the SWG charter. Once the charter is approved by the OGC Technical and Planning Committees (TC & PC), the SWG starts with the consensus based standard development process and eventually recommends to the Technical Committee the release of the final Standard to the public.

It is important that additional integration tests and real-world deployment demonstrations further explore the potential of the GeoVolumes API, resolve any outstanding interoperability issues, and explore best practices for the organization of GeoVolumes within different domains and disciplines. Several of these tests are scheduled to begin in September 2020.

The high-level architecture is built around the needs of the various entities ('A'), ('B'), and ('C') in an enterprise as illustrated in the Figure 2. The three entities differ in the amount of data that can be stored and processed, the available bandwidth for data transport, the multiplicity of supported analytics, and the offered data products. Despite these differences, it was the goal of this Pilot to develop a model that allows offering, discovering, requesting, and processing data at each entity using a common single API on top of a single organizational model of 3D data in space. At the same time, this common single API should acknowledge available 3D data format and distribution standards such as 3D Tiles, I3S, CityGML, or CDB to ensure that customers can retrieve 3D data in the optimal format for their respective tasks.

High capacity data centers ('A') have 3D data available for broad regions or on a global scale. Data can be made available in multiple formats and distributions based on a set of converters and transcoders. Access to the data is offered to other entities in the enterprise by means of the GeoVolumes API as developed in this Pilot. Depending on users’ needs, data can be made available at alternative APIs in 2D or in raw format, such as e.g. OGC API Tiles or OGC API Features.

Medium capacity data centers ('B') do not require all data that is available at the data center ('A'), but are more selective. The amount of data transferred to ('B') depends on the available bandwidth and specific needs for data analysis and re-distribution. To obtain required data in the best suited format and minimum size, medium capacity data centers make use of the specific space-centric indexing scheme that is the fundamental idea of GeoVolumes/3D Container and the corresponding GeoVolumes API offered by ('A'). The indexing scheme is illustrated further below. It allows organizing data according to the human conceptual model of space. That is, it makes data available that corresponds to cognitive entities like a country with its cities and cities with its buildings, streets, or underground infrastructure. Medium capacity data centers again make their products available at the GeoVolume API; following the same conceptual model and distribution options as the high capacity data centers.

The high-level architecture defines a third enterprise entity, the low capacity field operations ('C'). These are connected at various bandwidth down to complete offline situations. In these cases, offline data packaging mechanisms and data volume optimized data selection and transmission processes are essential. Customers at this level want to go back and forth between 3D data optimized for visualization via low bandwidth connections and attribute-loaded data that provides detailed information about selected elements in a given view. That is, server-side rendering pipelines need to be integrated with scene graphs delivered to client applications.

Several 3D data related standards are currently available or in development. In the context of OGC, these are CityGML and CDB on the data model and storage format end, and the 3D Portrayal Service (3DPS) as a content transmission format agnostic service for 3D scene navigation and retrieval of feature information. The community standards 3D Tiles and I3S exist for data delivery. On the content transmission side, additional standards such as X3D or glTF have been explored in the OGC context several times. All these standards either serve different roles or have different strengths and weaknesses within 3D data visualization and analysis pipelines and will co-exist in future. A detailed comparison between 3D transmission formats 3D Tiles and I3S is available in the 3D Container Engineering Report; their usage and performance have been a subject of the OGC Testbed-13: 3D Tiles and I3S Interoperability and Performance ER.

This Pilot addressed a number of technical challenges and interoperability issues such as:

The 3D (Data) Container (3DC), is a geo-volume information resource described by an enclosing bounding volume (2D/3D). The 3DC has an enclosing bounding box and contains at most one 3D model dataset that is relevant to that volume. The 3D model dataset is represented by reference to one or more distributions. This summary uses the terms 3DC, 3D Container, and 3D Data Container interchangeably. The reason is that the original term “3D Container” is used in the GeoVolume API, but was questioned towards the end of the Pilot due to the potential risk of term overloading.

A bounding volume is a closed volume containing the union of a set of geometric objects. The following figure illustrates typical bounding volumes (red) with enclosed objects (yellow, green, and blue cuboids).

GeoVolumes follow one conceptual organization of space applied by humans, which is a nested collection of spaces where every space contains either a number of sub-spaces or a set of objects. As an example, the GeoVolume “Earth” contains a set of child GeoVolumes, one for each continent. Each continent then may have a set of child GeoVolumes for the various countries, or, if countries are irrelevant in that scenario, a number of datasets that represent the topography, rivers, and human settlements.

Thus, 3DC may describe a collection of spatially disjoint GeoVolumes or a nested, hierarchical collections of GeoVolumes. This concept is illustrated in the following figure. Here, the GeoVolume “North America” contains the two child GeoVolumes “Montreal” and “New York City”. Both are spatially disjoint. The GeoVolume “New York City” again contains a single 3D model dataset representing buildings. These buildings are available in distribution formats CityGML, 3D Tiles, and I3S.

The default representations of a 3D-Container are json/html information documents that define the bounding box, link to an implicit tileset scheme if applicable, and provide links to the actual content. The complete definition of the 3D Container is available in the 3D Container Engineering Report. The following figure illustrates the main elements of the container. It does not provide all details to improve readability. 3D Containers are organized in collections as described above.

What a content reference links to is dependent on content type and currently defined for the following types:

The following section describes the key elements of the GeoVolumes API, an OpenAPI 3.0 REST API developed for this Pilot. The GeoVolumes API conforms to the OGC API-Common foundation resources: landing page, API definition, conformance declaration, and collections (spatial resources). It provides access to 3D resources and allows the exchange of content compliant with the 3D Container also developed in this Pilot. Table 1 describes the resources and applicable HTTP methods for the GeoVolumes API. Those resources and methods are illustrated graphically in Figure 6.

Landing Page: The entry point to the API (/). The landing page provides links to the service description, API definition (/api), conformance declaration (/conformance) and collections (/collections). The landing page requires no parameters. The HTTP / GET response returns landing page content in JSON.

Conformance: The Conformance declaration states the conformance classes from standards or community specifications, identified by a URI, to which the API conforms. The conformance resource requires no parameters. The HTTP /conformance GET response returns the list of URIs of conformance classes implemented by the server in JSON.

API/Definition: Provides the API definition that describes the capabilities of the server and which can be used by developers to understand the API, by software clients to connect to the server, or by development tools to support the implementation of servers and clients. The api resource requires no parameters. The HTTP /api GET response returns the list of URIs of API definitions in JSON.

Collections: Collections provides the information and access collection of 3D containers. The collection resources accept the 2D or 3D bounding box (bbox) and format parameter. The resource accepts query or header parameters for the format parameter. The bounding box query parameter lower left: x, y, {z}, and upper right x, y, {z} (z-coordinate is optional) returns 3DC that are within the area. The HTTP /collection GET response returns JSON containing two properties, links (link: URI, type, relationship) and 3D Data Container.

3D Container: The collection resources support access to 3DC with a unique identifier (/collections/{3DContainterID}). The format and bounding box parameters in the collections request can be applied to a specific 3DC request. The bbox query on a 3DC will apply filtering on the contents within the 3DC. The HTTP /collections/{3DContainterID} GET response returns JSON representing the 3D Data Container.

Five clients have been implemented in the course of the Pilot that interact with six implementations of the GeoVolume API and its 3D Container resources. Figure 7 shows the setup. Clients and servers have been thoroughly tested for interoperability. The connectors only illustrate the technical interoperability experiments, some are omitted to improve readability.