1. Introduction

The Open Geospatial Consortium (OGC) is releasing this Call for Participation (CFP) to solicit proposals for the OGC Interoperable Simulation and Gaming (ISG) Year 2 Sprint ("Year 2 Sprint"). This initiative builds on momentum from the ISG Sprint conducted in September, 2020 ("Year 1 Sprint") and reported on in the corresponding Engineering Report (ER).

The primary goal of the Year 1 Sprint was to advance the use of relevant Khronos Group and OGC Standards in the modeling and simulation community through practical exercise and testing of the OGC API - GeoVolumes draft specification.

The Year 2 Sprint is soliciting prototype implementations across a much broader set of existing and forthcoming Khronos Group and OGC Standards and specifications. The primary goal is to discover new ideas and recommendations for advancing the baselines of these two standards-development partners.

The Standard/Specification-to-Scenario Cross Reference table provides a list of candidate Standards and specifications that could potentially be the subject of investigation, though bidders are also welcome to propose others (provided that clear justifications are included).

Another sprint goal is, where possible, to align with the direction of the OGC CDB Standards Working Group (SWG). A draft description of this direction is depicted in the DRAFT CDB Standard Roadmap (subject to change). This potential alignment is informative; proposals are not required to demonstrate conformance. The latest approved CDB Standard can be found at OGC CDB Standard.

1.1. OGC Innovation Program Initiative

This initiative is being conducted under the OGC Innovation Program. This program provides a collaborative agile process for solving geospatial challenges. Organizations (sponsors and technology implementers) come together to solve problems, produce prototypes, develop demonstrations, provide best practices, and advance the future of standards. Since 1999 more than 100 initiatives have taken place.

The initiative will provide an outstanding opportunity to engage with the latest research on geospatial system design, concept development, and rapid prototyping, particularly at the intersection of 3D and geospatial technologies.

2. Master Schedule

The following table details the major Initiative milestones and events. Dates are subject to change.

Table 1. Master schedule
Milestone Date  Event


March 31, 2021

Release of Call for Participation (CFP)


April 30, 2021

CFP Proposal Submission Deadline (11:59pm EDT)


May 31

All Participation Agreements signed (OGC will start sending preliminary offers in early May).


June 1-4

(specific date TBD) Half-day Kickoff Workshop to be organized as a virtual meeting.


Week of June 7

Mini-Sprint #1 (tentatively, two scheduled teleconferences plus ad hoc calls as needed).


Week of June 14.

Quarterly OGC Member Meeting: submit formal review request to selected OGC WG to review the Engineering Report (ER) later in the timeline (probably at the September Member Meeting).


Week of June 21

Mini-Sprint #2.


Week of June 28

Dry-Run(s) and Stakeholder Demo Event (tentatively, 1-2 virtual presentations for dry-runs and 1 virtual presentation for a Stakeholder Demo).


July 31

All participant Engineering Report (ER) contributions submitted.


August (date TBD)

Near-Final ER draft posted to Pending and Working Group review requested.


September (date TBD)

Quarterly OGC Member Meeting: ER Publication Vote; Presentation(s) of Final Results.

3. Sprint Scenarios

Bidders are required to identify at least one (1) and as many as three (3) scenarios. Any selected scenario(s) will eventually serve as the source of specific sprint requirements. Full details are provided under Submission Guidelines and Cost-Share Funding below.

Each proposed scenario should clearly reference the OGC Standards Baseline where applicable. The Baseline is the complete set of member approved Abstract Specifications, Standards, and Community Standards.

Bidders may choose one or more of the following "supplied scenarios" or construct their own. Each proposed bidder-developed scenario will be considered as long as it meets OGC needs and is comparable in extent to the supplied scenarios below. The Standard/Specification-to-Scenario Cross Reference table provides a cross-reference of OGC Standards and specifications with the supplied scenarios. Bidders should use this table to ensure that their descriptions address the correct document. Where applicable, proposals for scenarios that make use of existing OGC API Standards or draft specifications will be evaluated more favorably than proposals that do not.

These supplied scenarios are intentionally broad. Each proposed bidder-developed scenario should focus on just those elements that would be within scope of the bidder’s proposed work.

The scenarios are presented in no particular order; they are numbered to enable convenient reference.

3.1. Scenario 1

This scenario is to develop efficient conversion mechanisms between the various 3D data file formats currently used in CDB (or recommended by a bidder for possible future use). The focus is to convert the overlapping capabilities from one to another. Not all features/capabilities may be convertible. OGC Standards and specifications should be referenced and employed as much as possible. It is likely that different conversion workflows and processes will be needed for different environments and display requirements. Not all conversion paths will be possible, and bidders should attempt to define the proposed use case(s) within the following sub-scenarios.

3.1.1. Scenario 1A

Prototype the conversion of one OGC data format to another when the conversion needs to be done on request and response time is a critical measure of success. Work done on this scenario should use existing OGC Standards/specifications where possible. Alternatively, the proposal should explain why an existing OGC Standard/specification cannot be used (and recommend a proposed alternative for accomplishing the goal). A proposed scenario could (at the bidder’s discretion) involve a façade or wrapper for backend data sources that themselves implement OGC Standards/specifications (OGC/W3C Spatial Data on the Web Best Practice - Convenience APIs outlines one possible approach).

3.1.2. Scenario 1B

Prototype the batch conversion of a large number of files representing 3D content that would exist in a large CDB dataset similar to the San Diego CDB Dataset used in the Year 1 Sprint. The prototype should enable examination of questions such as the processing burden on server resources, how well each particular prototype solution scales (or fails to scale), and what some of the performance limits are. Results of this work should be able to provide guidance to the recommended sizing and limits of future versions of CDB (see the DRAFT CDB Standard Roadmap). Work done on this scenario is not necessarily required to use existing OGC Standards/specifications. Instead it might propose a prototype of a new API that is designed for large scale batch conversions.

3.1.3. Goals

  • Conversion between CDB, glTF, OpenFlight, 3D Tiles, and I3S.

  • For client/server architectures, clear explanations of where the processing burden would be placed (and why).

  • A use case addressing limited wide-area network (Internet) bandwidth.

  • Take advantage of existing OGC Standards/specifications. Minimize proposed extensions where possible.

3.2. Scenario 2

Support outdoor and indoor modeling of a building. The implementation could show before-and-after representations of functional aspects (e.g., HVAC, plumbing, electrical) or artistic aspects (e.g., interior design). The model must include and display metadata at multiple levels. This scenario should readily allow for virtual-reality (VR) walkthroughs in the indoor portion of the building.

3.2.1. Goals

  • Connect implementations of indoor and outdoor OGC Standards/specifications into a seamless display.

  • Generate, collect, transmit, and display scene-relevant metadata.

  • Demonstrate the use of VR headset displays with implementations of OGC Standards/specifications.

  • Demonstrate the use of game engines (e.g., Unreal, Unity) with implementations of OGC Standards.

3.3. Scenario 3

Show movement of traffic on land- or air-based transportation networks (i.e., road, rail, or aircraft). The animation could be real-time, historical, or synthetic. It should show multiple moving objects. The animation of the objects should conform to the network paths and must appear realistic for the object (e.g., buses have a larger turning radius than small cars). Individual models should be animated to simulate real-world counterparts. For example, semi-trucks need to be animated with a pivot point between the tractor and trailer; and articulate buses need to be skin-animated on turns. Existing OGC Standards/specifications should be used as much as possible and appropriate for the particular use case(s) identified by the bidder.

3.3.1. Goals

  • Use of model and object animation to simulate activity by merging data from implementations of existing (or proposed new) OGC Standards/specifications.

  • Demonstrate the use of game engines (e.g., Unreal, Unity) with existing (or proposed new) OGC Standards/specifications.

  • Identify missing or incomplete specifications for tracking moving objects.

  • Examine prototypes for city-wide digital twins for transportation networks.

3.4. Scenario 4

Identify and define missing functionality from glTF that would increase the usefulness of CDB. This may include extension(s) of the existing OGC CDB Standard to brand new capabilities that have not previously been specified. The capability may exist in supported CDB formats or not at all. The specific features and capabilities should be clearly stated to help avoid duplicate effort within OGC or with other organizations.

3.4.1. Goal

  • Draft definitions and initial implementations of capabilities needed by CDB. The OpenFlight - glTF Comparison table shows similarities and differences between OpenFlight (used by CDB) and glTF. If a proposed new feature is marked as already existing in both formats, then the proposal should explain why the existing formats are insufficient (and additional work is justified).

3.5. OGC Standards/Specifications and Scenarios

Many existing Standards/specifications might already apply to the supplied scenarios above. Bidders should determine which of these are applicable to the use case(s) in their proposals. This table shows which existing Standards/specifications are likely to be relevant. It is not expected that a proposal would necessarily include all the listed standards, and additional, unlisted standards could also be needed for some of the proposed work.

Table 2. OGC Standard/Specification to Scenario Cross Reference Table



1 A&B (Conversion)

2 (Indoor/ Outdoor)

3 (Moving Objects)

4 (New Capabilities)

glTF V2





Khronos glTF Extensions





Vendor glTF Extensions










OpenFlight (PDF download)





3D Tiles










GeoPose Standards WG





GeoVolumes (Draft)





Indexed 3D Scene Layers (I3S)










Indoor Mapping Data Format (IMDF)





Moving Features





Routing Standards WG










This table is intended to be used as a guide in determining which Standards and specifications can be used with the various scenarios. Particular use cases may or may not use the indicated Standard/specification.

4. Submission Guidelines and Cost-Share Funding

Proposals must be submitted before the deadline indicated in the Master Schedule.

Bidders responding to this CFP should be organizational OGC members familiar with the OGC vision, mission, approach, and values.

Proposals from non-members or individual members will be considered provided that a completed application for organizational membership (or a letter of intent) is submitted prior to (or along with) the proposal.

Bidders will be selected for cost share funds on the basis of adherence to the CFP requirements and the overall proposal quality. The general objective is to create prototype implementations to discover findings and recommendations that will inform future standards development work. Each proposed deliverable should formulate a path for producing executable interoperable prototype implementations for the selected scenario(s) and for documenting the associated findings and recommendations as contributions to the Sprint ER. Bidders not selected for cost share funds may still request to participate on a purely in-kind basis.

Each selected participant (even one not requesting any funding) will be required to enter into a Participation Agreement contract ("PA") with the OGC. The reason this requirement applies to purely in-kind participants is that other participants might have to rely upon their delivery. Each PA will include a Statement of Work ("SOW") identifying specific participant roles and responsibilities.

4.1. Requesting Cost-Share Stipends

Cost-share stipends will be available in the form of USD $5,000 increments, up to a maximum of three ($15,000) per participant. Each proposal should clearly indicate how many $5,000 increments are being requested.

More than three increments may be requested, but it is unlikely that more than three will be awarded to any particular bidder. Bidders may loosely coordinate their bids, but the work and proposals should be clearly separated. Combined awards will not be made, but two independent awards could be made to two bidders who intend to collaborate later during sprint execution (be sure that this is clearly indicated in both proposals).

Subsequent cost-share offers to selected bidders will also be made as increments ($5,000, $10,000, or $15,000).

Bidders should clearly link each requested increment with one or more proposed scenarios. Ideally, 1-3 independent $5,000 increments will be requested, with each request a multiple of $5,000.

For example, a proposal could include a request for $5,000 to support delivery of a prototype under the first scenario, $5,000 under the third scenario, and $5,000 for a bidder’s own custom-developed scenario. Another proposal might request $5,000 for scenario 2 and $10,000 for a bidder’s custom-developed scenario. Another proposal might request the full $15,000 for a bidder’s custom-developed scenario. For this last example, a thorough description of the full scenario would be expected (including which Standards/specifications would be involved and how the scenario might align with the work of the OGC CDB SWG).

4.2. Proposal Evaluation and Cost-Share Awards

All or a portion of the requested cost-share funding could subsequently be offered by OGC depending on the attractiveness of the proposed scenario relative to other proposals received. In the last example above, two increments totaling $10,000 might be offered in response to the request for three increments.

Each bidder will have the option to accept or reject this offer (of course).

In general, each bid will be evaluated based on how well the proposed deliverables will contribute to achievement of the goals described in the Sprint Scenarios. Here are some additional considerations that might lead to otherwise equal proposals to be preferred.

  • All else being equal, proposals that include the use of existing OGC Standards or draft specifications will be favored over those that do not.

  • Bidders are encouraged to assemble partial elements of the provided Sprint Scenarios into new combinations to come up with scenarios of their own.

    • But entirely new scope that was not included in any of the provided scenarios might also be acceptable.

  • All else being equal, proposals that clearly describe a testing approach will be favored over those that do not.

  • Proposals that include development of new or revised draft specifications would also be considered favorably.

  • All else being equal, proposals that plan on using collaboration with other bidder(s) to strengthen the quality and value of their interoperability testing will will be favored over those that do not.

  • Finally, capabilities such as conversion tools might not add much value to standards-based interoperability if they are not openly available for use by the broader community.

4.3. How May Cost-Share Stipends Be Used?

Stipend funds may be used as the participant sees fit. There are no restrictions so long as the proposed scope is delivered on schedule and the participant meets all the administrative requirements under Initiative Organization and Execution.

5. Initiative Organization and Execution

5.1. Policies and Procedures

This initiative will be conducted within the policy framework of OGC’s Bylaws and Intellectual Property Rights Policy ("IPR Policy"), as agreed to in the OGC Membership Agreement, and in accordance with the OGC Innovation Program Policies and Procedures and the OGC Principles of Conduct, the latter governing all related personal and public interactions.

Several key requirements are summarized below for ready reference:

  • Each selected participant will agree to notify OGC staff if it is aware of any claims under any issued patents (or patent applications) which would likely impact an implementation of the specification or other work product which is the subject of the initiative. Participant need not be the inventor of such patent (or patent application) in order to provide notice, nor will participant be held responsible for expressing a belief which turns out to be inaccurate. Specific requirements are described under the "Necessary Claims" clause of the IPR Policy.

  • Each selected participant will agree to refrain from making any public representations that draft Engineering Report (ER) content has been endorsed by OGC before the ER has been approved in an OGC Technical Committee (TC) vote.

  • Each selected participant will agree to provide more detailed requirements for its assigned deliverables, and to coordinate with other initiative participants, at the Kickoff event.

5.2. To Be Provided by OGC

The San Diego CDB sample data that was used for the Year 1 Sprint will also be available for the Year 2 Sprint. The dataset may be downloaded as needed, but please note that clicking the following link might automatically start a download of a 17GB file.

This is public data being made available without restriction. Bidders may also propose their own dataset(s) for use in the sprint.

5.3. Participant Deliverable Requirements

Participants will be required to make administrative deliverables in the form of labor hours. These will be consumed by participation in scheduled telecons during the weekly mini-sprints and in a demo telecon at the end of the final mini-sprint.

Participants will also be required to make contributions to the ER in the weeks following the mini-sprints (if not before).

All technical activities in this testbed will result in one or more deliverables which generally take the form of demonstration of component implementations or document (ER) contributions.

5.3.1. Engineering Report

An initiative Engineering Report (ER) will be prepared in accordance with OGC published templates. The ER will be delivered by posting on the OGC Pending directory when complete and the document has achieved a satisfactory level of consensus among contributors and editors. ERs are the formal mechanism used to deliver results of the Innovation Program to Sponsors and to the OGC Standards Program for consideration by way of Standards Working Groups and Domain Working Groups.

Each sprint participant will be expected to provide full input to at least one ER chapter devoted to their component implementation(s). A member of the OGC initiative team will play the Editor role to produce front-matter and to shepherd the ER through the publication voting process.

ER contributions should follow this OGC Document Editorial Guidance (scroll down to view PDF file content).

5.3.2. Component Implementations

Component implementations include services, clients, datasets, and tools. A service component is typically delivered by deploying an endpoint via an accessible URL. A client component typically exercises a service interface to demonstrate interoperability.

The PAs will not require delivery of any component source code to OGC. What is delivered instead is the demonstrated behavior of the component installed on the participant’s infrastructure (or in a cloud), and the corresponding document contributions to ER. Source code snippets may be contributed for inclusion in the ER. As with narrative and graphical contributions, these snippets would become part of the OGC-owned document and fall under the associated copyright.

However, participants are certainly permitted (and welcomed) to create their own open-source code and upload it to a public repository of their choosing. It is up to each participant to make its own choices in this regard.

5.3.3. Demo Assets

Component implementations are often used as part of outreach demonstrations near the end of the timeline. To support these demos, component implementations are required to include Demo Assets. For clients, the most common approach to meet this requirement is to create a video recording of a user interaction with the client. These video recordings may optionally be included in a new YouTube Playlist such as this one for the Year 1 Sprint.

Specific requirements for each video recording are as follows:

  • The video should include an end-title slide that should be visible for about the last 5 seconds of the video and includes the following information:

    • [Logo] Acme, Inc.

    • [contact]

    • Created for

    • [OGC logo] OpenGeospatial Consortium

    • Interoperable Simulation and Gaming Year 2 Sprint

    • June 2021.

  • Upload the video recording to the designated Portal directory (to be provided).

  • Include the following metadata in the Description field of the upload dialog box:

    • A Title that starts with "OGC ISG Year 2 Sprint:", keeping in mind that there is a 100-character limit [if no title is provided, we’ll insert the file name],

    • Abstract: [1-2 sentence high-level description of the content],

    • Author(s): [organization and/or individuals], and

    • Keywords: [for example, OGC, Khronos Group, 3D, simulation, gaming, CDB, etc.].

Since server components often do not have end-user interfaces, participants may instead support outreach by delivering static UML diagrams, wiring diagrams, screenshots, etc. In many cases, the images created for an ER will be sufficient as long as they are suitable for showing in outreach activities such as Member Meetings and public presentations. A server implementer may still choose to create a video recording to feature their organization more prominently in the new YouTube playlist. Another reason to record a video might be to show interactions with a "developer user" (since these interactions might not appear in a client recording for an "end user").


Demo-asset deliverables are slightly different from TIE testing deliverables. The latter don’t necessarily need to be recorded (though they often appear in a recording if the TIE testing is demonstrated in a telecon recording).

Appendix A: Modeling Formats Comparison

This section compares the similarities and differences between OpenFlight (used by CDB) and glTF. The material is presented in tabular form with the feature name in bold text. Important differences between the capabilities offered by OpenFlight and glTF are in the cell as explanatory text. glTF feature names are links to the appropriate part of the glTF Core V2.0 Specification. The source for OpenFlight material is OpenFlight Scene Description Database Specification 16.0 OGC Community Standard. The latest approved CDB Standard can be found at OGC CDB Standard.

Table 3. OpenFlight - glTF Comparison
Feature Description OpenFlight glTF


Move, rotate, and scale the contents


Scenes, Nodes and Hierarchy, and Transformations


The means to define the geometry of a model

Mesh, Vertex, Face, Subface - Allows the specification of arbitrary planar convex polygons to define a surface. Not all of these nodes are required to create geometry, but at least two are.

Meshes - This is collection of vertices and indices that only create a triangulated surface.


The means to put a color, texture, or material on a geometric surface

Mesh, Face - Limited to basic coloring and image textures

Materials - Physically Based Material support including advanced PBR features.


The means to change geometry and/or appearance of the model over time. There are several sub-types that are listed separately.

Key Frame

Specifies a collection of important (key) frames.

Group - Specifies a collection of frames where each collection is displayed in total replacing the contents of the previous frame. This is like discrete key frames (no interpolation between frames).

Animations - This node supports all animation types in glTF. Generally this is done by linearly interpolating between the key frames for the specific type of animation desired.


Specifies how the surface moves over a collection of joints in response to the movement of those joints.


Skins and Animations - Provides data for weighted geometry vertices (skin) and moves them according the animation of the joints.


Specifies a starting and ending geometry, typically down to the level of individual vertices. The system linearly interpolates between the two based on some externally supplied value.

Vertex, Morph Vertex

Morph Target and Animations


Specifies allowed animation within fixed limits at fixed points in the model.

Degree of Freedom

AGI_articulations and Animations


Level of Detail allows a model to exist at several detail levels. The display system chooses which detail level to display based on the distance to the object and potentially other factors.

Level of Detail



This feature allows zero or more models to be displayed from the collection. This is a generalized version of LOD and is frequently used for before & after displays.


KHR_materials_variants provides this functionality for appearance on the same geometry. Except for the LOD indicated above, there is no explicit functionality for this capability.


This feature provides lighting for the model and scene. It may or may not illuminate other objects. Subtypes are listed separately.

Glow Lights

This feature is small glowing light sources that do not illuminate other objects.

Light Point

This is typically done with an emissive color or texture on geometry. There is no explicit support in the format.

Punctual Lights

This includes point, spot, and directional lights that illuminate other objects.

Light Source - The reference does not provide any indication that directional lights are supported.

n/a - Support for light interaction with the model appearance is supported; however, the format does not include light definitions. See Notes, Lighting for additional details.


Image Based Lighting (IBL) is used to illuminate a PB Material model. This provides light from 4pi steradians with the proper coloring for each angle. It is typically used to light an individual location in a scene.


EXT_lights_image_based (see Notes, Lighting)

Camera/ Viewpoint

The location where a virtual camera is put into the scene for viewing the contents. Typically several characteristics of the camera are available for definition including (but not necessarily all) lens, zoom, projection type (perspective or orthographic)


Cameras (see Notes, Viewing)


The ability to add text to the scene without creating specialized geometry for it.




The ability to add sound to an object (model) or environment.


MSFT_audio_emitter There are discussions as to how appropriate this is for glTF in the standardized version.


The ability to include secondary files or datasets as directly as part of the scene. These inclusions do not modify existing objects or features.

External reference



The ability to associate data about the node (metadata) with a node. This is usually structured and provides for easy expansion.

Comment - This is unstructured plain descriptive text.

KHR_xmp_json_ld - Public, but currently unratified extension to provide a structure to store metadata in various nodes.


The ability to create multiple display objects from a single source object. The geometry, appearance, and animation is the same between the instances.

Instancing, Replication


A high-level comparison of the modeling portion of OpenFlight and glTF. The structural elements of both formats were ignored.

  1. Lighting: glTF does support lights; however, the trend is not to have models with lights as they need to interact with something physical to be seen. The lighting is typically supplied by the system handling the display of the glTF model. Model illumination is typically done with IBL. It is possible to include IBL with a model using EXT_lights_image_based.

  2. Viewing Typically cameras are contained and managed in the scene environment to account for different uses of the model. There is no reqirements that the model camera must be used.

Appendix B: DRAFT CDB Roadmap

Below is an informative DRAFT depiction of the direction of the OGC CDB SWG. This information is not an OGC Standard. It is subject to change without notice and should not be referred to as an OGC Standard. The latest approved CDB Standard can be found at OGC CDB Standard.

CDB Roadmap 200312
Figure 1. DRAFT CDB Standard Roadmap (subject to change). The "CDB 2.0 High-Level Architecture" and "CDB Document Organization - v5" inserts are presented in more detail below.

Zooming in on the DRAFT CDB 2.0 High-Level Architecture: