Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure

The CDB standard makes use of several XML namespaces to isolate the definitions of its schemas. The name of these namespaces is built around a base URL.

The target namespace of all CDB schemas follow this pattern:

"http://schemas.opengis.net/cdb/[Name]/[Version]"

Where the Name is identical to the filename portion of the file containing the schema and Version is the version number of the schema.

To illustrate how a target namespace is composed, here is the target namespace of the schema found in Version.xsd (item 12 in the list above):

"http://schemas.opengis.net/cdb/Version/1.1"

IMPORTANT NOTE: For brevity, the literal “CDB” in a schema path should be expanded to:

Name/1.1

in any implementation.

Metadata is "https://en.wikipedia.org/wiki/Data[data] [information] that provides information about other data”^[5]. In the geospatial community and the rapidly emerging spatial web community, metadata is critical to operations such as discovery and determining whether a resource is “fit for purpose”. Three distinct types of metadata exist: descriptive metadata, structural metadata, and administrative metadata ^[6].

The geospatial community has a long and extensive history in defining and using metadata for geospatial resources. Without metadata, discovery of required resources and determination of whether a resource is “Fit for Purpose” becomes difficult if not impossible. The geospatial community makes use of all three types of metadata, although the first and third are more critical. The CDB use of metadata focuses on use cases 1 and 3.

The following is a list of these files. While the general term being used is “metadata” in terms of the file system structure, a number of these files are either controlled vocabularies or attribute files. Please read Clauses 1.4.4, 1.5, and 3.1.1 Metadata Directory for more detailed information on the files maintained in that folder. The following table identifies the files stored in the metadata folder and whether they are metadata or controlled vocabularies.

Each of these files is described in detail later in this document.

In CDB version 1.1 and later, additional metadata requirements and elements are specified. These are traditional metadata including geospatial metadata. Specifically, the reader should reference clauses 3.1.1, 3.1.2, and 5.1 (special focus on 5.1.6). Also, make special note of the guidance in clause “3.2.3.2 How to handle the metadata directory.”

Moved to section 5.1 Volume 10: Implementation Guidance

Moved to section 5.2 Volume 10: Implementation Guidance

The CDB standard is transport protocol-independent. The standard does not mandate the use of specific transport protocols. Furthermore, this standard does not explicitly rely on or specify any transport protocols.

This section was moved to section 5.3 Volume 10, Implementation Guidance

CDB structured data stores may be implemented on any modern operating systems whether they are Windows-like or Unix-like.

Throughout this standard, the reader will notice that filenames and directory paths are specified using a mix of upper and lower cases. This choice is made to improve and ease the readability of those names.

However, it is important to note that no two names are to differ only by their case. After all, a name is used to designate a single object or concept whether that name is spelled in lowercase or uppercase or even using mixed case. For instance, the terms house, House, and HOUSE (and even HoUsE) all convey the same idea of a residence where people live. And this stays true for all combination of cases.

In general, all TIFF/GeoTIFF files benefit from LZW compression. For this reason, and as a general practice, the compression of all TIFF-based raster datasets is recommended. The one exception is when every cell in the raster dataset is a unique floating point number. In this case, the compressed file may be larger than the original.

Consequently, tiles at a given LOD never overlap with others of the same LOD and are always aligned with at least two of the edges of tiles at the previous LOD.

Figure 2-4 illustrates how different Levels of Detail (LOD’s) can be combined within individual geocells. In the illustration, some CDB Geocells of the pictured earth slice are represented using five LODs, while others have only three or four LODs. Each Geocell included in a CDB data store shall represented by an instance of at least the coarsest tile supported, i.e., one tile at LOD −10. In addition, it is not necessary that the entire geocell be represented at the same level of resolution across the entire cell. However, if a tile is present at LOD n, it implies that a courser tile exists at LOD n−1 covering the area of the tile at LOD n, until LOD −10 is reached.

Figure 2-4. Earth Slice Example (Five Levels of Detail)

A Base Material Table (BMT) is provided for run-time access by client applications. See section 5.1.3, Base Material Table for more details on the file format.

A substrate provides a means to describe the material composition of “hidden” materials located beneath (or inside) the surface of a feature. This information is not explicitly modeled using (for instance) polygons; instead it is an essential characteristic of the material that makes up the modeled feature.

Consider a seabed consisting of a silt deposit (Figure 2-6: Seabed Composite Material). Such a deposit might have a thickness of a few centimeters. In our model, it is considered too thick to be considered the surface substrate of the seabed. In fact, below this silt deposit, there can be sand with a thickness of a few dozen centimeters, followed by rock of (essentially) infinite thickness. A sonar device can use the thickness information provided by the Seabed Composite Material, to generate multiple echoes, corresponding to each substrate.

Figure 2-6. Seabed Composite Material

As a second example, consider a half-filled refinery oil tank (see Figure 2-7: Oil Tank Composite Materials).

Figure 2-7. Oil Tank Composite Materials

In order to capture different thermal signatures for the top and bottom portions of the tank, a modeler uses two different Composite Materials:

For the top half of the tank, the modeler uses a Composite Material consisting of paint (surface substrate), metal (primary substrate) and air (secondary substrate).

For the bottom half of the tank, the modeler uses a Composite Material consisting of paint (surface substrate), metal (primary substrate) and oil (secondary substrate).

Figure 2-8. Thermal Simulation of Oil Tank Composite Materials

Note that since the metal substrate is several centimeters thick, it is not considered to be the surface substrate of the oil. Figure 2-8: Thermal Simulation of Oil Tank Composite Materials, illustrates the different simulation responses for a FLIR and an OTW CDB client device for this particular example.

Composite Material Tables provide the means by which Composite Materials can be defined. Each entry within a Composite Material Table defines a structured arrangement of basic materials or of aggregates (i.e., a Composite Material). Each Composite Material entry is assigned a Composite Material Index (and an optional name). CDB datasets can then make use of the index value in order to select Composite Materials.

There are several Composite Material Tables spread across the CDB hierarchy. Note however that all Composite Material Tables follow a common XML notation that describes each Composite Material into its primary substrate, surface and secondary substrate components. Composite Materials Tables can take various forms, either as distinct XML files or embedded XML code within a file.

Here is the XML notation for a Composite Material Table:

The Secondary_Substrate and the Thickness are optional. To specify aggregates (more than one material attribute in the MIT), the Material block is repeated. The Secondary_Substrate is provided (and optionally repeated) to described composite (stratified) materials. They appear in order starting from the Surface_Substrate, if present, followed by the Primary_Substrate (nearest to the surface), and followed by the Secondary Substrate, if present.

In addition, each composite material can be optionally tagged with a descriptive name. The CDB composite material table mechanism provides the means to tag each CDB composite material with a data store tool-specific or modeler-specific composite material name.

Consider a linear feature in a CDB data store that corresponds to a painted stripe on a runway surface. The linear feature is stored in the Man-Made Lineal dataset; the linear feature references an entry into the Geocell’s Composite Material Table. That reference is the index of the Composite Material for painted asphalt. The entry pointed to describes a Composite Material whose Primary Substrate is 100% BM_ASPHALT and whose Surface Substrate is 100% BM_PAINT-ASPHALT.

Consider a terrain polygon feature in the GSFeature dataset. The polygon feature covers a large wetland area that contains 4 Base Materials, namely BM_SOIL (21%), BM_WATER-FRESH (51%), BM_LAND-LOW_MEADOW (26%) and BM_SAND (2%). The polygon feature references an entry into the Geocell’s Composite Material Table. That reference is the name of the Composite Material for wetlands. The entry describes a Composite Material whose Primary Substrate is composed of four Base Materials, namely water (with 51% weight), low height vegetation (with 26% weight), soil (with 21% weight) and sand (with 2% weight).

This file contains metadata, including spatial metadata, pertinent to an entire CDB data store. Please refer to Clause 5.1.x for detailed information for guidance on metadata elements should be specified for the global metadata elements. The specification of global metadata is mandatory in CDB version 1.1 or later. Please note that this standard does not specify which metadata standard shall be used. Instead, for flexibility and in recognition that different communities use different metadata standards or profiles of metadata standards, the CDB standard provides a list of allowed metadata standards and profiles of those standards. The reader should reference Clause 5.1.6 and Clause 5.1.12 for how the metadata standard used in a CDB data store is specified as part of the “Version” metadata.

This file contains the metadata that defines the light points name hierarchy for the CDB. Refer to Section 2.3, Light Naming, for a description of the light type hierarchy. A listing of the CDB light type hierarchy can be found in Annex J. If “Lights.xml” is not found in the metadata directory then use the hierarchy found in Annex J (Volume 2 OGC CDB Core Model and Physical Structure Annexes). Refer to Section 5.1.3 Light Name Hierarchy Metadata for a description of the light point name hierarchy file.

This file contains the metadata that defines the CDB model components. Refer to Section 2.4, Model Component Naming, for a description of the model components. The XML file containing the CDB Model Components ^[23] is part of the CDB standard distribution package and can be found in the following file: \CDB\Metadata\Model_Components.xml. Refer to section 5.1.4 of this document - Model Components Definition Metadata - for a description of the model component file.

This file contains the base material names for the CDB. Refer to Section 2.5, Materials, for a description of the CDB materials. A listing of the CDB Base Materials can be found in \CDB\Metadata\Materials.xml. Refer to section 5.1.5 Base Material Table for a description of the materials definition file.

This file contains the default values for each of the CDB datasets. Refer to Chapter 5, CDB Datasets, for a description of the CDB datasets. Annex S of Volume 2”OGC CDB Core: Model and Physical Structure: Informative Annexes” lists the various default values as documented throughout this standard. Defaults values found in Annex S shall be used if the “Defaults.xml” file is not found in the metadata directory. Refer to section 5.1.6 Default Values Definition Metadata for a description of the defaults definition file.

This metadata file is mandatory and identifies the content of one CDB Version. The concept is described in section 3.2.1, CDB Version. The content of the file is defined in section 5.1.8, Version Metadata. See Requirement 38.

This file is used to describe all the CDB attributes that are supported by the CDB standard. A complete listing and description of CDB attributes is provided in section 5.7.1.3, CDB Attributes of this standard. The file is described in section 5.1.9 CDB Attributes Metadata.

This optional file is used to describe all Geomatics attributes that may be referenced by this CDB (refer to section 5.7.1.2.6.2, Geomatics Attributes for a description of Geomatics attributes). Note that the usage of Geomatics attribution falls outside of the jurisdiction of the CDB standard. Nonetheless, the CDB standard provides a standardized mechanism to allow users to fully describe each of the Geomatics attributes they wish to insert within the CDB repository structure. The file is described in Section 5.1.10 (this volume), Geomatics Attributes Metadata. The schema that governs the contents of the attribute metadata files is Vector_Attributes.xsd. Refer to Section 1.4.2 of this document for a description of this schema.

This optional file is used to describe all Vendor attributes that may be referenced by this CDB (refer to section 5.7.1.2.6.3, Vendor Attributes for a description of Vendor attributes). Note that the usage of Vendor attribution falls outside of the jurisdiction of the CDB standard. Nonetheless, the CDB standard provides a standardized mechanism to allow users to fully describe each of the Vendor attributes they wish to insert within the CDB repository structure. The file is described in Section 5.1.11 (this volume), Vendor Attributes Metadata. The schema that governs the contents of the attribute metadata files is Vector_Attributes.xsd. Refer to Section 1.4.2 of this document for a description of this schema.

These files are limited to “Lights_xxx.xml” Definitions Metadata files and offer a complementary approach to modifying the appearance of lights for specific client-devices. The “xxx” suffix is a 32-character string placeholder that stands for the client-device name. There can only be one such file per client-device and the files for each client-device are optional. Refer to section 5.1.3.1, Client Specific Lights Definition Metadata for a description of the client specific lights definition file.

This file provides the means of defining CDB Configurations. The concept is defined in section 3.2.4, CDB Configuration; the content of the file is defined in section 5.1.13, Configuration Metadata.

A CDB Extension is a special CDB Version that is making use of the extension mechanism defined by this Standard to supplement the CDB with user-defined data. The actual way user-defined data is formatted and stored in a CDB Extension falls outside the realm of the Standard and is completely left to the user. The following UML diagram defines the CDB Extension concept.

Figure 3-3. UML Diagram of CDB Extension Concept

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). A client application checks the name attribute to recognize and process known CDB Extensions; unrecognized CDB Extensions are skipped.

To illustrate the rule, assume that CDB Version 2 from Figure 3-2 above is in fact a CDB Extension whose name is not recognized by the client application; then the client must skip CDB Version 2 and continue its processing with CDB Version 1.

The CDB File Replacement Mechanism works at the file level, as the name implies. For this reason, in the case of a geospecific 3D model (GSModel) datasets whose files are stored as ZIP files, the replacement is done at the ZIP level; i.e., the content of the current version of the ZIP file completely replaces the previous version.

The File Replacement Mechanism does not apply to the content of the Metadata directory because the files in a CDB Version must be generated, interpreted and processed with their own metadata. Stated otherwise, the Metadata of a CDB Version belongs solely to the files residing inside that CDB Version. When generating a CDB Version, the content generation tool must also generate the Metadata that will permit a client device to consume and interpret its content. Consequently, when a client device consumes data from a particular CDB Version, the client application should retrieve and use the Metadata of that CDB Version to correctly interpret the data obtained from it.

The CDB standard has an important Feature Data Dictionary (FDD) whose origins are traceable to the DIGEST v2.1 Specification. However, the current FDD is a consolidation of the DIGEST, DGIWG ^[28], SEDRIS ^[29], and UHRB ^[30] dictionaries. The CDB FDD makes use of feature codes ^[31] (FC) to classify features. To provide an even better classification of features, the CDB standard defines an additional attribute called the feature sub-code (FSC). By extending the feature code hierarchy structure in this manner, it is possible to define a broader set of model types. The sub-code value and its significance depend on the primary feature code. Refer to /CDB/Metadata/Feature_Data_Dictionary.xml for the complete list of feature codes and subcodes.

Sections 5.7.1.3.24 and 5.7.1.3.25 respectively provide additional information on feature attributes.

One of the uses of feature codes is to create a hierarchy of subdirectories by taking advantage of the manner in which a Feature Data Dictionary is built. In CDB, a feature code is a 5-character code where the first character represents a category of features, the second represents a subcategory of the current category, and the last three characters represent a specific type in the subcategory. The CDB standard uses these three parts to compose the following hierarchy of folders:

\A_Category\B_Subcategory\999_Type\

Where A is the first character of the feature code, Category is the category name, B is the second character of the feature code, Subcategory is the subcategory name, 999 are the 3^rd, 4^th, and 5^th characters of the feature code, and Type feature type as per /CDB/Metadata/Feature_Data_Dictionary.xml.

Feature codes provide a means for encoding real-world entities or objects and concepts, including those which are not necessarily visible or have a tangible physical form (e.g., airspace). Featuture codes allow a standardized way to describe the world in terms of features, attributes and attribute values. Feature codes do not specify the delineation or geometry of features. Attributes are the properties or characteristics associated with features. A standardized dictionary is required to support encoding in order to maximize interoperability and to understand the production, exchange, distribution, and exploitation of digital geographic data.

Feature codes are defined and stored in a dictionary of features, attributes and attribute values organized in a standardized coding system ^[32]. Feature codes have not been developed to satisfy the requirements of any single application, product, or data store. Feature codes are intended to be independent from level of resolution (scale), representation, or portrayal. The appropriate selection of features codes and attributes are intended to be implemented as part of the overall solution for an application, by means of a database (supported by a data schema or model), a product, or dataset (defined according to a format specification and a data model).

Users of feature codes are advised that, as with any dictionary, there may be more than one way to encode geographic entities, either by offering a choice of features or a combination of features and attributes. A heliport is listed as feature GB035 (Heliport), but could also be encoded as feature code GB006 (Airfield) associated with the attribute APT (Airfield type) containing a coded value of 009 (Heliport). Another example would be AK090 (Fairgrounds) and AK091 (Exhibition Grounds), which could be interchanged depending on the user’s own interpretation.

When a feature is represented by a 3D model, the model itself is given a name that is used to better describe or differentiate two features having the same feature and FSC codes. Even though the model name is left to the discretion of the modeler, the CDB standard recommends the use of the feature code based name as the model name. See the /CDB/Metadata/Feature_Data_Dictionary.xml for the complete list of feature codes. In the case of Moving Models, the model name is the human-readable version of its DIS Entity Type.

The model name corresponds to the MODL attribute defined in section 5.7.1.3.41.

CDB Moving Models make use of the DIS standard (see reference [7]) to create the directory structures where MModel datasets are stored. The DIS standard uses a structure called the DIS Entity Type to identify a “moving model”; this structure is made of seven fields named:

The first four fields (kind, domain, country and category) are used to create four subdirectories in the moving model datasets hierarchy. Each of the directory names is composed of the field’s value (1 to 3 digits), followed by an underscore “_”, and concatenated with the field’s name as per Annex M (Volume 2 CDB Core: Model and Physical Structure Annexes).

Another directory name is created by concatenating all fields with the underscore character. This character string also forms the Moving Model DIS Code (MMDC) attribute later defined in section 5.7.1.3.40.

Together, these five directories classify CDB Moving Models into a DIS-like structure that looks like this:

.\1_Kind\2_Domain\3_Country\4_Category\1_2_3_4_5_6_7\

The above directory structure is used, for instance, by the MModelGeometry dataset later defined in section 3.5.1.

Examples of valid texture names are Brick, M1A2, house, City_Hall, etc. A name such as C-130 is invalid because the second character (“-“) is not alphanumeric.

The directory represented by \A corresponds to the first character of TNAM in uppercase. The second directory, \B, corresponds to the second character of TNAM in uppercase. As a result, a texture named “house” will be stored in a directory tree with the following structure:

\H\O\house\

The terms “Level of Detail” and its acronym “LOD” are generally well known to the intended audience of this standard.

This standard specifies a numeric scale to classify a LOD between 34 levels numbered from −10 to +23. The details will be provided later in the document. At this point, it is sufficient to define the convention used throughout the standard to designate a particular LOD.

The standard designates a LOD by appending its level to the uppercase letter L. When the level is negative, the uppercase letter C is used in lieu of the minus sign. The numeric values of all levels are represented by 2-digit numbers. As a result, LODs are designated as LC10 for level −10, L00 for level 0, or L23 for level 23.

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-3: GTModelGeometry Entry File Naming Convention

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-4: GTModelGeometry Level of Detail Naming Convention

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-5: GTModelDescriptor Naming Convention

The following example illustrates the directory structure that would store the entry file of all geotypical buildings with a feature code of AL015:

\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature\015_Building\

Where \CDB\GTModel is the root of all geotypical model datasets, \500_GTModelGeometry is the directory containing all feature code categories, \A_Culture is the directory containing all feature code subcategories of category A (named Culture), \L_Misc_Feature is the directory containing all feature types of category A and subcategory L (named Misc_Feature), \015_Building is the directory containing all OpenFlight files representing geotypical buildings whose feature types are 015 (named Building).

Assuming the use of OpenFlight, examples of files found in the above directory are:

.\D500_S001_T001_AL015_004_Castle.flt

.\D500_S001_T001_AL015_015_School.flt

.\D500_S001_T001_AL015_021_Garage.flt

.\D500_S001_T001_AL015_037_Fire_Station.flt

.\D500_S001_T001_AL015_050_Church.flt

Note that all filenames start with a common portion (D500_S001_T001_AL015) and that only their FSC and MODL portions vary.

If the castle above (AL015_004_Castle) is represented with 3 levels of details, say LOD 3, 5 and 8, they would be stored in .\L03\, .\L05\, and .\L08\ giving file names such as these:

.\L03\D510_S001_T001_L03_AL015_004_Castle.flt

.\L05\D510_S001_T001_L05_AL015_004_Castle.flt

.\L08\D510_S001_T001_L08_AL015_004_Castle.flt

Again, the descriptor associated with the same castle (AL015_004_Castle) would be found in this file:

.\D503_S001_T001_AL015_004_Castle.xml

The following table defines each field of the file name and Table 5-8 provides the values of the Component Selectors to complete the name.

Table 3-7: GTModelTexture Naming Convention

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-8: GTModelMaterial Naming Convention

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-9: GTModelMaterial Naming Convention

The following example illustrates the directory structure that would store all files associated with a texture named ‘Brick’:

\CDB\GTModel\501_GTModelTexture\B\R\Brick\

Where \CDB\GTModel is the root of all geotypical model datasets, \501_GTModelTexture is the directory containing all geotypical textures, \B is the directory containing all textures whose name start with the letter ‘B’ or ‘b’, \R is the directory containing all textures whose name have the letter ‘R’ or ‘r’ in the second position, and \Brick is the directory containing all texture-related files whose name is ‘Brick’. Note that the second letter of the texture name is a lowercase ‘r’ but the corresponding directory name is an uppercase ‘R.’

If the Brick texture has a resolution of 1 cm and a dimension of 256 x 256 pixels, Table 3-1 tells us that the finest LOD will be 10 (TS = 0.01 m) and the coarsest will be 2 (TS = 2.56 m), and assuming SGI rgb based textures, and the following files would be found in the above directory:

.\D511_S001_T001_L02_Brick.rgb

.\D511_S001_T001_L03_Brick.rgb

.\D511_S001_T001_L04_Brick.rgb

.\D511_S001_T001_L05_Brick.rgb

.\D511_S001_T001_L06_Brick.rgb

.\D511_S001_T001_L07_Brick.rgb

.\D511_S001_T001_L08_Brick.rgb

.\D511_S001_T001_L09_Brick.rgb

.\D511_S001_T001_L10_Brick.rgb

The metadata (if provided) associated with the above material textures would reside in the same directory and be named:

.\D511_S001_T001_Church-Gothic_mtd.xml

The following example illustrates the directory structure that would store all LODs of a material texture whose name is Church-Gothic:

\CDB\GTModel\501_GTModelTexture\C\U\Church-Gothic\

Again, note that the second letter of the material texture name is a lowercase ‘u’ but the corresponding directory name is an uppercase ‘U.’

If the material texture has a resolution of 15 cm and a dimension of 256 x 256 pixels, the finest LOD will be 6 and the coarsest will be −2, and assuming images as TIFF files, the following files would be found in the above directory:

The composite material table associated with the above material textures would reside in the same directory and be named:

The metadata (if provided) associated with the above material textures would reside in the same directory and be named:

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-11: GTModelInteriorGeometry Naming Convention

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-12: GTModelInteriorDescriptor Naming Convention

The following example illustrates the directory structure that would store the interior of all geotypical buildings represented at LOD 3 and whose feature code is AL015:

\CDB\GTModel\506_GTModelInteriorGeometry\A_Culture\
L_Misc_Feature\015_Building\L03\

Where \CDB\GTModel is the root of all geotypical model datasets, \505_GTModelInteriorGeometry is the directory containing all feature categories, \A_Culture is the directory containing all feature subcategories of category A (named Culture), \L_Misc_Feature is the directory containing all feature types of category A and subcategory L (named Misc_Feature), \015_Building is the directory containing all level of details representing geotypical buildings whose feature types are 015 (named Building), and \L03 is the directory containing the model files ^[35] representing LOD 3 of these buildings.

Assuming the use of OpenFlight, examples of files found in the above directory are:

Note that all filenames start with a common portion (D506_S001_T001_L03_AL015) and that only their FSC and MODL portions vary.

The descriptors associated with the interior of these models would be found in level 4 of the directory structure in the following files:

\CDB\GTModel\506_GTModelInteriorGeometry\A_Culture\
L_Misc_Feature\015_Building\
.\D508_S001_T001_AL015_004_Castle.xml
.\D508_S001_T001_AL015_015_School.xml
.\D508_S001_T001_AL015_021_Garage.xml
.\D508_S001_T001_AL015_037_Fire_Station.xml
.\D508_S001_T001_AL015_050_Church.xml

If there is also additional metadata for the interior of these models, they would also be found in level 4 of the directory structure in the following files:

\CDB\GTModel\506_GTModelInteriorGeometry\A_Culture\
L_Misc_Feature\015_Building\
.\D508_S001_T001_AL015_004_Castle_mtd.xml
.\D508_S001_T001_AL015_015_School_mtd.xml
.\D508_S001_T001_AL015_021_Garage_mts.xml
.\D508_S001_T001_AL015_037_Fire_Station_mtd.xml
.\D508_S001_T001_AL015_050_Church_mtd.xml

Note that any one of the models may have additional metadata or all may have additional metadata.

The following table defines each field of the file name and Table 5-8 provides the values of the Component Selectors to complete the name.

Table 3-14: GTModelInteriorTexture Naming Convention

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-15: GTModelInteriorMaterial Naming Convention

The following example illustrates the directory structure that would store all LODs of a texture whose name is BeigeGypseWall:

\CDB\GTModel\507_GTModelInteriorTexture\B\E\BeigeGypseWall\

Where \CDB\GTModel is the root of all geotypical model datasets, \507_GTModelInteriorTexture is the directory containing all geotypical interior textures, \B is the directory containing all textures whose name start with the letter B, \R is the directory containing all textures whose name start the letter ‘B’ followed by the letter ‘E’, and \BeigeGypseWall is the directory containing all LODs of the texture representing a beige gypse wall. Note that the second letter of the texture name is a lowercase ‘e’ but the corresponding directory name is an uppercase ‘E.’

If the texture has a resolution of 1 cm and a dimension of 256 x 256 pixels, the finest LOD will be 10 and the coarsest will be 2, and the SGI RGB image file format is used, the following files would be found in the above directory:

The following example illustrates the directory structure that would store all LODs of a material texture associated with the interior of a gothic church and whose name is Church-Gothic:

\CDB\GTModel\507_GTModelInteriorTexture\C\H\Church-Gothic\

Where \CDB\GTModel is the root of all geotypical model datasets, \507_GTModelInteriorTexture is the directory containing all geotypical interior material textures, \C is the directory containing all textures whose name start with the letter C, \H is the directory containing all textures whose name start the letter ‘C’ followed by the letter ‘H’, and \Church-Gothic is the directory containing all LODs of the material texture called Church-Gothic. Note that the second letter of the material texture name is a lowercase ‘h’ but the corresponding directory name is an uppercase ‘H.’

If the material texture has a resolution of 1 cm and a dimension of 256 x 256 pixels, the finest LOD will be 10 and the coarsest will be 2, and the following files would be found in the above directory:

D509_Snnn_Tnnn_L02_Church-Gothic.tif

D509_Snnn_Tnnn_L03_Church-Gothic.tif

D509_Snnn_Tnnn_L04_Church-Gothic.tif

D509_Snnn_Tnnn_L05_Church-Gothic.tif

D509_Snnn_Tnnn_L06_Church-Gothic.tif

D509_Snnn_Tnnn_L07_Church-Gothic.tif

D509_Snnn_Tnnn_L08_Church-Gothic.tif

D509_Snnn_Tnnn_L09_Church-Gothic.tif

D509_Snnn_Tnnn_L10_Church-Gothic.tif

The metadata (if provided) associated with the above material textures would reside in the same directory and be named:

.\D509_Snnn_Tnnn_Church-Gothic_mtd.xml

The following table defines each field of the file name and Table 5-9 provides the values of the Component Selectors to complete the name.

Table 3-17: GTModelSignature Naming Convention

The following example illustrates the directory structure that would store the signature of all geotypical buildings represented at LOD 3 and whose feature code is AL015:

\CDB\GTModel\502_GTModelSignature\A_Culture\L_Misc_Feature\015_Building\L03\

Where \CDB\GTModel is the root of all geotypical model datasets, \502_GTModelSignature is the directory containing all feature categories, \A_Culture is the directory containing all feature subcategories of category A (named Culture), \L_Misc_Feature is the directory containing all feature types of category A and subcategory L (named Misc_Feature), \015_Building is the directory containing all level of details representing the signature of geotypical buildings whose feature types are 015 (named Building), and \L03 is the directory containing the vector data sets representing LOD 3 of these buildings ^[36].

Examples of files that could be found in the above directory are:

If there is metadata for this file and the metadata is encoded in XML, the above directory would also include:

The following table defines each field of the file names and Table 5-10 provides the values of the Component Selectors to complete the name.

Table 3-19: MModelGeometry Naming Convention

The following table defines each field of the file names and Table 5-10 provides the values of the Component Selectors to complete the name.

Table 3-20: MModelDescriptor Naming Convention

The following example illustrates the directory structure that would store the M1A2 SEP version of the M1 Abrams tank.

\CDB\MModel\600_MModelGeometry\1_Platform\1_Land\225_United_States\1_Tank\1_1_225_1_1_8_0\

Where \CDB\MModel is the root of all moving model datasets, \600_MModelGeometry is the directory containing the geometry and descriptor of all moving models, \1_Platform is the directory containing all DIS Entity of Kind 1 (named Platform), \1_Land is the directory containing all DIS platforms of Domain 1 (named Land), \225_United_States is the directory containing all DIS land platforms of Country 225 (called United_States), \1_Tank is the directory containing all DIS land platforms of Category 1 (named Tank), and \1_1_225_1_1_8_0 is the directory containing all geometry and descriptor files of the M1A2 SEP Abrams tank.

Examples of files found in the above directory are:

The following table defines each field of the file names and Table 5-8 provides the values of the Component Selectors to complete the name.

Table 3-22: MModelTexture Naming Convention

The following table defines each field of the file names and Table 5-10 provides the values of the Component Selectors to complete the name.

Table 3-23: MModelMaterial Naming Convention

The following table defines each field of the file names and Table 5-10 provides the values of the Component Selectors to complete the name.

Table 3-24: MModelMaterial Naming Convention

Assuming that the textures, materials, and CMT of the M1A2 SEP are called M1A2_SEP, the following directory structure would store them.

\CDB\MModel\601_MModelTexture\M\1\M1A2_SEP\

Where \CDB\MModel is the root of all moving model datasets, \601_MModelTexture is the directory containing the textures, material textures, and CMTs of all moving models, \M is the directory containing all files whose TNAM field starts with the letter ‘m’ or ‘M’, \1 is the directory containing all files whose TNAM field starts with ‘m1’ or ‘M1’, and \M1A2_SEP is the directory containing all texture-related files whose TNAM is M1A2_SEP.

Examples of files found in the above directory are:

The following table defines each field of the file names and Table 5-10 provides the values of the Component Selectors to complete the name.

Table 3-26: MModelSignature Naming Convention

The following example illustrates the directory structure that would store LOD 4 of the RCS Signature of the M1A2 SEP Abrams tank.

\CDB\MModel\606_MModelSignature\1_Platform\1_Land\225_United_States\1_Tank\1_1_225_1_1_8_0\L04

Where \CDB\MModel is the root of all moving model datasets, \606_MModelGeometry is the directory containing the RCS signature of all moving models, \1_Platform is the directory containing all DIS Entity of Kind 1 (named Platform), \1_Land is the directory containing all DIS platforms of Domain 1 (named Land), \225_United_States is the directory containing all DIS land platforms of Country 225 (called United_States), \1_Tank is the directory containing all DIS land platforms of Category 1 (named Tank), \1_1_225_1_1_8_0 is the directory containing all levels of detail of the RCS signature of the M1A2 SEP Abrams tank, and \L04 is the directory containing the files representing LOD 4 of RCS signature of the tank.

For ShapeFiles an example of files found in the above directory are:

__ D606_Snnn_Tnnn_L04_1_1_225_1_1_8_0.shp

D606_Snnn_Tnnn_L04_1_1_225_1_1_8_0.shx

D606_Snnn_Tnnn_L04_1_1_225_1_1_8_0.dbf

D606_Snnn_Tnnn_L04_1_1_225_1_1_8_0.dbt __

Data elements within a tile are organized into a regular grid where data elements are evenly positioned at every XUnit_LOD and YUnit_LOD as described in Section 2.1.2, Tile Levels-of-Detail (Tile-LODs). This type of organization is referred to as a Raster Dataset. Raster Datasets always have a fixed number of elements corresponding to the number of units shown in Table 2-4: CDB LOD versus Tile and Grid Size. An example of a raster dataset is terrain imagery.

Note: Partially-filled Tile-LODs are not permitted in a compliant the CDB data store. In the case where data at the Tile-LOD’s resolution does not fully cover the Tile-LOD’s geographic footprint, the modeler (or the tools) should fill the remainder area of the Tile-LOD with the “best available” data. There are two cases to consider:

Case I: In the case where coarser LODm data exists for the remainder area of the Tile- LODn, the LODm data should be interpolated to LODn.

Case II: In the case where coarser LODm does not exist for the remainder area of the Tile-LODn, then the remainder area of Tile-LODn should be filled with the default value for this dataset.

The point features, the lineal features, and the polygon features of the CDB are organized into several Vector Datasets and into levels of details.

The level-of-detail organization of the Vector Datasets mimics the concept of map scaling commonly found in cartography (for example a 1:50,000 map). If we pursue the analogy with cartography, increasing the LOD number (increasingly finer detail) of a dataset is equivalent to decreasing the map’s scaling (1:n map scaling where n is decreasing). As is the case with cartography, the Tile-LOD number provides a clear indication of both the positional accuracy and of the density of features. Consequently, the CDB specifies an average value for the density of features for each LOD of the Vector Dataset hierarchy. Table 3-27 below defines these values. For each CDB LOD, the table provides the maximum number of points allowed per Tile-LOD and the resulting average Feature Density.

Table 3-27: CDB LOD versus Feature Density

The last type of tiled datasets is used to store 2D and 3D Models and will be later described in their own sections.

This section provides the algorithm to determine the name of the directory at level 1 of the Tiles hierarchy.

The CDB standard specifies DlatCell to be 1 degree anywhere on earth, which gives 180 earth slices (NbSliceID = 180) and a SliceID ranging from 0 to 179. Note that the latitude range of the CDB standard Earth Model Tiled Datasets is –90 ≤ lat < 90; Refer to Section 2.1.3, Handling of the North and South Pole for the handling of the latitude of +90.

Note that the directory name corresponds to the latitude of the southwest corner of the CDB Geocell. Moreover, future releases of the CDB Specification shall retain the same value of DlatCell. Note that a modification of the value of DlatCell would entail substantial changes to the resulting CDB directory and file naming thus requiring a re-compilation of existing CDBs.

This section provides the algorithm to determine the name of the directory at level 2 of the Tiles hierarchy.

Note that SliceIDIndex and NbSliceIDIndex are a function of both latitude and longitude; however, NbSliceIDIndexEq is the number of SliceIDIndex at the equator. First, the longitude size of the CDB Geocell (DLonCell) is determined:

where…

DLonCellBasic is the width of a CDB Geocell in degrees at the equator

DLonZone(lat) is the number of DLonCellBasic in a given zone as per Table 3-29: NbSliceIDIndex for every CDB Zones. DLonZone(lat) is a function of the latitude.

The CDB standard sets DLonCellBasic to 1 degree, which gives 360 CDB Geocells (NbSliceIDIndexEq=360) at the equator. Table 3-29: NbSliceIDIndex for every CDB Zones, provides the values for NbSliceIDIndex at given latitudes. SliceIDIndex ranges from 0 to NbSliceIDIndexEq-1 at all latitudes. Note that the longitude range of the CDB Earth Model Tiled Datasets is –180 ≤ lon < 180 which implies that an application needs to convert a longitude of 180 to –180 before computing SliceIDIndex.

Since DLonCellBasic is set to 1 degree, the index SliceIDIndex will increment by DLonZone(lat); therefore, the directory name corresponds to the longitude of the southwest corner of the CDB Geocell. Moreover, future release of the CDB standard should retain the same value of DLonCellBasic. Doing otherwise will cause substantial modifications to the repository file naming convention and tile content thus requiring a conversion of the CDB instance.

Figure 3-8. Allocation of CDB Geocells with Increasing Latitude

Table 3-29: NbSliceIDIndex for every CDB Zones

The name of the directory at level 3 is composed of the dataset code and dataset name. The complete list is provided in Annex Q of the OGC CDB Core: Model and Physical Structure: Informative Annexes. Examples are provided below.

This directory level contains all of the Level of Details directories supported by the corresponding datasets.

All coarse LOD tiles, ranging from LOD –10 to LOD –1, are stored in a single directory uniquely named \LC. The remaining finer LODs (i.e., LOD 0 to LOD 23) have their own corresponding directories, named \Lxx where xx is the 2-digit LOD number.

The UREF directory level subdivides a geocell into a number of rows to limit the number of entries in a directory.

The number of files at a given LOD is proportional to 2^2×LOD. For instance, LOD 10 represents about one million files. The introduction of the UREF directory level reduces the number of files per directory to the order of 2^LOD.

The name of the directory is composed of the character U (Up direction) followed by the Up index (or the row number) of the tile, as described in this section.

The number of rows in a CDB Geocell at a given LOD is given by the following equation:

…which simplifies to:

The index of a row ranges from 0 for the bottom row to U_NRowLod−1 for the upper row. For any given latitude lat, its Up Index U_Ref is determined by first computing DLat:

…which simplifies to the following for computer language that support modulo:

Then the index of the UREF can be evaluated as follows:

Knowing that the value of DLatCell is 1° for the whole CDB, the resulting formulas become:

The following table defines each field of the file name and chapter 5, CDB Datasets, provides the dataset codes and the component selectors to complete the name.

Table 3-30: Tiled Dataset File Naming Convention 1

The RREF token divides a particular level of details into columns of tiles. The number of columns in a CDB Geocell at a given LOD is given by the following equation:

…which simplifies to:

The index of a column ranges from 0 for the leftmost column to R_NColLod−1 for the rightmost column. For any given lat/lon coordinate, its Right Index R_Ref is determined by first computing DLon:

…which simplifies to the following for computer language that support modulo:

Then the Right Index R_Ref can be evaluated as follows:

By substituing DLonCell that is defined in section 3.6.2.2, Directory Level 2 (Longitude Directory), we obtain the following set of equations:

The value of DLonZone is provided by Table 3-29: NbSliceIDIndex for every CDB Zones.

The following GSModel datasets reside inside ZIP archives.