Publication Date: 2021-01-26

Approval Date: 2020-12-11

Submission Date: 2020-11-20

Reference number of this document: OGC 20-087

Reference URL for this document: http://www.opengis.net/doc/PER/ISG-Sprint

Category: OGC Public Engineering Report

Editors: Leonard Daly, Scott Serich

Title: Interoperable Simulation and Gaming Sprint Engineering Report


OGC Public Engineering Report

COPYRIGHT

Copyright ©2021, 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

The OGC Interoperable Simulation and Gaming Sprint advanced the use of relevant OGC and Khronos standards in the modeling and simulation community through practical exercise and testing of the GeoVolumes API draft specification produced by the 3D Data Container and Tiles API Pilot. Of particular interest was the handling and integration of glTF models coming from multiple sources, but the sprint also examined the specification’s implementability, consistency, completeness, and maturity.

2. Executive Summary

The Interactive Simulation and Gaming Sprint ("Sprint") was undertaken by OGC to verify the results of the 3D Data Container and Tiles API Pilot ("Pilot"). The Pilot produced the OGC GeoVolumes API draft specification ("draft spec" [1]). The Sprint was specifically designed to test the coverage and consistency of the draft spec and with respect to other OGC APIs. It was expected that the Sprint would uncover no major issues with the draft spec, but would identify interoperability issues with multiple data stores and between other OGC APIs. The Sprint was not intended as a full-coverage verification and validation of the draft spec.

As indicated in the OGC 3D Data Container and Tiles API Pilot Summary Engineering Report [2], it was important from a business perspective that additional integration tests and real-world deployment demonstrations further explore the potential of the GeoVolumes API draft spec. The implementation and testing work conducted in this initiative went a long way toward resolving any outstanding interoperability issues and exploring best practices for the organization of GeoVolumes within the interoperable simulation and gaming domain.

Another important component in the Sprint was the use of 3D models in (graphics language transmission format (glTF) [3]). This format is of particular interest to OGC because of its emergence as a common (i.e., de facto standard) web transmission model format. The format was developed and is supported by the Khronos Group, which was a partner in the Sprint.

Please also visit the OGC ISG Sprint YouTube Playlist to view participant video recordings.

2.1. Operation

The Sprint implementation work lasted six weeks, primarily during September 2020. The original plan called for a week-long in-person coding effort; however, due to the Covid-19 pandemic, this was changed to a virtual event with each participant providing their own development support.

The primary source data used in the Sprint was from the San Diego CDB dataset, which implemented the OGC CDB Standard [4]. Other data formats such as OpenFlight [5] were also used.

ogc data orientation
Figure 1. The orientation images for the San Diego CDB dataset. The left image is an overhead shot of the San Diego coastline from La Jolla to the US/Mexico border. The red square indicates the data set region. The right image is a rendering of a portion of this dataset. Up is approximately north-east with the San Diego Convention Center at bottom center-right. The rendering was created by CAE.

The participants for the Sprint were (in alphabetical order): CAE, Cesium, Cognitics, Ecere, Helyx, Hexagon, InfoDao, SimBlocks, and Steinbeis. Most participants had experience participating in prior OGC projects. All participants were OGC member organizations.

The Sprint Call for Participation (CfP) [6] provided three scenarios. Participants could also propose their own scenario provided that fit within Sprint guidelines. Table 2 provides a summary description of the selected scenarios. Table 3 shows the coverage of scenarios by the participants.

2.2. Accomplishments

All of the participants worked together using each other’s resources and expertise to augment their work. The Technology Integration Experiment (TIE) Table shows the full results of their cooperative work testing their GeoVolumes API implementations and those of others.

Through the development and testing work undertaken in the Sprint, the participants tested a wide range of GeoVolumes API draft spec coverage. No serious defects were discovered, and no major problems with correctness, completeness, or consistency were reported. Significant results that were reported include:

  • Use of a previously unused dataset (San Diego CDB) with the draft spec,

  • Hosting a GeoVolumes API service on Amazon Web Services without issue,

  • Partial integration with OGC’s SensorThings API,

  • Dynamic update of models in the datastore,

  • Dynamic update of terrain used in the datastore, and

  • Partial integration with Unity’s game engine.

2.3. Issues

As expected, the Sprint did identify several issues. Most of these were not with the GeoVolumes API draft spec but with the underlying support. One item that all participants noted (and no solution was provided) was the lack of an optimized conversion between the various data formats that were used. This included CDB, glTF, and OpenFlight.

The participants did investigate issues arising from differences between various OGC APIs. The primary finding was that the OGC API - Common - Part 2: Geospatial Data was a key document. Issues would have arisen if the various functional specifications were inconsistent with this specification. At the time of the investigation, no inconsistencies had been discovered.

Most of the issues with the GeoVolumes API draft spec were in the areas of definitions and use of URLs and HTTP requests and replies. These issues did not prevent the APIs from working, but differences could arise between different implementations in areas where the draft spec does not go into that level of detail.

Three items were identified as involving URLs. Mostly it was a case of determining how the URL path end-point (final component of the path) was used to access specific data format. This is tied in with the issue noted in Media Type. A minor note is that the GeoVolumes draft specification is not completely clear on the server environment. An issue might arise if the server (the part of the system that provides the data through the API) is configured as a file server (responds to the file protocol).

Issues involving HTTP concerned the use of Request Methods, Media Type, and Request Attributes. These issues did not prevent the API from working, but could cause some interoperability issues in larger-scale environments.

Issues with Request Methods addressed how a data change should be made to the datastore. Media types allow the client and server to communicate as to the format of the data. This interacted with the URL issues (described above) by controlling how a specific format of data is requested and received. Request attributes assist in the means to specify alternate or roll-over data sources.

2.4. Recommendations

Seventeen recommendations were made for future work. These items are generally referred to as "projects," but they could be fairly brief and small undertakings by a Domain or Standards Working Group or as part of another effort (Sprint, Pilot, Testbed, etc.) within OGC. Items not directly part of OGC could also be addressed through appropriate joint projects or liaison arrangements with external organizations/groups.

These range from projects external to OGC (four projects) generally carried out by other organizations or community efforts, three data based projects (generally conversion from one format to another), three projects to enhance the GeoVolumes API draft spec, four projects to develop a clear definition of feature (model or terrain) change (part to HTTP Request Method discussed above), and three on API infrastructure (to address the URL and HTTP issues described above).


2.5. Document contributor contact points

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

Contacts

Name Organization Role

Leonard Daly

Daly Realism representing Khronos Group

Contributor & Editor

Scott Serich

Open Geospatial Consortium

Contributor & Editor

Holly Black

CAE

Contributor

Sean Lilley

Cesium

Contributor

Michala Hill

Cognitics

Contributor

Jerome St-Louis

Ecere

Contributor

Anneley Hadland

Helyx

Contributor

Emeric Beaufays

Hexagon

Contributor

Joshua Rentrope

InfoDao

Contributor

Jordan Dauble

SimBlocks.io

Contributor

Patrick Caughey

SimBlocks.io

Contributor

Barbara Cotter

SimBlocks.io

Contributor

Glenn Johnson

SimBlocks.io

Contributor

Joseph Kaile

SimBlocks.io

Contributor

Volker Coors

Steinbeis, HFT Stuttgart

Contributor

Thunyathep Santhanavanich (Joe)

Steinbeis, HFT Stuttgart

Contributor

Harpreet Singh

Steinbeis, HFT Stuttgart

Contributor

Patrick Würstle

Steinbeis, HFT Stuttgart

Contributor

2.6. 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

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 Tiles

3D Tiles [7] is designed for streaming and rendering massive 3D geospatial content such as Photogrammetry, 3D Buildings, BIM/CAD, Instanced Features, and Point Clouds. It defines a hierarchical data structure and a set of tile formats which deliver renderable content. 3D Tiles does not define explicit rules for visualization of the content; a client may visualize 3D Tiles data however it sees fit.

● b3dm

Batched 3D Model (b3dm) [8] allows offline batching of heterogeneous 3D models, such as different buildings in a city, for efficient streaming to a web client for rendering and interaction. Efficiency comes from transferring multiple models in a single request and rendering them in the least number of WebGL draw calls necessary. Using the core 3D Tiles spec language, each model is a feature.

● CDB

The CDB standard [4] defines a standardized model and structure for a single, “versionable,” virtual representation of the earth. A CDB structured data store provides for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various simulator client-devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime simulation tasks. In this case, a CDB is plug-and-play interoperable between CDB-compliant simulators. A CDB can be readily used by existing simulation client-devices (legacy Image Generators, Radar simulator, Computer Generated Forces, etc.) through a data publishing process that is performed on-demand in real-time.

● Full Motion Video (FMV)

Full Motion Video (FMV)-compliant refers to the combination of a video stream and associated metadata into one video file, which makes the video geospatially aware. The sensor systems collect camera pointing information, platform position and attitude, and other data, and encode it into the video stream so that each video frame is associated with geopositional information [9].

● GeoVolumes

GeoVolumes [10] 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.

● IANA

Internet Assigned Numbers Authority is the organization responsible for oversight of the architecture of the Internet. They are ultimately responsible for assignment of IP addresses and management of Media Types.

● jp2 | JPEG2000

It is an advanced lossy compression algorithm for representing 2D data. It is currently not widely supported in browsers, requiring a (CPU-intensive) conversion to JPEG or PNG/GIF.

● OpenFlight

OpenFlight [5] is a file format originally designed as a nonproprietary 3D geometry model format for use by real-time 3D visual simulation image generators. The OpenFlight file format is used today in the high end real-time visual simulation industry as the standard interchange format between different IG systems, and is currently administrated by Presagis [11].

● URL/URI

At one time Uniform Resource Location (URL) was a subset of Uniform Resource Identifier (URI). Now both are considered the same [12].

● W3C

World Wide Web Consortium is responsible for all standards that make the Web operate, including URIs, HTTP, etc.

5. Overview

Section 6 describes the Material and Purpose of the Sprint. All of the material that was provided to the participants is either included here or referenced.

Section 7 presents the overall Findings from the Sprint. The discussion includes material learned from all participants and the Sprint leadership team in carrying out the Sprint.

Section 8 presents the major Conclusions from the Sprint. This represents the collective knowledge and experience of the participants and editor.

Sections 9-17 contain the Participant Detailed Reports.

Section 18 contains the consolidated Future Recommendations. Much of this content was gathered from participant detailed reports.

Appendix A contains a copy of the Sprint Technology Integration Experiments (TIE) Table, with additional notes and comments.

Appendix B contains the document Revision History.

Appendix C contains the document Bibliography.

6. Material and Purpose

6.1. Call for Participation

The ISG Sprint: Call for Participation (CfP) [6] was released on 7 July 2020 by the Open Geospatial Consortium for the purpose of obtaining proposals from organizations interested in furthering study of the GeoVolumes draft specification [1]. The CfP provided all of the material necessary for organizations to make a proposal for participation either by direct inclusion in the document or publicly available links.

The CfP specified a schedule from kickoff meeting (1 September) through the Sprint Week (21-25 September), and participant final report inputs (5 October). The Sprint was originally desired to be in-person; however, pandemic lockdown restrictions required that all participant work be done remotely during the sprint week. This decision was made prior to the due date for proposals.

6.2. Data Sets

The primary data set for the Sprint is known as San Diego CDB (licensed under the SanGIS Legal Notice - SanGIS GIS Data End User Use Agreement and Disclaimer for Data Released to the Public [13]). This data set was collected using a number of sensors and methods from <start> to <end> and encompassed nearly all of the downtown San Diego and vicinity, including the port, sports stadium, recreational facilities, commercial, and housing areas.