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.

The dataset was created with open source data provided by the United States Geological Survey and the San Diego Geographic Information Source.

From the full CDB geocell, a smaller subset of data was used as a focus for this analysis.

Two independent workflows were employed for CDB data generation and conversion. One for the translation of CDB datasets to 3D Tiles. The other for the creation of a new CDB OpenFlight model from full motion video converted to glTF.

Original CDB content rendered in Presagis VegaPrime showed no apparent content loss once the data was converted to 3D Tile. The comparison was made as rendered in Cesium ion and Cognitics Dragonfly.

The initial 3D Tile rendering in Dragonfly appeared too dark compared to the original content and surrounding basemap. To mitigate the noticeable difference in brightness the Cesium3DTileset object was created with the property imageBasedLightingFactor: new Cesium.Cartesian2(5,5) set.

The glTF model generated using FMV source was visually no different then the CDB OpenFlight model.

The original CDB to glTF convertor utilized in the FG3D data translation service, placed all textures associated with the glTF in a subfolder. This proved problematic for several of the glTF rendering platforms that were used to verify glTF compliance. Therefore, modifications were completed to collocate the textures with the model geometry.

The final result of placing the glTF model in the 3D Tile scene required manual editing for geopositional placement. In CDB a corresponding shapefile would provide the positioning information for transmission.

Further analysis and consideration needs to be conducted in the following areas:

In this Sprint, the Cesium team focused on investigating the optimal method of serving 3D content from a CDB dataset into a web viewer. The team achieved this by developing a CDB to 3D Tiles converter and evaluating runtime performance by loading the converted San Diego test data in CesiumJS. The idea of converting the test data to 3D Tiles on-the-fly with partial updates was explored, however, there was not enough time to implement that in this Sprint.

A parallel stream of effort involved building on our work in the 3D Container and Tiles API Pilot and integrating the GeoVolumes API into Dragonfly, a web based 2D/3D common operational picture (COP) platform built in support of the Global Situational Awareness (GSA) program.

In collaboration with Cognitics and CAE, the team aimed to build on work done in the OGC 3D Container and Tile API Pilot. The goal was to integrate the GeoVolumes API into Dragonfly, a common operational picture platform built to provide global situational awareness. Dragonfly uses OGC WMS as the vehicle for organizing and serving 2D data, but there was a need for a container for all the 3D data that was available to the user. The chosen format for 3D data was the OGC 3D Tiles format.

On the backend, the team set up the GeoVolumes API to enable querying data on the client side, based on the bounding box of the current view of the map. The second part of the work involved setting up an endpoint to ingest 3D Tiles created by Rapid3D, a tool to used to generate 3D data from full motion video, and adding it to the available GeoVolumes collections. In the user interface, the team added the ability for a user to "discover" the bounding box of a 3D collection by hovering over it in the GeoVolumes list, as shown below.

Cesium worked on two different tracks during the Sprint - CDB to 3D Tiles conversion and GeoVolumes experimentation in Dragonfly - and a future goal was to see how these two efforts converge. For example, future work could extend the GeoVolumes API to support on-the-fly CDB to 3D Tiles conversion when a particular area of interest was selected.

Another future goal is to explore the conversion process from CDB X to 3D Tiles next, once those specifications are further along. This would improve interoperability between CDB and the Well-Formed Format for One World Terrain. Efforts were already underway to use glTF in both formats, and this Sprint helped identify other areas that need more convergence - specifically implicit tiling schemes, raster layers, and per-texel metadata.

In cooperation with CAE and Cesium, the Cognitics team used GeoVolumes to enhance integration between the Global Situational Awareness (GSA) and Rapid3D (R3D) efforts. The current phase of the GSA effort has produced a prototype infrastructure/service called Dragonfly.

Within Dragonfly, a user has the ability to send full motion video (FMV) into Rapid3D for the generation of 3D content. When a production task has completed, Rapid3D provides the content back into Dragonfly for visualization in 2D and 3D (Cesium).

Currently, all content produced in this manner was incorporated into the visualization. It lacked any method for organizing the content for user filtering.

In this Sprint, the Cognitics team:

This provided a realistic scenario for the Sprint while also addressing a real sponsor need.

Dragonfly is deployed in the commercial Amazon Web Services cloud as a series of Docker containers. The Dragonfly web based user interface supports 2D and 3D content and is currently hosted at https://dragonfly.caeusa.com/. The Dragonfly datastore contained both static 3D content and processed content from Rapid3D which was indexed using GeoVolumes and filtered by a visible bounding box. Dragonfly utilized GeoServer for 2D streaming and Cesium Ion for streaming of 3D Tiles. Ion is a robust, scalable, and secure platform for 3D geospatial data that optimizes and tiles it for the web, serves it up in the cloud, and streams it to any device. Cesium 3D content shown in Dragonfly included Cesium World Terrain, and Cesium OSM Buildings. PostgreSQL/PostGIS, OGC CDB, 3D Tiles were all used for data storage.

Dragonfly utilized the GeoVolumes API for selection and of 3D content based on bounding box, rather than displaying all content at all zoom levels. While in 3D view, GeoVolumes was displayed under Overlays in the Main Menu.

When the user was zoomed out to the globe level, the effective bounding box was the entire globe, and all available GeoVolumes overlays were displayed in the table of contents.

As the user zoomed in, the bounding box encompassed only the area shown in the user interface and only the corresponding GeoVolumes overlays are shown. In the figure below, the bounding box includes Beirut and Damascus. When the user hovered over a GeoVolumes overlay, the extent of that overlay was highlighted, as seen in the figure below of the Damascus overlay.

The Vricon SurfaceMesh of Damascus, Syria was static 3D content in the Dragonfly datastore. The figures below show the data in directly overhead and oblique views.

The Fort Story dataset was constructed from full motion video (FMV) that was uploaded via the Dragonfly user interface and sent through the Rapid3D process to generate the 3D content. The figures below show the data in directly overhead and oblique views.

In the OGC Interoperable Simulation and Gaming Sprint, Ecere improved its GeoVolumes API service implementation, based on its GNOSIS Map Server. Some issues were resolved with the CDB importing process. The 3D Tiles tileset generation was improved with support for textures. Caching and other optimizations were also implemented to achieve better performance. Other Sprint participants were able to successfully access and display the 3D data from the San Diego CDB served by the service.

Ecere, in collaboration with Steinbeis, also investigated a mechanism to update 3D content, such as adding, removing or updating 3D models, based on the Simple Transactions extension defined for the OGC API - Features specifications.

Although Ecere focused on the server-side aspect during the ISG Sprint, some performance improvements were still made to the client to better deal with the large dataset used.

In this report, Ecere also presents some considerations for the standardization of the GeoVolumes API based on its experience as both client and server developers, as well as involvement in other OGC Innovation and Standards Program activities.

The server provided by Ecere is based on its GNOSIS Map Server which implements support for the new OGC API family of standards. The GeoVolumes API defines the bridge between the OGC API - Common - Part 2: Geospatial data and 3D data. This 3D data is typically defined as Bounding Volume Hierarchy to facilitate culling out data outside the view frustum as well as to retrieve and display the right amount of detail. This is the case with both the 3D Tiles and i3s OGC Community Standards. However the same collection of data could also be accessed using other OGC API specifications, such as Features and Tiles, as demonstrated in this implementation. The GNOSIS Map Server implementation currently support generation of 3D Tiles on-the-fly from a source data store.

In the 3D Container and Tiles Pilot, Ecere improved client-side support for visualizing 3D Tiles and performed a number of TIEs with GeoVolumes API implementations from all other participants of the pilot, as well as with the GNOSIS Map Server using the Tiles API and associated extensions for 3D data. The result of those TIEs are demonstrated in a video and discussed in the 3DC&T engineering report.

For the ISG Sprint, Ecere spent efforts mainly on improving the server component and investigating a mechanism to update the 3D data.

However some performance improvements were done on the client to better accommodate the large amount of detailed models and full resolution textures of the San Diego CDB dataset. An issue with the rendering of referenced 3D models, where an applied orientation was not taken into account to light it properly, was also resolved.

Sample screenshots of GNOSIS Cartographer visualizing the imported San Diego CDB follow. In addition to this dataset, worldwide elevation data from Viewfinder Panoramas by Jonathan de Ferranti and imagery from NASA Visible Earth’s Blue Marble are used outside of the extent covered by the San Diego dataset.

This last image features ESA Gaia’s Sky in colour (Gaia Data Processing and Analysis Consortium (DPAC); A. Moitinho / A. F. Silva / M. Barros / C. Barata, University of Lisbon, Portugal; H. Savietto, Fork Research, Portugal.) CC BY SA 3.0.

Ecere feels that there are still important adjustments to be made, and questions to answer with regards to the GeoVolumes API draft specifications for it to progress towards becoming an OGC standard, and in particular to integrate well within the new OGC API family of standards.

The formats that were handled by the draft GeoVolumes API in the previous pilot were i3s and 3D Tiles. These are community standards that serve out 3D data through a particular bounding volume hierarchy. But there are a wider range of formats that can be served directly (such as CDB or CityGML), or can be transformed to an intermediate state for easier transmission over the web - for instance a 2D tile matrix set or implicit tiling tileset. The structure of these datasets should lend itself to the OGC Tiles API. So an important question is where is the boundary between APIs in the OGC ecosystem – is it a fuzzy boundary? Is there no problem with having both types of API under the same collection, as long as everyone uses OGC API Common as the core consistently? So far the structure of the GeoVolumes API follows OpenAPI Common Part 2: Geospatial data, which includes a landing page, a list of collections (including filtering by bbox), a collection description (including a link to the data) and filtering on the data itself (e.g., through a bounding box). Any future extensions to this part of the specification should be made with caution so as to not break interoperability with the other nascent OGC APIs.

The term used here for serving different representations of the same data as different services, formats or links is an alternate distribution. In the sprint the team considered some issues around alternate distributions.

This was done with the assistance of a survey tool, to poll sprint participants on their views of how the draft specification was structured, and what defines an alternate distribution. Unfortunately there was not a lot of uptake of the survey, however some useful information was gained. It is recommended that if this type of survey were used more widely, it could provide useful insight into the general consensus around specification issues.

At the OpenAPI Common level, alternate distributions are only really discussed in terms of JSON or HTML representations of server responses. However, it can be posited that the different OGC API standards are all alternate distributions of a collection of geospatial data. So the same source data could be converted and served in different ways – either with a manual conversion or on the fly (e.g., to 3D Tiles, i3s, a 2D representation of the data, or as features).

The following sections discuss how alternate representations can be found at different levels, and potential issues and recommendations around this that can be put forward to the DWG.

The below diagram summarizes what is believed to be the different levels of decision point when creating a GeoVolumes resource, of which all of them have the potential to represent the same data in different ways, thus creating alternate distributions.

The most instinctive way to thing about alternate distributions is to think about alternate data types. For instance in terms of 3D data this may be gLTF data, it may be CityGML, it may be as CDB, or as a tileset. It could be that the same city model can be presented using different formats. In this way, an alternate distribution can occur purely considering the data level.

One step on from representing alternate distributions at the data level is at the service level. When considering 3D, this relates to community standards such as 3D Tiles or i3S – where data is transformed into an efficient format for serving over the web. Serving these alternate representations has been explored for a few years and has culminated in two community standards.

Turning the data level into the service level could be a pre-processed event, such as with our static server, or could use an on-the-fly conversion service such as some of the other participants in the sprint.

Another step further from the service level, is the means by which these services are structured for clients to interact with it. This considers the mechanism by which clients request and get responses from a server as a particular type of distribution. The goal is to have a common starting point and landing page, and to display the collections within, but then to differentiate based on the particular structure of the distribution format. In order to bring both 3D Tiles and i3s under the same banner, the draft GeoVolumes API was designed, folding both of these community standards into an OpenAPI common structure. Other draft specifications include OGC API - Tiles and OGC API - Features.

The draft specification built in the pilot mainly dealt with the structure of the landing page, what is considered a resource, and provided demonstration services broken out by geography. It concerned itself primarily with 3D Tiles and i3s, with the departure from OGC API Common being the bounding volume hierarchy and specific community standard formats from this point on.

In terms of what is in scope of the GeoVolumes API from an alternate distribution perspective, it was considered that many of the 3D data formats could ultimately be served using the GeoVolumes API, however whether serving them directly as raw data (such as the CDB example) counts that need to be clarified in the draft specification. In addition, there was talk that the GeoVolumes API could be extended with for instance the draft 3D Tiles implicit tiling scheme [18] discussed by Cesium. This would be the equivalent of the tiling schemes that fall under the Tiles API, but tailored for working with 3D data. A further discussion should be had to decide whether a 2D Tile map scheme served through the 3D Tiles implicit tiling scheme falls under the GeoVolumes API or not. Key questions are:

The team’s thoughts are that what differentiates the GeoVolumes API is the ‘bounding volume hierarchy’ structure of the two community standards. If this were the distinction, in this case neither does serving 3D data as 2D tiles, and so the OGC Tiles API, despite serving 3D data, would also not be in scope of the GeoVolumes API. Indeed the Features API could also serve features that have 3D content, but does not have a bounding volume hierarchy.

At the collections and collection level, the response from the API is typically either a JSON or HTML response. This is the most common case where alternative distributions are found within many APIs. At this point in the GeoVolumes API, the collections are listed, along with link relations and media types that tell the client what format to expect.

Once the data, the service and the API are chosen, there are still more decisions to be made on how to represent alternative distributions within the GeoAPI structure. In the pilot, each sub-resource on the server had its own endpoint such as the below:

http://server.com/collections/SanDiego/SanDiego-buildings/3dTiles

http://server.com/collections/SanDiego/SanDiego-buildings/i3s

This could then be expanded as other community standards are embraced – for instance if the implicit tiling scheme was decided to be in scope by the working group, this too could have its own endpoint:

http://server.com/collections/SanDiego/SanDiego-buildings/iTiles

(or whatever the implicit tiling scheme is named).

However there is a separate school of thought that there could also (or instead) be a common endpoint with a parameter instead deciding which representation of the resource to return, so that the client can use content-negotiation (Accept: header) to select the desired representation. For instance:

http://server.com/collections/SanDiego/SanDiego-buildings/bvh?f=3dTiles

http://server.com/collections/SanDiego/SanDiego-buildings/bvh?f=i3s

http://server.com/collections/SanDiego/SanDiego-buildings/bvh?f=iTiles

(or whatever name the implicit tiling scheme is named).

The use of parameters for content negotiation of the resource is currently not discussed in the draft GeoVolumes API but could be elaborated upon. Whether this is used in addition to the current API structure, or is even taken back a level so that:

http://server.com/collections/SanDiego/SanDiego-buildings?f=3dTiles

referenced the 3D Tiles endpoint is not agreed upon. Also please note that this does not preclude also changing the parameter value further down the path (for instance f=b3dm to bring back the final bounding volume).

It has also been discussed that the collectionId cannot contain slashes and the GeoVolumes API is currently not compatible with the OGC API family of standards if they currently allow slashes. A ‘:’ structure has been proposed for hierarchy structures [19], however for the most simple web servers hosted on Windows, folder names that will be served cannot contain ‘:’ in their name and therefore may cause issues with interoperability. It is suggested this is discussed further in the Domain Working Group. As servers become more complicated with different data levels, this will need to be standardized.

As discussed, from within a single API, defining a resource or sub-resource as an alternate distribution can typically be done using a link relation. OGC API Common refers to IANA’s definition that an ‘alternate’ link relation is ‘a substitute for this context’. Link relations are also discussed within the 3D Container ER, with a slight extension to include parent and root link relation types [20]. If the W3C guidance around link relations are considered, a couple of points are made:

The last paragraph is interesting, as it suggests that more than one alternate distribution can be present for a particular resource, but that they are all alternative representations of the original. So the original could be served as 3D Tiles, but a second alternative distribution could be served as i3s, and a third as an implicit tiling scheme, for instance. So putting endpoints, parameters and link relations together the endpoint of each alternate distribution should also reference the endpoint of other representations of the same data using link relations. These can be chosen using the href of the link or by a url parameter.

As discussed above, alongside the ref: alternate link relation, should be a related type attribute, which relates to the media type (previously MIME type). The media types explored in the pilot were predominantly application/json+i3s and application/json+3dTiles. These are not currently registered with IANA, and as such need to be officially / successfully registered to be official.

Note that this doesn’t preclude other media types being used further down the path (e.g., application/json).

Ecere suggested that if this were not possible, an alternative would be to use the application/JSON type, with a particular approach agreed upon in OGC API – Common that was common to all, to lay out the schemas in a standardized way.

What is suggested based on this understanding is that there is a hierarchy of alternate distributions for 3D content:

There are some cases which could be construed as an alternate distribution such as:

It is suggested that 1-3 are different resources instead of different distributions. Number 2 is tricky, as if the same resource were served as 3D Tiles from different servers, but once is federated or daisy-chained through to the second server, it is suggested that this is a different resource. However if it was presented to the client as a different distribution type (3D Tiles whereas data on the server is I3S), such as number 4, it could instead be interpreted as an alternate distribution of the same resource, and the endpoint and link relations would need to reflect this.

This could be defined more by the working group to understand better the scope and differentiation of the ‘original’ and ‘alternate’ link relation tag.

During the survey, the team also asked whether the link relation was used by the clients to identify which was an ‘original’ resource or which was an ‘alternate’ distribution. It wasn’t directly used from the small response received, and instead, it would need to be reflected in the resource title or associated metadata. This may need further consideration as servers become larger with many links to alternate distributions, as it might start to become confusing in the client which is the ‘original’ resource if it is not published with it in the title.

The draft specification was also considered to see if it was compatible with the OpenAPI conversion tool Shapechange. The draft specification was compared to recent work done in OGC Testbed-16, which considered OpenAPI Common and OpenAPI Features: part 1 Core. As the GeoVolumes specification essentially takes its core from OpenAPI Common, the draft specification is considered to be compatible with this workflow. This means that a UML model of the draft specification can be created, and then this can be imported into Shapechange to convert it to JSON. This JSON can then be used as an API template for Swaggerhub or another API tool. This process is currently in draft for Testbed 16, but more will be released soon.

Having a clear understanding of the alternate distribution options available at each stage of the standardization process, knowing where to standardize, and where to provide tailored structure for particular distribution types helps to demonstrate how flexible and adaptable the OGC OpenAPI model is. We hope these discussions have highlighted a few areas where questions may occur in future, that could be clarified as part of development of the draft API. It was encouraging that the pieces of OGC API Common fitted well with the 3D data handover in the pilot, and that the conversion from CDB to 3D Tiles has been equally smooth in this sprint, suggesting a promising way forward for the GeoVolumes API.

This chapter investigates how model and terrain updates, originating from a CDB data store and delivered as glTF or elevation, were integrated with background elevation and OGC 3D Tiles into the client environment.

For a large data set, all the meshes from the CDB data store were converted to an OGC 3DTiles tileset. Displaying the resulting pre-processed OGC 3DTiles offers performance and visual quality advantages over reading the CDB data store directly. The increased efficiency was due to a better tiling scheme and mesh simplification.

Generating tiles on the fly was attempted with mixed results.

OGC 3DTiles can be automatically adapted to elevation updates, whether they come from a CDB data store or another source. This was achieved through a proxy service that reads B3DM files and adjusts the height of the vertices before forwarding them to the client. The possibility to do this at render time, on the client, using GPU evaluated expressions was also explored.

Using GPU evaluated expressions, deletions/updates/additions in the CDB data store were handled by pushing down background OGC 3DTiles. The old and new models integrated seamlessly, and there was no need to reprocess the entire dataset to create a single coherent OGC 3DTiles tileset.

The research was based on the San Diego CDB sample dataset provided for this Sprint. It provided imagery, elevation, 3D models and a variety of vector data.

This section recaps the organization of CDB data for 3D models.

CDB uses a tiling system where higher Levels Of Detail (LOD) add more mesh models. Single buildings also had several LODs embedded in a single file. While CBD has the flexibility to achieve anything visually, it was complex to decode on the client or to process on the fly. This section describes an approach to convert the entire CDB 3D models to a more efficient OGC 3DTiles tileset through a pre-processing stage.

When converting to 3DTiles, only the highest LOD for every 3D model was taken into account to re-generate a complete tileset.

The new LOD structure was an octree where child nodes entirely replaced parent nodes.

Creating this structure was a recursive process that repeated the following steps: tiling → grouping tiles → simplifying → re-texture.

The pre-processed tileset could display more buildings at low LODs than would be possible by loading the raw files from the CDB data store even if the distant buildings were simplified meshes with just a basic texture.

Serving 3D Models on the fly meant that whenever a client application looked at the data from a certain angle, it would send a request to the server that must gather the data to be visualized and convert it to glTF on the fly.

On the fly 3DTiles also meant that updates to the CDB data-store would be directly taken into account without needing to reprocess the entire CDB data-store every time.

At startup or when an update was detected, the (on-the-fly) server created a tileset.json file by decoding and indexing the bounds of all the 3D models into an octree structure. This process took around 5 minutes on the San Diego Dataset which contained about 6Gb of mesh data. Each node was given a name and a tileset.json file was generated. The client therefore requested tiles that didn’t exist yet because the server generated them on the fly.

The LOD structure of the CDB data store wasn’t used because in this particular case, it was inadequate. If the CDB data store LOD structure could be used, the process would become almost instantaneous. A good LOD structure is one that is deep and has small tiles of approximately the same size.

When a tile was requested, the relevant meshes would be loaded, converted to glTF, wrapped in a B3DM file and sent back to the client. The approach of simplifying meshes for lower LODs could not be done in real-time because it was too slow. Simply dropping out smaller buildings for lower LODs would have to be used.

A common issue was mismatch between terrain and 3D models that were typically served through different services.

In order to circumvent this issue, CDB datastores provided the elevation model that the 3D meshes should fit onto.

However, In order to serve very large 3D mesh datasets, they are typically pre-processed with embedded elevation. This meant that updating the elevation model would cause a mismatch with the 3D meshes.

The image on the left shows a mismatch between the elevation model and the 3DTiles. The image on the right shows a perfect match between the two.

3D Meshes could be displaced at render time using GPU evaluated expressions. This technique allowed handling 3D model updates and ensuring that there was no overlap or mismatch between data sets.

When 3D data was served on the fly from a CDB data store, updates were taken into account automatically. However, pre-processing a large data set has several advantages in terms of visual appearance and performance. In addition, model updates might originate from other sources than the CDB store itself.

On the fly vertex displacement offered a solution for small model updates where the new data was processed into a separate 3DTiles tileset. The original vertices that were part of the base 3DTiles tileset were squashed below the new data and the result was a perfect integration. This tactic was only usable for smaller updates like a single building or a small area. For a more general solution, Serving OGC 3DTiles from CDB with on the fly tiling offered the most flexibility.

The GeoVolumes API draft spec allowed for querying geospatial data based on properties like bounding box, data format, and other extents of the data. The main goal of the ISG Sprint was to test interoperability among various server-client interactions facilitated by the GeoVolumes API. In short, participants tested how the GeoVolumes API could be served to reliably request and display data among different clients.

All participants were given access to the San Diego CDB, and the standards for the GeoVolumes API and CDB were given. Participants were also expected to visualize the data contained within the CDB. Over the course of the event, participants were able to discuss a range of potential uses as well as concerns over the specific role of GeoVolumes. This section of the report will cover InfoDao’s experience during the Sprint and will reference side conversations with other participants.

As a quick summary, InfoDao was able to use the GeoVolumes API to quickly and reliably retrieve information. The ease of query generation coupled with the accessibility of 3D Tiles (e.g., glTF/GLB as 3D data and Transform matrix as location data) allowed InfoDao’s clients to visualize the CDB data with minimal development overhead. When compared to a standard like the CDB, the simplicity and accessibility of the data were greatly highlighted; taking implementation from 1 week for CDB to less than a day for 3D Tiles.

Resulting from the conversion of CDB to 3D tiles, a theme arose in discussion about how to ameliorate the differences among these standards. For instance, while InfoDao’s client was able to access and display content from a CDB (utilizing the STAC specification from an OGC API implementation), it was not immediately accessible from a GeoVolumes perspective. On the other hand, CAE produced a separate 3D Tiles distribution that allowed participants to more easily serve the GeoVolumes API. This worked well for the purposes of the Sprint, however, there is a question of the methods of supplying multiple data distributions from one source of data.

Helyx’s Sprint report contains great starting discussion on the various formats and delivery methods the OGC has standardized, and conversations with Ecere also highlight the similarities and potential future work actions that could resolve these issues.

But before getting into the weeds, here are the results.

Here are the images from the TIE testing.

GeoVolumes performs well and is easy to implement, however it is not free from issues. While it is easy to see it as a wrapper for accessing geospatial data, the OGC has similar containers for other data formats. This Sprint highlighted the roles and limits of GeoVolumes and its supported data formats (glTF and JSON) by taking its contrast with CDB. InfoDao’s experience with the Sprint also discovered similar enquiries to Ecere’s issues in using the OGC API as a potential bridge between the two standards (whether by extension specification or in the core specification).

This Sprint Report reviews the participation of SimBlocks.io in the OGC Interoperable Simulation and Gaming Sprint, which was held from September 21 through September 25, 2020.

The purpose of the OGC Interoperable Simulation and Gaming Sprint was to advance the use of relevant OGC and Khronos standards in the modeling and simulation community through practical exercise and testing of the OGC GeoVolumes API draft specification, including data formats included in the processing of 3D models pass through the OGC GeoVolumes API such as 3D Tiles and CDB. The SimBlocks team submitted a proposal in August in response to an open call for participation in the sprint and was accepted within a week. SimBlocks agreed to participate in the sprint and also join the Open Geospatial Consortium as an Associate Small Company Member. This report will provide a fresh perspective on the OGC GeoVolumes API from a company that did not participate in the previous 3D Data Container and Tiles API Pilot.

SimBlocks specializes in connecting commercial gaming technologies with real-time 3D visualization applications by supporting industry standards for geospatial terrains, 3D models, and communication interoperability. SimBlocks has created a whole-earth visualization tool using the COTS Unity game engine capable of rendering the entire globe at any location at multiple levels of detail for imagery and elevation data. The One World SDK for Unity can consume geospatial data from cloud providers using web services APIs to process imagery, elevation data, and vector data. SimBlocks has tested ingesting data over web services including from Microsoft Bing Maps, OpenStreetMap, and a CDB web service provider.

The One World SDK for Unity also supports direct loading of high-detailed content insets using a variety of modeling formats, including OpenFlight [5], OGC CDB [4], and OGC GeoPackage [22]. SimBlocks has also recently prototyped solutions to integrate 3D Tiles and glTF models in Unity by connecting to Cesium Ion. The SimBlocks team has found that Unity is a very capable development tool that is well suited for prototyping visual applications with deployment capabilities for virtual reality and augment reality devices.

SimBlocks has been operating for over 4 years and is located in Orlando, Florida at the University of Central Florida Business Incubation Program at Research Park.

The OGC GeoVolumes architecture separates visual client applications from servers holding the 3D model content. The exact format of the models is hidden from the client. From the perspective of the client, the main benefit of the GeoVolumes API is that fewer 3D model formats need to be supported and accessing the models for a known area becomes very simple. From reviewing the 3D models provided by the servers, 3D Tiles content (including glTF) is the primary format that was necessary to be supported by the Unity-based client.

SimBlocks agreed to review communicating with the various servers developed by other participants in the Sprint. The SimBlocks team first checked if the URLs for the Landing Page, Conformance, api, Collections, and 3D Container pages existed. If so, each of the pages would appear as a webpage in a browser in the form of a human-readable JSON file.

Once the servers were reviewed, the SimBlocks team attempted to retrieve the models from the servers and save the B3DM files. During this process the SimBlocks team confirmed that it was necessary to accommodate whether the server contains their models as URLs (Steinbeis) or URIs (Cesium, Cognitics, Ecere, Helyx, InfoDao). The team identified that some servers with URIs intended for the B3DM files to be relative to the domain (Ecere) and others intended for the files to be appended to the URL of the current endpoint (Cesium, Cognitics, Ecere (Pilot), Helyx, InfoDao).

Page addresses and TIE testing notes are presented in the tables below.

Some of the landing pages point to service description links that are different from /api. Working links were included in this table.

After successfully retrieving models from most of the servers, the team developed tools for converting and loading the building content.

Additional TIE testing results can be found in the Technology Integration Experiment (TIE) Table.

This section describes the methods the team used to import glTF content into Unity. Because the Unity Editor does not currently directly support 3D Tiles or glTF content, the SimBlocks team reviewed several open source repositories to see how well they worked. Eventually, the team included an approach of developing its own 3D Tiles importer.

The SimBlocks team found the OGC GeoVolumes Sprint to be very useful. Additional work items that the team would like to continue experimenting with processing geospatial content using real-time 3D game engine technologies are:

After discussing with Unity’s geospatial team, the SimBlocks team identified a 4th method of conversion that promises to be even faster than Method 3 (Directly load B3DM) while also allowing use of native C++ code.

In the ISG Sprint, the Steinbeis team developed a 3D web application for simulating modern urban mobility such as air-taxi or E-bike in the 3D urban environment. In this application, the concept and implementation used the GeoVolumes API for managing the standard 2D or 3D static geospatial resources including building models, road network, tree, imageries, and terrain. At the same time, dynamic moving data such as taxi, air-taxi movement, e-bike movement was managed by the OGC SensorThings API standard.

The client application was based on CesiumJS framework. It was partially based on the implementation from the Steinbeis OGC 3D Container and Tiles pilot client. The User Interface menu is shown in the image below which allows users to do following interactions:

With the update pipeline, existing 3D Tiles were updated as the changes were made to the input 3D dataset. The CDB data store was used as the primary dataset in this sprint. The building models were stored in OpenFlight [5] (* .flt) format within CDB store. It was required to setup the OpenFlight to 3D Tiles conversion. FME was used for this purpose. In the following section this conversion from CDB (* .flt) to 3D tiles is discussed.

The nature of this project was to investigate the GeoVolumes draft specification and identify additional areas of investigate for future work. As a result this project generated a large number of recommendations for future work for a project of this size. Most of the recommendations come from the participants. They are listed below, with similar items grouped into sections.

This section presupposes familiarity with the Findings Chapter, especially the Discovered Inconsistencies section and the Conclusions Chapter.