15 © 2015 Open Geospatial Consortium
The CDB Specification also provides for near-infinite cultural content. The CDB Specification for vector data 3D point, lineal and areal features is also structured into a LOD hierarchy
consisting of up to 34 LODs. At the finest possible LOD, a CDB can contain in excess of 100 million cultural features per square meter.
The CDB Specification permits each geographic area to be modeled at a distinct LOD in accordance to the availability of source data. Since this capability is provided at a tile-level, it is
storage-efficient.
1.4.4 Earth Geodetic Spatial Representation Model
Geo-referenced data constitute a major aspect of the CDB Specification synthetic environment data. It uses a geographic coordinate representation WGS-84 latlong, elevation for the earth’s
terrain surfaces and ocean floor. Furthermore, natural and man-made objects are positioned and oriented using geodetic coordinates. The CDB Specification provides geodetic coverage for the
entire earth.
1.4.5 TileLayerLevel-of-Detail Structure
The CDB Specification offers a structure that is well suited for the efficient access of its contents. To this end, it relies on three important means to organize the synthetic environment
data:
Tiles Layers
Level-of-Detail LOD
1.4.5.1 Tiles
The CDB Specification relies on a top-level tile structure designed to organize the data for efficient access in real-time. The tile structure provides an effective means for simulator client-
devices to access the datasets of a geographical area at a selected LOD. Since the spatial dimension of tiles varies inversely with LOD i.e., resolution, client-devices can readily predict
the amount of data contained within the tile; as a result, the management of memory within client-devices is simplified and much more deterministic.
The CDB Specification Data Representation Model DRM is logically organized as a strip of geo-unit aligned tiles along each earth slice. Each earth slice is divided into a decreasing number
of tiles to account for the fact that the length of an earth slice decreases with increasing latitude.
1.4.5.2 Layers
The CDB Specification DRM is also logically organized as distinct layers of information. The layers are theoretically independent from each other, i.e., changes in one layer do not impose
changes in other layers.
Layers are additive in fidelity, i.e., the achievable level of the simulation fidelity increases with the number of layers.
16 © 2015 Open Geospatial Consortium
Secondly, unavailable layers are automatically defaulted. A database modeler need not fully populate the CDB. There is no mandatory “coverage completeness requirement” imposed by the
CDB Specification. This feature permits the generation of a CDB even when database modelers are confronted with limited data availability. The usefulnessfaithfulness of the synthetic
environment increases with the number of available layers.
The layering mechanism improves the efficiency of the client-devices since they need only access and be aware of the datasets that are relevant to them, at their prescribed level of
fidelity. For instance, a simulator CGF client-device will not likely have a reason to use ground raster imagery; however, it is quite likely interested in accessing ground surface properties when
determining traffic-ability.
1.4.5.3 Levels-of-Detail
The availability of LOD representations is critical to real-time performance, especially when dealing with grid-organized data. Most simulation client-devices can readily take advantage of
an LOD structure because, in many cases, less detailinformation is necessary at increasing distances from the simulated own-ship. As a result, many client-devices can reduce by 100-fold
or more the required bandwidth to access synthetic environment data in real-time.
Additionally, the availability of LODs can be readily exploited by simulator client-devices to improve their algorithmic efficiency. Devices such as Image Generators IGs can readily take
advantage of an LOD structure because image perspective naturally reduces image detail with distance as a result of the perspective computation inherent to the IG; as a result, much less
geometric detail and texture detail need be processed or considered at far range.
The spatial sampling pitch of each successive LOD follows power of two progressions; this is a pre-requisite for the efficient and deterministic management of memory by all client-devices of a
typical simulator.
The terrain LOD can be controlled to the tile level. Since the CDB Specification supports a variable LOD hierarchy spanning up to 34 levels, it is possible to control the allocation of LODs
by area. The variable LOD hierarchy provides for efficient use of storage because the LOD hierarchy needs to be deepened only in the areas where higher resolution is desired. Figure 1-5:
Variable Allocation of LOD, illustrates an earth strip made up of a series of tiles; some portions of the strip have been modeled with 3, 4, or 5 LODs according to the application requirements.
1.4.6 Platform Independence
The constraints imposed by the CDB Specification are minimal and are designed to allow its implementation on any of the widely available computer hardware platforms, operating systems,
file systems and transport protocols.
On CDB-compliant simulator client-devices
10
, any CDB can run “as-is” without the traditional off-line compilation step. This allows the simulation user community to freely exchange CDBs
10
A CDB-compliant client-device is a client-device that inputs synthetic environment data that conforms to the format, structure and conventions of this Specification. Any client-device that does not natively conform to this
17 © 2015 Open Geospatial Consortium
across simulators either through the exchange of physical media or entire storage subsystems or via network. As a result, a CDB can run without change regardless of the computer platforms,
simulator system software and simulator client-devices. While the CDB Specification does not explicitly mandate the use of specific computer platforms and system software, it does however
specify a set of minimum criteria as listed below.
Figure 1-5: Variable Allocation of LOD
1.4.6.1 System Software Independence
The following paragraphs explain the various software requirements.
Specification must reformat and restructure the CDB data to the device’s native formatstructure through the use of a runtime publisher. A client-device need not input all of the CDB datasets and attributes to be CDB-compliant.
18 © 2015 Open Geospatial Consortium
1.4.6.1.1 File System
The CDB Specification is file system independent, i.e., it does not mandate the use of a specific file system. However, compliance to the CDB Specification does require that the file system be
able to support a minimal set of capabilities. All modern file systems in use today conform to the minimal set of capabilities described in Section 2.2, File System File Naming Conventions.
1.4.6.1.2 Operating System
The CDB Specification is Operating System OS independent; it does not mandate the use of a specific OS. However, compliance to the Specification does require that the operating system be
able to support a minimal set of capabilities. All modern operating systems in use today conform to the minimal set of capabilities listed below. This includes Windows32, NT, UNIX, Linux,
IRIX, Solaris, etc.
The CDB Specification assumes that the operating system supports, as a minimum, the following:
1. Byte-stream random file access 2. 32-bit integers, natively
3. A 32-bit address space 4. Floating point support per IEEE-754, natively
5. 2GB virtual address space per process 6. Memory paging
7. Network communication
1.4.6.1.3 Transport Protocols
The CDB Specification is transport protocol-independent; it does not mandate the use of specific transport protocols. Furthermore, the Specification does not explicitly rely on or specify any
transport protocols.
1.4.6.2 System Hardware Independence
The CDB Specification is hardware independent; it 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 Specification implementation
11
. The CDB Specification assumes that the system hardware supports, as a minimum, the
subsystems described in the following sections.
11
The CDB Specification internally uses conventional “atomic” data types, namely signedunsigned n-byte quantities, ASCII strings, IEEE-754 floats singledouble. While it is theoretically possible to build a CDB
Specification-compliant software implementation on a processor platform that does not explicitly support these atomic types, it is clear that such implementation would be inefficient.
19 © 2015 Open Geospatial Consortium
1.4.6.2.1 ProcessorMemory
The CDB Specification is processor-independent; it does not mandate the use of a specific processor type. However, compliance to the CDB Specification does require that the processor
be able to support a minimal set of capabilities. All modern processor systems in use today conform to the stated minimal set of capabilities listed below. This includes processors such as
the Pentium, XEON, Celeron, Duron, Athlon, MIPS, and PowerPC. The CDB Specification does not impose requirements on hardwarememory over and above those mandated by the
commonly available OS; as a minimum, the CDB Specification itself requires support for:
1. 8-bit, 16-bit, and 32-bit signed and unsigned integers, natively 2. A 32-bit address space
3. 32-bit and 64-bit double precision floating point values IEEE-754, natively 4. 2 GB virtual address space
5. Virtual memory space 6. Immediate and indirect memory addressing modes
1.4.6.2.2 Storage Subsystem
The CDB Specification does not impose requirements on the storage subsystem other than those mandated by the selected OS and the selected file system. As a minimum, it must be able to
support file system as previously specified. An empty CDB requires very little in terms of storage; it will likely fit on a few diskettes or a single CD. However, a typical CDB is expected
to range from hundreds of Mbytes to hundreds of Tbytes.
1.4.6.2.3 IO Subsystem
The CDB Specification does not impose requirements on its IO subsystem other than those mandated by the selected OS, specifically:
1. Disk IO subsystem 2. Network IO subsystems
1.4.6.2.4 Client-Device Independence
The CDB Specification is client-device independent; it caters to the collective needs of all client- devices likely encountered on a tactical mission simulator; the Specification itself is completely
independent of any vendor-specific devices.
NOTE: 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 off-line or on-line repository, the CDB
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 Specification makes use of data types commonly available in standard computer platforms
20 © 2015 Open Geospatial Consortium
floats, integers, etc.. While it would be theoretically possible to cater to a client-device that does not support the CDB Specification “atomic” data
types, it would unduly load the attached on-line publisher. As a result, it is recommended that all client-devices provide hardware support for the
CDB atomic data types.
The CDB Specification limits its scope to synthetic representations of the earth; its internal data is organized and optimized to reflect its intended use in simulation applications. The concept of
an earth model and the means to represent earth surface regions with associated cultural features figure prominently within the Specification because they are important to the targeted CDB
applications
12
. Since it is the client-devices that initiate access to the CDB, they must each be theoretically
“aware” of at least the geodetic earth model. Otherwise, the contents and the structure of the CDB can be completely abstracted from the client-device. The runtime publishers provide the
necessary level of abstraction. The level of abstraction provided by the publishers is purely a function of the selected implementation of the client-device and its associated publishers. It is
entirely acceptable, for the client-device to understand and to be completely “aware” of the CDB as it is defined by the CDB Specification. In this case, such a device would not require a runtime
publisher, because it is already CDB-native.
The runtime publishers bridge the gap between the information content requested by the attached client-device and the information content and structure available to them in the CDB. As a
result, the runtime publishers must each be theoretically “aware” of the following CDB concepts:
1. Tile: Ability to understand the concept of earth surface areas hierarchically
subdivided in accordance to the CDB Specification 2. Level of detail:
Ability to understand the concept of resolution or level-of-detail, for terrain, cultural vector data, raster imagery, and model geometry
3. Terrain surface representation: Ability to understand concepts pertinent to earth surface geometry and
attribution 4. Cultural vector data point, linear, areal:
Ability to understand the concept of point, linear and areal cultural data and related attribution, fixed or conformed to earth surface
5. Grid-organized data and meshes: Ability to understand the concept of grid-organized single-value datasets e.g.,
elevation grid and multi-value datasets e.g., color triplets
12
Conversely, the Specification is not optimized to represent CADCAE data for use in manufacturing.
21 © 2015 Open Geospatial Consortium
6. Imagery: Ability to understand the concept color raster imagery mapped onto terrain
surfaces or models 7. Model geometry incl. light points:
Ability to understand the concept of general surface geometry 8. Model positioning capability:
Ability to differentiate between statically and dynamically positioned models 9. Descriptive attribution:
Ability to understand the attribution concepts pertinent to the client-device
1.4.7 Synthetic Environment Scalability Adaptability
The concept of scalability when applied to synthetic environments not only applies to the geographic extent of the database but more importantly, it also reflects the ability to scale the
environment in resolution and fidelity. These concepts are fully supported by the CDB Specification and are explained below:
1. Geographic extent: Correspond to the range of geographic extent of the earth surface that can be
modeled. 2. Resolution:
Correspond to the range of information density for instance, the number of elevation values per km2 of the modeled datasets.
3. Fidelity: Correspond to the amount and type of synthetic environment data that can be
modeled to support higher-fidelity simulator client-devices
13
. Consider for instance a simulator capable of supporting a single-surface earth skin
representation versus one capable of representing tunnels, bathymetric data, location-dependent tide heights, location-dependent wave heights, etc.
Clearly, the amount of information required by the higher-fidelity simulator is greater.
4. Precision:
13
The CDB Specification supports this concept through two mechanisms: Data defaulting: The CDB Specification is tolerant to missing data, because all attributes, layers and
datasets have Specification default behaviors. As more of the data is provided, the fidelity of the environmental database increases.
Additive layering: The CDB Specification offers a layered environment database organization. The layer organization is “fidelity-ordered”, i.e., basic layers appear first in the hierarchy while the layers needed for a higher-
fidelity simulation appear later in the hierarchy.
22 © 2015 Open Geospatial Consortium
Correspond to the range of numerical precision i.e., number of bits allocated to represent a quantity of the modeled datasets.
Today, modelers face difficult challenges if they want a synthetic environment that is both scalable and adaptive. The solution to this difficult issue extends beyond the “mechanics” of
achieving backwardforward compatibility; it also requires a complete “dissociation” of the database from any of the constraints imposed by the client-devices. It is current practice today
for modelers to repeatedly adjust the content, resolution and density of synthetic environment databases to closely match the capabilities and performance of the targeted client-devices. When
content is added to the database, previously modeled content is usually removed or simplified. Under such constraints, it is difficult for a modeler to build a synthetic environment database
capable of meeting anything but its immediate requirements.
Figure 1-6: Typical Evolution of a Database shows the typical evolution of a modeled region for use in a mission rehearsal. The initial version of the region may have only a few high-
resolutionhigh-fidelity areas; however, over a given time period, modelers will be asked to model additional target areas. As a result, the size, complexity, resolution and fidelity of the
synthetic environment database gradually increase. Without built-in provisions for scalability, significant rework of the database is required each time a target area is added.
Figure 1-6: Typical Evolution of a Database
The CDB Specification, on the other hand, offers a new paradigm: the “dissociation” of the synthetic environment database’s extent, resolution, fidelity, precision, structure and format from
its client-devices. This concept is not limited to aspects of formatting, numerical representation, internal structure, file structure, file systems, etc. More importantly, the concept also covers
aspects relating to synthetic environment database fidelity and resolution. Historically, the fidelity and resolution of synthetic environment databases has been intimately linked to the
capabilities of the targeted simulator client-devices. More often than not, the source data was manipulated and adapted to constraints imposed by the client-devices. As a result, the content,
resolution and density of synthetic environment databases were repeatedly adjusted to closely match the capabilities and performance of the targeted client-devices. The amount of time
devoted to repeatedly addingeditingremoving content, and then repeatedly re-publishing would largely exceed the effort of creating and building the original synthetic environment database.
The CDB Specification offers the means to break this inter-dependence.
23 © 2015 Open Geospatial Consortium
When assembling a CDB, the synthetic environment database modeler is permitted within their time-cost budget to include content that significantly exceeds the capabilities of their
simulators. The job of “adjusting” content to client-devices is relegated to the runtime publishers; the modeler is freed from this labor-intensive, repetitive task.
In a typical CDB Specification implementation, it is anticipated that client-devices will independently control their respective runtime publishers so that the runtime published synthetic
environment corresponds to their inherent capabilities resolution, fidelity, etc..
Nonetheless, the runtime publishing paradigm offers interesting new possibilities. For instance, it would be possible to individually adjust the fidelity and resolution of the synthetic
environment for each client-device; this adjustment could be done at any time. As a result, it is possible to control and adjust the overall simulator fidelity and correlation to a level that was
previously unachievable.
1.4.8 Platform Scalability
The CDB Specification does not enforce a particular computer hardware infrastructure. The selected infrastructure allocated to the handling of the CDB is largely determined by the overall
simulation requirements. Any leeway the simulator architect may have at their disposal when trading-off various simulator performance parameters against each other, are as follows:
1. Geographic extent 2. SESimulator Resolution
3. SESimulator Fidelity 4. SESimulator Precision
5. Desired level of client-devices correlation 6. Client-level SE load management
7. Simulated aircraft speed 8. CDB sharing
An experienced simulation engineer can typically undertake this analysis; however, the process requires a good understanding of the content available in the targeted CDBs and of the content
each client-device needs in order to meet its stated level of performance and fidelity. If for cost considerations the system engineer is unable to reconcile both, he can relax or trade-off some of
the above parameters.
Alternately, it is possible to implement a simulator with client-devices or attached publishers that are capable of automatically adjusting resolution and fidelity in order to overcome
performance limitations attributable to the CDB storage infrastructure andor runtime publishers.
Figure 1-7: Typical Implementation of CDB Specification on High-end Simulator, below is a system block diagram of a typical implementation of the CDB Specification on a high-end
tactical flight simulator. The runtime CDB system serves the combined needs of a mission functions computer, an OTWNVG IG, a FLIR IG, Radar and a CGF subsystem equipped with
its own terrain server. The runtime CDB system is scaled to reflect the collective capabilities of the attached client-devices; as a result, the storage system is configured to supply the necessary
24 © 2015 Open Geospatial Consortium
bandwidth. Similarly, the IO bandwidth of the CDB servers and processing performance of the runtime publishers are scaled to satisfy the demands of their respective client-devices.
Figure 1-7: Typical Implementation of CDB Specification on High-end Simulator
Figure 1-8: Typical Implementation of CDB Specification on Desktop Computer, below shows a modest application of the CDB Specification; it consists of a single desktop computer equipped
with both stealth viewer and radar simulation application software. Each application is front- ended by a runtime publisher that in turn interfaces to the CDB via a standard file system. Given
the more modest platform resources, some trade-offs in either resolution or fidelity might be required. This can be implemented in the runtime publisher or in the client-device application
software.
25 © 2015 Open Geospatial Consortium
Figure 1-8: Typical Implementation of CDB Specification on Desktop Computer
1.4.9 Simulator Wide Unique Data Representation, Data Normalization
A CDB is a single repository for the entire simulator’s synthetic environment DB. The CDB’s internal structure ensures that all datasets are uniquely represented yet available through a
publishing process to each of the simulator client-devices at runtime. This paradigm eliminates the extensive duplication of datasets that are shared by two or more client-devices.
The CDB Specification is technically a normalized data model in the sense that it best meets the logical data design objectives of correctness, consistency, simplicity, non-redundancy and
stability. Ignoring any tailoring or tuning for particular application requirements or performance, a normalized design provides the following advantages:
1. Minimize amount of space required to store data: Normalization precludes storing data items in multiple places.
2. Minimize risk of data inconsistencies within the database: Since datasets are stored in only one place, there is no risk of datasets
becoming inconsistent uncorrelated. 3. Minimize possible update and delete anomalies:
A normalized CDB eliminates the concerns related to update or delete operations.
4. Maximize the stability of the data structure: The process of normalization helps in associating attributes with entities based
26 © 2015 Open Geospatial Consortium
on the inherent properties of the data rather than on particular application requirements. Thus, new application requirements are less likely to force
changes on the CDB Specification database design.
1.4.10 Compression of Storage Intensive Imagery Datasets
The CDB Specification prescribes the use of an industry standard compression algorithm for its storage intensive raster imagery datasets. This not only provides a substantial reduction in
storage, but also reduces the data transmission bandwidths associated with simulator’s access to the synthetic environment database at runtime. As a result of its storage efficiency, the CDB
Specification relies on relatively few data formats for storing its datasets; there is no benefit other than storage efficiency to be gained in supporting any other specialized data formats
whose underlying objective is only for storage efficiency. The CDB Specification embodies the JPEG 2000 industry standard format for raster imagery because it has comparable storage
efficiency to all of these image formats without sacrificing any generality. JPEG 2000 has been chosen by the CDB Specification as a format for the storage of OTW raster imagery because of
the following characteristics:
1. High compression efficiency: Compression better than 0.25 bits per pixels. Virtually indiscernible loss in
image quality for 10:1 – 20:1 compression. 2. Lossless and lossy compression:
Lossless compression ratios approx. 1.7:1 3. Perceptual color space internal coding:
Allow dark images to be reconstructed without banding artifacts. 4. High dynamic range:
Compress and decompress images with various dynamic ranges e.g., 1-bit to 16-bit for each color component.
5. Large images sizes: Up to 232 - 1
There are other characteristics of the JPEG 2000 that are worth mentioning but are not directly beneficial to the CDB Specification. Those are:
1. Progressive image reconstruction: Allow images to be reconstructed with increasing pixel accuracy and
resolution. 2. Region of interest coding:
Permits certain Region of Interest ROI’s in the image to be coded and transmitted with better quality and less distortion than the rest of the image.
3. Seamless quality and resolution scalability: Without having to download the entire file
4. Error resilience during transfers.
27 © 2015 Open Geospatial Consortium
JPEG 2000 will be solely targeted at Raster Imagery data only. The reason is simply because of its highly efficient compression scheme that fits well with the goal of reducing the huge datasets
associated with Imagery. Other raster-based datasets defined in the CDB will solely be using the TIFF format due to their more manageable size.
1.4.11 Compression of other Raster Datasets
In general, all TIFFGeoTIFF files benefit from LZW compression when their content is not of type floating-point. For this reason, and as a general practice, the CDB Specification
recommends the compression of all TIFF-based raster datasets containing integer values.
1.5 Key Benefits of the CDB Specification
The following outline the key benefits of using the CDB Specification.
1.5.1 Improved Synthetic environment DB Generation Timeline
Important reductions in both the DB generation and DB update timeline are expected from the CDB Specification because:
1. There is no need to compile distinct synthetic environment runtime databases for each of the simulator client-devices.
2. All of the datasets common to two of more client-devices need not be duplicated. All associated client-specific structures are also eliminated.
3. Tiles and layers are technically independent from each other; as a result, there is no need to reprocess neighboring tiles and coincident layers. However, one
exception to this relates to the level-of-detail generation. 4. The CDB Specification tile structure permits users to “pipeline” or overlap the
DB creationupdate process, see Figure 1-9: Pipelined DB Update Process, with DB transfer process
14
.
Figure 1-9: Pipelined DB Update Process
5. The CDB Specification tile structure lends itself naturally to the concurrent or “parallel” production of the CDB.
14
Assuming the DB toolset used by the modelers at the DB Generation Facility allow its users to manipulate Environmental DB content on a small-area basis.
28 © 2015 Open Geospatial Consortium
6. The CDB Specification internal versioning mechanism lends itself well to CDB updates because only the affected tiles or layers need be re-transmitted
to the simulator. This represents a significant timesaving, especially in cases where small updates are constantly applied to a comparatively large CDB.
7. The conversion of the synthetic environment from its tool-native representation into a form directly entered by each of the simulator client-
devices is broken down into several publishings accomplished in real-time on behalf of each of client-device. This approach permits the CDB Specification
representation of the synthetic environment to be “dissociated” from the resolution, fidelity, precision, structure and format imposed by each client-
devices. Collectively, the runtime publishers handle the more complex portion of the workload; they transform the CDB data into a form that is
ingested on-the-fly by the client-device. This process is done in real-time, on a demand-basis, as the simulator progresses within the synthetic environment.
Since there is one publisher for each of the client-device, the publishing workload is typically distributed across several computer platforms.
Furthermore, since the simulated own-ship moves at speeds that are bounded by the capabilities of the simulated vehicle, it is not necessary to instantly
publish the entire synthetic environment before undertaking a training exercise; the runtime publishers need only respond to the demands of the
client-devices. When the simulated own-ship’s position is static, runtime publishers go idle. As the own-ship starts advancing, client-devices start
demanding for new regions, and publishers resume the publishing process. Publishing workload peaks at high-speed over highly resolved areas of the
synthetic environment.
1.5.2 Interoperable Simulation-Ready Synthetic environment DB
A CDB-compliant database CDB is a fully interoperable, simulator-ready synthetic environment DB, i.e., it can be used “as-is” on any CDB-compliant simulator. Because the CDB is free of
any simulator dependencies, there is no need to undertake a time-consuming and expensive rework of the runtime databases in order to adapt it them to the format, structure, content, and
precision constraints imposed by the simulator.
1.5.3 Improved Client-device RobustnessDeterminism
The CDB Specification tile organization provides the means to implement deterministic loading andor paging of the CDB because each tile corresponds to the same amount of data i.e., a
“quanta” of information called a LOD-tile, regardless of its position on earth and regardless of its assigned LOD. This is a key characteristic of the CDB Specification and is necessary to
ensure deterministic operation of client-devices, even when the CDB’s resolution varies considerably from region to region or when the CDB is modeled at an extremely high-resolution.
It is quite straightforward for a client-device to determine the amount of memory it must locally allocate when loading or paging-in a geographical area of interest. If the geographical area of
interest exceeds the client-device’s capabilities, it can easily revert to a coarser LOD, hence
