Publication Date: 2018-01-11

Approval Date: 2017-12-07

Posted Date: 2017-11-15

Reference number of this document: OGC 17-042

Reference URL for this document:

Category: Public Engineering Report

Editor: Sara Saeedi, other participants of the CDB thread

Title: OGC Testbed-13: CDB Engineering Report

OGC Engineering Report


Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit


This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.


Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Summary

The Open Geospatial Consortium (OGC) CDB Standard is an international standard that describes rules, requirements, and best practices for structuring, modeling, and storing geospatial information required in high performance modeling and simulation (M&S) applications. Previously called the Common Data Base Specification the OGC members voted to officially change the name to “CDB” in the OGC community and standard [4]. OGC CDB 1.0 defines the core conceptual models, use cases, requirements, and specifications for employing geospatial data in 3D M&S. A persistent and important concern about the OGC CDB is how to evolve beyond the current use of CDB feature codes and incorporate the more recent NSG (National System for Geospatial-Intelligence) Application Schema (NAS) and DGIWG (Digital Geographic Information Working Group) Feature and Attribute encoding. The CDB Standard Working Group (SWG) has started examining the feature codes and attribution schema as used in the CDB standard. This effort was expanded in Testbed 13 to develop CDB profiles for supporting interoperability of existing CDB with the NAS-based feature codes and schemas by investigating how a specific profile, e.g. "Urban Military NAS Profile" can be developed and used in CDB. For this purpose, a mapping between CDB and NAS feature codes and schemas is expressed. This mapping has been applied by OGC Web Services such as Web Feature Service (WFS) to publish a CDB feature with attributes and schemas from the NAS profile.

This Engineering Report (ER) summarizes the CDB sub-thread work in Testbed 13. The document is structured in three phases and includes a feasibility study; the implementation of data models and schemas mapping that are based on the feasibility study results; and a set of OGC web services that implement the CDB in the form of WFS and WCS (Web Coverage Service) instances.

This Engineering Report describes:

  • The conceptual model of an OGC CDB 1.0 datastore as a UML (Unified Modeling Language) diagram to show different datasets (the 3D models, vector features and coverages) structure;

  • How to process and use a NAS-based Profile as a CDB feature/attribute data model or a GML-SF0 application schema;

  • How to access, navigate and visualize a CDB dataset using OGC web services (such as WFS and WCS).

This work provides insights into:

  • The in-depth study of the OGC CDB 1.0 feature data dictionary and attribution schema;

  • The requirements and constraints for extending the CDB feature data dictionary (FDD) and attribute schemas;

  • The development and prototyping of the WFS and WCS access to the CDB datastore for a NAS based urban military scenario.

1.1. Requirements

This Engineering Report addresses the following requirements:

  • A NAS-based profile UML model to configure the feature data in a CDB dataset;

  • Creation of the CDB configuration mapping files consistent with a NAS profile UML model;

  • Implementation of a CDB dataset with all the requirements of a NAS-based Urban Military profile.

1.2. Key Findings and Prior-After Comparison

The work and experiments completed in the OGC Testbed 13 CDB sub-thread are described in this CDB ER document. This ER was reported to the CDB SWG on several occasions and the current key findings of the CDB sub-thread are summarized here:

  • Feasibility study for extending OGC CDB 1.0 feature codes and attributes reveals that the current version (1.0) supports only a limited extension:

    • The feature type codes which exist in the FDD.xml files are a fixed set, and the extension needs hard coding of the newly added codes;

    • CDB has an indexing structure (based on Feature and Attribute Coding Catalogue (FACC) codes) to save feature types inside the folder hierarchy. This indexing is also a limitation for defining the feature codes. If an arbitrary alphabetical feature code is used inside the CDB, then the indexing mechanism will be broken. Another approach is to define a mapping between the new alphabetical feature codes and old indexing;

    • The attributes schema is defined for the tiled vector datasets inside the Shapefile database file. However, the attribute schema can be extended in the current version of the CDB using extended attributes.

  • The OGC CDB 1.0 can be accessed by OGC web services that support a NAS profile in organizing features and attributes and indexing vector features.

  • Change Request proposals have been discussed for the OGC CDB 2.0 and will be submitted by December 31, 2017.

    • The recommendations for replacing FACC feature code and indexing structure to be consistent with the application schemas (e.g. NAS data model) under discussion for the OGC CDB 2.0;

    • The recommendations for supporting application schemas in CDB (level of complexity: Esri Geodatabase, GML-SF0 application schema) are being discussed for the OGC CDB 2.0;

    • The method to expand the supported encodings and formats for an OGC CDB compliant datastore;

    • Generating a coherent attribute schema for CDB 1.0 based on the "CDB_Attribute.xml" file.

1.3. What Does This ER Mean for the Working Group and OGC in General

This ER is mainly of interest to the CDB SWG and the CDB implementation community. In particular, any Change Request Proposals created as a result of the work will be discussed in the SWG. The work documented in this ER is important for CDB SWG as it applies to the CDB 1.0 standard, expands its feature codes/attribution schema using NAS profile, and accesses the CDB data store using OGC web services. Due to the strong link to 3D information streaming and NGA’s NSG application schema, the work is also expected to be of interest to other OGC Domain Working Groups (DWG) such as the 3D Information Management (3DIM) DWG, Defense & Intelligence DWG, Distributed Simulation and Gaming DWG, OGC Web Services and profiling.

1.4. Document Contributor Contact Points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name Organization

Sara Saeedi (editor and Contributor)

University of Calgary

Steve Liang (Contributor)

University of Calgary

Robin Houtmeyers (Contributor)

Luciad Inc.

James Badger (Contributor)

University of Calgary

1.5. Future Work

The following future work items are envisioned:

  1. A performance analysis and evaluation for using CDB extended with the NAS profile in run-time simulation;

  2. Describe explicitly how the CDB model may or may not align with the rest of the OGC baseline, including standards such as Sensor Observation Service (SOS) and the Discrete Global Grid Systems (DGGS) standard;

  3. Extend the supported encodings and formats for a CDB database to include the use of the OGC GeoPackage, CityGML, LandInfra and IndoorGML standards as well as other broadly used community encoding standards, such as COLLADA. This work may require performing OGC interoperability experiments to understand the implications of these options better.

  4. Consider replacement(s) for the feature data dictionary with application schemas (e.g., NAS) that describe the features, attributes, associations and relationships of a different domain of application.

1.6. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

3. Terms and definitions

For the purposes of this report, the definitions specified in the OGC® CDB Core Standard: CDB Terms and Definitions (OGC 15-112r2) shall apply. In addition, the following terms and definitions apply.

3.1. Application Schema

An application level conceptual schema for data required by one or more applications. It includes feature type and model (code, attributes, units, etc.) along with any constraints important for the integrity of the data.

3.2. Client

The software component that can invoke an operation from a service.

3.3. Feature

A fundamental unit of spatial data that represents a physical entity, e.g. a building, a river, or a person. A feature may or may not have geometric aspects.

3.4. Feature Data Dictionary

A Feature data dictionary is a collection of descriptions of the Feature objects or items in a Feature data model for the benefit of programmers and others who need to refer to them.

3.5. GeoServer

An open source map server for sharing geospatial data designed for interoperability.

3.6. GSModel

A Geospecific model is instanced once and only once within a CDB. Geospecific models usually correspond to unique (in either shape, size, texture, materials or attribution), man-made, real world 3D features.

3.7. GTModel

A Geotypical model is instanced multiple times within a CDB data store. Geotypical models correspond to representative (in shape, size, texture, materials and attribution) models of real-world manmade or natural 3D features.

3.8. Interface

The named set of operations that characterize the behaviour of a service.

3.9. OpenFlight

OpenFlight (or .flt) is a 3D geometry model file format designed as a non-proprietary
format for use by real-time 3D visual simulation image generators.

3.10. Service

The distinct part of the functionality that is provided by an entity through interfaces.

3.11. QGIS

A Free and Open Source Geographic Information System[QGIS Website]

4. Abbreviated terms

  • 3D Three Dimensional

  • 3DIM 3D Information Management

  • API Application Program Interface

  • EA Enterprise Architect (UML modeling tool from Sparx Systems)

  • ER Engineering Report

  • Esri Environmental Systems Research Institute

  • ETag Entity tag

  • CDB Common Database (OGC standard)

  • CEAI CDB Extended Attribute Index

  • COLLADA COLLAborative Design Activity

  • COTS Commercial Off The Shelf

  • CRS Coordinate Reference System

  • DFDD DGIWG Feature Data Dictionary

  • DGIWG Defense Geographic Information Working Group

  • DIGEST The Digital Geographic Information Exchange Standard

  • DIS Distributed Interactive Simulations [IEEE Std 1278TM]

  • DWG Domain Working Group

  • EAC Environment Attribute Code

  • EAV Environment Attribute Value

  • FACC Feature and Attribute Coding Catalogue

  • FDD Feature Data Dictionary

  • FSC Feature Sub-Code

  • GEAI Geomatics Extended Attribute Index

  • glTF graphics library Transmission Format

  • GML Geography Markup Language (OGC/ISO standard)

  • GML-SF GML Simple Features Profile (OGC standard)

  • GML-SF0 GML Simple Features Profile, Level 0

  • GPU Graphics Processing Unit

  • HLA High-Level Architecture Standard [IEEE Std 1516TM]

  • HTML Hypertext Markup Language

  • HTTP Hypertext Transfer Protocol

  • ISO International Standardisation Organisation

  • JPEG Joint Photographic Experts Group

  • KVP Key-Value Pair

  • LoD Level of Detail

  • LZW Lempel–Ziv–Welch method for image compression

  • M&S Modeling and Simulation

  • MModel Moving 3D models

  • NAS NSG Application Schema

  • NetCDF Network Common Data Form

  • NGA National Geospatial-Intelligence Agency

  • NSG National System for Geospatial-Intelligence

  • NYC New York City

  • OGC Open Geospatial Consortium, Inc.

  • TIE Technology Integration Experiment

  • TIFF Tagged Image File Format.

  • SGI Silicon Graphics Image

  • SWG Standard Working Group

  • UML Unified Modeling Language (OMG standard)

  • URL Uniform Resource Locator

  • VEAI Vendor Extended Attribute Index

  • WebGL Web Graphics Library

  • WCS Web Coverage Service (OGC standard)

  • WFS Web Feature Service (OGC standard)

  • WGS-84 World Geodetic System 1984

  • WMS Web Map Service (OGC standard)

  • WMTS Web Map Tile Service

  • XML Extensible Markup Language (W3C standard)

  • XSD XML Schema Definition

5. Overview

This Engineering Report (ER) discusses the conduct and results of the CDB extended future codes and attribute schemas Feasibility Study, including all lessons learned from the experiments completed during the CDB feature code transformation development and the web services implementation. The purpose of this document is to summarize the project definition, requirements, and evaluate proposed solutions in order to offer the optimum recommendations. The CDB ER will explain the current CDB data model, attribute schema as well as the feasibility of expanding the current schema. The web service and client-server architecture for the WFS, WCS, and conversion client for accessing the CDB data store is presented in the ER. Then, the results of the experiments for online performance are evaluated. Finally, the project recommendations are presented.

5.1. Outline

The following figure (Figure 1) describes the CDB workflow executed in Testbed 13.

ch4 fig1 ERoutline
Figure 1. CDB sub-thread ER Workflow Outline

This document contains the following chapters:

  1. Preface: This section presents information on administrative and legal aspects of this ER.

  2. Summary: This section presents information on scope, what this ER means for the OGC in general and document contributor contact points.

  3. References: This section presents information on documents that are referenced in this ER.

  4. Terms: This section presents information on terms and abbreviations that are used in this ER.

  5. Overview: In this section and overview of the CDB sub-thread work is presented and then, the outline of CDB ER, New York City (NYC) sample dataset, demonstration scenarios and Technology Integration Experiments is discussed.

  6. Background: This ER includes an overview of the OGC CDB version 1.0 which defines a conceptual model and file structure for the storage, access, and modification of a CDB data store.

  7. Feasibility Study: The CDB feature codes and attribution schema are introduced at the first step. Also, the feasibility of extending the CDB feature data dictionary is investigated. Pros and cons and limitations resulting from different approaches are documented in this section.

  8. CDB-NAS profile Mapping: Next, the NAS-based Military Urban Profile is introduced and a mapping between the CDB and NAS is implemented based on the look-up tables. The decision to use a look-up table for transforming feature codes from the OGC CDB to NAS was made for practical reasons, which was to ensure its compatibility with the implementations of OGC CDB 1.0 described in the feasibility study.

  9. CDB WFS: This section presents information on the CDB WFS implementations, architecture and the results conducted. The CDB WFS is used to access and visualize a sample CDB vector and 3D model data store using a NAS profile feature code and attributes.

  10. CDB WCS: This section presents information on the CDB WCS implementations, architecture and the results conducted. The CDB WCS is used to access and visualize the tiled elevation and imagery data of a sample CDB datastore.

  11. CDB Client: This section presents information on the client implementations, architecture and the results conducted.

  12. Findings: This section summarizes the findings. It also provides forward-looking recommendations.

5.2. Sample Dataset

The sample data set used in the CDB sub-thread is the NYC dataset created by FlightSafety International Inc. solely for use by the National Geospatial-Intelligence Agency (NGA) in support of OGC’s Testbed 13 effort. The CDB is physically arranged on disk into the following top level folders:

  • Metadata: This is a directory structure that contains a set of XML metadata files and controlled vocabularies that are global to the CDB.

  • GTModel: This is a directory structure that contains Geotypical Models. Geotypical models are a set of generic models that are defined once in the CDB and are intended to be rendered in multiple places throughout the CDB.

  • Tiles: This is a directory structure that contains the tiled datasets including vector, elevation, imagery and Geospecific model.

The Coordinate Reference System (CRS) of this datastore is WGS 84 (World Geodetic System, 1984). The New York data set contains two CDB Geocells: N40-W74 and N40-W75. The demonstration data store has thirteen tiled data layers: Elevation, MinMaxElevation, MaxCulture, Imagery, GeoSpecificFeatures, GeoTypicalFeatures, VectorMaterial, RoadNetwork, RailRoadNetwork, GeoSpecificModelGeometry, GeoSpecificModelTexture, GeoSpecificModelDescriptorbuildings and Hydro. The CDB sub-thread experiments make use of the Elevation, Imagery, Geotypical, and Geospecific model data layers. Each data layer has its own LoDs (level of Details). A CDB-compliant datastore currently uses ShapeFiles for the representation and attribution of vector feature datasets. Aligned with the capabilities of the ShapeFile format, vector features consist of points, lines and polygon features. The raster data layers such as Elevation and Imagery are in GeoTIFF format. The format of the 3D models, the buildings and trees with geometry & textures, is OpenFlight. OpenFlight is a format widely supported in the modeling and simulation community for dynamic and static 3D models. The texture of those models can be described as .rgb format.

In the NYC CDB data version.xml file, it has been denoted that the dataset is compatible with the CDB 3.2 specification. On the other hand, in the Specification_Version.xml file of the NYC CDB datastore, it was mentioned that the CDB Database Version is 3.0 and released in September 2008. After evaluating most of the datasets inside the CDB it was concluded that this sample data store in Testbed 13 was generated based on CDB 3.0 specifications.

Regardless, there are some enhancements in the OGC CDB 1.0 compared CDB 3.2 specification such as updating the terms and definition to be consistent with the ISO 19xxx (Geomatics) series of standards, specifically ISO 19111 Spatial referencing by Coordinates and ISO 19017 Spatial Schema which is published as the OGC CDB 1.0 Standard, Volume 3: OGC CDB Terms and Definitions. Also, the metadata files and folder updated (e.g., corrections to the Feature Data Dictionary, the addition of a Priority field to the Feature Data Dictionary, additional Base Materials for building interiors, changes to the CDB Attributes, the addition of new airliners and countries codes). Handling of Topological Networks, Model LoDs and significant size and some of the datasets had minor changes as well. The list of these updates can be found in the OGC CDB Wiki page [6]. From the CDB 3.0 to the CDB 3.2 specification, updates are more significant and fully described in the OGC CDB Best Practices documents ([7] and [8]).


The sample NYC CDB datastore version is based on an older version (CDB 3.0) and is different from OGC CDB 1.0. The updates and additions are in the form of new datasets, new feature or model attributes, and new enumerations. They are listed below:

  • Addition of a CDB Attribute Extension Mechanism

  • Changes to FDD entries and fields

  • Changes to the CDB Attributes

  • Metadata folder and the XML files changed

  • Some datasets deprecated and some datasets added

  • Model Levels-of-Detail is changed and simplified

  • Imagery and Elevation datasets components changed

  • Handling of Topological Networks is different

  • Additional Base Materials for use with building interiors

5.3. Demonstration Scenario

The underlying use case for the work documented in this report is that:

  • Organization A as a CDB provider:

    • Wants to share the CDB dataset with other users without them having to download and manually import the data;

    • Should be able to set its CDB as a data source for either a WCS or WFS server application.

  • Organization B as a CDB consumer:

    • Wants to be able to access a CDB dataset using standardized OGC Web Services protocols;

    • Is able to integrate the CDB data into existing local data analysis workflows using WCS and WFS without having to install or set up CDB-specific components;

    • Wants to access a CDB dataset via a WFS interface with spatial querying capabilities;

    • Wants a client that is capable of viewing CDB datasets either locally or via a WCS/WFS interface;

    • Wants the ability to convert a CDB dataset from CDB feature codes to NAS for a specific purpose and vice versa.

5.4. Technology Integration Experiments

This section discusses the CDB-related Technology Integrated Experiments (TIEs) conducted in Testbed 13.

5.4.1. TIE Components

The following table provides an overview of the components involved in the CDB TIEs.

Table 2. Involved TIE Components
Abbreviation Component Name and Description Deliverable


Web Coverage Service to access elevation and imagery data



Web Map Service to access imagery data



Web Feature Service to access vector data layers



3D Web Feature Service to access 3D models


CDB Client

Conversion Client to access both a local CDB and CDB web services


The above components are available on the University of Calgary component page and the LUCIAD component page.

5.4.2. TIE Results

The following table lists all the conducted TIEs.

Table 3. TIE Pairings
TIE between Use Case Success

CDB-client / CDB-WCS

Show elevation and imagery data provided by the CDB WCS


CDB-client / CDB-WMS

Show imagery data provided by the CDB WMS


CDB-client / CDB-WFS

Show road network data provided by CDB WFS


CDB-client / CDB-3DWFS

Show 3D vegetation data provided by the CDB 3D WFS


CDB-client / local CDB loading

Show data from a local CDB datastore


CDB-client / local CDB NAS conversion

Convert local CDB data to the NAS profile


The TIEs for the CDB client were all successful and the demonstration videos are uploaded on the OGC portal (OGC Testbed 13*/Streaming and 3D Data/CDB).

6. OGC CDB 1.0 Background

The OGC CDB is an international standard for structuring, modeling, and storing geospatial information required in high performance modeling and simulation applications. The CDB open standard enables various application scenarios for visualization, planning, education, training, emergency response and healthcare. CDB defines the core conceptual models, use cases, requirements, and specifications for employing geospatial data in 3D M&S [4]. The main features of the OGC CDB Standard are described as:

  • Run-time performance;

  • Full plug-and-play interoperable geospatial data store;

  • Ability to integrate proprietary and open-source data formats;

  • Usefulness in 3D and dynamic simulation environments.

Furthermore, compatibility with the OGC standards baseline reduces the complexity of discovering, transforming, and streaming geospatial data in the synthetic environment and makes them more widely acceptable to major geospatial data/software producers.

6.1. CDB Conceptual Data Model

Conceptual modelling is a structural methodology for describing how the components of a CDB data store will be implemented based on the modular specification design pattern. The OGC CDB conceptual model presents the important components of the core standard (Figure 2). This model, along with its requirements, extension, file-based structure, data formats, access, and the discovery of services, can be used as the basis for the OGC CDB standard in a variety of application domains. The conceptual model is comprised of concepts, schema, classes and categories, as well as their relationships, which are used to understand, and/or represent an OGC CDB datastore. The following figure (Figure 2) describes the CDB original conceptual model and consists of all the UML files related to the CDB’s structure. The CDB conceptual model could be implemented in Oracle, PostGIS or almost any other database software.

ch5 fig1 CDB CM
Figure 2. OGC CDB core conceptual model and its related packages

The CDB datastore structure provides efficient access to its contents. The main properties of the CDB datastore UML diagram are listed in the following Table.

Table 4. Description of the OGC CDB conceptual model (Please refer to Figure 2)
Name Definition Data Type & Value Multiplicity & Use


Geographically divides the world into geodetic tiles (bound by latitudes and longitudes), each containing at least a dataset.

Dataset type.

One or more (mandatory).

LoD Hierarchy

Each dataset layer has a hierarchy of data layers describing different levels of details.

Hierarchy of raster, vector and 3D models.

One or more (mandatory).


It defines the basic storage unit used in a CDB datastore.

Layers of data.

One or more (mandatory).

3D Models

It includes 3D representations of static or moving features such as buildings, pylons and posts, aircraft and other moving platforms. 3D models have various model components.

Model data formats supported in the CDB standard (e.g. OpenFlight).

Zero or more (optional).


There are various imageries in a CDB datastore such as representations of geo-referenced terrain, elevation, and texture.

Image data formats supported in the CDB standard (e.g. GeoTIFF, JPEG, etc.).

Zero or more (optional)

Vector Features

These include all the vector feature datasets in a CDB which are defined by the feature codes.

Vectors data formats supported by the CDB (e.g. Shapefile, etc.).

Zero or more (optional).


It is depicted by a grid of elevation data elements at regular geographic intervals, or a Triangulated irregular network.

Grid of terrain altimetry data.

Zero or more (optional).


A number of CDB XML files that include the default hierarchies, naming, and values to be used by client devices.

XML association.

Zero or more (optional).

The OGC CDB Standard relies on three important means to organize the synthetic environmental data: a) Tiles which organize the data into zones defined by its location with respect to a WGS84 reference system; b) Layers (or datasets) which organize different types of data in a tile; and c) Levels of Detail (LoD) which organize the data in each layer of each tile by its detail. The UML diagram in Figure 3 describes how the data is categorized into tiles, layers and LoDs. This is the basis for the CDB geospatial data categorization. A CDB database can use existing common file formats for storing data such as: TIFF/GeoTIFF (raster data), JPEG 2000 (imagery data), OpenFlight (3D models), Shape (vector data and radar cross sections), RGB (textures), XML (Metadata) and ZIP (file collection).

ch5 fig2 FileHierarchy
Figure 3. UML diagram of the CDB general data organization

This diagram shows the general data organization for the CDB. The main properties of the CDB general data organization UML diagram are listed in the following table.

Table 5. Description of the OGC CDB data organization (Please refer to Figure 3)
Name Definition Data Type Multiplicity

Raster Dataset

Data elements are organized into an evenly-positioned, regular grid. Raster Datasets always have a fixed number of elements corresponding to their LoD spec.

Raster data formats supported in CDB Core Standard for elevation, imageries, texture and grid data.

Zero or more (optional).

Vector Dataset

The point, line, and area features are organized into several Vector Datasets and LoDs. For each LoD, the maximum number of points allowed per Tile-LoD and the resulting average Feature Density is defined.

Vector data, RMDescriptor, GSFeature, GTFeature, GeoPolitical, VectorMateria, RoadNetwork, RailRoadNetwork, PowerLineNetwork, HydrographyNetwork.

Zero or more (optional).

3D Model Dataset

This includes the 3D Geotypical, Geospecific, Moving Model and 2D Model or cultural features such as air platforms, buildings and pylons and posts. 3D models have various model components.

OpenFlight models, GSModelGeometry, GSModelTexture, GSModelSignature, GSModelDescriptor, GSModelMaterial, GSModelInteriorGeometry, GSModelInteriorTexture, GSModelInteriorDescriptor, GSModelInteriorMaterial, GSModelCMT, T2DmodelGeometry.

Zero or more (optional).

Navigation Dataset

Navigation library is composed of a single dataset.


Zero or more (optional).

6.2. CDB File Folder Structure

This section describes how the current version of a CDB conformant datastore uses the computer’s native file system to store data in files and directories. An important feature of the CDB Standard is that all CDB file names are unique and that the file name alone is sufficient to infer the path of the file. This is an important performance factor for the simulator client to find the path of a specific feature or dataset by its name. The CDB datastore 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 datastore comprises of the following structures:

  • \CDB\: This is the root directory. It does not need to be named “\CDB\” but can be any valid path name on any disk device or volume under the target file system it is stored on;

  • \CDB\Metadata\: This directory contains the XML metadata and controlled vocabulary files which are global to the CDB;

  • \CDB\GTModel\: This is the entry directory that contains the Geotypical Models Datasets;

  • \CDB\MModel\: This is the entry directory that contains the Moving Models Datasets;

  • \CDB\Tiles\: This is the entry directory that contains all the tiles within the CDB instance;

  • \CDB\Navigation\: This is the entry directory that contains the global Navigation datasets.

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

7. Feasibility Study of the CDB Extended Feature Codes and Attribute Schema

One of the persistent and important concerns with the OGC CDB 1.0 standard is how to evolve beyond the current use of CDB feature codes and attributes. OGC CDB users and SWG members have expressed an interest in a broader feature data dictionary (FDD) which embodies most (if not all) of the feature codes encountered in the commonly used OGC standards and baselines and at a minimum level, incorporate the much more recent NSG Application Schema (NAS). Therefore, the main objectives of the CDB work package in Testbed 13 are focused on investigating how CDB could support:

  • Additional feature types and attributes than those specified in the OGC CDB 1.0 standard;

  • Schemas (a specification of the feature types that may occur in a dataset along with their attributes and additional information such as multiplicity and association).

This section explains the current CDB data model, feature coding, and attribution schema. Then, the interoperability issues related to use of the NAS profile are described. Finally, the current solutions for extending CDB feature codes and schema are evaluated and the proposed change requests are presented.

7.1. OGC CDB Feature Codes

The OGC CDB 1.0 standard comes with a set of pre-defined feature types, which are listed in a Feature Data Dictionary (FDD), in the form of an XML file and specified as part of the standard. The list of feature types is defined in a Feature_Data_Dictionary.xml [1] file which is located at /CDB/Metadata/Feature_Data_Dictionary.xml. The CDB feature dictionary currently does not support a capability to express relationships between features.

The mostly used formats in CDB to encode feature data (vectors and 3D models) are Shapefiles and OpenFlight files. The CDB feature codes have also been used for indexing Geotypical and Geospecific 3D models.

The OGC CDB 1.0 standard uses a convenient categorization of features (based on FACC code which is now called as "CDB feature code"). The first character in a 5-character CDB feature code (e.g., "CCnnn") represents a category of features, the second represents a subcategory of the current category, and the last three characters represent a specific feature type in the subcategory. To provide an even better classification of features, the CDB standard defines an additional attribute called feature sub-code (FSC). By extending the feature code hierarchy structure in this manner, it is possible to define a broader set of feature types. The sub-code value and its meaning depend on the feature code and varies by feature type. The feature code structure and its data model are presented in Figure 4.

ch6 fig1 FeatureCodes
Figure 4. OGC CDB Feature code category and data model

The current CDB FDD is a consolidation of the DIGEST, DGIWG, SEDRIS, and UHRB dictionaries. These standards are commonly used for the attribution of source vector data in a broad range of simulation applications (Figure 5). These Feature Codes were supported by the DGIWG FDD and the ISO/IEC 18025 data dictionaries.