Volume 10: OGC CDB Implementation Guidance (Best Practice)

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:

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:

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:

Immediate and indirect memory addressing modes

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:

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.

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.

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:

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.

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…

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.

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.

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.

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.

Figure 1-3. Use of CDB as an Off-line and On-line Data Store Repository

The CDB standard associated Best Practices specify formats and conventions related to synthetic environments for use in simulation. However, many additional benefits can be garnered if a CDB structured data store is also used as an online data store repository. This is particularly true when one considers the effort expended in the deployment of the synthetic environment to the training and/or mission rehearsal facilities.

When used as an online data store repository, there is no need to store and maintain off-line published versions of the data store for each client-device (as illustrated in Figure 1-3). As a result, the storage and computing demands on the data store generation facility are significantly lowered. This is especially true of data store generation facilities whose mandate involves the generation of complex synthetic environments for use by several training facilities.

Figure 1-4: SE Workflow with CDB as Combined Off-line/Runtime Data Store Repository, illustrates the simplified database generation workflow resulting from a data store that is used as both an offline and a runtime SE repository.

Figure 1-4. SE Workflow with CDB as Combined Off-line/Runtime Data Store Repository

This approach permits the CDB representation of the synthetic environment to be “dissociated” from the resolution, fidelity, precision, structure and format imposed by the internals of client-devices. Compliancy to the CDB standard can be achieved either by modification of the client-device internal software to make it CDB-native or by inserting a runtime publishing process that transforms the CDB structured data into the client-device’s legacy native runtime format. In the later case, this process is done in real-time, on a demand-basis, as the simulator “flies” within the synthetic environment. Note that since the simulated own ship ^[10] 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 runtime publishers resume the publishing process. Publishing workload peaks at high-speed over highly resolved areas of the synthetic environment.

Note that virtually all simulation client-devices in existence today natively ingest proprietary native runtime formats. As a result, a runtime publisher is required to transform the CDB structured data into legacy client device’s native runtime format. The runtime publishing process is performed when the CDB conformant database is paged-in from the CDB storage device. Volume 7, OGC CDB Data Model Guidance provides a set of guidelines regarding the implementation of Runtime Publishers.

This section illustrates a possible implementation architecture of the CDB Standard on a flight simulator. The standard does not mandate particular simulator architecture or the use of specific computer platforms. The selected implementation varies with the required level of fidelity and performance of the simulator and its client-devices.

As shown in Figure 1-5: Typical CDB Implementation on a Suite of Simulators, a typical implementation of a CDB compliant system consists of the following main components.

Figure 1-5. Typical CDB Implementation on a Suite of Simulators

Note: Was A.13 in Volume 2 in original submission

The purpose of the MinElevation and MaxElevation components is to provide the CDB data store with the necessary data and structure to achieve the required level of determinism in the computation line-of-sight calculations with the terrain.  The values of each component are with respect to mean sea level.  Since both the MinElevation and the MaxElevation values are specified in this standard, any line-of-sight algorithm can rapidly assess an intersection status of the line-of-sight vector with the terrain.

There are three cases to consider:

CASE 1 – No intersection:  If all of the LOS Bounding Boxes are above the MinMax Bounding Boxes, then there is no intersection between the line-of-sight vector and the terrain.  No further testing is required.  (Refer to Figure A-16: Case 1 – No Intersection.)

Figure A-16: Case 1 – No Intersection

CASE 2 – Potential intersection:  If one or more of the LOS Bounding Boxes overlap with a MinMax Bounding Box, then there is a potential intersection between the line-of-sight vector and the terrain.  This step must be repeated with progressively finer level-of-detail versions of the MinElevation and MaxElevation values until Case 1 or Case 3 is encountered.  If the finest level-of-detail is reached and the LOS result still yields a potential intersection status (Case 2), then the LOS algorithm must perform a LOS intersection with the finest LOD of the Primary Terrain Elevation component using the prescribed CDB meshing convention.  (Refer to Figure A-17: Case 2 – Potential Intersection.)

Figure A-17: Case 2 – Potential Intersection

CASE 3 – Intersection:  If one or more of the LOS Bounding Boxes are below the MinMax Bounding Boxes, then there is an intersection between the line-of-sight vector and the terrain.  No further testing is required to determine whether there is intersection or not.  (Refer to Figure A-18: Case 3 – Guaranteed Intersection.)  However, to determine the intersection point, the LOS algorithm must perform the following additional steps.  If (starting with the LOS point-of-origin) one or more of the LOS Bounding Boxes overlap with a MinMax Bounding Boxes, then there is a potential intersection between the line-of-sight vector and the terrain for that MinMax Bounding Box.  This step must be repeated with progressively finer level-of-detail versions of the MinElevation and MaxElevation values until Case 1 or Case 3 is encountered.  If the finest level-of-detail is reached and the LOS result still yields a potential intersection status (Case 2), then the LOS algorithm must perform a LOS intersection with the finest LOD of the Primary Terrain Elevation component using the prescribed CDB meshing convention.

Figure A-18: Case 3 – Guaranteed Intersection

The default CDB standard color space follows the same convention as the Windows sRGB Color Space Profile. sRGB is the default color space in Windows, based on the IEC 61966-2-1 Standard. A sRGB compliant device does not have to provide a profile or other support for color management to work well.

Nonetheless, whether calibrated or not to the IEC Standard, all variants of RGB are typically close enough that undemanding viewers can get by with simply displaying the data without color correction. By storing calibrated RGB, the CDB standard retains compatibility with existing database tools and software programs that expect RGB data, yet provides enough information for conversion to XYZ in applications that need precise colors. Thus, the CDB standard gets the best of both worlds.

Full compliance to the CDB standard requires adherence to the color space described in this section. However, in virtually all cases, direct use of un-calibrated RGB is sufficient. The builders of Synthetic Environment Databases and the users of Visual Systems should be aware of these color space conventions; significant deviation from the underlying IEC assumptions may yield significant color differences.

The CDB standard encoded RGB color tri-stimulus values assume the following:

Table G-1. CIE Chromaticity for CDB Reference Primaries & CIE Standard Illuminant

According to PNG (Portable Network Graphics) Specification Version 1.0, W3C Recommendation 01-October-1996 Appendix, Color Tutorial,

(http://www.w3.org/TR/PNG-GammaAppendix):

“The color of an object depends not only on the precise spectrum of light emitted or reflected from it, but also on the observer, their species, what else they can see at the same time, even what they have recently looked at. Furthermore, two very different spectra can produce exactly the same color sensation. Color is not an objective property of real-world objects; it is a subjective, biological sensation. However, by making some simplifying assumptions (such as: we are talking about human vision) it is possible to produce a mathematical model of color and thereby obtain good color accuracy."

Chromaticity is an objective measurement of the color of an object, leaving aside the brightness information. Chromaticity uses two parameters x and y, which are readily calculated from XYZ:

XYZ colors having the same chromaticity values will appear to have the same hue but can vary in absolute brightness. Notice that x,y are dimensionless ratios, so they have the same values no matter what units we’ve used for X,Y,Z.

The Y value of an XYZ color is directly proportional to its absolute brightness and is called the luminance of the color. We can describe a color either by XYZ coordinates or by chromaticity x,y plus luminance Y. The XYZ form has the advantage that it is linearly related to RGB intensities.

The “white point” of a display device is the chromaticity x,y of the monitor’s nominal white, that is, the color produced when R = G = B = maximum.

It’s customary to specify CRT monitor colors by giving the chromaticities of the individual phosphors R, G, and B, plus the white point. The white point allows one to infer the relative brightness of the three phosphors, which isn’t determined by their chromaticities alone.

NOTE: The absolute brightness of the monitor is not specified. For computer graphics work, we generally don’t care very much about absolute brightness levels. Instead of dealing with absolute XYZ values (in which X,Y,Z are expressed in physical units of radiated power, such as candelas per square meter), it is convenient to work in “relative XYZ” units, where the monitor’s nominal white is taken to have a luminance (Y) of 1.0. Given this assumption, it’s simple to compute XYZ coordinates for the monitor’s white, red, green, and blue from their chromaticity values.

Make a few simplifying assumptions first, like the monitor really is jet black with no input and the guns don’t interfere with one another. Then, given that you know the

CIE XYZ values for each of red, green, and blue for a particular monitor, you put them into a matrix M:

RGB intensity samples normalized to the range zero to one can be converted to XYZ by matrix multiplication.

In other words, X = Xr*R  Xg*G  Xb*B, and similarly for Y and Z. You can go the other way too:

Where M^-1= The inverse of the matrix M used to go from XYZ-1931 color space to the CDB specification RGB color space.

In the RGB encoding process, negative sRGB tri-stimulus values, and sRGB tri-stimulus values greater than 1,00 are not retained. When encoding software cannot support this extended range, the luminance dynamic range and color gamut of RGB is limited to the tri-stimulus values between 0,0 and 1,0 by simple clipping.

According to PNG (Portable Network Graphics) Specification Version 1.0, W3C Recommendation 01-October-1996 Appendix, Color Tutorial,

(http://www.w3.org/TR/PNG-GammaAppendix):

“The gamut of a device is the subset of visible colors that the device can display. (Note that this has nothing to do with gamma.) The gamut of an RGB device can be visualized as a polyhedron in XYZ space; the vertices correspond to the device’s black, blue, red, green, magenta, cyan, yellow, and white.

Different devices have different gamut (e.g. database generation workstation, simulator display systems). In other words one device may be able to display certain colors (usually highly saturated ones) that another device cannot. The gamut of a particular RGB device can be determined from its R, G, and B chromaticities and white point.

Converting image data from one device to another generally results in gamut mismatches colors that cannot be represented exactly on the destination device. The process of making the colors fit, which can range from a simple clip to elaborate nonlinear scaling transformations, is termed gamut mapping. The aim is to produce a reasonable visual representation of the original image.