Volume 11: OGC CDB Core Standard Conceptual Model

This section shows the relationship between the tile structure, layers and LoDs. As can be seen in Figure 4, any TileGeoCell class may have any number of layers and each layer is associated with a LoD matrix set.

This section describes how a current version of a CDB conformant data store uses the computer’s native file system to store data in files and directories, what the CDB versioning structure is, and how the data is categorized. Further, this section defines the structure of a CDB conformant data store, i.e., the name of all directories forming the CDB hierarchy, as well as the name of all files found in the CDB hierarchy. An important feature of the CDB standard is that all CDB file names are unique and that the filename alone is sufficient to infer the path of the file.

The CDB data store is composed of several datasets that usually reside in their own directory. However, some datasets share a common structure. The top-level directory of the CDB data store follows the following structures.

Most of the CDB datasets are organized in a tiled structure and stored under \CDB\Tiles\ directory. The tiled structure facilitates access to the information in real-time by any runtime client-devices. However, for some datasets such as Moving Models or Geotypical Models that require minimal storage, there is no significant advantage to their being added into such a tile structure. Such datasets are referred to as global datasets. They consist of data elements that are global to the earth.

A CDB Version is a collection of CDB and/or user-defined datasets. A CDB Version contains data belonging to a single version of a CDB conformant data store. One CDB Version may refer to another one, which is the basis for the CDB File Replacement Mechanism. The concept of a CDB Version is illustrated using the following UML diagram (Figure 4).

The diagram shows that a CDB Version contains CDB Datasets. In addition, it states which CDB Version Number has been used to build the CDB content. Finally, the CDB Version has a reference to another CDB Version. This reference allows the creation of a chain of CDB Versions. By chaining two CDB Versions together, the user can replace files in a previous CDB Version with new ones in a newer CDB Version data store. The diagram shows that a CDB Extension inherits all the attributes of a CDB Version and adds its own attributes, a name and a version number (of the extension). The client application checks the name attribute to recognize and process known CDB Extensions and unrecognized CDB Extensions are skipped.

The term Model refers to all of the modeled representations of a cultural feature. The model type features of a CDB can be represented using the following UML diagram. 3DModel, referred to as a GSModel, is unique. In the case where the 3DModel is instanced, it is referred to as a GTModel. A 3DModel that is capable of movement is called a MModel. In the case where a MModel is positioned by the modeler, it is called a statically-positioned MModel.

The term Model-LoD refers to a specific level of detail of a Model. The main properties of the CDB 2D/3D model type UML diagram are listed below.

Tiled vector data differs from their raster counterpart in three important ways. First of all, the tiled vector data internal structure permits a non-uniform distribution of elements within the tile: i.e., the position of each element within the tile is explicit. Secondly, the tiled vector data’s internal structure permits a variable number of elements within a tile’s boundary. Finally, the distribution of the element types from a single list can be controlled.

Conceptually, the LoD for tiled vector data implicitly provides the average density of elements within the tile. The run-time LoD behavior that controls the rendered number of data elements depends on various parameters and on the off-line filtering process.

The light name hierarchy for a CDB compliant data store is described in detail within the table found in Volume 2 Annex J of the OGC CDB Core Standard ^[5]. This Annex provides a description of the entire naming hierarchy, including the hierarchical relationship of the levels with respect to each other and the position of each light type within this hierarchy. To this end, the lights hierarchy definition controlled vocabulary is stored in an XML file in the metadata CDB directory. “Lights.xml” file contains the name of each light type and a unique code with each light type. Light codes have a one-to-one association with light types; consequently, the light codes are unique among all light types. For run-time access of this data, clients must be able to retrieve such information. The below diagram (figure 9) shows the UML diagram of light data hierarchy to define and validate the content of the CDB light names hierarchy found in /CDB/Metadata/Lights.xml.

This attribute “Version” represents the version number of the Light.xml file.

Client-devices use the light type code as an index to lookup the client-specific properties and characteristics of each light type using a Lights_xxx.xml. The CDB standard offers a complementary approach to modifying the appearance of lights. This approach provides basic control over light intensity, color, lobe width and aspect, frequency and duty cycle for potential use by simulation implementations. This approach also permits a modeller to add new light types to the CDB light hierarchy. The below UML diagram (figure) presents the schema for the fields of the Lights_xxx.xml which is generated from the schema file located at \CDB\Schema\Lights_Tuning.xsd.

The CDB Standard provides the means to unambiguously tag any portions of a 3D model (moving model or cultural feature with a modeled representation) with a descriptive name. Component model names are stored in the model components’ definition file, at \CDB\Metadata\Model_Components.xml which is delivered with the standard distribution package.

CDB Model Components is a list of components which are made up of the component names along with their descriptions.

A Base Material represents a basic material such as water, vegetation, concrete, glass, or steel. Each Base Material used in a CDB data store has a unique name. The components of a Base Material are listed in Volume 1 Section 2.5.1 of the CDB Core standard in Table 2-6: Components of a Base Material. A Base Material Table (BMT) is provided for run-time access by client applications. More details on the file format can be found in Volume 1 Core Standard section 5.1.3, Base Material Table. CDB Base Materials are listed and stored in an XML file named \CDB\Metadata\Materials.xml. The format of the file is defined by the following UML diagram generated from an XML schema that is delivered with the CDB standard in the file named \CDB\Metadata\Schema\Base_Material_Table.xsd.

The main properties of the base materials table UML diagram are documented below.

Composite Material Tables provide a structured arrangement by which Composite Materials can be defined. There are several Composite Material Tables spread across the CDB hierarchy. A CMT is a list of one or more composite materials. Note that all Composite Material Tables follow the following UML diagram.

The main properties of the composite material tables’ UML diagram are documented below.

Default values for all datasets can be stored in the default values’ metadata file “\CDB\Metadata\Defaults.xml”. Default values, defined throughout the CDB standard, are listed in Volume 2 Annexes for the Core CDB Standard (normative) - Annex S and the below UML diagram indicates the schema provided in \CDB\Metadata\Schema\Defaults.xsd to define and validate the content of Defaults.xml. There are two types of default values: read and write default values (‘R’ or ‘W’.) Generally, read default values are values to be used when optional information is not available. Write default values are default values to be used by CDB creation tools to fill mandatory content when information is either missing or not available. The default value name is a unique name identifying a default value for a given dataset. Valid default value names are listed in Annex S. Each default value has a type. Valid default value data types are “float”, “integer” and “string”.

The “XML_Version” attribute is used to indicate the version of the XML file containing the list of CDB Default Values. It is independent from the version of the standard.

Each CDB version has a version control file that is called Version.xml. Its contents should be defined and validated by the following UML diagram which is generated from the content of Defaults.xsd in the schema folder of the CDB.

The optional <PreviousIncrementalRootDirectory> element is used to refer to another CDB Version. This is the mechanism used to chain together two CDB versions. The mandatory <Specification> element indicates the CDB standard that is used to produce the content of the CDB Version. Note that version numbers of the standard are limited to the version numbers from the legacy industry-maintained CDB specification, specifically 3.2, 3.1, and 3.0. For the OGC standard, allowed versions are 1.0, 1.1, and 1.2. All the OGC versions are backwards compatible. Other values are not permitted. Finally, the optional <Extension> element indicates that this CDB Version is in fact a CDB Extension. A version control file that does not have a CDB Extension indicates that the CDB Version holds content that strictly follows the CDB standard.

A CDB Extension corresponds to user defined information, which is not described or supported by the CDB standard, stored within the CDB Version. As an example, such additional information could be client or vendor-specific information used to increase system performance. Any user defined information shall not replace or be used in place of existing CDB information. A CDB Extension only contains vendor or device specific information.

The CDB Configuration and CDB Version mechanisms allow users to manage the CDB by offering the following capabilities:

The Configuration metadata file provides the means of defining CDB Configurations. The complete XML schema is provided in /CDB/Metadata/Schema/Configuration.xsd delivered with the standard and displayed below.

A single XML file, named Configuration.xml, completely defines the configuration of a CDB. This way, the client application does not have to traverse the linked list of CDB Versions through the 'PreviousIncrementalRootDirectory' element found in Version.xml. The main properties of the configuration metadata UML diagram are documented below.

The CDB attributes are listed and described in Volume 1: CDB Core section 5.7.1.3 CDB Attributes. The controlled vocabulary for these attributes is stored in \CDB\Metadata\CDB_Attributes.xml and the following diagram indicates the schema file as provided in the CDB schema folder, Vector_Attributes.xsd. In essence, the file is the transposition of CDB Attributes into a format more appropriate for a computer program.

The UML diagram is composed of three majors sections (i.e., attributes, units and scalers), the first one being the most important. The file has a list of attributes, followed by two lists of units and scalers that are referenced by an individual attribute. The main properties of the vector attributes’ UML diagram are documented below.

This following UML presents an XML schema file in the CDB schema folder which defines the metadata associated with 3D models. These metadata are in accordance with the legacy industry-maintained versions of the CDB specification and includes name, feature data dictionary, mass, part, texture and materials.

The main properties of the 3D model metadata UML diagram are documented below.

The following conformance class is designed to determine if any dataset claiming conformance to the CDB Conceptual model is described based on the comprehensive set of requirements.

A class diagram shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships. Classes and relationships represent real-world concepts to describe the structure of a system. The CDB Core Standard is presented in this document in diagrams using the Unified Modeling Language (UML) class diagrams. The UML notations used in this standard are described here (see ISO TS 19103, Geographic information - Conceptual schema language for the details).

A relationship is a general term covering the specific types of logical connections found on class and objects diagrams. UML shows the following relationships:

The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity (the number of objects that participate in the association) of instances of that entity as listed in the below table:

In the document, UML diagrams typically identifies a stereotype with a bracketed comment for each object identifying whether it is a class, interface, etc. Additionally, the UMLs are color-coded as follow to show different stereotypes: