24
© 2016 Open Geospatial Consortium
● Tiles: The CDB defined storage structure allows efficient searching, retrieval and
storage of any information contained within the CDB. The storage structure portion of this standard geographically divides the world into geodetic tiles each tile bounded by
latitude and longitude, each tile containing a specific set of features such as terrain altimetry, vectors and models such as 3d models and radar cross section models, which
are in turn represented by the datasets. The datasets define the basic storage unit used in a CDB data store. The geographic granularity is at the tile level while the information
granularity is at the dataset level. As a result, the CDB storage structure permits flexible and efficient updates due to the different levels of granularity with which the information
can be stored or retrieved
● Layers: The CDB model is also logically organized as distinct layers of information.
The layers are notionally independent from each other i.e., changes in one layer do not impose changes in other layers.
● Levels-of-Detail LODs: The availability of LOD representations is critical to real-time
performance. 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 environmental data in real-time. The
availability of levels-of-detail permits client-devices to deal with data stores having big- data levels of content. The CDB storage model supports a LOD hierarchy consisting of
up to 34 LODs. The CDB standard requires that each geographic area be reduced into a LOD hierarchy in accordance to the availability of source data.
The standard does not define or enforce an operating system or file system.
1.6.4 What the CDB Standard is Not
The representation and sharing of geospatial data plays a key role in the interoperation of systems and applications that use such data. In the mid to late 90’s some specificationsstandards
were conceived to provide a means of sharing synthetic environment data, in source form, for a wide variety of applications. They provided a standardized means to share native databases,
thereby avoiding direct and often inefficient conversion of the data tofrom often proprietary native database format.
The CDB standard defines a model for data representation and attribution of terrain, objects and entities within the CDB data store. However, the standard does not define requirements for the
movement, change in shape, physical properties andor behavior of such objects and entities. These capabilities fall under the domain of simulation software or application.
The CDB standard does not define requirements for the representations of celestial bodies, such as the Sun, Moon, stars, and planets. Rather, this standard assumes that the modeled
representation of celestial bodies is internally held within the appropriate simulator client- devices.
The CDB standard does not specify a mandatory “coverage completeness requirement” imposed by. This permits the generation of a CDB structured data store even when there is limited data
availability.
25
© 2016 Open Geospatial Consortium
Given the requirement that the CDB standard be platform independent, the standard does not provide the implementation details of specific off-line data store compilers or runtime publishers
attached to specific client-devices
9
. Furthermore, since there is no standardization of the SE representation internal to client-devices they vary by type
10
, by vendors, it is unlikely that such information would completely satisfy the interests of all developers. More importantly, the
structure and format of data ingested by each client-device is typically proprietary. Finally, this standard does not describe the effort required to develop CDB off-line compilers andor CDB
runtime publishers.
1.7 General CDB Data Store and Implementation requirements
