Publication Date: 2020-10-22

Approval Date: 2020-09-23

Submission Date: 2020-07-15

Reference number of this document: OGC 20-029

Reference URL for this document: http://www.opengis.net/doc/PER/3DT-data-container

Category: OGC Public Engineering Report

Editors: Timothy Miller, Gil Trenum, Josh Lieberman

Title: 3D Data Container Engineering Report

OGC Public Engineering Report

COPYRIGHT

Copyright © 2020 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Subject

This OGC Engineering Report documents the goals, activities, experiences, and outcomes of the 3D Data Container and Tiles API Pilot. Participants in the Pilot cooperatively defined a GeoVolume (3D Geospatial Volume) resource and developed a GeoVolumes API based on the concept to provide access to different 2D and 3D geospatial dataset distributions organized by region of interest. Multiple client and server implementations of the GeoVolumes API successfully carried out technology interchange experiments that demonstrated the value of the API for improving interoperability between 3D geospatial data formats.

2. Executive Summary

The goal of the OGC 3D Data Container and Tiles API Pilot was to:

  • Explore an integrated suite of draft specifications for 3D geospatial resources compatible with existing OGC 3D delivery standards in order to support smooth transitions between 2D and 3D environments;

  • Allow applications working with 2D tile resources to get 3D tiled resources; and,

  • Enable 3D bounding volumes to support multiple data models, datasets, and distributions.

To achieve these goals, the Pilot participants developed a draft GeoVolume resource (originally the 3D Container resource) and GeoVolumes API providing browse and query access to 3D geospatial data for streamed data delivery by means of nested geospatial volume container resources. The 3D data resources supported by this API include feature geometries, feature attribute values, elevation models, texture data, and so forth. The API provides both link-follow and bbox query methods of access to 2D and 3D resources in a manner independent of the structure of the underlying data store, supporting multiple standard geospatial distribution formats such as 3D Tiles, I3S, CityGML, and CDB.

A number of data server and client implementations were developed in the course of the Pilot in order to test interoperable data delivery via the draft API. The GeoVolumes API developed by the Pilot is described using the OpenAPI 3.0 definition language and conforms to the building blocks of the draft OGC API – Common – Part 1: Core specification such as landing page, API definition, conformance declaration, and collections information. The Pilot developed and tested the GeoVolumes API in order to advance open standard-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.

The following requirements were identified in the Call for Participation (CFP) of the 3D Data Container and Tiles API Pilot:

  1. Provide API access to tiled and un-tiled 3D resources.

  2. Allow exchange of content organized according to 3D Container resources.

  3. Align with existing and emerging OGC APIs, standards, and candidate standards (e.g. OGC API - Features, OGC API - Common, 3D Tiles Community Standard, I3S Community Standard).

The present draft GeoVolumes API specification includes the six basic and extended forms of functionality implemented and tested during the Pilot. The experiences developed in the course of the Pilot suggest that further work is needed to extend the API for additional data types and nested volume schemes. Future work should also address the integration of the GeoVolumes API with other OGC API building blocks to provide seamless interaction from navigating volumes of interest to accessing specific dataset distributions.

2.1. Document contributor contact points

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

Contacts

Name Organization Role

Ryan Gauthier

US Army Geospatial Center

Sponsor/Contributor

Jeff Harrison

US Army Geospatial Center

Sponsor/Contributor

Tom Myers

US Army Geospatial Center

Sponsor/Contributor

Tim Miller

Leidos

Editor

Gil Trenum

Leidos

Editor

Josh Lieberman

OGC

Editor

Terry Idol

OGC

Contributor

Rob Jones

Helyx

Contributor

Matthew Knight

Helyx

Contributor

Anneley Hadland

Helyx

Contributor

Tamrat Belayneh

Esri

Contributor

Jérôme Jacovella-St-Louis

Ecere

Contributor

Aaron Brinton

Cognitics

Contributor

Michala Hill

Cognitics

Contributor

Ignacio Correas

Skymantics

Contributor

Preston Rodrigues

Steinbeis

Contributor

Kevin Ring

Cesium

Contributor

Volker Coors

Steinbeis

Contributor

Thunyathep Santhanavanich

Steinbeis

Contributor

2.2. Foreword

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.

3. References

The following normative documents are referenced in this document.

4. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

● 3D-Container

The most general definition of a 3D-Container (GeoVolume) is a spatial information resource with a distinct bounding volume, a (required) enclosing bounding box (2D / 3D), containing at most one 3D model dataset which is relevant to that volume (items, content) and represented by references to one or more distributions, and includes or references other 3D-Containers (children) whose bounding volumes are fully contained by the parent container’s bounding volume.

● coordinate reference system

Coordinate system that is related to the real world by a datum term name (source: ISO 19111)

● portrayal

Presentation of information to humans (source: ISO 19117)

● LiDAR

Light Detection and Ranging — a common method for acquiring point clouds through aerial, terrestrial, and mobile acquisition methods.

● Bounding Volume

Typically a simple shape like a sphere, rectangular box, or convex hull that can simply be tested for intersection or overlap.[2]

boundingVolume
● YAML

YAML is a human friendly data serialization standard for all programming languages.

4.1. Abbreviated terms

  • 3DC 3D-Container

  • 3DGV 3D GeoVolume

  • 3DPS 3D Portrayal Service

  • API Application Programming Interface

  • B3DM Batched 3D Model

  • BIM Building Information Model

  • BVH Bounding Volume Hierarchy

  • CDB Common Database

  • CRS Coordinate Reference System

  • EPSG European Petroleum Survey Group

  • glTF GL Transmission Format

  • I3DM Instanced 3D Model

  • I3S Indexed 3D Scene Layer

  • IDL Interface Definition Language

  • JSON JavaScript Object Notation

  • LOD Level of Detail

  • MBS Minimum Bounding Sphere

  • MBV Minimum Bounding Volume

  • OBB Oriented Bounding Box

  • RS Regular Subdivision

  • TIEs Technology Integration Experiments

  • TMS Tile Map Services

  • WFS Web Feature Service

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • YAML A recursive acronym for "YAML Ain’t Markup Language"

5. Overview

Section 6 discusses the existing standards and previous work relevant to the Pilot.

Section 7 presents the server and data architecture developed in this Pilot.

Section 8 presents multiple use cases: (1) API user, client, and (2) server use case and I3S To 3D-Tiles converter use case.

Section 9 presents the Pilot participants client and server 3D Container implementations.

Section 10 presents the Technology Integration Experiments (TIEs) results for the Pilot.

Section 11 discusses Pilot recommendations going forward.

Section 12 provides a summary of the main findings and discusses server and data architecture developed in this Pilot.

6. Existing and Relevant Standards

6.1. Background

This OGC Pilot builds on previous work from other OGC Innovation Program initiatives as well as OGC Standards Program efforts. The following documents serve as foundational references for this Pilot activity. Some items listed below are not yet released to the public. Draft versions of these documents have been made available. The final versions of these documents may change from the currently provided versions. Participants are advised to check the OGC website for updates on these documents.

6.2. Existing Standards/Previous Work

  • 3D Tiles Community Standard 1.0 (18-053r2) - The OGC 3D Tiles Community Standard specifies a model and encoding for streaming and rendering massive 3D geospatial content such as Photogrammetry, 3D Buildings, BIM/CAD, Instanced Features, and Point Clouds. The community standard defines a hierarchical data structure and a set of tile formats which deliver content that can be rendered. Of specific interest to this initiative is glTF. The standard document also describes 3D Tile Styles, a declarative styling specification which may be applied to tilesets.

  • OGC Indexed 3D Scene Layer (I3S) and Scene Layer Package Format Specification (OGC 17-014r7) - An OGC Community standard that specifies a model and encoding format for the transmission of 3D content as well as a persistence model for Scene Layers. A Scene Layer is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic content, supporting coordinate reference systems and height models in conjunction with a rich set of layer types.

  • OGC Testbed 13: 3D Tiles and I3S Interoperability and Performance Engineering Report (OGC 17-046) - The report captures the lessons learned from prototyping interoperability of 3D Tiles and I3S using: a 3D Portrayal Service, performance studies of 3D tiling algorithms, and a proof-of-concept of the use of 3D Tiles and I3S as data delivery formats for the OGC 3D Portrayal Service interface standard.

  • OGC 3D Portrayal Service 1.0 Standard (OGC 15-001r4) - The OGC standard specifies how geospatial 3D content is described, selected, and delivered. The standard provides a framework to determine whether 3D content is interoperable at the content representation level.

  • OpenAPI (v3.0) - OpenAPI is a freely-available API description framework that provides a developer with programmatic access to a software application or service. These APIs use sets of technologies that enable websites and/or client applications to interact with each other by using REST, SOAP, JavaScript, and other web technologies. These APIs have allowed web communities to create an open architecture for sharing content and data between communities and applications. A very typical application for an OpenAPI implementation is to access data such as: Tweets, geolocation(s), maps, stock quotes, weather sensors, and so forth. Since 2016 OGC members and staff have actively been investigating OpenAPI (and its commercial equivalent, Swagger). OGC Members and staff recognized that the existing OGC Web Service Standards (OWS) were in effect web APIs, but that modernizing how they provide content via the web required a fundamental change in underlying design. Two documents further advanced the idea: 1) the OGC Open Geospatial APIs White Paper and 2) the Spatial Data on the Web Best Practices, jointly developed by the OGC and the W3C memberships. These documents highlighted how geospatial data should be more native to the architecture of the web. Further, OGC staff worked on “implementer friendly” views of OGC standards and experimented with an OpenAPI definition for the Web Map Tile Service (WMTS) and became aware of work by the United Kingdom Hydrographic Office (UKHO) to publish OpenAPI definitions for the OGC Web Map Service (WMS) of Electronic Navigational Charts.

  • OGC API - Features - Part 1: Core standard (OGC 17-069r3) - This OGC standard provides API building blocks to create, modify and query features on the Web. This standard specifies the fundamental API building blocks for interacting with features. The spatial data community uses the term 'feature' for things in the real world that are of interest. The standard is part of the OGC API family of standards. OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. Most recently, the OGC Web Feature Service (WFS) and Filter Encoding Service (FES) Standards Working Group rebuilt the WFS standard to the new OGC API - Features standard with an integrated OpenAPI definition as core to describe how to build against the standard. The patterns used to define the OGC API - Features standard are being used to advance other OGC standards as OpenAPI definitions. This work can be reviewed on the OGC API - Features standard webpage.

  • OGC Testbed-15: Maps and Tiles API Engineering Report (OGC 19-069) - This Engineering Report was developed as part of the Testbed-15 initiative [1]. It is not a standard, but reflects the latest work on Web APIs to access and manage maps and 2D tiled data.

  • OGC Testbed-15: Styles API Engineering Report (OGC 19-010r2) - This Engineering Report was developed as part of the Testbed-15 initiative. It is not a standard, but reflects the latest work done in OGC on styles for 2D data. The Styles API is a Web API that enables map servers and clients as well as visual style editors to manage and fetch styles [2]. The API is consistent with the emerging OGC API family of standards. The API complements the Features, Maps and Tiles APIs and builds on the conceptual model for styles developed in OGC Testbed-15. This report specifies the API using OpenAPI, specifies how the same styles should be represented in a GeoPackage and documents the lessons learned during the implementation.

  • OGC® Routing Pilot ER (OGC 19-041r3) - This Engineering Report was produced by the OGC Routing Pilot. The Pilot assessed an abstract baseline suite of functions, capabilities, and encodings to address a common standard interface for network routing functionality [3]. This included guidance for extending the Routing API to account for various routing data models and support for network routing engine configuration via the Routing API. The engineering report is not an OGC standard, but it was delivered to the OGC Standards Program for further consideration.

7. Architecture

This section describes the architectural context of the Pilot as well as relevant architectural perspectives on the software designed and implemented to demonstrate solutions to Pilot requirements.

7.1. Enterprise architecture

The high-level architecture of the Pilot scenario is based on the needs of various types of entities and/or systems ('A'), ('B'), and ('C') in a distributed enterprise as illustrated in Figure 1. The three systems differ in the volume of data that can be stored and processed, the available bandwidth for data transport between entities, the multiplicity of supported analytics, and the offered data products. Despite these differences, the goal of this Pilot was to develop a model that allows offering, discovering, requesting, and processing data at each entity using a common API on top of a single organizational model of 3D geospatial data in space. At the same time, this common API should leverage available 3D geospatial data formats and distribution standards such as 3D Tiles, I3S, CityGML, and CDB to ensure that users can work with 3D geospatial datasets by means of the optimal distribution format and interaction method for their specific application task.