Open Geospatial Consortium

Submission Date: 2020-01-21

Approval Date:      2020-08-24

Publication Date:      2021-02-26

External identifier of this OGC® document:

Internal reference number of this OGC® document:        16-006r5

Version: 1.2

Category: OGC® Best Practice

Editor:      Carl Reed

Volume 10: OGC CDB Implementation Guidance (Best Practice)

Copyright notice

Copyright © 2021 Open Geospatial Consortium

To obtain additional rights of use, visit


This document defines an OGC Best Practice on a particular technology or approach related to an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC Standard. It is subject to change without notice. However, this document is an official position of the OGC membership on this particular technology topic.

Document type:        OGC® Best Practice

Document subtype:   

Document stage:    Approved

Document language:  English

License Agreement

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

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



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

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

i. Abstract

This document provides detailed implementation guidance for developing and maintaining a CDB compliant data store.

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

The application of CDB to future simulation architectures will significantly reduce runtime-source level and algorithmic correlation errors, while reducing development, update and configuration management timelines. With the addition of the High Level Architecture - Federation Object Model (HLA/FOM) and Distributed Interactive Simulation (DIS) protocols, the application of the CDB standard provides a Common Environment to which inter-connected simulators share a common view of the simulated environment.

The CDB standard defines an open format for the storage, access and modification of a synthetic environment database. A synthetic environment is a computer simulation that represents activities at a high level of realism, from simulation of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by super-realistic special effects and accurate behavioral models. SE allows visualization of and immersion into the environment being simulated [1].

This standard defines the organization and storage structure of a worldwide synthetic representation of the earth as well as the conventions necessary to support all of the subsystems of a full-mission simulator. The standard makes use of several commercial and simulation data formats endorsed by leaders of the database tools industry. A series of associated OGC Best Practice documents define rules and guidelines for data representation of real world features.

The CDB synthetic environment is a representation of the natural environment including external features such as man-made structures and systems. A CDB data store can include terrain relief, terrain imagery, three-dimensional (3D) models of natural and man-made cultural features, 3D models of dynamic vehicles, the ocean surface, and the ocean bottom, including features (both natural and man-made) on the ocean floor. In addition, the data store can includes the specific attributes of the synthetic environment data as well as their relationships.

The associated CDB Standard Best Practice documents provide a description of a data schema for Synthetic Environmental information (i.e., it merely describes data) for use in simulation. The CDB Standard provides a rigorous definition of the semantic meaning for each dataset, each attribute and establishes the structure/organization of that data as a schema comprised of a folder hierarchy and files with internal (industry-standard) formats.

A CDB conformant data store contains datasets organized in layers, tiles and levels-of-detail. Together, these datasets represent the features of a synthetic environment for the purposes of distributed simulation applications. The organization of the synthetic environmental data in a CDB compliant data store is specifically tailored for real-time applications.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, cdb, implementation guidance, simulation, synthetic environment

iii. Preface

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.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Organization name(s)

  • CAE Inc.

  • Carl Reed, OGC Individual Member

  • Envitia, Ltd

  • Glen Johnson, OGC Individual Member

  • KaDSci, LLC

  • Laval University

  • Open Site Plan

  • University of Calgary

  • UK Met Office

The OGC CDB standard is based on and derived from an industry developed and maintained specification, which has been approved and published as OGC Document 15-003: OGC Common DataBase Volume 1 Main Body. An extensive listing of contributors to the legacy industry-led CDB specification is at Chapter 11, pp 475-476 in that OGC Best Practices Document ( .

v. Comment Submission

All questions regarding this submission should be directed to the editor or the submitters:



Carl Reed

Carl Reed & Associates

David Graham

CAE Inc.

vi. Document Organization

include:: ease of editing and review, the standard has been separated into 16 Volumes, one being a schema repository.

  • Volume 0: OGC CDB Companion Primer for the CDB standard (Best Practice).

  • Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure. The main body (core) of the CDB standard (Normative).

  • Volume 2: OGC CDB Core Model and Physical Structure Annexes (Best Practice).

  • Volume 3: OGC CDB Terms and Definitions (Normative).

  • Volume 4: OGC CDB Rules for Encoding CDB Vector Data using Shapefiles (Best Practice).

  • Volume 5: OGC CDB Radar Cross Section (RCS) Models (Best Practice).

  • Volume 6: OGC CDB Rules for Encoding CDB Models using OpenFlight (Best Practice).

  • Volume 7: OGC CDB Data Model Guidance (Best Practice).

  • Volume 8: OGC CDB Spatial Reference System Guidance (Best Practice).

  • Volume 9: OGC CDB Schema Package: provides the normative schemas for key features types required in the synthetic modeling environment. Essentially, these schemas are designed to enable semantic interoperability within the simulation context (Normative).

  • Volume 10: OGC CDB Implementation Guidance (Best Practice).

  • Volume 11: OGC CDB Core Standard Conceptual Model (Normative).

  • Volume 12: OGC CDB Navaids Attribution and Navaids Attribution Enumeration Values (Best Practice).

  • Volume 13: OGC CDB Rules for Encoding CDB Vector Data using GeoPackage (Normative, Optional Extension).

  • Volume 14: OGC CDB Guidance on Conversion of CDB Shapefiles into CDB GeoPackages (Best Practice).

  • Volume 15: OGC CDB Optional Multi-Spectral Imagery Extension (Normative). of_volumes.adoc[]

vii. Future Work

The CDB community anticipates that additional standardization will be required to prescribe content appropriate to targeted simulation applications. In its current form, the CDB standard does not mandate synthetic environmental richness, quality and resolution.

The OGC CDB Standards Working Group (SWG) members understand there is a requirement for eventual alignment of the CDB standard with the OGC/ISO standards baseline. In Version 1 of the CDB standard, effort was invested to begin aligning terminology and concepts, specifically in the coordinate reference system discussions and requirements.

The current version of the CDB standard is fully backwards compatible with version 3.2 of the CDB specification as defined and implemented by the current CDB implementer and user community. The requirements for a CDB data store are focused on the ability to store, manage, and access extremely large volumes of geographic content. In this version of the standard, initial harmonization with the OGC and ISO standards baseline has begun. For example, where appropriate, the CDB simulation community terms and definitions have been replaced with OGC/ISO terms and definitions. Further, the standards documents have been reorganized and structured to be consistent with the OGC Modular Specification Policy. However, the CDB SWG and community recognize the need to further harmonize and align this standard with the OGC baseline and other IT best practices. There has already been considerable discussion in this regard.

Based on such discussions and comments received during the public comment period, the following future work tasks are envisioned:

  1. Describe explicitly how the CDB model may or may not align with the OGC DGGS standard;

  2. Provide best practice details on how to use WMS, WFS, and WCS to access existing CDB data stores. This work may require Interoperability Experiments to better understand the implications of these decisions;

  3. Extend the supported encodings and formats for a CDB data store to include the use of the OGC GeoPackage, CityGML, and InDoorGML standards as well as other broadly used community encoding standards, such as GeoTIFF. This work may require performing OGC Interoperability Experiments to better understand the implications of these decisions.

  4. Further align CDB terminology to be fully consistent with OGC/ISO terminology.

Making these enhancements will allow the use and implementation of a CDB structured data store for application areas other than aviation simulators.

1. Scope

This document provides detailed implementation guidance for developing and maintaining a CDB compliant data store.

2. Conformance

Not Applicable

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

  • Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure. The main body (core) of the CBD standard (Normative).

  • Volume 2: OGC CDB Core Model and Physical Structure Annexes (Best Practice).

4. Terms and Definitions

For the purposes of this document, the following abbreviations apply. All other terms and definitions are contained in Volume 3: OGC CDB Terms and Definitions (

RTP: Run-Time Publishers SE: Synthetic Environment

5. Platform Recommendations

This section provides recommendations for platform minimum capabilities to implement a CDB Data Store. The platform constraints imposed by the CDB standard are minimal and are designed to allow implementation in many of the widely available computer hardware platforms, operating systems, file systems and transport protocols. Below are the suggested Platform requirements.

5.1. File System

A CDB data store instance is file system independent, (i.e., the use of a specific file system is not specified). However, implementation of the CDB standard does require that the file system be able to support a minimal set of capabilities as listed below:

  1. File name/Directory name structure:

    1. Character set: in accordance to with Decimal, Hexadecimal, and Character codes as given in

    2. Length of filename (including path to file): 256 characters or more.

    3. Length of filename extension: “dot” followed by three characters or more

  2. Minimum Directory structure:

    1. Number of files or directories in root directory: 256 entries or more.

    2. Number of files or directories per directory (except root): 2048 entries or more

    3. Depth of directory hierarchy: 9 or more (assuming at least 256 entries per directory level).

    4. Directory size: 128 KB or more (assuming 64 bytes per directory entry).

  3. File Size: 64 MB or more.

  4. Number of files per volume: 41,600 files or more (assuming 650 MB CD with 16 KB files.

  5. Support for removable media.

  6. Support for bootable/non-bootable volume.

5.2. Operating System

The CDB standard is Operating System (OS) independent; it does not mandate the use of a specific OS. However, compliance to this standard does require that the operating system be able to support a minimal set of capabilities.

Any operating system implementing the CDB standard should support at a minimum the following basic OS properties:

  • Byte-stream random file access

  • 32-bit integers, natively

  • A 32-bit address space

  • Floating point support (per IEEE-754), natively

  • 2GB virtual address space per process

  • Memory paging

  • Network communication

5.3. System Hardware Independence

Implementation of the CDB standard is hardware independent. The CDB standard does not mandate the use of particular hardware platforms. Furthermore, any general-purpose hardware compatible with modern Operating Systems (OS) can be used for a CDB implementation.

Implementation of the CDB standard assumes that the system hardware shall support, as a minimum, the subsystems described in the following requirement.

Hardware memory for systems implementing the CDB standard should support:

  • 8-bit, 16-bit, and 32-bit signed and unsigned integers, natively

  • A 32-bit address space

  • 32-bit and 64-bit double precision floating point values (IEEE-754), natively

  • 2 GB virtual address space

  • Virtual memory space

Immediate and indirect memory addressing modes

6. Informative Implementation Guidance

6.1. Clarification: Publisher Considerations

The CDB Standard does not provide guidelines regarding its implementation within specific vendor SE toolsets and vendor simulation architectures. This clearly falls outside of the scope of the CDB Standard. The CDB Standard is focused a physical and logical storage structure and guidance on storage formats for information (i.e., it merely describes data) for use in simulation.

The CDB model lends itself to a real-time implementation within simulation architectures. This capability requires that the vendor’s client-device be adapted with a Run-Time publishing (RTP) software function which transforms the CDB structured data into the client-device’s internal legacy/proprietary format. This is a new concept for the simulation industry and consequently there is considerable confusion regarding the implementation of Off-line and Run-Time Publishers (RTPs). While much of the attention has focused on RTPs, a similar set of considerations apply to the implementation of an off-line CDB capability (CDB is used as a Refined Source Data Repository). In this latter case, the capability requires that the vendor develop an off-line CDB import function which ingests the CDB into their Synthetic Environment Creation toolset. Once imported, the vendor toolset could produce the vendor’s proprietary data format through an off-line compilation function.

By definition, the function of an RTP is to bridge the “gap” (or adapt) between CDB data schema and the client-device’s internal (proprietary) data schema. Since this gap is unknown, it is impossible in this addendum to provide hard-and-fast rules and detailed estimates for the implementation of an RTP (or a CDB import function).

Note that there are many alternatives open to a vendor when considering the level of compliancy he wishes to achieve. The level-of-effort is essentially a function of the level of compliancy the vendor wishes to achieve, and the size of the intrinsic “gap” between the CDB data schema and his device’s internal schema.

Nonetheless, this section highlights aspects of the CDB that are particularly significant when considering such implementations. These aspects dominate the level-of-effort required to achieve ideal CDB compliancy.

The CDB Standard limits itself to a description of a data schema for Synthetic Environmental information (i.e., it merely describes data) for use in simulation. The CDB Best Practices provide rigorous guidance of the semantic meaning for each dataset, each attribute and establishes the structure/organization of that data as a schema comprised of a folder hierarchy and files with internal (industry-standard) formats. This ensures that the all CDB data is understood, interpreted and efficiently accessed in the same way by each client-device. The CDB standard does not include detailed guidelines regarding off-line database compliers or runtime publisher implementations, since this would be tantamount to dictating internal vendor formats which are by their very nature proprietary.

The CDB Standard DOES NOT specify:

  • The implementation details of an off-line CDB import function that can then be used to compile the imported Synthetic Environmental data into one or more types of proprietary runtime databases (only the client-device vendor has this knowledge and control);

  • The implementation details or algorithms of runtime publishers attached to specific client-device (only the client-device vendor has this knowledge and control); or

  • The implementation details or algorithms of client-devices that use CDB data (only the client-device vendor has this knowledge and control).

While the CDB standard does not govern the actual implementation of client-devices, it is expected that the CDB standard will have a “unifying” effect on the implementation of each vendor’s client-device by virtue of the fact that they will share the exact same Synthetic Environmental data. It is expected that side-by-side comparisons will be easier to undertake due to the fact that devices will run off the exact same runtime data. Prior to the advent of the CDB standard, side-by-side comparisons were considerably more difficult to undertake due to the fact the entire SE creation chain starting from raw source was implicated in such evaluations.

If we set aside legacy considerations, the simplest approach to adopting the CDB would require that client-devices ingest the CDB natively, i.e., client-devices would handle all of the CDB data schema/semantics without any off-line or run-time intermediary.

In practice however, most vendors have extensive legacy SE assets and cannot afford to obsolesce these. As a result, most client-devices must continue to support their own proprietary legacy runtime databases. Given these considerations, two solutions are possible.

  1. No change to the Client-device: In this approach, vendors have chosen to achieve an off-line CDB capability (CDB is used as a Refined Source Data Repository). This capability requires that the vendor develops an off-line CDB import function which ingests the CDB into his Synthetic Environment Creation toolset; once imported, the toolset produces (as always) the vendor’s proprietary data format through an off-line compilation function.

  2. Level-of-Effort of a Publisher Implementation

The following discussion attempts to qualify the level-of-effort to achieve CDB compliancy. The discussion applies equally to both paradigms, i.e., the CDB Runtime Publishing paradigm and the CDB import-then-compile paradigm.

In the case where a client-device already supports most of data schema and semantics concepts of the CDB, then the RTP (or import-then-compile) software is proportionally less complex. For instance, if an IG already supports the concepts of tiles, of levels-of-detail, of layers and understands the concepts of datasets such as terrain texture, gridded terrain elevation, gridded terrain materials, etc. then there is a modest amount of work to be performed by an RTP.

The level-of-effort in adopting the CDB model is proportional to the difference between the CDB data schema and client-device’s internal proprietary data schema.

Clearly, the algorithmic complexity of an RTP and the computational load imposed on the RTP is directly proportional to the above-mentioned “gap.” The larger the “gap,” the more expensive a RTP is to develop and the more computational resources need to be allocated to implement it. Conversely, with a smaller “gap,” the RTP development is straightforward and relatively few computational resources need to be allocated to this function.

In order to assess the level-of-effort to adopt the CDB model, the vendor must first evaluate the similarity of data schemas between the CDB and his client-device, in particular, the vendor must assess whether they espouse the following fundamental CDB concepts:

  • Independent Tiles (used for paging of all data)

  • Independent Levels-of-Detail (for all data)

  • Independent Layers (Dataset Layering)

  • Following dataset concepts and semantics:

    • Semantic understanding of all CDB layers

    • Geo-gridded data layers consisting of terrain altimetry, terrain texture, terrain materials/mixtures

    • Geo-defined vector features (points, lineals, areals)

      • With/without modeled 3D representations

      • Feature attribution

    • 3D Modeled representation of features (using a data schema similar to or equivalent to OpenFlight)

      • Instanced geotypical models

      • Instanced model geometry

      • Instanced model texture

      • Non-instanced geospecific models

    • Conforming of features to terrain skin (e.g. height conforming)

    • Topological networks

    • JPEG-2K compression

    • Generation of device-specific NVG/FLIR rendering parameters for light-points and materials

In the case where a client-device does not intrinsically support one or more of the above-mentioned CDB concepts, the RTP must perform SE conversions that will likely fall beyond those of mere format/structure manipulations. Such conversions may affect the precision of the data, its semantic meaning, etc. and thus can compromise certain aspects of runtime correlation.

The CDB data model favors modern up-to-date implementations of client-devices. In effect, the level-of-effort to develop an RTP for an obsolete legacy device is likely to be greater than for a modern device. This is because early approaches in digital computer based flight simulation were more severely constrained by severe hardware, software and data source limitations. Consequently, simulation engineers made important compromises between a subsystem’s targeted fidelity and its level of generality, scalability, abstraction, and correlation with other simulator client-devices. In many cases, engineers reverted to complex support data structures (generated off-line) in order to reduce the computational load at runtime.

A classic example of this was the use of Binary Separation Planes (BSPs) data structures [2] which were required prior to the widespread adoption of Z-buffers by the IG vendors. The CDB standard does not make provisions for this and as such, the RTP for legacy BSP-based IG devices would be burdened with the rather difficult task to generate BSPs in real-time.

Given their tremendous benefit, the concepts of paging (e.g. tiles) and levels-of-details have steadily been adopted by simulation vendors over the past 15-20 years and have been applied to most datasets, notably terrain and imagery datasets. (See Appendices G and F of the Volume 2: OGC CDB Core Model and Physical Structure Annexes for a rationale for Tiles and Levels-of-detail). As a result, it is not expected that the CDB tiles and LOD concepts will be a problem for most vendors. Note however that CDB applies these two concepts to ALL dataset layers including vector features and 3D models.

6.1.1. Client-Devices

Each client-device is matched either to an off-line compiler or to a runtime publisher. In the runtime case, the runtime publisher transforms this data into the client-device’s legacy native data format and structures the CDB synthetic environment data as it is paged-in by its client-device. Regardless of its use as an offline or online repository, implementing the CDB standard eliminates all client-format dependencies. Alternately, the client-device may be designed / modified to be CDB-native, in which case a separate runtime publisher is not required. Note that the CDB standard makes use of data types commonly available in standard computer platforms (floats, integers, etc.). While it would be theoretically possible to cater to a client-device that does not support the “atomic” data types, it would unduly load the attached online publisher. As a result, it is recommended that all client-devices provide hardware support for the CDB specified atomic data types.

Since it is the client-devices that initiate access to the CDB conformant data store, they must each be theoretically “aware” of at least the geodetic earth reference model [3]. Otherwise, the contents and the structure of the data store instance can be completely abstracted from the client-device.

6.1.2. Typical Functions Performed by a Publisher Implementation

The following discussion provides a typical list of software functions that must be developed in order to achieve CDB compliancy. The discussion applies equally to both paradigms, i.e. the CDB Runtime Publishing paradigm and the CDB import-then-compile paradigm.

Virtually all simulation client-devices in existence today natively ingest their own proprietary native runtime formats. In order to ingest CDB structured data directly, vendors must adapt the device’s software to natively ingest the currently defined CDB formats [4] (e.g., TIFF, Shape, OpenFlight, etc.) or alternately, they can insert a runtime publisher function that transforms the CDB data formats into legacy client device’s native runtime format. The runtime publishing process is performed when the CDB is paged-in from the CDB storage device.

The runtime publishers are nothing more than well-optimized offline publishers capable of responding to the on-demand compilation of datasets as they are being paged-in by the respective client devices. The function of a runtime publisher is no different than that of a conventional offline database publisher, i.e., it…

  1. transforms the assembled data store so that it satisfies the client-device’s internal data structure and format

  2. transforms the assembled data store so that it satisfies the client-device’s internal naming conventions

  3. transforms the assembled data store so that it satisfies the client-device’s number precision and number representation

  4. transforms the assembled data store into parameters compatible with the client device’s internal algorithms (typically light parameters, FLIR/NVG parameters, etc.

  5. transforms the assembled data store so that it satisfies the client-device’s data fidelity requirements

  6. transforms the assembled data store so that it satisfies the client-device’s performance and internal memory limitations

  7. transforms the assembled data store so that it satisfies the client-device’s level of-detail representation requirements.

Ideally, the scope of an RTP should be purely limited to manipulations of data format and data structure and internal naming conventions (items a-g above). Under such circumstances, it is possible to achieve perfect runtime correlation between client-devices.

6.1.3. Publisher Implementation Recommendations

The use of the CDB data schema “as-is” by a client-device achieves all of the benefits stated in sections 1.4 and 1.5 of the CDB Standard, namely:

  1. Improved SE generation timeline and deployment

  2. Interoperable simulation-ready SE

  3. Improved client-device robustness/determinism

  4. Increase SE longevity

  5. Reduced SE storage infrastructure cost

  6. Platform independence and scalability

  7. SE scalability and adaptability

In the case where a client-device does not adhere to one or more of the above-mentioned “fundamental CDB concepts,” fewer of the CDB benefits will be realizable.

For instance, a client-device incapable of dealing with levels-of-detail will not have the same level SE scalability (a benefit explained in section 1.4.7 of the CDB Standard) as one that fully espouses that concept. While the latter may be acceptable, it is clearly a less-compliant and an inferior implementation of the CDB than the former.

Changes to the modeled representation of features are generally not advisable since it invariably affects the accuracy of the modeled representation. Most image generators in use today can ingest a (one-for-one correspondence) the CDB modeled polygonal representation of 3D features. However, in the case of terrain, there are two dominant approaches in industry, either a regular grid with LODs or alternately, the Terrain Irregular Network (TIN) mesh. The CDB Standard has opted for the former given its greater scalability, determinism and compatibility with tiling schemes. Clearly, implementations where such conversions are not necessary are advantaged and provide more of the above-mentioned CDB benefits.

Furthermore, the CDB is designed to provide both the semantic (e.g. vector data/attribution) and the modeled representation of features. Since the CDB Standard and associated Best Practices provides both, it is not advisable to ignore or replace the modeled representation (if provided) nor is it advisable to synthesize a non-CDB modeled representation if none was supplied within the CDB. While the CDB Standard does not forbid vendors to interpret CDB feature data for the purpose of procedurally synthesizing more detailed feature data or synthesizing modeled data from the feature data, this practice is not recommended as this would severely compromise correlation and inter-operability. In the context of correlated synthetic environments, such approaches are viable if and only if all client-devices in a federation are equipped with the exact same procedural algorithms. Currently, this is not possible because there are no industry-standard, open-source procedural algorithms endorsed by all simulation vendors.

In the case of the CDB Runtime Publishing paradigm and the CDB import-then-compile paradigm, it is not advisable to ignore or replace the modeled representation (if provided) nor is it advisable to synthesize a non-CDB modeled representation if none was supplied within the CDB.

6.2. Use of a CDB conformant data store as an Off-line Repository

Figure 1-1: Use of a CDB conformant data store as an Off-line Repository, illustrates the deployment process of a CDB conformant database when it is used solely as an off-line Master repository. This approach follows the SE deployment paradigm commonly used today within the simulation community. The use of a CDB conformant data store as an off-line environmental data repository offers immediate benefits, namely…

  • SE Standardization through a public, open, fully-documented schema that is already supported by several SE authoring tools.

  • SE Plug-and-Play Portability and Interoperability across various vendor SE authoring toolsets

  • SE Correlation through the elimination of source correlation errors through normalization of all data sets (a single representation for each dataset)

  • SE Re-use by eliminating dependencies that are specific to the simulation application, the Data store Generation tool suite, the simulation program, the technology

  • SE Scalability which results in near-infinite SE addressability, spatial resolution and content density in each of the SE datasets

  • 3D Model Library Management through built-in provisions for the cataloging of models

  • SE Versioning Mechanism allowing instant access to prior versions and simplified configuration management

  • Cooperative SE Workflow through an internal SE structure which favors teamwork. The SE workflow can be allocated by specialty (e.g., altimetry, satellite imagery, vector data) or by geographic footprint

  • Straightforward SE Archival and Recovery

Note that the use of the use of CDB conformant data store as an offline repository does not impose any change to the simulation training equipment (i.e., no modifications to client-devices are required [5]). However, the deployment of the synthetic environment is similar to the conventional approaches used in industry requiring the time-consuming, storage-intensive, off-line compilation of proprietary runtime databases to each client-device. Furthermore, the computing demands on the data store generation facility are significantly greater because the entire data store must be published off-line for each client-device before it can be deployed. These costs rapidly escalate with the complexity and size of the synthetic environment, the number of supported client-devices and the number of supported training facilities. For complex data stores, these costs can far outweigh the costs of the runtime publishers attached to each simulator client-device.


Figure 1-1. Use of CDB Conformant Database as an off-line Database Repository

In most modern SE tool suites in-use today, the Data Preparation step shown in Figure 1-2: SE Workflow with a CDB structured data store as an Off-line Repository consists of many sub-steps usually applied in sequence to each of the datasets (aka layers) of the SE. In effect, this aspect of the modeler’s responsibilities is virtually identical to that of a GIS [6] specialist. As a result, many of the simulation equipment vendors offer SE authoring tools that integrate best-of-breed COTS [7] GIS tools into their respective tool suites. The steps include the following.

  • Format conversion: raw source data is provided to modelers in literally hundreds of formats. Early on in the SE generation process, modelers typically settle on a single format per SE layer (e.g., terrain altimetry, imagery, attribution)

  • Error handling: raw source often contains errors or anomalies that, if left undetected, corrupt and propagate through the entire SE data preparation pipeline. As a minimum, these errors must be detected early on in the process. More advanced tools can correct many of these automatically, particularly if there is some redundancy across the layers of data.

  • Data geo-referencing: this is the process of assigning a unique location (latitude, longitude and elevation) to each piece of raw data entering the SE pipeline.

  • Data Registration: each dataset is manipulated so that it coincides with information contained in the other datasets. These manipulations include projections, coordinate conversions, ortho-rectification, correction for lens distortions, etc. For images, this process is also known as rectification.

  • Data Harmonization: the raw data of a dataset varies over a geographic extent if it was obtained under different conditions, such as from two or more sensors with differing spectral sensitivity characteristics, resolution, in different seasons, under different conditions of weather, illumination, vegetation and human activity. The modeler must factor for these variations when selecting and assembling the datasets into a self-coherent SE.


Figure 1-2. SE Workflow with CDB as an off-line Repository

The effort expended during the Data Preparation and Modeling step is mostly independent of the targeted simulation devices and the targeted applications. Consequently, the results of the data preparation step can be stored into a Refined Source Data Store (RSDS) and then re-targeted at modest cost to one or more simulation devices.

The standardization of simulation data stores can greatly enhance their portability and reusability. The CDB Standard and associated OGC Best Practices offers a standardized means to capture the effort expended during the Data Preparation and Modeling step. In effect, a CDB structured database becomes a master repository where refined source can be “accumulated” and managed under configuration control.

While standardization of format/structure is essential to achieve high portability, interoperability and reuse, the SE content must be ideally developed so that its content is truly independent of the training application. Therefore, we strongly recommend that the SE content of the CDB structured repository be developed to be independent of the training application.

Historically, SEs were developed for a single, targeted simulation application (e.g., tactical fighter, civil and air transport, rotary wing, or ground/urban warfare). In effect, the intended training application played an important role in determining the RSDB content because SE developers were constrained by the capabilities of the authoring tools and of the targeted simulation device. Unfortunately, this tailoring of SE was performed too early during the SE workflow and severely limited the applicability and re-use of the SE. Application tailoring can require either data intensification [8] or data decimation [9].

Once the SE developer has completed his work in creating the various data layers of the RFDS, he must offline publish (aka “compile”) the SE into one or more device-specific data publishing steps. As we will discuss in section 6.4, Use of CDB structured data store as a Combined Off-line and run-time data store Repository, the device-specific off-line compilation step can be entirely omitted if the targeted training equipment is CDB-compliant.

While an off-line publishing approach does not offer all of the benefits described in this section, it nonetheless provides an easy, low-effort, migration path to CDB. Any equipment vendor can easily publish the data into their proprietary runtime format. Firstly, the publishing process is facilitated by the fact that the CDB standard provides guidance on how to use industry standard formats. However, the CDB model goes much further in that it specifies how to use these formats in a global, standardized data model suited to high-end real-time simulations. This greatly facilitates the work of SE developers. Thus, the CDB model provides a far simpler and straightforward means of interchanging refined source data.

6.3. Use of a CDB conformant data store as a Combined Off-line and Run-time Data store Repository

A data store conforming to this CDB standard can be both used an offline repository for authoring tools or as an on-line (or runtime) repository for simulators. When used as a runtime repository, a CDB conformant data store offers plug-and-play interchangeability between simulators that conform to the CDB standard. Since a CDB conformant data store can be used directly by some or all of the simulator client-devices, it is considered a run-time environment data store.

In addition to the benefits outlined in section 6.3, the use of the CDB conformant data store as a combined off-line and run-time repository offers many additional benefits.

  • SE Plug-and-Play Portability and Interoperability across CDB-compliant simulators and simulator confederacies (be it tactical air, rotary, urban/ground, sea).

  • Reduced Mission Rehearsal Timeline by eliminating SE generation steps (off-line publishing, database assembly and data automation.

  • Simplified Deployment, Configuration Control and Management of Training Facility SE Assets by eliminating the duplication of SE runtime DBs for each simulator and each client-device of each simulator.

  • Single, centralized storage system for the SE runtime repository (can be extended to a web-enabled CDB).

  • Seamless integration of 3D models to the simulator.

  • Fair Fight/Runtime Content Correlation through the adjustment of runtime level-of-detail control limits at each client-device.

Figure 1-3: Use of CDB Model as an Off-line and On-line Data Store Repository, illustrates the CDB structure as an off-line Master data store repository for the tools and as an online Master data store repository for the training facilities. Note that the deployment of the synthetic environment to the training facilities involves a simple copy operation. The deployment of a CDB conformant data store is further simplified through an incremental versioning scheme. Since only the differences need be stored within the data store, new versions can be generated and deployed efficiently.