Interoperable Simulation and Gaming Sprint Engineering Report

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.

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.

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:

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.

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

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

Contacts

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.

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.

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.

All participants could elect to use other datasets, particularly any of those from the OGC 3D Data Container and Tiles API Pilot (aka "Pilot") [2]. In particular, much use was made of the New York data set.

The San Diego CDB was available for download by all participants. Many of the participants made that data available to all participants through the GeoVolumes API on their servers. New York data was also made available through multiple APIs implemented during the Pilot. See Table 1 for a list of available servers.

Several of the Sprint participants also participated in the Pilot. These organizations provided their GeoVolumes API servers for use to everyone during the Sprint. These servers were generally populated with both the New York and San Diego data.

The three 3D Data Container and Tiles API Pilot engineering reports (collectively referred to as "Pilot ER") [14, 1, 2] were made available to all participants prior to kickoff. Subsequent to the start of the Sprint, the Pilot ER was made publicly available. The draft specification is part 2 [1] of the document set. This contained the API specification that was the primary target of the Sprint.

These architecture diagrams were provided with the CfP. Figure 5 illustrates the service architecture of the 3D Data Container and Tiles environment that includes the GeoVolumes API. Figure 6 illustrates access to city-based datasets (in particular for New York, US and Montreal, CA), but only showing the detail for New York City.

Arrows show the potential paths of requests from the clients; data flow is in the reverse direction. The connecting lines indicate conceptual requests and data flows. The actual connections may be distributed across several physical devices.

This figure is presented as an illustration of possible connections. It is not intended to be a complete illustration of all connections or possible data sets.

The CfP described three possible scenarios [6]. Participants could choose to work on any number of these, any variant of these, or one (or more) of their choosing.

These scenarios were designed to test and explore portions of the draft GeoVolumes specification that OGC and the sponsors felt were not sufficiently explored in the Pilot. They derive directly from the discussion from Chapter 10 of the Extended Executive Summary [2]. In addition to the listed scenarios, participants were invited to explore other areas that fit within the opportunities described in Chapter 10. Some of the participants did use this option to explore other capabilities, especially related to game-engine integration. The Findings chapter of this report discusses the participant’s scenario choices.

This section describes findings of the Sprint participants. Each finding presented here is significant in that is was reported by at least two participants or it was a serious issue reported by a single participant.

Not all participants investigated the same aspects of the draft Specification. This approach enabled fairly expansive testing of the draft Specification and related areas.

Each participant was free to choose which one (or more) scenarios to pursue. Three scenarios were discussed in the CfP [6]. Participants could also create their own scenario. OGC reviewed each participant’s proposal and suggested revisions to better align with the goals of the Sprint, the interest of the Sponsor, and the coverage by the other participants. Table 2 provides a summary description of the selected scenarios. Table 3 shows the coverage of scenarios by the participants.

All participants cooperated with each other in various aspects of the Sprint. This included a team entry, providing data services for the Sprint, and use and testing of other OGC API services.

Two teams were formed. Three participants, CAE, Cesium, and Cognitics, teamed together to produce a combined result. This was done with the knowledge and approval of the sponsor. A two participant team (Ecere and Steinbeis) was formed to test the insertion, modification, and deletion of 3D objects and terrain into the base scene.

All participants cooperated and included the test and use of other participant services during the Sprint. Use and testing was performed by all members agains OGC GeoVolumes API services offered by others. Table 4 shows the interoperation between offered services (servers) and uses (clients).

The work done for the Sprint was closely tied to the work done for the Pilot, even though some of the participants were different between the two initiatives. The mix of participants allowed some with extensive experience in GeoVolumes to dig deeper into areas that were not fully explored during the Pilot. Participants who were not part of the Pilot brought a fresh read to the document along with potential solutions.

No defects in the draft specification were discovered, though several items need further investigation. These are discussed in the Discovered Inconsistencies section. Several participants discussed the importance of GeoVolumes following the OGC API Core, Volume 2: 3D Data specification to ensure compatibility throughout the suite of OGC APIs.

In addition to the results shown in Table 4 the participants were able to use their existing GeoVolume client software to access data-stores that had not been previously used by OGC and OGC projects. These data-stores included data in CDB and other formats that either were served directly (as 3D Tiles static files) or generated on-the-fly from CDB and other sources.

Steinbeis extended one of the scenarios to include the integration of SensorThings API [15] to illustrate how these two APIs could work together (SensorThings API Server for Urban Mobility). There were no inconsistencies or other issues found.

It is worth mentioning that two participants (CAE and Cognitics) have hosted their services on Amazon Web Services (AWS) to improve throughput and allow for easy load expansion when needed. The use of cloud services was smooth and without issues. These were not tested for heavy loads, load balancing capabilities, or performance.

Several of the participants developed the capability to update part of the dataset during operation. These updates do not require regeneration of the entire dataset from the data-store. There are mechanisms to ensure that any generated and cached files are appropriately rebuilt on the next request.

Ecere, Steinbeis, and Hexagon addressed the insert/update/removal models using the OGC API - Features standard. The specified API proved sufficient (but not necessarily ideal) to perform these functions within the context of GeoVolumes API and the Sprint. Ecere proposed an extension that provided a better interface to refer to models. All of these participants did note that getting the models to align with the local terrain was not a simple matter and required different solutions depending on how the client was designed and configured.

Nearly all of the participants noted that conversion of CDB to 3D Tiles was an expensive operation and needed to be avoided especially for on-the-fly requests. Cesium noted that in addition to the performance issues associated with conversion, the high-detailed building files are (generally) very large (50-100MB), and improving the tiling scheme is needed to maintain performance of the server and client.

Another issue noted by Ecere and Cesium (among others) was handling the creation of glTF files. In particular the manipulation of meshes. Some of the supporting libraries may require a particular condition (e.g., each mesh only uses a single material) while the output may require a single mesh with multiple materials.

Several of the participants discovered various issues related to HTTP transactions. These include issues in the URL, request method, content-type, and, request attributes. The issues and possible solutions are interrelated. Each issue is linked to the section of the participants report where it is discussed in detail.

SimBlocks.io worked on integrating their solution into the Unity game engine. There was quite a bit of work to do bringing in the 3D data as glTF or 3D Tiles into Unity. The solution they developed during the Sprint is sub-optimal, but it did work. They reported that they felt the solution for the Unreal engine would likely require a similar amount of work.

The focus of the analysis of data was centered upon the generation of 3D Tiles and glTF models from a CDB data store. This activity exercised the National Geospatial Intelligence Agency’s Foundation in GEOINT 3D (FG3D) pipeline and the United States Special Operation Command Rapid 3D (R3D) architecture. The resultant data was reviewed for anomalies encountered with those 3D formats from the original CDB content.

CAE provided the San Diego v4.1 CDB for participant use in the OGC ISG Sprint [13].

The San Diego CDB v4.1 is a single geocell (1° latitude by 1° longitude) with the southwest corner at N33 W118. The CDB coverage is considered Medium Resolution and contains a High Resolution inset in the San Diego area.

The CDB dataset contained elevation (GeoTIFF), imagery (jpeg2000), 3D models with textures (OpenFlight [5]), road and hydrography vectors (ESRI shapefiles). The 3D models were a mixture of GSFeature and GTFeature representations. The base imagery was populated in the high resolution area to CDB Level of Detail 9; equivalent to 0.0212354 meter resolution.