Algorithmic correlation: Is the degree of informational consistency between Parametric correlation: Is the degree of informational consistency between

48 © 2015 Open Geospatial Consortium error by exercising explicit control, at run-time, on the resolution of the data processed by the client-devices. This approach is much preferable to off-line published approaches where parametric correlation is established during the compilation of the runtime databases and cannot be changed once the runtime database is produced. Table 1-1: Summary of Synthetic Environment Database Correlation Errors, provides a summary of the different types of correlation errors and howwhere such errors can be addressed. Figure 1-15: Sources of Synthetic environment Database Correlation Errors, illustrates the conventional synthetic environment database process from raw source, the assembly of datasets at the DB workstation, the publishing into runtime databases, and the rendering by the simulator client- devices. Table 1-1: Summary of Synthetic Environment Database Correlation Errors Correlation Description Addressed by C D B S p e c S im D e vi c e s D a ta b a se T o o ls Data Raw Source Raw source correlation errors caused by data collections at different times and from different devices. Also caused by registration errors. Toolset and human operators address raw source correlation errors ensuring that data is properly corrected and registered. X Datasets Dataset correlation errors are caused by discrepancies between co-located dataset layers. Toolset ensures that dependent dataset layers are updated together, while CDB Specification minimizes these dependencies. X X Runtime Sources Information from several runtime databases contains conflicting information. CDB Specification addresses runtime source correlation by enforcing a single runtime database. X 49 © 2015 Open Geospatial Consortium Correlation Description Addressed by C D B S p e c S im D e vi c e s D a ta b a se T o o ls Computational Algorithmic Different client-devices may use different algorithms to filter information and to simulate real-world device. Simulation clients address algorithmic correlation errors. They ensure that the different algorithms used are compatible. X Parametric Same client-devices may run with different initial parameters. A simulation that would ensure each client- device runs at just discernible error levels. X Accuracy Different computational platforms may run at different numerical accuracies. Using the same platform with identical numerical accuracy for all client- devices and servers. Developing software according to strict rules and guidelines addresses computational accuracy correlation errors. X X X Temporal Synchronism Lags and delays introduced by networking systems as well as subsystems using different time bases may cause subsystems to be unsynchronized. Through system architecture, system is designed to use proper bandwidths and computational methods to reduce latencies. All simulator client-devices use the same clock. X Paging latency Paging and runtime publishing may introduce delays long enough to prevent some simulation clients to get information on time. Paging and runtime publishing tasks and client-device paging software ensures that runtime information is available on time. X 50 © 2015 Open Geospatial Consortium Figure 1-15: Sources of Synthetic environment Database Correlation Errors 51 © 2015 Open Geospatial Consortium The implementation of the CDB Specification on a simulator can also provide the means to reduce and control the sources of parametric correlation at the client-device level. The underlying cause of parametric correlation usually points to the intrinsic capabilities i.e., the performance and functionality of each client-device. Since many client-devices are unable to cope with the synthetic environment database at its full fidelity, the off-line compilers “filter- out” portions of the database e.g., level of resolution, level of fidelity in order to meet the limited functionality or the real-time constraints of the targeted device. In order to further control processing variations, some client-devices are equipped with the means to dynamically “filter-out” portions of the database in order to meet real-time constraints. The filters can be typically controlled statically and sometimes even dynamically through the use of parameters. The amount and type of data that is rejected by each type of client-device can vary considerably. This is the underlying cause of parametric correlation errors. In conventional simulator client- devices, the handling of parametric correlation is handled in a half-hazard fashion, largely because the “filter parameters” are either fixed or inaccessible to the user. Distinct database compilers generate distinct runtime databases, each configured with their respective filtering parameters. The CDB Specification offers multi-tiered solutions to this problem. Firstly, since it has a unique data representation, the resolution, fidelity and accuracy of the synthetic environment database, as seen by each of runtime publisher attached to the client-devices, is completely correlated. Secondly, since the publishing process is done on-line, it is possible to provide the user access to the filter parameters so that he can globally control resolution, fidelity and accuracy and hence correlation of the synthetic environment database across all simulator client-devices. While the CDB Specification does not provide explicit jurisdiction over the implementation of this mechanism in the client-devicespublishers, it is nonetheless possible to improve parametric correlation, at runtime, via control of the client-devicespublishers. This new paradigm now permits the simulator user the means to not only control client-device load but to globally re-examine and control the level of correlation within a simulator or across simulators. The control of parametric correlation requires a working understanding of the characteristics of the client-device. At a minimum, one must consider the operating limits of all client-devices and ensure that the runtime publishers limit synthetic environment content to the limits imposed by the client-devices 22 . Secondly, one must have a working model of the “filter parameters” made available by the client-devices or by their runtime publishers. Thirdly, one must have a working performance model of each client-device. Finally, one must have an understanding of “just discernible threshold” of correlation as it applies to each client-device. For example, it is unlikely that increasing the terrain resolution from 1m to ½m would produce a discernible change in how a CGF system allows simulated players to interact realistically with one another. As a result, the ½m terrain resolution of the CGF system is below the “just discernible threshold” of that device. The ½m data can be discarded without reducing the level of correlation provided by that client-device. 22 For instance, an IG might refuse to operate if confronted with an area modeled with 1 millimeter OTW texture. 52 © 2015 Open Geospatial Consortium As mentioned earlier, the runtime publishing paradigm permits the simulator user the means to control client-device load and to globally re-examine and control the level of correlation within a simulator or across simulators. Several choices are possible, depending on the flexibility offered in the implementation of the runtime publishers and the client-devices. The choices are: 1. Publishers globally adjusted to overload limit of least capable client-device see Figure 1-16: Overload Limit of Least Capable Client-Device: Figure 1-16: Overload Limit of Least Capable Client-Device a. Assuming sufficient parameter controls in each of the client-devices, parametric correlation errors can be eliminated by setting the filter parameters of all client-devicespublishers to the least-capable client- device in the simulator. b. Success is contingent on suitable set of parameters in each client- device. c. The result is full correlation with no overloads, but with the lowest observed DB fidelity. 2. Publishers individually adjusted to the overload limit of each client device see Figure 1-17: Overload Limit of Each Client-Device: 53 © 2015 Open Geospatial Consortium Figure 1-17: Overload Limit of Each Client-Device a. This is the approach used in virtually all simulators in operation today. b. Result is partial correlation with no overloads, and high-observed DB fidelity. 3. Publishers adjusted to the CDB content, but globally adjusted to the operating limit of the least capable client-device see Figure 1-18: Operating Limit of Least Capable Client-Device: Figure 1-18: Operating Limit of Least Capable Client-Device a. Client-devices are allowed to overload in areas where database content is deemed critical. b. Result is full correlation, possible overloads with high-observed DB fidelity. 54 © 2015 Open Geospatial Consortium 4. Publishers adjusted to the CDB content, but individually adjusted to the operating limit of each client-device see Figure 1-19: Individually Adjusted to the Operating Limit of Each Client-Device: Figure 1-19: Individually Adjusted to the Operating Limit of Each Client-Device a. Client-devices are allowed to overload in areas where database content is deemed critical. b. Result is, possible overloads and the highest observed DB fidelity. 5. Publishers adjusted by the simulator operator at scenario startup see Figure 1-20: Adjusted by the Simulator Operator at Scenario Startup: Figure 1-20: Adjusted by the Simulator Operator at Scenario Startup 55 © 2015 Open Geospatial Consortium Chapter 2 2 CDB Concepts This chapter presents basic CDB concepts of the Specification. These concepts are either reused by other concepts or used repeatedly throughout the Specification.

2.1 Partitioning the Earth into Tiles

The CDB tiling approach has the following characteristics: 1. The earth model is divided in latitude into slices. 2. The slice’s x-axis is aligned to WGS-84 lines of latitude. 3. The slice’s y-axis is aligned to WGS-84 lines of longitude. 4. The number of units along the slice’s y-axis for a given level of detail is the same for all slices. The earth surface geodetic dimension in arc- second of y-axis units within an earth slice is exactly the same, regardless of latitude. 5. The geodetic dimension of an x-axis unit in arc-second is constant within a zone, but is re-defined at pre-selected latitudes to achieve a greater level of spatial sampling uniformity in all tiles; this overcomes the narrowing effect of increased latitudes on longitudinal distances. The definition of zones in the CDB is the same as those in DTED with the exception of the poles. 6. The number of units along the slice’s x-axis for a given level of detail is the same within each zone. 7. The number of units along the slice’s y-axis is constrained to a multiple of 2 n in all slices. 8. The number of units along the slice’s x-axis will vary depending on which zone the latitude of the slice belongs. At this point we introduce the concept of a CDB Geocell, which differs slightly from a DTED cell. Both DTED and the CDB have Geocells whose height is 1 degree but whose width varies depending on its latitude. The only difference is that the CDB provides for an additional zone at each of the poles. Table 2-2 shows the dimensions of a CDB Geocell per zones of latitude. For instance, in latitude zone 5, which goes from –50° to 50° of latitude, a CDB Geocell is 1° × 1°, in zone 4 and 6 which goes from latitude 50° to 70° the cell size is 1° × 2°. The main reason to introduce this concept is to maintain a reasonable eccentricity between the sides by trying to keep them as close to a square as possible. Variable CDB Geocell size in the CDB Specification reduces the simulator client-device processing overheads associated with the switching from one zone to another due to small number of zones across the earth, reduces the variation of longitudinal dimensions in meters to a maximum of 50 and improves 56 © 2015 Open Geospatial Consortium storage efficiency. Two criteria are used to define the size of a CDB Geocell: a. A CDB Geocell must contain a whole number of DTED Geocells; in other words a CDB Geocell must start and end on a whole degree along the longitudinal axis. This is done so as to facilitate mapping from CDB Geocells to DTED Geocells, b. The length of the CDB Geocell must be a whole factor of 180, in other words length of 1, 2, 3, 4, 6 and 12 degrees are legal but lengths of 7 and 8 degrees would not be since these are not exact factors of 180. Table 2-1: Intervals for DTED Level 2 DTED Zone Latitude Range Degrees Latitude Interval Arc seconds Longitude Interval Arc seconds I 0 – 50 N-S 1 1 II 50 – 70 N-S 1 2 III 70 – 75 N-S 1 3 IV 75 – 80 N-S 1 4 V 80 – 90 N-S 1 6 Table 2-2: Size of CDB Geocell per Zone CDB Zone Latitude Range Degrees CDB Geocell size ° Lat × ° Lon Number of DTED Geocells –90 ≤ lat –89 1 × 12 12 1 –89 ≤ lat –80 1 × 6 6 2 –80 ≤ lat –75 1 × 4 4 3 –75 ≤ lat –70 1 × 3 3 4 –70 ≤ lat –50 1 × 2 2 5 –50 ≤ lat +50 1 × 1 1 6 +50 ≤ lat +70 1 × 2 2 7 +70 ≤ lat +75 1 × 3 3 8 +75 ≤ lat +80 1 × 4 4 9 +80 ≤ lat +89 1 × 6 6 10 +89 ≤ lat +90 1 × 12 12

2.1.1 Description

The CDB Specification represents the earth as a fixed number of slices divided equally along a latitude axis as illustrated in Figure 2-1: CDB Earth Slice Representation.