Correlated Databases Are Your Friend
If one simulator is updated with a different terrain database, IG (image generator), or run-time, or if a user is attempting to combine simulators in a heterogeneous or mixed environment that share the same terrain, then violations become much more likely.
For example, an organization is connecting an Apache helicopter simulation to an Abrams tank simulator. This will likely be a mix of differing technologies since each simulator was purchased at a different time, uses different run-times and protocols. Because the user cannot change the technology the simulators are built on, it is important that both simulators are using the same terrain database.
That said, each simulator’s run-time might read the database differently, and render it in an inconsistent manner from one simulator to the other. How a run-time reads, interprets and displays data may not be the same. If the Apache simulator cannot support the volume of trees – for example – contained in the database and therefore only displays some of the trees, while the Abrams simulator displays all trees, then a violation occurs.
This LOD (level of detail) correlation issue is not only limited to different run-times but can also apply to terrain database formats as well. When using differing database formats, it is essential to ensure that they are correlated. For example, two terrain databases represent the exact same geographical coordinates, but one is in the OpenFlight format, and the other in JCATS. To be fair fight compliant, each one should contain the same data as the other. That is, buildings, trees, rivers, elevations, etc. should be identical. Furthermore, it is important that each database’s LODs are also correlated so that at certain distances, features or buildings are displayed consistently across all simulators.