Open Geospatial Consortium
Submission Date: 2015-03-02
Approval Date: 2015-05-23
Publication Date: 2015-07-22
External identifier of this OGC® document: http://www.opengis.net/doc/BP/cdb-vol1/1.0
Internal reference number of this OGC® document:

15-003

Version: 1.0.0
Category: OGC® Best Practice
Editor: David Graham

OGC Common DataBase
Volume 1 Main Body
Copyright notice
Copyright © 2015 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.

Warning
This document defines an OGC Best Practices on a particular technology or approach.
This document is not an OGC Standard and may not be referred to as an OGC Standard.
It is subject to change without notice. However, this document is an official position of
the OGC membership on this particular technology topic.

Document type:
Document subtype:
Document stage:
Document language:

OGC® Best PracticeApproved
Englishi

Copyright © 2015 Open Geospatial ConsortiumCopyright 2015 CAE Inc.
The companies listed above have granted the Open Geospatial Consortium (OGC) a
nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document andto modify this document and distribute copies of the modified version.

ii

Copyright © 2015 Open Geospatial Consortium

License Agreement
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 A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTSTHAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDEDIN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILLMEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE
UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT
THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OFINTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY
DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTINGFROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH
THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
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 asprovided 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 orcause 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.

iii

Copyright © 2015 Open Geospatial Consortiumi.

Abstract
The Common DataBase (CDB) Specification provides the means for a single,
versionable, simulation-rich, synthetic representation of the earth. A database that
conforms to this Specification is referred to as a Common DataBase or CDB. A CDB
provides for a synthetic environment repository that is plug-and-play interoperable
between database authoring workstations. Moreover, a CDB can be used as a common
on-line (or runtime) repository from which various simulator client-devices cansimultaneously retrieve and modify, in real-time, relevant information to perform theirrespective runtime simulation tasks; in this case, a CDB is plug-and-play interoperable
between CDB-compliant simulators. A CDB can be readily used by existing simulationclient-devices (legacy Image Generators, Radar simulator, Computer Generated Forces,etc.) through a data publishing process that is performed on-demand in real-time.
The application of CDB to future simulator architectures will significantly reduceruntime-source level and algorithmic correlation errors, while reducing development,
update and configuration management timelines. With the addition of the HLA/FOM
and DIS protocols, the application of the CDB Specification provides a Common
Environment to which inter-connected simulators share a common view of the simulated
environment.
The CDB Specification is an open format Specification for the storage, access andmodification of a synthetic environment database. The Specification defines the data
representation, organization and storage structure of a worldwide synthetic representationof the earth as well as the conventions necessary to support all of the subsystems of afull-mission simulator. The Specification makes use of several commercial andsimulation data formats endorsed by leaders of the database tools industry.
The CDB synthetic environment is a representation of the natural environment including
external features such as man-made structures and systems. It encompasses the terrain
relief, terrain imagery, three-dimensional (3D) models of natural and man-made culturalfeatures, 3D models of dynamic vehicles, the ocean surface, and the ocean bottom,
including features (both natural and man-made) on the ocean floor. In addition, thesynthetic environment includes the specific attributes of the synthetic environment data
as well as their relationships.
A CDB contains datasets organized in layers, tiles and levels-of-detail; together, thesedatasets represent the features of a synthetic environment for the purposes of distributed
simulation applications. The organization of the synthetic environmental data in a CDB
is specifically tailored for real-time applications.

ii.

Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, CDB, Common DataBase, simulationiv

Copyright © 2015 Open Geospatial Consortium

iii.

Preface
The industry-maintained Common CDB has been discussed and demonstrated at OGC
Technical Committee meetings beginning in September, 2013.
At the suggestion of several attendees at the first CDB ad-hoc meeting in September,
2014, the current version of the existing CDB specification has been slightly reformatted
for publication as an OGC Best Practice.
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 beaware that might be infringed by any implementation of the standard set forth in thisdocument, and to provide supporting documentation.

iv.

Submitting organizations
The following organizations submitted this Document to the Open Geospatial
Consortium (OGC):CAE Inc.

v.

Submitters
All questions regarding this submission should be directed to the editor or the submitters:

Name

Affiliation

David Graham

CAE Inc.

Mike Lokuta

CAE USA, Incv

Copyright © 2015 Open Geospatial Consortium1. Scope
The full CDB specification, in its current, industry-maintained format and version,
addresses the interoperability challenge of full plug-and-play interoperability and re-useof synthetic environment databases used for high fidelity simulation and mission
rehearsal.
The first CDB specification was developed under a competitive contract awarded to CAE
to meet requirements of the United States Special Operations Command. The CDB
Specification was required to be open and non-proprietary as part of the original
requirements. The revision history of the industry-maintained specification is containedin the following document sections.
The CDB specification was been widely implemented by multiple, independent industry
contractors for end-user simulation and mission rehearsal customers in many different
countries over a period of ten years.
For ease of editing and review, the specification has been separated into two Volumes.
Volume 1 contains the main body of the specification, and Volume 2 contains theappendices. Nevertheless, the documents remain large and verbose, as the current,
industry maintained specification has functioned as a data model, an encoding
specification, and an engineering tutorial on how to implement this new and different
simulation synthetic environment paradigm.
The remainder of this document comprises Volume 1.

vi

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Common DataBase (CDB) Version 3.2 Specification Volume 1

vii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Revision History
The new revision history is presented in reversed chronological order where the most recent
revision appears at the top of the table.
VersionDate

Description

3.2

19 March 2014

Changes:- Updated the list of DIS codes found in/CDB/Metadata/Moving_Model_Codes.xml- Editorial changes to volume 1 and 2 to remove markups andhighlights, promote a consistent use of various terms andexpressions, check spelling, correct the formatting, etc.
First public release of version 3.2 of the CDB Specification.

12 February 2014

The changes with respect to the first release candidate of 19
December 2013 are the followings:- Revised the implementation of the Primary Alternate
Elevation (formely Subordinate Terrain Offset)- Added the Subordinate Alternate Bathymetry- Introduced the concept of Mesh Type and added an optional
channel to the Primary Terrain Elevation and Subordinate
Bathymetry components to store the Mesh Type.
19 December 2013

First release candidate of version 3.2 of the CDB Specification.

December 2012

The changes with respect to the first draft of December 2012
take into account comments received from users and addressconcerns about compatibility with version 3.0.
First Draft of version 3.2 of the CDB Specification.

Old Revision History
The old revision history is presented in chronological order where the most recent revisionappears at the bottom of the table.
Revision Level

Date

Description

V1.0 – First Draft

October 28, 2005

V2.0 – Second Draft

March 16, 2006

First draft available for comments fromindustry
Second draft of the CDB Specification

viii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
V2.1 – Third Draft
V2.2 – Fourth Draft
V2.3 – Fifth Draft
V2.4 – Sixth Draft
V2.5 – Seventh Draft
V3.0 – Draft
V3.0 – Draft 2
V3.0 – Draft 3
V3.0
V3.1 – Draft
V3.1
V3.1 – Correction 1

October 25, 2006
June 15, 2007
July 9, 2007
October 5, 2007
November 9, 2007
December 21, 2007
March 27, 2008
June 25, 2008
September 2008
November 2009
May 2010
December 2011

Third draft of the CDB Specification
Fourth draft of the CDB Specification
Fifth draft of the CDB Specification
Sixth draft of the CDB Specification
Seventh draft of the CDB Specification
First draft of CDB 3.0
Second draft of CDB 3.0
Third draft of CDB 3.0
Official release of CDB 3.0
First draft of CDB 3.1
Official Release of CDB 3.1
Editorial Corrections to CDB 3.1

ix

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Table of Contents1	  Introduction ............................................................................................................................. 1	
  
1.1	
  

Purpose ................................................................................................................ 1	
  

1.2	
  

Document Structure ............................................................................................ 1	
  

1.3	
  

Scope ................................................................................................................... 2	
  1.3.1	
  What is the CDB Specification ........................................................................... 3	
  1.3.1.1	
  Use of CDB as an Off-line Database Repository................................................ 5	
  1.3.1.2	
  Use of CDB as a Combined Off-line and Run-time Database Repository ......... 9	
  1.3.2	
  What the CDB Specification Is Not .................................................................. 12	
  1.3.3	
  What is a CDB .................................................................................................. 13	
  

1.4	
  

Key Features and Characteristics of the CDB Specification ............................ 14	
  1.4.1	  Synthetic environment Database for Simulation Applications ......................... 14	
  1.4.2	
  Logical Addressability ...................................................................................... 14	
  1.4.3	
  High Spatial Resolution and Scalability ........................................................... 14	
  1.4.4	  Earth Geodetic Spatial Representation Model .................................................. 15	
  1.4.5	
  Tile/Layer/Level-of-Detail Structure ................................................................ 15	
  1.4.5.1	
  Tiles................................................................................................................... 15	
  1.4.5.2	
  Layers ................................................................................................................ 15	
  1.4.5.3	
  Levels-of-Detail ................................................................................................ 16	
  1.4.6	
  Platform Independence ..................................................................................... 16	
  1.4.6.1	
  System Software Independence ........................................................................ 17	
  1.4.6.2	
  System Hardware Independence ....................................................................... 18	
  1.4.7	  Synthetic Environment Scalability & Adaptability .......................................... 21	
  1.4.8	
  Platform Scalability .......................................................................................... 23	
  1.4.9	
  Simulator Wide Unique Data Representation, Data Normalization ................. 25	
  1.4.10	  Compression of Storage Intensive Imagery Datasets ....................................... 26	
  x

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.4.11	  1.5	
  Key Benefits of the CDB Specification ............................................................ 27	
  1.5.1	
  Improved Synthetic environment DB Generation Timeline ............................. 27	
  1.5.2	
  Interoperable Simulation-Ready Synthetic environment DB ........................... 28	
  1.5.3	
  Improved Client-device Robustness/Determinism ........................................... 28	
  1.5.4	
  Runtime-Adjustable Synthetic Environment DB Correlation and Fidelity ...... 29	
  1.5.5	
  Increased Synthetic Environment DB Longevity ............................................. 29	
  1.5.6	
  Reduced Synthetic Environment DB Storage Infrastructure Cost .................... 30	
  

1.6	
  

2	
  

Compression of other Raster Datasets .............................................................. 27	
  

CDB Primer ...................................................................................................... 30	
  1.6.1	  

CDB Specification Data Representation and Organization .............................. 31	
  1.6.2	  

CDB Specification Logical Structure ............................................................... 32	
  1.6.3	  

CDB Structure, Organization on Media and Conventions................................ 33	
  1.6.4	  Typical Implementation on a Simulator ........................................................... 34	
  1.6.4.1	
  Database Generation Facility ............................................................................ 35	
  1.6.4.2	
  Database Generation Flow ................................................................................ 36	
  1.6.4.3	
  Update Manager ................................................................................................ 39	
  1.6.4.4	
  

CDB Servers ..................................................................................................... 40	
  1.6.4.5	  Other Applications of the CDB Specification .................................................. 44	
  1.6.5	
  Use of CDB in Applications Requiring Dynamic Synthetic Environments ..... 44	
  1.6.6	  Synthetic Environment Database Correlation ................................................... 45	
  

CDB Concepts ...................................................................................................................... 55	
  
2.1	
  

Partitioning the Earth into Tiles ........................................................................ 55	
  2.1.1	
  Description ........................................................................................................ 56	
  2.1.2	
  Tile Levels-of-Detail (Tile-LODs) ................................................................... 59	
  2.1.2.1	
  Tile-LOD Area Coverage Rules ....................................................................... 63	
  2.1.2.2	
  Tile-LOD Hierarchy Rules ............................................................................... 64	
  2.1.2.3	
  Tile-LOD Replacement Rules........................................................................... 64	  xi

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2.1.3	  2.2	
  File System Requirements ................................................................................ 65	
  2.2.1	
  Character Set ..................................................................................................... 65	
  2.2.2	  A word about case-sensitiveness ...................................................................... 66	
  

2.3	
  

Light Naming .................................................................................................... 67	
  2.3.1	  2.4	
  Adding Names to the CDB Light Name Hierarchy .......................................... 69	
  Model Component Naming............................................................................... 69	
  2.4.1	  2.5	
  Adding New Model Components ..................................................................... 70	
  Materials ........................................................................................................... 70	
  2.5.1	
  2.5.1.1	
  2.5.2	
  Base Materials ................................................................................................... 71	
  Base Material Table (BMT) .............................................................................. 71	  Composite Materials ......................................................................................... 71	
  2.5.2.1	
  Composite Material Substrates ......................................................................... 72	
  2.5.2.2	
  Composite Material Tables (CMT) ................................................................... 74	
  2.5.2.3	
  Example 1 ......................................................................................................... 76	
  2.5.2.4	
  Example 2 ......................................................................................................... 76	
  2.5.3	
  Bringing it all Together ..................................................................................... 76	
  2.5.4	
  Determination of Material Properties by SEM ................................................. 77	
  2.5.4.1	
  2.5.5	  3	  Handling of the North and South Pole .............................................................. 64	
  Example ............................................................................................................ 78	
  Generation of Materials for Inclusion in CDB Datasets ................................... 79	
  

CDB Structure ....................................................................................................................... 81	
  
3.1	
  

Top-Level CDB Structure Description ............................................................. 81	
  3.1.1	
  Metadata Directory ........................................................................................... 82	
  3.1.2	
  Metadata File Examples .................................................................................... 84	
  

3.2	
  
3.2.1	  

CDB Configuration Management ..................................................................... 84	
  CDB Version ..................................................................................................... 84	  xii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.2.1.1	
  

CDB Extensions ................................................................................................ 86	
  3.2.2	  CDB Version Directory Structure ..................................................................... 86	
  3.2.3	  

CDB File Replacement Mechanism.................................................................. 87	
  3.2.3.1	
  How to Handle Archives ................................................................................... 89	
  3.2.3.2	
  How to Handle the Metadata Directory ............................................................ 89	
  3.2.4	  

CDB Configuration ........................................................................................... 89	
  3.2.5	  Management of CDB Configurations and Versions ......................................... 90	
  

3.3	
  

CDB Model Types ............................................................................................ 91	
  3.3.1	  GTModel (Geotypical 3D Model) .................................................................... 92	
  3.3.2	  GSModel (Geospecific 3D Model) ................................................................... 92	
  3.3.3	  T2DModel (Tiled 2D Model) ........................................................................... 92	
  3.3.4	  MModel (Moving 3D Model) ........................................................................... 92	
  3.3.5	
  Use of GSModels and GTModels ..................................................................... 93	
  3.3.6	  Organizing Models into Levels of Details ........................................................ 96	
  3.3.7	  Organizing Models into Datasets ...................................................................... 98	
  3.3.8	  Terms and Expressions ..................................................................................... 99	
  3.3.8.1	
  Feature Classification........................................................................................ 99	
  3.3.8.2	
  Model Name...................................................................................................... 99	
  3.3.8.3	
  

DIS Entity Type ................................................................................................ 99	
  3.3.8.4	
  Texture Name.................................................................................................. 100	
  3.3.8.5	
  Level of Detail ................................................................................................ 101	
  

3.4	
  

GTModel Library Datasets ............................................................................. 101	  3.4.1	  GTModel Directory Structure 1: Geometry and Descriptor ........................... 101	  3.4.1.1	
  GTModelGeometry Entry File Naming Convention ...................................... 102	  3.4.1.2	
  GTModelGeometry Level of Detail Naming Convention .............................. 103	
  

3.4.1.3	
  GTModelDescriptor Naming Convention ...................................................... 104	
  

3.4.1.4	
  Examples ......................................................................................................... 104	
  

3.4.2	  GTModel Directory Structure 2: Texture, Material, and CMT ...................... 105	
  

xiii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.4.2.1	
  GTModelTexture Naming Convention ........................................................... 106	
  3.4.2.2	
  GTModelMaterial Naming Convention .......................................................... 106	
  3.4.2.3	
  GTModelCMT Naming Convention............................................................... 107	  

3.4.2.4	
  Examples ......................................................................................................... 107	  

3.4.3	  GTModel Directory Structure 3: Interior Geometry and Descriptor .............. 108	
  3.4.3.1	
  GTModelInteriorGeometry Naming Convention ........................................... 109	  3.4.3.2	
  GTModelInteriorDescriptor Naming Convention .......................................... 110	
  3.4.3.3	
  Examples ......................................................................................................... 110	
  3.4.4	  GTModel Directory Structure 4: Interior Texture, Material, and CMT ......... 111	
  3.4.4.1	
  GTModelInteriorTexture Naming Convention ............................................... 112	
  3.4.4.2	
  GTModelInteriorMaterial Naming Convention .............................................. 113	
  3.4.4.3	
  Example 1 ....................................................................................................... 113	
  3.4.4.4	
  Example 2 ....................................................................................................... 114	
  

3.4.5	  GTModel Directory Structure 5: Signature .................................................... 114	
  

3.4.5.1	
  Naming Convention ........................................................................................ 115	
  

3.4.5.2	
  Examples ......................................................................................................... 116	
  3.4.6	  3.5	
  GTModel Complete Examples ....................................................................... 116	  MModel Library Datasets ............................................................................... 117	  3.5.1	  MModel Directory Structure 1: Geometry and Descriptor ............................. 117	  3.5.1.1	
  MModelGeometry Naming Convention ......................................................... 118	
  3.5.1.2	
  MModelDescriptor Naming Convention ........................................................ 119	  

3.5.1.3	
  Examples ......................................................................................................... 119	  

3.5.2	  MModel Directory Structure 2: Texture, Material, and CMT ........................ 120	
  3.5.2.1	
  MModelTexture Naming Convention............................................................. 120	
  3.5.2.2	
  MModelMaterial Naming Convention ........................................................... 121	  

3.5.2.3	
  MModelCMT Naming Convention ................................................................ 121	  

3.5.2.4	
  Examples ......................................................................................................... 122	  3.5.3	  MModel Directory Structure 3: Signature ...................................................... 122	  3.5.3.1	
  Naming Convention ........................................................................................ 123	  3.5.3.2	
  Examples ......................................................................................................... 124	
  

3.5.4	  MModel Complete Examples ......................................................................... 125	
  xiv

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 20143.6	  CDB Tiled Datasets ........................................................................................ 125	
  3.6.1	
  Tiled Dataset Types ........................................................................................ 125	
  3.6.1.1	
  Raster Datasets ................................................................................................ 125	
  3.6.1.2	
  Vector Datasets ............................................................................................... 126	
  

3.6.1.3	
  Model Datasets................................................................................................ 127	
  

3.6.2	
  Tiled Dataset Directory Structure ................................................................... 127	
  

3.6.2.1	
  Directory Level 1 (Latitude Directory) ........................................................... 129	
  

3.6.2.2	
  Directory Level 2 (Longitude Directory) ........................................................ 130	
  

3.6.2.3	
  Directory Level 3 (Dataset Directory) ............................................................ 132	
  

3.6.2.4	
  Directory Level 4 (LOD Directory) ................................................................ 133	
  3.6.2.5	
  Directory Level 5 (UREF Directory) .............................................................. 133	
  3.6.3	
  Tiled Dataset File Naming Conventions ......................................................... 135	
  

3.6.3.1	
  File Naming Convention for Files in Leaf Directories (UREF Directory) ..... 135	
  

3.6.3.2	
  File Naming Convention for Files in ZIP Archives ........................................ 137	
  

3.7	
  

Navigation Library Dataset ............................................................................. 139	
  3.7.1	  NavData Structure ........................................................................................... 139	
  3.7.2	  Naming Convention ........................................................................................ 139	
  3.7.2.1	
  Examples ......................................................................................................... 139	
  

4	
  

CDB File Formats ............................................................................................................... 141	
  

5	
  

CDB Datasets ...................................................................................................................... 145	
  
5.1	
  

Metadata Datasets ........................................................................................... 145	
  5.1.1	
  5.1.1.1	
  Light Name Hierarchy Metadata .................................................................... 146	
  Client Specific Lights Definition Metadata .................................................... 147	
  

5.1.2	
  Model Components Definition Metadata........................................................ 150	
  5.1.3	
  Base Material Table ........................................................................................ 150	
  5.1.4	
  Default Values Definition Metadata ............................................................... 151	
  5.1.5	
  Specification Version Metadata – Deprecated ................................................ 151	
  

5.1.6	
  Version Metadata ............................................................................................ 152	
  xv

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.1.7	  

CDB Attributes Metadata ............................................................................... 152	
  

5.1.7.1	
  Definition of the <Attribute> Element............................................................ 153	
  5.1.7.2	
  Definition of the <Unit> Element ................................................................... 154	
  

5.1.7.3	
  Definition of the <Scaler> Element ................................................................ 154	
  

5.1.7.4	
  Example of CDB_Attributes.xml.................................................................... 155	
  

5.1.8	
  Geomatics Attributes Metadata....................................................................... 155	
  

5.1.9	
  Vendor Attributes Metadata ............................................................................ 155	
  5.1.10	  Configuration Metadata .................................................................................. 155	
  5.1.10.1	
  A Note about Folder Path ........................................................................... 156	
  

5.1.10.2	
  Example ...................................................................................................... 156	
  

5.2	
  

Navigation Library Datasets ........................................................................... 157	
  

5.2.1	
  5.2.1.1	
  5.2.2	
  5.2.2.1	
  Schema Files ................................................................................................... 161	  Example .......................................................................................................... 162	  Key Datasets ................................................................................................... 163	
  Example .......................................................................................................... 164	
  

5.3	
  

CDB Model Textures ...................................................................................... 165	
  

5.4	
  

GTModel Library Datasets ............................................................................. 167	
  

5.5	
  

MModel Library Datasets ............................................................................... 169	
  

5.6	
  

Tiled Raster Datasets ...................................................................................... 171	
  5.6.1	
  Tiled Elevation Dataset ................................................................................... 176	
  5.6.1.1	
  Terrain Mesh Types ........................................................................................ 177	
  

5.6.1.2	
  List of all Elevation Dataset Components ...................................................... 178	
  5.6.1.3	
  Primary Terrain Elevation Component ........................................................... 179	
  

5.6.1.4	
  Primary Alternate Terrain Elevation Component ........................................... 182	
  

5.6.1.5	
  Terrain Constraints.......................................................................................... 185	
  5.6.1.6	
  MinElevation and MaxElevation Components ............................................... 188	
  

5.6.1.7	
  MaxCulture Component.................................................................................. 197	
  5.6.1.8	
  Subordinate Bathymetry Component .............................................................. 200	
  5.6.1.9	
  Subordinate Alternate Bathymetry Component .............................................. 203	
  xvi

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.1.10	
  5.6.2	
  Subordinate Tide Component ..................................................................... 204	  Tiled Imagery Dataset ..................................................................................... 208	
  

5.6.2.1	
  Raster-Based Imagery File Storage Extension Naming.................................. 208	
  

5.6.2.2	
  List of all Imagery Dataset Components ........................................................ 215	
  5.6.2.3	
  Visible Spectrum Terrain Imagery (VSTI) Components ................................ 216	
  

5.6.2.4	
  Visible Spectrum Terrain Light Map (VSTLM) Component ......................... 219	  5.6.3	
  Tiled Raster Material Dataset ......................................................................... 220	
  5.6.3.1	
  List of all Raster Material Dataset Components ............................................. 223	
  5.6.3.2	
  Composite Material Index Component ........................................................... 223	
  5.6.3.3	
  Composite Material Mixture Component ....................................................... 224	
  5.6.3.4	
  Composite Material Table Component ........................................................... 225	
  

5.7	
  

Tiled Vector Datasets ...................................................................................... 226	
  5.7.1	
  Introduction to Vector Datasets ...................................................................... 226	
  5.7.1.1	
  Shapefile Type Usage and Conventions ......................................................... 229	  5.7.1.2	
  

CDB Attribution.............................................................................................. 231	
  

5.7.1.3	
  

CDB Attributes ............................................................................................... 239	  5.7.1.4	
  Explicitly Modeled Representations ............................................................... 287	
  5.7.1.5	
  Implicitly Modeled Representations ............................................................... 288	
  5.7.1.6	
  Handling of Topological Networks ................................................................ 288	
  5.7.1.7	
  Handling of Light Points ................................................................................. 291	
  5.7.1.8	
  Allocation of CDB Attributes To Vector Datasets ......................................... 291	
  5.7.2	
  Tiled Navigation Dataset ................................................................................ 295	
  5.7.2.1	
  Default Read Value ......................................................................................... 295	
  5.7.2.2	
  Default Write Value ........................................................................................ 295	
  5.7.3	
  Tiled GSFeature Dataset ................................................................................. 295	
  5.7.3.1	
  Default Read Value ......................................................................................... 297	  5.7.3.2	
  Default Write Value ........................................................................................ 297	
  5.7.4	
  Tiled GTFeature Dataset ................................................................................. 297	
  5.7.4.1	
  Default Read Value ......................................................................................... 298	
  5.7.4.2	
  Default Write Value ........................................................................................ 298	  5.7.5	
  Tiled GeoPolitical Feature Dataset ................................................................. 298	
  

xvii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.5.1	
  Boundary and Location Features .................................................................... 299	  5.7.5.2	
  Elevation Constraint Features ......................................................................... 301	
  5.7.5.3	
  Default Read Value ......................................................................................... 302	
  5.7.5.4	
  Default Write Value ........................................................................................ 302	
  5.7.6	
  5.7.6.1	
  Default Read Value ......................................................................................... 303	  5.7.6.2	
  Default Write Value ........................................................................................ 303	  5.7.7	
  Tiled RailRoadNetwork Dataset ..................................................................... 304	
  5.7.7.1	
  Default Read Value ......................................................................................... 304	
  5.7.7.2	
  Default Write Value ........................................................................................ 304	
  5.7.8	
  Tiled PowerLineNetwork Dataset................................................................... 305	
  

5.7.8.1	
  Default Read Value ......................................................................................... 306	
  5.7.8.2	
  Default Write Value ........................................................................................ 306	
  5.7.9	
  Tiled HydrographyNetwork Dataset ............................................................... 306	
  5.7.9.1	
  Default Read Value ......................................................................................... 307	
  

5.7.9.2	
  Default Write Value ........................................................................................ 307	
  

5.7.10	  Tiled Vector Composite Material Table (VCMT) .......................................... 307	
  

5.7.10.1	
  Data Type .................................................................................................... 307	
  

5.7.10.2	
  Default Read Value ..................................................................................... 307	
  

5.7.10.3	
  Default Write Value .................................................................................... 308	
  

5.8	
  

6	
  

Tiled RoadNetwork Dataset ............................................................................ 302	  Tiled Model Datasets ...................................................................................... 308	
  5.8.1	
  Tiled GSModel Datasets ................................................................................. 308	  5.8.2	
  Tiled T2DModel Datasets ............................................................................... 309	  

CDB OpenFlight Models .................................................................................................... 311	
  
6.1	
  

OpenFlight File Header................................................................................... 311	
  

6.2	
  

OpenFlight Model Tree Structure ................................................................... 311	
  6.2.1	  

CDB Model Tree Structure ............................................................................. 313	
  6.2.2	  T2DModel Tree Structure ............................................................................... 313	
  6.2.2.1	
  Restrictions ..................................................................................................... 315	
  

xviii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.2.2.2	
  Node Attributes ............................................................................................... 315	
  6.2.3	  The Use of Node Names ................................................................................. 315	
  6.2.4	
  Model Master File ........................................................................................... 316	
  6.2.5	
  Referencing Other OpenFlight Files ............................................................... 317	
  6.2.5.1	
  Models Straddling Multiple Files ................................................................... 317	
  6.2.5.2	
  Models with Multiple Model-LODs ............................................................... 318	
  

6.3	
  

Modeling Conventions .................................................................................... 318	  6.3.1	
  Model Coordinate Systems ............................................................................. 318	  6.3.1.1	
  Origin .............................................................................................................. 319	  6.3.1.2	
  Local Coordinate Systems .............................................................................. 323	
  6.3.1.3	
  Units ................................................................................................................ 323	
  6.3.1.4	
  Roll, Pitch, Yaw .............................................................................................. 324	
  6.3.2	  Geometry......................................................................................................... 324	
  6.3.3	  Roof Tagging .................................................................................................. 325	
  

6.3.4	
  Relative Priority .............................................................................................. 325	
  

6.4	
  

Model Identifiers ............................................................................................. 326	
  6.4.1	  GSModel and GTModel Identifier.................................................................. 326	
  6.4.2	  MModel Identifier ........................................................................................... 326	
  6.4.3	  2DModel Identifier ......................................................................................... 326	
  

6.5	
  

Model Zones ................................................................................................... 327	  6.5.1	
  Definition ........................................................................................................ 327	  6.5.2	
  Global Zones ................................................................................................... 328	  6.5.3	
  Zone Attributes ............................................................................................... 328	  6.5.3.1	
  Material ........................................................................................................... 328	  6.5.3.2	
  Temperature .................................................................................................... 329	  6.5.4	
  Implementation Guidelines ............................................................................. 330	
  

6.5.5	
  Model Zone Naming ....................................................................................... 332	
  xix

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.5.6	  Usages ............................................................................................................. 334	
  6.5.6.1	
  Model Landing Zones ..................................................................................... 334	
  6.5.6.2	
  Model Footprint Zones ................................................................................... 334	
  6.5.6.3	
  Model Cutout Zones ....................................................................................... 335	  6.5.6.4	
  Model Interior Zones ...................................................................................... 337	
  

6.6	
  

Model Points ................................................................................................... 348	  6.6.1	
  Definition ........................................................................................................ 349	  6.6.2	  Usages ............................................................................................................. 349	  6.6.2.1	
  Model DIS Origin ........................................................................................... 349	  6.6.2.2	
  Model Viewpoint ............................................................................................ 352	
  6.6.2.3	
  Model Attach Point ......................................................................................... 353	
  6.6.2.4	
  Model Anchor Point ........................................................................................ 353	
  6.6.2.5	
  Model Center of Mass ..................................................................................... 353	
  

6.7	
  

Model Conforming.......................................................................................... 354	
  6.7.1	  

Non Conformal (Absolute) Mode ................................................................... 355	  6.7.2	
  Point Conformal Mode ................................................................................... 355	  6.7.3	
  Vertex Conformal Mode ................................................................................. 356	
  6.7.4	
  Line Conformal Mode..................................................................................... 357	  6.7.5	
  Plane Conformal Mode ................................................................................... 358	  6.7.6	
  Surface Conformal Mode ................................................................................ 360	
  

6.8	
  

Model Levels-of-Detail ................................................................................... 361	  6.8.1	
  Exchange LODs .............................................................................................. 363	
  6.8.2	
  Additive LODs ................................................................................................ 363	
  6.8.3	
  Significant Size ............................................................................................... 364	
  6.8.3.1	
  Significant Size – Coarsest LOD .................................................................... 364	
  6.8.3.2	
  Significant Size – Other LODs ....................................................................... 366	
  6.8.4	  LOD Node Ordering ....................................................................................... 367	  6.8.5	  

LOD Generation Guidelines ........................................................................... 368	  xx

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 20146.9	  Model Switch Nodes ....................................................................................... 369	  6.9.1	
  Definition ........................................................................................................ 369	  6.9.2	  Usage............................................................................................................... 370	
  6.9.2.1	
  Articulations .................................................................................................... 370	
  6.9.2.2	
  Damage States ................................................................................................. 370	
  6.9.2.3	
  Temporal Anti-aliasing ................................................................................... 373	
  

6.10	
  

Model Articulations ........................................................................................ 375	
  6.10.1	
  Definition ........................................................................................................ 375	
  6.10.2	
  Usage............................................................................................................... 376	
  6.10.2.1	
  Rotating Parts .............................................................................................. 376	
  

6.11	
  

Model Light Points ......................................................................................... 376	
  

6.12	
  

Model Attributes ............................................................................................. 378	  6.12.1	
  Definition ........................................................................................................ 378	  6.12.2	  Vendor Attributes............................................................................................ 379	  6.12.3	
  Examples ......................................................................................................... 379	
  

6.13	
  

Model Textures ............................................................................................... 380	
  6.13.1	  Handling of Multi-textures ............................................................................. 380	
  6.13.1.1	
  Base Texture Layer ..................................................................................... 380	
  6.13.1.2	
  Subordinate Texture Layer ......................................................................... 381	
  6.13.1.3	
  Texture Mapping Conventions ................................................................... 382	
  6.13.2	
  Default Gamma Corrections ........................................................................... 383	
  6.13.3	  Texture Dimension.......................................................................................... 383	
  6.13.3.1	
  Texture Mipmap.......................................................................................... 383	
  6.13.3.2	
  Texture Size ................................................................................................ 384	
  6.13.3.3	
  Texel Size.................................................................................................... 384	
  6.13.4	  Texture Palette ................................................................................................ 384	
  6.13.4.1	
  MModel Example ....................................................................................... 384	
  6.13.4.2	
  GTModel Example...................................................................................... 384	
  xxi

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.13.4.3	
  GSModel Example ...................................................................................... 385	
  6.13.4.4	
  T2DModel Example.................................................................................... 385	
  6.13.5	  6.13.5.1	
  Model Shadow Textures ............................................................................. 386	
  6.13.5.2	
  Model Skin Textures ................................................................................... 388	  6.13.5.3	
  Model Night Maps ...................................................................................... 391	
  6.13.5.4	
  Model Light Maps....................................................................................... 393	
  6.13.5.5	  Model Tangent-space Normal Maps ........................................................... 396	
  6.13.5.6	
  Model Detail Texture Maps ........................................................................ 397	
  6.13.5.7	
  Model Contaminant and Skid Mark Textures ............................................. 398	  6.13.5.8	
  Model Cubic Reflection Maps .................................................................... 398	  6.13.5.9	
  Model Gloss Maps ...................................................................................... 401	
  6.13.5.10	
  Model Material Textures............................................................................. 401	
  

6.14	
  

Model Descriptor (Metadata) Datasets ........................................................... 401	
  6.14.1	  Model Name.................................................................................................... 402	
  6.14.2	  Model Identification........................................................................................ 402	
  6.14.2.1	
  Moving Model Identification ...................................................................... 402	
  6.14.2.2	
  Cultural Feature Identification .................................................................... 403	
  6.14.3	  Model Mass ..................................................................................................... 403	
  6.14.4	  Model Parts ..................................................................................................... 403	
  6.14.5	  Model Textures ............................................................................................... 404	
  6.14.5.1	
  Texture Metadata ........................................................................................ 404	
  6.14.5.2	
  Texture Switch ............................................................................................ 405	
  6.14.6	  Model Configurations ..................................................................................... 406	
  6.14.6.1	
  Defining Stations in a Configuration .......................................................... 406	
  6.14.6.2	
  Defining Equipment in a Station................................................................. 407	
  6.14.6.3	
  Defining Equipment Names ........................................................................ 407	
  6.14.7	
  7	
  Usages ............................................................................................................. 386	
  Model Composite Materials ............................................................................ 409	  

CDB Radar Cross Section (RCS) Models .......................................................................... 411	
  
7.1	
  

Introduction ..................................................................................................... 411	
  

xxii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 20147.2	  RCS Data Model ............................................................................................. 411	
  7.2.1	  7.3	  RCS Model Structure ...................................................................................... 411	  
RCS Polar Diagram Data Representation using Shapefile ............................. 412	
  7.3.1	  Shapefile Internal Data Structure .................................................................... 412	
  7.3.1.1	
  

RCS Model Class-Level Attributes: ............................................................... 416	
  7.3.1.2	
  

RCS Instance-Level Attribute Data ................................................................ 421	
  7.3.2	
  Multi-Variant RCS Model Applicability ........................................................ 423	
  7.3.3	
  Model’s Articulations Effect on RCS Data .................................................... 444	
  

8	
  

Glossary .............................................................................................................................. 445	
  

9	
  

Acronyms and Abbreviations ............................................................................................. 463	
  

10	
  

Reference Documents ..................................................................................................... 471	
  

11	
  

List of Contributors ......................................................................................................... 475	
  

xxiii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

List of Figures
Figure P-1: Current Approach to Synthetic Environment Generation......................................... P-4	  Figure P-2: CDB Approach to Synthetic Environment Generation............................................. P-6	  Figure 1-1: Use of CDB as an Off-line Database Repository ......................................................... 6	  Figure 1-2: SE Workflow with CDB as an Off-line Database Repository ..................................... 7	  Figure 1-3: Use of CDB as an Off-line and On-line Database Repository ................................... 10	  Figure 1-4: SE Workflow with CDB as Combined Off-line/Runtime Database Repository ....... 11	  Figure 1-5: Variable Allocation of LOD ...................................................................................... 17	
  Figure 1-6: Typical Evolution of a Database ................................................................................ 22	
  Figure 1-7: Typical Implementation of CDB Specification on High-end Simulator.................... 24	
  Figure 1-8: Typical Implementation of CDB Specification on Desktop Computer ..................... 25	
  Figure 1-9: Pipelined DB Update Process .................................................................................... 27	
  Figure 1-10: CDB Specification Tile/Layer Structure .................................................................. 33	
  Figure 1-11: Typical CDB Implementation on a Suite of Simulators .......................................... 35	
  Figure 1-12: Typical DB Generation - CDB Used as DB Repository .......................................... 36	
  Figure 1-13: Typical DB Generation Flow - CDB Used as DB & Sim Repository ..................... 38	
  Figure 1-14: Versioning Paradigm Applied to Dynamic SE ........................................................ 45	
  Figure 1-15: Sources of Synthetic environment Database Correlation Errors ............................. 50	
  Figure 1-16: Overload Limit of Least Capable Client-Device ..................................................... 52	
  Figure 1-17: Overload Limit of Each Client-Device .................................................................... 53	
  Figure 1-18: Operating Limit of Least Capable Client-Device .................................................... 53	
  Figure 1-19: Individually Adjusted to the Operating Limit of Each Client-Device ..................... 54	
  Figure 1-20: Adjusted by the Simulator Operator at Scenario Startup ......................................... 54	
  Figure 2-1: CDB Earth Slice Representation ................................................................................ 57	
  Figure 2-2: Variation of Longitudinal Dimensions versus Latitude ............................................. 58	
  Figure 2-3: Tile-LOD Hierarchy ................................................................................................... 62	
  Figure 2-4: Earth Slice Example (Five Levels-of-Detail)............................................................. 63	
  Figure 2-5: Extract from Light Naming Hierarchy ....................................................................... 68	
  Figure 2-6: Seabed Composite Material ....................................................................................... 73	
  Figure 2-7: Oil Tank Composite Materials ................................................................................... 73	
  Figure 2-8: Thermal Simulation of Oil Tank Composite Materials ............................................. 74	
  Figure 2-9: Flow of Material Attribution Data ............................................................................. 77	
  Figure 2-10: Linking CDB Base Materials to SEM Base Materials ............................................. 78	
  Figure 2-11: SEM Base Material Properties Table ....................................................................... 78	
  Figure 3-1: UML Diagram of CDB Version Concept .................................................................. 85	
  Figure 3-2: A Valid Chain of CDB Versions................................................................................ 85	
  Figure 3-3: UML Diagram of CDB Extension Concept ............................................................... 86	
  Figure 3-4: Adding content to the CDB ........................................................................................ 87	
  Figure 3-5: Modifying Content of the CDB ................................................................................. 88	
  Figure 3-6: Deleting Content from the CDB ................................................................................ 89	
  Figure 3-7: UML Diagram of CDB Configuration Concept ........................................................ 90	
  Figure 3-8: Allocation of CDB Geocells with Increasing Latitude ............................................ 131	  Figure 5-1: Center Grid Data Elements ...................................................................................... 174	
  Figure 5-2: Corner Grid Data Elements ...................................................................................... 174	
  Figure 5-3: Center Data Elements as a Function of LODs ......................................................... 175	
  xxv

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Figure 5-4: Corner Data Elements as a Function of LODs ......................................................... 175	
  Figure 5-5: Example of Digital Elevation Model (DEM) ........................................................... 176	  Figure 5-6: DEM Depicted as a Grid of Elevations at Regular Sample Points .......................... 177	  Figure 5-7: CDB Mesh Types ..................................................................................................... 178	  Figure 5-8: Primary Terrain Elevation Component .................................................................... 180	  Figure 5-9: Modeling of Wells, Overhanging Cliffs and Tunnels .............................................. 181	
  Figure 5-10: Encoding of Lat/Long Offsets................................................................................ 183	
  Figure 5-11: Grid Element Coverage within a CDB Tile ........................................................... 183	
  Figure 5-12: Storage Tank Point-Feature ................................................................................... 187	
  Figure 5-13: Road Lineal Feature ............................................................................................... 188	  Figure 5-14: LOD Structure of Raster Datasets .......................................................................... 189	
  Figure 5-15: Generation of LODs for the MinMaxElevation Dataset (1D) ............................... 191	
  Figure 5-16: Generation of LODs for the MinMaxElevation Dataset (2D) ............................... 192	  Figure 5-17: Generation of LODs for the MinMaxElevation Dataset (1D) – Special Case ....... 193	
  Figure 5-18: Availability of LODs for Elevation and MinMaxElevation Datasets .................... 194	
  Figure 5-19: Missing MinMaxElevation Datasets ...................................................................... 197	
  Figure 5-20: Primary Terrain Elevation and Subordinate Bathymetry Components ................. 200	
  Figure 5-21: Derived Earth Elevation Values ............................................................................. 201	
  Figure 5-22: Example of Primary Terrain Elevation and Bathymetry Components .................. 202	
  Figure 5-23: Terrain Elevation, Bathymetry and Tide Components .......................................... 205	
  Figure 5-24: Derived Earth Elevation, Water Elevation and Surface Elevation Values ............ 206	
  Figure 5-25: Projection of Terrain Imagery Dataset onto Terrain Elevation Dataset................. 217	
  Figure 5-26: Image Classification Example ............................................................................... 221	
  Figure 5-27: Example of a Raster Material Dataset.................................................................... 222	  Figure 5-28: Instance-level Attribution Schema ......................................................................... 234	  Figure 5-29: Class-level Attribution Schema ............................................................................. 235	  Figure 5-30: Relation between Shapes and Attributes ................................................................ 238	
  Figure 5-31: RTAI Typical Usage Histogram ............................................................................ 274	  Figure 5-32: Example of a Topological Network ....................................................................... 288	  Figure 5-33: Example of International Boundaries .................................................................... 300	  Figure 5-34: Example of City Locations .................................................................................... 300	  Figure 5-35: Example of State Capital Locations and Time Zone Boundaries .......................... 301	  Figure 6-1: General OpenFlight Tree Structure .......................................................................... 312	
  Figure 6-2: Internal Structure of CDB Models ........................................................................... 313	  Figure 6-3: Internal Structure of T2DModels ............................................................................. 314	
  Figure 6-4: Typical Structure of a Model Master File ................................................................ 317	  Figure 6-5: Model Coordinate System ........................................................................................ 319	  Figure 6-6: Coordinate System – Aircraft .................................................................................. 320	
  Figure 6-7: Coordinate System – Helicopter .............................................................................. 320	
  Figure 6-8: Coordinate System – Ship ........................................................................................ 321	  Figure 6-9: Coordinate System – Ground-based Model ............................................................. 321	  Figure 6-10: Coordinate System – Lifeform ............................................................................... 322	  Figure 6-11: Coordinate System – Cultural Feature ................................................................... 322	  Figure 6-12: Coordinate System – Power Pylon......................................................................... 323	  Figure 6-13: Model Global Zone ................................................................................................ 328	  Figure 6-14: Simple Zone ........................................................................................................... 330	
  

xxvi

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Figure 6-15: Articulated Zone .................................................................................................... 330	  Figure 6-16: Zone Hierachy ........................................................................................................ 330	  Figure 6-17: Simple Zone Graphical Representation ................................................................. 331	  Figure 6-18: Additive LOD to Control the Graphical Representation ....................................... 331	  Figure 6-19: Exchange LODs to Select the Graphical Representation....................................... 332	  Figure 6-20: Switch Node to Select the Graphical Representation ............................................ 332	  Figure 6-21: Footprint Zone Structure ........................................................................................ 335	  Figure 6-22: Cutout Zone Structure ............................................................................................ 336	  Figure 6-23: Model Shell Structure ............................................................................................ 338	  Figure 6-24: Model Interior Structure......................................................................................... 339	  Figure 6-25: Interior Zone Structure ........................................................................................... 339	  Figure 6-26: Floor Zone Structure .............................................................................................. 343	  Figure 6-27: Room Zone Structure ............................................................................................. 344	
  Figure 6-28: Fixture Zone Structure ........................................................................................... 345	  Figure 6-29: Fixture Zone Structure ........................................................................................... 345	  Figure 6-30: Partition Zone Structure ......................................................................................... 346	  Figure 6-31: Aperture Structure .................................................................................................. 348	  Figure 6-32: Surface Zone Structure........................................................................................... 348	  Figure 6-33: Orientation of the Chinook Helicopter................................................................... 350	
  Figure 6-34: The Body of the Chinook Helicopter ..................................................................... 351	  Figure 6-35: The DIS Origin of the Chinook Helicopter ............................................................ 352	  Figure 6-36: Conforming Vertices to Terrain ............................................................................. 354	
  Figure 6-37: Origin Conformal Mode......................................................................................... 356	  Figure 6-38: Vertex Conformal Mode Example ......................................................................... 357	  Figure 6-39: Line Conformal Mode ............................................................................................ 358	  Figure 6-40: Plane Conformal Mode .......................................................................................... 359	  Figure 6-41: Application of Line and Plane Conformal Modes on 3D Roads ........................... 360	
  Figure 6-42: Surface	  Confomal	  Mode ........................................................................................ 361	  Figure 6-43: Exchange and Additive LOD Nodes ...................................................................... 363	  Figure 6-44: Exchange LOD Nodes ........................................................................................... 367	  Figure 6-45: General Damage State Tree Structure .................................................................... 370	  Figure 6-46: Damage States Ordering ........................................................................................ 372	  Figure 6-47: Example of a Texture Representing a Rotor .......................................................... 373	  Figure 6-48: Multiple Versions of Rotating Parts....................................................................... 374	  Figure 6-49: Using Shadow Polygons ........................................................................................ 386	  Figure 6-50: Example of a Shadow Map in the XY Plane ......................................................... 387	  Figure 6-51: The M1A2 Abrams with a Desert Camouflage ..................................................... 388	  Figure 6-52: The M1A2 Abrams with a Forest Camouflage ...................................................... 389	  Figure 6-53: M1A2 Desert Skin Mosaic ..................................................................................... 390	  Figure 6-54: Base Texture .......................................................................................................... 392	  Figure 6-55: Night Map .............................................................................................................. 392	  Figure 6-56: Light Map ............................................................................................................... 394	
  Figure 6-57: Combined Effect of Base Textures and Light Maps .............................................. 395	
  Figure 6-58: Combined Effect of Night and Light Maps ........................................................... 395	
  Figure 6-59: Normal Map Sample .............................................................................................. 397	  Figure 6-60: Detail Texture Map Sample ................................................................................... 398	
  

xxvii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Figure 6-61: Environment Used to Produce Reflection Map ..................................................... 399	  Figure 6-62: Resulting Reflection Map ...................................................................................... 399	  Figure 6-63: Rendered Reflection Map onto Reflecting Cube ................................................... 400	
  Figure 7-1: Graphical Representation of the 3D Model RCS Shape Data ................................. 413	  Figure 7-2: Polar Diagram of RCS Data in Planar Representation ............................................ 414	  Figure 7-3: Polar Diagram of RCS Data in Spherical Representation........................................ 415	  Figure 7-4: UML Representation of the 3D Model RCS Shapefile Structure ............................ 422	  Figure 7-5: Example of RCS Shapefile ...................................................................................... 423	
  xxviii

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

List of Tables
Table 1-1: Summary of Synthetic Environment Database Correlation Errors ............................. 48	
  Table 2-1: Intervals for DTED Level 2......................................................................................... 56	
  Table 2-2: Size of CDB Geocell per Zone .................................................................................... 56	
  Table 2-3: CDB Geocell Unit Size in Arc Seconds ...................................................................... 59	
  Table 2-4: CDB LOD versus Tile and Grid Size .......................................................................... 60	
  Table 2-5: Character Set Used for CDB Files and Folders ........................................................... 65	
  Table 2-6: Components of a Base Material .................................................................................. 71	
  Table 3-1: CDB LOD vs. Model Resolution ................................................................................ 97	
  Table 3-2: GTModelGeometry Directory Structure ................................................................... 102	  Table 3-3: GTModelGeometry Entry File Naming Convention................................................. 103	  Table 3-4: GTModelGeometry Level of Detail Naming Convention ........................................ 103	  Table 3-5: GTModelDescriptor Naming Convention ................................................................. 104	  Table 3-6: GTModelTexture Directory Structure ....................................................................... 105	
  Table 3-7: GTModelTexture Naming Convention ..................................................................... 106	  Table 3-8: GTModelMaterial Naming Convention .................................................................... 106	  Table 3-9: GTModelMaterial Naming Convention .................................................................... 107	  Table 3-10: GTModelInteriorGeometry Directory Structure ..................................................... 109	  Table 3-11: GTModelInteriorGeometry Naming Convention .................................................... 110	  Table 3-12: GTModelInteriorDescriptor Naming Convention ................................................... 110	  Table 3-13: GTModelInteriorTexture Directory Structure ......................................................... 112	  Table 3-14: GTModelInteriorTexture Naming Convention ....................................................... 112	  Table 3-15: GTModelInteriorMaterial Naming Convention ...................................................... 113	  Table 3-16: GTModelSignature Directory Structure .................................................................. 114	  Table 3-17: GTModelSignature Naming Convention ................................................................ 116	  Table 3-18: MModelGeometry Directory Structure ................................................................... 117	  Table 3-19: MModelGeometry Naming Convention ................................................................. 118	  Table 3-20: MModelDescriptor Naming Convention................................................................. 119	  Table 3-21: MModelTexture Directory Structure....................................................................... 120	  Table 3-22: MModelTexture Naming Convention ..................................................................... 120	  Table 3-23: MModelMaterial Naming Convention .................................................................... 121	  Table 3-24: MModelMaterial Naming Convention .................................................................... 121	  Table 3-25: MModelSignature Directory Structure .................................................................... 122	  Table 3-26: MModelSignature Naming Convention .................................................................. 123	  Table 3-27: CDB LOD versus Feature Density .......................................................................... 126	  Table 3-28: Tiled Dataset Directory Structure............................................................................ 128	  Table 3-29: NbSliceIDIndex for every CDB Zones ................................................................... 131	  Table 3-30: Tiled Dataset File Naming Convention 1 ................................................................ 135	  Table 3-31: GTModelGeometry Entry File Directory Structure ................................................ 139	  Table 3-32: NavData Naming Convention ................................................................................. 139	  Table 4-1: CDB File Format Compatibility ................................................................................ 143	  Table 5-1: Component Selectors for Metadata Datasets............................................................. 145	  Table 5-2: Component Selectors for Navigation Dataset ........................................................... 157	  Table 5-3: List of Navigation Components ................................................................................ 158	  Table 5-4: List of Navigation Schema Attributes ....................................................................... 162	
  

xxix

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 5-5: Example of a Navigation Schema ............................................................................. 162	  Table 5-6: List of Navigation Key Attributes ............................................................................. 164	  Table 5-7: Example of Navigation Keys .................................................................................... 164	  Table 5-8: Component Selectors for CDB Model Textures ....................................................... 165	
  Table 5-9: Component Selectors for GTModel Datasets ............................................................ 167	  Table 5-10: Component Selectors for Mmodel Datasets ............................................................ 169	
  Table 5-11: Elevation Dataset Components ............................................................................... 178	  Table 5-12: Partial List of Hypsography FACCs (for Offline Terrain Constraining) ................ 185	  Table 5-13: List of Hypsography FACCs (for Online Terrain Constraining) ............................ 187	  Table 5-14: XML Tags for the JPEG 2000 Metadata ................................................................. 215	  Table 5-15: Imagery Dataset Components ................................................................................. 216	  Table 5-16: VSTI Default Read Values ...................................................................................... 218	  Table 5-17: Raster Material Dataset Components ...................................................................... 223	  Table 5-18: Component Selector 2 for Vector Datasets ............................................................. 228	
  Table 5-19: Boundary Type Enumeration Values ...................................................................... 244	  Table 5-20: Location Accuracy Enumeration Values ................................................................. 259	  Table 5-21: Location Type Enumeration Values ........................................................................ 262	  Table 5-22: Populated Place Type Enumeration Values ............................................................ 273	  Table 5-23: Surface Roughness Enumeration Values ................................................................ 277	  Table 5-24: Structure Shape Category Enumeration Values ...................................................... 280	  Table 5-25: Structure Shape of Roof Enumeration Values ........................................................ 283	  Table 5-26: Urban Street Pattern Enumeration Values............................................................... 285	  Table 5-27: Allocation of CDB Attributes to Vector Datasets ................................................... 292	  Table 5-28: Tiled Navigation Dataset ......................................................................................... 295	  Table 5-29: Component Selectors for GSFeature Dataset .......................................................... 296	  Table 5-30: Component Selectors for GTFeature Dataset .......................................................... 297	  Table 5-31: Component Selectors for GeoPolitical Feature Dataset .......................................... 298	  Table 5-32: Component Selectors for RoadNetwork Dataset..................................................... 303	  Table 5-33: Component Selectors for RailRoadNetwork Dataset .............................................. 304	  Table 5-34: Component Selectors for PowerLineNetwork Dataset ........................................... 305	  Table 5-35: Component Selectors for HydrographyNetwork Dataset ........................................ 306	  Table 5-36: Vector Composite Material Table Component ....................................................... 307	  Table 5-37: Component Selectors for GSModel Datasets .......................................................... 308	  Table 5-38: Component Selectors for T2DModel Datasets ........................................................ 309	  Table 6-1: Sample XML Tag Used in a Comment Record ........................................................ 316	  Table 6-2: XML Tags for Zones ................................................................................................. 327	  Table 6-3: OpenFlight Records for a Zone ................................................................................. 328	  Table 6-4: XML Tags for Hot Spots ........................................................................................... 329	  Table 6-5: Footprint Zone XML Tags ........................................................................................ 335	  Table 6-6: XML Tags for Landing Zones................................................................................... 336	  Table 6-7: Shell Zones XML Tags ............................................................................................. 338	  Table 6-8: Interior Zone XML Tags ........................................................................................... 339	  Table 6-9: UHRB Class Names and corresponding CDB Zone Names ..................................... 340	  Table 6-10: XML Tags for Zone Connections ........................................................................... 341	  Table 6-11: Examples of Absolute and Relative Paths ............................................................... 341	  Table 6-12: Floor Zone XML Tags ............................................................................................ 342	
  xxx

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-13: Room Zone XML Tags ........................................................................................... 343	  Table 6-14: Fixture Zone XML Tags.......................................................................................... 344	  Table 6-15: Partition Zone XML Tags ....................................................................................... 346	  Table 6-16: Aperture Zone XML Tags ....................................................................................... 347	  Table 6-17: XML Tags for Points ............................................................................................... 349	  Table 6-18: OpenFlight Records for a Point ............................................................................... 349	  Table 6-19: XML Tags for the DIS Origin ................................................................................. 349	  Table 6-20: XML Tags for a Viewpoint ..................................................................................... 353	  Table 6-21: XML Tags for Attach Point..................................................................................... 353	  Table 6-22: XML Tags for Anchor Point ................................................................................... 353	  Table 6-23: XML Tags for Center of Mass ................................................................................ 354	  Table 6-24: Conformal Modes .................................................................................................... 355	  Table 6-25: XML Tags to Create a CDB Switch ........................................................................ 369	  Table 6-26: OpenFlight Records to Create a CDB Switch ......................................................... 370	  Table 6-27: XML Tags for Damage State Switch ...................................................................... 371	  Table 6-28: Example of a Damage State Switch with Two Transitions ..................................... 371	  Table 6-29: XML Tags for Motion Blur Switch ......................................................................... 374	  Table 6-30: Example of a Motion Blur Switch with One Transition ......................................... 375	
  Table 6-31: XML Tags for DOF ................................................................................................. 375	
  Table 6-32: OpenFlight Records for a Light Point ..................................................................... 378	  Table 7-1: ModelSignature Significant Angle per LOD............................................................. 414	  Table 7-2: XML Tags for Hot Spots ........................................................................................... 416	  Table 7-3: RCS Instance Attribute Fields ................................................................................... 421	  Table 7-4: Radar Model Numbers .............................................................................................. 423	
  

xxxi

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Preface
Intended Audience
The primary audience for this document includes distributed simulation system developers andsynthetic environment database tool developers whose applications are intended to read and/or
write synthetic environment database files. To this end, this document discusses concepts
incorporated in the Specification and contains a detailed description of the physical layout of thefiles as represented on disk.
This document assumes the reader is familiar with:(1)

Synthetic environment creation and generation process.

(2)

Existing database interchange and database visualization standards (such as
SEDRIS, SIF, OpenFlight, DIS, DIGEST, Shapefile, TIFF, JPEG, etc.).

(3)

Image Generation and radar simulation principles.

(4)

Sensor subsystems used in aircraft and other vehicles (Radar, Night Vision
Image Intensifiers, Infrared (IR) sensors, Laser Range Finders, etc.) requiring
the use of synthetic environment databases.

(5)

Simulator client-devices (such as Computer Generated Forces, Air/Ground
Traffic Control, Weather, etc.) requiring the use of synthetic environment
databases.

(6)
Principles of Object-Oriented (OO) programming.
Problem Definition
Complex mission simulators include a wide range of subsystems designed to simulate on-board
equipment and to provide a rich gaming environment complete with weather, computer
generated forces, ordnance, air traffic, networked players, etc. Each of these subsystems
typically utilizes a proprietary runtime database (and format) for its synthetic representation of
the gaming area. Traditionally, these application-specific formats have been generated off-line at
a database generation facility using a variety of tools and processes. This approach has several
inherent disadvantages, including length of time needed for synthetic environment production for
multiple simulation applications, loss of correlation due to compilation differences, complexity
in configuration management, and an inefficient update process. The abundance of distinct
database formats creates several challenges for configuration management, resulting inmismatched correlation of the various cues, and in the increased timeline needed to generatethese databases. The CDB Specification is a new approach that establishes a set of industrystandard formats and conventions for all simulator client subsystems (aka simulator clientdevices).
Digital computer based flight simulation dates back to the mid-60s. Many legacy processes andassumptions have predicated the creation, maintenance, and modification of traditional militarytactical training flight simulator synthetic environment databases (DBs). Early approaches wereusually constrained by severe hardware, software and data source limitations. This in turn would© 2015 Open Geospatial Consortium

P-1

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
force simulation engineers to make important compromises between a subsystem’s targeted
fidelity and its level of generality, scalability, abstraction, and correlation with other simulator
client-devices. Industry wide standardization could not be readily achieved because
technologically viable options only offered partial solutions to these needs. Digital technologies
have made tremendous strides in the past 10 years and are narrowing the “gap” between what isrequired for training and what the technology can now deliver. As this trend continues,
simulation engineers can re-examine all of these earlier trade-offs, and redress past compromises.
The approach to visual system synthetic environments is rife with such compromises. For
instance, most DB formats in use today still require a full off-line re-compilation of the DB into a(usually proprietary) runtime format, even for a small-area update. As a result, the creation andupdate of such databases is still a recurring labor-intensive exercise. Separate, non-harmonized,
Image Generator (IG) manufacturer proprietary tools are required to generate and modify theDB, resulting in sometimes incongruous, incomplete, and closed DB formats. The typicalevolution of the DB format poses important configuration control challenges due to the requiredreconciliation of incompatible revisions of these DB formats. The entire process is further
aggravated by the time-consuming off-line compilation of visual, sensor, threat, and air traffic
DBs.
The confluence of digital multi-spectral high-resolution satellite imagery and highly capablevisual systems has created dramatic new Mission Planning and Mission Rehearsal capabilities.
As a result, recent environment databases built to take advantage of these new capabilities
require orders of magnitude more storage than equivalent databases just a few years ago.
It is clear that, if left unchecked, these factors will become important cost drivers and currently
impact simulators (see Figure P-1: Current Approach to Synthetic Environment Generation) in
the following areas:(1)

Size of the Synthetic Environment Storage:
In order to satisfy the runtime device loadable representation of each of thesimulator client-devices, the synthetic environment is replicated several times.
Most runtime device-loadable formats do not take advantage of modern
compression schemes. Furthermore, each of runtime device-loadable formats
imposes its own distinct database structure; in many cases, the organization of
the runtime database is not sufficiently flexible to permit small-area changes
without a recompilation of the database. Each recompilation generates acomplete copy of the database that must then be deployed and put underconfiguration control.

(2)Longevity of the Synthetic Environment Database:
The runtime loadable representation of each of the simulator client-devices isclosely associated with the fidelity, the features, and the format restrictions
imposed by the simulator client-devices. Increasingly, the design of simulator
client-devices is being influenced by the rapidly evolving Commercial-OffThe-Shelf (COTS) technology. However, few of the benefits of the new© 2015 Open Geospatial Consortium

P-2

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
simulator technology can be realized unless the runtime DB is rebuilt to the
new simulator capabilities.
(3)

Scalability of the Synthetic Environment Database:
The runtime loadable representation typically provided by current vendors foreach of the simulator client-devices is closely aligned to the total content anddensity limits imposed by each simulator client-devices. Once “frozen” into
the runtime loadable DB, it is difficult to fully take advantage of emerging
simulator technologies capable of handling greater DB content/density.

(4)

Environment Database Correlation:
Correlation between simulator client-devices is aggravated due to the alternate
data representations demanded by each of the (often proprietary) simulator
client-devices. Data representations can vary in resolution, precision, and in
fidelity. A solution to the correlation issue is costly because each of theruntime DBs must be re-compiled to the capabilities of the most limited
simulator client-device.

(5)

Database Availability Timeline:
The extensive off-line compilation process that produces the runtime
databases is time-consuming; furthermore, this is aggravated because
important amounts of data are replicated in each of the runtime devicespecific databases. While a parallel processing approach could alleviate this,many of current database compilation tools are not capable of supporting this.
The transfer of the replicated databases from the DB generation facility to thesimulator(s) wastes additional time. Finally, small-area updates are timeconsuming because of the monolithic structure of the client-device runtime
DBs.

(6)

Configuration management:
The configuration management of distinct simulator client-devices requires
additional effort because the client-specific runtime DBs must each be rederived and re-compiled from the raw source data. The evolution of the (often
proprietary) runtime DB formats poses additional configuration control
challenges because prior versions of the format cannot be fully reconciledwith new ones. Hence, backward compatibility cannot always be assured.
Finally, the runtime DBs are often massive entities; small area-updates cannot
be undertaken without re-compiling the entire DB.

© 2015 Open Geospatial Consortium

P-3

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure P-1: Current Approach to Synthetic Environment Generation

The CDB Specification addresses these and other shortcomings through a common database
Specification. It is intended as a simulation Specification for use in producing a unified synthetic
representation of the world. A database built to the CDB Specification is referred to as aCommon Database (CDB). A CDB is a single-copy data repository from which various
simulator client-devices are able to simultaneously retrieve, in real-time, relevant information to
perform their respective runtime simulation tasks.
The CDB Specification enhances unity and correlation between various simulator level clientdevices (e.g., Visual, Radar), while improving database maintainability. As a result, one of themain benefits of the CDB Specification is the elimination of several types of correlation errors
attributable to alternate, sometimes conflicting data representations required by each thesimulator client-devices. The Specification achieves this by allowing all simulator clientsdevices to share, in runtime, a single repository of the synthetic environment information. In
addition, a CDB can also be used as a master repository for the authoring tools; as a result CDB
content can be interchanged between DB workstations. Finally, in the case where one or more of
the client-devices are not compliant to this CDB Specification, it is possible to revert to theconventional compilation paradigm, (i.e., compile the CDB into one or more client-device
loadable (usually proprietary) representations).
The CDB Specification internal data representation model is based on the native formats used byindustry-standard toolsets. As a result, it eliminates the time-consuming off-line database
compilation process for each of the clients. The CDB Specification redefines a new balance© 2015 Open Geospatial Consortium

P-4

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
between off-line and on-line compilation processes because modern computer platforms can now
accomplish most of the compilation process in real-time1.
The CDB Specification addresses the issues that have characterized the simulation industry forpast decades (see Figure P-2: CDB Approach to Synthetic Environment Generation), as follows:1(1)

Size of Synthetic Environment Storage:
The CDB consolidates the synthetic environment into a single data repositorythat provides a static representation of the earth. It includes all the relevant
information so that all the simulator client-devices can perform theirrespective simulation tasks in order to meet the training and mission rehearsal
requirements. It avoids any data content duplication. Storage intensive
datasets can be optionally compressed using modern third-party algorithms.
The CDB Specification provides a fine-grain versioning scheme that avoids
the replication of the entire DB when effecting small-area updates.

(2)

Scalability of Synthetic Environment Database:
A CDB can be built to a size or a density that far exceeds the capabilities ofsome or all of its client-devices. The data structure of the CDB Specification
makes it possible to implement runtime filtering schemes to adjust the loaded
CDB content density to the specific capabilities of the client-devices. As aresult, a CDB can be scaled to take advantage of future simulator
technological improvements.

(3)

Environment DB Correlation:
Since CDB content is unique (without data duplication), runtime source level
correlation errors among clients are eliminated, thereby ensuring intersubsystem coherence and simulator interoperability. In addition, it is possible
to improve correlation by adjusting the runtime publishing process associatedwith each client-device.

(4)

Database Availability Timeline:
The CDB generation process allows for small database incremental updates,
thereby shortening generation and build process times. Furthermore, thetranslation step into CDB format is rather straightforward since the CDB
Specification is based on industry-standard native tool formats.

(5)

Configuration Management:
Configuration management effort is reduced, because a single CDB
corresponds to the synthetic environment of all the client-devices in thesimulator. Furthermore, while a CDB is conceptually a single, yet layered
entity, the Specification internally supports incremental updates resulting in
efficient storage and handling of CDB versions.

The CDB Specification does require however, that most of its dataset be generated in a level-of-detail hierarchy.

© 2015 Open Geospatial Consortium

P-5

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure P-2: CDB Approach to Synthetic Environment Generation© 2015 Open Geospatial Consortium

P-6

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 1
1Introduction

1.1
PurposeThis Specification provides a full description of a data model (aka schema) for the synthetic
representation of the world. The representation of the synthetic environment in CDB format is
intended for use by authoring tools and by various simulator client-devices that are able tosimultaneously retrieve, in real-time, relevant information to perform their respective runtime
simulation tasks. With the addition of the DIS protocol, the application of the CDB
Specification provides a Common Environment to which inter-connected simulators share acommon view of the simulated environment.
1.2
Document Structure
A significant portion of the CDB Specification concerns itself with aspects of the data model that
relate to the structure of the database repository on the storage subsystem. The organization of
the CDB data into tiles, levels-of-detail and datasets is embodied through a set of conventions
that prescribe the CDB directory hierarchy and file naming conventions. All aspects of the CDB
structure are covered in Chapter 3.
A second important aspect of the CDB Specification deals with all of the naming conventions
that are internal to the CDB. Names provide the simulator client-devices the necessary means tounderstand the meaning of and to control the various elements modeled within the synthetic
environment. For example, the CDB naming conventions provide all the simulator clientdevices the means to control cultural lighting, to articulate a landing gear on an aircraft, toanimate a trailing wake on a ship, to control the heat emitted by a tank engine, to position a caron the ground, etc. Names also provide the means to attribute lights and to attribute materials.
All of the CDB Concepts are stated in Chapter 2 that also deals with the naming and handling ofmaterials that make up the synthetic environment.
Chapter 4, CDB File Formats provides a description of all the formats prescribed by the CDB
Specification.
Chapter 5, CDB Datasets provides a detailed description of all CDB datasets.
OpenFlight plays a significant role within the CDB Specification since all of the statically
positioned cultural features and the moving models are represented in this format. However, for
it to be truly useful in the context of simulation, the OpenFlight format must be supplemented
with a set of agreed-upon conventions that can be used by all client-devices and the simulation
software. Chapter 6, CDB OpenFlight Models establishes all such OpenFlight conventions for
the CDB Specification.

© 2015 Open Geospatial Consortium

1

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
For devices such as Radars, a geometric representation of a model may often provide a level offidelity which is insufficient or inappropriate for use in simulation or alternately, it may not be
feasible to compute a radar cross-section (RCS) of the model in real-time. Alternately, a user
may wish to incorporate real-world RCS data into the simulator client-devices in order to further
improve simulation fidelity. To this end, the CDB Specification defines a RCS (Radar CrossSection) model representation for use by Sensor Simulation client-devices such as Radar and/or
Sonar. Chapter 7, CDB Radar Cross Section (RCS) Models establishes a set of conventions that
permit RCS representations using the Shapefile format.
The CDB Specification relies heavily on five established industry formats, namely the TIFF
format (Appendix B), the OpenFlight format (Appendix C), the RGB format (Appendix P), theShapefile format (Appendix D) and the JPEG 2000 file format (Appendix T). These
Specifications have been included as appendices to this Specification. Each of these documents
has been annotated to reflect the conventions established by the CDB Specification. The
conventions define how TIFF, OpenFlight, RGB, Shapefile and JPEG 2000 formatted files are to
be interpreted by CDB-compliant simulator readers.
Appendices E and F provide the CDB light type naming hierarchy and the CDB modelcomponent hierarchies respectively while Appendix L provides the material list for the CDB
Specification.
Other Appendices further describes other aspects of the CDB Specifications like providing the
CDB Directory Naming and Structure (Appendix M), the mapping of FACC Codes (Appendix
N), the List of Texture Component Selectors (Appendix O), the SGI Image File Format(Appendix P), the Table of Dataset Codes (Appendix Q) or how some datasets are derived fromothers (Appendix R).
1.3
Scope
The Specification defines an earth synthetic environment data model and the representation,organization, storage structure and conventions necessary to support all of the subsystems of afull-mission simulator. The Specification makes use of several commercial and simulation data
formats endorsed by leaders of the database tools industry.
The CDB synthetic environment is a representation of the natural environment including externalfeatures such as man-made structures and systems. It encompasses the terrain relief, terrain
imagery, three-dimensional (3D) models of natural and man-made cultural features, 3D models
of vehicles, the ocean surface, and the ocean bottom, including features (both natural and manmade) on the ocean floor. In addition, the synthetic environment includes the specific attributesof the synthetic environment data as well as their relationships.
A database that conforms to the CDB Specification (i.e., a CDB) contains datasets organized inlayers, tiles and levels-of-detail; together, these datasets represent the features and models of asynthetic environment for the purposes of distributed simulation applications. The organizationof the synthetic environmental data in a CDB is specifically tailored for real-time applications.

© 2015 Open Geospatial Consortium2

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.3.1
What is the CDB Specification
The CDB Specification is an open synthetic environment database Specification to which the
U.S. Government has unrestricted rights. The CDB Specification is rooted in a group of formats
well established within the simulation industry. To each of these formats, the CDB Specification
provides a comprehensive set of conventions appropriate to the field of simulation. The
Specification defines all aspects of data representation and organization, storage structure to
support full-mission simulation. A database that conforms to the CDB Specification (i.e., a
CDB) contains datasets organized in layers and tiles that represent the features of a synthetic
environment for the purposes of distributed simulation applications. A CDB can be readily usedby existing simulation client-devices (legacy IGs, Radars, CGF, etc.) through a publishingprocess performed in real-time. The data structures used in CDB Specification synthetic
environment databases are different than those used in relational databases mostly because the
CDB has chosen to standardize on formats adopted by the simulation community. Thisfacilitates the work required to adapt existing authoring tools to read/write/modify the CDB andthe task to develop runtime publishers (RTP) designed to operate on these data structures.
The CDB Specification is fundamentally about:
1. A representation of the natural earth and man-made synthetic environment for
the field of simulation.
2. A turnkey, as-is representation of the Synthetic Environment (SE) for use inreal-time distributed simulation.
The synthetic environment is a representation of the natural environment at a specificgeographical location including the external features of the man-made structures and systems.
Therefore, the synthetic environment includes the terrain, the terrain features (both natural andman-made), three-dimensional (3D) models of vehicles, the ocean surface, and the ocean bottom,
including features (both natural and man-made) on the ocean floor. In addition, the synthetic
environment includes the specific attributes of the synthetic environment data as well as theirrelationships. The CDB Specification is more than just a means of creating visual (aka out-thewindow) scenery. Unlike other Specifications that only deal with data representational types ofpolygons, colors, and textures, it deals with all the data representational types needed in high-end
virtual and constructive simulation applications.
The bulk of the CDB internal data representation is based on five commercial data formats
endorsed by leaders of the simulation database tools industry, namely:
TIFF/GeoTIFF: for the representation of terrain altimetry, terrain surface characteristics
relevant to simulation.
OpenFlight: for the representation of 3D culture and moving models.
RGB: for the textures associated with 3D culture and moving models.
Shapefile: for the instancing and attribution of statically positioned point, lineal and areal 2D/3D
culture features.

© 2015 Open Geospatial Consortium

3

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
JPEG 2000: for a representation of terrain raster imagery comprising a well defined andaccepted compression method that allows both lossy and lossless schemes.
The CDB Specification storage structure allows efficient searching, retrieval and storage of any
information contained within the CDB. The storage structure portion of the Specification defines
a comprehensive binary file description, (i.e., it specifies the exact format of all files used in theimplementation of the Specification). Storage structure aspects include descriptions of each
information field used within CDB Specification files, including data types and data typedescriptions.
The CDB Specification relies on three important means to organize the environmental data:
1. Tiles: The CDB storage structure allows efficient searching2, retrieval andstorage of any information contained within the CDB. The storage structure
portion of the Specification geographically divides the world into geodetic
tiles (bound by latitudes and longitudes), each containing a specific set offeatures (such as terrain altimetry, vectors) and models (such as OpenFlightmodels, RCS models), which are in turn represented by the datasets (seeFigure 1-10: CDB Specification Tile/Layer Structure). The datasets define thebasic storage unit used in a CDB. The geographic granularity is at the tilelevel while the information granularity is at the dataset level. As a result, the
CDB storage structure permits flexible and efficient updates due to thedifferent levels of granularity with which the information can be stored or
retrieved
2. Layers: The CDB standard data representation model is also logicallyorganized as distinct layers of information. The layers are notionallyindependent from each other (i.e., changes in one layer do not impose changes
in other layers).
3. Levels-of-Detail (LODs): The availability of LOD representations is criticalto real-time performance. Most simulation client-devices can readily takeadvantage of an LOD structure because, in many cases, less detail/informationis necessary at increasing distances from the simulated own-ship. As a result,many client-devices can reduce (by 100-fold or more) the required bandwidth
to access environmental data in real-time. The availability of levels-of-detail
permits client-devices to deal with databases having near-infinite content.
The CDB standard is structured into an LOD hierarchy consisting of up to 34
LODs. The CDB standard requires that each geographic area be reduced intoa LOD hierarchy in accordance to the availability of source data.
The Specification does not define or enforce an operating system or file system; nonetheless, theimplementation of a CDB storage sub-system must conform to absolute minimum file system
requirements called for by the Specification.

2

A information is retrieved by means of an implicit index defined by this Specification© 2015 Open Geospatial Consortium

4

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.3.1.1
Use of CDB as an Off-line Database Repository
Figure 1-1: Use of CDB as an Off-line Database Repository, illustrates the deployment processof a CDB when it is used solely as an off-line Master database repository. This approach follows
the SE deployment paradigm commonly used today within the simulation community. The useof the CDB as an off-line environmental data repository offers immediate benefits, namely…
SE Standardization through a public, open, fully-documented database schemathat is already supported by several SE authoring tools.
SE Plug-and-Play Portability and Interoperability across various vendor SE
authoring toolsets
SE Correlation through the elimination of source correlation errors throughnormalization of all data sets (a single representation for each dataset)
SE Re-use by eliminating dependencies that are specific to the simulation
application, the Database Generation tool suite, the simulation program, thetechnology
SE Scalability which results in near-infinite SE addressability, spatial resolution
and content density in each of the SE datasets.
3D Model Library Management through built-in provisions for the cataloging ofmodelsSE Versioning Mechanism allowing instant access to prior versions andsimplified configuration management
Cooperative SE Workflow through an internal SE structure which favors teamwork. The SE workflow can be allocated by specialty (e.g., altimetry, satellite
imagery, vector data) or by geographic footprint.
Straightforward SE Archival and Recovery
Note that the use of the CDB as an off-line repository does not impose any change to thesimulation training equipment (i.e., no modifications to client-devices are required3). However,the deployment of the synthetic environment is similar to the conventional approaches used inindustry requiring the time-consuming, storage-intensive, off-line compilation of proprietaryruntime databases to each client-device. Furthermore, the computing demands on the databasegeneration facility are significantly greater because the entire database must be published off-line
for each client-device before it can be deployed. These costs rapidly escalate with thecomplexity and size of the synthetic environment, the number of supported client-devices and thenumber of supported training facilities. For complex databases, these costs can far outweigh thecosts of the runtime publishers attached to each simulator client-device.

3

Or alternately, runtime publishers need not be developed for client-devices© 2015 Open Geospatial Consortium

5

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 1-1: Use of CDB as an Off-line Database Repository

In most modern SE tool suites in-use today, the Data Preparation step shown in Figure 1-2: SE
Workflow with CDB as an Off-line Database Repository consists of many sub-steps usuallyapplied in sequence to each of the datasets (aka layers) of the SE. In effect, this aspect of themodeler’s responsibilities is virtually identical to that of a GIS4 specialist. As a result, many of
the simulation equipment vendors offer SE authoring tools that integrate best-of-breed COTS5
GIS tools into their respective tool suites. The steps include:
Format conversion: raw source data is provided to modelers in literally hundreds
of formats. Early on in the SE generation process, modelers typically settle on asingle format per SE layer (e.g., terrain altimetry, imagery, attribution)
Error handling: raw source often contains errors or anomalies that, if left
undetected, corrupt and propagate through the entire SE data preparation pipeline.
As a minimum, these errors must be detected early on in the process. Moreadvanced tools can correct many of these automatically, particularly if there issome redundancy across the layers of data.
Data geo-referencing: this is the process of assigning a unique location (latitude,
longitude and elevation) to each piece of raw data entering the SE pipeline.
Data Registration: each dataset is manipulated so that it coincides withinformation contained in the other datasets. These manipulations include
4

Geographic Information Systems

5

Commercial-Off-The-Shelf© 2015 Open Geospatial Consortium

6

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
projections, coordinate conversions, ortho-rectification, correction for lensdistortions, etc. For images, this process is also known as rectification.
Data Harmonization: the raw data of a dataset varies over a geographic extent if
it was obtained under different conditions, such as from two or more sensors withdiffering spectral sensitivity characteristics, resolution, in different seasons, under
different conditions of weather, illumination, vegetation and human activity. The
modeler must factor for these variations when selecting and assembling thedatasets into a self-coherent SE.

Figure 1-2: SE Workflow with CDB as an Off-line Database Repository

The effort expended during the Data Preparation and Modeling step is mostly independent of thetargeted simulation devices and the targeted applications. Consequently, the results of the datapreparation step can be stored into a Refined Source DataBase (RSDB) and then re-targeted atmodest cost to one or more simulation devices.
The standardization of RSDBs can greatly enhance their portability and re-usability.
Unfortunately, standardization has not been the focus of most SE authoring tool vendors nor ofsimulation equipment vendors. The CDB now offers a standardized means to capture the effort
expended during the Data Preparation and Modeling step. In effect, the CDB becomes a master
repository where refined source can be “accumulated” and managed under configuration control.

© 2015 Open Geospatial Consortium

7

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
While standardization of format/structure is essential to achieve high portability, inter-operability
and re-use, the SE content must be ideally developed so that its content is truly independent of
the training application. Therefore, we strongly recommend that the SE content of the CDB
repository be developed to be independent of the training application.
Historically, SEs were developed for a single, targeted simulation application (e.g., tacticalfighter, civil and air transport, rotary wing, or ground/urban warfare). In effect, the intended
training application played an important role in determining the RSDB content because SE
developers were constrained by the capabilities of the authoring tools and of the targeted
simulation device. Unfortunately, this tailoring of SE was performed too early during the SE
workflow and severely limited the applicability and re-use of the SE. Application tailoring canrequire either data intensification6 or data decimation7 . Note that the process of dataintensification and decimation lends themselves to computer automation and can be performed
during the off-line publishing process. In the future, we anticipate some data intensification to
be done in real-time time.
Once the SE developer has completed his work in creating the various data layers of the Refined
Source DataBase, he must off-line publish (aka “compile”) the SE into one or more devicespecific data publishing steps. As we will discuss in section 1.3.1.2, Use of CDB as a Combined
Off-line and Run-time Database Repository, the device-specific off-line compilation step can be
entirely omitted if the targeted training equipment is CDB-compliant.
While an off-line publishing approach does not offer all of the benefits described in section
1.3.1.1, it nonetheless provides an easy, low-effort, migration path to CDB. Any equipmentvendor can easily publish the RSDB into his proprietary runtime format. Firstly, the publishingprocess is facilitated by the fact that the CDB specification internally use of industry standard
formats (e.g., TIFF, JPEG, OpenFlight, and Shape). As a result, it bears much commonality withother database interchange formats. However, the CDB goes much further in that it “wraps”
these formats into a global, standardized data model suited to high-end real-time simulations.
This greatly facilitates the work of SE developers. Thus, the CDB provides a far simpler andstraightforward means of interchanging refined source data, when compared to alternatives such
as SIF, SEDRIS, OpenFlight that have partial pre-defined data models that are not sufficiently
comprehensive for use in real-time simulations.

6

Data Intensification is the process of augmenting or deriving added detail from the information found in theraw data. For instance, intensification can be used to augment flattened terrain imagery with 3D cultural detailrelief. A typical example of this consisting in populating forested areas found in the terrain imagery with individual
three-dimensional trees.
7

Data Decimation is the process of removing or simplifying the informational content found in the raw data.
For instance, decimation can be used to transform individually modeled buildings into simplified city blocks or to
reduce the resolution of terrain imagery. Data decimation is usually undertaken to ensure that the SE falls within thecapabilities of the targeted simulator system.

© 2015 Open Geospatial Consortium

8

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.3.1.2
Use of CDB as a Combined Off-line and Run-time Database Repository
A CDB can be both used an off-line repository for the database authoring tools or as an on-line(or runtime) repository for the simulators. When used as a runtime repository, the CDB offers
plug-and-play interchangeability between simulators that conform to the CDB specification.
Since the CDB can be used directly by some or all of the simulator client-devices, it isconsidered a run-time environment database.
In addition to the benefits outlined in section 1.3.1.1, Use of CDB as an Off-line Database
Repository, the use of the CDB as a combined off-line and run-time repository offers many
additional benefits, in particular:
SE Plug-and-Play Portability and Interoperability across CDB-compliant
simulators and simulator confederacies (be it tactical air, rotary, urban/ground,sea).
Reduced Mission Rehearsal Timeline by eliminating SE generation steps (off-line
publishing, database assembly and data automation
Simplified Deployment, Configuration Control and Management of Training
Facility SE Assets by eliminating the duplication of SE runtime DBs for eachsimulator and each client-device of each simulator.
Single, centralized storage system for the SE runtime repository (can be extended
to a web-enabled CDB)
Seamless integration of 3D models to the simulator.
Fair Fight/Runtime Content Correlation through the adjustment of runtime levelof-detail control limits at each client-device.
Figure 1-3: Use of CDB as an Off-line and On-line Database Repository, illustrates the CDB as
an off-line Master database repository for the tools and as an on-line Master database repository
for the training facilities. Note that the deployment of the synthetic environment to the training
facilities involves a simple copy operation. The deployment of the CDB is further simplified
through an incremental versioning scheme. Since only the differences need be stored within the
CDB, new versions can be generated and deployed efficiently.

© 2015 Open Geospatial Consortium

9

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 1-3: Use of CDB as an Off-line and On-line Database Repository

The CDB specification standardizes formats and conventions related to synthetic environments
for use in simulation. However, many additional benefits can be garnered if the CDB is also
used as an on-line database repository; this is particularly true when one considers the effort
expended in the deployment of the synthetic environment to the training and/or mission rehearsal
facilities.
When used as an on-line database repository, there is no need to store and maintain off-line
published versions of the database for each client-device (as illustrated in Figure 1-3). As aresult, the storage and computing demands on the database generation facility are significantly
lowered. This is especially true of database generation facilities whose mandate involves thegeneration of complex synthetic environments for use by several training facilities.
Figure 1-1: Use of CDB as an Off-line Database Repository, illustrates the simplified databasegeneration workflow resulting from a CDB that is used as both an offline and a runtime SE
repository.

© 2015 Open Geospatial Consortium

10

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 1-4: SE Workflow with CDB as Combined Off-line/Runtime Database Repository

This approach permits the CDB representation of the synthetic environment to be “dissociated”
from the resolution, fidelity, precision, structure and format imposed by the internals of clientdevices. Compliancy to the CDB specification can be achieved either by modification of theclient-device internal software to make it CDB-native or by inserting a runtime publishingprocess that transforms the CDB data into the client-device’s legacy native runtime format. In
the later case, this process is done in real-time, on a demand-basis, as the simulator “flies” within
the synthetic environment. Note that since the simulated own-ship moves at speeds that arebounded by the capabilities of the simulated vehicle, it is not necessary to instantly publish theentire synthetic environment before undertaking a training exercise; the runtime publishers need
only respond to the demands of the client-devices. When the simulated own-ship’s position is
static, runtime publishers go idle. As the own-ship starts advancing, client-devices start
demanding for new regions, and runtime publishers resume the publishing process. Publishingworkload peaks at high-speed over highly resolved areas of the synthetic environment.
Note that virtually all simulation client-devices in existence today natively ingest proprietarynative runtime formats. As a result, a runtime publisher is required to transform the CDB data
into legacy client device’s native runtime format. The runtime publishing process is performed
when the CDB is paged-in from the CDB storage device. Appendix A of the CDB Specification
provides a set of guidelines regarding the implementation of Runtime Publishers.

© 2015 Open Geospatial Consortium

11

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.3.2
What the CDB Specification Is Not
The representation and sharing of synthetic environment data plays a key role in theinteroperation of systems and applications that use such data. In the mid to late 90’s somespecifications/standards were conceived to provide a means of sharing synthetic environment
data, in source form, for a wide variety of applications. They provided a standardized means toshare native databases, thereby avoiding direct and (often inefficient) conversion of the data
to/from (often proprietary) native database format. Their mandate was about:
1. providing a representation of synthetic environment data for the modeling andsimulation field; and2. providing the means to freely interchange synthetic environment datasets.
Such Specifications addressed the interchange of data, representing thesimulated natural environment, in advance of the runtime use.
The CDB Specification, on the other hand, is primarily intended as a distributed simulator
runtime synthetic environment database Specification. It is a Specification optimized for
distributed simulation applications that require very large synthetic environment databases foruse in high-end simulation, mission planning/rehearsal. The CDB Specification datasets extend
the simulation beyond just “classic out-the-window” visualization since it supports thesimulation of sensors, such as FLIR, NVG, Radar and other simulation subsystems such as
Computer Generated Forces and NAVAIDS.
The CDB Specification concerns itself with the modeled data representation and attribution ofterrain, objects and entities within the synthetic environment. However, it does not concern itself
with the movement, change in shape, physical properties and/or behavior of such objects andentities; this falls under the domain of synthetic environment simulations.
The CDB Specification does not concern itself with representations of celestial bodies (such as
the Sun, Moon, stars, and planets). Rather, it assumes that the modeled representation (e.g., theSun/Moon disk representation in an IG) of celestial bodies is internally held within theappropriate simulator client-devices.
Due to its real time vocation, the CDB Specification limits the number of units of measure foreach physical quantity. For instance, all terrain surface coordinates are represented in lat-longwhile all other distances are in meters. This is in stark contrast to DB interchange standards,
which permits a large set of units for each physical quantity (for example distance can be
expressed in feet, meters, miles, parsecs, light-years, nautical miles, inverse-meters, angstroms,
microns).
The CDB Specification provides a high degree of flexibility in setting content. There is no
mandatory “coverage completeness requirement” imposed by the CDB Specification. Thispermits the generation of a CDB even when a database modeler is confronted with limited data
availability. It is understood however, that a CDB that is minimally populated will be of limited
value to many simulation applications. Hence, the applicability of any CDB is clearly related to
the richness, quality and resolution of its content. It is anticipated that additional standardization
will be required to prescribe content appropriate to targeted simulation applications. In its© 2015 Open Geospatial Consortium

12

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
current form, the CDB Specification does not mandate on synthetic environmental richness,quality and resolution.
Given the mandate of the CDB Specification to be platform independent, it cannot provide theimplementation details of specific off-line database compilers or runtime publishers attached to
specific client-devices. Furthermore, since there is no standardization of the SE representationinternal to client-devices (they vary by type8, by vendors), it is unlikely that such information
would completely satisfy the interests of all developers. More importantly, the structure andformat of synthetic environment data ingested by each client-device is typically proprietary; as aresult, it is impossible to fully describe the effort required to develop CDB off-line compilers
and/or CDB runtime publishers.
1.3.3
What is a CDB
A CDB corresponds to a static synthetic representation of the whole earth; it is geographicallydivided of into geodetic tiles (bound by latitudes and longitudes), each containing one or more
specific sets of features. It uses the WGS-84 earth model to provide geodetic interoperability.
Each of the simulator client-devices accesses the CDB geospecific information using the WGS84 geodetic coordinate system.
A CDB contains the features and modeled representation of the synthetic environment. It
contains terrain altimetry; its raster imagery, its attribution as well as 3D feature with theirmodeled geometry, texture and attribution. The Specification also makes provision for the
representation of moving models. The representation of moving models is comprehensive andgoes well beyond other visualization standards because it makes provisions for the standardized
simulator naming conventions, material and feature attribution, radar/laser reflectivity, aircraft
and airport lighting systems, armaments, special effects, collision points/volumes just to name afew.
The Specification governs all aspects of the CDB, as follows:Z
Data content and representation of the synthetic environment
Z
Structure and organization of the synthetic environment
Z
File format of the synthetic environment as stored on media
The CDB Specification describes a modeled synthetic environment representation for distributed
simulation applications. Section 1.6.5, Use of CDB in Applications Requiring Dynamic
Synthetic Environments discusses how a CDB-compliant simulator could be adapted to handle
modifications of the synthetic environment in real-time.
Given the CDB’s structured representation and attribution of terrain, objects and entities, it is
now possible to design a broad range of synthetic environment simulations that modify synthetic
environments in real-time. Such simulations can modify the CDB and notify their changes to theother simulation federate that share a CDB. This provides a synthetic environment that is
persistent and fully correlated across all simulation federates. For example, terrain trafficability
8

It is precisely the intent of the CDB Specification to provide such standardization.

© 2015 Open Geospatial Consortium

13

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
could be handled by a new SE simulation that dynamically calculates soil moisture content as afunction of localized rain precipitation and soil types/composition. A second simulation would
then derive the resulting soil physics and determine vehicle wheel slippage across the varying
terrain conditions.
The modification/notification approach is well-suited for a broad gamut of SE simulations;however, some simulations are very data intensive and would require excessive broadcasting
bandwidths to other federates. In such cases, these dynamic simulations would have to be
replicated in the other client-devices of the federation. Good examples of this are visual system
special effects (e.g., rotor downwash effect, missile plumes, muzzle flashes, cast landing lights);
typically such simulations are proprietary and intrinsic to the client-devices. Other examples ofthis include the varying effects of weather9 (local winds, temperature, humidity, particulates,etc.) and oceans (currents, temperature, etc.).
1.4
Key Features and Characteristics of the CDB Specification
The following paragraphs provide an overview of key features and characteristics of the CDB
Specification.
1.4.1
Synthetic environment Database for Simulation Applications
The CDB Specification is a simulator-level synthetic environment database Specification for use
in real-time. The Specification is open, platform-independent and client-device independent.
The Specification defines all aspects of data representation and organization, and storage
structure necessary to support full-mission real-time simulation. The CDB Specification
synthetic environment databases contain datasets that represent the features of a synthetic
environment for the purposes of simulation applications. The CDB provides a time-invariant
synthetic environment representation of the earth, composed as terrain, natural/man-madefeatures and moving models for use by SE authoring tools and simulators.
1.4.2
Logical Addressability
The CDB Specification provides for near-infinite addressability. The amount of information
associated with a CDB is limited only by available disk storage. The CDB Specification allows
for a nearly infinite number of identifiers within a single CDB. Addressability is not expected to
be a limiting factor even if we assume a yearly doubling of storage capacity.
1.4.3
High Spatial Resolution and Scalability
The CDB Specification provides for near-infinite resolution due its organization of data in
LODs. The CDB Specification grid-organized data (e.g., elevation, ground raster imagery,ground properties) is structured into an LOD hierarchy consisting of up to 34 LODs. Gridorganized data can be represented to a resolution of 13 microns.
9Time-varying weather simulation effects could be simulated by a “weather server” simulation subsystem
which in turn can rely on the terrain elevation and terrain material datasets to perform its simulation of weather inreal-time.

© 2015 Open Geospatial Consortium

14

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The CDB Specification also provides for near-infinite cultural content. The CDB Specificationfor vector data (3D point, lineal and areal features) is also structured into a LOD hierarchy
consisting of up to 34 LODs. At the finest possible LOD, a CDB can contain in excess of 100
million cultural features per square meter.
The CDB Specification permits each geographic area to be modeled at a distinct LOD in
accordance to the availability of source data. Since this capability is provided at a tile-level, it isstorage-efficient.
1.4.4
Earth Geodetic Spatial Representation Model
Geo-referenced data constitute a major aspect of the CDB Specification synthetic environment
data. It uses a geographic coordinate representation (WGS-84 lat/long, elevation) for the earth’s
terrain surfaces and ocean floor. Furthermore, natural and man-made objects are positioned andoriented using geodetic coordinates. The CDB Specification provides geodetic coverage for theentire earth.
1.4.5
Tile/Layer/Level-of-Detail Structure
The CDB Specification offers a structure that is well suited for the efficient access of its
contents. To this end, it relies on three important means to organize the synthetic environment
data:
Z
Z
Z

Tiles
LayersLevel-of-Detail (LOD)

1.4.5.1
Tiles
The CDB Specification relies on a top-level tile structure designed to organize the data for
efficient access in real-time. The tile structure provides an effective means for simulator clientdevices to access the datasets of a geographical area at a selected LOD. Since the spatial
dimension of tiles varies inversely with LOD (i.e., resolution), client-devices can readily predict
the amount of data contained within the tile; as a result, the management of memory withinclient-devices is simplified and much more deterministic.
The CDB Specification Data Representation Model (DRM) is logically organized as a strip of
geo-unit aligned tiles along each earth slice. Each earth slice is divided into a decreasing numberof tiles to account for the fact that the length of an earth slice decreases with increasing latitude.
1.4.5.2
LayersThe CDB Specification DRM is also logically organized as distinct layers of information. The
layers are theoretically independent from each other, (i.e., changes in one layer do not imposechanges in other layers).
Layers are additive in fidelity, (i.e., the achievable level of the simulation fidelity increases with
the number of layers).

© 2015 Open Geospatial Consortium

15

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Secondly, unavailable layers are automatically defaulted. A database modeler need not fully
populate the CDB. There is no mandatory “coverage completeness requirement” imposed by the
CDB Specification. This feature permits the generation of a CDB even when database modelers
are confronted with limited data availability. The usefulness/faithfulness of the synthetic
environment increases with the number of available layers.
The layering mechanism improves the efficiency of the client-devices since they need only
access (and be aware) of the datasets that are relevant to them, at their prescribed level offidelity. For instance, a simulator CGF client-device will not likely have a reason to use groundraster imagery; however, it is quite likely interested in accessing ground surface properties when
determining traffic-ability.
1.4.5.3
Levels-of-Detail
The availability of LOD representations is critical to real-time performance, especially when
dealing with grid-organized data. Most simulation client-devices can readily take advantage ofan LOD structure because, in many cases, less detail/information is necessary at increasing
distances from the simulated own-ship. As a result, many client-devices can reduce (by 100-foldor more) the required bandwidth to access synthetic environment data in real-time.
Additionally, the availability of LODs can be readily exploited by simulator client-devices toimprove their algorithmic efficiency. Devices such as Image Generators (IGs) can readily takeadvantage of an LOD structure because image perspective naturally reduces image detail with
distance as a result of the perspective computation inherent to the IG; as a result, much lessgeometric detail and texture detail need be processed or considered at far range.
The spatial sampling pitch of each successive LOD follows power of two progressions; this is a
pre-requisite for the efficient and deterministic management of memory by all client-devices of atypical simulator.
The terrain LOD can be controlled to the tile level. Since the CDB Specification supports avariable LOD hierarchy spanning up to 34 levels, it is possible to control the allocation of LODs
by area. The variable LOD hierarchy provides for efficient use of storage because the LOD
hierarchy needs to be deepened only in the areas where higher resolution is desired. Figure 1-5:
Variable Allocation of LOD, illustrates an earth strip made up of a series of tiles; some portionsof the strip have been modeled with 3, 4, or 5 LODs according to the application requirements.
1.4.6
Platform Independence
The constraints imposed by the CDB Specification are minimal and are designed to allow its
implementation on any of the widely available computer hardware platforms, operating systems,
file systems and transport protocols.
On CDB-compliant simulator client-devices10, any CDB can run “as-is” without the traditional
off-line compilation step. This allows the simulation user community to freely exchange CDBs
10

A CDB-compliant client-device is a client-device that inputs synthetic environment data that conforms to theformat, structure and conventions of this Specification. Any client-device that does not natively conform to this© 2015 Open Geospatial Consortium

16

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
across simulators either through the exchange of physical media (or entire storage subsystems) or
via network. As a result, a CDB can run without change regardless of the computer platforms,
simulator system software and simulator client-devices. While the CDB Specification does not
explicitly mandate the use of specific computer platforms and system software, it does however
specify a set of minimum criteria as listed below.

Figure 1-5: Variable Allocation of LOD

1.4.6.1
System Software Independence
The following paragraphs explain the various software requirements.

Specification must reformat and restructure the CDB data to the device’s native format/structure through the use of aruntime publisher. A client-device need not input all of the CDB datasets and attributes to be CDB-compliant.

© 2015 Open Geospatial Consortium

17

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.4.6.1.1 File System
The CDB Specification is file system independent, (i.e., it does not mandate the use of a specificfile system). However, compliance to the CDB Specification does require that the file system beable to support a minimal set of capabilities. All modern file systems in use today conform to
the minimal set of capabilities described in Section 2.2, File System File Naming Conventions.
1.4.6.1.2 Operating System
The CDB Specification is Operating System (OS) independent; it does not mandate the use of a
specific OS. However, compliance to the Specification does require that the operating system beable to support a minimal set of capabilities. All modern operating systems in use today conformto the minimal set of capabilities listed below. This includes Windows32, NT, UNIX, Linux,
IRIX, Solaris, etc.
The CDB Specification assumes that the operating system supports, as a minimum, thefollowing:
1.
2.
3.
4.
5.
6.
7.

Byte-stream random file access
32-bit integers, natively
A 32-bit address space
Floating point support (per IEEE-754), natively
2GB virtual address space per process
Memory paging
Network communication

1.4.6.1.3 Transport Protocols
The CDB Specification is transport protocol-independent; it does not mandate the use of specifictransport protocols. Furthermore, the Specification does not explicitly rely on or specify any
transport protocols.
1.4.6.2
System Hardware Independence
The CDB Specification is hardware independent; it does not mandate the use of particular
hardware platforms. Furthermore, any general-purpose hardware compatible with modern
Operating Systems (OS) can be used for a CDB Specification implementation11.
The CDB Specification assumes that the system hardware supports, as a minimum, thesubsystems described in the following sections.

11

The CDB Specification internally uses conventional “atomic” data types, namely signed/unsigned n-byte
quantities, ASCII strings, IEEE-754 floats (single/double). While it is theoretically possible to build a CDB
Specification-compliant software implementation on a processor platform that does not explicitly support theseatomic types, it is clear that such implementation would be inefficient.

© 2015 Open Geospatial Consortium

18

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.4.6.2.1 Processor/Memory
The CDB Specification is processor-independent; it does not mandate the use of a specificprocessor type. However, compliance to the CDB Specification does require that the processor
be able to support a minimal set of capabilities. All modern processor systems in use today
conform to the stated minimal set of capabilities listed below. This includes processors such as
the Pentium, XEON, Celeron, Duron, Athlon, MIPS, and PowerPC. The CDB Specification
does not impose requirements on hardware/memory over and above those mandated by thecommonly available OS; as a minimum, the CDB Specification itself requires support for:
1.
2.
3.
4.
5.
6.

8-bit, 16-bit, and 32-bit signed and unsigned integers, natively
A 32-bit address space
32-bit and 64-bit double precision floating point values (IEEE-754), natively
2 GB virtual address space
Virtual memory space
Immediate and indirect memory addressing modes

1.4.6.2.2 Storage Subsystem
The CDB Specification does not impose requirements on the storage subsystem other than thosemandated by the selected OS and the selected file system. As a minimum, it must be able tosupport file system as previously specified. An empty CDB requires very little in terms ofstorage; it will likely fit on a few diskettes or a single CD. However, a typical CDB is expected
to range from hundreds of Mbytes to hundreds of Tbytes.
1.4.6.2.3 IO Subsystem
The CDB Specification does not impose requirements on its IO subsystem other than thosemandated by the selected OS, specifically:
1. Disk I/O subsystem
2. Network I/O subsystems
1.4.6.2.4 Client-Device Independence
The CDB Specification is client-device independent; it caters to the collective needs of all clientdevices likely encountered on a tactical mission simulator; the Specification itself is completely
independent of any vendor-specific devices.
NOTE:

Each client-device is matched either to an off-line compiler or to a runtime
publisher. In the runtime case, the runtime publisher transforms this data
into the client-device’s legacy native data format and structures the CDB
synthetic environment data as it is paged-in by its client-device.
Regardless of its use as an off-line or on-line repository, the CDB
eliminates all client-format dependencies. Alternately, the client-device
may be designed / modified to be CDB-native, in which case a separate
runtime publisher is not required. Note that the CDB Specification makes
use of data types commonly available in standard computer platforms© 2015 Open Geospatial Consortium

19

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
(floats, integers, etc.). While it would be theoretically possible to cater toa client-device that does not support the CDB Specification “atomic” datatypes, it would unduly load the attached on-line publisher. As a result, it
is recommended that all client-devices provide hardware support for the
CDB atomic data types.
The CDB Specification limits its scope to synthetic representations of the earth; its internal datais organized and optimized to reflect its intended use in simulation applications. The concept ofan earth model and the means to represent earth surface regions with associated cultural features
figure prominently within the Specification because they are important to the targeted CDB
applications12.
Since it is the client-devices that initiate access to the CDB, they must each be theoretically“aware” of at least the geodetic earth model. Otherwise, the contents and the structure of the
CDB can be completely abstracted from the client-device. The runtime publishers provide thenecessary level of abstraction. The level of abstraction provided by the publishers is purely afunction of the selected implementation of the client-device and its associated publishers. It is
entirely acceptable, for the client-device to understand and to be completely “aware” of the CDB
as it is defined by the CDB Specification. In this case, such a device would not require a runtime
publisher, because it is already CDB-native.
The runtime publishers bridge the gap between the information content requested by the attachedclient-device and the information content and structure available to them in the CDB. As aresult, the runtime publishers must each be theoretically “aware” of the following CDB concepts:
1. Tile:Ability to understand the concept of earth surface areas hierarchicallysubdivided in accordance to the CDB Specification
2. Level of detail:Ability to understand the concept of resolution or level-of-detail, for terrain,cultural vector data, raster imagery, and model geometry
3. Terrain surface representation:
Ability to understand concepts pertinent to earth surface geometry andattribution
4. Cultural vector data (point, linear, areal):
Ability to understand the concept of point, linear and areal cultural data andrelated attribution, fixed or conformed to earth surface
5. Grid-organized data and meshes:
Ability to understand the concept of grid-organized single-value datasets (e.g.,
elevation grid) and multi-value datasets (e.g., color triplets)
12

Conversely, the Specification is not optimized to represent CAD/CAE data for use in manufacturing.

© 2015 Open Geospatial Consortium

20

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6. Imagery:
Ability to understand the concept color raster imagery mapped onto terrain
surfaces or models
7. Model geometry (incl. light points):
Ability to understand the concept of general surface geometry
8. Model positioning capability:
Ability to differentiate between statically and dynamically positioned models
9. Descriptive attribution:
Ability to understand the attribution concepts pertinent to the client-device
1.4.7
Synthetic Environment Scalability & Adaptability
The concept of scalability when applied to synthetic environments not only applies to thegeographic extent of the database but more importantly, it also reflects the ability to scale theenvironment in resolution and fidelity. These concepts are fully supported by the CDB
Specification and are explained below:
1. Geographic extent:
Correspond to the range of geographic extent of the earth surface that can bemodeled.
2. Resolution:
Correspond to the range of information density (for instance, the number of
elevation values per km2) of the modeled datasets.
3. Fidelity:
Correspond to the amount and type of synthetic environment data that can bemodeled to support higher-fidelity simulator client-devices13. Consider for
instance a simulator capable of supporting a single-surface earth skinrepresentation versus one capable of representing tunnels, bathymetric data,
location-dependent tide heights, location-dependent wave heights, etc.
Clearly, the amount of information required by the higher-fidelity simulator isgreater.
4. Precision:
13

The CDB Specification supports this concept through two mechanisms:

Data defaulting: The CDB Specification is tolerant to missing data, because all attributes, layers anddatasets have Specification default behaviors. As more of the data is provided, the fidelity of the environmental
database increases.
Additive layering: The CDB Specification offers a layered environment database organization. The layer
organization is “fidelity-ordered”, (i.e., basic layers appear first in the hierarchy while the layers needed for a higherfidelity simulation appear later in the hierarchy).

© 2015 Open Geospatial Consortium

21

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Correspond to the range of numerical precision (i.e., number of bits allocatedto represent a quantity) of the modeled datasets.
Today, modelers face difficult challenges if they want a synthetic environment that is both
scalable and adaptive. The solution to this difficult issue extends beyond the “mechanics” ofachieving backward/forward compatibility; it also requires a complete “dissociation” of thedatabase from any of the constraints imposed by the client-devices. It is current practice today
for modelers to repeatedly adjust the content, resolution and density of synthetic environment
databases to closely match the capabilities and performance of the targeted client-devices. When
content is added to the database, previously modeled content is usually removed or simplified.
Under such constraints, it is difficult for a modeler to build a synthetic environment databasecapable of meeting anything but its immediate requirements.
Figure 1-6: Typical Evolution of a Database shows the typical evolution of a modeled region foruse in a mission rehearsal. The initial version of the region may have only a few highresolution/high-fidelity areas; however, over a given time period, modelers will be asked tomodel additional target areas. As a result, the size, complexity, resolution and fidelity of thesynthetic environment database gradually increase. Without built-in provisions for scalability,
significant rework of the database is required each time a target area is added.

Figure 1-6: Typical Evolution of a Database

The CDB Specification, on the other hand, offers a new paradigm: the “dissociation” of thesynthetic environment database’s extent, resolution, fidelity, precision, structure and format fromits client-devices. This concept is not limited to aspects of formatting, numerical representation,internal structure, file structure, file systems, etc. More importantly, the concept also covers
aspects relating to synthetic environment database fidelity and resolution. Historically, thefidelity and resolution of synthetic environment databases has been intimately linked to thecapabilities of the targeted simulator client-devices. More often than not, the source data wasmanipulated and adapted to constraints imposed by the client-devices. As a result, the content,
resolution and density of synthetic environment databases were repeatedly adjusted to closely
match the capabilities and performance of the targeted client-devices. The amount of time
devoted to repeatedly adding/editing/removing content, and then repeatedly re-publishing would
largely exceed the effort of creating and building the original synthetic environment database.
The CDB Specification offers the means to break this inter-dependence.

© 2015 Open Geospatial Consortium

22

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
When assembling a CDB, the synthetic environment database modeler is permitted (within theirtime-cost budget) to include content that significantly exceeds the capabilities of theirsimulator(s). The job of “adjusting” content to client-devices is relegated to the runtime
publishers; the modeler is freed from this labor-intensive, repetitive task.
In a typical CDB Specification implementation, it is anticipated that client-devices will
independently control their respective runtime publishers so that the runtime published synthetic
environment corresponds to their inherent capabilities (resolution, fidelity, etc.).
Nonetheless, the runtime publishing paradigm offers interesting new possibilities. For instance,
it would be possible to individually adjust the fidelity and resolution of the synthetic
environment for each client-device; this adjustment could be done at any time. As a result, it ispossible to control and adjust the overall simulator fidelity and correlation to a level that waspreviously unachievable.
1.4.8
Platform Scalability
The CDB Specification does not enforce a particular computer hardware infrastructure. The
selected infrastructure allocated to the handling of the CDB is largely determined by the overallsimulation requirements. Any leeway the simulator architect may have at their disposal when
trading-off various simulator performance parameters against each other, are as follows:
1. Geographic extent
2. SE/Simulator Resolution
3. SE/Simulator Fidelity
4. SE/Simulator Precision
5. Desired level of client-devices correlation
6. Client-level SE load management
7. Simulated aircraft speed
8. CDB sharing
An experienced simulation engineer can typically undertake this analysis; however, the process
requires a good understanding of the content available in the targeted CDB(s) and of the content
each client-device needs in order to meet its stated level of performance and fidelity. If for costconsiderations the system engineer is unable to reconcile both, he can relax or trade-off some of
the above parameters.
Alternately, it is possible to implement a simulator with client-devices (or attached publishers)
that are capable of automatically adjusting resolution and fidelity in order to overcome
performance limitations attributable to the CDB storage infrastructure and/or runtime publishers.
Figure 1-7: Typical Implementation of CDB Specification on High-end Simulator, below is asystem block diagram of a typical implementation of the CDB Specification on a high-end
tactical flight simulator. The runtime CDB system serves the combined needs of a missionfunctions computer, an OTW/NVG IG, a FLIR IG, Radar and a CGF subsystem equipped with
its own terrain server. The runtime CDB system is scaled to reflect the collective capabilities of
the attached client-devices; as a result, the storage system is configured to supply the necessary© 2015 Open Geospatial Consortium

23

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
bandwidth. Similarly, the IO bandwidth of the CDB servers and processing performance of theruntime publishers are scaled to satisfy the demands of their respective client-devices.

Figure 1-7: Typical Implementation of CDB Specification on High-end Simulator

Figure 1-8: Typical Implementation of CDB Specification on Desktop Computer, below shows amodest application of the CDB Specification; it consists of a single desktop computer equippedwith both stealth viewer and radar simulation application software. Each application is frontended by a runtime publisher that in turn interfaces to the CDB via a standard file system. Given
the more modest platform resources, some trade-offs in either resolution or fidelity might berequired. This can be implemented in the runtime publisher or in the client-device application
software.

© 2015 Open Geospatial Consortium

24

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 1-8: Typical Implementation of CDB Specification on Desktop Computer

1.4.9
Simulator Wide Unique Data Representation, Data Normalization
A CDB is a single repository for the entire simulator’s synthetic environment DB. The CDB’s
internal structure ensures that all datasets are uniquely represented yet available (through apublishing process) to each of the simulator client-devices at runtime. This paradigm eliminates
the extensive duplication of datasets that are shared by two or more client-devices.
The CDB Specification is technically a normalized data model in the sense that it best meets thelogical data design objectives of correctness, consistency, simplicity, non-redundancy andstability. Ignoring any tailoring or tuning for particular application requirements or performance,a normalized design provides the following advantages:
1. Minimize amount of space required to store data:
Normalization precludes storing data items in multiple places.
2. Minimize risk of data inconsistencies within the database:Since datasets are stored in only one place, there is no risk of datasets
becoming inconsistent (uncorrelated).
3. Minimize possible update and delete anomalies:
A normalized CDB eliminates the concerns related to update or delete
operations.
4. Maximize the stability of the data structure:
The process of normalization helps in associating attributes with entities based© 2015 Open Geospatial Consortium

25

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
on the inherent properties of the data rather than on particular application
requirements. Thus, new application requirements are less likely to forcechanges on the CDB Specification database design.
1.4.10Compression of Storage Intensive Imagery Datasets
The CDB Specification prescribes the use of an industry standard compression algorithm for its
storage intensive raster imagery datasets. This not only provides a substantial reduction instorage, but also reduces the data transmission bandwidths associated with simulator’s access tothe synthetic environment database at runtime. As a result of its storage efficiency, the CDB
Specification relies on relatively few data formats for storing its datasets; there is no benefit(other than storage efficiency) to be gained in supporting any other specialized data formats
whose underlying objective is only for storage efficiency. The CDB Specification embodies the
JPEG 2000 industry standard format for raster imagery because it has comparable storage
efficiency to all of these image formats without sacrificing any generality. JPEG 2000 has beenchosen by the CDB Specification as a format for the storage of OTW raster imagery because of
the following characteristics:
1. High compression efficiency:
Compression better than 0.25 bits per pixels. Virtually indiscernible loss inimage quality for 10:1 – 20:1 compression.
2. Lossless and lossy compression:
Lossless compression ratios approx. 1.7:1
3. Perceptual color space internal coding:
Allow dark images to be reconstructed without banding artifacts.
4. High dynamic range:
Compress and decompress images with various dynamic ranges (e.g., 1-bit to
16-bit) for each color component.
5. Large images sizes:
Up to (2^32 - 1)
There are other characteristics of the JPEG 2000 that are worth mentioning but are not directly
beneficial to the CDB Specification. Those are:
1. Progressive image reconstruction:
Allow images to be reconstructed with increasing pixel accuracy andresolution.
2. Region of interest coding:
Permits certain Region of Interest (ROI’s) in the image to be coded andtransmitted with better quality and less distortion than the rest of the image.
3. Seamless quality and resolution scalability:
Without having to download the entire file
4. Error resilience during transfers.

© 2015 Open Geospatial Consortium

26

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
JPEG 2000 will be solely targeted at Raster Imagery data only. The reason is simply because of
its highly efficient compression scheme that fits well with the goal of reducing the huge datasets
associated with Imagery. Other raster-based datasets defined in the CDB will solely be using the
TIFF format due to their more manageable size.
1.4.11
Compression of other Raster Datasets
In general, all TIFF/GeoTIFF files benefit from LZW compression when their content is not oftype floating-point. For this reason, and as a general practice, the CDB Specification
recommends the compression of all TIFF-based raster datasets containing integer values.
1.5
Key Benefits of the CDB Specification
The following outline the key benefits of using the CDB Specification.
1.5.1
Improved Synthetic environment DB Generation Timeline
Important reductions in both the DB generation and DB update timeline are expected from the
CDB Specification because:
1. There is no need to compile distinct synthetic environment runtime databasesfor each of the simulator client-devices.
2. All of the datasets common to two of more client-devices need not be
duplicated. All associated client-specific structures are also eliminated.
3. Tiles and layers are technically independent from each other; as a result, there
is no need to reprocess neighboring tiles and coincident layers. However, one
exception to this relates to the level-of-detail generation.
4. The CDB Specification tile structure permits users to “pipeline” or overlap the
DB creation/update process, see Figure 1-9: Pipelined DB Update Process,with DB transfer process14.

Figure 1-9: Pipelined DB Update Process

5. The CDB Specification tile structure lends itself naturally to the concurrent or“parallel” production of the CDB.

14

Assuming the DB toolset (used by the modelers at the DB Generation Facility) allow its users to manipulate
Environmental DB content on a small-area basis.

© 2015 Open Geospatial Consortium

27

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6. The CDB Specification internal versioning mechanism lends itself well to
CDB updates because only the affected tiles or layers need be re-transmitted
to the simulator. This represents a significant timesaving, especially in cases
where small updates are constantly applied to a comparatively large CDB.
7. The conversion of the synthetic environment from its tool-native
representation into a form directly entered by each of the simulator clientdevices is broken down into several publishings accomplished in real-time on
behalf of each of client-device. This approach permits the CDB Specification
representation of the synthetic environment to be “dissociated” from theresolution, fidelity, precision, structure and format imposed by each clientdevices. Collectively, the runtime publishers handle the more complex
portion of the workload; they transform the CDB data into a form that isingested on-the-fly by the client-device. This process is done in real-time, on
a demand-basis, as the simulator progresses within the synthetic environment.
Since there is one publisher for each of the client-device, the publishingworkload is typically distributed across several computer platforms.
Furthermore, since the simulated own-ship moves at speeds that are boundedby the capabilities of the simulated vehicle, it is not necessary to instantly
publish the entire synthetic environment before undertaking a training
exercise; the runtime publishers need only respond to the demands of theclient-devices. When the simulated own-ship’s position is static, runtime
publishers go idle. As the own-ship starts advancing, client-devices start
demanding for new regions, and publishers resume the publishing process.
Publishing workload peaks at high-speed over highly resolved areas of thesynthetic environment.
1.5.2
Interoperable Simulation-Ready Synthetic environment DB
A CDB-compliant database CDB is a fully interoperable, simulator-ready synthetic environment
DB, (i.e., it can be used “as-is” on any CDB-compliant simulator). Because the CDB is free ofany simulator dependencies, there is no need to undertake a time-consuming and expensive
rework of the runtime database(s) in order to adapt it (them) to the format, structure, content, andprecision constraints imposed by the simulator.
1.5.3
Improved Client-device Robustness/Determinism
The CDB Specification tile organization provides the means to implement deterministic loading
and/or paging of the CDB because each tile corresponds to the same amount of data (i.e., a“quanta” of information called a LOD-tile), regardless of its position on earth and regardless of
its assigned LOD. This is a key characteristic of the CDB Specification and is necessary toensure deterministic operation of client-devices, even when the CDB’s resolution varies
considerably from region to region or when the CDB is modeled at an extremely high-resolution.
It is quite straightforward for a client-device to determine the amount of memory it must locallyallocate when loading (or paging-in) a geographical area of interest. If the geographical area ofinterest exceeds the client-device’s capabilities, it can easily revert to a coarser LOD, hence© 2015 Open Geospatial Consortium

28

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
gracefully degrading, as opposed to aborting (due to an internal failure in allocating sufficient
memory) or “skipping” over the offending area.
Consider for instance, a CDB modeled to a background area terrain texture resolution of 10 m,
and a target area modeled to a resolution of 1cm. The target area holds 1,000,000 fold more data
per unit of geographic area than the background area. Furthermore, assume that the client-device
is not designed to take advantage of the CDB LOD tile structure, i.e., it always loads or pages its
data as fixed-dimension (geographically speaking) areas. Upon requesting a fixed-dimension
portion within the target area, the client-device would receive 1,000,000 fold more data than in
the background area. Clearly, such a device would require an enormous amount of physicalmemory to alleviate such a variation in resolution. The CDB Specification offers a moremanageable alternative because the CDB is allocated into fixed-sized LOD tiles. Hence, theclient-device’s paging manager can first break down the requested area into tiles at the requested
LOD; from this, the paging manager can easily predict the amount of storage needed to hold therequested area in memory; if it exceeds the client-device capabilities the client-device can revert
to a coarser LOD.
The CDB tile organization lends itself to robust, deterministic management of memory withinclient-devices because memory can be allocated/de-allocated in fixed sized quantities. As aresult, client-devices need not concern themselves with complex and non-deterministic memory
de-fragmentation schemes that do not lend themselves to real-time applications.
1.5.4
Runtime-Adjustable Synthetic Environment DB Correlation and Fidelity
The CDB Specification plays a critical role in improving the internal correlation of a synthetic
environment because it eliminates the replication of runtime databases for each of the clientdevices. The prior art in simulation mandated replicated copies of the synthetic environment
database; each were constrained to content, formats, and structures specific to each client-device.
As a result, the potential for correlation errors abounded. The CDB Specification resolves thisby defining a single, usable in real-time, open, synthetic environment database representation.
The CDB “runtime publishing” paradigm now permits the simulator vendor the means to not
only control client-device load but to globally re-examine and control the level of correlation
within a simulator (or across simulators). While the CDB Specification does not provide explicit
jurisdiction over the implementation of this mechanism in the client-devices and/or publishers, it
is nonetheless possible to improve parametric correlation, at runtime, via control of the clientdevices/publishers.
This topic is discussed in more detail in Section 1.6.6, Synthetic Environment Database
Correlation.
1.5.5
Increased Synthetic Environment DB Longevity
The longevity of synthetic environment databases for use in simulation has traditionally been asource of considerable aggravation within the user-community.

© 2015 Open Geospatial Consortium

29

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
At the source-level, the issue was partially resolved through the inception of standards such as
SEDRIS SIF. These standards largely isolated the synthetic environment source data from thetools and platforms. As a result, source-level synthetic environment databases are no longer
subject to obsolescence when vendors abandon a tool/platform. The advent of suchSpecifications permitted the modeler to abstract the source-level synthetic environment databasefrom the tools and platforms that are used to create the synthetic environment database.
While this is a step in the right direction, it must be realized that a considerable level of effort(both human and machine) is required to adapt source-level data to a form that is directly usableby each of the simulator client-devices, also known as the runtime-level vendor-specific databaseformat; this is referred to as the “compilation” process. More often than not, the source data is
manipulated and adapted to constraints imposed by one or more simulator client-devices. In
most cases, the content, resolution and density of synthetic environment databases are repeatedly
adjusted to closely match the capabilities and performance of the targeted client-devices. While
it is true that the native tool format database remains independent of the targeted client-devices,
it is clear that content of the source-level database roughly corresponds to the capabilities of thethen-current client-devices. As a result, source-level databases become quickly outdated and do
require a complete rebuild to take advantage of new simulator capabilities.
The CDB Specification avoids these pitfalls because the CDB need not be adapted to theconstraints imposed by simulator client-devices; that role is relegated to the runtime publishers.
Hence, the synthetic environment database can be built, right from the start, to a level of fidelity
commensurate with the anticipated useful life of the targeted simulator(s).
1.5.6
Reduced Synthetic Environment DB Storage Infrastructure Cost
For equivalent synthetic environment DB content, the CDB Specification offers a significant
storage space savings and significant reductions in the required interconnect infrastructure tosupply the synthetic environment DB to the simulator(s).
The reduction in equipment and labor can be attributed to the following CDB features:
1. Simulator-wide unique data representation: eliminate duplication of datasets
across client-devices.
2. Compression of storage-intensive datasets: provides effective compression of
key datasets.
3. Fine-grain versioning:
CDB is internally versioned. It is possible to revert to prior representations of
the SE without restoring stored back-ups of the CDB. Because the underlying
mechanism is fine-grained, only in affected geographic areas or datasets of the
CDB need to be versioned.
1.6
CDB Primer
The following paragraphs provide the description and focus of the CDB Specification.

© 2015 Open Geospatial Consortium

30

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.6.1
CDB Specification Data Representation and Organization
The CDB Specification provides the means of describing all of the feature sets relevant tosimulation (such as terrain, 3D objects). These feature sets are logical regroupings of datasetsthat are used directly by the simulator client-devices.
In its initial implementation, the Specification supports the following representations:
1. Terrain:
Is a representation of the terrain shape/elevation, raster imagery, surface
attribution and other surface characteristics relevant to distributed simulations.
2. Point feature:
Is a representation of a single location in space or on the earth’s surface. It
consists of a single <latitude, longitude> coordinate with or without anelevation. When a point feature does not have an elevation, it is deemed to beon the surface of the earth. It is often associated with a 3D model. The
information includes point-feature type identification, location, orientation,connectivity, attribution and other characteristics relevant to simulation.
3. Linear feature:
Is the representation of predominantly man-made multi-segmented lineoriented features conformed relative to the terrain (such as runways, roads,
transmission lines, fences). The information includes linear feature typeidentification, location, orientation, lineal geometry, connectivity, attribution
and other surface characteristics relevant to simulation.
4. Areal feature:
Is a representation of closed area-oriented features conformed relative to theterrain such as forested areas, fields. The information includes areal feature
type identification, location, orientation, 2D geometry, connectivity,
attribution and other surface characteristics relevant to simulation.
5. 3D cultural model:
Is a model that is statically positioned on the terrain or bathymetry skin.
Cultural models are often a 3D representation of a man-made or a naturalobject positioned and conformed relative to the terrain. The information
includes its geometry, articulations, raster imagery (texture, normal map, light
map, etc.), lighting systems, and other characteristics relevant to simulation.
6. Moving model:
Is a model that is not fixed at one location in the synthetic environment
database. The simulation host can update the position and orientation of amoving model at every simulation iteration cycle. A moving model is a 3D
representation of man-made objects free to move within the CDB. The
information includes feature type identification, (vehicle class, type, model,etc.), geometry, articulations, raster imagery (texture, normal map, light map,etc.), lighting systems, connectivity to special effects, attribution and othercharacteristics relevant to simulation© 2015 Open Geospatial Consortium

31

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
7. Materials:
Is a symbolic representation of the surface materials for all of the elements
contained within the CDB. Client-devices are required to simulate thesynthetic environment over different portions of the electromagnetic
spectrum: IR (e.g., FLIR, NVG), microwaves (e.g., Radar), audio (e.g.,
Sonar), etc. The fidelity of the sensor synthetic environment simulation
model that runs in each of the client-devices is highly dependent on therichness and completeness of properties that characterize the synthetic
environment database in the electromagnetic spectrum of interest.
NOTE: One of the primary objectives of this Specification is to provide andintegrate all of the data required by all sensor devices, not just IGs
producing the Out-The-Window (OTW) scenes. In addition, the mandateof this Specification is to accomplish this objective in a deviceindependent fashion. The CDB Specification provides a means for clientdevices to retain their internal Sensor Synthetic Environment Model(SEM), and yet do so without introducing device dependencies within the
CDB synthetic environment. To accomplish this objective, client-device
vendors must provide the appropriate SEM properties for the prescribed
CDB Base Materials (see Appendix L), since none of the (vendor/devicespecific) material properties are stored within the CDB.
8. Navigational data:
Is a representation of ARINC-424 and DAFIF data in the form of NAVAIDs,
Airport/Heliport, Runway/Helipad, Waypoints, Routes, Holding Patterns,
Airways, Airspace, etc.
In order to represent the above feature sets, the CDB Specification logically organizes its data inmutually exclusive datasets. Furthermore, the CDB Specification is platform and client-device
independent; as a result, the internal data representation is free of client-device specifics andmore closely aligned to DB structures/formats supported by prominent industry standard tools.
The CDB Specification native coordinate system is geodetic (latitude, longitude, and elevation)
based on the WGS-84 earth model. All the simulator client-devices can access CDB geospecificinformation using this convention.
1.6.2
CDB Specification Logical Structure
The CDB Specification is a simulator format for simulation and as such, its storage structure is
optimized for simulator client-devices runtime performance. Therefore, the internal storage
structure is designed with these specific considerations in mind, i.e., as follows:
1. It promotes efficient real-time CDB data access by the simulator clientdevices without degrading their performance. The structure allows
simultaneous accesses by all of the various simulator client-devices.
2. It promotes efficient database updates and deployment in order to reduce thedeployment of a CDB onto one or more simulators.

© 2015 Open Geospatial Consortium

32

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
To address these objectives, the storage structure geographically divides the world into geodetic
tiles (bound by latitudes and longitudes), each containing a specific set of features (such as
terrain altimetry, vectors), models (such OpenFlight models, RCS models), which are in turn
represented by the datasets (see Figure 1-10: CDB Specification Tile/Layer Structure). The
datasets define the basic storage unit used in a CDB. The geographic granularity is at the tilelevel while the information granularity is at the dataset level. As a result, the CDB storage
structure permits flexible and efficient updates due to the different levels of granularity withwhich the information can be stored or retrieved. At the database generation facility, it ispossible to effect small updates, either at the tile level; the feature set level or the dataset level.
Similarly, the storage structure fully supports real-time retrieval of CDB content at the tile level
and the dataset level. Finally, the CDB’s incremental versioning mechanism allows users toefficiently deploy updates to a CDB; only the files whose content differs from a prior version
need be generated and transferred from the database generation facility to the simulation facility.
Another benefit of the CDB Specification storage structure is its ability to support the concurrent
generation and deployment.

Figure 1-10: CDB Specification Tile/Layer Structure

1.6.3
CDB Structure, Organization on Media and Conventions
This CDB Specification describes the CDB data content, representation, as well as the logicalorganization of the CDB data stored on the CDB server disks:
1. Database Structure:
Database structure comprises all of the data structures used to access database
content (such as file paths, Level-of-Detail (LOD), lists) to speed up access,information layering, versioning and configuration management.

© 2015 Open Geospatial Consortium

33

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2. Naming Conventions:
Use to describe a naming hierarchy for cultural models, moving models, lights
and model components.
1.6.4
Typical Implementation on a Simulator
This section is included here to illustrate a typical implementation of CDB Specification on aflight simulator, when used as an on-line (or runtime) repository. The Specification does notmandate particular simulator architecture or the use of specific computer platforms. The selected
implementation varies with the required level of fidelity and performance of the simulator and its
client-devices.
NOTE:

Legacy simulator client-devices can be readily retrofitted for compatibility
with the CDB Specification by inserting a runtime publisher in their SE
paging pipeline.

As shown in Figure 1-11: Typical CDB Implementation on a Suite of Simulators below, a typical
implementation of a CDB Specification System consists of the following main components:
1. Database Generation Facility (DBGF) and CDB Master Store:
A geo-graphically co-located group of workstation(s), computer platforms,
input devices (digitizing tablets, etc.), output devices (stereo viewers, etc.),modeling software, visualization software, CDB server, CDB off-line
publishing software and any other associated software and hardware used forthe development/modification of the CDB. The CDB Master Store consists ofa mass storage system (typically a storage array) and its associated network.
It is connected to a dedicated DBGF Server.
2. Update Manager (UM):The Update Manager software consists of both client and server software.
The Update Manager Server (UMS) software is located at the DBGF. It
manages the CDB updates (versions) and runs in the same platform as the
DBGF Server. The Update Manager Client (UMC) software is located at the
Simulator Facility and runs on the Update Manager Platform shown in Figure
1-11: Typical CDB Implementation on a Suite of Simulators. It
communicates with the UMS to transfer the CDB (partial or complete copy)
and its updates.
3. Simulator Facility CDB Repository:
The simulator repository consists of a mass storage system (typically a storagearray) and its associated network infrastructure. It is connected to the UMC(primarily for update purposes) and the CDB Servers (for simulator clientdevice runtime access).
4. CDB servers:
Is an optional15 gateway to CDB mass storage and applicable infrastructure.
15

Optionally needed for a large-scale CDB repository whose storage system is based on a Storage Area Network(SAN).

© 2015 Open Geospatial Consortium

34

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The CDB servers access, filter and distribute CDB data in response to requests
from the simulator runtime publishers.
5. Runtime publishers:
A term used to describe the computer platforms, and the software thattranslates and optimizes, at runtime, CDB synthetic environment database to aclient-device specific legacy runtime format. Data is pulled from the CDB
server and in turn published in response to requests from its attached simulator
client-device.
6. Simulator client-devices:
Are simulation sub-systems (IGs, radar, weather server, Computer Generated
Forces (CGF) terrain server, etc.) that require a complete or partial synthetic
representation of the world. CDB runtime clients may require a CDB runtime
publisher to convert the CDB into a form they can directly input.

Figure 1-11: Typical CDB Implementation on a Suite of Simulators

1.6.4.1
Database Generation Facility
The DBGF is used for the purpose of CDB creation and CDB updates. Each workstation isequipped with one or more specialized tools. The tool suite provides the means to generate andmanipulate the synthetic environment.

© 2015 Open Geospatial Consortium

35

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1.6.4.2
Database Generation Flow
The CDB considerably simplifies the database generation process, particularly all aspects ofdatabase generation that deal with database layering, formatting, structure and level-of-detailing.

Figure 1-12: Typical DB Generation - CDB Used as DB Repository

Figure 1-12: Typical DB Generation - CDB Used as DB Repository and Figure 1-13: Typical
DB Generation Flow - CDB Used as DB & Sim Repository illustrate a typical databasegeneration workflow with the CDB used as a DB workstation repository and the CDB used as a
Repository for the DB workstation and the simulator. Both approaches share the same steps,
namely:Z

Source data collection and preparation: This step usually involves theloading of raw (usually) uncorrected data and the conversion to formats native
to the database toolset.

Z

Source data preparation: This step usually involves the detection/correctionof errors, the harmonization of the data and the correction of errors. In thiscontext, errors signify all instances where the data fails to meet prescribedcriteria. For instance, errors can be as straightforward as corrupted digital© 2015 Open Geospatial Consortium

36

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
data. More subtle forms of errors could be textures that fail to meet various
brightness, contrast, chrominance, and distortion criteria. Harmonizing datarequires that data sources be coherent with each other. An example of nonharmonized dataset is a terrain imagery mosaic built from pictures taken indifferent seasons, with different illumination conditions, with/without clouds,etc.
Z

3D modeling of features:This step involves the creation of 3D
representations for culture features (buildings, trees, vehicles, etc.), thecreation and mapping of texture patterns/imagery to the geometricalrepresentation, the generation of the model LOD, and the generation of
appropriate attribution data so that the simulator can control the model andhave it respond to the simulated environment.

Z

Database automation: Modern database generation tools offer an increasinglevel-of-automation to the modelers, thereby improving the DB generation
timeline (for example, a forest tool that controls the placement of individual
trees correlated to the underlying terrain imagery). Over the past few years,
tool vendors have introduced a broad set of tools aimed at eliminating highly
repetitive modeling tasks; this includes tools for runway generation (including
the positioning of stripes, lights, signs, markings, etc.), road/railroad
generation, cultural feature extraction from stereo pairs, cultural feature
footprint extraction from image classification processes, terrain grid
generation from stereo pairs, terrain surface material classification, etc.

© 2015 Open Geospatial Consortium

37

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 1-13: Typical DB Generation Flow - CDB Used as DB & Sim Repository

The result of the above steps yields a group of independent, layered and correlated datasets, (i.e.,
datasets that are geographically aligned in latitude/longitude (but not always elevation)), allsharing compatible projections, with all of the necessary attribution.
In the non-CDB approach illustrated in Figure 1-12: Typical DB Generation - CDB Used as DB
Repository, the correlated layered datasets are collapsed into a single global database during thedatabase compilation process. In many database tools, the generation of the terrain plays apivotal role in the database assembly process because all of the cultural features are conformed
and constrained to the terrain representation and structure. Most client-devices in existence
today have interdependent terrain geometry, raster imagery and culture; as a result of this, mosttools in use today resolve these inter-dependencies during this critical and computationallyexpensive database assembly step. The resultant database is stored on disk at the DB generation
facility. Following the assembly process, the modeler is required to run an off-line compilation
process for each of the supported client-devices. The compilation process must resolve all ofdifferences between the tool-native representation and the client-device internal representation.

© 2015 Open Geospatial Consortium

38

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
During this step, the off-line compiler performs a series of steps that transforms the database into
an alternative form (usually proprietary) that resolves:
1.
2.
3.
4.
5.

its internal formats
its structure and organization (for example, its level-of-detail representations)its naming conventions
the number precision and number representation of its data
the type and fidelity of data/parameters it uses for its internal algorithms(typically light parameters, FLIR/NVG parameters, etc.)
6. its performance limitations
As stated earlier in Section 1.3.1.1, the CDB can be used as an off-line repository for theauthoring tools and as an on-line repository for the simulator(s). In the latter case, there is noneed for an off-database compilation process because this step is in-effect performed on-line by
the runtime database publishers. Furthermore, since the CDB datasets adhere to data formats
commonly in use, most authoring tools in existence today, have the necessary software to
read/write data in the mandated formats.
Out of the many steps typically required by the off-line compilation, the CDB only requires thatlevels-of-detail be generated for the terrain elevation, raster imagery, and the grouping of culturalfeatures. These improvements are expected to yield important savings in man-hrs, machine-hrs
and storage when compared to the non-CDB approach.
1.6.4.3
Update Manager
The creation of the CDB and subsequent updates are performed at the DBGF. The Update
Manager (UM) keeps track of these updates and synchronizes the Simulator CDB Repository to
the DBGF. The CDB Specification permits flexible and efficient access of the CDB and does sowith different levels of granularity; thus, it is possible to perform modifications to the CDB on acomplete tile, or on individual datasets of a tile. This permits rapid deployment of the CDB, afeature that is particularly valuable for mission planning and rehearsal. With few exceptions16,
there is no inter-dependency between datasets and it is possible to modify a dataset (such as theterrain imagery) without reprocessing the complete tile; only the modified dataset requires reprocessing. The CDB Specification supports the concurrent creation/modification of the CDB
with its deployment. Once a tile, a feature set, or a dataset has been processed, it may betransferred to the simulator facility concurrently with other work performed at the DBGF.
Updates to the simulator CDB repository are performed by the UM. The simulator CDB
repository is configured to provide storage for a (partial or complete) copy of the Database
Generation Facility (DBGF) CDB master store. The Update Manager transfers the CDB and its
updates by area of interest, allowing for partial updates or even complete copies of the CDB.
The Update Manager (UM) simulator CDB repository is used by one or more co-locatedsimulators to retrieve the CDB in real-time.

16

The only exceptions to this CDB principle are the MinElevation, MaxElevation datasets which are slaved to the
Terrain Elevation dataset and the MaxCulture dataset which is slaved to the GSFeature/GTFeature dataset.

© 2015 Open Geospatial Consortium

39

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Additionally, the UM manages the facility’s release of the CDB. It maintains versioning
information as supplied by the DBGF. Based upon this information, it is possible to request or
approve CDB updates to the facility from the UM.
1.6.4.4
CDB Servers
When the CDB is used as an on-line (or runtime) repository, a set of CDB servers (i.e., the server
complex) are required in order to fetch data in real-time from the simulator CDB repository.
Each of the CDB servers responds to the requests made by the simulator client-device runtime
publishers.
1.6.4.4.1 Runtime Publishers
When the CDB is used as an on-line (or runtime) repository, a set of runtime publishers are
required in order to transform the CDB data into legacy client-devices (simulator subsystems)
internal format17. The runtime publishers provide a key role in further enhancing overall
algorithmic correlation within and across simulators. Each publisher communicates to the CDB
server complex and the attached simulator client-device as follows:
1. Receive update requests for synthetic environment data from their respective
simulator client-devices.
2. Relays the update request to the CDB server complex.
3. Once the update request is acknowledged and the data retrieved by the CDB
server complex, the runtime publisher pulls CDB data from the CDB server
complex and converts and formats this data into a form directly usable by thesimulator client-device. This processing is accomplished in real-time.
4. Transfers the converted CDB data to the simulator client-device.
1.6.4.4.2 Simulator Client-devices
The paragraphs below provide a short description of the client-devices found on a typicalsimulator and the global types of information required from the CDB.
1.6.4.4.2.1 Visual Subsystems
Typical visual subsystems compute and display in real-time, 3D true perspective scenes
depicting rehearsal and training environments for OTW, IR, simulated Night Vision Goggles(NVG), and 3D stealth IG viewing purposes.
1.6.4.4.2.2 Out-The-Window Image Generator (OTW IG)
The IG portion of the visual system provides a wide range of features designed to replicate realworld environments. High density and high complexity 3D models can be superimposed onto
high-resolution terrain altimetry and raster imagery. Scene complexity with proper object detailand occulting provide critical speed, height and distance cueing. Special effects are implemented
17

Alternately, client-devices can be designed / modified to natively handle the CDB’s data model, thereby
obviating the need for a separate runtime publishing step.

© 2015 Open Geospatial Consortium

40

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
throughout the database to enhance the crew’s experience and overall scene integrity. TypicalIGs optimize the density, distribution and information content of visual features in the scene(s)for all conditions of operations.
The visual subsystem uses time invariant information held in the CDB such as:
1.
2.
3.
4.
5.

Terrain altimetry and raster imagery data
Cultural feature data
Light point data
Airport data
Material attribution data

1.6.4.4.2.3 Infrared IG
Included in the CDB coding is the material attribution used by a typical physics-based Infrared
Sensor Synthetic environment Model. This model computes, in real-time, the amount of radiatedand propagated energy within the simulated thermal bands.
A typical thermal model takes into account the following material properties:
1. Solar absorbance
2. Surface emissivity:
This coefficient reflects the degree of IR radiation emitted by the surface.
3. Thermal conductivity
4. Thermal inertia:
This coefficient describes the material ability to gain/lose its heat to a still-air
environment.
1.6.4.4.2.4 Night Vision Goggles Image Generation
Included in the CDB coding is the material attribution (exclusive of any properties) used by
NVG simulation models.
1.6.4.4.2.5 Ownship-Centric Mission Functions
Visual subsystems typically provide a set of ownship-centric Mission Functions (MIF) for use indetermining:
1. The Height Above Terrain (HAT), Height Above Culture (HAC), and Height
Above Ocean (HAO). This function may report the material type of the texelor the polygon, and the normal of the surface immediately beneath the point.
2. Own-ship Collision Detection (CD) with terrain, 3D culture and moving
models. This may include long thin objects such as power lines.
3. Line Of Sight (LOS) and Laser Ranging Function (LRF) originating from theownship. This function may return the range, the material type and the© 2015 Open Geospatial Consortium

41

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
normal of the nearest encountered element in the database. The maximum
length of a requested vector is typically limited to the paged-in database.
The mission functions provided by an IG base their computations on a database that has LOD
representations equivalent to those used by OTW IGs. Since the visual subsystem scene
management mechanisms are essentially slaved to the own-ship’s position, the terrain accuracy(e.g., its LOD), the cultural density/LOD and the texture resolution decrease with distance fromthe own-ship. As a result, the IG-based mission functions computations are best suited for ownship functions. In cases where the database needs to be interrogated randomly anywhere in thegaming area, simulator client-devices such as Computer Generated Forces (via a terrain server)
are best suited because their architecture is not own-ship-centric.
1.6.4.4.2.6 Computer Generated Forces (CGF)
CGF provides a synthetic tactical environment for simulation-based training. It simulates
behaviors and offers interactions between different entities within the simulation. It models
dynamics, behavior doctrines, weather conditions, communications, intelligence, weapons andsensor interactions, as well as terrain interactions. CGF offers modeling of physics-basedmodels in a real-time natural and electronic warfare environment for air, land and sea
simulations.
Typically, CGF is able to create a realistic simulated multi-threat, time-stressed environment
comprising items such as:
1. Friendly, enemy and neutral entities operating within the gaming area
2. Interaction with weather conditions currently in the simulation
3. Entities with representative dynamics (velocity, acceleration, etc.), signatures,
vulnerabilities, equipment, communications, sensors, and weapons
4. CGF uses time invariant information held in CDB such as:a. Terrain altimetry and raster imagery
b. Cultural features
c. Linear (vector) and areal informationd. Sensor signaturese. Moving Models
1.6.4.4.2.7 Weather Simulation
The Weather Simulation (WX) involves computing and analyzing the various weather
components and models around important areas defined in a simulation, in order to produce
realistic real-life scenarios for the sub-systems being affected by weather effects. As such, aweather data server typically handles the weather simulation; this server handles requests forweather-related data such as temperature, 3D winds, turbulence gradients, and complex weather
objects such as clouds, frontal systems or storm fronts.

© 2015 Open Geospatial Consortium

42

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
WX uses time invariant information held in CDB such as terrain elevation and (potentially)significant features with 3D modeled representations to compute weather and wind patterns.
1.6.4.4.2.8 Radar
Typical Radar Simulation Models require modeling of all real-life and man-made effects orobjects that can cause significant echo returns from the wavelengths of the simulated Radar RF
main beam and side lobes. Additionally, LOS computations are necessary for proper target
occultation by the Radar.
The Radar subsystem uses time invariant information held in CDB such as:
1.
2.
3.
4.
5.

Terrain altimetry and Raster materials
Cultural features with either 2D and 3D modeled representations
Material properties
Land/Coastline/Man-Made features
Target shapes (RCS polar diagrams, 3D models)

1.6.4.4.2.9 Navigation System
The Navigation System provides the navigation information around the areas and routes as
defined in a simulation in order to provide precise NAVAIDs data which will generate wellcorrelated sub-systems being part of such simulation scenarios.
As such, the Navigation System Simulation handles navigation aids information requests fromother simulator client-devices such as:
1. Tactical Air Navigation (TACAN)
2. Automatic Direction Finder (ADF)
3. VHF Omni Range (VOR)
4. Instrument Landing System (ILS)
5. Microwave Landing System (MLS)
6. Doppler Navigation System (DNS)
7. Global Positioning System (GPS)
8. Inertial Navigation Unit (INU)
9. Non-Directional Beacons (NDB)
In addition to the NAVAIDs, the navigational data include datasets such as:
1. Communications Stations data
2. Airport/Heliport (including SIDs, STARs, Terminal Procedure/Approaches,
Gates)
3. Runway/Helipad
4. Waypoints
5. Routes
6. Holding Patterns
7. Airways
8. Airspaces© 2015 Open Geospatial Consortium

43

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
NAV uses time invariant information held in CDB such as:
1.
2.
3.
4.
5.
6.
7.

ICAO code and Airport Identifier
NAVAIDs frequency, channel, navigational range, power
Declination
Magnetic variations
Communications Stations data
Airport/Heliport
Runway/Helipad

1.6.4.5
Other Applications of the CDB Specification
While the Specification was initially targeted primarily for use in flight simulator applications, it
is entirely suited to a broad range of other applications that make use of the same datasets; theseinclude (and are not limited to):1. Ground warfare simulation
2. Anti-submarine warfare
3. Visualization
4. Modeling and Simulation
5. Urban Planning
6. Natural Resource Management
7. Emergency Management
The implementation of the CDB Specification on legcy simulator client-devices usually
mandates the use of the runtime publishers; these costs are largely offset by the consolidation(and substantial reduction) of storage and associated infrastructure. In the future, it is anticipatedthat the runtime publishing computer infrastructure will be largely “absorbed” by higher
performance client-devices that will natively process the CDB without an intermediateconversion into a legacy internal format.
In applications that are less demanding than flight simulation, the CDB Specification can be
implemented without resorting to high-performance computer platforms. For instance, thesimulator repository mass storage system (shown in Figure 1-11: Typical CDB Implementation
on a Suite of Simulators) can be a single disk storage device. In demanding applications, thesimulator repository can be implemented as a large-scale Storage Area Network (SAN).
Similarly, the UM, the CDB server and each of the client-device runtime publishers can be
implemented as software tasks within a single computer platform, or can even be migrated tosoftware tasks running internally within the client-devices. Figure 1-8: Typical Implementationof CDB Specification on Desktop Computer, illustrates a desktop trainer consisting of a StealthViewer and radar simulations, implemented as software applications running on a single
computer platform; both applications pull their synthetic environment data from a disk-resident
CDB.
1.6.5
Use of CDB in Applications Requiring Dynamic Synthetic Environments
A CDB-compliant simulator already incorporates most of the architectural features required tosupport the handling of Dynamic Synthetic Environments (aka DSE). Figure 1-14: Versioning© 2015 Open Geospatial Consortium

44

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Paradigm Applied to Dynamic SE, illustrates how CDB-compliant simulator architecture can beextended to permit the runtime modification of the CDB. This can be accomplished byleveraging simulator architectures that natively adhere to the CDB data schema and to the CDB
versioning capabilities.
This capability requires that the simulator be equipped with a Dynamic Synthetic Environment
Generator whose interfaces conform to the CDB Specification; all other elements of thesimulator architecture are identical to those of a CDB-compliant simulator.
Two applications of this principle could be envisaged:
1. DB update from DIS: This is the so-called “Dynamic Terrain/Synthetic
Environment”, where a group of confederates interoperate over a DIS networkby receiving update commands that trigger runtime modification of the CDB.
2. DB creation/update from live data feed: Terrain areas could be created or
modified on-the-fly, based on live data (such as terrain imagery or LIDAR
data transmitted by a UAV) and provided instantly to the confederates.

Figure 1-14: Versioning Paradigm Applied to Dynamic SE

1.6.6
Synthetic Environment Database Correlation
Synthetic environment correlation issues arise whenever two or more devices exhibit adiscernible level of informational inconsistency. Correlation of synthetic environment databases
has long been a problem in simulation, primarily aggravated by the fact that each of thesimulator client-devices used distinct runtime databases.
There are many different types of correlation errors, and each have a contribution to the overallcorrelation problems that has plagued simulators for several years. They are defined here as
follows:© 2015 Open Geospatial Consortium

45

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1. Raw source correlation: Is the degree of informational consistency between
two or more sets of raw data18 (i.e., inputs to a modeling station) representing
aspects of the same environment (for instance, the correlation errors arisingfrom Digital Terrain Elevation Data (DTED) elevation data that does not
perfectly match to satellite raster imagery due to oblique view distortions
induced by the satellite). Correlation errors are intrinsic to the process ofgathering data because since there is no means to gather all of the required
data from a single device, at a single instant in time. Instead, datasets (e.g.,
elevation, raster imagery, geometry) are each gathered from various devices ofvarious types (with distinct precision, formats, capabilities, fidelity) at
different times. This in turn leads to a broad range of correlation errors
typically resolved by the modeler during the final assembly of the synthetic
environment from its sources.
2. Source database self-correlation: Is the degree of informational consistency
between the internal datasets of a source database produced by a DB
generation toolset. To a large extent, the effort expended at DB generation
time consists in eliminating (or at least reducing) correlation errors arisingfrom miss-correlated raw source data.
3. Runtime database correlation: Is the degree of informational consistency
between two or more runtime client-specific databases representing the same
synthetic environment19. The likelihood of achieving correlated runtime
client-device databases is particularly low when different authoring tools (andpossibly different source data) are used to assemble each of the compiled
runtime databases. In recent years, some authoring tools have been improved
to automatically produce a set of client-device database from one common
repository (internal to the tools). Nonetheless, it is still current practice within
the simulation community to independently deploy the simulator client-device
databases; as a result, correlation errors may occur especially if the masterdatabase repository is constantly evolving. The CDB Specification eliminates
database correlation errors since only one database is used to represent thesame synthetic environment. The CDB is a single database that can beaccessed simultaneously by all simulator client-devices at runtime. By
definition, it addresses all runtime database-level correlation errors.
4. Numerical accuracy correlation: Is the degree of informational consistency
between the outputs of two or more devices, with each device performing thesame algorithms, using the same control parameters but performing internal
computations to a different numerical accuracy. Consider for example two
18

In this context, raw source denotes any input to the modeling workstation that is used to assemble the synthetic
environment; consequently, the data may have undergone some level of post-processing (such as image colorbalancing, image ortho-rectification, etc.) or may be in a specialized source interchange format (such as SIF,SEDRIS, etc.).
19

A runtime client-specific database is a device-loadable database format that can be processed by a target device.

© 2015 Open Geospatial Consortium

46

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014devices computing the sin of an angle, one with a series of 10 terms, andanother with an interpolation of a look-up table with 100 entries, or one device
using 32-bit signed integers for its internal computations and the other using
single-precision floats. The CDB Specification reduces numerical accuracy
correlation errors because a single representation is used for each dataset.
Note however that numerical correlation may deteriorate due to the variancesin numerical precision inherent to each client-device.
5. Algorithmic correlation: Is the degree of informational consistency between
the outputs of two or more devices, with each device performing its internal
computations to the same numerical accuracy, but using different algorithms
with possibly different control parameters. Consider for example, two devices
meshing terrain from a regular grid of elevation points, one using a regularmesh of right-handed triangles using the elevation points as vertices, and theother with a DeLauney triangulated mesh derived from the grid of elevation
points. Algorithmic correlation errors can be introduced anywhere in thedataset processing chain, ranging from the raw source level right through tothe internals of the simulator client-devices. While it is not possible tomandate complete algorithmic uniformity throughout this elaborate chain, the
CDB Specification offers solutions to this issue20. Firstly, only one databaseis produced, so all DB authoring tool algorithmic correlation issues are
eliminated. Note that the implementation of runtime publishers on a simulator
can play a role in improving overall algorithmic correlation21.
6. Parametric correlation: Is the degree of informational consistency between
the outputs of two or more devices, with each device performing the samealgorithms with identical numerical precision with different control
parameters (e.g., consider two devices generating regular meshes of righthanded triangles based on a regular grid of elevation points organized by
LOD, one using an LOD meshing tolerance parameter of 1m and the other one
using 2m). Note that it is clearly possible to create a synthetic environment
database whose content is at a level of resolution, fidelity and accuracy thatcan overwhelm any client-device; however, the amount and type of data thatis rejected by each type of client-device can vary considerably. For example,
a NAVAIDs data server client-device need only be concerned with Digital
Aeronautical Flight Information File (DAFIF™), and as a result is virtually
unaffected by changes in the resolution of the terrain elevation data which
could easily increase terrain SE content by 100-fold. The implementation of
the CDB Specification on a simulator can reduce and/or eliminate parametric20

For instance, the CDB does not impose the terrain skinning and meshing conventions that each of the runtime
publisher generates for its attached client-device. However, it is understood that if all client-devices would use the
CDB meshing conventions natively, correlation issues between clients would be significantly reduced.
21

Since each dataset is uniquely represented, it is possible to share a greater number of algorithms between CDB
runtime publishers. This ensures that datasets are processed in an identical fashion whenever two or more
publishers share the same algorithm.

© 2015 Open Geospatial Consortium

47

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
error by exercising explicit control, at run-time, on the resolution of the dataprocessed by the client-devices. This approach is much preferable to off-line
published approaches where parametric correlation is established during thecompilation of the runtime databases and cannot be changed once the runtime
database is produced.
Table 1-1: Summary of Synthetic Environment Database Correlation Errors, provides a summaryof the different types of correlation errors and how/where such errors can be addressed. Figure
1-15: Sources of Synthetic environment Database Correlation Errors, illustrates the conventional
synthetic environment database process from raw source, the assembly of datasets at the DB
workstation, the publishing into runtime databases, and the rendering by the simulator clientdevices.

Raw Source

Datasets
Data

Runtime
Sources

Addressed by

Raw source correlation
errors caused by datacollections at different
times and from different
devices. Also caused byregistration errors.

Toolset and humanoperators address raw
source correlation errors
ensuring that data isproperly corrected andregistered.

Dataset correlation errors Toolset ensures thatare caused by discrepancies dependent dataset layers
between co-located dataset are updated together,X
while CDB Specification
layers.
minimizes thesedependencies.

Database Tools

Description

Sim Devices

Correlation

CDB Spec

Table 1-1: Summary of Synthetic Environment Database Correlation Errors

X

X

Information from several CDB Specification
runtime databases contains addresses runtime source
correlation by enforcing X
conflicting information.
a single runtime
database.

© 2015 Open Geospatial Consortium48

Algorithmic

ParametricComputational
Accuracy

Synchronism

Temporal

Addressed byDifferent client-devices
Simulation clients
may use different
address algorithmic
algorithms to filter
correlation errors. They
information and to simulate ensure that the different
real-world device.
algorithms used arecompatible.

X

Same client-devices may
run with different initial
parameters.

A simulation that would
ensure each clientdevice runs at justdiscernible error levels.

X

Different computational
platforms may run atdifferent numericalaccuracies.

Using the same platform
with identical numericalaccuracy for all clientdevices and servers.
Developing softwareX
according to strict rules
and guidelines addresses
computational accuracy
correlation errors.

X

Lags and delays introduced Through systemby networking systems as architecture, system iswell as subsystems using designed to use properdifferent time bases may
bandwidths andcause subsystems to becomputational methods
unsynchronized.
to reduce latencies. All
simulator client-devices
use the same clock.

Paging latency Paging and runtime
publishing may introduce
delays long enough toprevent some simulationclients to get information
on time.

Paging and runtime
publishing tasks andclient-device paging
software ensures thatruntime information isavailable on time.

© 2015 Open Geospatial Consortium

Database Tools

Description

Sim Devices

Correlation

CDB Spec

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

X

X

X

49

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 1-15: Sources of Synthetic environment Database Correlation Errors© 2015 Open Geospatial Consortium

50

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The implementation of the CDB Specification on a simulator can also provide the means to
reduce and control the sources of parametric correlation at the client-device level. The
underlying cause of parametric correlation usually points to the intrinsic capabilities (i.e., theperformance and functionality) of each client-device. Since many client-devices are unable tocope with the synthetic environment database at its full fidelity, the off-line compilers “filterout” portions of the database (e.g., level of resolution, level of fidelity) in order to meet thelimited functionality or the real-time constraints of the targeted device. In order to further
control processing variations, some client-devices are equipped with the means to dynamically“filter-out” portions of the database in order to meet real-time constraints. The filters can be
typically controlled statically (and sometimes even dynamically) through the use of parameters.
The amount and type of data that is rejected by each type of client-device can vary considerably.
This is the underlying cause of parametric correlation errors. In conventional simulator clientdevices, the handling of parametric correlation is handled in a half-hazard fashion, largely
because the “filter parameters” are either fixed or inaccessible to the user. Distinct database
compilers generate distinct runtime databases, each configured with their respective filteringparameters.
The CDB Specification offers multi-tiered solutions to this problem. Firstly, since it has aunique data representation, the resolution, fidelity and accuracy of the synthetic environment
database, as seen by each of runtime publisher attached to the client-devices, is completely
correlated. Secondly, since the publishing process is done on-line, it is possible to provide theuser access to the filter parameters so that he can globally control resolution, fidelity andaccuracy (and hence correlation) of the synthetic environment database across all simulator
client-devices. While the CDB Specification does not provide explicit jurisdiction over the
implementation of this mechanism in the client-devices/publishers, it is nonetheless possible toimprove parametric correlation, at runtime, via control of the client-devices/publishers. This
new paradigm now permits the simulator user the means to not only control client-device load
but to globally re-examine and control the level of correlation within a simulator (or acrosssimulators).
The control of parametric correlation requires a working understanding of the characteristics ofthe client-device. At a minimum, one must consider the operating limits of all client-devices andensure that the runtime publishers limit synthetic environment content to the limits imposed by
the client-devices22. Secondly, one must have a working model of the “filter parameters” madeavailable by the client-devices or by their runtime publishers. Thirdly, one must have a working
performance model of each client-device. Finally, one must have an understanding of “justdiscernible threshold” of correlation as it applies to each client-device. For example, it isunlikely that increasing the terrain resolution from 1m to ½m would produce a discernible
change in how a CGF system allows simulated players to interact realistically with one another.
As a result, the ½m terrain resolution of the CGF system is below the “just discernible threshold”
of that device. The ½m data can be discarded without reducing the level of correlation provided
by that client-device.
22

For instance, an IG might refuse to operate if confronted with an area modeled with 1 millimeter OTW texture.

© 2015 Open Geospatial Consortium

51

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
As mentioned earlier, the runtime publishing paradigm permits the simulator user the means tocontrol client-device load and to globally re-examine and control the level of correlation within asimulator (or across simulators). Several choices are possible, depending on the flexibility
offered in the implementation of the runtime publishers and the client-devices. The choices are:
1. Publishers globally adjusted to overload limit of least capable client-device(see Figure 1-16: Overload Limit of Least Capable Client-Device):

Figure 1-16: Overload Limit of Least Capable Client-Device

a. Assuming sufficient (parameter) controls in each of the client-devices,parametric correlation errors can be eliminated by setting the filter
parameters of all client-devices/publishers to the least-capable clientdevice in the simulator.
b. Success is contingent on suitable set of parameters in each clientdevice.
c. The result is full correlation with no overloads, but with the lowest
observed DB fidelity.
2. Publishers individually adjusted to the overload limit of each client device(see Figure 1-17: Overload Limit of Each Client-Device):© 2015 Open Geospatial Consortium

52

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 1-17: Overload Limit of Each Client-Device

a. This is the approach used in virtually all simulators in operation today.
b. Result is partial correlation with no overloads, and high-observed DB
fidelity.
3. Publishers adjusted to the CDB content, but globally adjusted to the operating
limit of the least capable client-device (see Figure 1-18: Operating Limit ofLeast Capable Client-Device):

Figure 1-18: Operating Limit of Least Capable Client-Device

a. Client-devices are allowed to overload in areas where database content
is deemed critical.
b. Result is full correlation, possible overloads with high-observed DB
fidelity.

© 2015 Open Geospatial Consortium

53

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
4. Publishers adjusted to the CDB content, but individually adjusted to theoperating limit of each client-device (see Figure 1-19: Individually Adjusted
to the Operating Limit of Each Client-Device):

Figure 1-19: Individually Adjusted to the Operating Limit of Each Client-Device

a. Client-devices are allowed to overload in areas where database content
is deemed critical.
b. Result is, possible overloads and the highest observed DB fidelity.
5. Publishers adjusted by the simulator operator at scenario startup (see Figure
1-20: Adjusted by the Simulator Operator at Scenario Startup):

Figure 1-20: Adjusted by the Simulator Operator at Scenario Startup© 2015 Open Geospatial Consortium

54

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 2
2
CDB Concepts
This chapter presents basic CDB concepts of the Specification. These concepts are either reusedby other concepts or used repeatedly throughout the Specification.
2.1
Partitioning the Earth into Tiles
The CDB tiling approach has the following characteristics:
1.
2.
3.
4.

5.

6.
7.
8.

The earth model is divided (in latitude) into slices.
The slice’s x-axis is aligned to WGS-84 lines of latitude.
The slice’s y-axis is aligned to WGS-84 lines of longitude.
The number of units along the slice’s y-axis for a given level of detail isthe same for all slices. The earth surface geodetic dimension in arcsecond of y-axis units within an earth slice is exactly the same, regardlessof latitude.
The geodetic dimension of an x-axis unit in arc-second is constant withina zone, but is re-defined at pre-selected latitudes to achieve a greater levelof spatial sampling uniformity in all tiles; this overcomes the narrowing
effect of increased latitudes on longitudinal distances. The definition ofzones in the CDB is the same as those in DTED (with the exception of thepoles).
The number of units along the slice’s x-axis for a given level of detail isthe same within each zone.
The number of units along the slice’s y-axis is constrained to a multiple of
2n in all slices.
The number of units along the slice’s x-axis will vary depending on whichzone the latitude of the slice belongs. At this point we introduce theconcept of a CDB Geocell, which differs slightly from a DTED cell. Both
DTED and the CDB have Geocells whose height is 1 degree but whose
width varies depending on its latitude. The only difference is that the
CDB provides for an additional zone at each of the poles. Table 2-2
shows the dimensions of a CDB Geocell per zones of latitude. For
instance, in latitude zone 5, which goes from –50° to 50° of latitude, a
CDB Geocell is 1° × 1°, in zone 4 and 6 which goes from latitude 50° to
70° the cell size is 1° × 2°. The main reason to introduce this concept is tomaintain a reasonable eccentricity between the sides by trying to keepthem as close to a square as possible. Variable CDB Geocell size in the
CDB Specification reduces the simulator client-device processing
overheads associated with the switching from one zone to another (due tosmall number of zones across the earth), reduces the variation of
longitudinal dimensions (in meters) to a maximum of 50% and improves© 2015 Open Geospatial Consortium

55

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
storage efficiency. Two criteria are used to define the size of a CDB
Geocell:a. A CDB Geocell must contain a whole number of DTED Geocells; inother words a CDB Geocell must start and end on a whole degree
along the longitudinal axis. This is done so as to facilitate mappingfrom CDB Geocells to DTED Geocells,b. The length of the CDB Geocell must be a whole factor of 180, in otherwords length of 1, 2, 3, 4, 6 and 12 degrees are legal but lengths of 7
and 8 degrees would not be since these are not exact factors of 180.
Table 2-1: Intervals for DTED Level 2
DTED
Zone

Latitude Range(Degrees)

Latitude Interval(Arc seconds)

Longitude Interval(Arc seconds)

I
II
III
IV
V

0 – 50 N-S
50 – 70 N-S
70 – 75 N-S
75 – 80 N-S
80 – 90 N-S

1
1
1
1
1

1
2
3
4
6

Table 2-2: Size of CDB Geocell per Zone
CDB
Zone
0
1
2
3
4
5
6
7
8
9
10

Latitude Range(Degrees)–90 ≤ lat < –89–89 ≤ lat < –80–80 ≤ lat < –75–75 ≤ lat < –70–70 ≤ lat < –50–50 ≤ lat < +50+50 ≤ lat < +70+70 ≤ lat < +75+75 ≤ lat < +80+80 ≤ lat < +89+89 ≤ lat < +90

CDB Geocell size(° Lat × ° Lon)
1 × 12
1 × 6
1 × 4
1 × 3
1 × 2
1 × 1
1 × 2
1 × 3
1 × 4
1 × 6
1 × 12

Number of
DTED Geocells
12
6
4
3
2
1
2
3
4
6
12

2.1.1
Description
The CDB Specification represents the earth as a fixed number of slices divided equally along alatitude axis as illustrated in Figure 2-1: CDB Earth Slice Representation.

© 2015 Open Geospatial Consortium

56

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 2-1: CDB Earth Slice Representation

The earth surface coordinate system conventions used for each slice consists of a regular twodimensional grid where the x-axis is always pointing east, aligned to WGS-84 lines of latitude
and where the y-axis is always pointing north, aligned with WGS-84 lines of longitude. The
earth surface origin, reference point (lat:0, long:0) on the CDB earth representation, is defined by
the intersection of the WGS-84 equator and the WGS-84 international 0° meridian. The x=0 and
y=0 reference is at (lat:0, long:0) x is positive going East and negative going West; y is positive
North of the equator and negative South.
Every x and y unit corresponds to a fixed increment of longitude and latitude in arc-second. The
x-axis and y-axis fixed increment unit are referred hereafter a XUnit and YUnit. Since the y-axisof the slices is aligned with WGS-84 lines of longitude, y-axis coordinate units are uniformly
distributed between the equator and the poles in both geodetic system terms (arc-second) and in
Cartesian system terms (meter). This property naturally leads to define the same number ofYUnit per slice; this however is not the case with the x-axis. As illustrated in Figure 2-2:
Variation of Longitudinal Dimensions versus Latitude, the Cartesian space distance between
such x-axis values diminishes as we move towards the poles. In order to maintain size
constancy, the CDB Specification provides a piecewise solution similar to that used by NGADTED data. The world is divided into eleven zones. All CDB Geocells within a slice are one
degree of latitude high (the height of a slice) and of varying width in longitude depending on thezone to which they belong.

© 2015 Open Geospatial Consortium

57

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 2-2: Variation of Longitudinal Dimensions versus Latitude

In order to meet one of the previously mentioned real-time considerations, the number of y-axis
units for one Geocell, NbYUnitInCDBGeocell, is set to a power of two. This has been chosen as1024 to give a north-south grid post spacing of approximately 109 meters at the default Level of
Detail (LOD 0); this spacing is the same for all earth slices.
𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 = 1024

(2–1)

𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁ℎ𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 180(2–2)

𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 = 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁(2–3)

The CDB Specification also imposes an integer number of slices along latitude lines.
NbEarthSlice is the number of earth slice from South Pole to North Pole and is equal to 180
since each slide is one degree.
Furthermore, the number of x-axis units, NbXUnitInCDBGeocell, is also maintained to be thesame as that of NbYUnitInCDBGeocell for all CDB Geocells. As previously stated, the cellwidth in longitude is adjusted at specific latitudes to maintain a reasonable aspect ratio. As aconsequence the area defined by the corner coordinates (x,y), (x+1, y) (x, y+1), (x+1,y+1),
decreases when moving toward the poles in the same zone and increases when moving toward
the equator.

© 2015 Open Geospatial Consortium

58

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The geodetic dimension of a YUnit is referred to as ArcSecLatUnitInCDBGeocell; it is the samefor all slices and is determined by Equation (2–4).
180  degrees  ×  3600  arcsec/degree
𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁  ×  𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁ℎ𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆
180  degrees  ×3600  arcsec/degree
𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 =
unit
1024
×180  slices
slice
𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 = 3.515625  arcsec/unit
𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 =(2–4)

ArcSecLatUnitInCDBGeocell is a constant defined by the CDB earth model and cannot be set toany other value.
Similarly, the geodetic dimension of a XUnit is referred to as ArcSecLongUnitInCDBGeocell; itvaries at specific latitudes and is shown in Table 2-3: CDB Geocell Unit Size in Arc Seconds.
As shown in the table, maintaining the NbXUnitInCDBGeocell constant causes abrupt changes in
ArcSecLongUnitInCDBGeocell at specific latitudes. This is done, however, to achieve ourobjective of maintaining a reasonable aspect ratio across the earth model.

Table 2-3: CDB Geocell Unit Size in Arc Seconds
Zone
0
1
2
3
4
5
6
7
8
9
10

CDB Geocell size(° Lat × ° Lon)
1 × 12
1 × 6
1 × 4
1 × 3
1 × 2
1 × 1
1 × 2
1 × 3
1 × 4
1 × 6
1 × 12

ArcSecLatUnit
InCDBGeocell
3.515625
3.515625
3.515625
3.515625
3.515625
3.515625
3.515625
3.515625
3.515625
3.515625
3.515625

ArcSecLongUnit
InCDBGeocell
42.187500
21.093750
14.062500
10.546875
7.031250
3.515625
7.031250
10.546875
14.062500
21.093750
42.187500

2.1.2
Tile Levels-of-Detail (Tile-LODs)
Since the CDB Specification defines NbXUnitInCDBGeocell and NbYUnitInCDBGeocell as
being the same and since NbYUnitInCDBGeocell is constrained to a power of two, the CDB tile
representation can readily reference square areas at a specified level-of-detail. These areas aredelimited by longitude and latitude extents. By convention, LOD 0 always corresponds to theearth slice size of NbXUnitInCDBGeocell × NbYUnitInCDBGeocell with a Cartesian unit
spacing in the range of one hundred meters at the slice’s zones boundaries and at the equator.

© 2015 Open Geospatial Consortium

59

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Numerically increasing levels of LOD (e.g., 1, 2, 3) correspond to tile datasets with
progressively finer resolution (smaller spatial sampling intervals).
The x-axis and y-axis fixed increment unit per LOD, XUnitLOD and YUnitLOD, are given per
Equation (2–5).
𝑋𝑋𝑋𝑋𝑋𝑋𝑋𝑋𝑋𝑋 =𝑋𝑋𝑋𝑋𝑋𝑋𝑋𝑋𝑋𝑋
2

(2–5)

𝑌𝑌𝑌𝑌𝑌𝑌𝑌𝑌𝑌𝑌
𝑌𝑌𝑌𝑌𝑌𝑌𝑌𝑌𝑌𝑌 = 2

Similarly, the number of units in the x-axis and y-axis and the total number of units in a CDB
geocell, respectively defined by NbXUnitInCDBGeocellLOD, NbYUnitInCDBGeocellLOD, andTotalNbUnitInSliceLOD, are computed by Equation (2–6).
𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 = 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁  ×  2𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 = 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁  ×  2
(2–6)
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇= 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁   ×  𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁The CDB standardizes tile sizes to 1024 × 1024 (e.g., 1024 XUnitLOD by 1024 YUnitLOD). Thus,
for positive LODs, every tile quadruples its geographic area coverage as the LOD decreases.
Since the CDB Specification limits each earth slice to NbYUnitInCDBGeocell (or 111319 m),tiles at LOD 0 have the same height as the height of an earth slice. For negative LODs, the same
tile size is maintained. This imposes that the number of units in both x-axes and y-axes arerecursively divided by two for every subsequent level until the total number of unit reaches one
by one unit. LOD –10 is the coarsest LOD represented by a CDB slice. The finest available
LOD number for the CDB is 23. Table 2-4 presents the complete list of CDB LODs with thecorresponding grid size, tile size, and the resulting approximate grid spacing at the equator.

Table 2-4: CDB LOD versus Tile and Grid Size
CDB LOD

Grid Size(n × n)Approximate Tile Edge Size(meters)

Approximate Grid Spacing(meters)

-10
-9
-8
-7
-6
-5
-4
-3
-2
-1
0
1

1
2
4
8
16
32
64
128
256
512
1024
1024

1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
5.56595 × 10+04

1.11319 × 10+05
5.56595 × 10+04
2.78298 × 10+04
1.39149 × 10+04
6.95744 × 10+03
3.47872 × 10+03
1.73936 × 10+03
8.69680 × 10+02
4.34840 × 10+02
2.17420 × 10+02
1.08710 × 10+02
5.43550 × 10+01© 2015 Open Geospatial Consortium

60

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CDB LOD

Grid Size(n × n)Approximate Tile Edge Size(meters)

Approximate Grid Spacing(meters)

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024
1024

2.78298 × 10+04
1.39149 × 10+04
6.95744 × 10+03
3.47872 × 10+03
1.73936 × 10+03
8.69680 × 10+02
4.34840 × 10+02
2.17420 × 10+02
1.08710 × 10+02
5.43550 × 10+01
2.71775 × 10+01
1.35887 × 10+01
6.79437 × 10+00
3.39719 × 10+00
1.69859 × 10+00
8.49297 × 10-01
4.24648 × 10-01
2.12324 × 10-01
1.06162 × 10-01
5.30810 × 10-02
2.65405 × 10-02
1.32703 × 10-02

2.71775 × 10+01
1.35887 × 10+01
6.79437 × 10+00
3.39719 × 10+00
1.69859 × 10+00
8.49297 × 10-01
4.24648 × 10-01
2.12324 × 10-01
1.06162 × 10-01
5.30810 × 10-02
2.65405 × 10-02
1.32703 × 10-02
6.63513 × 10-03
3.31756 × 10-03
1.65878 × 10-03
8.29391 × 10-04
4.14696 × 10-04
2.07348 × 10-04
1.03674 × 10-04
5.18369 × 10-05
2.59185 × 10-05
1.29592 × 10-05

As a result, at LOD −10, a tile covers an area of approximately 111 km × 111 km and isrepresented by a single grid element. At the opposite end of the table, at LOD 23, a tile covers aminuscule area of 13 mm × 13 mm with a corresponding grid spacing of about 13 µm.
Note the line corresponding to LOD 0; it highlights the point where the grid size stops increasing
while the tile size starts decreasing. Figure 2-3 illustrates the hierarchy of CDB Tile LODs.

© 2015 Open Geospatial Consortium

61

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 2-3: Tile-LOD Hierarchy© 2015 Open Geospatial Consortium

62

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2.1.2.1
Tile-LOD Area Coverage Rules
A tile from LOD –10 to LOD 0 occupies the area of exactly one CDB Geocell. This is true for
all CDB Geocells from all CDB Zones. Starting with LOD 1 and up, this area is recursively
subdivided into smaller tiles, every level corresponding to a finer representation of the previous
level allowing for multiple levels of details. 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 theprevious LOD.
Figure 2-4, Earth Slice Example (Five Levels-of-Detail), shows an earth slice represented withfive distinct LODs. In the illustration, certain CDB Geocell of the earth slice is represented withall five LODs, while others have only three or four LODs. Each Geocell, when present, isrepresented by an instance of at least the coarsest tile supported by the CDB Specification, i.e.,
one tile at LOD −10. In addition, if a tile exists at LOD n, not all 4 tiles at LOD n+1 need toexist. However, if a tile is present at LOD n, it implies that a corser 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)© 2015 Open Geospatial Consortium

63

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2.1.2.2
Tile-LOD Hierarchy Rules
The CDB Specification further imposes that the LOD hierarchy of all tiled dataset must becomplete for every CDB Geocell. However, each CDB Geocell may have a different number ofTile-LODs.
2.1.2.3
Tile-LOD Replacement Rules
In general, finer tiles replace coarser tiles. The actual rules are:1. For negative levels of details, a tile at LOD n replaces exactly one tile at
LOD n−1 since both tiles cover the same area.
2. For positive levels of details, a tile at LOD n is replaced by 4 tiles at LOD n+1
since tiles from LOD n+1 cover only a quarter of the area covered by the tileat LOD n.
In the case of positive LODs, note that it is not necessary that all 4 tiles from LOD n+1 exist; aslong as one of the four tiles is present, the replacement of the tile at LOD n can take place.
For instance, one tile at LOD −1 is replaced by one tile at LOD 0 which is in turn replaced byfour tiles at LOD 1. The replacement of coarser tiles with finer tiles stops when no finer tiles
exist.
2.1.3
Handling of the North and South Pole
Zones 0 and 10 (South and North Pole) are processed differently than the other zones. As per
Table 2-2: Size of CDB Geocell per Zone, this corresponds to an earth slice of 1 × 30 CDB
Geocells.
As shown in Figure 2-2: Variation of Longitudinal Dimensions versus Latitude, a single CDB
Geocell at the poles covers 12 degrees in longitude and 1 degree in latitude within a single slice.
As a geographic position gets closer and closer to the poles in terms of latitude, fewer points are
required in the data grid; however the CDB Geocell still has a regular rectangular shape.
Therefore, this implies that grid points will be progressively super sampled in longitude in orderto respect the grid format of the CDB.
In CDB Zone 0, the bottom edges of the 30 geocells of the zone all converge and collapse to asingle point, the South Pole. However, the data that belong exactly to the South Pole is found ina single Geocell, the one whose lower left corner is at −90° of latitude and 0° of longitude. The
redundant data representing the South Pole found in the other 29 geocells of zone 0 is ignored.
Similarly, in CDB Zone 10, the top edges of the 30 geocells of the zone also converge andcollapse to a single point, the North Pole. Again, the data that belong exactly to the North Pole isfound in a single Geocell whose lower left corner is at +89° of latitude and 0° of longitude. The
redundant data representing the North Pole found in the other 29 geocells of zone 10 is ignored.
The case of raster datasets that make use of the corner grid conventions is an exception since the
CDB does not provide the means of representing data at precisely the North Pole (+90° of
latitude and 0° of longitude). In this case, it is recommended that client-devices use the averageof the nearest grid elements in the immediate vicinity of the North Pole.

© 2015 Open Geospatial Consortium

64

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2.2
File System Requirements
The CDB Specification is file system independent, (i.e., it does not mandate the use of a specificfile system). However, compliance to the CDB Specification does require that the file system beable to support a minimal set of capabilities listed below:
1.

File name/Directory name structure:a. Character set: in accordance to Table 2-5: Character Set Used for CDB
Files and Folders.
b. Length of filename (including path to file): 256 characters or more.
c. Length of filename extension: “dot” followed by three characters or
more
Minimum Directory structure:a. Number of files or directories in root directory: 256 entries or more.
b. Number of files or directories per directory (except root): 2048 entries
or morec. Depth of directory hierarchy: 9 or more (assuming at least 256 entries
per directory level).
d. Directory size: 128 KB or more (assuming 64 bytes per directory
entry).
File Size: 64 Mbytes or more.
Number of files per volume: 41,600 files or more (assuming 650 MB CD
with 16 Kbyte files.
Support for removable media.
Support for bootable/non-bootable volume.

2.

3.
4.
5.
6.
2.2.1

Character Set
Table 2-5: Character Set Used for CDB Files and Folders
Dec

Hex

32

20

33

21

34

Char

Dec

Hex

Char

Dec

Hex

Char

64

40

@

96

60

`

!

65

41

A

97

61

a

22

“

66

42

B

98

62

b

35

23

#

67

43

C

99

63

c

36

24

$

68

44

D

100

64

d

37

25

%

69

45

E

101

65

e

38

26

&

70

46

F

102

66

f

39

27

'

71

47

G

103

67

g

40

28

(

72

48

H

104

68

h

41

29

)

73

49

I

105

69

i

42

2A

*

74

4A

J

106

6A

j

43

2B

+

75

4B

K

107

6B

k

44

2C

,

76

4C

L

108

6C

l

45

2D

-

77

4D

M

109

6D

m

© 2015 Open Geospatial Consortium

65

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Dec

Hex

Char

Dec

Hex

Char

Dec

Hex

Char

46

2E

.

78

4E

N

110

6E

n

47

2F

/

79

4F

O

111

6F

o

48

30

0

80

50

P

112

70

p

49

31

1

81

51

Q

113

71

q

50

32

2

82

52

R

114

72

r

51

33

3

83

53

S

115

73

s

52

34

4

84

54

T

116

74

t

53

35

5

85

55

U

117

75

u

54

36

6

86

56

V

118

76

v

55

37

7

87

57

W

119

77

w

56

38

8

88

58

X

120

78

x

57

39

9

89

59

Y

121

79

y

58

3A

:

90

5A

Z

122

7A

z

59

3B

;

91

5B

[

123

7B

{

60

3C

<

92

5C

\

124

7C

|

61

3D

=

93

5D

]

125

7D

}

62

3E

>

94

5E

^

126

7E

~

63

3F

?

95

5F

_

127

7F

2.2.2
A word about case-sensitivenessOne of the intent guiding the development of the CDB Specification is the possibility of
implementing it on modern operating systems whether they are Windows-like or Unix-like.
Throughout this Specification, the reader will notice that file names and directory paths are
specified using a mix of upper and lower cases. This choice is made to improve and ease thereadability of those names.
However, it is important to note that no two names are to differ only by their case. After all, aname 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 (andeven HoUsE) all convey the same idea of a residence where people live. And this stays true forall combination of cases.
As a result, the CDB Specification demands that all names appear exactly as specified in thisdocument, including the appendices.

© 2015 Open Geospatial Consortium

66

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2.3
Light Naming
The CDB Specification provides the means to unambiguously tag any modeled light point45 witha descriptive name. This provides client-devices with the information necessary to control all
light points that have been tagged with a name that conforms to this Specification.
The CDB Specification provides a comprehensive set of light types, particularly well suited to
the needs of Visual simulation. Light types include those found on:
cultural features including point, lineals, areals, and specialized airport
systems
air, land, and surface platforms
life forms
munitions
Each light type defined by this Specification, corresponds to a real-world light type. The
Specification provides a definition of each light type, which is representative of the light type’sfunction rather that its characteristics. The client-devices use the light type name as an index toderive the properties and characteristics of the light. The approach is client-device independent
because the (device-specific) client rendering parameters are not stored in the CDB and are
therefore invisible to the modeler and the database tools. The modeler/tools need not be
concerned with dozens of parameters that describe the light’s properties and characteristics. The
client-devices internally build and initialize a table of light properties and characteristics for theirrespective use. The table is nominally built at CDB load time and is built to match the device’s
inherent capabilities and level-of-fidelity.
The light point types are structured in a hierarchy that is designed to simplify the modeler’s
workload. Increasing levels of specialization are possible if a modeler specifies light names
located in deeper levels of the light naming hierarchy, i.e., the more specialized the light, thedeeper the level.
An extract from the light naming hierarchy is illustrated in Figure 2-5: Extract from Light
Naming Hierarchy as an example. This portion of the light naming hierarchy concerns itself
with lights used for “Line-based Cultural” light points (e.g., streets, highways). Immediately
below the “Line-Based” level, the modeler can choose from a wide selection of lights such as
Fluorescent_Light, Incandescent_Light, or Sodium_Light. A modeler that does not want toconcern itself with the particular characteristics of highway lights may choose to tag its lights
with a name that is higher up in CDB light name hierarchy. On the other hand, a modeler thathas more elaborate source data and has more time at his disposal may choose to differentiate
between “Multilane_Divided_Hwy” and “Highway” and/or “Sodium” and “Incandescent”
lighting (further down in the CDB light name hierarchy).

45

The CDB Specification does not distinguish between a light-point and a light-source. In the simulation industry,
the term light-point refers to a point source of light that does not illuminate its immediate surroundings. Likewise,
the term light-source refers to a point source of light capable of illuminating its immediate surroundings.

© 2015 Open Geospatial Consortium

67

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
White light indicating the presence of an hazard around the airport

HazardFlashing_LightWhite hazard flashing light

Hi_Intensity_LightWhite Hi-Intensity hazard lightLine-Based

Generic Line based lights (Linear features as Roads)

Fluorescent_Light

Fluorescent based Light

Incandescent_Light

Incandescent based Light

Mercury_Light

Mercury based Light

Metal_Halide_Light

Metal Halide based Light

Sodium_Light

Sodium based Light

Multilane_Divided_Hwy

Generic Multi-lane divided highway lights

Incandescent_Light

Incandescent based Light

Mercury_Light

Mercury based Light

Metal_Halide_Light

Metal Halide based Light

Sodium_Light

Sodium based LightMedianMedian divider Lights

Edge

Highway edge/sidewalk lights
Generic Multi-lane highway lights

Multilane_Hwy
Incandescent_Light

Incandescent based Light

Mercury_Light

Mercury based Light

Metal_Halide_Light

Metal Halide based Light

Sodium_Light

Sodium based LightMedianMedian divider Lights

Edge

Highway edge/sidewalk lights

Highway

Generic Single Lane Highway

Incandescent_Light

Incandescent based Light

Mercury_Light

Mercury based Light

Metal_Halide_Light

Metal Halide based Light

Sodium_Light

Sodium based Light

Figure 2-5: Extract from Light Naming Hierarchy

The name of a light is composed as follows. Starting from the top-most level of the hierarchy,
concatenate each of the names encountered with the backslash46 “\” character. Go down throughhierarchy until the desired level of specificity is encountered.
Here are a few examples:\Light\Platform: A light suitable for use on all platforms\Light\Platform\Air\Aircraft_Helos\Formation_Light: A formation light foruse on aircraft and helicopter platforms\Light\Platform\Land\Headlight\High_Beam_Light: A high-beam head-lightfor use on land vehicles\Light\Cultural\Line-based\Highway: A light suitable to depict highway
lighting\Light\Cultural\Line-based\Highway\Incandescent_Light: A light used to
depict incandescent highway lighting

46

The CDB Specification uses the backslash character as a separator for light names. In no time should thereader assume that the Specification is favoring the Windows operating system which is also using the backslash asa separator when building directory paths. Again, the backslash is simply a separator for names.

© 2015 Open Geospatial Consortium

68

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2.3.1
Adding Names to the CDB Light Name Hierarchy
The hierarchy also permits modelers to reference light types that are not defined by the current
version CDB Specification. This can be achieved by adhering to the following procedure.
First, the modeler or the simulator vendor is required to a) create a new light type name with its
corresponding light code, b) provide a definition for the light type name c) insert the new lighttype into the light name hierarchy d) edit the Lights.xml metadata file to reflect the change to theLight Name Hierarchy and e) optionally provide values for Description, Intensity, Color,
Frequency, Duty_Cycle… in the Lights_xxx.xml files. If the new entry has no values for
Description, Intensity, etc, the new light type will immediately inherit all of the properties andcharacteristics of CDB-native light types higher up in the light hierarchy. If the new entry
requires one or more of the fields stated in Section 2.3.2, Light Type Modeler Tuning, it will beassigned those characteristics.
Note that the level of rendering fidelity is a function of customer requirements and/or thevendor’s capabilities.
The user may also elect to propose his new light name for inclusion into subsequent versions of
the CDB Specification.
Since the light type codes are global to the CDB, it is strongly recommended that none of theexisting light type codes be modified when adding a new light type; failure to do this would
require a complete recompilation of the CDB in order to map light point type name to their
newly assigned light point type codes. For this reason, it is recommended that the CDB tools
create new light type codes so that light relationships within the CDB remain coherent.
2.4
Model Component Naming
The CDB Specification provides the means to unambiguously tag any portion of a 3D model(moving model or cultural feature) with a descriptive name. As a result, client-devices have theinformation necessary to control all of the model components that have been tagged with a namethat conforms to this Specification.
The CDB Specification provides a comprehensive set of model components, particularly well
suited to the needs of simulation. Model components include those used on:
1.
air platforms
2.
buildings
3.
land platforms
4.
missile and rocket platforms
5.
surface (maritime) platforms
6.
pylons and posts
Each model component defined by this Specification (refer to Appendix F for a listing of theModel Components) corresponds to a real-world model component. The client-devices use thename as an index to provide the simulation software the needed control over the component inquestion.

© 2015 Open Geospatial Consortium

69

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Examples of model components are Cockpit, Turret, Rudder, Engine, Anchor, Flight_Deck, Tire,
Landing_Gear, Chimney, etc.
Chapter 6, CDB OpenFlight Models provides details on how to use one of these names to
identify a particular model component.
2.4.1
Adding New Model Components
The user may propose missing model component names for inclusion into subsequent versions of
the Specification. In the meantime, the missing name can be used to tag a specific modelcomponent and a simulation client-device can use that name to detect and control the newcomponent.
2.5
Materials
This portion of the CDB Specification deals with the handling of materials that make up thesynthetic environment. The CDB Specification provides a flexible means to store and represent
materials found in the CDB representation of the synthetic environment.
In general, materials are inputs to production or manufacturing. They are often raw - that is
unprocessed, but are sometimes processed before being used in more advanced production
processes. A material represents the substance or substances out of which a thing is or can be
made.
The CDB Specification provides the means to represent:
Z

Basic (homogeneous) materials such as steel, aluminum, copper, sand, soil,stone, glass, concrete, wood, water, rubber. CDB materials are chosen for
their relevance to simulation, in particular, thermal spectrum simulation.

Z

Aggregates or mixtures of basic materials

Z

Composite materials, i.e., a structured arrangement of basic materials or of
aggregates which together represent a composite’s material that has:o A Surface Substrateo A Primary Substrateo One or more optional Secondary Substrates
Appendix L of this Specification provides a list of CDB Base Materials. All references toComposite Materials must, in the end, resolve down to one or more of the stated CDB BaseMaterials.
Sensor simulation typically requires a simulation of the device itself, supplemented by acomplete simulation of the synthetic environment over the portion of the electromagnetic
spectrum that is relevant to this device. The former simulation is referred to as the Sensor
Simulation Model (SSM) while the latter is called the Sensor Environmental Model (SEM).
Most SEMs in existence today rely heavily on environmental database whose content is designed
to match the functionality, fidelity, structure and format requirements of the SEM. The level of© 2015 Open Geospatial Consortium

70

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
realism possible by the SEM depends heavily on the quality, quantity and completeness of thedata available. This makes the environmental database highly device-specific.
The task of determining a definitive list of material properties that would accommodate all of theabove requirements for the today’s sensor types, vendor implementations and SEMs would be asignificant challenge. Instead, the CDB Specification defines and publicly defines a list of
materials that can be used in a CDB. It is the responsibility of vendors to (internally) define theproperties (that satisfies the sensor type) for these CDB materials. Vendors are totally free toselect material properties that satisfy the fidelity, functionality and precision requirements of the
SEM for the sensor type of interest. Section A.1 of Appendix A provides a rationale for theapproach taken by the CDB Specification.
2.5.1
Base Materials
A Base Material represents a basic (primitive) material such as water, vegetation, concrete, glass,steel. Each Base Material has a unique name. The components of a Base Material are listed inTable 2-6: Components of a Base Material. The Base Material name must be unique, since it canbe used as an index or search key in other tables (described in subsequent sections) of the CDB
structure.
Table 2-6: Components of a Base Material

Component

Name *

Description

Name used to represent a Basic Material.

Describes the essential nature of the basic material
represented. A typical example can also be provided in the
Description
description field* Uniquely identifies the Base Material.
The Base Material’s name always begins with the “BM_” string, followed by a unique arbitrary
string that respects the following conventions:Z

Contains letters, digits, the underscore (_) or the hyphen (-) characters.

Z
The Base Material Name including its prefix string is limited to 32 characters.
The description of a material class gives the essential nature of the basic material represented.
Appendix L presents all of the Base Materials currently defined by the CDB Specification.
2.5.1.1
Base Material Table (BMT)A Base Material Table (BMT) is provided for run-time access by client applications. See section
5.1.3, Base Material Table for details on the file format.
2.5.2
Composite Materials
This section provides additional description and details regarding the layered substrate structure
to Base Materials, aka Composite Materials.

© 2015 Open Geospatial Consortium

71

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Each Composite Material consists of a primary substrate component, an optional surface
component and one or more optional secondary substrate components. Each of thesecomponents is in turn composed of one or more Base Materials described in the previous section.
Components that are composed of two or more Base Materials are aggregates. Each Composite
Material has a primary substrate as a minimum. The primary and secondary substrates can be
optionally assigned a thickness (in meters). By definition, the surface substrate corresponds tothe first µm to mm of a Composite Material. The surface substrate does not change the nature of
the primary substrate; its purpose is to differentiate the object's primary substrate from its
coating.
Each substrate is defined by a variable-size structure that references one or more Base Materials.
Each Base Material is assigned a weight ranging from 1% to 100%. The sum of the weights
assigned to the Base Materials of each component must sum to 100%. For example, a mixture
aggregate of 75% sand and 25% soil, would be constructed as a Composite Material with a
primary substrate component with Base Materials BM_SAND (75% weight) and BM_SOIL(25% weight); in this example, there is no surface substrate and no secondary substrates.
2.5.2.1
Composite Material Substrates
A substrate provides a means to describe the material composition of “hidden” materials locatedbeneath (or inside) the surface of a feature. This information is not explicitly modeled using (forinstance) polygons; instead it is an essential characteristic of the material that makes up themodeled 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 besand 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.

© 2015 Open Geospatial Consortium

72

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

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© 2015 Open Geospatial Consortium73

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In order to capture different thermal signatures for the top and bottom portions of the tank, amodeler 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).

Thermal Infrared

VisibleFigure 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 thesurface 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 thisparticular example.
2.5.2.2
Composite Material Tables (CMT)
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 useof the index value in order to select Composite Materials.
There are several Composite Material Tables spread across the CDB hierarchy. Note howeverthat 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.

© 2015 Open Geospatial Consortium

74

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Here is the XML notation for a Composite Material Table:<Composite_Material_Table><Composite_Material index="..."><Name>...</Name><Surface_Substrate><Material><Name>...</Name><Weight>...</Weight></Material><!-- Insert other Material as needed --></Surface_Substrate><Primary_Substrate><Material><Name>...</Name><Weight>...</Weight></Material><!-- Insert other Material as needed --><Thickness>...</Thickness></Primary_Substrate><Secondary_Substrate><Material><Name>...</Name><Weight>...</Weight></Material><!-- Insert other Material as needed --><Thickness>...</Thickness></Secondary_Substrate><!-- Insert other Secondary_Substrate as needed --></Composite_Material><!-- Insert other Composite_Material as needed --></Composite_Material_Table>

There can be only one Primary_Substrate and it is mandatory. There can be only one
Surface_Substrate and it is optional. The Secondary_Substrate and the Thickness are optional.
To specify aggregates (more than one material attribute in the MIT), the Material block isrepeated. 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. The base materials that make each substrate must be listed in decreasingorder of weighting.
Each composite material must be tagged with a non-negative integer index, zero being reserved
for default value that is assigned by the database tools. In addition, each composite material canbe optionally tagged with a descriptive name. The CDB composite material table mechanism© 2015 Open Geospatial Consortium

75

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014provides the means to tag each CDB composite material with a database tool-specific ormodeler-specific composite material name.
2.5.2.3
Example 1
Consider a linear feature in the CDB 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_PAINTASPHALT.
2.5.2.4
Example 2
Consider a terrain areal feature in the GSFeature dataset of the CDB. The areal feature covers alarge wetland area that contains 4 Base Materials, namely BM_SOIL (21%), BM_WATERFRESH (51%), BM_LAND-LOW_MEADOW (26%) and BM_SAND (2%). The areal featurereferences 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).
2.5.3
Bringing it all Together
Figure 2-9: Flow of Material Attribution Data illustrates the flow of material attribution datafrom features in the CDB right through to the client-device.
Each of the raster features of the CDB can (and should) reference a Composite Material. The
reference points to an entry into a Composite Material Table. Each CDB tile has a Composite
Material Table. The impact of additions, deletions, and modifications to the Composite Material
Table are limited to only those features that make up the tile; this reduces the compilation timeassociated with the production of Composite Material Table data.
Likewise, zones and polygons within an OpenFlight model can optionally reference one or more
Composite Materials. The references each point to entries into a Composite Material Table thatis associated with the model. Each model can have an associated Composite Material Table.
The impact of additions, deletions, and modifications to the Composite Material Table arelimited to only those features that make up the model; this reduces the generation time associatedwith the production of Composite Material Table data for the model.
In turn, each of the entries in the Material Composite Table has one or more references to BaseMaterials entries of the Base Materials Table. The Base Materials Table is global to the CDB
and its contents are defined and governed by this Specification.

© 2015 Open Geospatial Consortium

76

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Local to CDB Tile
Composite
Material
Table

DatasetGlobal to CDB

Local to the Client-device SEM

CDB’s BaseMaterial
Table

SEM Base
Material Table

key3
key18
key21
key13
key7
key36
key28
key24
key31
key4


CMIX









S1 P 1 P 2 P 3 S1

Surface substrate
Primary substrate
Feature locallyreferences aComposite Material

S2

Secondary
substratematerial0material1
material2
material3
material4
material5
material6
material7
material8
material9
material10
material11
material12
material13
material14
material15
material16
material17
material18
material19

Secondary
substrate

Composite Materials each reference
one or more (global) Base Materials

α ε γ τ µ

CDB’s Base Materials each reference
SEM Base Materials and hence SEM
material properties

Figure 2-9: Flow of Material Attribution Data

2.5.4
Determination of Material Properties by SEM
The association of material properties to features in the CDB requires two distinct steps.
1.

2.

The first step consists in establishing a correspondence between all of theBase Materials in the CDB and the Base Materials directly supported by
the SEM of the client-device. This is a manual task performed by the
SEM specialist(s). The specialist must ensure that his SEM has acorresponding Base Material for each of the CDB Base Materials. In
cases where the SEM is simple, it is possible for two or more CDB BaseMaterials to point to the same SEM Base Material. Alternately the SEM
specialist may chose to create new SEM Base Materials that correspond
more closely to the CDB’s Base Materials. The result of this process is a
SEM look-up.

The second step is typically undertaken during the CDB initialization by
the client-device running the SEM. During this initialization phase, theSEM reads the content of the global Base Material Table and the SEM
look-up provided by the SEM specialist. This look-up establishes anindirect link between the Base Materials in the CDB and the material
properties of the client-device’s SEM Base Materials. In fact, the indirect
link (i.e., the look-up table) can be eliminated if the client device© 2015 Open Geospatial Consortium

77

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
internally builds a Materials Properties Table that uses the CDB material
keys directly (as illustrated in Figure 2-11: SEM Base Material Properties
Table).
Global: Belongs to the CDB

External: Belongs to the SEM

CDB Base
Material

References from
Composite Materials

key3
key18
key21
key13
key7
key36
key28
key24
gen31
key4

SEM's
Look-Up
Table
0
1
2
3
4
5
6
7
8
9

SEM's BaseMaterial Table

10
7
9
17
2
0
4
11
1
12

material0material1
material2
material3
material4
material5
material6
material7
material8
material9
material10
material11
material12
material13
material14
material15
material16
material17
material18
material19

Step 1Off-line

α ε γ τ µ

key36
gen31
key7
key28
key18
key21
key3
key24
key4
key37
key151
key13

Step 2
Run-time

Figure 2-10: Linking CDB Base Materials to SEM Base Materials
CDB Base
Material
Table

References from
Composite Materials

key3
key18
key21
key13
key7
key36
key28
key24
gen31
key4

SEM's
Base Material
Properties Table
0
1
2
3
4
5
6
7
8
9

α10
α7
α9
α17
α2
α0
α4
α11
α1
α12

ε10
ε7
ε9
ε17
ε2
ε0
ε4
ε11
ε1
ε12

γ10
γ7
γ9
γ17
γ2
γ0
γ4
γ11
γ1
γ12

τ10
τ7
τ9
τ17
τ2
τ0
τ4
τ11
τ1
τ12

µ10
µ7
µ9
µ17
µ2
µ0
µ4
µ11
µ1
µ12

Figure 2-11: SEM Base Material Properties Table

2.5.4.1
ExampleIn the example of Section 2.5.2.4, Example 2, we have a Composite Material consisting of four
Base Materials. For the purpose of this example, we will associate hypothetical keys to thesematerials:© 2015 Open Geospatial Consortium

78

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
water
(key3 = "BM_WATER-FRESH", BMT's index 0)
vegetation (key21 = " BM_LAND-LOW_MEADOW", BMT's index 2)
soil(key7 = " BM_SOIL ", BMT's index 4)
sand(key4 = " BM_SAND ", BMT's index 9)
The SEM specialist establishes the following correspondence between the CDB Base Materials
and his materials (step 1):
key3 to material 8 ("Lake", SEM list's index 8)
key21 to material 3 ("Uncultivated Land", SEM list's index 3)
key7 to material 7 ("Soil", SEM list's index 7)
key4 to material 12 ("Sand", SEM list's index 12)
During the CDB initialization process (step 2), a look-up table is built as follows:
BMT’s index 0 is associated to SEM list's index 8
BMT’s index 2 is associated to SEM list's index 3
BMT’s index 4 is associated to SEM list's index 7
BMT’s index 9 is associated to SEM list's index 12
2.5.5
Generation of Materials for Inclusion in CDB Datasets
In the case of vector data, the generation of the material information typically requires themodeler to apply an image classification process to the terrain raster imagery. Many industrystandard tools offer this classification capability.
Following this step, the resultant material classified raster imagery is vectorized into areals
and/or lineals. Note that the quality of the image classification typically improves with theavailability of multi-spectral terrain imagery data. Also note that these two steps can be skipped
if the vectorized datasets already exist in digital form.
The classification of the terrain imagery can be done directly against the Base Materials definedby Appendix L of this Specification. In this case, the modeler need not be aware of the BaseMaterials mandated by the CDB Specification. This can be done because the tools can abstract
these Base Materials and provide the modeler with an alternate selection of materials. The
selection of materials provided to the modeler is quite arbitrary. This indirect step allows
modelers to work with the “materials” they are familiar with. Nonetheless, the tools must, in theend, build the Composite Material Tables required by the CDB Specification and resolve allmaterial references into the Base Materials supported by this Specification. In effect, theComposite Material Table is used to map the modeler’s materials into CDB Base Materials.
Alternately, the classification of the terrain imagery can be done against whatever “material
classes” modelers are accustomed to use when conducting such classifications. In this case, theSEM specialist can define corresponding Composite Materials for each of these material classes
so that they resolve down to the Base Materials supported by the CDB.

© 2015 Open Geospatial Consortium

79

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In the case of 3D models, the modeler is required to appropriately tag zones or selected polygons
with the appropriate materials. Here again, the modeler need not be aware of the Base Materials
mandated by the CDB Specification and can work with the materials he is most familiar with.

© 2015 Open Geospatial Consortium80

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 3
3
CDB StructureThis chapter defines the structure of the CDB, 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 Specification is the fact that all CDB file names are unique and that the filename alone
is sufficient to infer the path to get to the file.
The CDB is composed of several datasets that usually reside in their own directory structure;
however some datasets share a common structure. The following sections present the directory
structures of all CDB datasets.
3.1
Top-Level CDB Structure Description
The top-level directory structure of the CDB from the root directory is described below. All of
the synthetic environment content falls in these directories:
1. \CDB\:
This is the root directory of the CDB. It does not need to be “\CDB\” and canbe any valid path name on any disk device or volume under the target filesystem it is stored on. In order for the text of this Specification to remainreadable, all examples referring to the root CDB path name will start with
\CDB\. A CDB cannot be stored directly in the root directory of a disk device
or volume. A CDB path name cannot be within another CDB or CDB version.
The length of the path name leading to the CDB root directory should be smallenough such that the platform file system can store all possible file path names
stored within a CDB. All of the files stored within a CDB must be under theroot directory or within a subdirectory under the root directory of the CDB, as
specified in this document. Run-time applications must be given the path anddevice on which the CDB is stored in order to access the CDB.
The CDB Specification also has provisions for the handling of multiple,
incremental versioning of the CDB. To support this capability, run time
applications must first access a predetermined version of the CDB and all its
predecessors to determine content changes to the CDB. If no change isencountered in any of the incremental versions, the applications are required touse the content of the active default CDB. The versioning mechanism is doneat the file level. Refer to Section 3.2, CDB Configuration Management, fordetails on how CDB supports incremental versioning.
2. \CDB\Metadata\:
The directory that contains the specific XML metadata files which are global
to the CDB. The directory structure and metadata descriptions are defined in
Section 3.1.1, Metadata Directory.

© 2015 Open Geospatial Consortium

81

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3. \CDB\GTModel\:This is the entry directory that contains the Geotypical Models Datasets. The
directory structure is as defined in Section 3.4, GTModel Library Datasets.
4. \CDB\MModel\:This is the entry directory that contains the Moving Models Datasets. The
directory structure is defined in Section 3.5, MModel Library Datasets.
5. \CDB\Tiles\:This is the entry directory that contains all tiles within the CDB instance. The
directory structure is defined in Section 3.6, CDB Tiled Datasets.

6. \CDB\Navigation\:
This is the entry directory that contains the global Navigation datasets. The
directory structure is defined in Section 3.7, Navigation Library Dataset
Most of the CDB datasets are organized in a tile structure and stored under \CDB\Tiles\
directory. The tile structure facilitates access to the information in real-time by the runtime
client-devices. However, for some datasets such as Moving Models or geotypical models
datasets that require minimal storage, there is no significant advantage to be added from such atile structure. Such datasets are referred to as global datasets; they consist of data elements thatare global to the earth, i.e., no structure other than the datasets is provided.
3.1.1
Metadata Directory
There is one directory containing metadata files that are global to the overall CDB structure.
\CDB\Metadata contains metadata files that define the various sets of naming hierarchies anddefinitions used throughout the CDB. File content is described in Section 5.1, Metadata
Datasets. Most metadata files (except one) are optional and CDB users must implement default
behaviors, according to information contained in this Specification. The \CDB\Metadata
directory contains the following metadata files:
1. “Lights” Definitions Metadata file:
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 lighttype hierarchy. A listing of the CDB light type hierarchy can be found in
Appendix E. The hierarchy found in Appendix E must be used when
“Lights.xml” is not found in the metadata directory. Refer to section 5.1.1
Light Name Hierarchy Metadata for a description of the light point namehierarchy file.
2. “Model_Components” Definitions Metadata file:
This file contains the metadata that defines the CDB model components.
Refer to Section 2.4, Model Component Naming, for a description of themodel components. A listing of the CDB model components can be found in
Appendix F. Refer to section 5.1.2 Model Components Definition Metadata
for a description of the model component file.
3. “Materials” Definitions Metadata file:
This file contains the base material names for the CDB. Refer to Section 2.5,

© 2015 Open Geospatial Consortium82

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Materials, for a description of the CDB materials. A listing of the CDB BaseMaterials can be found in Appendix L. The base material names found inappendix L must be used when the “Materials.xml” file is not found in themetadata directory. Refer to section 5.1.3 Base Material Table for a
description of the materials definition file.
4. “Defaults” Definitions Metadata 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. Appendix S
lists the various default values as documented throughout this Specification.
Defaults values found in appendix S must be used if the “Defaults.xml” file is
not found in the metadata directory. Refer to section 5.1.4 Default Values
Definition Metadata for a description of the defaults definition file.
5. “Specification_Version” Metadata file (deprecated)

6. “Version” Metadata 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.6, Version Metadata.
7. “CDB_Attributes” Metadata file:
This file is used to describe all the CDB attributes that are supported by the
CDB Specification. A complete listing and description of CDB attributes isprovided in section 5.7.1.3, CDB Attributes of this Specification. The file isdescribed in section 5.1.7 CDB Attributes Metadata.
8. “Geomatics_Attributes” Metadata file:
This file is used to describe all Geomatics attributes that may be referenced bythis CDB (refer to section 5.7.1.2.6.2, Geomatics Attributes for a descriptionof Geomatics attributes). Note that the usage of Geomatics attribution falls
outside of the jurisdiction of the CDB Specification. Nonetheless, the CDB
Specification 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.8, Geomatics
Attributes Metadata.
9. “Vendor_Attributes” Metadata file:
This file is used to describe all Vendor attributes that may be referenced bythis 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 Specification. Nonetheless, the CDB
Specification 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.9, Vendor Attributes
Metadata.
10. Client-specific Metadata files:
These files are limited to “Lights_xxx.xml” Definitions Metadata files andoffer a complementary approach to modifying the appearance of lights for© 2015 Open Geospatial Consortium83

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
specific client-devices. The “xxx” suffix is a 32-character string placeholderthat stands for the client-device name. There can only be one such file perclient-device and the files for each client-device are optional. Refer to section
5.1.1.1, Client Specific Lights Definition Metadata for a description of theclient specific lights definition file.
11. “Configuration” Metadata file:
This file provides the means of defining CDB Configurations. The concept isdefined in section 3.2.4, CDB Configuration; the content of the file is definedin section 5.1.10, Configuration Metadata.
3.1.2
Metadata File Examples
Each CDB Version has a metadata file whose complete path and file name is:\CDB\Metadata\Version.xml

A Forward Looking Infrared client device named “FLIR” has a client specific metadata filehaving the following directory path and file name:\CDB\Metadata\Lights_FLIR.xml

3.2
CDB Configuration Management
The CDB Configuration and CDB Version mechanisms allow users to manage the Common
Database (CDB). The two mechanisms permit the users to implement Configuration
Management (CM) and versioning by offering the following capabilities:
The Common Database (CDB) can have multiple simultaneous independent CDB
Configurations.
Each CDB Configuration is defined by an ordered list of CDB Versions.
A CDB Version is either a collection of pure CDB Datasets or a collection ofuser-defined datasetso in which case the CDB Version is called a CDB Extension
3.2.1
CDB Version
A CDB Version is a collection of pure CDB Datasets and/or user-defined datasets. A CDB
Version contains data belonging to a single version of the Specification. A CDB Version may
refer to another CDB Version. This is the basis for the CDB File Replacement Mechanism. The
concept of a CDB Version is illustrated by the UML diagram below.

© 2015 Open Geospatial Consortium

84

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

CDB Version

0..1-CDB Datasets-CDB Specification Version-CDB Version
0..*
CDB Dataset-data

Figure 3-1: UML Diagram of CDB Version Concept	
  The diagram shows that a CDB Version contains CDB Datasets; in addition it states which CDB
Specification Number has been used to build the CDB content; finally, the CDB Version has areference 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. The figure below illustrates the chaining of
CDB Versions belonging to different CDB Specification Number.

CDB Spec 3.2

CDB Spec 3.1

CDB Spec 3.0

CDB Version 3

CDB Version 2

CDB Version 1

Figure 3-2: A Valid Chain of CDB Versions

The figure above shows three (3) CDB Versions, each containing data compliant to a different
version of the Specification. It shows that CDB Version 3 (on the left) complies with version 3.2of the Specification and refers (the blue line) to CDB Version 2 (in the middle), a 3.1-compliant
database, which in turn refers to CDB Version 1 (to the right), a 3.0-compliant database.
Each CDB Version has its own Version.xml file in its Metadata folder. As such, the smallest
CDB Version contains a single file:\CDB\Metadata\Version.xml© 2015 Open Geospatial Consortium

85

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Since a CDB is made of at least one CDB Version, an empty and valid CDB has exactly one file,
Version.xml, and all other datasets assume their default values.
3.2.1.1
CDB Extensions
A CDB Extension is a special CDB Version that is making use of the extension mechanism
defined by this Specification 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 theSpecification and is completely left to the user. The following UML diagram defines the CDB
Extension concept.

CDB Version

0..1-CDB Datasets-CDB Specification Version-CDB Version

0..*
CDB Dataset-data

CDB Extension-name-version0..*User Dataset-data

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.
3.2.2
CDB Version Directory Structure
The files and the directory structure of CDB Versions are defined in subsequent section of thischapter. There can be an arbitrary number of CDB Versions in the CDB.
The root of each CDB Version can have any valid path name47 on any disk device or volume
under the target file system it is stored on. A CDB Version cannot be stored directly in the root47

As defined in section 2.2, File System© 2015 Open Geospatial Consortium86Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
directory of a disk device or volume. A CDB Version path name cannot be within another CDB
Version. The length of the path name leading to the CDB Version directory should be smallenough such that the platform file system can store all possible file path names stored within a
CDB version.
The path to the boot CDB Version is the entry point that must be provided to all client-device
applications when loading the CDB synthetic environment. Run-time applications must haveaccess, directly or indirectly, to all disk devices and volumes as well as all paths to all linked
CDB Versions simultaneously.
3.2.3
CDB File Replacement Mechanism
The CDB File Replacement Mechanism allows content to be added, deleted and modified fromthe CDB. A file is said to exist in two (or more) CDB Versions when its relative path and nameare the same in each version. This mechanism describe herein defines how to handle identicalfiles found in multiple CDB Versions. Each CDB Version can contain a set of additions,modifications and deletions with respect to prior CDB Versions.
Figure 3-4 illustrates the case where a modeler has created a CDB Version that contains anadditional level-of-detail to a wellhead OpenFlight model. When processed by a client
application, the “effective” CDB now contains both the AA051_Wellhead_LOD0.flt and theAA051_Wellhead_LOD1.flt files.

Figure 3-4: Adding content to the CDB

The process of modifying files is similar to adding files; any files that have been modified areinserted in a new CDB Version. Figure 3-5: Modifying Content of the CDB, illustrates the casewhere a modeler has modified level-of-detail #1 of a wellhead OpenFlight model. When© 2015 Open Geospatial Consortium87

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
processed by a client application, the “effective” CDB now contains the modified version of theAA051_Wellhead_LOD1.flt.

Figure 3-5: Modifying Content of the CDB

A CDB Version can be created when content needs to be deleted from a prior CDB Version.
The instruction to remove content from the CDB is triggered from the null files (e.g., files thatare empty and whose size is zero) that are encountered within a CDB Version. Whenever aclient application encounters a null file, it stops searching for it in prior CDB Versions andconsider the file absent from the CDB. Figure 3-6: Deleting Content from the CDB, illustrates
the case where a modeler has deleted level-of-detail #1 of a wellhead OpenFlight model. When
processed by a client application, the “effective” CDB no longer contains theAA051_Wellhead_LOD1.flt OpenFlight file.

© 2015 Open Geospatial Consortium88Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 3-6: Deleting Content from the CDB

3.2.3.1
How to Handle Archives
The CDB File Replacement Mechanism works at the file level, as the name implies. For thisreason, in the case of geospecific 3D model (GSModel) datasets whose files are stored in 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.
3.2.3.2
How to Handle the Metadata Directory
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 mustalso 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, it must
retrieve and use the Metadata of that CDB Version to correctly interpret the data obtained from
it.
3.2.4
CDB Configuration
A CDB Configuration defines a list of CDB Versions. The following UML diagram presents the
CDB Configuration concept.

© 2015 Open Geospatial Consortium

89

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CDB Configuration+Comment+CDB Version Lists
1..*
CDB Version List
+CDB Specification Version+CDB Versions

1..*
CDB Version+Comment+Path

CDB Extension+Name+Version

Figure 3-7: UML Diagram of CDB Configuration Concept

The UML diagram tells us that a CDB Configuration is a collection of one to many Lists of CDB
Versions. Each list of CDB Versions belongs to a single version of the CDB Specification andhas a collection of one to many CDB Versions. Note that a CDB Extension is a CDB Version
that is making use of the extension mechanism defined by this Specification to supplement the
CDB with user-defined data.
The Configuration.xml metadata file provides the means of defining a CDB Configuration. The
file resides in the Metadata folder of the CDB as follows:\CDB\Metadata\Configuration.xml

When a client application opens a CDB, it searches the Metadata folder for the presence of theConfiguration.xml file. If the file is found, the client uses its content to access all CDB Versions
that are making up this CDB configuration. Otherwise, the client falls back to the mechanism
associated with Version.xml. Note that when the client finds Configuration.xml, it does not needto open any of the Version.xml files associated with the CDB Versions referred to by the CDB
Configuration; i.e., the purpose of the Configuration.xml file is to avoid reading multiple
Version.xml files scattered all over the CDB.
3.2.5
Management of CDB Configurations and Versions
The performance of real-time simulation systems is directly affected by the number of CDB
versions in the currently active CDB configuration. Unless the number of versions is bounded,
performance guarantees cannot be provided by client-devices.

© 2015 Open Geospatial Consortium

90

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Since a CDB is usually intended for use in real-time simulation systems, it is strongly
recommended that all CDB chains be limited to no more than 8 CDB versions48. Failure to do
this may result in unsuitable delays when performing simulator repositions or may lead to paging
artifacts at higher speeds and/or lower-altitudes. Client-device data sheets should specify thecriteria under which performance can be guaranteed for the specified training requirements.
In the case where a CDB is solely intended as an off-line (read-write) repository it is permissible
to have chains with up to 50 versions. Database processing times may increase with chain
lengths, commensurate with storage system access times.
3.3
CDB Model Types
The cultural features of a CDB can be represented using one of the following types of modeled
representations:a) GTModel: 3D modeled geotypical representation of a point-feature that isanchored to the ground.
b) GSModel: 3D modeled geospecific representation of a point-, lineal- or arealfeature that is anchored to the ground.
c) T2DModel: 2D modeled geospecific or geotypical representations of point-, lineal
and areal features that are anchored to the ground.
d) MModel: 3D modeled representations of point-features that are not anchored to
the ground.
The modeled representation of a feature primarily consists of its geometry and textures, andencompasses its exterior and interior.

In this Specification, the following terms and expressions will be used:
The term Model refers to all of the modeled representations of a culturalfeature.
The term Model-LOD refers to a specific level of detail of a Model.
The term 2DModel refers to the modeled representations of a 2D feature, i.e.,a feature that has no significant height with respect to the underlying terrain.
The term 2DModel-LOD refers to a specific level of detail of a 2DModel.
The term 3DModel refers to the modeled representation of a 3D feature thatcan be readily distinguished from the underlying terrain. In the case where the48

For instance, this would allow for configurations that consist of 1 version for a background world, 3
versions for each of the CDB specification versions, 1 version for dynamic changes, and 3 modeling content
versions (1 content version for each specification version).

© 2015 Open Geospatial Consortium91

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3DModel is unique, it is referred to as a GSModel. In the case where the3DModel 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 ispositioned by the modeler, it is called a statically-positioned MModel.
The term 3DModel-LOD refers to a specific level of detail of a 3DModel.
3.3.1
GTModel (Geotypical 3D Model)
A feature is said to have a 3D geotypical modeled representation if it is associated with a 3D
Model that is typical of the feature’s shape, size, textures, materials, and attributes. The use ofgeotypical models is appropriate if the modeler does not wish to fully replicate all of the uniquecharacteristics (e.g., shape, size, texture) of a feature, as they are in the real-world. When afeature is represented by a geotypical model, the modeler is in effect stating that two or morefeatures of the same type (i.e., same FACC) have the same modeled representation.
3.3.2
GSModel (Geospecific 3D Model)
A feature is said to have a 3D geospecific modeled representation if it is associated with a 3Dmodel that is unique in shape, size, texture, materials, and attributes. The use of geospecificmodels is appropriate if the modeler wishes to fully replicate all of the unique characteristics(e.g., shape, size, texture) of a feature, as they are in the real-world. As a result, a geospecificmodel usually corresponds to a unique real-world recognizable cultural feature. Real-world
features such as the Eiffel Tower, the Pentagon, or the CN Tower, to name a few, are usuallymodeled as geospecific.
3.3.3
T2DModel (Tiled 2D Model)
A feature is said to have a 2D modeled representation if it is associated with a modeled
representation that has no significant height with respect to the underlying terrain and generally
conforms to the terrain profile. It is convenient to think of the 2D Models as a complement andas an extension to the Primary Elevation and (VSTI) Imagery datasets. 2D Models provide themeans to represent 2D surface features that are conformed to the underlying terrain:a) Modeled representation of geotypical and geospecific 2D lineal-features such as
roads, runways and taxiways, stripes.
b) Modeled representation of geotypical and geospecific 2D areal-features such as
aprons, surface markings, contaminants, land usage (campgrounds, farms, etc.).
2D Models can also be used to model geotypical terrain textures as a mesh of 2D textured
polygons overlaying the terrain. This modeling technique replicates approaches used in early
Image Generators which had limited ability to page-in geospecific terrain textures.
3.3.4
MModel (Moving 3D Model)
A moving model is typically characterized as such if it can move (on its own) or be moved.
More specifically within the context of the CDB Specification, the model is not required to be
attached to a cultural point feature.

© 2015 Open Geospatial Consortium92

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
During the course of a multi-player simulation49, each client-device is typically solicited toprovide a modeled representation of each of the players. The activation of such players requiresthat the client-device access the appropriate modeled representation for each of players. There
are a large number of military simulations where the player types are characterized by their DIS
code. To this end, the CDB provides a moving model library whose structure provides aconvenient categorization of models by their DIS code.
3.3.5
Use of GSModels and GTModels
Sections 3.3.1 and 3.3.2 illustrate cases where the choice to represent a feature with either ageotypical (GTModels) or a geospecific model (GSModels) is more clear-cut. This section gives
additional insight into the considerations and trade-offs that go with associating a point-feature
with either a geotypical or a geospecific modeled representation. By characterizing a feature as
geotypical, the modeler makes a statement as to the expected usage of the feature (and its
associated modeled representation) within the CDB.
When a feature is tagged as geotypical…
a) the modeler is making a statement about his knowledge of the very highprobability of repeatedly encountering that model type within the CDB and…
b) the modeler is making a statement that he will likely associate the same modeled
representation (same shape, size, texture, materials, or attributes, etc.) for thefeature type – as a result, the client-devices can count on the fact that the model
will be heavily replicated throughout the CDB. The characterization of a model
as geotypical tells the consumers of the CDB that the model is heavily usedthroughout the CDB and that it may be cached in memory for re-use.
The manner in which geotypical models are stored / accessed differs from their geospecificcounterparts. Geotypical models are stored in their own directory structure; this group of models
is referred collectively as the GTModel library. The storage structure of the GTModel libraryprovides a convenient categorization of models by their FACC and their level-of-detail. As aresult, geotypical models can be managed as a global library of 3D models that are used to fill
the CDB with cultural detail.
The above discussion applies equally to statically-positioned moving models. The manner inwhich statically-positioned moving model features (and their modeled representations) are stored
and accessed is similar to geotypical models; it differs however in the fact that the MModellibrary provides a categorization of models by their DIS code. The model is fetched from theMModel library regardless of whether it is used as statically-positioned model by the modeler orwhether it is dynamically-positioned by the client-device during the simulation.
Conversely, when a feature is tagged as geospecific…

49

The players may be virtual (e.g., other simulators), synthetic (e.g., computer-generated simulations) or may be live
(real-world players playing alongside virtual or synthetic players).

© 2015 Open Geospatial Consortium

93

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014a) the modeler is making a statement about his knowledge of the very low
probability of encountering (typically only once) that feature type within the CDBor…
b) the modeler is making a statement regarding his intention to associate a uniquemodeled representation (different shape, size, texture, materials, or attributes, etc.)
for that feature – as a result, the client-devices can assume that the feature will
never share the same modeled representation with other features (e.g., no model
replication) within the CDB. Real-world recognizable cultural point features (saythe Eiffel Tower, the Pentagon, the CN Tower) are usually modeled as
geospecific.
GSModels have a storage organization that is consistent with Tiled datasets. The storage
organization of tiled datasets has been optimized to efficiently access CDB content by its lat-longlocation, its level-of-detail and its dataset component type. Like all of the CDB Tiled datasets,
geospecific models are stored in the \CDB\Tiles\ directory. As a result, client-devices canreference each model with a unique directory path and a unique file name which is derived fromthe model’s unique position, level-of-detail, and its FACC feature code.
In most cases, the decision to invoke a modeled representation of a feature as either geotypical or
geospecific is clear. When it comes to real-world recognizable cultural features, therepresentation of these features is clearly a geospecific model because it is encountered once inthe entire CDB and it is unique in its shape, texture, etc. At the end of the spectrum, many
simulation applications use a generic modeled representation for each feature type and theninstance that modeled representation throughout the synthetic environment. For this case, thechoice is clearly geotypical.
There are cases however, where the decision to represent features as either geotypical or
geospecific is not as clear-cut. For instance, a modeler may not be satisfied with a single
modeled representation for all the hospital features (FACC-FSC = AL015-006); accordingly, he
may wish to model two or more variants of hospitals in the CDB. While each of these modeled
representation may not be real-world specific, they are nonetheless variants of hospitals (say bysize or by region or country for example). Usually, the primary motivation for such variations is
one of esthetics and realism; it is not necessarily motivated by the need to accurately reflect realworld features.
In making his decision, the modeler should factor-in the following trade-offs:a) CDB Storage Size: The size of the CDB is smaller when the cultural featuresreference geotypical models rather than geospecific models. This is due to thefact that the modeled representation of geotypical model is not duplicated withineach tile – instead, the model appears once in the GTModel library dataset
directory. Clearly, a geotypical model is the preferred choice if the modeler
wishes to assign and re-use the same modeled representation for a given feature
type.
b) Client-device Memory Footprint: By assigning a geotypical model to a feature,
the modeler provides a valuable “clue” to the client-device that the feature will be© 2015 Open Geospatial Consortium

94

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
instanced throughout the CDB with the same modeled representation. As a result,client-device should dedicate physical memory for the storage of the geotypicalmodels for later use.
c) GTModel Library Management: The CDB’s Feature Data Dictionary (FDD) isbased on the DIGEST, DGIWG, SEDRIS and UHRB geomatics standards. Thesestandards are commonly used for the attribution of source vector data in a broad
range of simulation applications. The CDB Feature Data Dictionary acts much
like what an English dictionary is to a collection of novels. As a result, it ispossible to develop a universal GTModel Library which is totally independent of
the CDB content (just like a dictionary is independent of books). This universal
GTModel Library can be simply copied into the \CDB\GTModel directory. The
structure of the GTModel Library is organized in accordance to the CDB’s FDD –in other words, the models are indexed using the CDB Feature Access Code
(FACC). The indexing approach greatly simplifies the management of the model
library since every model has a pre-established location in the library.
d) CDB Generation and Update: As mentioned earlier, the size of the CDB issmaller when the cultural features reference geotypical models rather thangeospecific models. This is due to the fact that the modeled representation ofgeotypical model is not duplicated within each tile – instead, the model appears
once in the GTModel library dataset directory. This reduces the amount of timerequired by the tools to generate and store the CDB onto the disk storage system.
The second benefit of geotypical models comes in the case where a modeler
wishes to change the modeled representation of one or more geotypical features
type across the entire CDB. Changes to the modeled representation of a feature
type can easily be performed by simply overwriting the desired model in model
library. From then on, all features of that type now reference the updated model –no other changes to the CBD are required.
Note that since the size of the GTModel library is likely to exceed the client-device’s model
memory, the client-device must implement a caching scheme which intelligently discards models
or portions of models that are deemed less important, used infrequently or not used at all50. It is
up to the client-device to accommodate for the disparity between the size of client-device’s
model memory and the size of the GTModel library. Clearly when the disparity is large, thecaching algorithm is solicited more frequently and there is more “trashing” of the cache’scontent. The key to a successful implementation of a caching scheme resides in an approach
which discards information not actively or currently used by the client-device. The CDB
specification offers a rich repertoire of attribution information so that client-devices can

50

For example, a caching scheme could be based on the model’s frequency of use (computed by the client-device
during the simulation), the model’s Relative Tactical Importance Code (RTAI), the model’s Bounding Sphere (BSR)and scale (SCAL), and the model’s Bounding Box (BBH, BBL, BBW). Failure to cache the model would result in
the wasteful refetching of the geotypical model from the disk storage system each time it is invoked. This would
greatly increase disk storage system IO and reduce client-device paging performance. In the worst-case, the clientdevice’ performance from a memory usage and disk storage bandwidth point-of-view is no worse than ofgeospecific models© 2015 Open Geospatial Consortium

95

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
accomplish this task optimally51. Consequently, the client-devices can smartly discard model
data that is not in use (e.g., models and/or, textures) during the course of a simulation. Note thatin more demanding cases, client-devices may have to resort to a greater level of sophisticationand determine which levels-of-detail of the model geometry and/or model texture are in use inorder to accommodate cache memory constraints. It is clearly in the modeler’s interest to avoid
widespread usage of model variants within the GTModel Library. In doing so, the modeleroverly relies on the client-devices abilities to smartly manage its model cache52. As a result, runtime performance may suffer.
As mentioned earlier, the modeled representation of a geotypical model is not duplicated withineach tile – instead, the model appears once in the GTModel library dataset directory. As a result,once the model is loaded into memory, it can be referenced without inducing a paging event to
the CDB storage system. Clearly, the paging requirements associated with geotypical features
are negligible. As a result, paging performance is improved because of the reduced IO
requirements on the CDB storage system.
3.3.6
Organizing Models into Levels of Details
The geometry, texture, and signature datasets of 3D models are organized into levels of details(LOD) based on their resolutions. The expression of the model resolution depends on thedataset; the resolution of the model geometry is called its Significant Size (SS); the texture
resolution is expressed by its Texel Size (TS); and for the radar signature of a model, its
resolution is simply its size and is measured by the diameter of its Bounding Sphere (BSD).
The lower bounds (LB) of SS, TS, and BSD for a given LOD can be expressed by the following
set of equations.
𝐿𝐿𝐿𝐿 > 111319 2   𝑚𝑚𝐿𝐿𝐿𝐿 > 111319 2   𝑚𝑚𝐿𝐿𝐿𝐿 > 111319 2   𝑚𝑚In all three equations, the value 111319 represents the approximate length in meters of an arc of
one degree at the equator53.

51

Failure to cache the model would result in the wasteful refetching of the geotypical model from the disk storage
system each time it is invoked. This would greatly increase disk storage system IO and reduce client-device paging
performance.
52

Client-devices with less capable memory management might simply refuse to load geotypical models once thememory is exhausted.
53

The actual equation to obtain the values of 111319 m is 𝐿𝐿 = 𝑎𝑎×where “a” is the length of the major semi-axis
���°of the WGS-84 ellipsoid; “a” is also known as the equatorial radius.

© 2015 Open Geospatial Consortium

96

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
For convenience, the following table gives the CDB LOD associated with these three measuresof the resolution of a model. Note that all values are expressed in meters using a scientificnotation with 6 decimals.

Table 3-1: CDB LOD vs. Model Resolution
ModelGeometry

ModelTexture

ModelSignature

CDB LOD

Significant Size

Texel Size

Bounding Sphere-10

SS > 5.565950 × 10+4

TS > 6.957438 × 10+3

BSD > 4.452760 × 10+5

-9

SS > 2.782975 × 10+4

TS > 3.478719 × 10+3

BSD > 2.226380 × 10+5

-8

SS > 1.391488 × 10+4

TS > 1.739359 × 10+3

BSD > 1.113190 × 10+5

-7

SS > 6.957438 × 10+3

TS > 8.696797 × 10+2

BSD > 5.565950 × 10+4

-6

SS > 3.478719 × 10+3

TS > 4.348398 × 10+2

BSD > 2.782975 × 10+4

-5

SS > 1.739359 × 10+3

TS > 2.174199 × 10+2

BSD > 1.391488 × 10+4

-4

SS > 8.696797 × 10+2

TS > 1.087100 × 10+2

BSD > 6.957438 × 10+3

-3

SS > 4.348398 × 10+2

TS > 5.435498 × 10+1

BSD > 3.478719 × 10+3

-2

SS > 2.174199 × 10+2

TS > 2.717749 × 10+1

BSD > 1.739359 × 10+3

-1

SS > 1.087100 × 10+2

TS > 1.358875 × 10+1

BSD > 8.696797 × 10+2

0

SS > 5.435498 × 10+1

TS > 6.794373 × 10+0

BSD > 4.348398 × 10+2

1

SS > 2.717749 × 10+1

TS > 3.397186 × 10+0

BSD > 2.174199 × 10+2

2

SS > 1.358875 × 10+1

TS > 1.698593 × 10+0

BSD > 1.087100 × 10+2

3

SS > 6.794373 × 10+0

TS > 8.492966 × 10−1

BSD > 5.435498 × 10+1

4

SS > 3.397186 × 10+0

TS > 4.246483 × 10−1

BSD > 2.717749 × 10+1

5

SS > 1.698593 × 10+0

TS > 2.123241 × 10−1

BSD > 1.358875 × 10+1

6

SS > 8.492966 × 10−1

TS > 1.061621 × 10−1

BSD > 6.794373 × 10+0

7

SS > 4.246483 × 10−1

TS > 5.308104 × 10−2

BSD > 3.397186 × 10+0

8

SS > 2.123241 × 10−1

TS > 2.654052 × 10−2

BSD > 1.698593 × 10+0

9

SS > 1.061621 × 10−1

TS > 1.327026 × 10−2

BSD > 8.492966 × 10−1

© 2015 Open Geospatial Consortium

97

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
ModelGeometry

ModelTexture

ModelSignature

CDB LOD

Significant Size

Texel Size

Bounding Sphere10

SS > 5.308104 × 10−2

TS > 6.635129 × 10−3

BSD > 4.246483 × 10−1

11SS > 2.654052 × 10−2

TS > 3.317565 × 10−3

BSD > 2.123241 × 10−1

12SS > 1.327026 × 10−2

TS > 1.658782 × 10−3

BSD > 1.061621 × 10−1

13

SS > 6.635129 × 10−3

TS > 8.293912 × 10−4

BSD > 5.308104 × 10−2

14SS > 3.317565 × 10−3

TS > 4.146956 × 10−4

BSD > 2.654052 × 10−2

15SS > 1.658782 × 10−3

TS > 2.073478 × 10−4

BSD > 1.327026 × 10−2

16

SS > 8.293912 × 10−4

TS > 1.036739 × 10−4

BSD > 6.635129 × 10−3

17SS > 4.146956 × 10−4

TS > 5.183695 × 10−5

BSD > 3.317565 × 10−3

18

SS > 2.073478 × 10−4

TS > 2.591847 × 10−5

BSD > 1.658782 × 10−3

19

SS > 1.036739 × 10−4

TS > 1.295924 × 10−5

BSD > 8.293912 × 10−4

20

SS > 5.183695 × 10−5

TS > 6.479619 × 10−6

BSD > 4.146956 × 10−4

21

SS > 2.591847 × 10−5

TS > 3.239809 × 10−6

BSD > 2.073478 × 10−4

22

SS > 1.295924 × 10−5

TS > 1.629905 × 10−6

BSD > 1.036739 × 10−4

23

SS > 0TS > 0

BSD > 0

When using the table to perform a lookup, first compute the value of SS, TS, or BSD, then scanthrough the lines of the table starting at the top with LOD −10; when the computed value islarger than the lower bound of the LOD, select that LOD. Since the values of SS, TS, and BSD
are, by definition, always positive, the search for a LOD will always be successful; in the worst
case, the search will end with the last line of the table.
3.3.7
Organizing Models into Datasets
GSModel, GTModel, and MModel are organized into multiple datasets representing theirexterior shell and interior, and their geometry and texture. The exterior of a model is called its
shell and is composed of a set of datasets representing its geometry (ModelGeometry andModelDescriptor) and its textures (ModelTexture, ModelMaterial, and ModelCMT). Similarly,
the interior of a model is divided into geometry (ModelInteriorGeometry andModelInteriorDescriptor) and textures (ModelInteriorTexture, ModelInteriorMaterial, andModelInteriorCMT) datasets.

© 2015 Open Geospatial Consortium98

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.3.8
Terms and Expressions
When referring to 3D Models, the Specification makes use of a number of terms and expressions
that are frequently mentioned throughout the text; these terms and expressions are defined below.
3.3.8.1
Feature Classification
The CDB Specification has an important Feature Data Dictionary (FDD) whose origins aretraceable to the DIGEST v2.1 Specification. However, the current FDD is a consolidation of the
DIGEST, DGIWG, SEDRIS, and UHRB dictionaries. The CDB FDD makes use of FACC
codes to classify features. To provide an even better classification of features, the Specification
defines an additional attribute called the FACC feature sub-code (FSC). By extending the FACC
hierarchy structure in this manner, it is possible to define a broader set of model types than ispossible with strict implementation of the FACC feature codes. The FACC sub-code value andits significance depend on the FACC feature code. Refer to Appendix N for a list of the FACC
feature sub-code.
FACC and FSC are two CDB attributes defined in sections 5.7.1.3.24 and 5.7.1.3.25
respectively.
One of the uses of FACC feature codes by the Specification is to create a hierarchy of
subdirectories by taking advantage of the manner in which a FACC is built. A FACC featurecode 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 Specification will use these three parts to compose the following
hierarchy of folders:\A_Category\B_Subcategory\999_Type\

Where A is the first character of the FACC code, Category is the category name, B is the second
character of the FACC code, Subcategory is the subcategory name, 999 are the 3rd, 4th, and 5th
characters of the FACC code, and Type feature type as per Appendix N.
3.3.8.2
Model Name
When a feature is represented by a 3D model, the model itself is given a name that is used tobetter describe or differentiate two features having the same FACC and FSC codes. Even though
the model name is left to the discretion of the modeler, the Specification recommends the use of
the FACC name as the model name. FACC names are listed in appendix N. In the case ofMoving 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.
3.3.8.3
DIS Entity TypeCDB 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:© 2015 Open Geospatial Consortium

99

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1. Kind
2. Domain
3. Country
4. Category
5. Subcategory
6. Specific
7. ExtraThe 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’svalue (1 to 3 digits), followed by an underscore “_”, and concatenated with the field’s name as
per Appendix M.
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.
3.3.8.4
Texture Name
The name of 3D model textures is a character string having a minimum of 2 characters and amaximum length of 32 characters. The first two characters must be alphanumeric. Examples ofvalid 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 acronym TNAM represents the texture name and is used to compose texture file anddirectory names. The following directory structure is used by CDB Model texture-related
datasets:\A\B\TNAM\

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, atexture named “house” will be stored in a directory tree with the following structure:\H\O\house\© 2015 Open Geospatial Consortium

100

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.3.8.5
Level of Detail
The terms “Level of Detail” and its acronym “LOD” are generally well known to the intended
audience of this Specification. In the context of the CDB Specification, filenames and directory
names will be composed from the concept of LOD. The Specification uses a numeric scale toclassify a LOD between 34 levels numbered from −10 to +23. The details will be provided laterin the document. At this point, it is sufficient to define the convention used throughout theSpecification to designate a particular LOD.
The Specification designates a LOD by appending its level to the uppercase letter L. When thelevel 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.
3.4
GTModel Library Datasets
The \CDB\GTModel\ folder is the root directory of the GTModel library which is composed of
the following datasets:
1. GTModelGeometry
2. GTModelTexture
3. GTModelDescriptor
4. GTModelMaterial
5. GTModelCMT
6. GTModelInteriorGeometry
7. GTModelInteriorTexture
8. GTModelinteriorDescriptor
9. GTModelInteriorMaterial
10. GTModelInteriorCMT
11. GTModelSignature
These datasets are stored in five (5) different directory structures described in the subsections
below.
3.4.1
GTModel Directory Structure 1: Geometry and Descriptor
This directory structure holds the geometry-related datasets of the GTModel Library; they are:
1. Dataset 500, GTModelGeometry Entry File
2. Dataset 510, GTModelGeometry Level of Detail
3. Dataset 503, GTModelDescriptor
The directory structure has 5 levels and is based on the FACC code of the model (see section
3.3.8.1).

© 2015 Open Geospatial Consortium

101

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 3-2: GTModelGeometry Directory Structure

Directory
Level

Directory
Name

Description

Level 1

500_GTModelGeometry The name of the directory is composed ofthe dataset code followed by an underscore
and the dataset name.

Level 2

A_Category

The first character of the FACC code iscalled the “Feature Category”. The nameof the directory is composed of the firstcharacter (denoted A) of the category namefollowed by an underscore and the categoryname (denoted Category) as per Appendix
N.

Level 3

B_Subcategory

The second character of the FACC code iscalled the “Feature Subcategory”. The
name of the directory is composed of thefirst character (denoted B) of thesubcategory name followed by anunderscore and the subcategory name(denoted Subcategory) as per Appendix N.

Level 4

999_Type

The 3rd, 4th, and 5th characters of the FACC
code are called the “Feature Type”. The
name of the directory is composed of thefeature type (denoted 999) followed by anunderscore and the name (denoted Type)
associated with the feature type as per
Appendix N.

Level 5LOD

Character L followed by the LOD number
corresponding to the Significant Size forpositive levels of detail. Characters LC
followed by the LOD number
corresponding to the Significant Size fornegative levels of detail.

3.4.1.1
GTModelGeometry Entry File Naming Convention
The files of the GTModelGeometry Entry File dataset are stored in level 4 of the 5-level
directory structure presented above. The names of the files adhere to the following naming
convention:
D500_Snnn_Tnnn_FACC_FSC_MODL.flt© 2015 Open Geospatial Consortium

102

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The following table defines each field of the file name and Table 5-9 provides the values of theComponent Selectors to complete the name.

Table 3-3: GTModelGeometry Entry File Naming Convention

Field

Description

D500
Snnn
Tnnn
FACC
FSC

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
Five-character FACC feature code as defined in Appendix N
Three-digit integer representing the FACC feature sub-code (FSC) as
defined in Appendix N
MODL 32-character Model Name Stringflt
The file type associated with the dataset (OpenFlight file)
3.4.1.2
GTModelGeometry Level of Detail Naming Convention
The files of the GTModelGeometry Level of Detail dataset are stored in level 5 of its directory
structure. The names of the files adhere to the following naming convention:
D510_Snnn_Tnnn_LOD_FACC_FSC_MODL.flt

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

Table 3-4: GTModelGeometry Level of Detail Naming Convention

Field

Description

D510
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2This field is identical to the name of the LOD directory (level 5) where
the file is stored.
FACC Five-character FACC feature code as defined in Appendix N
Three-digit integer representing the FACC feature sub-code (FSC) as
FSC
defined in Appendix N
MODL 32-character Model Name Stringflt
The file type associated with the dataset (OpenFlight file)© 2015 Open Geospatial Consortium

103

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.4.1.3
GTModelDescriptor Naming Convention
The files of the GTModelDescriptor dataset are stored in level 4 of the 5-level directory structure
presented above. The names of the files adhere to the following naming convention:
D503_Snnn_Tnnn_FACC_FSC_MODL.xml

The following table defines each field of the file name and Table 5-9 provides the values of theComponent Selectors to complete the name.
Table 3-5: GTModelDescriptor Naming Convention

Field

Description

D503
Snnn
Tnnn
FACC
FSC

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
Five-character FACC feature code as defined in Appendix N
Three-digit integer representing the FACC feature sub-code (FSC) as
defined in Appendix N
MODL 32-character Model Name Stringxml
The file type associated with the dataset
3.4.1.4
ExamplesThe following example illustrates the directory structure that would store the entry file of all
geotypical buildings with a FACC 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 FACC categories, \A_Culture is the directory containing all FACC
subcategories of category A (named Culture), \L_Misc_Feature is the directory containing all
FACC types of category A and subcategory L (named Misc_Feature), \015_Building is the
directory containing all OpenFlight files representing geotypical buildings whose FACC types
are 015 (named Building).
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.

© 2015 Open Geospatial Consortium

104

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
If the castle above (AL015_004_Castle) is represented with 3 levels of details, say LOD 3, 5 and8, 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

3.4.2
GTModel Directory Structure 2: Texture, Material, and CMTThis directory structure holds the texture-related datasets of the GTModel Libray; they are:
1. Dataset 501, GTModelTexture (Deprecated)
2. Dataset 511, GTModelTexture
3. Dataset 504, GTModelMaterial
4. Dataset 505, GTModelCMT
The directory structure has 4 levels and is based on the texture name.

Table 3-6: GTModelTexture Directory Structure

Directory
Level

Directory
Name

Description

Level 1

501_GTModelTexture The name of the directory is composed of thedataset code followed by an underscore andthe dataset name.

Level 2A

The name of the directory corresponds to thefirst character of texture name (TNAM), in
uppercase.

Level 3B

The name of the directory corresponds to thesecond character of texture name (TNAM), in
uppercase.

Level 4TNAM

The texture name has from 2 to 32 characters.
The first two characters must bealphanumeric.

Note that for compatibility with version 3.0 of the Specification, the name of the directory atlevel 1 is kept to 501_GTModelTexture eventhough dataset 501 has been deprecated andreplaced with dataset 511 in version 3.1 of the Specification.

© 2015 Open Geospatial Consortium

105

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.4.2.1
GTModelTexture Naming Convention
The names of the GTModelTexture files adhere to the following naming convention:
D511_Snnn_Tnnn_LOD_TNAM.rgb

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

Table 3-7: GTModelTexture Naming Convention

Field

Description

D511
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
The Level of Detail corresponding to the Texel Size of the texture as
explained in section 3.3.8.5.
TNAM The texture name; identical to the folder name where the texture resides.
rgb
The file type associated with the dataset (SGI Image)
3.4.2.2
GTModelMaterial Naming Convention
The names of the GTModelMaterial files adhere to the following naming convention:
D504_Snnn_Tnnn_LOD_TNAM.tif

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

Table 3-8: GTModelMaterial Naming Convention

Field

Description

D504
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
The Level of Detail corresponding to the Texel Size of the texture as
explained in section 3.3.8.5.
TNAM The material texture name; identical to the folder name where thematerial texture resides.
tif
The file type associated with the dataset (TIFF file)© 2015 Open Geospatial Consortium

106Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.4.2.3
GTModelCMT Naming Convention
The names of the GTModelCMT files adhere to the following naming convention:
D505_Snnn_Tnnn_TNAM.xml

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

Table 3-9: GTModelMaterial Naming Convention

Field
D505
Snnn
Tnnn
TNAM
xml

Description
Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
The material texture name; identical to the folder name where thematerial texture resides.
The file type associated with the dataset

3.4.2.4
ExamplesThe following example illustrates the directory structure that would store all files associated witha 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 whosename start with the letter ‘B’ or ‘b’, \R is the directory containing all textures whose name havethe letter ‘R’ or ‘r’ in the second position, and \Brick is the directory containing all texturerelated files whose name is ‘Brick’. Note that the second letter of the texture name is alowercase ‘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 thefollowing 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© 2015 Open Geospatial Consortium

107

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
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 thecorresponding 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 the following files would be found in the above
directory:.\D504_Snnn_Tnnn_LC02_Church-Gothic.tif.\D504_Snnn_Tnnn_LC01_Church-Gothic.tif.\D504_Snnn_Tnnn_L00_Church-Gothic.tif.\D504_Snnn_Tnnn_L01_Church-Gothic.tif.\D504_Snnn_Tnnn_L02_Church-Gothic.tif.\D504_Snnn_Tnnn_L03_Church-Gothic.tif.\D504_Snnn_Tnnn_L04_Church-Gothic.tif.\D504_Snnn_Tnnn_L05_Church-Gothic.tif.\D504_Snnn_Tnnn_L06_Church-Gothic.tif

The composite material table associated with the above material textures would reside in thesame directory and be named:.\D505_Snnn_Tnnn_Church-Gothic.xml

3.4.3
GTModel Directory Structure 3: Interior Geometry and Descriptor
This directory structure holds the datasets related to the geometry of the interior of a GTModel;
they are:
1. Dataset 506, GTModelInteriorGeometry
2. Dataset 508, GTModelInteriorDescriptor
The directory structure has 5 levels and is based on the FACC code of the model (see section
3.3.8.1).

© 2015 Open Geospatial Consortium

108

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 3-10: GTModelInteriorGeometry Directory Structure

Directory
Level

Directory
Name

Description

Level 1

506_GTModelInteriorGeometry The name of the directory iscomposed of the dataset code
followed by an underscore and thedataset name.

Level 2

A_Category

The first character of the FACC
code (denoted A), called the“Feature Category”, followed by anunderscore and the category name(denoted Category) as per
Appendix N.

Level 3

B_Subcategory

The second character of the FACC
code (denoted B), called the“Feature Subcategory”, followed byan underscore and the subcategoryname (denoted Subcategory) as per
Appendix N.

Level 4

999_Type

The 3rd, 4th, and 5th characters of the
FACC code (denoted 999), called
the “Feature Type”, followed by anunderscore and the name (denotedType) associated with the feature
type as per Appendix N.

Level 5LOD

The Level of Detail corresponding
to the Significant Size of the model
as explained in section 3.3.8.5.

3.4.3.1
GTModelInteriorGeometry Naming Convention
The files of the GTModelInteriorGeometry dataset are stored in level 5 of its directory structure.
The names of the files adhere to the following naming convention:
D506_Snnn_Tnnn_LOD_FACC_FSC_MODL.flt

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

© 2015 Open Geospatial Consortium

109

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 3-11: GTModelInteriorGeometry Naming Convention

Field

Description

D506
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2This field is identical to the name of the LOD directory (level 5) where
the file is stored.
FACC Five-character FACC feature code as defined in Appendix N
Three-digit integer representing the FACC feature sub-code (FSC) as
FSC
defined in Appendix N
MODL 32-character Model Name Stringflt
The file type associated with the dataset (OpenFlight file)
3.4.3.2
GTModelInteriorDescriptor Naming Convention
The files of the GTModelInteriorDescriptor dataset are stored in level 4 of the 5-level directory
structure presented above. The names of the files adhere to the following naming convention:
D508_Snnn_Tnnn_FACC_FSC_MODL.xml

The following table defines each field of the file name and Table 5-9 provides the values of theComponent Selectors to complete the name.
Table 3-12: GTModelInteriorDescriptor Naming Convention

Field

Description

D508
Snnn
Tnnn
FACC
FSC

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
Five-character FACC feature code as defined in Appendix N
Three-digit integer representing the FACC feature sub-code (FSC) as
defined in Appendix N
MODL 32-character Model Name Stringxml
The file type associated with the dataset.
3.4.3.3
ExamplesThe following example illustrates the directory structure that would store the interior of all
geotypical buildings represented at LOD 3 and whose FACC are AL015:\CDB\GTModel\506_GTModelInteriorGeometry\A_Culture\
L_Misc_Feature\015_Building\L03\© 2015 Open Geospatial Consortium

110Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Where \CDB\GTModel is the root of all geotypical model datasets,\505_GTModelInteriorGeometry is the directory containing all FACC categories, \A_Culture is
the directory containing all FACC subcategories of category A (named Culture),\L_Misc_Feature is the directory containing all FACC types of category A and subcategory L(named Misc_Feature), \015_Building is the directory containing all level of details representing
geotypical buildings whose FACC types are 015 (named Building), and \L03 is the directory
containing the OpenFlight files representing LOD 3 of these buildings.
Examples of files found in the above directory are:.\D506_S001_T001_L03_AL015_004_Castle.flt.\D506_S001_T001_L03_AL015_015_School.flt.\D506_S001_T001_L03_AL015_021_Garage.flt.\D506_S001_T001_L03_AL015_037_Fire_Station.flt.\D506_S001_T001_L03_AL015_050_Church.flt

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 thedirectory 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

3.4.4
GTModel Directory Structure 4: Interior Texture, Material, and CMTThis directory structure holds the datasets related to the textures of the interior of a GTModel;
they are:
1. Dataset 507, GTModelInteriorTexture
2. Dataset 509, GTModelInteriorMaterial
3. Dataset 513, GTModelInteriorCMT
The directory structure has 4 levels and is based on the texture name.

© 2015 Open Geospatial Consortium

111

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 3-13: GTModelInteriorTexture Directory Structure

Directory
Level

Directory
Name

Description

Level 1

507_GTModelInteriorTexture The name of the directory iscomposed of the dataset code
followed by an underscore and thedataset name.

Level 2A

The name of the directory
corresponds to the first character of
texture name (TNAM), in uppercase.

Level 3B

The name of the directory
corresponds to the second character of
texture name (TNAM), in uppercase.

Level 4TNAM

The texture name has from 2 to 32
characters. The first two charactersmust be alphanumeric.

3.4.4.1
GTModelInteriorTexture Naming Convention
The names of the GTModelInteriorTexture files adhere to the following naming convention:
D507_Snnn_Tnnn_LOD_TNAM.rgb

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

Table 3-14: GTModelInteriorTexture Naming Convention

Field

Description

D507
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
The Level of Detail corresponding to the Texel Size of the texture as
explained in section 3.3.8.5.
TNAM The texture name; identical to the folder name where the texture resides.
rgb
The file type associated with the dataset (SGI Image)© 2015 Open Geospatial Consortium

112

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.4.4.2
GTModelInteriorMaterial Naming Convention
The names of the GTModelInteriorMaterial files adhere to the following naming convention:
D509_Snnn_Tnnn_LOD_TNAM.tif

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

Table 3-15: GTModelInteriorMaterial Naming Convention

Field

Description

D509
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
The Level of Detail corresponding to the Texel Size of the texture as
explained in section 3.3.8.5.
TNAM The material texture name; identical to the folder name where thematerial texture resides.
tif
The file type associated with the dataset (TIFF file)
3.4.4.3
Example 1
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 isthe 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 gypsewall. 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 willbe 10 and the coarsest will be 2, and the following files would be found in the above directory:
D507_S001_T001_L02_BeigeGypseWall.rgb
D507_S001_T001_L03_BeigeGypseWall.rgb
D507_S001_T001_L04_BeigeGypseWall.rgb
D507_S001_T001_L05_BeigeGypseWall.rgb
D507_S001_T001_L06_BeigeGypseWall.rgb
D507_S001_T001_L07_BeigeGypseWall.rgb
D507_S001_T001_L08_BeigeGypseWall.rgb
D507_S001_T001_L09_BeigeGypseWall.rgb© 2015 Open Geospatial Consortium

113

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
D507_S001_T001_L10_BeigeGypseWall.rgb

3.4.4.4
Example 2
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 ChurchGothic. Note that the second letter of the material texture name is a lowercase ‘h’ but thecorresponding 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

3.4.5
GTModel Directory Structure 5: SignatureThis directory structure holds the datasets related to the radar signature of a GTModel; they are:
1. Dataset 502, GTModelSignature (Deprecated)
2. Dataset 512, GTModelSignature
The directory structure has 5 levels and is based on the FACC code of the model (see section
3.3.8.1).

Table 3-16: GTModelSignature Directory Structure

Directory
Level
Level 1

Directory
Name

Description

502_GTModelSignature The name of the directory is composed ofthe dataset code followed by an underscore
and the dataset name.

© 2015 Open Geospatial Consortium

114

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Directory
Level

Directory
Name

Description

Level 2

A_Category

The first character of the FACC code iscalled the “Feature Category”. The nameof the directory is composed of the firstcharacter (denoted A) of the category namefollowed by an underscore and the categoryname (denoted Category) as per Appendix
N.

Level 3

B_Subcategory

The second character of the FACC code iscalled the “Feature Subcategory”. The
name of the directory is composed of thefirst character (denoted B) of thesubcategory name followed by anunderscore and the subcategory name(denoted Subcategory) as per Appendix N.

Level 4

999_Type

The 3rd, 4th, and 5th characters of the FACC
code are called the “Feature Type”. The
name of the directory is composed of thefeature type (denoted 999) followed by anunderscore and the name (denoted Type)
associated with the feature type as per
Appendix N.

Level 5LOD

Character L followed by the LOD number
corresponding to the Significant Size forpositive levels of detail. Characters LC
followed by the LOD number
corresponding to the Significant Size fornegative levels of detail.

Note that for compatibility with version 3.0 of the Specification, the name of the directory atlevel 1 is kept to 502_GTModelSignature eventhough dataset 502 has been deprecated andreplaced with dataset 512 in version 3.1 of the Specification.
3.4.5.1
Naming Convention
The names of the GTModelSignature files adhere to the following naming convention:
D512_Snnn_Tnnn_LOD_FACC_FSC_MODL.xxx

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

© 2015 Open Geospatial Consortium

115

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Table 3-17: GTModelSignature Naming Convention

Field

Description

D512
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2This field is identical to the name of the LOD directory (level 5) where
the file is stored.
FACC Five-character FACC feature code as defined in Appendix N
Three-digit integer representing the FACC feature sub-code (FSC) as
FSC
defined in Appendix N
MODL 32-character Model Name Stringxxx
The file type associated with the dataset (ESRI Shapefile)
3.4.5.2
ExamplesThe following example illustrates the directory structure that would store the signature of all
geotypical buildings represented at LOD 3 and whose FACC are 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 FACC categories, \A_Culture is the directory containing all FACC
subcategories of category A (named Culture), \L_Misc_Feature is the directory containing all
FACC 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
FACC types are 015 (named Building), and \L03 is the directory containing the Shapefiles
representing LOD 3 of these buildings.
Examples of files found in the above directory are:.\D512_S001_T001_L03_AL015_004_Castle.shp.\D512_S001_T001_L03_AL015_004_Castle.shx.\D512_S001_T001_L03_AL015_004_Castle.dbf.\D512_S001_T017_L03_AL015_004_Castle.dbf

3.4.6
GTModel Complete Examples
The following examples illustrate the locations and names of all files of the GTModel Library.
\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature\
015_Building\
D500_S001_T001_AL015_004_Castle.flt(Entry File)
D503_S001_T001_AL015_004_Castle.xml(Descriptor)
Lnn\D510_S001_T001_Lnn_AL015_004_Castle.flt(LOD)© 2015 Open Geospatial Consortium

116

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
\CDB\GTModel\501_GTModelTexture\C\A\Castle\
D511_Snnn_Tnnn_Lnn_Castle.rgb
D504_Snnn_Tnnn_Lnn_Castle.tif
D505_Snnn_Tnnn_Castle.xml(Texture)(Material)(CMT)\CDB\GTModel\502_GTModelSignature\A_Culture\L_Misc_Feature\
015_Building\Lnn\
D512_Snnn_Tnnn_Lnn_AL015_004_Castle.shp(Signature)D512_Snnn_Tnnn_Lnn_AL015_004_Castle.shx
D512_Snnn_Tnnn_Lnn_AL015_004_Castle.dbf
D512_Snnn_Tnnn_Lnn_AL015_004_Castle.dbt\CDB\GTModel\506_GTModelInteriorGeometry\A_Culture\
L_Misc_Feature\015_Building\
D508_S001_T001_AL015_004_Castle.xml
Lnn\D506_S001_T001_Lnn_AL015_004_Castle.flt(Descriptor)(LOD)\CDB\GTModel\507_GTModelInteriorTexture\C\A\Castle\
D507_Snnn_Tnnn_Lnn_Castle.rgb
D509_Snnn_Tnnn_Lnn_Castle.tif
D513_Snnn_Tnnn_Castle.xml(Texture)(Material)
(CMT)

3.5
MModel Library Datasets
The \CDB\MModel\ folder is the root directory of the MModel library which is composed of thefollowing datasets.
1. MModelGeometry
2. MModelDescriptor
3. MModelTexture
4. MModelMaterial
5. MModelCMT
6. MModelSignature
These datasets are stored in three (3) different directory structures described in the subsections
below.
3.5.1
MModel Directory Structure 1: Geometry and Descriptor
This directory structure is owned by the MModelGeometry dataset that is assigned dataset code
600. The structure has 6 levels and is based on the DIS Entity Type (see section 3.3.8.3). The
same directory structure.is used to store the files of the MModelDescriptor dataset.

Table 3-18: MModelGeometry Directory Structure

Directory
Level

DirectoryName© 2015 Open Geospatial Consortium

Description

117

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Directory
Level

Directory
Name

Description

Level 1

600_MModelGeometry The name of the directory is composed ofthe dataset code followed by an underscore
and the dataset name.

Level 2

9_KindThe numeric code assigned to the DIS
Entity Kind followed by an underscore andthe name of this kind as per Appendix M.

Level 3

9_Domain

The numeric code assigned to the DIS
Domain followed by an underscore and thename of the domain as per Appendix M.

Level 4

9_Country

The numeric code assigned to the DISCountry followed by an underscore and thename of this country as per Appendix M.

Level 5

9_Category

The numeric code assigned to the DIS
Catagory followed by an underscore and thename of this category as per Appendix M.

Level 6

9_9_9_9_9_9_9

All 7 fields of the DIS Entity typeconcatenated and separated by anunderscore.

3.5.1.1
MModelGeometry Naming Convention
The names of all MModelGeometry files adhere to the following naming convention:
D600_Snnn_Tnnn_MMDC.flt

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

Table 3-19: MModelGeometry Naming Convention

Field
D600
Snnn
Tnnn
MMDC

Description
Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit value of Component Selector 1
Character T followed by the 3-digit value of Component Selector 2
The Moving Model DIS Code is the same as directory level 6 above© 2015 Open Geospatial Consortium

118

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Field
flt

Description
The file type associated with the dataset (OpenFlight file)

3.5.1.2
MModelDescriptor Naming Convention
The MModelDescriptor dataset is assigned dataset code 603 and the names of all
MModelDescriptor files adhere to the following naming convention:
D603_S001_T001_MMDC.xml

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

Table 3-20: MModelDescriptor Naming Convention

Field
D603
S001
T001
MMDC
xml

Description
Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit value of Component Selector 1
Character T followed by the 3-digit value of Component Selector 2
The Moving Model DIS Code is the same as directory level 6 above
The file type associated with the dataset (XML File)

3.5.1.3
ExamplesThe following example illustrates the directory structure that would store the M1A2 SEP versionof 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:D600_S001_T001_1_1_225_1_1_8_0.flt
D603_S001_T001_1_1_225_1_1_8_0.xml© 2015 Open Geospatial Consortium

119Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.5.2
MModel Directory Structure 2: Texture, Material, and CMTThis directory structure is owned by the MModelTexture dataset that is assigned dataset code
601. The structure has 4 levels and is based on the texture name (see section 3.3.8.4). The same
directory structure.is used to store the files of the MModelMaterial and MModelCMT datasets.

Table 3-21: MModelTexture Directory Structure

Directory
Level

Directory
Name

Description

Level 1

601_MModelTexture The name of the directory is composed of thedataset code followed by an underscore andthe dataset name.

Level 2A

The name of the directory corresponds to thefirst character of the texture name (TNAM), in
uppercase.

Level 3B

The name of the directory corresponds to thesecond character of the texture name (TNAM),
in uppercase.

Level 4TNAM

The texture name has from 2 to 32 characters.
The first two characters must be alphanumeric.

3.5.2.1
MModelTexture Naming Convention
The names of all MModelTexture files adhere to the following naming convention:
D601_Snnn_Tnnn_Wnn_TNAM.rgb

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

Table 3-22: MModelTexture Naming Convention

Field
D601
Snnn
Tnnn
Wnn
TNAM

Description
Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit value of Component Selector 1
Character T followed by the 3-digit value of Component Selector 2
Character W followed by the 2-digit Texture Size CodeThe texture name; identical to directory level 4 above© 2015 Open Geospatial Consortium

120

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Field
rgb

Description
The file type associated with the dataset (SGI Image)

3.5.2.2
MModelMaterial Naming Convention
The MModelMaterial dataset is assigned dataset code 604 and the names of all MModelMaterial
files adhere to the following naming convention:
D604_Snnn_Tnnn_Wnn_TNAM.tif

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

Table 3-23: MModelMaterial Naming Convention

Field
D604
Snnn
Tnnn
Wnn
TNAM
tif

Description
Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit value of Component Selector 1
Character T followed by the 3-digit value of Component Selector 2
Character W followed by the 2-digit Texture Size CodeThe texture name; identical to directory level 4 above
The file type associated with the dataset (TIFF File)

3.5.2.3
MModelCMT Naming Convention
The MModelCMT dataset is assigned dataset code 605 and the names of all MModelCMT files
adhere to the following naming convention:
D605_S001_T001_TNAM.xml

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

Table 3-24: MModelMaterial Naming Convention

Field
D605
S001
T001
TNAM

Description
Character D followed by the 3-digit code assigned to the dataset
Character S followed by the 3-digit value of Component Selector 1
Character T followed by the 3-digit value of Component Selector 2
The texture name; identical to directory level 4 above© 2015 Open Geospatial Consortium

121

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Field
xml

Description
The file type associated with the dataset

3.5.2.4
ExamplesAssuming that the textures, materials, and CMT of the M1A2 SEP are called M1A2_SEP, thefollowing 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:D601_S005_T001_W10_M1A2_SEP.rgb
D604_S001_T001_W09_M1A2_SEP.tif
D605_S001_T001_M1A2_SEP.xml

3.5.3
MModel Directory Structure 3: SignatureThis directory structure is dedicated to the MModelSignature dataset that is assigned dataset
code 606. The structure has 7 levels and is based on the DIS Entity Type (see section 3.3.8.3).

Table 3-25: MModelSignature Directory Structure

Directory
Level

Directory
Name

Description

Level 1

606_MModelSignature The name of the directory is composed ofthe dataset code followed by an underscore
and the dataset name.

Level 2

9_KindThe numeric code assigned to the DIS Entity
Kind followed by an underscore and thename of this kind as per Appendix M.

Level 3

9_Domain

The numeric code assigned to the DIS
Domain followed by an underscore and thename of the domain as per Appendix M.

© 2015 Open Geospatial Consortium

122

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Directory
Level

Directory
Name

Description

Level 4

9_Country

The numeric code assigned to the DISCountry followed by an underscore and thename of this country as per Appendix M.

Level 5

9_Category

The numeric code assigned to the DIS
Catagory followed by an underscore and thename of this category as per Appendix M.

Level 6

9_9_9_9_9_9_9

All 7 fields of the DIS Entity typeconcatenated and separated by anunderscore.

Level 7

LOD

Character L followed by the LOD number
corresponding to the Significant Size forpositive levels of detail. Characters LC
followed by the LOD number corresponding
to the Significant Size for negative levels ofdetail.

3.5.3.1
Naming Convention
The names of all MModelSignature files adhere to the following naming convention:
D606_Snnn_Tnnn_LOD_MMDC.shp
D606_Snnn_Tnnn_LOD_MMDC.shx
D606_Snnn_Tnnn_LOD_MMDC.dbf
D606_Snnn_Tnnn_LOD_MMDC.dbt

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

Table 3-26: MModelSignature Naming Convention

Field

Description

D606
Snnn
Tnnn
LOD

Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit value of Component Selector 1
Character T followed by the 3-digit value of Component Selector 2This field is identical to the name of the LOD directory (level 7) where
the file is stored.
MMDC The Moving Model DIS Code is the same as directory level 6© 2015 Open Geospatial Consortium

123

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Field
shp
shx
dbf
dbt

Description
The file type associated with the dataset (ESRI Shapefile)

3.5.3.2
ExamplesThe 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 Shapefiles representing LOD 4 of RCS signature of the tank.
Examples of files found in the above directory are:D606_Sxxx_Txxx_L04_1_1_225_1_1_8_0.shp
D606_Sxxx_Txxx_L04_1_1_225_1_1_8_0.shx
D606_Sxxx_Txxx_L04_1_1_225_1_1_8_0.dbf
D606_Sxxx_Txxx_L04_1_1_225_1_1_8_0.dbt© 2015 Open Geospatial Consortium

124

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.5.4
MModel Complete Examples
The following examples, based on the M1A2 SEP, illustrate the naming conventions of all
MModel datasets.
\CDB\MModel\600_MModelGeometry\1_Platform\1_Land\225_United_States\1_Tank\1_1_225_1_1_8_0\
D600_Snnn_Tnnn_1_1_225_1_1_8_0.flt
D603_S001_T001_1_1_225_1_1_8_0.xml(Geometry)(Descriptor)\CDB\MModel\601_MModelTexture\M\1\M1A2_SEP\
D601_Snnn_Tnnn_Wnn_M1A2_SEP.rgb
D604_Snnn_Tnnn_Wnn_M1A2_SEP.tif
D605_S001_T001_M1A2_SEP.xml(Texture)(Material)(CMT)\CDB\MModel\606_MModelSignature\1_Platform\1_Land\225_United_States\1_Tank\1_1_225_1_1_8_0\Lnn\
D606_Snnn_Tnnn_Lnn_1_1_225_1_1_8_0.shp
D606_Snnn_Tnnn_Lnn_1_1_225_1_1_8_0.shx
D606_Snnn_Tnnn_Lnn_1_1_225_1_1_8_0.dbf
D606_Snnn_Tnnn_Lnn_1_1_225_1_1_8_0.dbt(Signature)

3.6
CDB Tiled Datasets
The \CDB\Tiles\ folder is the root directory of all tiled datasets; they all share a similar directory
structure described below. All tiled datasets implement the CDB tiling scheme described in
Section 2.1, Partitioning the Earth into Tiles.
3.6.1
Tiled Dataset Types
There are three principal types of tiled datasets:
1. Raster Datasets
2. Vector Datasets
3. Model Datasets
3.6.1.1
Raster Datasets
Data elements within a tile are organized into a regular grid where data elements are evenly
positioned at every XUnitLOD and YUnitLOD 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.

© 2015 Open Geospatial Consortium

125Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Note:

Case I:
Case II:

Partially-filled Tile-LODs are not permitted by the CDB specification. In the casewhere data at the Tile-LOD’s resolution does not fully cover the Tile-LOD’s
geographic footprint, the modeler (or the tools) must fill the remainder area of the
Tile-LOD with the “best available” data. There are two cases to consider:
In the case where coarser LODm data exists for the remainder area of the TileLODn, the LODm data should be interpolated to LODn.
In the case where coarser LODm does not exist for the remainder area of the TileLODn, then the remainder area of Tile-LODn should be filled with the default value
for this dataset.

3.6.1.2
Vector Datasets
The point features, the lineal features, and the areal 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 withcartography, increasing the LOD number (increasingly finer detail) of a dataset is equivalent todecreasing the map’s scaling (1:n map scaling where n is decreasing). As is the case withcartography, 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 densityof features for each LOD of the Vector Dataset hierarchy. Table 3-27 below defines thesevalues. For each CDB LOD, the table provides the maximum number of points allowed per TileLOD and the resulting average Feature Density.

Table 3-27: CDB LOD versus Feature Density
CDB LOD

Maximum Number ofPoints per Tile

Approximate Tile Edge Size(meters)

Average Point Density(points/m2)

-10
-9
-8
-7
-6
-5
-4
-3
-2
-1
0
1
2
3
4

1
1
1
1
4
16
64
256
1024
4096
16384
16384
16384
16384
16384

1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
1.11319 × 10+05
5.56595 × 10+04
2.78298 × 10+04
1.39149 × 10+04
6.95744 × 10+03

8.06977 × 10-11
8.06977 × 10-11
8.06977 × 10-11
8.06977 × 10-11
3.22791 × 10-10
1.29116 × 10-09
5.16466 × 10-09
2.06586 × 10-08
8.26345 × 10-08
3.30538 × 10-07
1.32215 × 10-06
5.28861 × 10-06
2.11544 × 10-05
8.46177 × 10-05
3.38471 × 10-04© 2015 Open Geospatial Consortium

126

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CDB LOD

Maximum Number ofPoints per Tile

Approximate Tile Edge Size(meters)

Average Point Density(points/m2)

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384
16384

3.47872 × 10+03
1.73936 × 10+03
8.69680 × 10+02
4.34840 × 10+02
2.17420 × 10+02
1.08710 × 10+02
5.43550 × 10+01
2.71775 × 10+01
1.35887 × 10+01
6.79437 × 10+00
3.39719 × 10+00
1.69859 × 10+00
8.49297 × 10-01
4.24648 × 10-01
2.12324 × 10-01
1.06162 × 10-01
5.30810 × 10-02
2.65405 × 10-02
1.32703 × 10-02

1.35388 × 10-03
5.41553 × 10-03
2.16621 × 10-02
8.66485 × 10-02
3.46594 × 10-01
1.38638 × 10+00
5.54551 × 10+00
2.21820 × 10+01
8.87281 × 10+01
3.54912 × 10+02
1.41965 × 10+03
5.67860 × 10+03
2.27144 × 10+04
9.08576 × 10+04
3.63430 × 10+05
1.45372 × 10+06
5.81489 × 10+06
2.32595 × 10+07
9.30382 × 10+07

For positive LODs, each Tile-LOD of the vector datasets is subject to a limit of 16,384 points todescribe the features, whether the file contains point, lineal, or areal features. For negative
LODs, this limit is recursively divided by 4 until it reaches the value 1.
3.6.1.3
Model Datasets
The last type of tiled datasets is used to store 2D and 3D Models and will be later described intheir own sections.
3.6.2
Tiled Dataset Directory Structure
The vast majority of CDB datasets are tiled; the complete list follows.
1. Elevation
2. MinMaxElevation
3. MaxCulture
4. Imagery
5. RMTexture
6. RMDescriptor
7. GSFeature
8. GTFeature
9. GeoPolitical
10. VectorMaterial© 2015 Open Geospatial Consortium

127

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
11. RoadNetwork
12. RailRoadNetwork
13. PowerLineNetwork
14. HydrographyNetwork
15. GSModelGeometry
16. GSModelTexture
17. GSModelSignature
18. GSModelDescriptor
19. GSModelMaterial
20. GSModelInteriorGeometry
21. GSModelInteriorTexture
22. GSModelInteriorDescriptor
23. GSModelInteriorMaterial
24. GSModelCMT
25. T2DModelGeometry
26. Navigation
All these datasets share the same 5-level directory structure defined below.

Table 3-28: Tiled Dataset Directory Structure

Directory
Directory
Level
Name
Level 1 Lat

Level 2Lon

Level 3

nnn_DatasetName

Level 4

LOD

Level 5UREF

Description
Geocell Latitude – This directory level divides
the CDB along lines of latitude aligned to
Geocells. By convention the name of thedirectory is based on the latitude of the southedge of the Geocell.
Geocell Longitude – This directory level
divides the CDB along lines of longitudealigned to Geocells. By convention the name ofthe directory is based on the longitude of thewest edge of the Geocell.
Tiled Dataset Name – The name of thedirectory is composed of the 3-digit dataset
code (denoted nnn) followed by an underscore
and the dataset name. Dataset codes are listed
in Appendix Q.
This directory level divides each of the tiled
datasets of the Geocell into its Level of Details
This directory level divides a particular level ofdetails into rows of tiles. UREF is a reference
to the Up Index of a tile.

© 2015 Open Geospatial Consortium

128

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The above directory structure results in the following path to all files of the tiled datasets.
\CDB\Tiles\Lat\Lon\nnn_DatasetName\LOD\UREF\

Directory levels are further described below.

3.6.2.1
Directory Level 1 (Latitude Directory)
This section provides the algorithm to determine the name of the directory at level 1 of the Tiles
hierarchy.
The directory name starts with either an “N” (North) for latitudes greater than or equal to 0 (lat ≥0) or a “S” (South) for latitude less than 0 (lat < 0); this “N,S” prefix is followed by two digits:
if lat < 0 the directory name is “S(NbSliceID/2 − SliceID)”
if lat ≥ 0 the directory name is “N(SliceID − NbSliceID/2)”
SliceID and NbSliceID are computed as per the following equations:⎛ lat + 90 ⎞SliceID = int ⎜⎟⎝ DLatCell ⎠90⎞⎛NbSliceID = 2 × int ⎜⎟⎝ DLatCell ⎠where…
lat : is the latitude of the CDB tile
DlatCell: is the size in degree of a CDB Geocell in latitude

The CDB Specification sets DlatCell to 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
Specification 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 tothe resulting CDB directory and file naming thus requiring a re-compilation of existing CDBs.
3.6.2.1.1 Examples
Data elements located at a latitude of −5.2° will be found under the directory named:\CDB\Tiles\S06

Data elements located at a latitude of +62.3° will be found under the directory named:\CDB\Tiles\N62© 2015 Open Geospatial Consortium

129

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.6.2.2
Directory Level 2 (Longitude Directory)
This section provides the algorithm to determine the name of the directory at level 2 of the Tiles
hierarchy.
The directory name prefix is “E” (East) for longitudes greater than or equal to 0 (lon ≥ 0) and“W” (West) for longitudes less than 0 (lon < 0); three digits follow the prefix:
if lon < 0 the name is “W(NbSliceIDIndexEq/2 − SliceIDIndex)”
if lon ≥ 0 the name is “E(SliceIDIndex − NbSliceIDIndexEq/2)”
SliceIDIndex and NbSliceIDIndexEq are computed as per the following equations:⎛ ⎛ lon + 180 ⎞⎞
SliceIDIndex = int ⎜⎜ int ⎜⎟ × DLonZone(lat ) ⎟⎟⎝ ⎝ DLonCell ⎠⎠⎛ 180 ⎞
NbSliceIDIndex = 2 × int ⎜⎟⎝ DLonCell ⎠
180
⎞
⎛
NbSliceIDIndexEq = 2 × int ⎜⎟⎝ DLonCellBasic ⎠where…
lon is the longitude of the CDB tile
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) must be determined:

DLonCell = DLonCellBasic × DLonZone(lat )where…
DLonCellBasic is the width of a CDB Geocell in degrees atthe 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 Specification 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 Specification
Earth Model Tiled Datasets is –180 ≤ lon < 180 which implies that an application must convert alongitude of 180 to –180 before computing SliceIDIndex.

© 2015 Open Geospatial Consortium

130

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
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 Specification should retain thesame value of DLonCellBasic. Doing otherwise will cause substantial modifications to therepository 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

Latitude
DLonZone(lat) NbSliceIDIndex+89 ≤ lat < +90
1230+80 ≤ lat < +89
660+75 ≤ lat < +80
490+70 ≤ lat < +75
3120© 2015 Open Geospatial Consortium

131Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Latitude
DLonZone(lat) NbSliceIDIndex+50 ≤ lat < +70
2
180–50 ≤ lat < +50
1
360–70 ≤ lat < –50
2
180–75 ≤ lat < –70
3120–80 ≤ lat < –75
490–89 ≤ lat < –80
660–90 ≤ lat < –89
1230
3.6.2.2.1 Examples
Data elements located at a latitude of −5.2° and a longitude of +45.2° will be found under the
directory named:\CDB\Tiles\S06\E045

Data elements located at a latitude of +62.3° and a longitude of –160.4° will be found under the
directory named:\CDB\Tiles\N62\W162

The reason for “W162” instead of “W161” is that at latitudes between 50° and 70°, the CDB
Geocells have a width of 2 degrees as indicated in Table 3-29: NbSliceIDIndex for every CDB
Zones. “W162” corresponds to the southwest corner of the corresponding CDB Geocell.
3.6.2.3
Directory Level 3 (Dataset Directory)
The name of the directory at level 3 is composed of the dataset code and dataset name. The
complete list is provided in Appendix Q. Examples are provided below.
3.6.2.3.1 Examples
The elevation and the imagery of the geocell located at a latitude of −6° and a longitude of +45°
will be found under the directories named:\CDB\Tiles\S06\E045\001_Elevation\CDB\Tiles\S06\E045\004_Imagery

The list of geospecific features of the geocell located at a latitude of +62° and a longitude of –160° will be found under the directory named:\CDB\Tiles\N62\W160\100_GSFeature

The network of roads covering the geocell located at a latitude of +62° and a longitude of –160°
will be found under the directory named:\CDB\Tiles\N62\W160\201_RoadNetwork

The geometry and textures of a geospecific 3D model located at latitude of −5.2° and a longitudeof +45.2° will be found under the directories named:\CDB\Tiles\S06\E045\300_GSModelGeometry\CDB\Tiles\S06\E045\301_GSModelTexture© 2015 Open Geospatial Consortium

132

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The geometry of tiled 2D models covering the geocell located at a latitude of −5° and a longitudeof +45° will be found under the directories named:\CDB\Tiles\S05\E045\310_T2DModelGeometry

To complete these examples, the files associated with the Navigation dataset and covering the
geocell located at a latitude of +36° and a longitude of −88° will be found under the directory
named:\CDB\Tiles\N36\W088\401_Navigation

3.6.2.4
Directory Level 4 (LOD Directory)
This directory level contains all of the Level of Details directories supported by thecorresponding 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.
3.6.2.4.1 Examples
LOD 2 of the terrain elevation of the geocell located at a latitude of −6° and a longitude of +45°
will be found under the directory named:\CDB\Tiles\S06\E045\001_Elevation\L02

LOD −6 of the same dataset for the same geocell will be found in:\CDB\Tiles\S06\E045\001_Elevation\LC3.6.2.5
Directory Level 5 (UREF Directory)
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 22×LOD. For instance, LOD 10 represents
about one million files. The introduction of the UREF directory level reduces the number offiles per directory to the order of 2LOD.
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:2
𝑈𝑈 = 𝑚𝑚𝑚𝑚𝑚𝑚 𝑖𝑖𝑖𝑖𝑖𝑖
,   1
2
𝑈𝑈 = 𝑚𝑚𝑚𝑚𝑚𝑚 2 ,   1© 2015 Open Geospatial Consortium

133

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The index of a row ranges from 0 for the bottom row to UNRowLod−1 for the upper row. For any
given latitude lat, its Up Index URef is determined by first computing DLat:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑙𝑙𝑙𝑙𝑙𝑙 + 90 − 𝑖𝑖𝑖𝑖𝑖𝑖

𝑙𝑙𝑙𝑙𝑙𝑙 + 90
×𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷…which simplifies to the following for computer language that support modulo:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑑𝑑 𝑙𝑙𝑙𝑙𝑙𝑙 + 90,   𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷

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

𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷×2
𝑈𝑈 = 𝑖𝑖𝑖𝑖𝑖𝑖
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷

Knowing that the value of DLatCell is 1° for the whole CDB, the resulting formulas become:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑚𝑚(𝑙𝑙𝑙𝑙𝑙𝑙 + 90,   1)𝑈𝑈 = 𝑖𝑖𝑖𝑖𝑖𝑖(𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷×2 )3.6.2.5.1 Examples
At a latitude of −5.2° and at LOD 2, the UREF index computed from the above formulas will be:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑚𝑚 −5.2 + 90,     1 = 𝑚𝑚𝑚𝑚𝑚𝑚 84.8,   1 = 0.8
𝑈𝑈 = 𝑖𝑖𝑖𝑖𝑖𝑖 0.8×2 = 𝑖𝑖𝑖𝑖𝑖𝑖 0.8×4 = 𝑖𝑖𝑖𝑖𝑖𝑖 3.2 = 3

Assuming a longitude of +45.2°, the elevation data corresponding to this coordinate will befound under the directory named:\CDB\Tiles\S06\E045\001_Elevation\L02\U3

A geospecific feature whose significant size qualifies it for LOD 7 and positioned at a latitude of+62.3° will produce the following UREF index:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑚𝑚 62.3 + 90,     1 = 𝑚𝑚𝑚𝑚𝑚𝑚 152.3,   1 = 0.3

𝑈𝑈 = 𝑖𝑖𝑖𝑖𝑖𝑖 0.3×2 = 𝑖𝑖𝑖𝑖𝑖𝑖 0.3×128 = 𝑖𝑖𝑖𝑖𝑖𝑖 38.4 = 38

Assuming a longitude of –160.4°, the data will be found under the directory named:\CDB\Tiles\N62\W162\100_GSFeature\L07\U38© 2015 Open Geospatial Consortium

134

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.6.3
Tiled Dataset File Naming Conventions
There are two sets of naming conventions for tiled datasets. The first one corresponds to thename of files located in the leaf directories of the \CDB\Tiles hierarchy. The second set ofnames applies to files found inside ZIP archives.
3.6.3.1
File Naming Convention for Files in Leaf Directories (UREF Directory)
All files stored in the UREF subdirectory of section 3.6.2.5 have the following naming
convention:
LatLon_Dnnn_Snnn_Tnnn_LOD_Un_Rn.xxx

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

Table 3-30: Tiled Dataset File Naming Convention 1

Field

Description

Lat

Geocell Latitude – Identical to the name of the directory defined in section
3.6.2.1, Directory Level 1 (Latitude Directory).
Geocell Longitude – Identical to the name of the directory defined in
section 3.6.2.2, Directory Level 2 (Longitude Directory).
Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit value of Component Selector 1.
Character T followed by the 3-digit value of Component Selector 2.
Level of Detail – As defined in section 3.3.8.5, Level of Detail.
UREF – Identical to the name of the directory as defined in section 3.6.2.5,
Directory Level 5 (UREF Directory).
RREF – A reference to the Right Index of a tile. Character R (Right
direction) followed by the column number as described in this section.
File extension as per file type.

Lon
Dnnn
Snnn
Tnnn
LOD
Un
Rn
xxx

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

𝑅𝑅 = 𝑚𝑚𝑚𝑚𝑚𝑚 𝑖𝑖𝑖𝑖𝑖𝑖

2
,   1
2

𝑅𝑅 = 𝑚𝑚𝑚𝑚𝑚𝑚 2 ,   1© 2015 Open Geospatial Consortium

135

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The index of a column ranges from 0 for the leftmost column to RNColLod−1 for the rightmost
column. For any given lat/lon coordinate, its Right Index RRef is determined by first computing
DLon:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑙𝑙𝑙𝑙𝑙𝑙 + 180 − 𝑖𝑖𝑖𝑖𝑖𝑖

𝑙𝑙𝑙𝑙𝑙𝑙 + 180
×𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷…which simplifies to the following for computer language that support modulo:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑚𝑚 𝑙𝑙𝑙𝑙𝑙𝑙 + 180,   𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷

Then the Right Index RRef can be evaluated as follows:
𝑅𝑅 = 𝑖𝑖𝑖𝑖𝑖𝑖

𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷×2
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷

By substituing DLonCell that is defined in section 3.6.2.2, Directory Level 2 (Longitude
Directory), we obtain the following set of equations:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑚𝑚(𝑙𝑙𝑙𝑙𝑙𝑙 + 180,   𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 𝑙𝑙𝑙𝑙𝑙𝑙 )𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷×2
𝑅𝑅 = 𝑖𝑖𝑖𝑖𝑖𝑖
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷(𝑙𝑙𝑙𝑙𝑙𝑙)

The value of DLonZone is provided by Table 3-29: NbSliceIDIndex for every CDB Zones.
3.6.3.1.1 Examples
Continuing from the examples in section 3.6.2.5.1, at a latitude of −5.2° and a longitude of+45.2° and at LOD 2, the RREF index computed from the above formulas will be:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑚𝑚 45.2 + 180,   𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 −5.2
𝑅𝑅 = 𝑖𝑖𝑖𝑖𝑖𝑖

0.2×2
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 −5.2

= 𝑖𝑖𝑖𝑖𝑖𝑖= 𝑚𝑚𝑚𝑚𝑚𝑚 225.2,   1 = 0.2

0.2×4= 𝑖𝑖𝑖𝑖𝑖𝑖 0.8 = 0
1

The primary elevation data corresponding to this coordinate will be found in the file named:
S06E045_D001_S001_T001_L02_U3_R0.tif

A man-made point feature whose significant size qualifies it for LOD 7, positioned at a latitudeof +62.3° and a longitude of -160.4° will produce the following RREF index:
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 𝑚𝑚𝑚𝑚𝑚𝑚 −160.4 + 180,   𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 62.3

= 𝑚𝑚𝑚𝑚𝑚𝑚 19.6,   2 = 1.6

1.6×2
1.6×128
𝑅𝑅 = 𝑖𝑖𝑖𝑖𝑖𝑖= 𝑖𝑖𝑖𝑖𝑖𝑖= 𝑖𝑖𝑖𝑖𝑖𝑖 102.4 = 102
2
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷(62.3)© 2015 Open Geospatial Consortium

136

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Resulting in the following file names:
N62W162_D100_S001_T001_L07_U38_R102.shp
N62W162_D100_S001_T001_L07_U38_R102.shx
N62W162_D100_S001_T001_L07_U38_R102.dbf
N62W162_D100_S001_T001_L07_U38_R102.dbt

3.6.3.2
File Naming Convention for Files in ZIP Archives
The following GSModel datasets reside inside ZIP archives.
1. GSModelGeometry
2. GSModelTexture
3. GSModelMaterial
4. GSModelDescriptor
5. GSModelInteriorGeometry
6. GSModelInteriorTexture
7. GSModelInteriorMaterial
8. GSModelInteriorDescriptor
These files are stored in archives whose names follow the naming convention defined in section
3.6.3.1 above; the files inside those archives follow the naming conventions defined here.
LatLon_Dnnn_Snnn_Tnnn_LOD_Un_Rn_"extra_tokens".xxx

The extra tokens are described in the next sections.

3.6.3.2.1 GSModel Geometry File Naming Conventions
The files from the GSModelGeometry and GSModelInteriorGeometry datasets have thefollowing naming convention:
LatLon_Dnnn_Snnn_Tnnn_LOD_Un_Rn_FACC_FSC_MODL.flt

The FACC, FSC, and MODL tokens are as defined in section 3.3.8.1, Feature Classification, andsection 3.3.8.2, Model Name.
3.6.3.2.2 GSModel Texture File Naming Conventions
The files from the GSModelTexture and GSModelInteriorTexture datasets have the following
naming convention:
LatLon_Dnnn_Snnn_Tnnn_LOD_Un_Rn_TNAM.rgb

The TNAM token is as defined in section 3.3.8.4, Texture Name.
3.6.3.2.3 GSModel Material File Naming Conventions
The files from the GSModelMaterial and GSModelInteriorMaterial datasets have the following
naming convention:
LatLon_Dnnn_Snnn_Tnnn_LOD_Un_Rn_TNAM.tif

The TNAM token is as defined in section 3.3.8.4, Texture Name.

© 2015 Open Geospatial Consortium

137

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.6.3.2.4 GSModel Descriptor File Naming Conventions
The files from the GSModelGeometry and GSModelInteriorGeometry datasets have thefollowing naming convention:
LatLon_Dnnn_Snnn_Tnnn_LOD_Un_Rn_FACC_FSC_MODL.flt

The FACC, FSC, and MODL tokens are as defined in section 3.3.8.1, Feature Classification, andsection 3.3.8.2, Model Name.
3.6.3.2.5 Examples
All archives at LOD 7 that are located at a latitude of +62.3° and a longitude of -160.4° will be
named:
N62W162_Dnnn_S001_T001_L07_U38_R102.zip

For each model dataset that uses an archive, the name of the archive will be:
N62W162_D300_S001_T001_L07_U38_R102.zip (Geometry)
N62W162_D301_S001_T001_L07_U38_R102.zip (Texture)
N62W162_D302_S001_T001_L07_U38_R102.zip (Signature)
N62W162_D303_S001_T001_L07_U38_R102.zip (Descriptor)
N62W162_D304_S001_T001_L07_U38_R102.zip (Material)
N62W162_D305_S001_T001_L07_U38_R102.zip (Interior Geometry)
N62W162_D306_S001_T001_L07_U38_R102.zip (Interior Texture)
N62W162_D307_S001_T001_L07_U38_R102.zip (Interior Descriptor)
N62W162_D308_S001_T001_L07_U38_R102.zip (Interior Material)

Examples of files found inside the above archives are:

N62W162_D300_S001_T001_L07_U38_R102_AL015_116_AcmeFactory.flt
N62W162_D301_Snnn_Tnnn_L07_U38_R102_AcmeFactory.rgb
N62W162_D302_Snnn_Tnnn_L07_U38_R102_AL015_116_AcmeFactory.shp
N62W162_D302_Snnn_Tnnn_L07_U38_R102_AL015_116_AcmeFactory.shx
N62W162_D302_Snnn_Tnnn_L07_U38_R102_AL015_116_AcmeFactory.dbf
N62W162_D303_S001_T001_L07_U38_R102_AL015_116_AcmeFactory.xml
N62W162_D304_Snnn_Tnnn_L07_U38_R102_AcmeFactory.tif
N62W162_D305_S001_T001_L07_U38_R102_AL015_116_AcmeFactory.flt
N62W162_D306_S001_T001_L07_U38_R102_AcmeFactoryWall.rgb
N62W162_D306_S001_T001_L07_U38_R102_AcmeFactoryFloor.rgb
N62W162_D306_S001_T001_L07_U38_R102_AcmeFactoryCeiling.rgb
N62W162_D307_S001_T001_L07_U38_R102_AL015_116_AcmeFactory.xml
N62W162_D308_Snnn_Tnnn_L07_U38_R102_AcmeFactory.tif

To complete the example, the name of the GSModel Composite Material Table (GSModelCMT)
that is associated with the above geocell is:
N62W162_D309_S001_T001_L00_U0_R0.xml

Note that this file is located at LOD 0, hence the value 0 for UREF and RREF. This will be
explained later in chapter 5.
Finally, the geometry of the tiled 2D model corresponding to the above tile will be named:
N62W162_D310_S001_T001_L07_U38_R102.flt© 2015 Open Geospatial Consortium

138

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3.7
Navigation Library Dataset
The \CDB\Navigation\ folder is the root directory of the Navigation library which is composedof a single dataset.
1. NavData
The purpose of the Navigation library is to include all of the information which is either notgeographically located, or has a global geographical coverage and can be used as a lookup to the
Navigation Tile-LODs.
3.7.1
NavData Structure
The NavData dataset is assigned dataset code 400 and has a single level directory structure.

Table 3-31: GTModelGeometry Entry File Directory Structure

Directory
Level
Level 1

Directory
Name

Description

400_NavData The name of the directory is composed of the dataset
code followed by an underscore and the dataset name.

3.7.2
Naming Convention
All files of the NavData dataset have the following naming convention:
D400_Snnn_Tnnn.dbf

The following table defines each field of the file name and section 5.2 provides the values of theComponent Selectors to complete the name.

Table 3-32: NavData Naming Convention

Field
D400
Snnn
Tnnn
dbf

Description
Character D followed by the 3-digit code assigned to the dataset.
Character S followed by the 3-digit Component Selector 1
Character T followed by the 3-digit Component Selector 2
The file type associated with the dataset (dBASE III+ file)

3.7.2.1
ExamplesThe Schema file (T002) of the Airport component (S001) of the NavData dataset is stored in:\CDB\Navigation\400_NavData\D400_S001_T002.dbf© 2015 Open Geospatial Consortium

139

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

© 2015 Open Geospatial Consortium

140

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 4
4
CDB File Formats
The CDB Specification internal formats are based on the formats used by industry-standard
toolsets. As a result, the Specification eliminates the time-consuming off-line database assemblyand database publishing process usually imposed by each of the clients. Refer to Section 1.6.4.2,
Database Generation Flow for a more comprehensive discussion of this topic.
Furthermore, the translation step into CDB format is typically trivial since the CDB Specification
is based on industry-standard native tool formats.
The CDB Specification permits any CDB to run “as-is”, without any offline assembly (akacompilation), translation, conversion, on any CDB-compliant simulator client-device platform.
This allows the simulator user community AND the database creation community to freely
exchange CDBs across simulators and database generation facilities either through the exchangeof physical media (or entire storage subsystems) or via network. As a result, a CDB can be runand exchanged without change on any CDB-compliant simulator client-devices or any databasegeneration workstations, regardless of the computer platforms, simulator system software.
The storage structure of the CDB Specification allows for efficient searching, retrieval andstorage of any information contained within the database. The storage structure portion of theSpecification is defined in Chapter 3.
This chapter concerns itself with the formats used by the CDB. The formats used by the CDB
Specification are:
1.

2.

TIFF (*.tif): used for the representation of all datasets whose inherent
structure reflects that of a two-dimensional regular grid in a Cartesian
coordinate system. The primary use of TIFF within a CDB is for the
representation of terrain elevation and raster imagery. To qualify as a
CDB-compliant TIFF reader, the reader must satisfy the requirements
described in Appendix B of this Specification. It is to be noted that the
LZW compression algorithm within the TIFF format is supported andencouraged by the CDB Specification when the data type of the content of
the file is of integral type. As a consequence, it is strongly recommended
to compress TIFF files containing integer values but to avoid compression
if the file contains floating-point values.
GeoTIFF (*.tif): used for the representation of all datasets whose
inherent structure reflects that of a two-dimensional regular grid of a
Geographic coordinate system. The primary use of GeoTIFF within a
CDB is for the representation of terrain elevation (note: the use GeoTIFF
is preferred over TIFF in the case of terrain elevation). CDB-compliant
GeoTIFF readers do not concerns themselves with any of the GeoTIFF
specific tags because the CDB Specification provides all of theconventions to geo-reference each geographic dataset. However, it is© 2015 Open Geospatial Consortium

141

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

3.

4.

5.

6.

strongly recommended that database generation tools be fully compliant to
GeoTIFF; this provision eliminates the need for the tools to be aware of
the CDB conventions governing the content of each geo-referenced
dataset.

SGI Format (*.rgb): used for the representation of 3D model textures.
The file format allows for the representation of an image with 1, 2, 3, or 4channels. A single channel image represents a grey-shaded texture; a twochannel image represents a grey-shaded texture with an alpha component
providing the transparency; a three-channel image represents a color(RGB) texture; finally, a four-channel image is a color (RGB) texture withan alpha channel providing the transparency. CDB-compliant RGB
readers must be fully compliant with the SGI Image File Format
Specification. Its use is limited to 3D models.
JPEG 2000 (*.jp2): used for the representation of an image encoded inaccordance to the JPEG 2000 standard. CDB-compliant JPEG 2000
readers must be fully compliant with the JPEG 2000 standard while
reading such still image file types. JPEG 2000 encoded images can beused for the representation of geo-referenced terrain imagery with somedegree of compression levels and is only applicable in the case of terrainraster imagery.

OpenFlight (*.flt): used for the representation of 3-dimensional
geometric representation of all models (statically positioned culturalmodels, moving models). To qualify as a CDB-compliant OpenFlight
reader, the reader must satisfy the requirements described in Appendix Cof this Specification.

Shape (*.shp, *.shx, *.dbf, *.dbt): used for the representation andattribution of the vector feature datasets in a CDB. To qualify as a CDBcompliant Shape reader, the reader must satisfy the requirements
described in Appendix D of this Specification.

Extensible Mark-up Language (*.xml): used to store metadata that
describes CDB versioning, describes CDB Composite and Base material
structure, defines CDB light type naming conventions and hierarchy, anddefines CDB model component hierarchy.
8.
Cross-platform and interoperable file storage and transfer format(*.zip): used to archive and store geospecific 3D model datasets.
Appendices B, C, D of this Specification define the required compliancy of CDB readers for the
TIFF, OpenFlight and Shape formats. Appendix T describes the JPEG 2000 file format and thelast section of Appendix D describes the dBASE III+ file format used by the Shapefile standard.
For all other formats (used by this Specification), CDB readers must be fully compliant.
7.

© 2015 Open Geospatial Consortium

142

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 4-1: CDB File Format Compatibility

File Format

*.tif
*.rgb
*.jp2
*.flt
*.shp, *.shx*.dbf, *.dbt
*.xml
*.zip

Versions Supported by
CDB

6.0
1.0
1.0
16.0
ERSI White Paper, July 98
dBASE III+ and above
1.0
6.3.1

© 2015 Open Geospatial Consortium

CDB Client-device Behavior
for Prior Versions

Ignores data
Ignores data
Ignores data
Ignores data
Ignores data
Ignores data
Ignores data
Ignores data

143

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 5
5
CDB Datasets
This chapter provides the description of the content of CDB datasets, except OpenFlight and
RCS models that are covered in the following chapters. Chapter 5 also provides the Component
Selectors necessary to complete the file names associated with all CDB datasets.
5.1
Metadata Datasets
Metadata datasets contain information, global to the CDB that define its structure, naming
hierarchies, default values, allowable values, and status. All metadata files are formatted using
eXtended Markup Language (XML) files and their XML schemas can be found in the\CDB\Metadata\Schema\ folder delivered with the Specification.
The table below lists all metadata files that are allowed and defined by the Specification. Notethat a dataset code and component selectors are assigned to each metadata file eventhough thesecodes do not participate in the construction of their file names. Dataset codes are assigned tometadata datasets for consistency with all other CDB Datasets.

Table 5-1: Component Selectors for Metadata Datasets
CS1
CS2
File Name
Dataset 700, Metadata001
Lights.xml
002
Model_Components.xml
003
Materials.xml
004
Defaults.xml
005
Specification_Version.xml (Deprecated)
006
Version.xml
007
CDB_Attributes.xml
008
Geomatics_Attributes.xml
009
Vendor_Attributes.xml
010
Configuration.xml
Dataset 701, Client-Specific Metadata
Lights_xxx.xml

For client-specific metadata, the Specification only reserves one dataset code but no component
selector. The mechanism is kept for backward compatibility with previous version of theSpecification. However, its use is strongly discouraged because it defeats the very intent of the
CDB, which is to promote correlation between client devices by having a single source of data.

© 2015 Open Geospatial Consortium

145

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.1.1
Light Name Hierarchy Metadata
The light name hierarchy for the CDB is described in detail within the table found in Appendix Eof this Specification. For run-time access of this data, clients must be able to retrieve suchinformation. To this end, the Lights Hierarchy Definition metadata is stored in an XML file inthe metadata CDB directory as described in Section 3.1.1, Metadata Directories. The name of
the file is “Lights.xml”.
The XML file provides a description of the entire naming hierarchy, including the hierarchicalrelationship of the levels with respect to each other and the position of each light type within thishierarchy. In addition to the name of each light type, the “Lights.xml” file contains a uniquecode with each light type.
In the case of light features (Airport Features - Lights and Environmental Lights tiled datasets),the light type code provides a storage-efficient means to attribute each light, since only the codeis used to attribute light features. Database tools are required to map the light type name string
provided by the modeler into a light type code.
In the case of light features that are part of OpenFlight models, the light type name string
provided by the modeler is used “as-is” within the model to attribute each of the light features.
Client-devices are required to internally build and initialize a table of light properties andcharacteristics for their respective use. This table could be indexed at runtime using the lighttype code. The table can be built at CDB load time and should match the device’s inherent
capabilities and level-of-fidelity; this flexibility can be achieved because the “Lights.xml” filecommunicates the lights naming hierarchy to the client-devices.
The client-devices are required by the CDB specification to ensure that properties andcharacteristics of lower-tier names in the light point hierarchy inherit the properties andcharacteristics of the higher-tier names in the light name hierarchy. This feature allows modelers
to add new light names to the light name hierarchy and be assured that the new light names will
immediately inherit all of the properties and characteristics of the parent names even if thesimulator vendor does not update any of the client-devices.
The light type code can range from 0 to 9,999. The light type codes are used by the Airport
Features - Lights and Environmental Lights tiled datasets of the CDB. It is up to the CDB
creation tools to ensure that the light type code does in fact correspond to the light type nameassigned by the modeler.
Below is a small sample of the CDB light name hierarchy in XML format.

© 2015 Open Geospatial Consortium

146

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Lights><Light type="Light" code="0"><Description>
All Purpose Generic light</Description><Light type="Platform" code="1"><Description>
Platform light</Description><Light type="Air" code="2"><Description>
Aircraft light</Description><Light type="Aircraft_Helos" code="3"><Description>
Light for Aircraft and Helicopters</Description><Light type="Anti-collision" code="4"><Description>
Anti collision light – normally red flashing</Description><Light type="Bottom_Light" code="5"><Description>
Anti-collision found on bottom of the fuselage</Description><Light type="NVG_Bottom_Light" code="6"><Description>
Anti-collision found on bottom of fuselage in NVG mode</Description></Light></Light></Light>... other light definitions of type Platform-Air-Aircraft_Helos</Light>... other light definitions of type Platform-Air</Light>... other light definitions of type Platform</Light></Light></Lights>

Note that light code numbering need not be consecutive. Light codes have a one-to-one
association with light types; consequently, the light codes are unique among all light types.
5.1.1.1
Client Specific Lights Definition Metadata
Client-devices use the light type code as an index to look-up the client-specific properties andcharacteristics of each light type. This approach is client-device independent because the(device-specific) client’s rendering parameters are local to its implementation. As a result,modelers need not bother setting or even understanding the many parameters specific to eachlight type and to each client-device type.
The CDB specification also offers a complementary approach to modifying the appearance oflights. This approach provides basic control over light intensity, color, lobe width and aspect,frequency and duty cycle to client devices. The approach also permits a modeler to add newlight types to the CDB light hierarchy.
Example:© 2015 Open Geospatial Consortium

147

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
As an example, we will create a client-specific lights definition metadata file for a hypotheticalclient-device. The information would be held in the Lights_xxx.xml metadata file corresponding
to the client-device for which lights are to be tuned. There can be one file per client-device andthe file for each client-device is optional. The file is not required if the modeler does not wish toadjust the basic characteristics of one or more light types for the associated client-device, or
he/she doesn’t require new light types to be added to the CDB light hierarchy. The metadata filewould be loaded by the client-device whose name matches the “xxx” character string of theLights_xxx.xml file. As for the Lights, the file would be located at the top of the CDB storage
hierarchy in directory \CDB\Metadata\ as described in Section 3.1.1, Metadata Directories.
Nominally, the Lights_xxx.xml consists of light type entries corresponding to the light types themodeler wishes to add/modify. Each entry in the Lights_xxx.xml file consists of one or optional
fields.
Consider the case of a simulator equipped with a client-device rendering simulated imagery formodel “A” NVG goggles and a second client-device rendering simulated imagery for model “B”
NVG goggles. After viewing the CDB on the simulator, the modeler wishes to diminish theintensity of the \Lights\Cultural\Line-based\Highway lights for model “A” NVG goggles to 90%of the intensity calculated by the simulator. To do this, the modeler creates aLights_NVG_A.xml, creates a light type entry for \Lights\Cultural\Line-based\Highway andprovides an intensity field with value of 0.9. Note that all other characteristics of the light typein this client-device are unaffected since the modeler did not provide additional fields.
Furthermore, the characteristics of the light type in all other client-devices remain unaffected
since the modeler did not provide other Lights_xxx.xml files.
The XML schema for the fields of the Lights_xxx.xml is delivered with the Specification in\CDB\Schema\Lights_Tuning.xsd. The fields are:Z

Intensity: When a light type is non-native to the CDB specification, whichmeans that it is without a corresponding entry in Appendix E, Intensity
represents the light point intensity for the client-device (range normalized
from 0.0 to 1.0). When the light entry is native to the CDB specification,
Intensity is used as a floating-point intensity modifier that multiplies theintensity calculated by the client-device. In both cases, Intensity defaults to avalue of 1.0.

Z

Color: When a light type is non-native to the CDB specification, Color is a
floating-point RGB triplet that represents the color of the light type for theclient-device (range normalized from 0.0 to 1.0). When the light entry isnative to the CDB specification, Color is a floating-point RGB triplet thatmultiplies the RGB value calculated by the client-device. Color applies only
to visual system client-device types. If absent in a light type entry, Colordefaults to a value of white (1.0, 1.0, 1.0).

Z

Directionality: A string that categorizes the light type as “Omnidirectional”,“Directional” or “Bidirectional”. If absent in a light type entry, Directionality
defaults to the value “Omnidirectional”.

© 2015 Open Geospatial Consortium

148

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Z

Lobe_Width: Represents the identifying section for the light’s lobe widthcharacteristics, which can have a horizontal and vertical attribute.
o Horizontal: When a light type is
non-native
to
the
CDB
specification, the Horizontal field
represents the light point’s halfintensity horizontal lobe width
for the client-device (range from
0.0 to 360.0). When the light
entry is native to the CDB specification, Horizontal field is used as afloating-point modifier that multiplies the horizontal lobe width
calculated by the client-device. Applies only to Directional andBidirectional light types. If absent in a light type entry, Horizontal
field defaults to a value of 1.0.
o Vertical: When a light type is non-native to the CDB specification,
Vertical field represents the light point’s half-intensity vertical lobe
width for the client-device (range from 0.0 to 360.0). When the light
entry is native to the CDB specification, Vertical field is used as afloating-point modifier that multiplies the vertical lobe width
calculated by the client-device. This applies only to Directional andBidirectional light types. If absent in a light type entry, Vertical field
defaults to a value of 1.0.

Z

Residual_Intensity: When a light type is non-native to the CDB specification,
Residual_Intensity represents the residual intensity of the light. Residual
intensity is the intensity of the light (range normalized from 0.0 to 1.0) outsideof the lobe defined by Lobe_Width:Horizontal and Lobe_Width:Verticalfields.
When the light entry is native to the CDB specification,
Residual_Intensity is used as a floating-point modifier that multiplies theresidual intensity calculated by the client-device. This applies only to
Directional and Bidirectional light types. If absent in a light type entry,
Residual_Intensity defaults to a value of 1.0.

Z

Frequency: A floating-point value greater than or equal to 0.0 that sets theblink or rotating frequency of the light in Hertz (cycles per second). A valueof 0.0 disables all blinking and rotating properties. If absent in a light type
entry, Frequency defaults to a value of 0.0.

Duty_Cycle: A floating-point value ranging from 0.0 to 1.0 that sets the duty
cycle of the light. Duty cycle is defined as the percentage of time the light isturned on over a complete cycle. A value of 0.0 permanently turns the lightoff. A value of 1.0 turns it on. The value is ignored if Frequency = 0.0. If
absent in a light type entry, Duty_Cycle defaults to a value of 0.5.
Here is a sample of a Lights_xxx.xml file where a modeler has exercised explicit control overthe properties of an anti-collision light and a landing light.
Z© 2015 Open Geospatial Consortium

149

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Lights_Tuning><Light type="\Light\Platform\Air\Aircraft_Helos\Anti-collision"><Description>Tuned for MH-47 CMS</Description><Intensity>0.75</Intensity><Color>1.0 0.0 0.0</Color><Directionality>Omnidirectional</Directionality><Frequency>0.5</Frequency><Duty_Cycle>0.2</Duty_Cycle></Light><Light type="\Light\Platform\Air\Aircraft_Helos\Landing"><Description>...</Description><Intensity>1.0</Intensity><Color>1.0 0.9 0.9</Color><Directionality>Directional</Directionality><Residual_Intensity>0.05</Residual_Intensity><Lobe_Width><Horizontal>30.0</Horizontal><Vertical>25.0</Vertical></Lobe_Width></Light></Lights_Tuning>

5.1.2
Model Components Definition Metadata
The CDB specification 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,“\CDB\Metadata\Model_Components.xml” as described in Section 3.1.1, Metadata Directories.
Appendix F lists all available model components. The XML schema is provided in\CDB\Metadata\Schema\Model_Components.xsd delivered with the Specification.
The following shows a content sample of the model component definition file:<Model_Components><Component name="Artillery_Gun"><Description>
1) Refers to any engine used for the discharge of large
projectiles and served by a crew of men.
2) Cannon-like weapons operated by more than one person.
</Description></Component><Component name="Windshield"><Description>
A transparent screen located in front of the occupants of avehicle to protect them from the wind and weather.
</Description></Component>... other components</Model_Components>

5.1.3
Base Material Table
CDB Base Materials are listed in Appendix L and stored an XML file named\CDB\Metadata\Materials.xml, as mentionned in section 3.1.1. The format of the file is definedby an XML schema that is delivered with the Specification in the file named\CDB\Metadata\Schema\Base_Material_Table.xsd.

© 2015 Open Geospatial Consortium

150

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Here is an excerpt of the CDB Base Material Table showing the definitions of the first and thelast base materials of the Specification.
<Base_Material_Table><Base_Material><Name>BM_ASH</Name><Description>
The solid remains of a fire</Description></Base_Material>...
<Base_Material><Name>BM_WOOD-DECIDUOUS</Name><Description>
Trunks, branches of live deciduous trees</Description></Base_Material></Base_Material_Table>

5.1.4
Default Values Definition Metadata
Default values for all datasets can be stored in the default values metadata file“\CDB\Metadata\Defaults.xml” as described in Section 3.1.1, Metadata Directories. Default
values defined throughout the CDB specification are listed in Appendix S. The XML schema isprovided in \CDB\Metadata\Schema\Defaults.xsd delivered with the Specification. 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 aredefault values to be used by CDB creation tools to fill mandatory content when information iseither 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 Appendix S. Each default
value has a type. Valid default value data types are “float”, “integer” and “string”.
The following is an excerpt of a “Defaults.xml” file containing the default terrain elevation
value.

<Default_Value_Table><Default_Value><Dataset>001_Elevation</Dataset><Name>Default_Elevation-1</Name><Description>Default Primary Terrain Elevation</Description><Type>float</Type><Value>0.0</Value><R_W_Type>R</R_W_Type></Default_Value><!-- Insert other Default Values in accordance to the table above --></Default_Value_Table>

5.1.5
Specification Version Metadata – Deprecated
The content of Specification_Version.xml has been merged into Version.xml; as such, the use of
the file is deprecated as of this version of the Specification.

© 2015 Open Geospatial Consortium

151

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.1.6
Version Metadata
Each CDB Version requires a version control file that is called Version.xml. Its contents are as
follows:<Version><PreviousIncrementalRootDirectory name="Path to another CDB Version"/><Comment>A comment to describe this CDB Version</Comment><Specification version="3.2|3.1|3.0"/><Extension name="name of the extension" version="version of this extension"/></Version>

The complete XML schema can be found in \CDB\Metadata\Schema\Version.xsd delivered with
the Specification.
The optional <PreviousIncrementalRootDirectory> element is used to refer to another CDB
Version. This is the mechanism to use to chain together two CDB versions. The optional<Comment> element is a free-format text to describe the purpose and/or the nature of the data of
this CDB Version. The mandatory <Specification> element indicates the CDB Specification thatis used to produce the content of this CDB Version. Note that version numbers of theSpecification are limited to the existing versions: 3.2, 3.1, and 3.0. Other values are notpermitted. 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 Specification.
A CDB Extension corresponds to user defined information, which is not described or supportedby the CDB Specification, 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 should only contain vendor or device specific information. CDB content
adhering to the CDB specification should only be found in the CDB versions. Client devices notconcerned with a CDB extension should ignore all non-CDB compliant content, without loss of
information.
5.1.7
CDB Attributes Metadata
The CDB attributes are listed and described in section 5.7.1.3 CDB Attributes. The metadata forthese attributes is stored in \CDB\Metadata\CDB_Attributes.xml and the schema can be found in\CDB\Metadata\Schema\Vector_Attributes.xsd. In essence, the file is the transposition of thetext found in section 5.7.1.3 CDB Attributes into a format more appropriate for a computer
program.
Its contents are as follows:© 2015 Open Geospatial Consortium

152

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Vector_Attributes><Attributes><Attribute>...</Attributes>...
<Attribute>...</Attributes></Attributes><Units><Unit>...</Unit>...
<Unit>...</Unit></Units><Scalers><Scaler>...</Scaler>...
<Scaler>...</Scaler></Scalers></Version>

The file is composed of three majors sections, 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 individual
attribute.
5.1.7.1
Definition of the <Attribute> Element
Each attribute is defined as follows:<Attribute code="..." symbol="..."><Name>...</Name><Description>...</Description><Level>...</Level><Value>...</Value></Attribute>

The code is the integer value assigned to each attribute listed in section 5.7.1.3, CDB Attributes.
The symbol is the unique character string identifying the attribute. The <Name> is the long formof the symbol. The <Description> is a free form text describing the attribute. The <Level> isdefined below and provides the schema level of the attribute. The <Value> element provides theinformation required to interpret (parse) the value assigned to this attribute.
The schema level is defined as follow:<Level><Instance>...</Instance><Class>...</Class><Extended>...</Extended></Level>The <Level> provides a mean to state if the attribute is Preferred, Supported, Deprecated, or Not
Supported for each of the schema level.
The definition of <Value> is as follow:© 2015 Open Geospatial Consortium

153

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Value><Type>...</Type><Format>...</Format><Precision>...</Precision><Range>...</Range><Unit>...</Unit><Scaler>...</Scaler></Value>

The <Type> is one of Text, Numeric, or Boolean. In the case of a numeric data type, the<Format> indicates if it is a Floating-Point or an Integer value. For a floating point type, the<Precision> provides the number of digits before and after the decimal point. For numeric types,
the <Range> provides the minimum and maximum values; the <Unit> is a reference to a unit
code; and the <Scaler> is a reference to a scaler code; both codes being respectively defined insubsequent <Units> and <Scalers> sections.
5.1.7.2
Definition of the <Unit> Element
The <Units> section is a list of <Unit> definitions as follow:<Unit code="..." symbol="..."><Name>...</Name><Description>...</Description></Unit>

The code is a positive integer used as a key when a <Value> references a unit. The symbol is thecharacter string that is commonly recognized as the unit identifier. The <Name> is the long formof the unit symbol and <Description> is a free-form text describing this unit.
5.1.7.3
Definition of the <Scaler> Element
The <Scalers> section is a list of <Scaler> definitions as follow:<Scaler code="..." symbol="..."><Name>...</Name><Description>...</Description><Multiplier>...</Multiplier></Scaler>

The code is a positive integer used as a key when a <Value> references a scaler. The symbol isthe character string that is commonly recognized as the scaler identifier. The <Name> is thelong form of the scaler symbol and <Description> is a free-form text describing this scaler.
Finally, <Multiplier> is the numerical multiplier applied to the base unit.

© 2015 Open Geospatial Consortium

154

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.1.7.4
Example of CDB_Attributes.xml
The following example illustrates how to define an attribute:<Vector_Attributes><Attributes><Attribute code="2" symbol="AO1"><Name>Angle of Orientation</Name><Description>Angle of Orientation with greater than 1 degree resolution.
The angular distance measured from true north (0 deg) clockwise to themajor (Y) axis of the feature. If the feature is square, the axis 0
through 89.999 deg shall be recorded. If the feature is circular, 360.000
deg shall be recorded.
</Description><Level><Instance>Preferred</Instance><Extended>Supported</Extended></Level><Value><Type>Numeric</Type><Format>Floating-point</Format><Precision>3.3</Precision><Range interval="Right-Open"><Min>0</Min><Max>360</Max></Range><Unit>2</Unit></Value></Attribute></Attributes><Units><Unit code="2" symbol="deg"><Name>degree</Name><Description>To mesure an angle</Description></Unit></Units><Scalers><Scaler code="2" symbol="k"><Name>kilo</Name><Description>A multiplier: thousand</Description><Multiplier>1000</Multiplier></Scaler></Scalers></Vector_Attributes>

The schema explains the use of the interval attribute of the <Range> element.
5.1.8
Geomatics Attributes Metadata
Geomatics attributes (section 5.7.1.2.6.2), are listed in “Geomatics_Attributes.xml” (section
3.1.1). The file uses the Geomatics_Attributes.xsd schema.
5.1.9
Vendor Attributes Metadata
Vendor attributes (section 5.7.1.2.6.3), are listed in “Vendor_Attributes.xml” (section 3.1.1).
The file uses the Vendor_Attributes.xsd schema.
5.1.10Configuration Metadata
The Configuration metadata file provides the means of defining CDB Configurations. The
syntax of the file is given below. The complete XML schema is provided in/CDB/Metadata/Schema/Configuration.xsd delivered with the Specification.

© 2015 Open Geospatial Consortium

155

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

<Configuration><Comment> An optional comment describing this CDB Configuration. </Comment><Version><Folder path="..."/><Comment> An optional comment describing this CDB Version. </Comment><Specification version="..."/><Extension name="..." version="..."/></Version><!-- Other versions as needed --></Configuration>

A <Configuration> is a list of one or more <Version> elements. A <Version> has a mandatory<Folder> element to provide the path to the CDB Version. The other three (3) elements have thesame definitions as that of section 5.1.6, Version Metadata.
5.1.10.1 A Note about Folder Path
The use of a relative path to a CDB Version ensures a greater form of interoperability between
operating systems and file systems. However, the Specification does not prevent the use ofabsolute paths60. A relative path is expressed relative to the root of the CDB Version containing
the Configuration file.
5.1.10.2 Example
Assume that we want to assemble two CDB Versions into a single CDB Configuration. The first
CDB Version is located in /CDB/myVersion and has the following Version.xml file.
<Version><PreviousIncrementalRootDirectory name="/CDB/theVersion"/><Comment> This is the comment describing myVersion. </Comment><Specification version="3.2"/></Version>

The second CDB Version complies with version 3.0 of the Specification, is located in/CDB/theVersion, and has the following Version.xml file.
<Version><Comment> This is the comment describing theVersion. </Comment></Version>

The resulting CDB Configuration is stored in /CDB/myConfiguration and its
Configuration.xml file could look like this:60

On Windows, the path can even be specified using the UNC notation.

© 2015 Open Geospatial Consortium

156

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Configuration><Comment>
This is an example of a CDB Configuration referring to two CDB Versions.
</Comment><Version><Folder path="../myVersion"/><Comment> This is the comment describing myVersion. </Comment><Specification version="3.2"/></Version><Version><Folder path="../theVersion"/><Comment> This is the comment describing theVersion. </Comment><Specification version="3.0"/></Version></Configuration>

Notice the use of relative paths to refer to the CDB Versions. Also notice the addition of the<Specification> element to the second <Version> to explicitly state that it contains data
complying with version 3.0 of the Specification.
5.2
Navigation Library Datasets
The NavData dataset represents the navigation portion of a CDB. It supports several simulation
subsystems such as the Instrument Landing System (ILS), Inertial Navigation/Global Positioning
System, and Microwave Landing System Communications. The dataset also provides
descriptions of airspaces, airways, heliports, helipads, gates, runways, approaches, and terminals.
It also provides information regarding climb procedures out of airports.
The NavData dataset is broken down into a collection of 46 (forty-six) components related to the
Flight Navigation. Together, these 46 components combine all of the information currently
provided by the following two organizations:Navigation System Data Base (produced by Jeppesen) around the ARINC
Standard 424-16
Product Standard for the Digital Aeronautical Flight Information File(DAFIF) produced by the National Intelligence Geospatial Agency
The component selector 2 is set to 001 for basic navigation records and these files are located in
the tiled Navigation dataset directories. The component selector 2 is set to 002 for schema files
and a value between 101 and 126 for key datasets. Schema and key datasets are located in the
global Navigation directory. Component selector 1 and the file type are as per Table 5-28: Tiled
Navigation Dataset. It provides a list of all CDB Navigation components with their designatednames and description.

Table 5-2: Component Selectors for Navigation Dataset
CS1

CS2

File
ExtensionComponent
Name

Component Description© 2015 Open Geospatial Consortium

157

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CS1

CS2

File
Extension

Dataset 400, NavData001-046002*.dbf
101-126-*.dbf

Component
Name
SchemaKey Dataset

Component Description
Lists the data attributes for the given
component
Sorted lists used to perform queries within the
NavData

T002: Schema file
T101: Storage number search key
T102: Ident search Key
T103: ICAO search Key
T104: Frequency search Key
T106: IATA search Key
T107: Type search Key
T108: Additional Ident 1 search Key
T109: Additional ICAO 1 search Key
T110: Channel search Key
T111: Additional Ident 2 search Key
T114: Range search Key
T115: Sequence search Key
T116: Country search Key
T117: Boundary search Key
T118: Code search Key
T120: Additional Ident 3 search Key
T121: Reserved
T122: Additional Type 1 search Key
T123: Additional ICAO 2 search Key
T126: Additional Ident 4 search Key

The Navigation Dataset uses the Shapefile format. Each of the Navigation features are
represented by point features in *.shp files. Each point feature is matched to a group of attributes(describes in Appendix H) provided by the *.dbf and, optionally, *.dbt portions of the Shapefile
format. Appendix I provides the enumeration codes for the Navigation data fields.

Table 5-3: List of Navigation Components
Component Name
Airport

CS1
1

Shape Type
Component Description
Point
Area or land that is used (or intended foruse) for the landing and take-off ofaircraft.

© 2015 Open Geospatial Consortium

158

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Component Name
AirRefueling

CS1
2

AirRefuelingControl

3

AirRefuelingFootnote

4

AirRefuelingPoint

5

AirRefuelingSegment

6

AirspaceBoundary

7

AirwayRestriction

8

Approach

9

ArrestingGear

10

COMMS

11

ControlAirspace

12

EnrouteAirway

13

FirUir

14

Gate
GLS
Helipad15
16
17

Shape Type
Component Description
Point
A specifically designated airspace
where air-to-air refueling operations arenormally conducted.
Point
Information regarding the Air Traffic
Control Center that controls the airspacewithin which the refueling track or
anchor is located.
Point
Supplemental notes defining an Air
Refueling component
Point
Single Point from an Air Refuelingstructure
Multipoint
Segment from an Air Refuelingstructure
Point
Designated airspace within which someor all aircraft may be subject to air
traffic control.
Point
Altitude and time restrictions for
airways, airway segments, or sequencesof airway segments
Multipoint
Preplanned instrument flight rule (IFR)
for air traffic control approachprocedures.
Point
Safety device consisting of engaging or
catching devices, and energy absorption
devices for the purpose of arresting both
tail hook and/or non-tail hook equipped
aircraft
Point
Voice, radio communications, andfacility call sign and frequencies
available for same operations between
the airport environment and aircraft.
Multipoint
Sequential listing of vertical and laterallimits, defining airspaces of different
classifications, within which air traffic
control service is provided
Point
A specified route designed forchanneling the flow of traffic asnecessary for the provision of air traffic
services
Multipoint
Flight Information region - Upper
Information Region. Designatedairspace within which some or all
aircraft may be subject to air traffic
control.
Point
Passenger gate at an airport
Point
GNSS Landing System
Line
Designated area usually with a preparedsurface used for take-off and landing ofhelicopters© 2015 Open Geospatial Consortium

159

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Component Name
Heliport

CS1
18

HoldingPattern

19

ILS

20

Marker21

MilitaryTrainingRoute

22

MilitaryTrainingRouteAirspa
ce23

MilitaryTrainingRouteDescri
ption
MilitaryTrainingRouteOverla
y

24

MLS

26

MSA

27

Navaid28

OffRouteTerrainClrAltitude

29

ParachuteJumpArea

30

ParachuteJumpAreaBoundary
PathPoint

31
32

25

Shape Type
Component Description
Point
Area or land intended to be used forlanding and takeoff of helicopters
Point
Flight path maintained by an aircraftthat is awaiting permission to land
Multipoint
Instrument landing system - Precision
instrument approach system normallyconsisting of electronic components andvisual aids
Point
Transmitter that radiates vertically adistinctive pattern for providing position
information to aircrafts
Point
Routes used by the Department of
Defense and associated Reserve and Air
Guard Units for the purpose of
conducting low altitude navigation andtactical training in both IFR and VFR
weather conditions below 10,000 feet
MSL at airspeeds in excess of 250 KTS
IAS.
Point
Special use airspace or military
operations area associated with a
Military Training Route
Point
Supplemental information regarding a
Military Training RouteMultipoint
The width left and right of centerline
based on a set of widths at Point Ident
and another set of width at the Next
Point Ident in one segment record.
Multipoint
Microwave Landing System - precision
instrument approach system normallyconsisting of electronic components andvisual aids
Point
Minimum Safe Altitude - altitude below
which it is hazardous to fly owing topresence of high ground or otherobstacles
Multipoint
Electronic device on the surface, which
provides point-to-point guidance
information or position data to aircraftin flight
Polygon
Off-Route Terrain Clearance Altitude Clearance altitudes in non-mountainous
and in mountainous areas
Point
An area designated for parachute
jumping activities.
Multipoint
Boundary of a Parachute Jump Area
Point

© 2015 Open Geospatial Consortium

160

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Component Name
PreferredRoute

CS1
33

PresetSite
RestrictiveAirspace

34
35

Runway

36

SID

37

SpecialUse Airspace

38

STAR

39

SupplTerminalData
TerminalProcClimb

40
41

TerminalProcFeedRoute42

TerminalProcMin

43

VFRRoute

44

VFRRouteSegment
Waypoint

45
46

Shape Type
Component Description
Point
A system of routes designed tominimize route changes during theoperational phase of flight and to aid in
the efficient management of air traffic.
Point
Preset Site
Multipoint
Airspace of defined dimensions
identified by an area on the surface ofthe earth wherein activities must be
confined
Line
Rectangular area on a land airport
prepared for the landing and takeoffruns of aircraft along its length
Multipoint
Standard Instrument Departure preplanned instrument flight rule (IFR)
for air traffic control departure
procedure
Point
Airspace of defined dimensions wherein
activities must be confined because of
their nature and/or wherein limitations
may be imposed upon aircraft
operations that are not a part of those
activities.
Multipoint
Standard Terminal Arrival - preplanned
instrument flight rule (IFR) air traffic
control arrival procedure
Point
Supplemental terminal data
Point
Terminal Procedure Climb - Min or
ATC Climb rates
Multipoint
Terminal Procedure Feeder Route - Aroute depicted on Instrument Approach
Procedures to designate routes foraircraft to proceed from the en route
structure to the Initial Approach Fix
Point
Terminal Procedure Minima - Heightminima data for Terminal Procedure
Multipoint
Preplanned arrival or departure routes
for helicopters or light fixed wing
aircraft to specified airports or heliports
using/in Visual Flight Rules (VFR
Multipoint
Segment of a VFR Route
Point
Predetermined geographical position,used for route or instrument approachdefinition or progress reporting
purposes

5.2.1
Schema Files
The schema file lists the data attributes for the given NavData component. It contains thefollowing columns:© 2015 Open Geospatial Consortium

161

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Table 5-4: List of Navigation Schema Attributes

Attribute
Type
ShortName String

LengthDefinition
11
A null-terminated string (ten characters or less).
Short-hand name of the attribute used in the tiled
ShapeFiles (the dBASE III+ .dbf format limits thefield names to 10 characters or less)
DataType
String255
The data type for the attribute
KeyId
Int
4
Index key for the attribute, used when performing aquery. Not all attributes have an assigned index
key, as only a few attributes can be used to perform
a query. For each attribute with an index key, an
index key dataset will be created.
For schema files, the value of CS2 shall be T002.
Each attribute with an index Key (KeyId) has an index key dataset created. The index key dataset
includes the last three characters of the KeyId inside the component selector 2 (ex. KeyId 2101
would be dataset component selector 2 – T101).
5.2.1.1
ExampleHere is the data content of the schema file for the Airport dataset (D400_S001_T002.dbf):

Table 5-5: Example of a Navigation Schema

ShortName DataType
StoraNumbe Uint64
AlterNam
String
AsCoStNumb Uint64
BeacoAvail Bool32
City
String
CivMilTyp
CivilMilitaryType
ClearStatu
ClearanceStatus
CountryCountryEntry
DayliTim
Float32
DayTimFram String
FlipPage
StringFuelType
String
HydElePres Bool32
IataCode
String
IcaoCode
String© 2015 Open Geospatial Consortium

KeyId
2101

2116

2103

162

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
ShortName DataType
KeyId
Ident
String2102
IfrCapabil
Bool32IslanGrou
StringJasu
String
LonRunLeng Uint32
LonRunSurf PavementType
MagTruIndi MagneticTrueIndication
MagneVaria Float32
MgrsPositi
StringName
StringNavIcaCod
StringNavaiIden
String
Notam
NotamSystem
OilType
StringOperaAgenc String
OperaHour
OperatingHours
Point1
GeoCoordinate
RemarkStringServiRemar String
SpeedLimit
Uint32
SpeLimAlti Sint32
StateName
StateEntry
SupFluTyp
StringTerraImpac
Bool32Timezone
Float32
TransAltit
Sint32
TransLeve
Sint32
As per this example, four Airport attributes can be used to perform queries:
StoraNumbe (key index 2101)
Ident (key index 2102)
IcaoCode (key index 2103)
Country (key index 2116)
5.2.2
Key Datasets
The index Key Datasets are sorted lists used to perform queries within the NavData. For each
attribute that has an index key in the schema file, an index Key Dataset must be created. For Key
Datasets, the Dataset Component Selector 2 shall include the last three digits of the index key
from the schema file.

© 2015 Open Geospatial Consortium

163

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Table 5-6: List of Navigation Key Attributes

Attribute
Type
Value
StringLengthDefinition
255
Value of the data attribute sorted inincreasing order (numbers or characters)
Lat ID
Signed Integer 3
Latitude index of the Geocell whichcontains the data record
Lon ID
Signed Integer 4
Longitude index of the Geocell whichcontains the data record
Row ID
Integer4
Index of the data record in the Geocell
starting at 1.
This information can then be used to rapidly lookup which CDB Tile contain the data in the
pageable NAV dataset (401) and use the Object ID to access the data record in this dataset.
The Storage number is a Primary Surrogate key that uniquely identifies each record within each
NAV dataset sub components.
5.2.2.1
ExampleFor the Airport NavData Component, there shall be 4 key datasets (for attributes StoraNumber,
Ident, IcaoCode and Country):\CDB\Navigation\400_NavData\D400_S001_T101.dbf(StoraNumber, key index 2101)\CDB\Navigation\400_NavData\D400_S001_T102.dbf(Ident, key index 2102)\CDB\Navigation\400_NavData\D400_S001_T103.dbf(IcaoCode, key index 2103)\CDB\Navigation\400_NavData\D400_S001_T116.dbf(Country, key index 2116)

The following is an excerpt from the D400_S001_T102.dbf file (Key Dataset for the Ident
attribute):

Table 5-7: Example of Navigation Keys

Value
00CA
00UT
00WI
01LS
01MT
01WI
02P
03AZ

Object ID
2
3
6
4
3
2
0
5

Lon ID
-117
-113
-90
-92
-115
-91
-78
-111

Lat ID
35
37
44
30
48
44
40
31

© 2015 Open Geospatial Consortium

164

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Value
03CO
03GA
04CA
04MS
04NV
05CL
05LS
05UT
06FA
06MN
06MO
06TE
07FA
07MT

Object ID
3
5
10
4
1
2
2
0
0
1
7
10
7
1

Lon ID
-105
-84
-118
-91
-116
-123
-93
-111
-81
-93
-95
-96
-81
-107

Lat ID
40
31
34
32
35
38
31
37
26
47
39
30
25
48

For example, the Airport with Ident 04CA shall be found in the Geocell with southwest corner at
N34:00:00/W118:00:00. It will be the 10th record in the corresponding Shapefile.
Here is an example of the Storage number being used as a reference between Navigation types:
Type: Approach
Attributions:o StoraNumbe Storage number (Approach)o AirStoNumb Airport storage number (referenced)
In this case, we see the Approach navigation type referencing the Airport navigation type byusing the Airport Storage number.
5.3
CDB Model Textures
The following table provides the Component Selectors associated with all kinds of textures thatare usable on geotypical (GT), geospecific (GS), moving (MM), and tiled (T2D) models.
In the context of CDB model textures, the first component selector is known as the “Texture
Kind” and the second component selector is simply called the “Texture Index”. Column 1 lists
all texture kinds supported by the Specification. The second column gives the range of indicesallowed for each kind.

Table 5-8: Component Selectors for CDB Model Textures
CS1
CS2(Kind) (Index)

ComponentName© 2015 Open Geospatial Consortium

Component
Description

165

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CS1
CS2
Component(Kind) (Index)
Name
001
001
Year-Round
TextureComponent
Description
Base textures for year-round usage on model shells or generalbase textures for model interiors.

002

001..012 Monthly
TextureBase textures for monthly usage on the shell of models(enumeration values in Appendix O, details in section 6.13.5.2)003

001..004 Seasonal
TextureDeprecated – Replaced with kind 009

004

001..999 Uniform Paint
SchemeBase textures for Moving Models with Uniform Paint Schemes(enumeration values in Appendix O, details in section 6.13.5.2)005

001..999 Camouflage
Paint Scheme

Base textures for Moving Models with Camouflage Paint
Schemes (enumeration values in Appendix O, details in section
6.13.5.2)006

001..999 Airline Paint
SchemeBase textures for Moving Models with Airline Paint Schemes(enumeration values in Appendix O, details in section 6.13.5.2)

007

001..999 Shadow Map

Base textures of Moving Models Shadows to be projected onto
terrain and/or culture (details in section 6.13.5.1.2)

008

001..999 Motion Blur
TextureBase textures for use with rotating parts (details in section
6.9.2.3)009

001..004 Quarterly
TextureBase textures for quarterly usage on the shell of models(enumeration values in Appendix O, details in section 6.13.5.2)

051

001..999 Night Map

Subordinate textures to simulate the effect of lights inside 3Dmodel shells (details in section 6.13.5.3)

052

001..999 Tangent-Space
Normal Map

Subordinate textures used to simulate the effect of irregularsurfaces (details in section 6.13.5.5)053

001..999 Light Map

Subordinate textures to simulate the effect of lights on
surrounding surfaces (detail in section 6.13.5.4)054

001..999 Contaminant

Subordinate textures to represent the presence of particules on
runways, taxiways, and roads in general (enumeration values inAppendix O, details in section 6.13.5.7)055

001..999 Skid Mark

Subordinate textures to represent the visible mark left by any
solid which moves against another one; especially marks of tires
on roads and runways (enumeration values in Appendix O,
details in section 6.13.5.7)056

001..999 Detail Texture

Subordinate texture used to add detail to the surface. In mostcases, modelers use detail textures to add a finer scaled texture to
the base texture (details in section 6.13.5.6)© 2015 Open Geospatial Consortium

166

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CS1
CS2
Component(Kind) (Index)
Name
057 001..999 Cubic
Reflection Map

Component
Description
Subordinate textures to simulate reflective surfaces (details in
section 6.13.5.8)

058

Subordinate textures providing the glossiness of a surface on a
per-pixel basis (details in section 6.13.5.9)099

001..999 Gloss Map
001

Night Map

Deprecated – Replaced with kind 051

002

Bump Map

Deprecated – Replaced with kind 052

003

Light Map

Deprecated – Replaced with kind 053

Appendix O enumerates all textures allocated to kind 002, 003, 004, 005, 006, and 055.
5.4
GTModel Library Datasets
Table 5-9 provides the component selector values associated with all GTModel datasets.

Table 5-9: Component Selectors for GTModel Datasets
File
Component
Component
Extension
Name
Description
Dataset 500, GTModelGeometry
001
001
*.flt
Geometry OpenFlight files containing the references to both the
Entry File shell and interiors of all levels of detail of geotypicalmodels.
Dataset 510, GTModelGeometry
001
001
*.flt
Geometry OpenFlight files containing the geometry of the shell ofLevel ofgeotypical models for a given level of detail.
DetailDataset 506, GTModelInteriorGeometry
001
001..999*.flt
Interior
OpenFlight files describing the geometry of the interior
Geometry of geotypical models for a given level of detail. The
value of Component Selector 2 is the file number.
Multiple files are used when the complexity of theinterior justifies using more than one file.
Dataset 503, GTModelDescriptor
Dataset 508, GTModelInteriorDescriptor
CS1

CS2

© 2015 Open Geospatial Consortium

167

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CS1

CS2

001

001

File
Component
Component
Extension
Name
Description.xml
Descriptor Provides the metadata associated with a GTModel.
See section 6.14, Metadata, for a description of thecontent.

Dataset 511, GTModelTexture
Dataset 507, GTModelInteriorTexture*.rgb
TextureDataset 504, GTModelMaterial
Dataset 509, GTModelInteriorMaterial001
001..255*.tif
Composite
Material
Index
002
001..254*.tif
Composite
Material
MixtureDataset 505, GTModelCMT
Dataset 513, GTModelInteriorCMT
001
001
*.xml
Composite
Material
Table

NOTE: A model descriptor includes a Composite
Material Table for the exclusive use by its
corresponding model geometry datasets above. This
CMT is not to be confused with the GTModelCMT and
GTModelInteriorCMT datasets below.
Individual base and subordinate textures applied onmodel geometry, see the complete list in section 5.3,
CDB Model Textures.
Each texel is an index into the associated Composite
Material Table (dataset 505 and 513 below). CS2 isthe layer number.
Each texel indicates the proportion (between 0.0 and
1.0) of the composite material found in thecorresponding material layer. Component Selector 2 isthe layer number. When the texels are of integral
types, they are scaled to the range 0.0 to 1.0.

The Composite Material Table is associated with
Material Textures; it contains the definition of thecomposite materials referenced by the model material
datasets above. Its format is as specified in section
2.5.2.2, Composite Material Tables (CMT)
Dataset 512, GTModelSignature (See notes 1 and 2 below)
001..999 001..016
*.shp
RCS
The Shapefile containing the Radar Cross Section of a
Signature geotypical model as described in Chapter 7.
*.shx
*.dbf
017..032*.dbf
RCS Class The class-level attributes associated with the RCS
Attributes Signature file as described in Chapter 7.

Note 1: For GTModelSignature dataset, CS1 refers to the “RCS Frequency” and is used toindicate at which frequency (in MegaHertz) the dataset was generated for. The value of CS1
represents a power of 10 of the frequency and ranges from 1 to 999. The range of frequencies
that can be represented is from 101 MHz to 10999 MHz.
Note 2: For GTModelSignature dataset, CS2 refers to the “RCS Polarization Type” and is used
to indicate how the electromagnetic field is polarized at transmission and reception by typical
Radar. The value can range from 1 to 16 for the instanced-level attributes and from 17 to 32 forthe class-level attributes.

© 2015 Open Geospatial Consortium

168

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Polarization Type (CS2)
Instance Attribute
Class Attribute
1
17
2
18
3
19
4
20
5
21
6
22
7
23
8
24
9
25
10
26
11
27
12
28
13
29
14
30
15
31
16
32

Description
LINEAR Polarization
CIRCULAR Polarization
ELLIPTICAL Polarization
SINGLE HH Polarization
SINGLE HV Polarization
SINGLE VV Polarization
SINGLE VH Polarization
DUAL HH-HV Polarization
DUAL VV-VH Polarization
DUAL HH-VV Polarization
ALTERNATING HH-HV Polarization
ALTERNATING VV-VH Polarization
POLARIMETRIC HH Polarization
POLARIMETRIC VV Polarization
POLARIMETRIC HV Polarization
POLARIMETRIC VH Polarization

5.5
MModel Library Datasets
Table 5-10 provides provide the component selector values associated with all Mmodel datasets.

Table 5-10: Component Selectors for Mmodel Datasets
File
Component
Component
Extension
Name
Description
Dataset 600, MmodelGeometry (See note 1 below)
001..999 001..999*.flt
Geometry OpenFlight files containing the geometry of
Mmodels as described in Chapter 6.
Dataset 601, MmodelTexture*.rgb
TextureIndividual base and subordinate textures applied onmodel geometry, see the complete list in section
5.3, CDB Model Textures.
Dataset 603, MmodelDescriptor
001
001
*.xml
Descriptor Provides the metadata associated with a Mmodel.
See section 6.14, Metadata, for a description of thecontent.
CS1

CS2

Dataset 604, MmodelMaterial

NOTE: The MmodelDescriptor includes aComposite Material Table for the exclusive use by
the MmodelGeometry dataset. This CMT is not tobe confused with the MModelCMT dataset below.

© 2015 Open Geospatial Consortium

169

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
File
Component
Component
Extension
Name
Description
001
001..255*.tif
Composite Each texel is an index into the Composite Material
Material
Table (dataset 605). Component selector 2 is theIndexlayer number.
002
001..254*.tif
Composite Each texel indicates the proportion (between 0.0
Materialand 1.0) of the composite material found in the
Mixturecorresponding material layer. Component Selector
2 is the layer number. When the texels are of
integral types, they are scaled to the range 0.0 to
1.0.
Dataset 605, MModelCMT
001
001
*.xml
Composite This is the composite material table for use with
Material
MmodelMaterial dataset. Its content is described
Table
in section 2.5.2.2, Composite Material Tables(CMT).
Dataset 606, MmodelSignature (See notes 2 and 3 below)
001..999 001..016
*.shp
RCS
The Shapefile containing the Radar Cross Section
Signature of a moving model as described in Chapter 7.
*.shx
*.dbf
017..032*.dbf
RCS Class The class-level attributes associated with the RCS
Attributes Signature file as described in Chapter 7.
CS1

CS2

Note 1: For the MmodelGeometry dataset, the geometry of a moving model can be made of one
or more parts, each stored in one or more files depending on how complex a part is.
The value of CS1 represents the part number. A Moving Model has at least one part, the model
itself that is also used as a master file for all the other parts when applicable. This is part number
1. Other parts are numbered sequentially. An example of an extra part is a removable externalfuel tank.
The value of CS2 is the file number. It is used when the complexity of a part requires using
more than one file. The file number starts with 1. A part that references external files does it
through OpenFlight Xref nodes.
Note 2: For MmodelSignature dataset, CS1 refers to the “RCS Frequency” and is used toindicate the range of frequencies (in MegaHertz) the dataset was generated for. The range is theset of frequencies from 10CS1-1 MHz without exceeding 10CS1 MHz.
Note 3: For MmodelSignature datasets, CS2 refers to the “RCS Polarization Type” and is used
to indicate how the electromagnetic field is polarized at transmission and reception by typical
Radar. The value can range from 1 to 16 for the instance-level attributes of polarizations andfrom 17 to 32 for the class-level attributes of polarizations.

© 2015 Open Geospatial Consortium

170

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Polarization Type (CS2)
Instance Attribute
Class Attribute
1
17
2
18
3
19
4
20
5
21
6
22
7
23
8
24
9
25
10
26
11
27
12
28
13
29
14
30
15
31
16
32

Description
LINEAR Polarization
CIRCULAR Polarization
ELLIPTICAL Polarization
SINGLE HH Polarization
SINGLE HV Polarization
SINGLE VV Polarization
SINGLE VH Polarization
DUAL HH-HV Polarization
DUAL VV-VH Polarization
DUAL HH-VV Polarization
ALTERNATING HH-HV Polarization
ALTERNATING VV-VH Polarization
POLARIMETRIC HH Polarization
POLARIMETRIC VV Polarization
POLARIMETRIC HV Polarization
POLARIMETRIC VH Polarization

5.6
Tiled Raster Datasets
A raster dataset consist in an evenly spaced grid of data elements that are positioned (ingeographic units) along the north-south and east-west axis. This section describes all of the CDB
raster datasets.
Most of the CDB raster datasets are broken down further into components. A component is a
specialization of the dataset. For example, bathymetry is a specialization of altimetry data
because it is targeted to the representation of submerged terrain surfaces; the bathymetric depth
data represents altimetry (e.g., heights) with respect to the Primary Elevation component.
Together, the Primary Elevation and Bathymetry components form the Elevation Dataset.
A component can be either 1) “primary”, (i.e., it can be used on a stand-alone basis) or 2)“subordinate”, (i.e., it must be used in conjunction with one or more primary components andone or more subordinate components). Subordinate components depend on information
contained within another component. Subordinate components are used to progressively add
complexity and/or information to a primary component or to another subordinate component.
For instance, the Elevation component is a primary component that contains information to allow
a simulator client-device to accurately represent the terrain profile or determine the terrain
height. On the other hand, Bathymetry is a subordinate component because it cannot be used
stand-alone and that it is implicitly subordinate to the Elevation component. It uses the Elevation
component to determine the depth of an ocean.

© 2015 Open Geospatial Consortium

171

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Primary(Elevation)

Subordinate(Bathymetry)

In addition to the notion of primary and subordinate, the CDB embodies the notion ofComponent Alternates. A component is said to be an alternate component if it can be usedinterchangeably with other components.
The two concepts can be used in combination as follows:1.
Primary
2.
Subordinate or
3.
Primary Alternate
4.
Subordinate Alternate
A component is Primary if the component is not dependent on another component, i.e., it can beused on a stand-alone basis. Conversely, a component is said to be Subordinate if the dataset isdependent on another component, be it a primary component or another subordinate component.
For example, the Bathymetric component is referenced to the CDB Primary terrain elevation
component; as a result, it is a subordinate component. The Primary elevation component is a
primary component because it does not depend on any other component.

Primary

Subordinate
Alternate #1

Subordinate
Alternate #2

A component is Primary Alternate if a) the component is not dependent on another component,
be it a primary component or another subordinate component and b) other primary components
can be used interchangeably with the component. For example, the VSTI Q1, Q2, Q3 and Q4components are all primary alternate components, because they each form the primary layer ofterrain imagery, yet they can be used interchangeably.

© 2015 Open Geospatial Consortium

172

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Primary
Alternate

Primary
Alternate

Primary
Alternate

Primary
Alternate(Q1 VSTI)(Q2 VSTI)(Q3 VSTI)(Q4 VSTI)

Finally, a component is Subordinate Alternate if a) if the component is dependent on anothercomponent, be it a primary component or another subordinate component and b) othersubordinate components can be used interchangeably with the component.
In the case of alternate components, one of them is designated as the default component; in theevent that an alternate component is missing in the CDB, the client-devices are required to revert
to the default alternate component.
Since subordinate components usually improve the overall fidelity of the dataset, client-devices
can revert to the primary component in the event that a subordinate component is missing in the
CDB. This behavior allows the CDB Specification to meet one important objective which is toallow any simulator client-device with relatively low performance to still be able to run a CDB
implementation (scalability).
Conceptually, the raster dataset tile’s internal grid structure uniformly subdivides the tile in bothaxes. The main characteristic of raster tile is that the number of data elements and the position of
every data element are implicit. The application must derive the data element position from thegeodetic tile position. The tile grid structure is aligned to the tile edge boundary. The gridelements are organized in row, column order, starting from the northwest corner scanningtowards the southeast. This is true for tiles in both the south and north hemisphere. The CDB
Specification accommodates for data elements that can be aligned either to the centers or to thecorners of the internal tile grid structure. In both cases, the number of data elements in the tile isa power of two. Furthermore, data elements can either represent values representative of
samples on the earth surface (e.g., altitude at a point) or values representative of a surface area on
the earth surface (average altitude over square area).
Figure 5-1: Center Grid Data Elements, illustrates a CDB tile with a grid of “center grid data
elements” overlaid onto the tile’s grid structure with the addressing conventions and thealignment of the samples and areas assigned to each of the data elements.

© 2015 Open Geospatial Consortium173

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-1: Center Grid Data Elements

Figure 5-2: Corner Grid Data Elements, illustrates a CDB tile with a grid of “corner grid data
elements” overlaid onto the tile’s grid structure with the addressing conventions and thealignment of the samples and areas corresponding to the data elements.

Figure 5-2: Corner Grid Data Elements

Figure 5-3: Center Data Elements as a Function of LODs, illustrates an implementation of center
grid data elements with four levels-of-details. Note the shift in position of the data element
centers along the x- and y-axis as we shift to progressively coarser levels-of-detail. Note also

© 2015 Open Geospatial Consortium

174

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
that the edges of the data elements areas stay aligned with x- and y-axis as we shift toprogressively coarser levels-of-detail.

Figure 5-3: Center Data Elements as a Function of LODs

Figure 5-4: Corner Data Elements as a Function of LODs, illustrates animplementation of corner grid data elements with four levels-of-details. Note theshift in the edge of the data element area along the x- and y-axis as we shift toprogressively coarser levels-of-detail. Note also that the position of the data elements
areas stay aligned with x- and y-axis as we shift to progressively coarser levels-ofdetail.

Figure 5-4: Corner Data Elements as a Function of LODs

Sections 5.6.1, 5.6.2, and 5.6.3 describe all of the raster datasets, namely the Tiled Elevation
Dataset, the Tiled Imagery Dataset, and the Tiled Raster Material Dataset; each of these sections
describes the associated “corner” versus “center” conventions. This convention is intrinsic to thecorresponding dataset and is not parametrical. Any changes to these implicit properties require
an additional specific dataset to ensure compatibility with applications.
The latitude and longitude of an implicit corner data element (in a tile) with coordinates (i, j) is
computed as per the following equation (note the equation for XunitLOD and YunitLOD can befound in eq. 3-4)

Latitude = TileLatitude − ( j × YUnit LOD )(eq. 5-1)
Longitude = TileLongitude + (i × XUnit LOD )Where TileLatitude, TileLongitude are the tile coordinates at the upper left corner and (i, j) are
the data element coordinates.

© 2015 Open Geospatial Consortium

175

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Similarly, the position of an implicit center data element in a tile is computed as per thefollowing equation:

Latitude = TileLatitude − (( j + 0.5) × YUnit LOD )Longitude = TileLongitude + ((i + 0.5) × XUnit LOD )(eq. 5-2)

5.6.1
Tiled Elevation Dataset
In a CDB, terrain elevation is depicted by a grid of data elements at regular geographic intervals
and at prescribed locations within the tile; each grid element is associated with an elevation
value. The resultant is a Digital Elevation Model (DEM) of the earth surface with respect (above
or below) to the WGS-84 reference ellipsoid. The Elevation Dataset implicitly follows thecorner grid element conventions.

Figure 5-5: Example of Digital Elevation Model (DEM)

The (x, y) coordinates of each grid element are its longitude and latitude, respectively. The
Elevation dataset holds the vertical extent of the terrain. In Figure 5-6: DEM Depicted as a Gridof Elevations at Regular Sample Points, obstacles such as a tower and a building have been
overlaid on the terrain grid to demonstrate that obstacle heights are relative to the terrain height.

© 2015 Open Geospatial Consortium

176

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-6: DEM Depicted as a Grid of Elevations at Regular Sample Points

The CDB LOD structure lends itself to variable levels of terrain elevation fidelity, on a per TileLOD basis. The selected grid spacing is a function of the height and geographic precision that isdesired. Through the use of LODs, one can specify a grid spacing appropriate to the required
terrain fidelity requirements. For instance, the accurate depiction of a runway profile (say down
to 1 ft height precision) would typically require a relatively fine pitch terrain elevation LOD even
if the area is nominally flat. Similarly, the accurate representation of sharp altitude
discontinuities (e.g., cliffs) also requires increasingly finer elevation grids to capture the cliff
profile correctly.
Negative elevation values do not imply that the elevation point is submerged; rather, a negativevalue merely indicates that its altitude is below the WGS-84 reference ellipsoid.
The CDB Specification defines a number of subordinate elevation components that are used in
combination with the primary component of the Elevation Dataset.
5.6.1.1
Terrain Mesh Types
The CDB Specification defines two mesh types to connect each grid post to its neighbors. The
purpose of the mesh type is to minimize the error in the representation of the Terrain Profile built
from the components of the Elevation dataset. Figure 5-7 below illustrates the supported CDB
Mesh Types.

© 2015 Open Geospatial Consortium

177

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014Mesh	
  Type	  0Mesh	
  Type	  1

Figure 5-7: CDB Mesh Types

Mesh type 0 connects the southwest grid post to its northeast neighbor while mesh type 1 does
the same for the northwest and southeast posts.
5.6.1.1.1 Data TypeThe mesh type is represented by an unsigned integer of a size that is large enough toaccommodate the range of mesh types defined by the Specification. As of this version of theSpecification, there are only two values defined; as such, an 8-bit unsigned integer is sufficientand appropriate to store the mesh type.
5.6.1.1.2 Default Value
By default, when the mesh type is not specified or not available, a value of zero is assumed.
5.6.1.2
List of all Elevation Dataset Components
The Elevation Dataset is comprised of several components listed here and detailed in thesubsequent sections.

Table 5-11: Elevation Dataset Components
CS1

CS2

Component
Description

File
Component
Extension
Name

Dataset 001, Elevation
001
*.tif
001

001

002

*.tif

001

003

*.tif

Primary
TerrainElevation
Primary
TerrainElevation
ControlPrimary
Alternate
TerrainElevation

A grid of data representing the Elevation at thesurface of the Earth. Stored as a 1 or 2-channel
TIFF image. When present, the second channel
provides the mesh type of each grid element.
DeprecatedA grid of data representing the Elevation of thesurface of the Earth at specified Latitude andLongitude offsets inside each grid element. Stored
as a 4-channel TIFF image.

© 2015 Open Geospatial Consortium

178

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Component
File
Component
Description
ExtensionName
002..099 001*.tif
Subordinate DeprecatedTerrainElevation
002..099 002*.tif
Subordinate DeprecatedTerrainElevation
Control
100
001
*.tif
Subordinate A grid of data representing the Depth of water with
Bathymetry respect to the selected Terrain Elevation
component. Store as a 1 or 2-channel TIFF image.
When present, the second channel provides themesh type of each grid element.
100
002
*.tif
Subordinate A grid of data representing the Depth of water at
Alternatespecified Latitude and Longitude offsets inside
Bathymetry each grid element with respect to the selected
Terrain Elevation component. Stored as a 4channel TIFF image.
101
001
*.tif
Subordinate A grid of data representing the average heightTide
variation of water with respect to the Primary
Elevation
Terrain Elevation Component.
Dataset 002, MinMaxElevation
001
001
*.tif
Minimum
Minimum height (on a per tile LOD basis) of the
Elevation
Primary Terrain Elevation Dataset Component(excluding all cultural features).
001
002
*.tif
Maximum
Maximum height (on a per tile LOD basis) of the
Elevation
Primary Terrain Elevation Dataset Component(excluding all cultural features).
Dataset 003, MaxCulture
001
001
*.tif
Primary
Maximum height (on a per tile LOD basis) of theMaximumbounding boxes of all cultural features held in the
Culturevector tiled datasets within the geographic footprint
Elevationof the area represented by the sample value.
CS1

CS2

5.6.1.3
Primary Terrain Elevation Component
The Primary Terrain Elevation component of the Elevation dataset represents the surface of the
Earth, i.e., the emerged part of the Earth’s crust, the surface of persistent bodies of water (e.g.,
ocean, lakes, rivers), and the permanent ice-covered parts of the Earth. However, the Primary
Terrain Elevation values exclude the heights of natural vegetation and man-made culturalfeatures.

© 2015 Open Geospatial Consortium

179

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-8: Primary Terrain Elevation Component

By definition, the Primary Terrain Elevation component represents a single elevation value ateach grid element of the dataset. As a result, each value of the Primary Terrain Elevation
component corresponds to the elevation of the highest Earth surface at the specified latitude andlongitude coordinate. Consider the example illustrated in Figure 5-8: Primary Terrain Elevation
Component. The diagram illustrates a region of Earth with a well, an overhanging cliff, and a
network of tunnels. Using solely the Primary Terrain Elevation component, the resulting terrain
representation corresponds to the continuous terrain profile represented by the red dotted line; asa result, the underside of the overhanging cliff, the tunnels, and the vertical walls of the well are
not represented.
To represent terrain walls, overhanging cliffs, wells, tunnels and mineshafts, modelers are
required to supplement the Primary Terrain Elevation component with terrain-conformed 3Dmodels as illustrated in Figure 5-9: Modeling of Wells, Overhanging Cliffs and Tunnels.
Embedded within such 3D models are special cutout zones which represent the clipping
geometry that is used to cut out the terrain skin.

© 2015 Open Geospatial Consortium

180

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-9: Modeling of Wells, Overhanging Cliffs and Tunnels

Model cutouts are explained in section 6.5.6.3, Model Cutout Zones and model conforming
modes are described in section 6.7, Model Conforming.
5.6.1.3.1 Data TypeThe Primary Terrain Elevation component of the Elevation dataset is represented as a 1 or 2channel TIFF image. The first channel contains the Elevation of the grid post; the optional
second channel indicates the Mesh Type used to connect the four grid posts that are adjacent to
the grid element. The elevation is represented by a floating-point or signed integer value
expressed in meters and relative to the WGS-84 reference ellipsoid. Integer values for tiles at
LOD larger than 0 are scaled according to the following formula:

𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼×2
Integer values can make use of TIFF’s 8-bit, 16-bit, or 32-bit representation.
The Mesh Type is stored as an unsigned 8-bit integer.
5.6.1.3.2 Default Read Value
Simulator client-devices should assume an Elevation value of Default_Elevation-1 if the data
values of the Primary Terrain Elevation component are not available (files associated with thePrimary Terrain Elevation component for the area covered by a tile, at a given LOD or coarser,
are either missing or cannot be accessed). The default value is stored in© 2015 Open Geospatial Consortium

181

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
\CDB\Metadata\Defaults.xml. In absence of a default value, the CDB Specification states thatclient-devices use a value of zero.
If the TIFF file has a single channel image, client devices assume a Mesh Type of zero.
5.6.1.3.3 Default Write Value
The files associated with the Primary Terrain Elevation component for area covered by a tile at agiven LOD need not be created if the source data is not available. Tiles partially populated withdata are not permitted. If the tool generating the Primary Terrain Elevation does not support theoptional Mesh Type, the optional second channel of the file need not be created; in which case
the TIFF file becomes a single channel image.
5.6.1.3.4 Supported Compression Algorithm
The CDB Specification supports the LZW compression algorithm for the Primary Terrain
Elevation component. Consider compressing the file if its content is not of type floating-point.
5.6.1.4
Primary Alternate Terrain Elevation Component
The accurate delineation of man-made elevation features such as roads, railroads, runways, andnatural elevation features such as ridgelines, coastlines requires very high levels-of-detail for thePrimary Terrain Elevation component. Such cases typically require an elevation grid pitch of
approximately ½ m or better (the equivalent of 8 million triangles per square kilometer) resulting
in unnecessary large storage and runtime processing. The Primary Alternate Terrain Elevation
component offers an effective solution to handle these use-cases.
The Primary Alternate Terrain Elevation component provides the means to accurately delineate
terrain features without having to revert to very fine LODs of the Primary Terrain Elevation
component. To do this, the Primary Alternate Terrain Elevation component encodes informationthat re-positions each elevation sample anywhere within its assigned grid element. In otherwords, the “phase” of each terrain elevation sample can be specified along the latitude andlongitude axes. In effect, the Primary Alternate Terrain Elevation component provides themeans to locally increase the altimetric precision of the modeled representation of a terrain
profile. While it would be possible for a modeler to manually control the position of individual
elevation points, it is expected that the SE tools automate this process by considering elevation
constraint points, lineals and areals provided by the modeler.
The constituents of the Primary Alternate Terrain Elevation are the elevation and mesh type atthe specified latitude and longitude offsets inside each grid element. These four constituents are
represented as 4 channels of a TIFF image.
The latitude and longitude offsets are expressed as unsigned 8-bit integer values that provide
position offsets expressed as 1/256th of the grid spacing for the LOD in question. Note thatsince the movement of each elevation point is constrained to the inside of its respective gridelement, it is impossible to disrupt the (regular grid) topology of the elevation grid; furthermore,© 2015 Open Geospatial Consortium

182

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
it is impossible to have elevation points that move outside of the confines of the tile-LOD.
Figure 5-10 illustrates the valid offset values inside each grid element of a tile-LOD.

Figure 5-10: Encoding of Lat/Long Offsets

Figure 5-11 illustrates the coverage of grid elements inside a CDB tile. It shows that a grid postis allowed to move inside the area covered by its grid element.

Figure 5-11: Grid Element Coverage within a CDB Tile

The Latitude Offset is expressed as an 8-bit unsigned integer value ranging from 0 to 255. The
value is scaled so that each grid element is fragmented in 256 equal parts in the latitude direction.

© 2015 Open Geospatial Consortium

183

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Thus, the elevation point cannot be positioned on the latitude of the next grid element directly
north of the current grid element.
The Longitude Offset is expressed as an 8-bit unsigned integer value ranging from 0 to 255. The
value is scaled so that each grid element is fragmented in 256 equal parts in the longitude
direction. Thus, the elevation point cannot be positioned on the longitude of the next gridelement directly east of the current grid element.
5.6.1.4.1 Data TypeThe first channel of the TIFF image contains the Elevation component and is represented as afloating-point or signed integer value. Integer values for tiles at LOD larger than 0 are scaled
according to the following formula:

𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼×2
Integer values can make use of TIFF’s 8-bit, 16-bit, or 32-bit representation.
The second channel of the TIFF image contains the Mest Type and is stored as an unsigned 8-bit
integer.
The third and fourth channels contain the Latitude and Longitude Offset components and arestored as unsigned 8-bit integers.
5.6.1.4.2 Default Read Value
Simulator client-devices should assume an Elevation value of Default_Elevation-1 if the data
values of the Primary Alternate Terrain Elevation component are not available (files associatedwith the Primary Alternate Terrain Elevation component for the area covered by a tile, at a given
LOD or coarser, are either missing or cannot be accessed). The default value is stored in\CDB\Metadata\Defaults.xml. In absence of a default value, the CDB Specification states thatclient-devices use a value of zero.
The default Mesh Type, Latitude and Longitude Offsets are zero.
5.6.1.4.3 Default Write Value
The files associated with the Primary Alternate Terrain Elevation component for an area coveredby a tile at a given LOD need not be created if the source data is not available. Tiles partially
populated with data are not permitted.

© 2015 Open Geospatial Consortium

184

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.1.4.4 Supported Compression Algorithm
The CDB Specification supports the LZW compression algorithm for the Primary Alternate
Terrain Elevation component. Consider compressing the file if its content is not of type floatingpoint.
5.6.1.5
Terrain Constraints
There are many instances where modelers may wish to take advantage of the availability ofposition and altitude of cultural features in order to locally control the terrain elevation data at apoint, along a specified contour line or within a given area. This operation is usually performed
off-line by the modeler and requires that the Elevation dataset be edited and re-generated offline.
Table 5-12: Partial List of Hypsography FACCs (for Offline Terrain Constraining)

The Data Dictionary of CDB Specification makes provision for the representation of many
hypsography features within the Geopolitical Dataset (see Table 5-12: Partial List of
Hypsography FACCs (for Offline Terrain Constraining). By virtue of their semantics, thesefeatures have no associated modeled representation. The modeler can use these hypsography
features to control the generation of the Terrain Elevation grid during the off-line CDB
compilation process. This terrain constraining operation can be performed by the SE tools as the
CDB is “assembled and compiled”. Note that runtime client-devices do not constrain the Terrain
Elevation Dataset to hypsography features. When terrain constraining is performed off-line,© 2015 Open Geospatial Consortium

185Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
hypsography features must have AHGT set to True, thereby instructing the SE Tools to constrain
the terrain elevation using the supplied (lat-long-elev) coordinates. The Shapefile feature must
be a PointZ, a MultiPointZ, a PolyLineZ, a PolygonZ or a MultiPatch.
While these hypsography features can be used by the off-line SE tools to control the terrain
skinning process, these features can be instead converted into Constraint Features, thereby
deferring the terrain constraining process to runtime client-devices.
Constraint Features are features that instruct client-devices to runtime-constrain the terrain
Elevation Dataset to a set of prescribed elevation values. This provides modelers the ability toaccurately control terrain elevation profiles even if the Terrain Elevation Dataset is of modest
resolution and is regularly-gridded; furthermore, the original Elevation Dataset remains
unaffected. In effect, the Constraint Features provides a storage-efficient means of capturing
terrain contours without having to re-generate / reskin the terrain to a higher-resolution.
Note that this operation is performed on Elevation Datasets that are regularly-gridded orirregularly-gridded. This capability is particularly effective when modelers wish to accurately
control terrain elevation profiles but only have regularly-gridded source elevation data of modest
resolution at their disposal. Each of these features is associated with vertices that define elevation
at the supplied lat-long coordinate(s). This approach provides a level-of-control similar to that ofTerrain Irregular Networks (TINs).
The following Constraint Features are used for Online Terrain Constraining:
Elevation Constraint Point (CA099-000): In the case of PointZ and MultiPointZ
features, the coordinates are used by the client-device to control the terrain
elevation at the specified (lat-long). The Feature’s AHGT attribute must be set to
TRUE. Note that features implemented as Shapefile Point, PointM, MultiPoint,
MultiPointM are ignored.
Elevation Constraint Line (CA099-001): In the case of PolyLineZ features, thecoordinates are used by the client-device to control the terrain elevation at the
specified (lat-long). The Feature’s AHGT attribute must be set to TRUE. Notethat features implemented as Shapefile PolyLine and PolyLineM are ignored.
Elevation Constraint Area (CA099-002): In the case of PolygonZ and MultiPatchfeatures, the coordinates are used by the client-device to control the terrain
elevation at the specified (lat-long). The Feature’s AHGT attribute must be set to
TRUE. Note that features implemented as Shapefile Polygon and PolygonM are
ignored.

© 2015 Open Geospatial Consortium

186

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 5-13: List of Hypsography FACCs (for Online Terrain Constraining)

An example of a point-feature is illustrated in Figure 5-12 . This picture shows a storage tanklocated atop a hill. Given the high terrain relief in this area, the modeler is concerned that theterrain may slope significantly in the immediate vicinity of the storage tank, particularly atcoarser LODs of the uniform-sampled terrain elevation grid. As a result, he defines a PointZ
Constraint Point feature that coincides with the position of the storage tank. AHGT set to Trueso that the client-device will constrain the Terrain Elevation dataset to the supplied value.

Figure 5-12: Storage Tank Point-Feature

A second example of this principle illustrated in Figure 5-13, this time applied to a road linealfeature. This picture shows a divided highway running alongside a mountainous area. Given thehigh terrain relief in this area, the modeler is concerned that the terrain may slope significantly in
the immediate vicinity of the road, particularly at the coarser LODs of the uniform-sampledterrain elevation grid. As a result, he defines a PolyLineZ Constraint Lineal feature that© 2015 Open Geospatial Consortium

187

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
coincides with the centerline of the road; AHGT set to True so that the client-device will
constrain the Terrain Elevation dataset to the supplied coordinates of the lineal feature.
The CDB Specification has well over 50 FACCs whose semantics are related to abstract
elevation-related features (such as CA010 Contour line; CA020 Ridge line; CA025 Valley line;
CA026 Breakline …) With the exception of VG018, all of them have semantics that imply asingle elevation value. The Feature “Variable Displacement Line”, FACC VG018, is an
exception; it allows for a (relative) elevation value for each of the vertices of the “Variable
Displacement Line”.
	
  

	
  
Figure 5-13: Road Lineal Feature

In the case where features overlap one other, client-devices are required to use the Layer Priority
Number (LPN) attribute; this attribute is mandatory for geographically overlapping features.
The LPN attribute is a number in the 0-32767; low numeric values correspond to low priority.
The LPN attribute is used to control the order in which the features are applied to (e.g. renderedinto) the Elevation dataset. Features are applied in succession in low-to-high priority order into
the Terrain Elevation dataset.
5.6.1.6
MinElevation and MaxElevation Components
The MinElevation and MaxElevation components are part of the MinMaxElevation dataset
whose purpose is to provide the CDB with the necessary data and structure to achieve a highlevel of determinism in computating line-of-sight intersections with the terrain. The values ofeach component are with respect to WGS-84 reference ellipsoid. Since both the MinElevationand the MaxElevation values are provided by this Specification, any line-of-sight algorithm canrapidly assess an intersection status of the line-of-sight vector with the terrain. An overview of
the algorithm governing the line-of-sight computations can be found in Section A.13 ofAppendix A.

© 2015 Open Geospatial Consortium

188

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The MinElevation and MaxElevation values follow the “center grid data element” convention of
the CDB Specification.
The generation of the MinMaxElevation dataset is quite simple. In essence, each center gridelement in the MinElevation component represents the lowest altitude for the area represented bythat grid element. Likewise, each center grid element in the MaxElevation component represents
the highest altitude for the area represented by that grid element.
The MinMaxElevation dataset components are derived from the Primary Terrain Elevation andPrimary Alternate Terrain Elevation components. As a result, the MinMaxElevation dataset
cannot have more LODs than the Terrain Elevation component it is based on.
5.6.1.6.1 Level of Details
As can be seen in Figure 5-14: LOD Structure of Raster Datasets, the MinMaxElevation dataset
LODs share the same structure as the Elevation dataset.

Figure 5-14: LOD Structure of Raster Datasets

The generation of each successive LOD of the MinElevation and MaxElevation components is
illustrated in Figure 5-15: Generation of LODs for the MinMaxElevation Dataset (1D) and again
in more detail in Figure 5-16: Generation of LODs for the MinMaxElevation Dataset (2D).
The detailed algorithm for the generation of the MinMaxElevation dataset is as follows:© 2015 Open Geospatial Consortium

189

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1. For a geocell, determine the finest available LOD of the Primary Terrain
Elevation and Primary Alternate Terrain Elevation components, (call it LOD= n)
2. For each tile at LOD = n, the MinElevation (and MaxElevation) grid elements
are generated by taking the corresponding minimum (and maximum) of thesurrounding four “corner grid data elements” of LOD = n of the Primary
Terrain Elevation component (illustrated as red dots in Figure 5-15:
Generation of LODs for the MinMaxElevation Dataset (1D)). If the Primary
Alternate Terrain Elavation component exists at LOD = n, the value of the
Elevation must be taken into account because it provides a better estimate of
the minimum or maximum elevation of the grid element. In other words, each
MinElevation sample value represents the minimum for the area formed by
the surrounding four “corner grid data elements” of the Primary Terrain
Elevation plus the contribution of the Primary Alternate Terrain Elavation for
the grid element. Likewise, each MaxElevation sample represents the
maximum of the area formed by the surrounding four “corner grid data
elements” of the Primary Terrain Elevation plus the contribution of thePrimary Alternate Terrain Elevation for the grid element, illustrated as green
dots in Figure 5-15: Generation of LODs for the MinMaxElevation Dataset(1D).
Note that the generation of the rightmost (column) and topmost (row) ofvalues of a tile requires access to the adjacent tiles of the Primary Terrain
Elevation. Note however that the availability of Primary Elevation Data at
LOD = n within the entire CDB geocell cannot be guaranteed since the CDB
permits the generation of the Terrain Elevation Dataset at different resolutions
for each geographic area as illustrated in Figure 5-18: Availability of LODs
for Elevation and MinMaxElevation Datasets.
As a result, a slight adjustment to the above algorithm is needed in order tocater to the case where Elevation data is missing in adjacent tiles. There are
two cases to consider:i. If Elevation data in the adjacent tiles (above and/or to the right) is notavailable at n ≥ LOD ≥ −10 , then one or more of the 4 corner gridelements samples will be missing, hence will not be available to“participate” in the min() or max() function. In other words, the min() andmax() functions must be designed to cater to a variable number of inputs
depending on the availability of valid corner grid elements.
ii. If Elevation data in adjacent tile(s) is not available at LOD = n but isavailable at a coarser LOD (call it LOD = m, where m ≥ −10), then thecorner grid Elevation values of the LOD = m must be propagated to finer
LOD = n so that they can participate in the min() or max() functions. This
principle is illustrated in Figure 5-17: Generation of LODs for the
MinMaxElevation Dataset (1D) – Special Case.

© 2015 Open Geospatial Consortium

190

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3. Each grid element value of the next coarser level-of-detail (LOD = n-1) of the
MinElevation (and MaxElevation) dataset is generated by taking the minimum(and maximum) of four surrounding values of LOD = n of the MinElevation(and MaxElevation) dataset, illustrated as red dots in Figure 5-15: Generationof LODs for the MinMaxElevation Dataset (1D).
4. Repeat steps 2 and 3 for levels of detail LOD = n-2, n-3, until LOD −10 isreached.
5. Perform step 4, but this time with LOD = m, (m ≥ −10). Note that if Primary
Elevation data in adjacent tile(s) is not available at LOD = m but is available
at a coarser LOD (call it LOD = p, where p ≥ −10), then the corner grid
Elevation values of the LOD = p must be propagated to finer LOD = m so thatthey can participate in the min() or max() functions.
6. Repeat until all LODs have been processed. Note that the MaxElevation tiles
at LOD = −10 contain a single value which represents the highest elevation
point for the entire geocell. Likewise, each of the MaxElevation tiles at LOD= −9 contains four values which correspond to the highest elevation points ineach of the four quadrants of the corresponding geocell.

Figure 5-15: Generation of LODs for the MinMaxElevation Dataset (1D)

© 2015 Open Geospatial Consortium

191

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

FinestPrimaryElevation LOD'n'Grid Post
Min-Maxvalue @LOD'n'
Min-Maxvalue @LOD'n-1'
Min-Maxvalue @LOD'n-2'
Min-Maxvalue @LOD'n-3'

Figure 5-16: Generation of LODs for the MinMaxElevation Dataset (2D)

© 2015 Open Geospatial Consortium

192

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-17: Generation of LODs for the MinMaxElevation Dataset (1D) – Special Case

© 2015 Open Geospatial Consortium

193

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-18: Availability of LODs for Elevation and MinMaxElevation Datasets

The CDB Specification does not require that the entire LOD hierarchy be stored for the
MinMaxElevation dataset. In fact, it is possible to omit some of the finest levels-of-detail fromthe hierarchy. The CDB Specification recommends that the MinElevation and MaxElevationneed only be stored to LOD = n - 4 and coarser (where n is the finest available LOD of thePrimary Terrain Elevation component in a geocell). For example if Primary Terrain Elevation
data is available for LOD = 15, then the MinMaxElevation hierarchy need only be provided for
LOD = -10 to LOD = 11. Note, that LOD = -10 to LOD = 0 are always required subject to theavailability of Primary Terrain Elevation data (these guidelines are explained in more detail in
section 5.6.1.6.4, Default Write Value).
Note that the presence of the MinMaxElevation dataset has a negligible effect on the size of the
CDB. In fact, the dataset adds only 1% of additional storage over and above that required by thePrimary Terrain Elevation component. This is a small price to pay in order to provide the means
to significantly speed-up line-of-sight computations in applications requiring the utmost in
determinism and real-time.
5.6.1.6.2 Data TypeThe MinElevation and MaxElevation components are represented as floating-point or signed
integer values. Integer values for tiles at LOD larger than 0 are scaled according to the following
formula:𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼×2
© 2015 Open Geospatial Consortium

194

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Integer values can make use of TIFF’s 8-bit, 16-bit, or 32-bit representation.
5.6.1.6.3 Default Read Value
The Line-of-Sight algorithm is described in Section A.13 of Appendix A. Note that thealgorithm starts with the coarsest LOD of the MinMaxElevation dataset; the algorithm
recursively executes with progressively finer level-of-detail versions of the MinMaxElevation
dataset until the algorithm decides it no longer needs to access finer levels or until the algorithm
no longer finds finer levels of the MinMaxElevation dataset.
If none of the LODs of the MinMaxElevation dataset are provided, then simulator client-devices
should assume default MinElevation and MaxElevation values. The default values for thesedatasets can be found in \CDB\Metadata\Defaults.xml and can be provided to the client-devices
on demand. Handling of defaults falls under the following two cases:
1.

2.

3.

CASE I: In the case where the tile-LOD for the MinElevation and thePrimary Terrain Elevation components are both missing, the CDB
Specification recommends a default setting of
Default_MinElevation_CaseI = Default_Elevation-1. Similarly, where atile-LOD for MaxElevation and the Primary Terrain Elevation
components are both missing, the CDB Specification recommends a
default setting of Default_MaxElevation_CaseI = Default_Elevation-1.
CASE II:In the case where the tile-LOD for the MinElevation is
missing and the Primary Terrain Elevation is not missing, the CDB
Specification recommends a default setting of
Default_MinElevation_CaseII = as supplied in Defaults.xml. In the event
where this default value is not supplied, the CDB Specification
recommends that client-devices use a default value of -400 m(corresponding to the shore of the Dead Sea) for MinElevation.
Similarly, when MaxElevation is missing and the Primary Terrain
Elevation is not missing, the CDB Specification recommends a default
setting of Default_MaxElevation_CaseII = as supplied in Defaults.xml. In
the event this default value is not supplied, the CDB Specification
recommends that client-devices use a default value of 8846 m(corresponding to the peak of Mount Everest) for MaxElevation.

5.6.1.6.4 Default Write Value
The files associated with the MinElevation and MaxElevation components for the area coveredby a tile at a given LOD should not be created if the Primary Terrain Elevation data is notavailable.
The CDB Specification recommends that the MinElevation and MaxElevation components begenerated in accordance to the following guidelines:© 2015 Open Geospatial Consortium

195

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 20141.

If the finest LOD of the Primary Terrain Elevation component is available
at LOD ≥ 4, then all LODs ranging from -10 ≤ LOD ≤ (n – 4) of the
MinElevation and MaxElevation components should be generated (where
n is the finest available LOD of the Primary Terrain Elevation
component). The technique illustrated in Figure 5-15: Generation of
LODs for the MinMaxElevation Dataset (1D) should be used to populate
the LOD hierarchy. Gaps (i.e., missing levels) in the MIP-MAP hierarchy
are not permitted. It is not permitted to generate MinElevation and
MaxElevation components tiles that are partially populated with data.
2.
If the finest available LOD of the Primary Terrain Elevation component isavailable at LOD ≤ 3, then all LODs ranging from -10 ≤ LOD ≤ 0 of the
MinElevation and MaxElevation components should be generated. The
technique illustrated in Figure 5-15: Generation of LODs for the
MinMaxElevation Dataset (1D) should be used to populate the LOD
hierarchy. Gaps (i.e., missing levels) in the MIP-MAP hierarchy are notpermitted. It is not permitted to generate MinElevation and MaxElevation
components tiles that are partially populated with data.
In the event where parts of a MinElevation tile cannot be determined due to missing primaryelevation tiles, the CDB Specification recommends to use a default value of
Default_MinElevation_CaseIII, -400 m (corresponding to the shore of the Dead Sea) for
MinElevation. Similarly, in the event where parts of a MaxElevation tile cannot be determined
due to missing primary elevation tiles, the CDB Specification recommends to use a default valueof Default_MaxElevation_CaseIII, 8846 m (corresponding to the peak of Mount Everest) for
MaxElevation. Figure 5-19: Missing MinMaxElevation Datasets shows this case:© 2015 Open Geospatial Consortium

196

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-19: Missing MinMaxElevation Datasets

5.6.1.6.5 Supported Compression Algorithm
The CDB Specification supports the LZW compression algorithm for both the MinElevation and
MaxElevation components. Consider compressing the file if its content is not of type floatingpoint.
5.6.1.7
MaxCulture Component
The purpose of the MaxCulture component is to provide the necessary data and structure for an
optimal level of determinism in the computation of line-of-sight, path finding and obstacle
avoidance algorithms with the cultural features of the CDB. The values of this component are
based on the heights of culture features with respect to the corresponding LOD of the culture, be
it its bounding sphere, its bounding box or its modeled representation (if supplied). In this© 2015 Open Geospatial Consortium

197

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
context, the cultural features of the CDB are those represented by all vector tiled datasets
excluding those related to NAV.
Since MinElevation, MaxElevation and MaxCulture components are provided by thisSpecification, any line-of-sight algorithm can rapidly assess an intersection status of the line-ofsight vector with the terrain and/or with the cultural features of the CDB. Furthermore, since the
MaxCulture component follows the same conventions as the MinElevation and MaxElevation
components, it is easy for the LOS algorithm to combine the values to determine thehighest/lowest point (with or without cultural features) in a given geographic area. The culturevariant of the LOS algorithm is virtually identical to the terrain-only case. Before undertaking its
computations, the LOS algorithm must add the values of MaxCulture to the MaxElevation
values, once adjusted for LOD, and then perform the first LOS determination based on this. If anintersection is detected with MaxCulture, the final determination of intersection is conducted at
first with the bounding box of the cultural feature, then with the actual geometry of the culturalfeature (if available).
Note that the geographic areas where MaxCulture is zero can be used to quickly identify theabsence of any obstacles that can potentially affect the route of an entity.
The MaxCulture component also follows the “center grid data element” convention of the CDB
Specification. In the case where a cultural feature has no modeled representation, theMaxCulture component must be generated from the feature’s bounding volume that overlaps
each MaxCulture grid data element. If the feature has an associated modeled representation, thegrid data of the MaxCulture component must be generated from the model geometry.
5.6.1.7.1 Level of Details
The coarser LODs of the MaxCulture component are iteratively derived from the finest
generated LOD.
Since the MaxCulture component is intended to be used in conjunction with the MaxElevation
component, it is recommended that the number of LODs for the MaxCulture component be equal
or greater than the MaxElevation component.
5.6.1.7.2 Data TypeThe MaxCulture component is represented as floating-point or signed integer values. Integer
values for tiles at LOD larger than 0 are scaled according to the following formula:

𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼×2
Integer values can make use of TIFF’s 8-bit, 16-bit, or 32-bit representation.

© 2015 Open Geospatial Consortium

198

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.1.7.3 Default Read Value
If none of the LODs of the MaxCulture dataset are provided, then simulator client-devices
should assume default MaxCulture values. The default values for these datasets can be found in\CDB\Metadata\Defaults.xml and can be provided to the client-devices on demand. Handling ofdefaults fall under the following two cases:
1.

2.

CASE I: In the case where the MaxCulture component is missing, butthere is at least one vector dataset; client-devices should assume a default
MaxCulture value of Default_MaxCulture_CaseI. In the event this default
value is not supplied, the CDB Specification recommends that clientdevices use a value of 600 m (corresponding to the tip of World’s tallest
tower plus a margin of 47 m).
CASE II: In the case where the MaxCulture component is missing, butthere is not a single vector dataset; client-devices should assume a default
MaxCulture value of Default_MaxCulture_CaseII. In the event thisdefault value is not supplied, the CDB Specification recommends thatclient-devices use a value of 0 m.

5.6.1.7.4 Default Write Value
The files associated with the MaxCulture components for the area covered by a tile at a given
LOD should not be created if the Primary Terrain Elevation data is not available.
The CDB Specification strongly recommends that the MaxCulture dataset be generated inaccordance to the following guidelines:
1. If the finest LOD of any vector tiled datasets is available at LOD ≥ 6, then all
LODs ranging from -10 ≤ LOD ≤ (n – 6) of the MaxCulture dataset should be
generated (where n is the finest available LOD of any vector tiled datasets).
The technique illustrated in Figure 5-15: Generation of LODs for the
MinMaxElevation Dataset (1D) should be used to populate the LOD
hierarchy. Gaps (i.e., missing levels) in the MIP-MAP hierarchy are notpermitted. It is not permitted to generate MaxCulture dataset tiles that are
partially populated with data.
2. If the finest LOD of any vector tiled datasets is available at LOD ≤ 5, then all
LODs ranging from -10 ≤ LOD ≤ 0 of the MaxCulture dataset should be
generated (where n is the finest available LOD of any vector tiled datasets).
The technique illustrated in Figure 5-15: Generation of LODs for the
MinMaxElevation Dataset (1D) should be used to populate the LOD
hierarchy. Gaps (i.e., missing levels) in the MIP-MAP hierarchy are notpermitted. It is not permitted to generate MaxCulture dataset tiles that are
partially populated with data.

© 2015 Open Geospatial Consortium

199

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.1.7.5 Supported Compression Algorithm
The CDB Specification supports the LZW compression algorithm for the MaxCulturecomponent. Consider compressing the file if its content is not of type floating-point.
5.6.1.8
Subordinate Bathymetry Component
The Subordinate Bathymetry component consists of a grid of data values that represent the depthof water (be it of fresh water bodies or of the ocean) with respect to the corresponding data
values of the Terrain Elevation (be it the Primary Terrain Elevation or Primary Alternate Terrain
Elevation components). The Subordinate Bathymetry component follows the corner gridelement conventions.
The generation of Bathymetry values is best explained by the illustration found in Figure 5-20:
Primary Terrain Elevation and Subordinate Bathymetry Components. In areas where Primary
Terrain Elevation values correspond to the surface of a body of water, each Bathymetry value
represents the height difference between the corresponding Primary Terrain Elevation value (thereference) and the Earth’s Crust. In all other areas, the Bathymetry values represent the height
difference between the nearby water body and the Earth’s Crust. Appendix A.8 provides the
mandated behavior of client-devices when reading a LOD of a primary component andcombining it with another LOD of a subordinate component such as the Bathymetry.

Figure 5-20: Primary Terrain Elevation and Subordinate Bathymetry Components

Positive (depth) values of Bathymetry indicate that the corresponding grid element is submerged,i.e., the Earth’s Crust is below the elevation values in the Primary Terrain Elevation component.
Zero values correspond to the shoreline of the water body. Negative values of Bathymetry
indicate that the grid element is above water. The use of negative values of Bathymetry in thevicinity of shorelines provides a better means of interpolating Bathymetry along shorelines; suchinterpolation improve the precision of shoreline contours that can be derived from the isoline B =0.

© 2015 Open Geospatial Consortium

200

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In areas that are submerged, the Primary Terrain Elevation component represents the surface of
the water, not the elevation of the Earth’s Crust. The height of any point of the Earth’s Crustwith respect to the WGS-84 reference ellipsoid can be determined using Equation (eq. 5-3).

Where

Ee = E – max(0,B)
E = Terrain Elevation component(eq. 5-3)

B = Bathymetry component
Ee = Earth’s Crust Elevation

The resulting profile of the Earth’s Crust is shown in Figure 5-21: Derived Earth Elevation
Values.

Figure 5-21: Derived Earth Elevation Values

The Bathymetry component needs to be provided only in areas on the Earth’s surface wherewater is present. Below is another example of the relations between the Primary Elevation
component and the Subordinate Bathymetry component.

© 2015 Open Geospatial Consortium

201

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The linked image cannot be displayed. The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location.

Figure 5-22: Example of Primary Terrain Elevation and Bathymetry Components

5.6.1.8.1 Data TypeThe Subordinate Bathymetry component of the Elevation dataset is represented as a 1 or 2channel TIFF image. The first channel contains the Depth of the grid post; the optional second
channel indicates the Type of Mesh used to connect the four grid posts that are adjacent to thegrid element. The depth is represented by a floating-point or signed integer value expressed inmeters and relative to the Primary Terrain Elevation component. Integer values for tiles at LOD
larger than 0 are scaled according to the following formula:

Depth   = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼×2
Integer values can make use of TIFF’s 8-bit, 16-bit, or 32-bit representation.
The Mesh Type is stored as an unsigned 8-bit integer.
5.6.1.8.2 Default Read Value
Simulator client-devices should assume a Depth value of Default_Bathymetry if the data values
are not available. The default value can be found in \CDB\Metadata\Defaults.xml. In the casewhere the default value cannot be found, the CDB Specification states that client-devices use avalue of zero. The default Mesh Type is zero.
5.6.1.8.3 Default Write Value
The files associated with the Subordinate Bathymetry component for area covered by a tile at agiven LOD need not be created if the source data is not available. Tiles partially populated with© 2015 Open Geospatial Consortium

202

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
data are not permitted. If the tool generating the Subordinate Bathymetry component does notsupport the optional Mesh Type, the optional second channel of the file need not be created; inwhich case the TIFF file becomes a single channel image.
5.6.1.8.4 Supported Compression Algorithm
The CDB Specification supports the LZW compression algorithm for the Subordinate
Bathymetry component. Consider compressing the file if its content is not of type floating-point.
5.6.1.9
Subordinate Alternate Bathymetry Component
The Subordinate Alternate Bathymetry component is similar to the Primary Alternate Terrain
Elevation component; it provides a better delineation of the shoreline and bottom of water bodies
such as oceans, lakes, and rivers. To do this, the Subordinate Alternate Bathymetry component
encodes information that re-positions each depth samples anywhere within its assigned gridelement. In other words, the “phase” of each bathymetry depth sample can be specified along
the latitude and longitude axes. In effect, the Subordinate Alternate Bathymetry component
provides the means to locally increase the precision of the modeled representation of the floor ofwater bodies. Again, it is expected that the SE tools produce the Subordinate Alternate
Bathymetry component by considering constraint points, lineals and areals provided by themodeler.
The constituents of the Subordinate Alternate Bathymetry are the depth and mesh type at the
specified latitude and longitude offsets inside each grid element. These four constituents are
represented as 4 channels of a TIFF image.
5.6.1.9.1 Data TypeThe first channel of the TIFF image contains the Depth component and is represented as afloating-point or signed integer value. Integer values for tiles at LOD larger than 0 are scaled
according to the following formula:

𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷ℎ = 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆×2
Integer samples can make use of TIFF’s 8-bit, 16-bit, or 32-bit representation.
The second channel of the TIFF image contains the Mest Type and is stored as an unsigned 8-bit
integer.
The third channel of the TIFF image contains the Latitude Offset and is stored as an 8-bit
unsigned integer value ranging from 0 to 255. The value is scaled so that each grid element isfragmented in 256 equal parts in the latitude direction. Thus, the grid post cannot be positionedon the latitude of the next grid element directly north of the current grid element.

© 2015 Open Geospatial Consortium203

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The fourth channel of the TIFF image contains the Longitude Offset and is stored as an 8-bit
unsigned integer value ranging from 0 to 255. The value is scaled so that each grid element isfragmented in 256 equal parts in the longitude direction. Thus, the grid post cannot be positionedon the longitude of the next grid element directly east of the current grid element.
5.6.1.9.2 Default Read Value
Simulator client-devices should assume a Depth of zero (as well as a Latitude and Longitude
Offsets of zero and a Mesh Type of zero) when the Subordinate Alternate Bathymetrycomponent is not available.
5.6.1.9.3 Default Write Value
The files associated with the Subordinate Alternate Bathymetry component for an area coveredby a tile at a given LOD need not be created if the source data is not available. Tiles partially
populated with data are not permitted.
5.6.1.9.4 Supported Compression Algorithm
The CDB Specification supports the LZW compression algorithm for the Subordinate Alternate
Bathymetry component. Consider compressing the file if its content is not of type floating-point.
5.6.1.10 Subordinate Tide Component
The Tide component represents the height variation of water (be it of fresh water bodies of water
or of the ocean) with respect to the Primary Elevation component. The Tide component
implicitly follows the corner grid element conventions. Each value in the Tide component must
be matched to the available LOD elevation values of the Primary Elevation component.
The Tide component needs only to be provided in areas on the Earth’s surface that are in thevicinity of water bodies. The information held in the Terrain Elevation and Tide components
permits a means for client-devices to accurately determine the shoreline profile as a function of
the tide level. When provided, the Tide component permits client devices to compute theelevation (with respect to the WGS-84 mean sea-level reference) in areas permanently or
potentially submerged. The Tide component need not be limited to oceans; it can also be used to
specify the variation of height of any body of water (rivers, lakes, gulfs, etc.).
The Tide component also permits simulation of tides that varies with location. In order todetermine the shoreline profile at a given location, the simulator client-devices must first
determine the height of (say) the ocean in the immediate vicinity of that location. The
sophistication of this calculation can vary greatly with simulation fidelity. A discussion of
possible alternatives regarding the fidelity of simulation Tide simulation models can be found in
Section A.8 of Appendix A.
With the CDB Tide component, simulator client-devices can readily determine the height of theocean (or any water surface whose height varies) at any point and as a result can derive the© 2015 Open Geospatial Consortium

204

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
geometry of the shoreline61. While a stored vector shoreline representation might provide a morestraightforward means of representing the shoreline geometry for some client-devices, that
representation would not lend itself to determining the variation of the shoreline geometry withvarying tides. Furthermore, a vectorized representation of the shoreline geometry would
essentially be a single-level of detail of the shoreline geometry; as a result, it would need to begenerated at a resolution designed to match the highest LOD Terrain Elevation data. Coarser
shoreline LODs would essentially be samples of the shoreline vector geometry at progressively
greater spatial intervals.
The CDB Tide component represents the height variation of water surfaces anywhere on the
Earth’s surface. The variation need not be limited to the effect of tides62. The Tide component
represents the height variation of the water surface above and below the mean water surface
level.

Figure 5-23: Terrain Elevation, Bathymetry and Tide Components

61

While a stored vector shoreline representation might have provided a more straightforward means ofrepresenting the shoreline geometry for some client-devices, that representation was rejected because it would notlend itself to determining the variation of the shoreline geometry with varying tides.
62

For instance, it could represent the nominal seasonal variations of water level of lakes and rivers.

© 2015 Open Geospatial Consortium

205

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-24: Derived Earth Elevation, Water Elevation and Surface Elevation Values

From the above components, simulation client devices can compute a) the elevation of the water
Ew, b) the elevation of the earth’s surface Ee (be it submerged or potentially submerged), and c)
the surface elevation of the earth / water Es. These computations can be performed in all areas
where the Bathymetry and Tide components are available (e.g., areas submerged or potentiallysubmerged). The values for Ew, Ee, and Es are referenced to the WGS-84 mean sea-levelreference level. Equation (eq. 5-4) though (eq. 5-6) can be used to compute Ew, Ee and Es:

Ew = E + min(0,B) + T
Ee = E – max(0,B)
Es = max(Ee, Ew)
Where

E=

(eq. 5-4)(eq. 5-5)(eq. 5-6)

Terrain Elevation component
B=

Bathymetry component

T = Tide component
Ew = Derived water elevation value
Ee = Derived earth elevation value
Es = Derived surface elevation
Client devices interested in computing the height of the ownship over terrain or water can use
equation (eq. 5-7).

HAT = O - Es

© 2015 Open Geospatial Consortium(eq. 5-7)

206

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Where

O=

Ownship Altitude

Finally, client devices interested in determining the depth of water D, can use equation (eq. 5-8).

NOTE:

D = min(0, Ew - Ee)
A computed value of D of 0 means the point is above water.

(eq. 5-8)

5.6.1.10.1 Data Type
Tide components are represented as floating-point or signed integer values. Integer values fortiles at LOD larger than 0 are scaled according to the following formula:

Tide   = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼×2
Integer values can make use of TIFF’s 8-bit, 16-bit, or 32-bit representation.
5.6.1.10.2 Default Read Value
Simulator client-devices should assume default Tide values if the data values are not available(files associated with the Tide component for the area covered by a tile, at a given LOD orcoarser, are either missing or cannot be accessed). The default value can be provided to theclient-devices on demand. The CDB Specification recommends a default tide value of 2.5m
(published average magnitude of tides worldwide).
Simulator client-devices should assume a default Tide value of Default_Tide if the data values
are not available (files associated with the Tide component for the area covered by a tile, at agiven LOD or coarser, are either missing or cannot be accessed). The default value can be foundin \CDB\Metadata\Defaults.xml and can be provided to the client-devices on demand. In thecase where the default value cannot be found, the CDB Specification recommends that clientdevices use a default tide value of 2.5m (average magnitude of tides worldwide).
5.6.1.10.3 Default Write Value
The files associated with the Tide component for area covered by a tile at a given LOD need not
be created if the source data is not available. Tiles partially populated with data are notpermitted.

© 2015 Open Geospatial Consortium

207

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.1.10.4 Supported Compression Algorithm
The CDB Specification supports the LZW compression algorithm for the Tide component.
Consider compressing the file if its content is not of type floating-point.
5.6.2
Tiled Imagery Dataset
In a CDB, the terrain imagery is depicted on a grid at regular geographic intervals. Each of thecomponents of the Imagery Dataset corresponds to the raster imagery draped over the terrainskin derived from the Primary Terrain Elevation Dataset. The Raster Imagery Dataset implicitly
follows the center grid element conventions.
The CDB Specification provides for a set of alternate terrain imagery representations
corresponding to the visible spectrum terrain imagery at different periods of the year. Together,
these representations are stored in a set of Visible Spectrum Terrain Imagery (VSTI)
components. Each of these representations can be either monochrome or color.
In addition, the CDB Specification provides for a subordinate light map representation that canbe applied to the selected VSTI component for a night-time representation of lighting patterns
created by the projection of light-sources onto the terrain surface. The light-map can be either
monochrome or color.
5.6.2.1
Raster-Based Imagery File Storage Extension Naming
As briefly mentioned earlier in Section 1.4.10, the CDB Specification introduces the notion of
support for JPEG 2000 raster-based storage format for raster imagery files. Since the CDB
Specification enforces a unique filename for each dataset file, a different file extension isrequired for such a dataset file format to distinguish it from TIFF for other raster based datasets,
thus any raster imagery dataset shall be stored under the “.jp2” file extension.
5.6.2.1.1 JPEG 2000 Metadata
In addition to the compressed image data, the JPEG 2000 files may contain metadata to holdadditional data boxes. They are the Intellectual Property box, XML box, URL box and UUID
box. Among them, the XML box is perfectly suited to store formatted metadata concerning thesource of this data, or the security attributes associated with the file usage. Below is the XML
format description of such metadata to be supported as part of this CDB Specification. It is to be
noted that the existence of this XML metadata box does not contain any information necessary
for decoding the image portion, and the correct interpretation of the XML data will not change
the visual appearance of the image. This metadata is divided in two distinct elements, namely
ORIGIN and SECURITY.

© 2015 Open Geospatial Consortium

208

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.2.1.1.1 Origin of data
XML Tag Namedatetime

FormatDescription
STRING File Date & Time: This field shallcontain the file’s origination in the format
CCYYMMDDhhmmss, where CC is thefirst two digits of the year (00-99), YY is
the last two digits of the year (00-99),
MM is the month (01-012), DD is the day(01-31), hh is the hour (00-23), mm is theminute (00-59), and ss is the second (0059). UTC is assumed to be the time zone
designator to express the time of day.
originatingstationid
STRING Originating Station ID: This field shallcontain the identification code or name ofthe originating organization, system,
station, or product. It shall not be filledwith spaces.
originatorname
STRING Originator’s Name: This field shallcontain a valid name for the operator who
originated the file. If the field is all
spaces, it shall represent that no operator
is assigned responsibility for origination.
originatorphone
STRING Originator’s Phone Number. This fieldshall contain valid phone number for theoperator who originated the file. If the
field is all spaces, it shall represent thatno phone number is available for theoperator assigned responsibility fororigination.
originatororganization STRING Originator’s Organization. This fieldshall contain a valid name of the
supporting organization.
originatoraddress
STRING Originator’s Address. This field shallcontain a valid address of the supportingorganization.
originatoremail
STRING Originator’s Electronic Mail Address.
This field shall contain a valid email
address of the supporting organization.
originatorwebsite
STRING Originator’s Web Site Address. This
field shall contain a valid web site addressof the supporting organization.
originatorremark
STRING Originator’s Remark Text. This fieldshall contain description text for any
special remarks concerning the file.

© 2015 Open Geospatial Consortium

ValuesDefault is 14 spaces
Date Format:
CCYYMMDDhhmmss

This 10-character fieldmust NOT be blank

Default is 24 spaces

Default is 18 spaces

Default is 80 spaces
Default is 256 spaces
Default is 100 spaces
Default is 100 spaces
Default is 100 spaces

209

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.2.1.1.2 Security
Attribute Nameclassificationlevel

FormatDescription
BYTE
File Security Classification:
This field shall contain a 1character valid value
representing the classificationlevel of the entire file.

systemSTRING File Security Classification
System: This field shallcontain valid values indicating
the national or multinational
security system used toclassify the file. If this field is
all blank spaces, it shall imply
that no security classification
system applies to the file.
STRING File Codewords: This fieldshall contain a valid indicatorof the security compartments
associated with the file.
STRING File Control and Handling.
This field shall contain valid
additional security control
and/or handling instructions(caveats) associated with thefile. Values include digraphs
found in DIAM 65-19 and/or
MIL_STD_2500B-Table A-4.
The digraph may indicate
single or multiple caveats.
The selection of a relevant
caveat(s) is application
specific. If this field is all
spaces, it shall imply that no
additional control andhandling instructions apply tothe file.
STRING File Releasing Instructions.
This field shall contain a valid
list of country and/or
multilateral entity codes towhich countries and/or
multilateral entities the file isauthorized for release. If thisfield is all spaces, it shall
imply that no file release
instructions apply.

codewords

controlhandlingreleaseinstructions© 2015 Open Geospatial Consortium

ValuesValid values are:T (=Top Secret),
S (=Secret),
C (=Confidential),
R (=Restricted),
U (=Unclassified).
Default is 2 spaces
Country Codes per FIPS 10-4
shall be used to indicate
national security systems;
codes found in DIAM 65-19
shall be used to indicate
multinational security systems.
Default is 11 spaces

Default is 2 spaces
Values include one or more of
the tri/digraphs found in
DIAM 65-19 and/or
MIL_STD_2500B-Table A-4.
Multiple entries shall beseparated by a single space

Default is 20 spaces
Valid items in the list are one
or more country codes asfound in FIPS 10-4 and/or
codes identifying multilateralentities as found in DIAM 6519.

210

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute Namedeclassificationtype

FormatDescription
STRING File Declassification Type.
This field shall contain a valid
indicator of the type of
security declassification or
downgrading instructions
which apply to the file.

ValuesDefault is 2 spaces

Valid values are:
DD (=declassify on a specificdate),DE (=declassify uponoccurrence of an event),
If this field is all spaces, it
GD (=downgrade to ashall imply that no file security specified level on a specificdeclassification ordate),
downgrading instructions
GE (=downgrade to a specified
apply.
level upon occurrence of anevent),O ( =OADR),
X (= exempt from automatic
declassification).
declassificationdate
STRING File Declassification Date.
Default is 8 spaces
This field shall indicate thedate on which a file is to be
Date Format:
declassified if the value in File CCYYMMDD
Declassification Type is DD.
If this field is all spaces, it
shall imply that no filedeclassification date applies.
declassificationexemption STRING File Declassification
Default is 4 spaces
Exemption. This field shallindicate the reason the file is
Valid values are X1 throughexempt from automatic
X8 and X251 through X259.
declassification if the value in X1 through X8 correspond toFile Declassification Type isthe declassification
X.
exemptions found in DOD
5200.1-R, paragraphs 4202b(1) through (8) for
If this field is all spaces, itmaterial exempt from the 10shall imply that a file
year rule. X251 through X259
declassification exemption
correspond to thedoes not apply.
declassification exemptions
found in DOD 5200.1-R,
paragraphs 4-301a(1) through(9) for permanently valuable
material exempt from the 25year declassification system.
filedowngrade
BYTE
File Downgrade. This field
Default is 1 spaceshall indicate the classificationlevel to which a file is to be
Valid values are:downgraded if the values in
S (=Secret),File Declassification Type are C (=Confidential),
GD or GE. If this field is all
R (=Restricted).
spaces, it shall imply that filesecurity downgrading does not
apply.

© 2015 Open Geospatial Consortium

211

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute Name
filedowngradedate

FormatDescription
STRING File Downgrade Date. This
field shall indicate the date on
which a file is to be
downgraded if the value in
File Declassification Type is
GD. If this field is all spaces,
it shall imply that a filesecurity downgrading datedoes not apply.
classificationtext
STRING File Classification Text. This
field shall be used to provide
additional information aboutfile classification to include
identification ofdeclassification or
downgrading event if thevalues in File Declassification
Type are DE or GE. It may
also be used to identify
multiple classification sources
and/or any other special
handling rules. If this field is
all spaces, it shall imply that
additional information aboutfile classification does not
apply.
classificationauthoritytype BYTE
File Classification Authority
Type. This field shall indicate
the type of authority used toclassify the file. If this field is
all spaces, it shall imply thatfile classification authority
type does not apply.

© 2015 Open Geospatial Consortium

ValuesDefault is 8 spaces
Date Format:
CCYYMMDD

Default is 43 spaces
Values are user defined freetext.

Default is 1 single space
Valid values are:
O (= original classification
authority),
D (= derivative from a single
source),M ( =derivative from multiple
sources).

212

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute Nameclassificationauthority

classificationreason

classificationsourcedate

FormatDescription
STRING File Classification Authority:
This field shall identify theclassification authority for the
file dependent upon the value
in File Classification Authority
Type. If this field is all
spaces, it shall imply that no
file classification authority
applies.

BYTE

File Classification Reason:
This field shall contain values
indicating the reason forclassifying the file. If thisfield is all spaces, it shall
imply that no file classification
reason applies.

STRING File Security Source Date:
This field shall indicate thedate of the source used toderive the classification of the
file. In the case of multiple
sources, the date of the mostrecent source shall be used. If
this field is all spaces, it shall
imply that a file security
source date does not apply.

© 2015 Open Geospatial Consortium

ValuesDefault is 40 spaces
Values are user defined freetext which should contain thefollowing information:- original classification
authority name and position or
personal identifier if the value
in File Classification Authority
Type is O;- title of the document or
security classification guideused to classify the file if thevalue in File Classification
Authority Type is D; andDerive-Multiple if the fileclassification was derived
from multiple sources. In thelatter case, the file originator
will maintain a record of thesources used in accordancewith existing security
directives. One of the multiple
sources may also be identified
in File Classification Text if
desired.
Default is 1 single space
Valid values are A through G.
These correspond to thereasons for originalclassification per E.O. 12958,
Section 1.5.(a) through (g).
Default is 8 spaces
Date Format:
CCYYMMDD

213

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute Namecontrolnumber

filecopynumber

numberofcopies

FormatDescription
STRING File Security Control Number:This field shall contain a valid
security control number
associated with the file. The
format of the security control
number shall be in accordancewith the regulations governing
the appropriate security
channel(s). If this field is all
spaces, it shall imply that no
file security control number
applies.
INT
File Copy Number: This fieldshall contain the copy numberof the file. If this field is all
zeros, it shall imply that there
is no tracking of file’s numberof copies.
INT
File Number of Copies: This
field shall contain the total
number of copies of the file. If
this field is all zeros, it shall
imply that there is no trackingof numbered file copies.

© 2015 Open Geospatial Consortium

ValuesDefault is 15 spaces

Default is 00000
Number can range between:
00000 to 99999
Default is 00000
Number can range between:
00000 to 99999

214

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.2.1.1.3 JPEG 2000 XML Example
Table 5-14: XML Tags for the JPEG 2000 Metadata<?xml version="1.0" encoding="UTF-8"?><JP2METADATA name="JPEG2000XML"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="JP2MetaData.xsd"><ORIGIN><datetime></datetime><originatingstationid></originatingstationid><originatorname></originatorname><originatorphone></originatorphone><originatororganization> </originatororganization><originatoraddress></originatoraddress><originatoremail></originatoremail><originatorwebsite></originatorwebsite><originatorremark></originatorremark></ORIGIN><SECURITY><classificationlevel></classificationlevel><system></system><codewords></codewords><controlhandling></controlhandling><releaseinstructions></releaseinstructions><declassificationtype></declassificationtype><declassificationdate></declassificationdate><declassificationexemption></declassificationexemption><filedowngrade></filedowngrade><filedowngradedate></filedowngradedate><classificationtext></classificationtext><classificationauthoritytype></classificationauthoritytype><classificationauthority></classificationauthority><classificationreason></classificationreason><securitysourcedate></securitysourcedate><controlnumber></controlnumber><filecopynumber></filecopynumber><numberofcopies></numberofcopies></SECURITY></JP2METADATA>

5.6.2.2
List of all Imagery Dataset Components
The Imagery Dataset is comprised of several components listed here and detailed in thesubsequent sections.

© 2015 Open Geospatial Consortium

215

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 5-15: Imagery Dataset Components
CS1

CS2

File
Extension

Dataset 004, Imagery
001
001

*.jp2

002

001..004

*.jp2

003

001..012

*.jp2

004

001..004

*.jp2

005

001

*.jp2

Component
Name

Component
Description

Yearly VSTI
Representation

Corresponds to the terrain imagery draped(orthographically) over the terrain skin derived
from the Primary Terrain Elevation Dataset.
This is the preferred Dataset Component for
year-round representative terrain imagery. It
may be single-channel monochrome or 3channel color image. This Dataset Component
follows the center grid conventions. Can beused interchangeably with all other Alternate
VSTI representations.
Seasonal VSTI Deprecated – Replaced with Quarterly VSTI
Representations Representations below
Monthly VSTI Monthly equivalent of Yearly VSTI
Representations representation, i.e., this is the preferred Dataset
Component for month-based representative
terrain imagery. Can be used interchangeably
with all other Alternate VSTI representations.
Quarterly VSTI Equivalent to Yearly VSTI representation but
Representations for the selected quarter of the year. Can be usedinterchangeably with all other Alternate VSTI
representations.
Subordinate
Corresponds to the terrain light maps draped
VSTLM(orthographically) over the terrain skin derived
from the Primary Terrain Elevation Dataset. It
may be single-channel monochrome or 3channel color image. This Dataset Component
follows the center grid conventions.

5.6.2.3
Visible Spectrum Terrain Imagery (VSTI) Components
The VSTI component provides the visible spectrum imagery that is geo-graphically draped (andusually ortho-rectified) over the geometric representation of the terrain skin that is stored in thePrimary Terrain Elevation Dataset. The CDB Specification provides the means to (optionally)
store alternate representations of the terrain imagery in order to provide the simulation clientdevices terrain representations that best represent the time-of-year being simulated. There arethree alternate approaches to the generation and storage of the VSTI Imagery Dataset and they
are organized as follows:
1. Yearly: The first approach requires a single, year-round representation of theterrain imagery.

© 2015 Open Geospatial Consortium

216

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
2. Quarterly: The second approach requires four variants of the terrain
imagery, one per calendar-year quarter63.
3. Monthly: The third approach requires monthly-variants of the terrain
imagery, one per month.
The VSTI Imagery Datasets can be provided and stored in any combination, be it yearly,
quarterly and/or monthly.
The VSTI dataset implicitly follows the center grid element conventions.

Figure 5-25: Projection of Terrain Imagery Dataset onto Terrain Elevation Dataset

The CDB grid representation of this raster imagery assumes a gamma of 1.0 (see Appendix G)
and a color space model in conformance with Windows sRGB or YUV Color Space Profile.
sRGB is the default color space in Windows, based on the IEC 61966-2-1 Standard. CDB terrain
imagery can optionally be compressed into JPEG 2000 with varying degrees of quantization(quality) levels. However, if using a quantization level different than 0, lossy image results inpossible image degradation and artifact addition.
5.6.2.3.1 Data TypeThe VSTI component is represented as single-channel gray-scale images, or as triple-channel
non-paletted color images in JPEG 2000 format. The use of transparency on terrain imagery is
not allowed.
63

Each quarter corresponds to specific months of the year. This concept of calendar-year quarters is distinct fromthe concept of seasons whereby the later depends on whether the user is in the northern or the southern hemisphereof Earth.

© 2015 Open Geospatial Consortium

217

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.2.3.2 Default Read Value
Simulator client-devices should default the VSTI values if the data values are not available (files
associated with the VSTI dataset for the area covered by a tile, at a given LOD or coarser, areeither missing or cannot be accessed). The default value can be found in\CDB\Metadata\Defaults.xml and can be provided to the client-devices on demand. In the casewhere the default value cannot be found, the CDB Specification recommends that client-devices
use a default value of half-intensity (0.5). Note that the default values are expressed as floatingpoint numbers ranging from 0.0 to 1.0. This ensures that the default is interpreted in a consistentmanner independently of the data representation in the *.jp2 file.
Simulation client-devices are required to select the VSTI texture that best represents thesimulation date. The retrieval of VSTI textures by the client-devices must follow the following
conventions:
1. The simulation date is converted to a month of the year

2. If the monthly VSTI representation for that month number is absent, then theclient-device is required to determine which quarter of the year it is and search
for the quarterly representation of the VSTI
3. If a quarterly representation is absent, then the client-device is required tosearch for a yearly representation of the VSTI
4. if the yearly representation is absent, then the client-device is required todefault to the Yearly default values found in \CDB\Metadata\Defaults.xml as
follows:
a. Default_VSTI_Y_Monob. Default_VSTI_Y_Red
c. Default_VSTI_Y_Greend. Default_VSTI_Y_Blue
The above conventions are summarized in Table 5-16.

Table 5-16: VSTI Default Read Values
Monthly

Quarterly

January001

February

002

March

003

April

004

May

005

Yearly001
001

Default

Default_VSTI_Y_Mono
Default_VSTI_Y_Red
Default_VSTI_Y_Green
Default_VSTI_Y_Blue002© 2015 Open Geospatial Consortium

218

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Monthly

Quarterly

June

006

July

007

August008

September

009

October

010

November

011

December

012

YearlyDefault

003

004

5.6.2.3.3 Default Gamma Correction
The default gamma correction is defined by Default_Imagery_Gamma found in the Defaults.xml
metadata file. If Default_Imagery_Gamma is not found in Defaults.xml, or if Defaults.xml is notfound in the metadata directory, assume a default gamma correction of 1.0.
5.6.2.3.4 Default Write Value
The files associated with the VSTI component for area covered by a tile at a given LOD need not
be created if the source data is not available. Tiles partially populated with data are notpermitted.
5.6.2.3.5 Supported Compression Algorithm
The CDB Specification supports compressed form using the JPEG 2000 format.
5.6.2.4
Visible Spectrum Terrain Light Map (VSTLM) Component
The VSTLM component provides the visible spectrum terrain light maps that areorthographically draped over the terrain skin (e.g., Primary Terrain Elevation Dataset) and onto
T2DModels. In addition, client-devices can also use the VSTLM component to orthographicallyproject the light map onto GTModels, GSModels and statically-positioned MModels.
Light maps fall under the category of subordinate textures. The light maps are used in low
illumination conditions (dusk, dawn, night) to represent the combined illumination effect of manmade light sources (primarily lamp-posts) on the terrain. The technique provides a convenientmeans to produce interesting and entirely predictable lighting effects without resorting tocomputationally intensive local light sources.
The light map adds to the lighting levels provided by the simulated ambient light level; thecombined ambient lighting and the light map together modulate the underlying VSTI. Light
maps can be created in a number of ways, either manually with a tool such as Photoshop, from© 2015 Open Geospatial Consortium

219

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
night-time imagery or finally from an off-line rendering process that simulates the illumination
effect of the urban lighting sources onto the terrain.
5.6.2.4.1 Data TypeThe VSTLM component is represented as single-channel gray-scale images, or as triple-channel
color images. The data is stored in JPEG 2000 format. Note that in the case of a monochrome
VSTLM, the implied chrominance of the VSTLM is white.
5.6.2.4.2 Default Read Value
Simulator client-devices should default the VSTLM values if the data values are not available(files associated with the VSTLM dataset for the area covered by a tile, at a given LOD orcoarser, are either missing or cannot be accessed). The default value can be found in\CDB\Metadata\Defaults.xml and can be provided to the client-devices on demand. In the casewhere the default value cannot be found, the CDB Specification recommends that client-devices
use a default value of zero-intensity (0.0). Note that the default values are expressed as floatingpoint numbers ranging from 0.0 to 1.0. This ensures that the default is interpreted in a consistentmanner independently of its representation in the *.jp2 file. The default values are:
Default_VSTLM_Mono
Default_VSTLM_Red
Default_VSTLM_Green
Default_VSTLM_Blue
5.6.2.4.3 Default Gamma Correction
The default gamma correction is defined by Default_Imagery_Gamma found in the Defaults.xml
metadata file. If Default_Imagery_Gamma is not found in Defaults.xml, or if Defaults.xml is notfound in the metadata directory, assume a default gamma correction of 1.0.
5.6.2.4.4 Default Write Value
The files associated with the VSTLM component for area covered by a tile at a given LOD neednot be created if the source data is not available. Tiles partially populated with data are notpermitted.
5.6.2.4.5 Supported Compression Algorithm
The CDB Specification supports compressed form using the JPEG 2000 format.
5.6.3
Tiled Raster Material Dataset
Historically, Digital Feature Analysis (DFAD) and VPF (Vector Product Format) data have beenused to provide the terrain and cultural content information used by the real-time sensors, thecomputer generated forces and the visual systems. The vectorized outlines of areas tagged withattribution data had a cartoon-like appearance because they did not capture the richly varying
mixture of materials. Each geometric shape would be represented as a single material type© 2015 Open Geospatial Consortium

220

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
resulting in simplistic sensor scenes. Sometimes, a locally applied texture pattern would beapplied to add some realism to the single material type. While it is still possible to build a CDB
in this manner, the preferred approach involves the use of the Raster Material Dataset described
here. The Raster Material Dataset can be readily derived from the (image) classification ofmono, color or multi-spectral imagery. This Dataset is a material-coded image with mixturingdata. It is independent of wavelength (visible, infrared, etc.) and is designed to support
geospecific, multi-spectral scene simulation across any computing platform. The Raster Material
Dataset is typically generated from material classification and mixturing analysis (see Figure
5-26: Image Classification Example). It can be developed directly from geospecific imagery,(e.g., SPOT, Landsat) and have a one-to-one correspondence with the image data. The Raster
Material Dataset results in a smoothly varying simulation database free of hard edges
characteristically found in vectorized DFAD outlines.

Figure 5-26: Image Classification Example

The Raster Material Dataset provides the means to store the types of materials and the area
coverage of each material within each pixel of the dataset. In all other aspects, it follows
conventions similar to the VSTI dataset.
A Raster Material Dataset consists of a set or stack of “n” Material Layers. This stacking
arrangement permits the modeler to assign up to “n” materials to the area covered by each pixelof the Raster Material Dataset. The Raster Material Dataset also consists of a stack of “n-1”mixture layers; the mixture layers define the proportions of materials at each pixel. The CDB
Specification makes provision for up to 255 materials, (i.e., any pixel within the Raster Material
Dataset can be assigned up to 255 materials).

© 2015 Open Geospatial Consortium

221

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-27: Example of a Raster Material Dataset

Figure 5-23: Terrain Elevation, Bathymetry and Tide Components, provides an example of a
Raster Material Dataset consisting of 3 material layers and two associated mixture layers. The
first Material Layer (i.e., layer 1) consists of a regular grid of pixels; each pixel contains a codethat represents the (composite) material with largest area coverage. Likewise, the second
Material Layer consists of a grid of pixels whose code represents the (composite) material withsecond-highest area coverage. Additional layers are added until the area corresponding to the
combined area of all (composite) materials at each pixel sums to 100%. Note that in layer 2, thematerial layer value of some pixels can be ignored (shown as “-“ in the illustration) because layer
1 had a material mixture value of 100%. Similarly, the material layer value of some pixels inlayer 3 can also be ignored because the mixture layers 1 and 2 add to 100%. In these cases, the
CDB Specification recommends that the layer value be assigned a Default_Material_Layer value
of 0.

NOTE:

The numeric value for Default_Material_Layer is zero (“0”) and is reserved by the
CDB Specification.

Mixture Layers represent the percentage area coverage of each material within each pixel of each
mixture. Since all layers must add to 100%, it is possible to represent “n” Material Layers with aset of “n-1” Mixture Layers. The last layer is implicit, and it is set to (100% - Sum of areas fromprevious layers). In the case where there is a single Material Layer, there is no need to store the(implicit) Mixture Layer. When there are two or more Material Layers, the Mixture Layer(s)must be generated.

© 2015 Open Geospatial Consortium

222

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.3.1
List of all Raster Material Dataset Components
The Raster Material Dataset is comprised of several components listed here and detailed in thesubsequent sections.

Table 5-17: Raster Material Dataset Components
Component
File
Component
Description
Extension
Name
Dataset 005, RMTexture001
001..255 *.tif
Composite
Each texel is an index into the Composite Material
Material
Table (dataset 006). CS2 is the layer number.
Index
Corresponds to a 2D grid of composite materialindices draped (orthographically) over the terrainskin derived from the Primary Terrain Elevation
Dataset.
002
001..254 *.tif
Composite
Each texel indicates the proportion (between 0.0
Materialand 1.0) of the composite material found in the
Mixturecorresponding material layer. CS2 is the layer
number. Corresponds to a 2D grid draped(orthographically) over the terrain skin derived
from the Primary Terrain Elevation Dataset. This
Dataset component follows the center gridconventions.
Dataset 006, RMDescriptor
001
001
*.xml
Composite
The Composite Material Table is referenced by theMaterial
Composite Material Index component and contains
Table
the definitions of the composite materials of a TileLOD.
CS1

CS2

5.6.3.2
Composite Material Index Component
As mentioned earlier, the CDB Specification allows pixels of the Raster Material Dataset toconsist of several (up to 255) composite materials. To accomplish this, it uses a layering conceptthat permits the assignment of several composite materials for each pixel in the Material Dataset.
As a result, the chosen representation for the Raster Material Dataset consists of a set or stacks of“n” Material Layers, where “n” is the maximum number of composite materials encountered inany pixel of the CDB tile at the specified LOD.
The code assigned to each pixel of each Material Layer is the index of a Composite Material
found in the Terrain Composite Material Table (TCMT) defined in 5.6.3.4.
Each pixel of the first Material Layer (e.g., layer “1”) consists of a code that represents thecomposite material with largest area coverage for that pixel. Likewise, each pixel of the second
Material Layer consists of a code that represents the composite material with second-highest area
coverage for that pixel. Additional layers are added until the area corresponding to the combined
area of all composite materials at each pixel sums to 100%.

© 2015 Open Geospatial Consortium

223

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.3.2.1 Data TypeThe Material Layer components are each represented as single-channel, material coded one byte
unsigned integer value images stored in TIFF.
5.6.3.2.2 Default Read Value
If none of the Material Layer components are available (files associated with the Material Layer
dataset for the area covered by a tile, at a given LOD or coarser, are either missing or cannot be
accessed), simulator client-devices should default to a single Material Layer component whose
content defaults to a single default Composite Material. The default Composite Material can befound in \CDB\Metadata\Defaults.xml and can be provided to the client-devices on demand.
The default value is:Z
Default_Material_Layer (0)In the case where the default value cannot be found, the CDB Specification recommends thatclient-devices default to single substrate composite material whose base material is:Z

Default_Base_Material (BM_LAND-MOOR)

5.6.3.2.3 Default Write Value
The files associated with the Material Layer components for the area covered by a tile at a given
LOD need not be created if the source data is not available. Tiles partially populated with data
are not permitted.
5.6.3.2.4 Supported Compression Algorithm
The LZW compression algorithm is applicable to Composite Material Index component in the
TIFF file format.
5.6.3.3
Composite Material Mixture Component
A Mixture Layer accompanies each Material Layer; its dimensions are identical to those of theMaterial Layer. The pixel values of the Mixture Layer “n” represent the area coverage ofMaterial Layer “n”. Since all layers must add to 100%, it is possible to represent “n” Material
Layers with a set of “n-1” Mixture Layers. As a result, the last layer is implicit, and it is set to(100% - Sum of areas from previous layers). In the case where there is a single Material Layer,
there is no need to store the (implicit) Mixture Layer. When there are two or more Material
Layers, the Mixture Layer(s) must be generated.
5.6.3.3.1 Data TypeThe Material Mixture components are each stored in a single-channel TIFF file. All values range
from 0.0 (0%) to 1.0 (100%). Integral types represent scaled integers to fit the range 0.0 to 1.0;
floating-point values are limited to the range 0.0 to 1.0.

© 2015 Open Geospatial Consortium

224

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.3.3.2 Default Read Value
If none of the Material Mixture components are available (files associated with the Material
Mixture dataset for the area covered by a tile, at a given LOD or coarser, are either missing or
cannot be accessed), simulator client-devices should assume equal mixturing for all available
Material Layers.
5.6.3.3.3 Default Write Value
The files associated with the Material Mixture components for the area covered by a tile at agiven LOD need not be created if the source data is not available. Tiles partially populated withdata are not permitted.
5.6.3.3.4 Supported Compression Algorithm
The LZW compression algorithm is applicable to Material Mixture components in the TIFF fileformat. Consider compressing the file if its content is not of type floating-point.
5.6.3.4
Composite Material Table Component
This Composite Material Table is called the Terrain CMT, or just TCMT; it provides a list of theComposite Materials shared by the Material Layers of the Material Dataset. There is one TCMT
for each CDB tile.
5.6.3.4.1 Data TypeThe TCMT follows the syntax described in Section 2.5.2.2, Composite Material Tables (CMT).
5.6.3.4.2 Default Read Value
Simulator client-devices should default the Terrain Composite Material Table if file associatedwith the Terrain Composite Material Table for the area covered by a tile, at a given LOD, iseither missing or cannot be accessed. The default values for the Terrain Composite Material
Table can be found in \CDB\Metadata\Defaults.xml and can be provided to the client-devices on
demand. The default value is a single Composite Material and is named:
Z
Default_Material_Layer (0)If the default information cannot be found within the \CDB\Metadata\Defaults.xml file, the CDB
Specification recommends defaulting to single substrate composite material whose base material
is named:Z
Default_Base_Material (BM_LAND-MOOR)
If an index is not found in the Terrain Composite Material Table, use the same defaulting
mechanism.

© 2015 Open Geospatial Consortium

225

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.6.3.4.3 Default Write Value
The files associated with the Terrain Composite Material Table for the area covered by a tile at agiven LOD need not be created if the source data is not available. Tiles partially populated withdata are not permitted.
5.7
Tiled Vector Datasets
Vector tiles differ from their raster counterpart in three important ways. First of all, a vector
tile’s internal structure permits a non-uniform distribution of elements within the tile, (i.e., theposition of each element within the tile is explicit). Secondly, the vector tile’s internal structure
permits a variable number of elements within the tile confines. Finally, it is possible to control
the distribution of the element types from a single list.
Conceptually, the LOD of a vector tile implicitly provides the average density of elements within
the tile. The run-time level-of-detail behavior that controls the rendered number of data elements
depends on various parameters and on the off-line filtering process.
NOTE: The LOD referred to in this section concerns itself with the grouping of cultural features
into tiles at specified LODs, and not with the geometric accuracy or detail of the modeled
representation of these features.
5.7.1
Introduction to Vector Datasets
The CDB Specification uses ESRI Shapefiles to represent vector data and attributes. All shapetypes are supported to represent point, lineal, and areal features.
A point feature is a geographic entity where its simplest representation resolves to a point withgeneral attributes such as size, position, or material. A lineal feature is a geographic entity thatdefines a one-dimensional feature such as a road, a canal, a river. An areal feature is ageographic entity where its simplest representation resolves to a two-dimension feature withgeneral attributes such as size, position and contours. In this context, a geographic entity isalways specified by latitude and longitude coordinates; in turn, the geographic entity is
conformed onto the terrain by the client-device.
The lineal and areal feature’s representation abstractly resolves to a one or a two dimensionalfeature. Unless otherwise specifically mentioned in the CDB Specification, lineal and areal
feature’s representations are not used to model a geometrical representation. However, thesefeatures may optionally reference an explicitly modeled representation (for example an
OpenFlight model) located in the geospecific model or the geotypical model datasets.
As per ESRI Shapefile Technical Description, the set of attributes of Vector features are stored indBase III+ files. Refer to Appendix D for the file format description. The CDB Specification
provides three attribution schemas to represent attribution data:
Z
Z
Z

Instance-level attribution schemaClass-level attribution schema
Extended-level attribution schema© 2015 Open Geospatial Consortium

226

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
To completely represent the vector data and attributes in a given tile, the CDB Specification
requires that a Vector dataset consists of some of all of the following files:
Z*.shp – feature shape files that provides the geometric aspects of each
instance of a vector feature (point, lineal, and areal features). All instances ofthe feature must be of the same Shape type. While the Shapefile format
supports up to 13 different types (each one stored in a different shape file),
CDB Specification requires a maximum of one Shapefile type for point
features, a maximum of one Shapefile type for lineal features and a maximumof one Shapefile type for areal features for each tile (for a maximum of 3
feature Shapefiles per tile).

Z*.shx – feature index files that stores the file offsets and content lengths foreach of the records of the feature files. The only purpose of these files is toprovide a simple means for clients to step through the individual records ofthe feature files (i.e., it contains no CDB modeled data).

Z*.dbf – feature instance-level files that provide the instance-level attribution
data for each of the records of the feature.

Z*.dbf – feature class-level files that provide the class-level attribution data foreach class of features present in the feature shape files.

Z*.dbf – feature extended-level files that provide optional extended-level
attribution data for entries in either the feature instance- or class-level files.

Z*.shp – figure point shape files allow modelers the ability to assign specificattribution for each point in lineal or areal features. Without this additional
Shapefile, the Shapefile format only allows specifying a single attribution for
the entire lineal or areal feature. The CDB Specification extends the concept
to allow specific attribution to each point of these features while enforcing
position correlation. For instance, in case of a PowerLine feature, it ispossible to associate, within the same dataset, a different geometricrepresentation of a PowerLine pylon for each point of the lineal and still
maintain the relationship between the point and the lineal.

Z*.shx – figure point index files that stores the file offsets and content lengths
for each of the records of the figure point shape files.

Z*.dbf – figure point instance-level files that provide the instance-level
attribution data for each of the records of the figure point shape files.

Z*.dbf – figure point class-level files that provide the class-level attribution
data for each class of features present in the figure point shape files

Z*.dbf – figure point extended-level files that provide optional extended-level
attribution data for entries in either the figure point instance- or class-levelfiles.

© 2015 Open Geospatial Consortium

227

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014*.dbf – 2D relationship files. These files establish the relationship of point,
lineal, and areal features of a single or different datasets in a tile and between
tiles.
In addition to *.shp, *.dbf and *.shx files, the Shapefile standard also refers to a memo file with a*.dbt file that is used to store comment fields associated with the attribution *.dbf file.
Z

All of the information that is needed to instance features is organized in accordance to the CDB
tile structure. All the tiled Vector dataset files are located in the same directory; the dataset’s
second component selector (CS2) is used to differentiate between files with the same extension
or with the same Vector features. Table 5-18: Component Selector 2 for Vector Dataset,presents the list of codes that are allocated. Note that Vector datasets do not necessarily use allof the Dataset Component Selector 2 reserved codes. Users of the CDB Specification shouldrefer to the appropriate section for an enumeration of the supported File Component Selector 2codes as well as the ones specific to the Dataset.
The Vector dataset concept and the FACC concepts overlap somewhat; some of the Vector
datasets are generalizations or specializations of FACCs. Appendix N provides a recommended
mapping of the FACC attributes across the CDB Datasets. Note that the same feature should nothave two representations.

Table 5-18: Component Selector 2 for Vector Datasets
CS2 File Extension
001 *.shp
*.shx
*.dbf
002 *.dbf
003 *.shp
*.shx
*.dbf
004 *.dbf
005 *.shp
*.shx
*.dbf
006 *.dbf
007 *.shp
*.shx
*.dbf
008 *.dbf
009 *.shp
*.shx
*.dbf
010 *.dbf
011 *.dbf
012
013

Dataset Component Name
Point features
Point feature class-level attributes
Lineal features

Supported Shape Type
Point, PointZ, PointM,
MultiPoint, MultiPointZ,
MultiPointM
N/A
PolyLine, PolyLineZ,
PolyLineM

Lineal feature class-level attributes
Areal features

N/A
Polygon, PolygonZ,
PolygonM, Multipatch

Areal feature class-level attributes
Lineal figure point features

N/A
Point, PointZ, PointM,
MultiPoint, MultiPointZ,
MultiPointM
N/A
Point, PointZ, PointM,
MultiPoint, MultiPointZ,
MultiPointM
N/A
N/A
N/A
N/A

Lineal figure point feature class-level attributes
Areal figure point features
Areal figure point feature class-level attributes
2D relationship tile connections
DeprecatedDeprecated© 2015 Open Geospatial Consortium

228

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CS2
014
015
016
017
018
019
020

File Extension
*.dbf
*.dbf
*.dbf
*.dbf
*.dbf
*.dbf

Dataset Component Name
Deprecated
2D relationship dataset connections
Point feature extended-level attributes
Lineal feature extended-level attributes
Areal feature extended-level attributes
Lineal Figure Point extended-level attributes
Areal Figure Point extended-level attributes

Supported Shape Type
N/A
N/A
N/A
N/A
N/A
N/A
N/A

5.7.1.1
Shapefile Type Usage and Conventions
This section establishes conventions globally applicable to the usage of all Shapefile features.

For explicitly modeled point cultural features:
Each point-feature of the CDB can be optionally associated with a GSModel, a GTModel orMModel. The rendering of GSModels, GTModels or MModels by client-devices requires anassociated point-feature. The linkage is made through point-feature attributes which together
provide the information needed by client-devices to locate the Model from the appropriate
Dataset at the appropriate level-of-detail. The following feature attributes provide the necessary
linkage:
FACC-FSC: Feature Code and Subcode
MODL: Model Name
MODT: Model Type
MLOD: Model Level-of-Detail
MMDC: Moving Model DIS CodeIn the Shapefile, the position of all points is expressed using WGS-84 geographic coordinates(latitude, longitude, altitude), as explained in Appendix K. If the feature has an associatedmodel, client-devices are required to position the model’s origin at the specified coordinate,orient the model’s Y-axis in accordance to the AO1 attribute, and align the model’s Z-axis sothat it points up. In the case of Shape types that do not have a Z component value, the object’s
height value is referenced to the underlying terrain; as a result, client-devices are required toposition the model’s origin wrt underlying terrain elevation dataset. For Point features with a Z
component, client-devices are required to position the model as per the AHGT class attributevalue. If AHGT is true, the model’s origin is positioned to the value specified by the Z
component (Absolute Terrain Altitude), irrelevant of the terrain elevation dataset. If AHGT isfalse or not present, the model’s origin is positioned to the value specified by the underlying
terrain offset by the Z component value.

© 2015 Open Geospatial Consortium

229

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
For modeled light points:
It is common practice within the simulation industry to model light points without theirassociated support structures. In this case, the preferred way to model light points is through theuse of point-features within the Airport and Environmental Light-Point Features Datasets of the
CDB; consequently, there are no Models associated with Airport and Environmental Light-Point
Features.
Note however that is entirely permissible to also model lights points with their associated support
structures. In this case, the CDB OpenFlight Model representing the support structure also
contains light points as specified in section 6.11, Model Light Points.
The “modeling” of light points is accomplished via the following light-point feature attributes:
LTYP: Light Type
LPH: Light Phase
AO1: Angle of Orientation
The position of light points are expressed using WGS-84 geographic coordinates (latitude,
longitude, altitude), as explained in Appendix K. Client-devices are required to position thecenter of the light point at the specified coordinate, orient directional light points in accordance
to the AO1 attribute. The elevation angle component of a directional light point is intrinsic to its
type (for instance a VASI\TypeT\2.5_Degree\Fly-Up1_light should be used to represent a TypeVASI light used for a 2.5 degree glide slope). In the case of Shape types that do not have a Z
component value, the light point’s height value is referenced to the underlying terrain; as a result,client-devices are required to elevate the light point’s center wrt underlying terrain elevation
dataset. For Light Point features with a Z component, client-devices are required to position thelight point’s center as per the AHGT value. If AHGT is true, the light point’s center ispositioned to the value specified by the Z component (Absolute Terrain Altitude), irrelevant of
the terrain elevation dataset. If AHGT is false or not present, the light point’s center ispositioned to the value specified by the underlying terrain offset by the Z component value.

For point, lineal and areal features that are not modeled:
The CDB data model does not make mandatory that all features of the CDB be modeled; as aresult, each feature is optionally associated with a GSModel, a GTModel or a MModel.
The position of vertices is expressed using WGS-84 geographic coordinates (latitude, longitude,
altitude), as explained in Appendix K. In the case of Shape types that do not have a Z
component value, the vertex’s height value is referenced to the underlying terrain; as a result,client-devices are required to position the vertex’s origin wrt underlying terrain elevation dataset.
For Shape types with a Z component, client-devices are required to position the vertex as per the
AHGT value. If AHGT is true, the vertex is positioned to the value specified by the Z
component (Absolute Terrain Altitude), irrelevant of the terrain elevation dataset. If AHGT is© 2015 Open Geospatial Consortium

230

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
false or not present, the vertex is positioned to the value specified by the underlying terrain offset
by the Z component value.
AHGT attribute, when present, is always ignored when the Z component value does not exist.
The bounding box coordinates Xmin, Ymin, Xmax, Ymax required by some Shape types are
expressed using WGS-84 geographic coordinates (in accordance to Appendix K).
The value of M and Mrange found in some of the Shape types (PointM, MultiPointM,
PolygonM, and PolyLineM) is ignored by client-devices.
5.7.1.1.1 Notes about Shapefile Polygon Shapes
Even though the Shapefile standard is very versatile, it also enforces some guidelines withrespect to the Polygon Shapes. Those guidelines are referred to in Appendix D – Shapefile July
1998 Technical Description – Annotated.
The key aspects that should be respected while generating Polygon Shapes are re-listed below:Z
Has no self-intersections or co-linear segmentsZ
Has no identical consecutive points (no zero-length segments)
Z
Does not degenerate into zero-area parts
Z
Does not have clock-wise inner rings (“Dirty Polygon”)
Although the above are guidelines, Shapefile readers shall handle such cases with proper error
handling and reporting.
5.7.1.2
CDB Attribution
Attributes are used to describe one or more real or virtual characteristics of a feature. Features
can be assigned a variable number of attributes.
5.7.1.2.1 Attribute CodeA unique four-digit numeric code is associated to each attribute. For example, the attribute"Angle of Orientation" has an attribute code of “0003”.
5.7.1.2.2 Attribute Identifier
A unique three-character or four-character alphanumeric identifier is associated to the attributes
that are governed by this Specification. Attributes other than those governed by the CDB
Specification may not have an assigned identifier. For example, the CDB attribute "Length" hasthe “LEN” identifier. The identifier is a case-sensitive string of up to 10 characters. In the caseof instance-level and class-level attributes, the identifier is used as the name of the *.dbf column.
5.7.1.2.3 Attribute Semantics
Each attribute is associated with a textual description (describing semantic information), which
provides a human readable definition of the attribute.

© 2015 Open Geospatial Consortium

231

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.2.4 Attributes Values
A value can be assigned to each attribute. The data type, length, format, range, usage, units,compatibility and schema of each attribute value is governed by this Specification. Attributevalues give quantitative/qualitative meaning to the attribute.
5.7.1.2.5 Attribute Usage
CDB attribution usage falls in the following categories:
Mandatory: A mandatory attribute is an attribute whose value must be provided for all of thefeatures of a specified dataset, i.e., a producer of CDB data (e.g., tools) is required to generatevalues for mandatory attributes. Consumers of CDB data (tools and/or simulator client-devices)can rely on the availability of mandatory attributes. A CDB with missing mandatory attributes is
considered non-compliant by this Specification.
Recommended: A recommended attribute is an attribute whose value should be provided for allof the features of a specified dataset. Consumers of CDB data (tools and/or simulator clientdevices) can always rely on the availability of recommended attributes since the attribute value iseither provided explicitly by the CDB or provided implicitly as a defaulted value in accordance
to section 5.7.1.3, CDB Attributes. A CDB with defaulted recommended attributes is considered
compliant by this Specification; however, the performance of one or more of the client-devices(commonly found on simulation devices) may be adversely affected.
Optional: An optional attribute is an attribute whose value may (optionally) be provided for allof the features of a specified dataset. Consumers of CDB data (tools and/or simulator clientdevices) cannot rely on the availability of optional attributes. A CDB with missing optional
attributes is considered compliant by this Specification; however, the performance of one ormore of the client-devices (commonly found on simulation devices) may be enhanced byincluding the optional attributes.
Dependent: A dependent attribute is an attribute whose value depends on another attribute, be it
mandatory, recommended, or optional. The attribute is considered mandatory if the attribute it
depends on is mandatory. Likewise, the attribute is considered recommended if the attribute it
depends on is recommended. Finally, the attribute is considered optional if the attribute it
depends on is optional.
Note that attribute usage information for each of the CDB attributes can be found in section
5.7.1.3, CDB Attributes and in Table 5-27: Allocation of CDB Attributes to Vector Datasets
5.7.1.2.6

Attribution Data Compatibility
The CDB Specification provides a flexible means to tag features with attribution data.
The CDB Specification accommodates the vast majority of attribution data that is in
use today and available through formats and products supported by the NGA andother US governmental agencies. The CDB Specification provides the means toattribute features with attribution data with varied origins.

© 2015 Open Geospatial Consortium

232

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.2.6.1 CDB Attributes
CDB attributes are attributes whose semantics, data type, length, format, range,
usage, units, compatibility and schema are entirely governed by the CDB
specification. Most of these attributes are unique to the CDB Specification, i.e., these
attributes are not found in source data that conforms to various (US) governmental
standards and Specifications. As a result, this attribution data must be derived via
CDB tool automation or provided directly by the user.
5.7.1.2.6.2 Geomatics Attributes
Geomatics attributes are attributes whose semantics, data type, length, format, range,
usage, and units, are governed by various governmental/industrial Specifications andstandards. Such attributes are generally found in source data that conforms to suchstandards and specifications. While the CDB Specification itself does not define andgovern the usage of these attributes, it nonetheless accommodates their storage within
the repository structure of the CDB.
5.7.1.2.6.3 Vendor Attributes
Vendor attributes are attributes whose semantics, data type, length, format, range,
usage, and units are governed by one or more vendors. In general, such attributes
cannot be used by other vendors since they are often proprietary. Such attributes
exclude the above two types of attributes and are generally unique to each vendor.
While the CDB Specification itself does not define and govern the usage of these
attributes, it nonetheless accommodates their storage within a CDB.
5.7.1.2.7

Attribution Schemas
The CDB Specification offers three different attribution schemas. Each of theschemas offers different trade-offs in the manner attribution data is accessed andstored. Each of these schemas is largely motivated by the storage size considerations,and flexibility in the manner attribution data can be assigned to individual features
and to groups of features.
The three attribution schemas supported by the CDB Specification are:Instance-level schemaClass-level schema
Extended-level schema

5.7.1.2.7.1 Instance-level SchemaThis is the attribution schema used for features whose attributes and attribute values vary witheach instance of a feature in a dataset. The attributes and their values are specified as attribution
columns in the instance-level *.dbf file that accompanies the dataset’s *.shp file. This *.dbf fileis referred to as the Dataset Instance-level*.dbf file.

© 2015 Open Geospatial Consortium

233

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Each instance of a feature is characterized by a corresponding set of instance-level attributes
implemented as a row within the instance-level *.dbf file. Each attribute is uniquely defined by
an attribute identifier that is a “case-sensitive” character string of 10 characters or less. This 10character limitation of attribute names is set by the dBASE III+ File format structure
implementation (see Appendix D).
The data type, length, format, range, usage, and units of the attribution values are specific to each
attribute. The interpretation of the attribution data value is governed by metadata that describes
the data type, the data format, the allowable range of the data, the numerical precision of thedata, the units associated with the data, etc for each attribute. The CDB_Attributes.xml metadata
file is used to describe all the CDB attributes listed in 5.7.1.2, CDB Attribution. This attributemetadata *.xml file must be included in the CDB folder hierarchy under the CDB Metadata
directory (refer to section 3.1.1, Metadata Directory). The CDB_Attributes.xml metadata file isbased on a *.xsd schema file that governs the syntax and structure of the attribute metadata file.
Refer to Appendix J for a listing of the attribute metadata schema.
Each row of this instance-level *.dbf file contains the instance-level attribute values for acorresponding feature in the *.shp file. The first column of each row within the instance-level*.dbf is always the classname (CNAM). If the classname is not used, its value is set to blank,
and all of the classname attributes must be added to the instance-level *.dbf file. The number ofcolumns in a Dataset Instance-level *.dbf file is different for each dataset. All of the instancelevel attributes are CDB attributes.

Figure 5-28: Instance-level Attribution Schema

5.7.1.2.7.2 Class-level SchemaThis is the preferred attribution schema for features whose attributes and attribute values can beshared by one or more of the instances of a feature in a dataset.
The attributes and their values are logically re-grouped under a classname (CNAM attribute) thatstands for the group of attributes specific to that class. Each row of the class-level *.dbf file© 2015 Open Geospatial Consortium

234

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
corresponds to a classname found in the instance-level *.dbf shape file. Each attribute class ischaracterized by a set of attributes implemented as a row within the class-level *.dbf file. Inturn, each attribute is uniquely defined by a name that is a “case-sensitive” character string of 10
characters or less. This 10-character limitation of attribute names is set by the dBASE III+ Fileformat structure implementation (see Appendix D).
The interpretation of the attribution data value is governed by metadata that describes the data
type, the data format, the allowable range of the data, the numerical precision of the data, theunits associated with the data, etc for each attribute. The CDB_Attributes.xml metadata file isused to describe all the CDB attributes listed in section 5.7.1.2, CDB Attribution. The
CDB_Attributes.xml file must be included in the CDB folder hierarchy under the CDB Metadata
directory (refer to section 3.1.1, Metadata Directory). The CDB_Attributes.xml metadata file isstructured in accordance to a *.xsd schema file. Refer to Appendix J for a description of theattribute metadata schema.
The first column of the file is the classname and acts as the primary key to access table entries;
all other rows correspond to the attributes represented by the classname. All of the class-level
attributes are CDB attributes. For each dataset, a classname is unique within a geocell.

Figure 5-29: Class-level Attribution Schema

5.7.1.2.7.3 Extended-level Schema
The CDB Specification provides an alternate attribution schema that can be used (in many cases)
to supplement the instance-level and class-level schemas.
The extended-level schema can be used to represent CDB attributes, Geomatics attributes andVendor attributes. However, the extended-level schema is the only means by which Geomatics
attributes and Vendor attributes can be accessed.
Linkage to the extended-level CDB attribution data is accomplished through the CEAI attribute;
CEAI is an index to a link list of CDB attributes stored in the extended-level *.dbf file.
Similarly, the GEAI and VEAI attributes are also indices to link lists of attributes stored in theextended-level *.dbf file. The extended-level *.dbf files has the structure described in section
5.7.1.2.7.4, Structure of Extended-level dbf Files.
There is one attribute metadata file (named CDB_Attributes.xml) that describes the CDB
attributes of section 5.7.1.3, CDB Attributes, one attribute metadata file (named© 2015 Open Geospatial Consortium

235

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Geomatics_Attributes.xml) for the Geomatics attributes and one attribute metadata file (named
Vendor_Attributes.xml) for the Vendor attributes. All three attribute metadata *.xml files are
optional; if provided, they must be included in the CDB folder hierarchy under the CDB
Metadata directory (refer to section 3.1.1, Metadata Directory). All three attribute metadata*.xml files share the same schema. The schema that governs the contents of the attributemetadata files is Vector_Attributes.xsd. Refer to Appendix J for a description of this schema.
5.7.1.2.7.4 Structure of Extended-level dbf Files
Each row of the Extended-Level *.dbf files correspond to an attribute. Each attribute row
consists of four columns as follows:
Column 1 – LNK (Link): The first column is a numeric 6-digit index to the next entry of a link
list of attributes (a value of 0 marks the end of the list). The LNK field provides a means toorganize attributes into link lists of attributes that in turn can be associated with a feature.
Column 2 – GRP (Group): The second column provides an 8-character string that is used toname the group to which the extended attributes belongs to. The actual value of this character
string is arbitrary and provides an indication of the source of the attribute. In practice, attributes
belongs to one of three (3) groups: CDB, Geomatics, and Vendor. If the extended-level attributeis one of the CDB attributes of section 5.7.1.2.7.5, the group name is “CDB”. If the extendedlevel attribute belongs to one of the Geomatics standards (such as “DIGEST”, “VMAP”,“SEDRIS”, “DGIWG”, “UHRB”), it is recommended to use the name of the standard as thegroup name. If the extended-level attribute is a vendor-specific attribute, then the group nameshould represent the name of the vendor (such as “CAE-M”, “Presagis”, “Thales”, “Rockwell”).
Column 3 – EAC (Environment Attribute Code): The third column provides a unique fourdigit numeric code for each attribute type. The codes for the CDB attributes can be found insection 5.7.1.3, CDB Attributes. Note however, that the codes for the Geomatics and Vendor
attributes are not specified by this Specification. Instead, this Specification provides a metadata
schema that allows developers to describe these attributes. See section 5.1.7, CDB Attributes
Metadata, for details.
Column 4 – EAV (Environment Attribute Value): The fourth column provides a data value forthe attribute. The data value is represented by general-purpose 16-character alphanumeric string.
In the case where more than 16-characters are needed to represent a data value, the remaining
characters are provided by appending consecutive row(s) with the same GRP and EAC values;
the value of LNK is incremented for each of the consecutive row(s). The interpretation of thedata value is governed by metadata that describes the data type, the data format, the allowable
range of the data, the numerical precision of the data, the units associated with the data, etc foreach attribute type.
5.7.1.2.7.5 Example
The following example illustrates the relations between Shapefiles and dBase files where
instance, class, and extended-level attributes are stored. The example focuses on extended-level© 2015 Open Geospatial Consortium

236

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014attributes. Note that it is possible to extend the list of instance and class attributes through theuse of the CEAI, GEAI, and VEAI attributes.
The attributes associated with the instance of Shape 2 are extended with CDB attributes because
CEAI has the value 4; that is an index into the Extended-level attributes dBase file, it points torecord 4. By following the link (LNK) in each record, the complete list of extended attributes
contains records 4, 5, and 8. These records add 3 CDB attributes: 5, 54, and 25. These codes
respectively correspond to APID, RWID, and GAID. Their respective values are Airport CYUL,
Runway 06L, and Gate B23.
The attributes that belong to the “Container” class are also extended with CDB attributes as
indicated by the value 6 of the CEAI attribute. Record 6 adds CDB attribute 29, LACC, with avalue of 1; record 7 adds CDB attribute 60, SSC, with a value of 84.
The attributes of the “Railroad” class are extended by Geomatics attributes as indicated by GEAI
and its value of 1. This adds 3 DIGEST geomatics attributes (numbered 1, 2 and 3) that are
defined in Geometics_Attributes.xml.
Finally, the “Highway” class attributes are extended with a single vendor attribute stored inrecord 9 and 10 (VEAI points to record 9 which points to record 10). The client detects that thisis a single attribute (and not two separate attributes) because the two records have identicalvalues for their GRP and EAC attributes. The vendor is identified as “ABC Inc.”; attribute 1,
defined in Vendor_Attributes.xml, has the value “1234567890ABCDEFGHIJ”.

© 2015 Open Geospatial Consortium

237

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

RTAI

SCALz

CEAI

GEAI

VEAI

5.2°
-­‐
-­‐
-­‐
-­‐

-­‐
82	
  500	  m33	
  565	  m154	  000	
  m
53565	
  m

-­‐
1
1
1
1

89% 1.0 1.0 1.0
71% -­‐-­‐-­‐
99% -­‐-­‐-­‐
85% -­‐-­‐-­‐
99% -­‐
-­‐
-­‐

-­‐
4
-­‐
-­‐
-­‐

-­‐
-­‐
-­‐
-­‐
-­‐

-­‐
-­‐
-­‐
-­‐
-­‐

SCALy

LPN

House
Highway
Highway
Railroad
Highway
…

SCALx

LENL

…

AO1

Shape	
  1
Shape	
  2
Shape	
  3
Shape	
  4
Shape	
  5

Instance-­‐Level	  Attributes	
  (*.dbf)
CNAM

Shapefile	
  (*.shp)

…

FACC

FSC

CEAI

GEAI

VEAI

Record	  1
Record	  2
Record	  3
Record	
  4

VX000
AN010
AP030

000
000
002

6
-­‐
-­‐

-­‐
1
-­‐

-­‐
-­‐
9

BSR

Header

CNAM

Class-­‐Level	  Attributes	
  (*.dbf)

Container 15.2	
  m
Railroad-­‐
Highway-­‐…

…

Header

LNK

GRP

EAC

EAV

Extended-­‐Level	  Attributes	
  (*.dbf)

Record	  1
Record	  2
Record	  3
Record	  4
Record	  5
Record	  6
Record	  7
Record	  8
Record	  9Record	
  10

2
3
0
5
8
7
0
0
10
0

DIGESTDIGESTDIGEST
CDB
CDB
CDB
CDB
CDB
ABC	
  Inc.
ABC	
  Inc.

1
2
3
5
54
29
60
25
1
1

1
6.45
XYZ...
CYUL
06L
1
84
B23
1234567890ABCDEF
GHIJ

Figure 5-30: Relation between Shapes and Attributes

Note that it is possible to simultaneously extend a record (instance and class) with CDB,
Geomatics, and vendor attributes. The example does not illustrate this situation to keep it(relatively) simple.

© 2015 Open Geospatial Consortium

238

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3
CDB Attributes
This section provides a list and description of the attributes that are governed by the CDB
Specification. Note that it is possible to provide attributes other than those listed here by making
use of the Geomatics and Vendor Extended-level attribution schema.
5.7.1.3.1

ATARS Extended Attribute Code (AEAC) – DeprecatedDescription:

A unique numeric identifier that points to the entry number of the
ATARS Extended Attribution file for the current dataset. This entry
is provided for legacy database generation facility considerations
only; CDB-compliant devices are not required to read and interpret
this field. The ATARS Extended Attribution file should be locatedin the same directory as the instance-level attribution file. An empty
AEAC field (i.e., null string) is allowed.

Identifier:

AEAC

Code:

0001

Data Type:numeric

Length:9 characters

Format:integer

Range:

0 to 999,999,999

Usage Note:

Optional. Use when ATARS extended attribution is required.

Unit:

N/A

Compatibility: CDB 3.0
5.7.1.3.2

Absolute Height Flag (AHGT)
Description:

Indicates how to interpret the Z component of a vertex.

Identifier:

AHGT

Code:

0002

Data Type:

LogicalLength:1 character

Format:N/A

Range:

F, f, N, n (false) and T, t, Y, y (true)© 2015 Open Geospatial Consortium

239

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Usage Note:

Optional. Specifies how to interpret shape type features with a Z
component. If AHGT is true, the feature is positioned to the value
specified by the Z component (Absolute Terrain Altitude), irrelevantof the terrain elevation dataset. If AHGT is false or not present, thefeature is positioned to the value specified by the underlying terrain
offset by the Z component value. Refer to section 5.7.1.1, Shapefile
Type Usage and Conventions for more details. AHGT can bepresent only in datasets using PointZ, PolylineZ, PolygonZ andMultiPointZ Shape types. AHGT should not be present for all other
Shape types or must be ignored otherwise. Refer to Appendix A –“How to Interpret the AHGT, HGT, BSR, BBH, and Z Attributes”
for additional usage guidelines.

Unit:

N/A

Default:

False

Compatibility: CDB 3.0

NOTE: It is recommended that the AHGT flag be set to false because it facilitates the creation of
CDB datasets that are independent of each others. When the Z coordinate (altitude)of a feature is relative to the ground, the terrain elevation dataset can be updated
without the need to recompute the altitude of the feature.

CAUTION: When the AHGT flag is set to true, the feature will be at a fixed WGS-84 elevation
independently of the terrain LOD selected by the client-device. As a result, there is
no guarantee that the feature (and its modeled representation) will remain above theterrain across all terrain LODs.

RECOMMENDATION:
Limit the use of AHGT=TRUE to data whose source is inherently
absolute. Such source data include geodetic marks or survey marks that provide aknown position in terms of latitude, longitude, and altitude. Good examples of suchmarkers are boundary markers between countries.

© 2015 Open Geospatial Consortium

240

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.3

Angle of Orientation (AO1)
Description:

Angle of Orientation with greater than 1 degree resolution – Theangular distance measured from true north (0°) clockwise to themajor (Y) axis of the feature.

Identifier:

AO1

Code:

0003

Data Type:numeric

Length:7 characters

Format:floating-point (recommended precision of 3.3)

Range:

0.000 to 360.000

Usage Note:

Recommended. CDB readers should default to a value of 0.000 if
AO1 is missing. Applicable to Point, Light Point, Moving Model
Location and Figure Point features. When used in conjunction with
the PowerLineNetwork dataset, AO1 corresponds to the orientationof the Y-axis of the modeled pylon. The modeled pylon should beoriented (in its local Cartesian space) so that the wires nominallyattach along the Y-axis. Refer to Appendix A – “Creating a 3D
Model for a Powerline Pylon” for additional usage guidelines.

Unit:

degreeDefault:

0.000

Compatibility: CDB 3.0, DIGEST v2.1
5.7.1.3.4

Airport Feature Name (APFN) – DeprecatedDescription:

This name is used to distinguish and categorize features within thelist of available Airport Lineal features and Airport Areal features.

Identifier:

APFN

Code:

0004

Data Type:text

Length:24 characters

Format:Alpha characters

Range:

N/A© 2015 Open Geospatial Consortium

241

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Usage Note:

N/A

Unit:

N/A

Default:

N/A

Compatibility: CDB 3.0
5.7.1.3.5

Airport ID (APID)
Description:

A unique alphanumeric identifier that points to a record in the
NavData Airport or Heliport dataset (i.e., a link to the Airport or the
Heliport description in the NavData dataset). This ID is the value ofthe field Ident of the Airport or Heliport dataset. Note that all of thelights located in vector datasets that are associated with the operationof an airport (including runway lights and lighting systems) are
required to reference an airport or heliport in the NavData dataset.
All man-made features associated with an airport or heliport must be
assigned an APID attribute; the APID attribute is not required forfeatures unrelated to airports or heliports.

Identifier:

APID

Code:

0005

Data Type:alphanumeric

Length:6 characters

Format:N/A

Range:

N/A

Usage Note:

Recommended for all Airport Light Points and airport-related
T2DModels (such as runway/taxiway/apron surfaces, and markings)
Failure to appropriately tag airport culture with APID attribute will
result in reduced control of airport-related culture by simulator.
Optional for Location Points, Environmental Light Points, andMoving Model Location features that fall within the confines of an
airport and for which control of the feature is desirable.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0© 2015 Open Geospatial Consortium

242

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Bounding Box Height (BBH)
5.7.1.3.7 Bounding Box Width (BBW)
5.7.1.3.8 Bounding Box Length (BBL)
5.7.1.3.6

Description:

The Height/Width/Length of the Bounding Box of the 3D model
associated with a point feature. It is the dimension of the box
centered at the model origin and that bounds the portion of the model
above its XY plane, including the envelopes of all articulated parts.
BBH refers to height of the box above the XY plane of the model,
BBW refers to the width of the box along the X-axis, and BBL refers
to the length of the box along the Y-axis. Note that for 3D models
used as cultural features, the XY plane of the model corresponds to
its ground reference plane. The value of BBH, BBW and BBL
should be accounted for by client-devices (in combination with otherinformation) to determine the appropriate distance at which themodel should be paged-in, rendered or processed. BBH, BBW andBBL are usually generated through database authoring tool
automation.

Identifiers:

BBH, BBW, BBL

Codes:

0006, 0007, 0008

Data Type:numeric

Length:9 characters

Format:floating-point (recommended precision 5.3)

Range:

0.000 to 99999.999

Usage Note:

Optional on features for which a MODL has been assigned. The
dimension of the bounding box is intrinsic to the model and identicalfor all LOD representations. Refer to Appendix A – “How toInterpret the AHGT, HGT, BSR, BBH, and Z Attributes” foradditional usage guidelines.

Unit:

metersDefault:

BBH defaults to the value of BSR

BBW and BBL default to twice the value of BSR
Compatibility: CDB 3.0
5.7.1.3.9

Boundary Type (BOTY)
Description:

A value that uniquely attributes a boundary according to theenumerators found here.

© 2015 Open Geospatial Consortium

243

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Identifier:

BOTY

Code:

0009

Data Type:

Enumeration per Table 5-19: Boundary Type Enumeration Values

Length:3 characters

Format:integer

Range:

0 to 999

Usage Note:

Optional. See table below for a list of accepted values. Can be used
only with Boundary Point, Lineal or Areal Feature Datasets (which
are part of the Geopolitical Datasets)

Unit:

N/A

Default:

0Compatibility: CDB 3.0

Table 5-19: Boundary Type Enumeration Values
BOTY Code Description0

Unknown

2

International

4Inter-provincial

5

Territorial

7

Regional

9

Tourist11

Military District

13

Populated Place

15

Time Zone Delimiter

1
3

6
8
10
12
14
16

Continental
Interstate

Economic

Communal
Private Zone
Disputed

Non-capital City
International Date Line© 2015 Open Geospatial Consortium

244

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 201417

Capital City

998

Not Applicable

999

Other

997

Unpopulated

5.7.1.3.10 Bounding Sphere Radius (BSR)
Description:
The radius of a feature. In the case where a feature references anassociated 3D model, it is the radius of the hemisphere centered at
the model origin and that bounds the portion of the model above its
XY plane, including the envelopes of all articulated parts. Note thatfor 3D models used as cultural features, the XY plane of the model
corresponds to its ground reference plane. The value of BSR shouldbe accounted for by client-devices (in combination with otherinformation) to determine the appropriate distance at which themodel should be paged-in, rendered or processed. When the featuredoes not reference a 3D model, BSR is the radius of the abstract
point representing the feature (e.g., a city).
Identifier:

BSR

Code:

0010

Data Type:numeric

Length:9 characters

Format:floating-point (recommended precision 5.3)

Range:

0.000 to 99,999.999

Usage Note:

Mandatory for features for which a MODL has been assigned, but
optional for geopolitical point features. The dimension of thebounding sphere is intrinsic to the model and identical for all LOD
representations. Refer to Appendix A – “How to Interpret the
AHGT, HGT, BSR, BBH, and Z Attributes” for additional usage
guidelines.

Unit:

metersDefault:

None

Compatibility: CDB 3.0© 2015 Open Geospatial Consortium

245

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.11 CDB Extended Attribute Index (CEAI)
Description:
An index that points to a row entry of a CDB Extended Attribution
file for the current dataset. This entry permits users to store an index
to a link list set of CDB-specific attributes. CDB-compliant devices
must be capable of reading and interpreting this field. Usage of this
attribution is not portable to other simulators because it falls outsideof the documented CDB attribution scheme. The CDB Extended
Attribution file should be located in the same directory as theinstance-level attribution file. An empty CEAI attribute is allowed.
Note that the first entry in the CDB Extended Attribution file has anindex of 1.
Identifier:

CEAI

Code:

0011

Data Type:numeric

Length:6 characters

Format:integer

Range:

1 to 999,999

Usage Note:

Optional. Use when CDB extended attribution is required. A“blank” or a value of 0 indicates that there are no CDB Extended
attributes.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0.
5.7.1.3.12 CDB Extended Attribute Code (CEAC) – DeprecatedDescription:
A unique numeric identifier that points to the entry number of a
CDB Extended Attribution file for the current dataset. This entry
permits users to store a link to a set of CDB-specific attributes
beyond those explicitly supported by the current version of thisSpecification. CDB-compliant devices may optionally read andinterpret this field due to program requirements that cannot be
supported by the current version of the CDB. Usage of this
attribution is not portable to other simulators because it falls outsideof the documented CDB attribution scheme. The CDB Extended
Attribution file should be located in the same directory as theinstance-level attribution file. An empty CEAC field is allowed.

© 2015 Open Geospatial Consortium

246

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Identifier:

CEAC

Code:

0012

Data Type:numeric

Length:9 characters

Format:integer

Range:

0 to 999,999,999

Usage Note:

Optional. Use when CDB extended attribution is required.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.13 Composite Material Index (CMIX)
Description:
Index into the Composite Material Table is used to determine theBase Materials composition of the associated feature. Refer to
Section 2.5, Material Naming Conventions for a description onmaterial naming conventions.
Identifier:

CMIX

Code:

0013

Data Type:numeric

Length:6 characters

Format:integer

Range:

0 to 999,999

Usage Note:

Mandatory. Recommended to specify materials on polygons ofMoving Models.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0© 2015 Open Geospatial Consortium

247

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.14 Class Name (CNAM)
Description:
A name that represents the Attribution Class. The class-level
attribution schema is described in Section 5.7.1.2.7.2, Class-level
Schema. Attributes are referenced via this classname. The
classname is used as the primary key to perform searches within theDataset Class Attribute file.
Identifier:

CNAM

Code:

0014

Data Type:text

Length:32 characters

Format:lexicalRange:

N/A

Usage Note:

Each row of a class-level dBASE file must have a valid CNAM
entry; the CNAM must be unique within the file. Each row of an
instance-level *.dbf can optionally use the CNAM to refer to classattributes; blank indicates “no class attribute”.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.15 Damage Level (DAMA)
Description:
Represents the level of damage of the feature and its model, if
applicable. The level is expressed as a percentage where a value of 0means no damage at all and a value of 100 means fully damaged andcompletely destroyed. In the case of network datasets, the level ofdamage shall be interpreted as a measure of the incapacity of thefeature to perform its function. For instance, a road network whose
damage level is 75% tells the client that it is only able to perform
25% of its intended function. As a result, a certain client may decidethat it cannot use the road network while another client may continue
to do so.
Identifier:

DAMA

Code:

0067

© 2015 Open Geospatial Consortium

248

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Data Type:numeric

Length:3 characters

Format:integer

Range:

0 to 100

Unit:

Percentage

Default:

0Compatibility: CDB 3.2
Usage Note:

In the context of HLA/DIS, the concept of DAMA maps directly tothe concepts of Damage State for which the standards define 4 states
named No Damage, Slight Damage, Moderate Damage, andDestroyed. The Specification suggests the following mapping
between CDB DAMA and HLA/DIS states.

From CDB to HLA/DIS
DAMA < 25

From HLA/DIS to CDB

No Damage

No Damage025 ≤ DAMA < 50

Slight Damage

Slight Damage

33

50 ≤ DAMA < 75

Moderate Damage

Moderate Damage

66

75 ≤ DAMA

Destroyed

Destroyed

100

5.7.1.3.16 DIGEST Extended Attribute Code (DEAC) – DeprecatedDescription:
A unique numeric identifier that points to the entry number of the
DIGEST Extended Attribution file for the current dataset. This entry
is provided for legacy database generation facility considerations
only; it provides a means for the CDB to act as a repository forlegacy DIGEST attribution. CDB-compliant devices are notrequired to read and interpret this field. The DIGEST Extended
Attribution file should be located in the same directory as theinstance-level attribution file. An empty DEAC field (i.e., null
string) is allowed.
Identifier:

DEAC

Code:

0015

© 2015 Open Geospatial Consortium

249

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Data Type:numeric

Length:9 characters

Format:integer

Range:

0 to 999,999,999

Usage Note:

Optional. Use when DIGEST extended attribution is required.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0.
5.7.1.3.17 Depth below Surface Level (DEP)
Description:
The depth of a feature. If the feature has no modeled representation,
its depth is measured as the distance from the surface level to thelowest point of the feature below the surface64. If the feature has an
associated 3D model, the depth is measured as the distance from the
XY plane of the model to the lowest point of the model below thatplane. DEP values are positive numbers.

64

Identifier:

DEP

Code:

0016

Data Type:numeric

Length:9 characters

Format:floating-point (recommended precision 5.3)

Range:

0.000 to 99999.999

Usage Note:

In the case of ground features, DEP refers to the portion of thefeature (or its modeled representation) that is underground. In thecase of moving models that are used as geotypical features, DEP
refers to the portion of the model that is below the waterline (i.e., theXY plane). In the case of network lineal features such as roads,
railroads and powerlines, DEP refers to the depth of the feature
under the ground in its vicinity. In the case of hydrographic features,

Surface here refers to the terrain in the immediate vicinity of the feature.

© 2015 Open Geospatial Consortium

250

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
DEP refers to the depth of rivers, lakes, etc65. This data is typicallyused by client-devices that need to determine whether or not awaterway is navigable by ships with a specific draw.
Unit:metersDefault:

0.000

Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.3.18 Directivity (DIR)
Description:
The side or sides of a feature that has the greatest reflectivity
potential. This data is typically needed for Radar simulation. DIR isused solely for lineal features in accordance to DFAD conventions
If DIR is not equal to 3, then AO1 is the angular distance measured
from true north (0 deg) clockwise to the reflective side of the feature.
Identifier:

DIR

Code:

0017

Data Type:numeric

Length:3 characters.

Format:integer. Enumerated per DIGEST

Range:

1: Uni-directional
2: Bi-directional
3: Omni-directional
0 to 999

Usage Note:

Recommended for lineal features. If absent, client-devices are
required to default to a value of 3 – Omni-directional

Unit:

N/A

Default:

3

Compatibility: CDB 3.0 and DIGEST

65

Note, that the CDB has provision for a raster dataset to represent the bathymetry. When provided, the dataset
provides a much more detailed underwater profile of hydrographic features.

© 2015 Open Geospatial Consortium

251

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.19 Density Measure (DML)
Description:
Percentage light coverage at night (expressed as a percentage) within
the area delimited by an areal feature.
Identifier:

DML

Code:

0018

Data Type:numeric

Length:3 characters

Format:integer

Range:

0 to 100

Usage Note:

Recommended. Applies to Geopolitical Dataset areal features thatdelineate inhabited areas. If this field is absent, client-devices shallassume 0%.

Unit:

Percentage

Default:

0Compatibility: CDB 3.0
5.7.1.3.20 Density Measure (% roof cover) (DMR)
Description:
Roof cover measure by percent within area of feature.
Identifier:

DMR

Code:

0019

Data Type:numeric

Length:3 characters

Format:integer

Range:

0 to 100

Usage Note:

Recommended for Areal features. If absent, client-devices shallassume 0%.

Unit:

percentage

Default:

0© 2015 Open Geospatial Consortium

252

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.3.21 Density Measure (structure count) (DMS)
Description:
Number of man-made, habitable structures per square kilometer.
Identifier:

DMS

Code:

0020

Data Type:numeric

Length:5 characters

Format:integer

Range:

0 to 99,999 (Note: differs from DIGEST range of -32767 to 32768)

Usage Note:

Recommended for Areal features. If absent, client-devices shallassume 0.

Unit:

N/A

Default:

0Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.3.22 Density Measure (% tree/canopy cover) (DMT)
Description:
Canopy cover measure by percent within area of feature during thesummer season.
Identifier:

DMT

Code:

0021

Data Type:numeric

Length:3 characters

Format:integer

Range:

0 to 100

Usage Note:

Recommended for Areal features. If absent, client-devices shallassume 0%.

Unit:

percentage© 2015 Open Geospatial Consortium

253

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Default:

0Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.3.23 End Junction ID (EJID)
Description:
A Junction Identification Number that is used to virtually connect
the end point of a lineal to another point, lineal or areal feature.
Lineal features stored in the same shape file having the same SJID or
EJID are connected. Lineal features stored in different shape files
having the same SJID or EJID as the JID listed in the corresponding
tile 2D relationship file are connected.
Identifier:

EJID

Code:

0022

Data Type:text numerals

Length:20 characters

Format:unsigned integer64 as character string

Range:

0 to (264 – 1)

Usage Note:

Mandatory for all features belonging to Topological Network
Datasets. Attribute is stored as a character string representing an
unsigned 64-bit number, and requires conversion back into
numerical representation by client reader. This is due to the 32-bit
limitation on integer values within dBASE files.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.24 Feature Attribute Classification Code (FACC)
Description:
This code used to distinguish and categorize features within adataset. The enumerated codes are listed in/CDB/Metadata/Feature_Data_Dictionary.xml.
Identifier:

FACC

Code:

0023

Data Type:text© 2015 Open Geospatial Consortium

254

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Length:5 characters

Format:two alpha characters following by three digits

Range:

N/A

Usage Note:

Mandatory

Unit:

N/A

Default:

None

Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.3.25 FACC Sub Code (FSC)
Description:
This code, in conjunction with the FACC is used to distinguish andcategorize features within a dataset. The enumerated codes are inaccordance to Appendix N.
Identifier:

FSC

Code:

0024

Data Type:numeric

Length:3 characters

Format:integer. Enumerated per Appendix N

Range:

0 to 999

Usage Note:

Mandatory

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.26 Gate ID (GAID)
Description:
A unique alphanumeric identifier (for the airport in question) that is
consistent with the IDENT attribute name within the NavData Gate
dataset. This ID is the value of the Gate Identifier of the Gate
dataset and can be used to extract additional information such as thegate position and bearing.
Identifier:

GAID© 2015 Open Geospatial Consortium

255

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Code:

0025

Data Type:alphanumeric

Length:6 characters

Format:N/A

Range:

N/A

Usage Note:

Recommended and Optional usages are per Table 5-27: Allocationof CDB Attributes to Vector Datasets. Typically used (but notlimited to) for models such as docking systems, marshallers andother models that are logically associated with a Terminal gate andthat require some level of control by the simulation application.

Unit:

N/A

Default:

None

Compatibility: CDB 3.1
5.7.1.3.27 Geomatics Extended Attribute Index (GEAI)
Description:
An index that points to a row entry of a Geomatics Extended
Attribution file for the current dataset. This entry permits users tostore an index to a link list set of Geomatics-specific attributes.
CDB-compliant devices are not mandated to read and interpret thisfield. Usage of this attribution is not portable to other simulators
because it falls outside of the documented CDB attribution scheme.
The Geomatics Extended Attribution file should be located in thesame directory as the instance-level attribution file. An empty GEAI
attribute is allowed. Note that the first entry in the Geomatics
Extended Attribution file has an index of 1.
Identifier:

GEAI

Code:

0026

Data Type:numeric

Length:6 characters

Format:integer

Range:

1 to 999,999© 2015 Open Geospatial Consortium

256

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Usage Note:

Optional. Use when Geomatics extended attribution is required. A“blank” or a value of 0 indicates that there are no Geomatics
Extended attributes.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0.
5.7.1.3.28 Height above Surface Level (HGT)
Description:
The height of a feature. If the feature has no modeled representation,
its height is measured as the distance from the surface level (groundor water) to the tallest point of the feature above the surface66. If thefeature has an associated 3D model, the height is measured as the
distance from the XY plane of the model to the highest point of themodel above that plane. HGT values are positive numbers.
Identifier:

HGT

Code:

0027

Data Type:numeric

Length:7 characters

Format:floating-point (recommended precision 4.2)

Range:

0.00 to 9999.99

Usage Note:

In the case of ground features, HGT refers to the portion of thefeature (or its modeled representation) that is meant to be above
ground. In the case of network lineal and areal features such as
roads, railroads, powerlines, or forest, HGT refers to the elevation of
the feature relative to the terrain in its immediate vicinity.

Unit:

metersDefault:

0.00

Compatibility: CDB 3.0

66

Surface here refers to the terrain in the immediate vicinity of the feature.

© 2015 Open Geospatial Consortium

257

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.29 Junction ID (JID)
Description:
A Junction Identification Number that is used to virtually connect apoint or an areal feature to another point, lineal or areal feature.
Features stored in the same shape file having the same JID areconnected. Features stored in different shape files having the same
JID as the JID listed in the corresponding tile 2D relationship file areconnected. When JID is associated to an areal feature, it necessarily
connects to the first point of the areal feature.
Identifier:

JID

Code:

0028

Data Type:text numerals

Length:20 characters

Format:unsigned integer64 as character string

Range:

0 to (264 – 1)

Usage Note:

Mandatory for all features belonging to Topological Network
Datasets. Attribute is used in 2D relationship file. Attribute isstored as a character string representing an unsigned 64-bit number,and requires conversion back into numerical representation by client
reader. This is due to the 32-bit limitation on integer values withindBASE files.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.30 Location Accuracy (LACC)
Description:
A precision value used to quantify the relative precision of the
Location point representing the specific GeoPolitical Location.
Identifier:

LACC

Code:

0029

Data Type:numeric

Length:3 characters

Format:integer© 2015 Open Geospatial Consortium

258

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Range:

0 to 999

Usage Note:

Optional. See Table 5-20: Location Accuracy Enumeration Values
for a list of accepted values.

Unit:meters.

Default:

0Compatibility: CDB 3.0

Table 5-20: Location Accuracy Enumeration Values

LACC Code Description0
Unknown
1
Better or equal to 10 m.
2
Better or equal to 100 m.
3
Better or equal to 250 m.
4
Better or equal to 500 m.
5
Better or equal to 1200 m.
6
Greater than 1200 m.
997
Unpopulated
998
Not Applicable
999
Other
5.7.1.3.31 Length of Lineal (LENL)
Description:
The length of a lineal. If the feature has been clipped to a tile
boundary, the length still gives the initial full length of the object
prior to the clipping operation, and if it belonged to a topologicalnetwork, LENL will represent the distance between the two closest
junction points encompassing this lineal segment. Note the Length
attribute is not used to define a bounding sphere associated to an
object, but rather to provide a weight to the relative length of thelineal as compared to others.
Identifier:

LENL

Code:

0030

Data Type:numeric

Length:6 characters© 2015 Open Geospatial Consortium

259

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Format:integer

Range:

0 to 999,999

Usage Note:

Mandatory for all networked lineal features. Length computation
should be account for the earth’s curvature.

Unit:

metersDefault:

None

Compatibility: CDB 3.0, SEDRIS (EA = 562)
5.7.1.3.32 Light Material Index (LMIX) – DeprecatedDescription:
Index into the Composite Material Table that is used to determine
the Light Material composition of the associated city illumination.
Represent the predominant material characterizing the major lightattributes of a populated area.
Identifier:

LMIX

Code:

0031

Data Type:numeric

Length:6 characters

Format:integer

Range:

0 to 999,999

Usage Note:

Optional. Applicable to Geopolitical Dataset areal features thatdelineate inhabited areas.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.33 Feature (or Location) Name (LNAM)
Description:
A toponym – a general term for any place or geographical entity.
The attribute is used to give a proper noun (a human readable name)to any feature from any vector dataset.
Identifier:

LNAM© 2015 Open Geospatial Consortium

260

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Code:

0032

Data Type:text

Length:32 characters

Format:lexicalRange:

N/A

Usage Note:

The use of LNAM goes from the name of a City to the name of aRoad, to the name of a Building, etc. Multiple names are possible
when using LNAM as an extended attribute. When more than one
name is provided, they must appear in order from the shortest nameto the longest one.

Unit:

N/A

Default:

Blank

Compatibility: CDB 3.0
5.7.1.3.34 Location Type (LOTY)
Description:
A value that uniquely attributes a location feature according to theenumerators found here.
Identifier:

LOTY

Code:

0033

Data Type:

Enumeration per Table 5-21: Location Type Enumeration Values

Length:3 characters

Format:integer

Range:

0 to 999

Usage Note:

Optional. Applicable to Geopolitical Dataset areal features. See
table below for a list of accepted values. Can be used only with
Location Point, Lineal or Areal Feature Datasets (which are part of
the Geopolitical Datasets)

Unit:

In cases where the location represents a bounded area, theapproximate geometric center is assumed.

Default:

0© 2015 Open Geospatial Consortium

261

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Compatibility: CDB 3.0.

Table 5-21: Location Type Enumeration Values

LOTY Code Description0
Unknown
1
Continent
2
Country3
State
4
Capital5
Province
6City
7
Municipality
997
Unpopulated
998
Not Applicable
999
Other
5.7.1.3.35 Light Phase (LPH)
Description:
Used for all light types that are periodic in nature (rotating, blink,
flashing, etc). The value of LPH controls the phase of the light
relative to all other lights that share the same LTYP. All other lightcharacteristics, including frequency and duration are implicitly
determined by the LTYP.
Identifier:

LPH

Code:

0034

Data Type:numeric

Length:3 characters

Format:integer

Range:

0 to 999

Usage Note:

Optional. In absence of a value, LPH defaults to a value of 0.

Unit:

thousands of a cycle

Default:000

Compatibility: CDB 3.0© 2015 Open Geospatial Consortium

262

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.36 Layer Priority Number (LPN)
Description:
A priority number that establishes the relative priority of overlapping
features. LPN establishes the order (starting from 0 for lowest
priority) by which overlapping features are processed by clientdevices.
Identifier:

LPN

Code:

0035

Data Type:numeric

Length:5 characters

Format:integer

Range:

0 to 32767

Usage Note:

Mandatory for terrain constraint features that overlap one another.
For all other features, it is optional. LPN is derived from priority
information stored and maintained by the authoring tools.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.37 Lane/Track Number (LTN)
Description:
The number of lanes on a road, tracks on railroad, or conductors on
powerlines, including both directions.
Identifier:

LTN

Code:

0036

Data Type:numeric

Length:2 characters

Format:integer

Range:

0 to 99 (Note: differs from DIGEST range of -32767 to 32768)

Usage Note:

Recommended for Road, RailRoad, and PowerLine Networkfeatures. Optional for Hydrography Network features.

© 2015 Open Geospatial Consortium

263

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Unit:

N/A

Default:

02 – for RoadNetwork lineal features

01 – for RailRoadNetwork lineal features
02 – for PowerLineNetwork lineal features
Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.3.38 Light Type (LTYP)
Description:
A unique code corresponding to a Light Type; Appendix E of thisSpecification provides the supported light types. The light types
follow a hierarchical organization provided by the light type naming
conventions described in Section 2.3, Light Naming. The Lights.xml
file establishes the correspondence between the LTYP code and theLight Type name.
Identifier:

LTYP

Code:

0037

Data Type:numeric

Length:4 characters

Format:integer

Range:

0 to 9999

Usage Note:

Mandatory for all Airport Light Point features, Environmental Light
Point features.

Unit:

N/A

Default:

0Compatibility: CDB 3.0
5.7.1.3.39 Model Level Of Detail (MLOD)
Description:
The level of detail of the 3D model associated with the point feature.
Identifier:

MLOD

Code:

0038

Data Type:numeric

Length:3 characters© 2015 Open Geospatial Consortium

264

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Format:integer

Range:-10 to 23

Usage Note:

When used in conjunction with MODL, the MLOD attributeindicates the LOD where the corresponding MODL is found. In thiscase, the value of MLOD can never be larger than the LOD of the
Vector Tile-LOD that contains it. When used in the context of
Airport and Environmental Light Point features, the value of MLOD,
if present, indicates that this lightpoint also exist in a 3D model
found at the specified LOD. In such case, the value of MLOD is notconstrained and can indicate any LOD.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.40 Moving Model DIS Code (MMDC)
Description:
A character string composed of the 7 fields of the DIS Entity Type.
Identifier:

MMDC

Code:

0039

Data Type:text

Length:maximum of 29 characters

Format:All seven fields of the DIS Entity Type separated by an underscorecharacter (“_”): 1_2_3_4_5_6_7

Range:

N/A

Usage Note:

Mandatory for Moving Model Location features

Unit:

N/A

Default:

None

Compatibility: CDB 3.0© 2015 Open Geospatial Consortium

265

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.41 Model Name (MODL)
Description:
A string reference, the model name, which stands for the modeled
geometry of a feature; in the case of buildings, this includes both its
external shell and modeled interior.
Identifier:

MODL

Code:

0040

Data Type:text

Length:32 characters

Format:per conventions described in Chapter 3, CDB Structure.

Range:

N/A

Usage Note:

Needed for Point features, Road Figure Point features, Railroad
Figure Point features, Pipeline Figure Point features andHydrography Figure Point features that are modeled as OpenFlightor as RCS (Shape). MODL can also be used with Road Lineal
features, Railroad Lineal features, Pipeline Lineal features andHydrography Lineal and Areal features. Note that it is not permitted
to specify a value for MODL simultaneously with a value for
MMDC.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.42 Model Type (MODT)
Description:
Indicates whether a feature is represented using a geotypical or
geospecific model. Together, the MODT, FACC, FSC, and MODL
attributes identify a unique model into the CDB.
Identifier:

MODT

Code:

0041

Data Type:text

Length:1 character

Format:“T” for geotypical, “S” for geospecific© 2015 Open Geospatial Consortium

266

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Range:

N/A

Usage Note:

Needed for features that are modeled as OpenFlight or as RCS(Shape).

Unit:

N/A

Default:”S”

Compatibility: CDB 3.0
5.7.1.3.43 Network Component Selector 1 (NCS1)
Description:
Code that is used to identify the component selector 1 file whichcontain the point, lineal, or areal feature that is virtually connected.
Identifier:

NCS1

Code:

0042

Data Type:numeric

Length:4 characters

Format:unsigned integer

Range:

0 to 9999

Usage Note:

Mandatory for Network datasets. Attribute is used in 2D relationship
file.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.44 Network Component Selector 2 (NCS2)
Description:
Code that is used to identify the component selector 2 file whichcontain the point, lineal, or areal feature that is virtually connected.
Identifier:

NCS2

Code:

0043

Data Type:numeric

Length:4 characters© 2015 Open Geospatial Consortium

267

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Format:unsigned integer

Range:

0 to 9999

Usage Note:

Mandatory for Network datasets. Attribute is used in 2D relationship
file.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.45 Network Dataset Code (NDSC)
Description:
Code that is used to identify the dataset code file which contain the
point, lineal, or areal feature that is virtually connected.
Identifier:

NDSC

Code:

0044

Data Type:numeric

Length:4 characters

Format:unsigned integer

Range:

0 to 9999

Usage Note:

Mandatory for Network datasets. Attribute is used in 2D
relationship file.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.46 Number of Instances (NIS) – DeprecatedDescription:
Number of instances found in the corresponding 3D model
associated with the cultural point feature.
Identifier:

NIS

Code:

0045

Data Type:numeric© 2015 Open Geospatial Consortium

268

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Length:6 characters

Format:integer

Range:

0 to 999,999

Usage Note:

Mandatory for features that are modeled as OpenFlight.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.47 Number of Indices (NIX) – DeprecatedDescription:
Number of Indices – Number of indices found in the corresponding
3D model associated with the cultural point feature.
Identifier:

NIX

Code:

0046

Data Type:numeric

Length:6 characters

Format:integer

Range:

0 to 999,999

Usage Note:

Mandatory for features that are modeled as OpenFlight.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.48 Number of Normals (NNL) – DeprecatedDescription:
Number of normal vectors found in the corresponding 3D model
associated with the cultural point feature.
Identifier:

NNL

Code:

0047

Data Type:numeric© 2015 Open Geospatial Consortium

269

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Length:6 characters

Format:integer

Range:

0 to 999,999

Usage Note:

Mandatory for features that are modeled as OpenFlight.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.49 Number of Texture Coordinates (NTC) – DeprecatedDescription:
Number of Texture Coordinates – Number of texture coordinates
found in the corresponding 3D model associated with the cultural
point feature.
Identifier:

NTC

Code:

0048

Data Type:numeric

Length:6 characters

Format:integer

Range:

0 to 999,999

Usage Note:

Mandatory for features that are modeled as OpenFlight.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.50 Number of Texel (NTX) – DeprecatedDescription:
Number of texels found in the corresponding 3D model associatedwith the cultural point feature.
Identifier:

NTX

Code:

0049

© 2015 Open Geospatial Consortium

270

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Data Type:numeric

Length:9 characters

Format:integer

Range:

0 to 999,999,999

Usage Note:

Mandatory for features that are modeled as OpenFlight.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.51 Number of Vertices (NVT) – DeprecatedDescription:
Number of Vertices – Number of vertices of the corresponding 3Dmodel associated with the cultural point feature.
Identifier:

NVT

Code:

0050

Data Type:numeric

Length:6 characters

Format:integer

Range:

0 to 999,999

Usage Note:

Mandatory for features that are modeled as OpenFlight.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.52 Population Density (POPD)
Description:
The number of inhabitants per square kilometer.
Identifier:

POPD

Code:

0051

© 2015 Open Geospatial Consortium

271

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Data Type:numeric

Length:5 characters

Format:integer

Range:

0 to 99999

Usage Note:

Applicable to Geopolitical features representing inhabited areas.

Unit:

Inhabitants per square kilometer

Default:

0Compatibility: CDB 3.0
5.7.1.3.53 Populated Place Type (POPT)
Description:
A value that uniquely represents the Populated Place Attribution
Type. This attribute should be used in conjunction with the BOTY
attribute when BOTY has an (enumerator) value of 13 whichcorresponds to “Populated Place”
Identifier:

POPT

Code:

0052

Data Type:

Enumeration per Table 5-22: Populated Place Type Enumeration
ValuesLength:3 characters

Format:integer

Range:

0 to 999

Usage Note:

Optional. Applies to Geopolitical Dataset areal features thatdelineate inhabited areas. See table below for a list of acceptedvalues.

Unit:

N/A

Default:

0Compatibility: CDB 3.0© 2015 Open Geospatial Consortium

272

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 5-22: Populated Place Type Enumeration Values

POPT Code Description0
Unknown
1
Native Settlement
2
Shanty Town
3
Tent Dwellings
4
Inland Village
5
Small City (less than 20,000 inhabitants)
6
Medium City (between 20,000 and 500,000 inhabitants)
7
Large City (more than 500,000 inhabitants)
997
Unpopulated
998
Not Applicable
999
Other
5.7.1.3.54 Relative TActical Importance (RTAI)
Description:
Provides the Relative TActical Importance of cultural features
relative to other features for the purpose of client-device scene/loadmanagement67. A value of 100% corresponds to the highest
importance; a value of 0% corresponds to the lowest importance.
When confronted with otherwise identical objects that differ only wrt
to their Relative TActical Importance, client-devices should always
discard features with lower importance before those of higher
importance in the course of performing their scene / load
management function. As a result, a value of zero gives complete
freedom to client-devices to discard the feature as soon as the load of
the client-device is exceeded. The effectiveness of scene / load
management functions can be severely hampered if large quantities
of features are assigned the same Relative TActical Importance by
the modeler. In effect, if all features are assigned the same value, theclient-devices have no means to distinguish tactically important
objects from each other. Assigning a value of 1% to all objects is
equivalent to assigning them all a value of 99%. Ideally, theassignment of tactical importance to features should be inaccordance to a histogram similar to the one shown here. The shapeof the curve is not critical, however the proportion of features taggedwith a high importance compared to those with low importance iscritical in achieving effective scene/load management schemes. It is
illustrated here to show that few features should have an importanceof 100 with progressively more features with lower importance. The
67

Note that the importance of the model can be further modified at run-time at the simulator console through thescenario importance value assigned to the model.

© 2015 Open Geospatial Consortium

273

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
assignment of the RTAI to each feature lends itself to database tools
automation. For instance, RTAI could be based on a look-up
function which factors the feature’s type (FACC or MMDC).

RTAI = f ( FACC _ or _ MMDC )The value of Relative TActical Importance should be accounted forby client-devices (in combination with other information) to
determine the appropriate distance at which the feature (and its
modeled representation, if available) should be rendered orprocessed. Relative TActical Importance is mandatory. It has nodefault value.

Figure 5-31: RTAI Typical Usage Histogram

Identifier:

RTAI

Code:

0053

Data Type:numeric

Length:3 characters

Format:integer

Range:

0 to 100

Usage Note:

Mandatory. All features should be tagged with an appropriate value
for the reasons stated above.

Unit:

Percentage

Default:

None

Compatibility: CDB 3.0© 2015 Open Geospatial Consortium

274

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.55 Runway ID (RWID)
Description:
An alphanumeric identifier that uniquely identifies a runway for agiven airport; this ID must match the value of the field Ident of the
Runway or Helipad dataset.
Identifier:

RWID

Code:

0054

Data Type:

Alphanumeric

Length:6 characters

Format:N/A

Range:

N/A

Usage Note:

Recommended for all Airport Light Points features. Failure toappropriately tag airport culture with RWID attribute will result in
reduced control of runway-related (or helipad) culture by simulator.
Optional for Point/Lineal/Areal features, Location Points Features,
Environmental Light Point features, and Moving Model Location
features that are associated with a runway and for which control of
the feature is desirable. The combination of RWID and APID points
to a unique record of the NavData Runway or Helipad dataset
components. Note that all of the lights and other features located invector datasets that are associated with the operation of a runway or
helipad are required to reference a runway or helipad in the NavData
dataset; the RWID attribute is not required for features unrelated to a
runway or helipad.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.56 Scaling (SCALx)
5.7.1.3.57 Scaling (SCALy)
5.7.1.3.58 Scaling (SCALz)
Description:
A set of scaling factors, one of the model axis, to be applied to therendering of model geometry by the client-device. A value of 1.0
instructs the client-devices to use the model as-is. The physical© 2015 Open Geospatial Consortium

275

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
dimension of models processed by client-device should approachzero, as SCALing tends to zero. The value of SCALing should also
be accounted for by client-devices (in combination with otherinformation) to determine the appropriate distance at which themodel should be paged-in, rendered or processed. All three
SCALing factors are optional. Values of zero and negative values
are not permitted.
Identifiers:

SCLAx, SCALy, SCALz

Codes:

0055, 0056, 0057

Data Type:numeric

Length:9 characters

Format:floating-point (recommended precision 3.5)

Range:

000.00001 to 999.99999

Usage Note:

Optional. CDB readers should default to a value of 1.0 if SCALx,
SCALy, or SCALz is missing.

Unit:

N/A

Default:

1.0

Compatibility: CDB 3.0
5.7.1.3.59 Start Junction ID (SJID)
Description:
A Junction Identification Number that is used to virtually connect
the start point of a lineal to another point, lineal or areal feature.
Lineal features stored in the same shape file having the same SJID or
EJID are connected. Lineal features stored in different shape files
having the same SJID or EJID as the JID listed in the corresponding
tile 2D relationship file are connected.
Identifier:

SJID

Code:

0058

Data Type:text numerals

Length:20 characters

Format:unsigned integer64 as character string© 2015 Open Geospatial Consortium

276

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Range:

0 to (264 – 1)

Usage Note:

Mandatory for all features belonging to Topological Network
Datasets. Attribute is stored as a character string representing an
unsigned 64-bit number, and requires conversion back into
numerical representation by client reader. This is due to the 32-bit
limitation on integer values within dBASE files.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0
5.7.1.3.60 Surface Roughness Description (SRD)
Description:
Describes the condition of the surface materials that may be used formobility prediction, construction material, and landing sites.
Identifier:

SRD

Code:

0059

Data Type:

Enumeration per Table 5-23: Surface Roughness Enumeration
ValuesLength:3 characters

Format:integer

Range:

0 to 999

Usage Note:

Recommended for Areal features.

Unit:

N/A

Default:

0Compatibility: CDB 3.0, DIGEST 2.1

Table 5-23: Surface Roughness Enumeration Values

SRD Code Description0
Unknown1
No surface roughness effect2
Area of high landslide potential© 2015 Open Geospatial Consortium

277

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
SRD Code Description
3
Uncohesive surface material/flat
4
Rough
5
Angular
6
Rounded11
Surface of numerous cobbles and boulders
12
Areas of stony terrain
13
Stony soil with surface rock14
Stony soil with scattered boulders
15
Stony soil with numerous boulders
16
Numerous boulders
17
Numerous rock outcrops
18
Area of scattered boulders
19
Talus slope
20
Boulder Field
31
Highly fractured rock surface
32
Weathered lava flows
33
Unweathered lava flows
34
Stony soil with numerous rock outcrops
35
Irregular surface with deep fractures of foliation
36
Rugged terrain with numerous rock outcrops
37
Rugged bedrock surface
38
Sand dunes
39
Sand dunes/low
40
Sand dunes/high41
Active sand dunes
42
Stabilized sand dunes
43
Highly distorted area, sharp rocky ridges
51
Stony soil cut by numerous gullies
52
Moderately dissected terrain
53
Moderately dissected terrain with scattered rock outcrops
54
Dissected floodplain
55
Highly dissected terrain
56
Area with deep erosional gullies
57
Steep, rugged, dissected terrain with narrow gullies
58
Karst areas of numerous sinkholes and solution valleys
59
Karst area of numerous sinkholes
60
Karst/hummocky terrain covered with large conical hills© 2015 Open Geospatial Consortium

278

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
SRD Code Description
61
Karst/hummocky terrain covered with low, broad-based mounds
62
Arroyo/wadi/wash
63
Playa/dry lake
64
Area of numerous meander scars and/or oxbow lakes
65
Solifluction lobes and frost scars
66
Hummocky ground, areas of frost heaving
67
Area of frost polygons
68
Area containing sabkhas
69
Area of numerous small lakes and ponds
70
Area of numerous crevasses
81
Area of numerous terraces
82
Quarries
83
Strip mines
84
Quarry/gravel pit
85
Quarry/sand pit
86
Mine tailings/waste piles
87
Salt evaporators
88
Area of numerous dikes
89
Area of numerous diked fields
90
Area of numerous fences
91
Area of numerous stone walls
92
Area of numerous man-made canals/drains/ditches
93
Area of numerous terraced fields
94
Parallel earthen mounds row crops
95
Area of numerous hedgerows
997
Unpopulated
998
Not Applicable
999
Other
5.7.1.3.61 Structure Shape Category (SSC)
Description:
Describes the Geometric form, appearance, or configuration of thefeature.
Identifier:

SSC

Code:

0060

Data Type:

Enumeration per Table 5-24: Structure Shape Category Enumeration
Values© 2015 Open Geospatial Consortium

279

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Length:3 characters

Format:integer

Range:

0 to 999

Usage Note:

Recommended for Point features, and all Network Lineal/Areal
Figure Points features.

Unit:

N/A

Default:

0Compatibility: CDB 3.0, DIGEST 2.1

Table 5-24: Structure Shape Category Enumeration Values

SSC Code Description0
Unknown1
Barrel, Ton
2
Blimp
3
Boat Hull (Float)
4
Bullet5
Reserved
6
Conical/Peaked/NUN
7
Cylindrical (Upright)/CAN
9
Reserved
10
Pillar/Spindle
11
Reserved
12
Pyramid
13
Reserved
14
Reserved
15
Solid/filled
16
Spar
17
Spherical (Hemispherical)
18
Truss
19
With Radome
20
Reserved
21
Artificial Mountain
22
Crescent
23
Ferris Wheel© 2015 Open Geospatial Consortium

280

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
SSC Code Description
24
Enclosed25
Roller Coaster
26
Lateral27
Mounds28
Ripple29
Star30Transverse
31
Reserved
32
Reserved
33
Reserved
34
Reserved
36
Windmotor
38
Reserved
40
Reserved
46
Open
52'A' Frame53'H' Frame
54'I' Frame56'Y' Frame
57
Reserved
58
Reserved
59
Telescoping Gasholder (Gasometer)
60
Mast
61
Tripod62
Reserved
63
Reserved
65
Cylindrical with flat top
66
Cylindrical with domed top
71
Cylindrical/Peaked
73
Superbuoy
74'T' Frame
75
Tetrahedron
76
Funnel77
Arch78
Multi-Arch
79
Round
80
Rectangular© 2015 Open Geospatial Consortium

281

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
SSC Code Description
81
Dragons Teeth
82
I-Beam83
Square84
Irregular
85
Diamond Shaped Buoy
86
Oval
87
Dome
88
Spherical with Column Support
89
Cylindrical or Peaked with tower support
90
High-Rise Building
91
Cylindrical
92
Cubic
93
Pole
94
Board
95
Column (Pillar)
96
Plaque97
Statue
98
Cross
107
Tower
108
Scanner109
Obelisk
110
Radome, Tower Mounted
997
Unpopulated
998
Not Applicable
999
Other
5.7.1.3.62 Structure Shape of Roof (SSR)
Description:
Describes the roof shape.
Identifier:

SSR

Code:

0061

Data Type:

Enumeration per Table 5-25: Structure Shape of Roof Enumeration
ValuesLength:3 characters

Format:integer© 2015 Open Geospatial Consortium

282

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Range:

0 to 999

Usage Note:

Recommended for Point features, and all Network Lineal/Areal
Point Figures.

Unit:

N/A

Default:

0Compatibility: CDB 3.0, DIGEST 2.1

Table 5-25: Structure Shape of Roof Enumeration Values

SSR Code Description0
Unknown
6
Conical/Peaked/NUN
38
Curved/Round (Quonset)
40
Dome
41
Flat
42
Gable (Pitched)
43
Reserved
44
Reserved
45
Reserved
46
Reserved
47
Sawtooth48
Reserved
49
Reserved
50
With Monitor
51
With Steeple
55
Flat with Monitor
58
Reserved
65
Gable with Monitor
65
Reserved
66
Reserved
71
Reserved
72
Reserved
77
With Cupola
78
With Turret
79
With Tower
80
With Minaret© 2015 Open Geospatial Consortium

283

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
SSR Code Description
997
Unpopulated
998
Not Applicable
999
Other
5.7.1.3.63 Traffic Flow (TRF)
Description:
Encodes the general destination of traffic.
Identifier:

TRF

Code:

0062

Data Type:numeric

Length:3 characters

Format:Integer. Enumerated per DIGEST 2.1. A few examples:

Range:

3:
One-way4:
Two-way
0 to 999

Usage Note:

Recommended on all Network Lineal (except PowerLines) features.

Unit:

N/A

Default:

003 – for RailRoadNetwork lineal features

004 – for other network lineal features
Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.3.64 Taxiway ID (TXID)
Description:
A unique alphanumeric identifier (for the airport in question).
Identifier:

TXID

Code:

0063

Data Type:alphanumeric

Length:6 characters

Format:N/A

Range:

N/A© 2015 Open Geospatial Consortium

284

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Usage Note:

Recommended usage and Optional usages are per table Table 5-27:
Allocation of CDB Attributes to Vector Datasets. Failure toappropriately tag airport culture with TXID attribute will result in
reduced control of taxiway-related culture by a simulation device.

Unit:

N/A

Default:

None

Compatibility: CDB 3.1
5.7.1.3.65 Urban Street Pattern (USP)
Description:
Describes the predominant geometric configuration of streets foundwithin the delineated area of the feature.
Identifier:

USP

Code:

0064

Data Type:

Enumeration per Table 5-26: Urban Street Pattern Enumeration
ValuesLength:3 characters

Format:integer

Range:

0 to 999

Usage Note:

Recommended for Areal features.

Unit:

N/A

Default:

0Compatibility: CDB 3.0, DIGEST 2.1

Table 5-26: Urban Street Pattern Enumeration Values

USP Code Description0
Unknown
2
Rectangular/Grid-Regular3
Rectangular/Grid-Irregular4
Curvilinear (cluster)
6
Concentric / Radial-Regular© 2015 Open Geospatial Consortium

285

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
USP Code Description
7
Concentric / Radial-Irregular9
Mixed-Curvilinear (cluster) and Rectangular (grid)
10
Mixed-Concentric / Radial and Rectangular (grid)
11
Mixed-Curvilinear (cluster) and Concentric / Radial
12
Reserved
13
Linear Strip
997
Unpopulated
998
Not Applicable
999
Other
5.7.1.3.66 Vendor Extended Attribute Index (VEAI)
Description:
An index that points to a row entry of a VendorExtended Attribution
file for the current dataset. This entry permits users to store an index
to a link list set of Vendor-specific attributes. CDB-compliant
devices are not mandated to read and interpret this field. Usage ofthis attribution is not portable to other simulators because it falls
outside of the documented CDB attribution scheme. The Vendor
Extended Attribution file should be located in the same directory as
the instance-level attribution file. An empty VEAI attribute isallowed. Note that the first entry in the Vendor Extended Attribution
file has an index of 1.
Identifier:

VEAI

Code:

0065

Data Type:numeric

Length:6 characters

Format:integer

Range:

1 to 999,999

Usage Note:

Optional. Use when Vendor extended attribution is required. A“blank” or a value of 0 indicates that there are no Vendor Extended
attributes.

Unit:

N/A

Default:

None

Compatibility: CDB 3.0.

© 2015 Open Geospatial Consortium

286

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.3.67 Width with Greater Than 1 meter Precision (WGP)
Description:
For lineal features (such as roads, railways, runways, taxiways),
WGP is a measurement of the shorter of two linear axes. For abridge, the width is the measurement perpendicular to the axis
between the abutments.
Identifier:

WGP

Code:

0066

Data Type:numeric

Length:9 characters

Format:floating-point (recommended precision 5.3)

Range:

0.000 to 99,999.999

Usage Note:

Recommended on all Network Lineal (except PowerLines) features.
When supplied for coastline, WGP corresponds to average width ofcoastline due to water height variations (such as tides) and wave
action.

Unit:

metersDefault:

None

Compatibility: CDB 3.0, DIGEST 2.1
5.7.1.4

Explicitly Modeled Representations

5.7.1.4.1 Referenced by Point Features
A point feature (whose position and attributes are stored in a Shapefile) can also refer to an
explicitly modeled representation.
A feature can point to an explicitly modeled representation of that feature that is stored in either
the GTModel library, the MModel library or alternately embedded inside a CDB tile. In order tospecify the modeled representation, the modeler must properly attribute the feature via the
MODL, MLOD, MMDC and MODT attributes in the vector dataset that contains the feature.
For Point features, the CDB supports two types of explicitly modeled representations:Z
OpenFlight models
Z
RCS Shapefile models
Natural vector features (such as trees, bushes) are usually represented by geotypical OpenFlightmodels. The majority of man-made features can also be geotypical in nature. For instance,
power pylons, telephone poles, or residential houses can all be represented with generic models© 2015 Open Geospatial Consortium

287

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
that are typical in appearance to the real-world objects they represent. The modeler need only
resort to a geospecific model if the application requires a model with the unique shape,
appearance and/or properties of the real-world object.
5.7.1.5
Implicitly Modeled Representations
An implicitly modeled representation is one that is defined completely by the supplied attributionof the Dataset in which it is contained. Examples of implicitly modeled features are light-points.
5.7.1.6
Handling of Topological Networks
The CDB provides several interconnected topological networks consisting of multiple datasets.
Each network dataset can be made of separate point features and or a series of points connected
together using lineal and areal features. Each lineal feature has a start and end nodes, whichcorrespond to intersections when connected to two or more other lineal features, or connections
when connected to an areal; the other intermediate points are used to accommodate deviationfrom a straight line. Typically, network datasets (such as roads, railroads) conform to theground; consequently, when the optional AHGT attribute is present, its value is set to false.
Each network dataset is stored as a distinct Shapefile.

1

4

7

2
5

3

6

8
Figure 5-32: Example of a Topological Network

The CDB Topological networks are useful when one needs to determine the shortest path
between two arbitrary nodes in the entire network; alternately, algorithms can use the network
topology in combination with a “cost” parameter based on length (in the case of shortest path),traffic speed (in the case of fastest path), or some other criteria that can be derived from theattribution information associated with the network datasets.
The CDB Topological networks are used for the following purposes:
To determine a route for features such as roads, rivers, railroads.
To follow a route made of roads, rivers, railroads.
To avoid an obstacle; for example a tank may not be able to cross a river or beable to go over or under a pipeline.
To efficiently process a “feature” for devices (such as radar) that do not
require a high definition of the geometrical representation or do not need torepresent more than one dimension.

© 2015 Open Geospatial Consortium

288

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The CDB Topological networks are optimized to facilitate road/river/railroad following tasks.
They support the notion of directionality such as one-way roads or both ways for two-way roads,
rivers. The vertex positions are physically positioned along the center of the feature’s
longitudinal axis; for example, a road such as a dual-lane undivided highway, the vertex data lies
along the stripes dividing the two lanes.
Features within the same or different network datasets are connected together using the junction
identifier attributes SJID, EJID or JID. Two or more features having the same identifier values
are considered virtually connected. This junction identifier allows, for instance, a primary roadto connect to a secondary road, or a river to connect a lake (in same network datasets), or toconnect a road and a river (in different network dataset). SJID, EJID or JID are mandatory
attributes for all topological network datasets. When not specified (i.e., blank), the feature is notconnected to any other features. Appendix A provides guidelines on how to generate thejunction identifiers.
Since the junction identifier is associated with a shape type feature, the following combinations
are supported:
Any point feature can be connected to any start or end point of a lineal feature(point to lineal connection), or to any start point of an areal feature (point toareal connection), using its JID attribute.
Any start point of a lineal feature can be connected to any point feature (point
to lineal connection), or to any start or end point of a lineal feature (lineal tolineal connection), or to any start point of an areal feature (lineal to areal
connection), using its SJID attribute.
Any end point of a lineal feature can be connected to any point feature (point
to lineal connection), or to any start or end point of a lineal feature (lineal tolineal connection), or to any start point of an areal feature (lineal to areal
connection), using its EJID attribute.
Any start point of an areal feature can be connected to any point feature (point
to areal connection), or to any start or end point of a lineal feature (lineal to
areal connection), using its JID attribute.
Connection information between two features located in two separate Shapefiles are explicitly
listed in 2D relationship files. This Specification currently supports two types of 2D relationshipfiles; the 2D relationship tile connection file which specifies connections of the same dataset
feature between two adjacent tiles, and the 2D relationship dataset connection file which
specifies connection of 2 or more different dataset and subdataset features within the same tile.
5.7.1.6.1 2D Relationship Tile Connection File
The CDB Topological network is broken into tiles and therefore must be clipped against tile
boundaries. To ensure the connectivity between tile boundaries of a lineal feature, the resulting
clipping point must share the same junction identifier (JID) in both tiles. This clipping point
potentially exists in several Tile-LODs having a common boundary; in which case, all points
representing the same clipping point share the same JID. Doing so ensures that connectivity
between geocells and tiles is preserved. A clipping point can be identified by the application by© 2015 Open Geospatial Consortium

289

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
checking the 2D relationship tile connection file. There is a 2D relationship tile connection file
per network dataset tile. When the file is missing, it indicates there is no clipping point for the
lineals belonging to the tile. The 2D relationship file is a dBASE file that contains a list ofrecords made of 2 attributes; the Junction ID (JID) that identifies the start or end point of theclipped lineal and the Network Component Selector 1 (NCS1) that identifies the network dataset
lineal file. The dataset code file is implicit to the network dataset tile directory and the Network
Component Selector 2 always represents a lineal feature Shapefile (code 003) thus do not require
to be included in the record. The coordinate of the tile adjacent to a clipping point can be
determined using the latitude and longitude of that point.
If a connection between two lineal features happens to be located exactly at a tile boundary, thelineal is obviously not clipped but a junction ID is allocated and included in the 2D relationshiptile connection file.
In a 2D relationship tile connection file, no two records are identical; however JIDs may appear
more than once with different NCS1, indicating a connection between network subdatasets.
5.7.1.6.2 2D Relationship Dataset Connection File
The CDB Topological network is made of several network datasets that in turn are made ofseveral ShapeFiles. By specifying a junction identifier per feature, any features in any of theseseveral ShapeFiles can in theory be connected to any other features located in a separate
Shapefile. A connection within a tile, which includes the tile boundaries, can be identified by theapplication by checking the 2D relationship dataset connection file. There is a 2D relationshipdataset connection file per network dataset tile. This file contains all the connections between
the subdatasets of the corresponding network dataset with other network datasets. When the fileis missing, it indicates there are no connections within the tile. The 2D relationship file is adBASE file that contains a list of records made of 4 attributes; the Junction ID (JID) that
identifies the connected point, lineal or areal features, the Network Dataset Code (NDSC) that
identifies the network dataset the feature belongs to, and the Network Component Selectors(NCS1 and NCS2) that identify the network subdataset and the shape type. The tile coordinate
and tile LOD is implicit to the Network Dataset tile directory.
All the records in the 2D relationship file are sorted per ascending JID. This has two advantages;
it speeds up the search process when looking for a specific JID and it groups all the features thatare connected together. In effect, there is always a minimum of two consecutive records with thesame JID; the record belonging to the corresponding file dataset (or subdataset) and the record
identifying the feature it connects to. Note that when a 2D relationship file specifies aconnection to a feature belonging to different network dataset, the corresponding LOD file ofthis dataset may or may not exist. If the corresponding LOD file of the target dataset is missing,
the application must look for the feature in the coarser LOD file of the target dataset. If thecorresponding LOD file of the target dataset exists, the feature may be missing because it has
been removed by the off-line tool decimation process; when this is the case, the application must
look for the feature in the finer LOD file of the target dataset.

© 2015 Open Geospatial Consortium

290

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.1.6.3 Junction Identifier (SJID, EJID, and JID) Range
This version of the Specification imposes that SJID, EJID and JID have unique values for all
network datasets within the same geocell. With a 64-bit range, it is practically impossible to run
out of ID number. In the process of creating the unique identifier, special care must be taken by
the off line tool in order to avoid duplicating the identifier at the geocell boundary for theclipping points when the modified or added features overlap two or more geocells.
Table 3-27, CDB LOD versus Feature Density, specifies the maximum number of elements in atile for vector datasets. This maximum number is not affected by the number of added clipping
point in a lineal feature. Although, this appears to lead to an unbounded number of points in afile, it is clamped to the geocell size. In practice, for a relative constant density, the number ofclipping points diminishes as the LOD number increases.
5.7.1.7
Handling of Light Points
All of the information that is needed to instantiate the light point features is organized inaccordance to the CDB terrain tile structure. Each instance of a light point feature refers to alight type defined by the CDB Specification via its shape attribution (LTYP). As a result, theentire definition of the light (i.e., its location, orientation and attributions) is self-contained
within the shape files.
The CDB Specification defines a collection of CDB Light Types that includes airport/runway
lighting systems, cultural lights, aircraft refueling systems, etc. The light types currently
supported by the CDB Specification are listed in Appendix E of this Specification; they are also
listed in Lights.xml as specified in Section 2.3, Light Naming. While the CDB Specification
provides a rigorous definition for each type of light, its representation is entirely determined by
the fidelity and the capabilities of client-devices.
5.7.1.8
Allocation of CDB Attributes To Vector Datasets
The CDB Specification limits the applicability of each of the CDB attributes to certain vector
datasets. This approach helps to reduce the number of columns (hence to reduce the size) of thedBase instance and class-level attribution files.
The allocation of CDB attributes to each of the Vector datasets is prescribed by Table 5-27
below.

© 2015 Open Geospatial Consortium

291

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

WGP

VEAI

USP

TRF

TXID

SSR

SSC

SRD

SJID

SCALz

SCALy

SCALx

RWID

RTAI

POPT

POPD

NDSC

NCS2

NCS1

MODT

MODL

MMDC

MLOD

LTYP

LTN

LPN

LPH

LOTY

LNAM

LENL

LACC

JID

HGT

GEAI

GAID

FSC

FACC

EJID

DMT

DMS

DMR

DML

DIR

DEP

DAMA

CNAM

CMIX

CEAI

BSR

BOTY

BBW

BBL

BBH

APID

AO1

AHGT

Table 5-27: Allocation of CDB Attributes to Vector Datasets

Feature Instance-level
Feature Class-level
Feature Extended-level

P P P P P P P P P P Y P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P PYY Y Y YY Y Y YY Y Y Y Y YY Y Y Y YYYY Y Y Y Y YYY Y Y Y Y Y Y YY Y Y Y Y Y YYY Y Y Y Y Y Y Y Y Y YY Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y YY Y Y Y Y Y Y Y Y Y YYGSFeature Dataset
Man Made Point
Man Made Lineal
Man Made Areal
Natural Point
Natural Lineal
Natural Areal
Tree Point
Airport Light Point
Airport Lineal
Airport Areal
Environmental Light Point

O
O
O
O
O
O
O
O
O
O
O

GTFeature Dataset
Man Made Point
Man Made Lineal
Man Made Areal
Tree Point
Tree Lineal
Tree Areal
Moving Model Location

O R
O
O
O R
O
O
O M

O O O OOOO O O OOOO O O O

O
O
O
O
O
O

O

GeoPolitical Dataset
Location Point
Location Lineal
Location Areal
Boundary Point
Boundary Lineal
Boundary Areal
Constraint Point
Constraint Lineal
Constraint ArealR O O O OOOR O O O OOOR O O O O
R R
R
R
R O

O

O
O
O

D O M
O M
O M
D O M
O M
O M
D O M
O M
O M
O M
O M

M
M
M
M
M
M
M
M
M
M
M

O
O
O
O
O
O
O
O
O
O
O

O
O R
O
O
O R
O
O

D O M
O M
O M
D O M
O M
O M
M O M

M
M
M
M
M
M
M

O
O
O
O
O
O
O

O
O R
O
O
O R
O
O

O O O R M OOO R M OOO R M OO O O R M OOO R M OOO R M O
O
O
O

R R

R

O R
O

R R

R R

R

O R R RO R R R

M M
M M
M M
M M
M M
M M
M M
M M
M M
M M
M M

O O D
O O R
O O R
O D
O R
O R
O D
R O O
O O R
O O R
O O O

O
O
O
O
O
O
O
O
O
O
O

M M O O D
M M O O R
M M O O R
M M
O D
M M
O R
M M
O R
O O M

O
O
O
O
O
O
O

M
M
M
M
M
M
M
M
M

M
M
M
M
M
M
M
M
M

O
O
O
O
O
O

O
O
O
O
O
O
O
O
O

O
O
O
O
O
O
O
O
O
O
O
O
O
O
O O O
O
O

M
M
M
M
O

O

M
M

M
M
M
M

O
O
O
O
O
O

O
O
O
O
O
O
O

M Mandatory

R Recommended

D Deprecated Attribution Schema

O Optional

D Dependent on other attribute

Y Allow ed Attribution Schema

D

O

D

O

D
M O

O

M O

D

O

D

O

M

M
M
M
M
M
M
M
M
M
M
M

M
M
M
M
M
M
M

O O M
M
O O M
O O M
M
O O M
M
M
M

P Preferred Attribution SchemaO O O O
O
O
O O O

R
O
O
O

O O O

R R O
O
O
O

R

O

O O O O
O
O
O O O

R R O
O
O
O

R

O

O
O
O
O
O
O

R

R

Not permitted
Not used

R
O
O
O

O

O
O
O
O
O
O

O
O R
R O
O
O R
O
O
O
O R
R O
O

O
O R
R O
O
O R
O
O

O
O R
R O
O
O R
R O
O
O M
O

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
(Cont’d on next page)

Feature Instance-level
Feature Class-level
Feature Extended-level
RoadNetwork Dataset
RoadNetwork Lineal
RoadNetwork Lineal Figure Pt
AirportNetwork Lineal
AirportNetwork Areal
Road/Airport Tile Connection
Road/Airport Dataset Connection
RailRoadNetwork Dataset
RailRoadNetwork Lineal
RailRoadNetwork Lineal Figure Pt
RailRoad Tile Connection
RailRoad Dataset Connection
PowerLineNetwork Dataset
PowerLineNetwork Lineal
PowerLineNetwork Lineal Figure Pt
PowerLine Tile Connection
PowerLine Dataset Connection
HydrographyNetwork Dataset
HydrographyNetwork Lineal
HydrographyNetwork Areal
HydrographyNetwork Lineal Figure Pt
HydrographyNetwork Areal Figure Pt
Hydrography Tile Connection
Hydrography Dataset Connection

WGP

VEAI

USP

TRF

TXID

SSR

SSC

SRD

SJID

SCALz

SCALy

SCALx

RWID

RTAI

POPT

POPD

NDSC

NCS2

NCS1

MODT

MODL

MMDC

MLOD

LTYP

LTN

LPN

LPH

LOTY

LNAM

LENL

LACC

JID

HGT

GEAI

GAID

FSC

FACC

EJID

DMT

DMS

DMR

DML

DIR

DEP

DAMA

CNAM

CMIX

CEAI

BSR

BOTY

BBW

BBL

BBH

APID

AO1

AHGT

Table 5-27: Allocation of CDB Attributes to Vector Datasets (Cont’d)

P P P P P P P P P P Y P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P PYY Y Y YY Y Y YY Y Y Y Y YY Y Y Y YYYY Y Y Y Y YYY Y Y Y Y Y Y YY Y Y Y Y Y YYY Y Y Y Y Y Y Y Y Y YY Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y YY Y Y Y Y Y Y Y Y Y YYORO R R O O O
O
R
O
R

O M
D O M
O M
O M
O
O

M
M
M
M
M
M

O
R
O R R O O O

O M
D O M
O
O

O
R
O R R O O OORORO R R O O OO R R O O O

O
O
O
O

O R
O D M
O R
O
O
M
O
M

M O
O
M O
O

R

M O O R
M O O
MM

M M M R O R
M M R O D M
O
M
O
M

M O
O

R

O M
D O M
O
O

M O O R
M O O
MM

M M M R O R
M M R O D M
O
M
O
M

M O
O

R

O M
O M
D O M
D O M
O
O

M
M
M
M
M
M

M M M
M M M
M M
M M

M O
O
O
O

R

O
O
O
O

O R
O
O R
O

M M
M
M M
M M

O R
O
O
O

M
M
M
M

R
R
R
R

R
R
R
R

O R
O
O D M
O D M
O
M
O
M

R

M Mandatory

R Recommended

D Deprecated Attribution Schema

O Optional

D Dependent on other attribute

Y Allow ed Attribution Schema© 2015 Open Geospatial Consortium

D
D
D

O
O
O
O

D
D
D
D

D
D

O D
O D

D
D

O D
O D

D

O
O
O
O

D
D

D
D
D
D

M
M M M

M
M M M

M
M M M

M
M M M

M
M
M
M

O M
O
O M
O M

R
R
R
R

R R
R
R R
R
R
R

O R
O
O R
O
O
O

M R O O O M
M R O O O

R
R

R R
R

O R
O
O
O

M R O O O M
M R O O O

R
R

R R
R

O R
O
O
O

M
M
M
M

R
R
R
R

R R
R
R
R

O R
O
O
O
O
O

P Preferred Attribution Schema

R
R
R
R

R
R
R
R

O
O
O
O

O
O
O
O

O
O
O
O

O
O
O
O

O M
O M
O
O

Not permitted
Not used293

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.2
Tiled Navigation Dataset
As described in section 5.2, the global navigation dataset is complemented by a tiled-based
dataset of basic navigation information that refers to the corresponding geocell. Those are foundin the \401_Navigation dataset which is subdivided into several components as listed in the nexttable.

Table 5-28: Tiled Navigation Dataset
CS1

CS2

File
Component
Extension
Name

Dataset 401, Navigation
001-046
001
*.shp
*.shx
*.dbf
*.dbt

Tiled
Navigation
DatasetComponent
Description
Contains the basic Navigation records

Refer to Table 5-3: List of Navigation Components, for a complete description of the possible
values of CS1.
5.7.2.1
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.2.2
Default Write Value
The files associated with this dataset for the area covered by the geocell need not be created if
the source data is not available.
5.7.3
Tiled GSFeature Dataset
A GSFeature is a geospecific (point, lineal, or areal) feature whose optional modeled
representation is also geospecific.
The GSFeature Dataset provides the position, size, orientation (points), shape (lineal and areals),
type and attribution of point, lineal, and areal features. It is subdivided into the following
components:
CS1 = 001: Man-made features
CS1 = 002: Natural features
CS1 = 003: Trees features
CS1 = 004: Airport features
CS1 = 005: Environmental lights
Table 5-29: Component Selectors for GSFeature Dataset lists all of the components of thedataset. The allocation of CDB attributes to each of the components is prescribed by Table 5-27:
Allocation of CDB Attributes to Vector Datasets.

© 2015 Open Geospatial Consortium

295

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
It is customary in many simulation applications to represent street lighting as points of lights; asa result, Airport and Environmental light points can be entirely described by their feature
position and attribution information and thus, do not have additional “modeled” data.
The modeling of geospecific trees is permitted when required to represent a specific geographic
area; however, it is understood that the majority of the times, geotypical trees will be sufficient.

Table 5-29: Component Selectors for GSFeature Dataset
001

002

003

004

005

CS1

CS2
001
002
016
003
004
017
005
006
018
001
002
016
003
004
017
005
006
018
001
002
016
001
002
016
003
004
017
005
006
018
001
002
016

Component Name

Man-made point features
Man-made point features class-level attributes
Man-made point features extended-level attributes
Man-made lineal features
Man-made lineal features class-level attributes
Man-made lineal features extended-level attributes
Man-made areal features
Man-made areal features class-level attributes
Man-made areal features extended-level attributes
Natural point features
Natural point features class-level attributes
Natural point features extended-level attributes
Natural lineal features
Natural lineal features class-level attributes
Natural lineal features extended-level attributes
Natural areal features
Natural areal features class-level attributes
Natural areal features extended-level attributes
Trees point features
Trees point features class-level attributes
Trees point features extended-level attributes
Airport light point features
Airport light point features class-level attributes
Airport light point features extended-level attributes
Airport lineal features
Airport lineal features class-level attributes
Airport lineal features extended-level attributes
Airport areal features
Airport areal features class-level attributes
Airport areal features extended-level attributes
Environmental light point features
Environmental light point features class-level attributes
Environmental light point extended-level attributes© 2015 Open Geospatial Consortium

296

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.3.1
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.3.2
Default Write Value
The files associated with this dataset for area covered by tile at a given LOD need not be created
if the source data is not available.
5.7.4
Tiled GTFeature Dataset
A GTFeature is a geotypical (point, lineal, or areal) feature whose optional modeled
representation is also geotypical.
The GTFeature Dataset provides the position, size, orientation (points), shape (lineal and areals),
type and attribution of point, lineal, and areal features. It is subdivided into the following
components:
CS1 = 001: Man-made features
CS1 = 002: Trees features
CS1 = 003: Moving model location features
Table 5-30: Component Selectors for GTFeature Dataset lists all of the components of thedataset. The allocation of CDB attributes to each of the components is prescribed by Table 5-27:
Allocation of CDB Attributes to Vector Datasets.
The Moving model location features component is used to permanently position moving models(e.g., position a row of parked tanks or aircrafts on a runway). When referenced and positioned
in this manner, these models cannot be moved and articulated during the simulation.

Table 5-30: Component Selectors for GTFeature Dataset
001

CS1

CS2
001
002
016
003
004
017
005
006
018

Component Name
Man-made point features
Man-made point features class-level attributes
Man-made point features extended-level attributes
Man-made lineal features
Man-made lineal features class-level attributes
Man-made lineal features extended-level attributes
Man-made areal features
Man-made areal features class-level attributes
Man-made areal features extended-level attributes© 2015 Open Geospatial Consortium

297

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

002

CS1

003

CS2
001
002
016
003
004
017
005
006
018
001
002
016

Component Name
Tree point features
Tree point features class-level attributes
Tree point features extended-level attributes
Tree lineal features
Tree lineal features class-level attributes
Tree lineal features extended-level attributes
Tree areal features
Tree areal features class-level attributes
Tree areal features extended-level attributes
Moving Model location features
Moving Model location features class-level attributes
Moving Model location features extended-level attributes

5.7.4.1
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.4.2
Default Write Value
The files associated with this dataset for area covered by tile at a given LOD need not be created
if the source data is not available.
5.7.5
Tiled GeoPolitical Feature Dataset
The GeoPolitical Feature dataset is used to provide information on the location, size and shape of
abstract locations, lines and areas with respect to the surface of the earth. Generally speaking, theobjects found in this dataset have no real-world physical representation (e.g., no physicalcharacteristics such as mass) and correspond to abstract concepts (such as airspace, country
boundary, danger zone).
The GeoPolitical Feature dataset is subdivided into the following components.

Table 5-31: Component Selectors for GeoPolitical Feature Dataset
CS1
001

CS2
001
002
016
003
004
017
005
006
018

Component Name
Boundary point features
Boundary point features class-level attribute
Boundary point features extended-level attribute
Boundary lineal features
Boundary lineal features class-level attribute
Boundary lineal features extended-level attribute
Boundary areal features
Boundary areal features class-level attribute
Boundary areal features extended-level attribute© 2015 Open Geospatial Consortium

298

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CS1
002

003

CS2
001
002
016
003
004
017
005
006
018
001
002
016
003
004
017
005
006
018

Component Name
Location point features
Location point features class-level attribute
Location point features extended-level attribute
Location lineal features
Location lineal features class-level attribute
Location lineal features extended-level attribute
Location areal features
Location areal features class-level attribute
Location areal features extended-level attribute
Constraint point features
Constraint point features class-level attribute
Constraint point features extended-level attribute
Constraint lineal features
Constraint lineal features class-level attribute
Constraint lineal features extended-level attribute
Constraint areal features
Constraint areal features class-level attribute
Constraint areal features extended-level attribute

5.7.5.1
Boundary and Location Features
GeoPolitical Areal features are essentially used for closed surface related attributions whereas
GeoPolitical Lineal features are used to model open areas as boundary delineations. Whencoarse specific locations are stored such as countries or cities, GeoPolitical Point features areused to locate the approximate geometric center of the related feature.
Some less-commonly used features could be 1) GeoPolitical Boundaries stored as Point features,or 2) GeoPolitical Locations stored as Lineals or Areals. The first case could be used torepresent a simple boundary consisting of a single radius as given by the Point feature. The
second case could be used to represent a city location with detailed Areal or Lineal vertices.
Figure 5-33: Example of International Boundaries, Figure 5-34: Example of City Locations, andFigure 5-35: Example of State Capital Locations and Time Zone Boundaries, all depict somesample cases where the GeoPolitical Feature dataset components can be used for.

© 2015 Open Geospatial Consortium

299

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-33: Example of International Boundaries

Figure 5-34: Example of City Locations© 2015 Open Geospatial Consortium

300

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 5-35: Example of State Capital Locations and Time Zone Boundaries

5.7.5.2

Elevation Constraint Features

There are many instances where modelers may wish to take advantage of the availability ofposition and altitude of cultural features in order to locally control the terrain elevation data at apoint, along a specified contour line or within a given area. This operation is usually performed
off-line by the modeler and requires that the Elevation dataset be edited and re-generated offline.
In addition to this approach, the CDB Specification provides a Constraint Features component to
the GeoPolitical Feature dataset, whose vector data is designed to instruct client-devices toruntime-constrain the Elevation dataset to a set of prescribed elevation values (thereby obviating
the need to offline re-generate the Elevation dataset). At runtime, client-devices are required toapply the elevation constraints to the selected Terrain Elevation component of the Elevation
dataset. The Constraint Features component provides modelers the ability to accurately control
terrain elevation profiles even if the Elevation dataset consists in a uniform grid of modest
resolution. Each of these features is associated with vertices which define elevation at the
supplied geographic coordinates. This approach approximates Terrain Irregular Networks(TINs). The Constraint Features have the following Feature Attribute Codes (FACCs):
Elevation Constraint Point (CA099-000): In the case of PointZ and MultiPointZ
features, the points are used by the client-device to control the terrain elevation.
The Feature’s AHGT attribute must be set to TRUE. Shapefile features
implemented as Point, PointM, MultiPoint, and MultiPointM are ignored.
Elevation Constraint Line (CA099-001): In the case of PolyLineZ features, thelines are used by the client-device to control the terrain elevation. The Feature’s© 2015 Open Geospatial Consortium

301

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
AHGT attribute must be set to TRUE. Shapefile features implemented as
PolyLine and PolyLineM are ignored.
Elevation Constraint Area (CA099-002): In the case of PolygonZ andMultiPatch features, the areas are used by the client-device to control the terrain
elevation. The Feature’s AHGT attribute must be set to TRUE. Shapefile
features implemented as Polygon and PolygonM are ignored.
The Data Dictionary of CDB Specification also makes provision for the representation of many
hypsography features within the Geopolitical Dataset (e.g., contour lines, ridge lines, valleylines, spot elevation). By virtue of their semantics, these features have no associated modeled
representation. The modeler can use these hypsography features to control the generation of the
Terrain Elevation grid during the off-line CDB compilation process. This terrain constraining
operation can be performed as the CDB is “assembled and compiled” by the SE tools. Note thatruntime client-devices are not required to constrain the Terrain Elevation Dataset to hypsography
features. When performed off-line, hypsography features must have AHGT set to True, thereby
instructing the SE Tools to constrain the terrain elevation using the supplied (latitude, longitude,and elevation) coordinates. The Shapefile feature must be of type PointZ, MultiPointZ,
PolyLineZ, PolygonZ, or MultiPatch.
While hypsography features can be used by the off-line tools to control the terrain skinning
process, these features can be instead converted into Constraint Features, thereby deferring theterrain constraining process to runtime client-devices. This provides modelers the ability toaccurately control terrain elevation profiles even if the Elevation dataset consists in a uniform
grid of modest resolution. In effect, the Constraint Features provides a storage-efficient meansof capturing terrain contours without having to revert to high resolution terrain grids.
The application of constraint features to uniform and non-uniform gridded terrain elevation
dataset is discussed in Appendix A.
5.7.5.3
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.5.4
Default Write Value
The files associated with this dataset for area covered by tile at a given LOD need not be created
if the source data is not available.
5.7.6
Tiled RoadNetwork Dataset
The RoadNetwork Dataset is used to specify all of the road40 networks. The points that make up
the RoadNetwork lineals are primarily used to establish the road network topology. However,40

Within the context of the CDB, the term road encompasses a broad gamut of networks implemented as long,narrow stretch of smoothed or paved surfaces, made for traveling by foot, motor vehicle, carriage, etc., between two
or more points. Examples of road networks are highways, interstates, roads, boulevards, streets, etc. It excludes
railways.

© 2015 Open Geospatial Consortium302

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
additional points can be used to more accurately define the actual path of the RoadNetwork
lineals between each of the junction points of the network; alternately, points can be used toprecisely specify the position of features along the RoadNetwork lineal. The altitude of eachpoint is optional and specifies the ground level when present.
It is possible to associate an explicitly modeled representation (via the MODL and MODT
attributes) to each RoadNetwork lineal. When provided, client-devices should instantiate themodeled representation for each point along the RoadNetwork lineal. Alternately, it is possible
to specify a distinct modeled representation for each point along the RoadNetwork lineal featureby assigning a distinct RoadNetwork Figure Point to each point of the RoadNetwork lineal
feature.
Table 5-32: Component Selectors for RoadNetwork Dataset lists all of the RoadNetwork Dataset
components. The allocation of CDB attributes to each of the RoadNetwork dataset components
is prescribed by Table 5-27: Allocation of CDB Attributes to Vector Datasets.

Table 5-32: Component Selectors for RoadNetwork Dataset
CS1
001
002

003

CS2
011
015
003
004
017
007
008
019
003
004
017
005
006
018

Component Name
Road/Airport Network Tile Connection 2D relationship
Road/Airport Network Dataset Connection 2D relationshipRoad Network lineal features
Road Network lineal features class-level attributes
Road Network lineal features extended-level attributes
Road Network lineal figure point features
Road Network lineal figure point class-level attributes
Road Network lineal figure point extended-level attributes
Airport Network lineal features
Airport Network lineal features class-level attributes
Airport Network lineal features extended-level attributes
Airport Network areal features
Airport Network areal features class-level attributes
Airport Network areal features extended-level attributes

5.7.6.1
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.6.2
Default Write Value
The files associated with this dataset for area covered by tile at a given LOD need not be created
if the source data is not available.

© 2015 Open Geospatial Consortium

303

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.7
Tiled RailRoadNetwork Dataset
The RailRoadNetwork Dataset is used to specify all of the railroad41 networks. The points thatmake up the RailRoadNetwork lineals are primarily used to establish the railroad network
topology. However, additional points can be used to more accurately define the actual path of
the RailRoadNetwork lineals between each of the junction points of the network; alternately,
points can be used to precisely specify the position of features along the RailRoadNetwork
lineal. The altitude of each point is optional and specifies the ground level when present.
It is possible to associate an explicitly modeled representation (via the MODL and MODT
attributes) to each RailRoadNetwork lineal. When provided, client-devices should instance themodeled representation for each point along the RailRoadNetwork lineal. Alternately, it ispossible to specify a distinct modeled representation for each point along the RailRoadNetwork
lineal feature by assigning a distinct a RailRoadNetwork Figure Point to each point of the
RailRoadNetwork lineal feature.
Table 5-33: Component Selectors for RailRoadNetwork Dataset lists RailRoadNetwork Dataset
components. The allocation of CDB attributes to each of the RailRoadNetwork dataset
components is prescribed by Table 5-27: Allocation of CDB Attributes to Vector Datasets.

Table 5-33: Component Selectors for RailRoadNetwork Dataset
CS1
001
002

CS2
011
015
003
004
017
007
008
019

Component Name
RailRoad Network Tile Connection 2D relationship point
RailRoad Network Dataset Connection 2D relationship point
RailRoad Network lineal features
RailRoad Network lineal features class-level attribute
RailRoad Network lineal features extended-level attribute
RailRoad Network lineal figure point features
RailRoad Network lineal figure point class-level attribute
RailRoad Network lineal figure point extended-level attribute

5.7.7.1
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.7.2
Default Write Value
The files associated with this dataset for area covered by tile at a given LOD need not be created
if the source data is not available.

41

Within the context of the CDB, the term railroads encompasses a broad gamut of networks implemented as roads
that are composed of parallel steel rails supported by ties and providing a track for locomotive-drawn trains or otherwheeled vehicles.

© 2015 Open Geospatial Consortium

304

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.8
Tiled PowerLineNetwork Dataset
The PowerLineNetwork Dataset is used to specify powerline42 networks. The points that makeup the PowerLineNetwork lineals are primarily used to establish the network topology.
However, additional points can be used to more accurately define the actual path of thePowerLineNetwork lineals between each of the junction points of the network; alternately, points
can be used to precisely specify the position of the poles, pylons, etc. of the PowerLineNetwork
lineal. The altitude of each point is optional and specifies the ground level when present.
It is possible to associate an explicitly modeled representation (via the MODL and MODT
attribute) to each PowerLineNetwork lineal. When provided, client-devices should instance themodeled representation for each point along the PowerLineNetwork lineal. Alternately, it ispossible to specify a distinct modeled representation for each point along the PowerLineNetwork
lineal feature by assigning a distinct a PowerLineNetwork Figure Point to each point of thePowerLineNetwork lineal feature. Allowed model representations are as per Section 5.7.1.4,
Explicitly Modeled Representations. In that case of wired- or cabled-networks, the model must
include the wire Attach Points43. Note also that client-devices are also required to automaticallyorient each instance of the modeled representation along the path of the PowerLineNetwork
lineal. In the case where the entrance and exit angles are not identical, the orientation should be
the average of both.
Table 5-34: Component Selectors for PowerLineNetwork Dataset, lists all of thePowerLineNetwork Dataset components. The allocation of CDB attributes to each of thePowerLineNetwork dataset components is prescribed by Table 5-27: Allocation of CDB
Attributes to Vector Datasets.

Table 5-34: Component Selectors for PowerLineNetwork Dataset
CS1
001
002

CS2
011
015
003
004
017
007
008
019

Component NamePowerLineNetwork tile connection 2D relationship point
PowerLineNetwork dataset connection 2D relationship point
PowerLineNetwork lineal features
PowerLineNetwork lineal features class-level attribute
PowerLineNetwork lineal features extended-level attribute
PowerLineNetwork lineal figure point features
PowerLineNetwork lineal figure point class-level attribute
PowerLineNetwork lineal figure point extended-level attribute42

Within the context of the CDB, the term powerline encompasses a broad gamut of networks implemented throughthe use of wires, cables and/or pipes.
43

Note that wires are not explicitly modeled in the CDB. As a result, client-devices are required to automaticallymodel them when rendering PowerLineNetwork lineal features. Such modeling can be achieved using a principle
known as the catenary, which is the shape of a perfectly flexible chain suspended by its ends and which ischaracterized solely by the gravity action.

© 2015 Open Geospatial Consortium

305

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5.7.8.1
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.8.2
Default Write Value
The files associated with this dataset for area covered by tile at a given LOD need not be created
if the source data is not available.
5.7.9
Tiled HydrographyNetwork Dataset
The HydrographyNetwork Dataset is used to specify hydrography44 networks. The points thatmake up the HydrographyNetwork lineals are primarily used to establish the network topology.
However, additional points can be used to more accurately define the actual path of theHydrographyNetwork lineals between each of the junction points of the network; alternately,
points can be used to precisely specify the position of models of the HydrographyNetwork lineal.
The altitude of each point is optional and specifies the ground level when present.
It is possible to associate an explicitly modeled representation (via the MODL and MODT
attributes) to each HydrographyNetwork lineal. When provided, client-devices should instancethe modeled representation for each point along the HydrographyNetwork lineal. Alternately, it
is possible to specify a distinct modeled representation for each point along theHydrographyNetwork lineal feature by assigning a distinct a HydrographyNetwork Figure Point
to each point of the HydrographyNetwork lineal feature. Allowed model representations are as
per Section 5.3.1.4, Explicitly Modeled Representations.
Table 5-35: Component Selectors for HydrographyNetwork Dataset lists all of the componentsof the HydrographyNetwork dastaset. The allocation of CDB attributes to each of theHydrographyNetwork dataset components is prescribed by Table 5-27: Allocation of CDB
Attributes to Vector Datasets.

Table 5-35: Component Selectors for HydrographyNetwork Dataset
CS1
001
002

CS2
011
015
003
004
017
005
006
018
007

Component Name
HydrographyNetwork tile connection 2D relationship point
HydrographyNetwork dataset connection 2D relationship point
HydrographyNetwork lineal features
HydrographyNetwork lineal features class-level attribute
HydrographyNetwork lineal features extended-level attribute
HydrographyNetwork areal features
HydrographyNetwork areal features class-level attribute
HydrographyNetwork areal features extended-level attribute
HydrographyNetwork lineal figure point features

44

Within the context of the CDB, the term hydrography encompasses a broad gamut of natural and man-madebodies of water such as oceans, lakes, rivers, canals, etc.

© 2015 Open Geospatial Consortium

306

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
008
019
009
010
020

HydrographyNetwork lineal figure point class-level attribute
HydrographyNetwork lineal figure point extended-level attribute
HydrographyNetwork areal figure point features
HydrographyNetwork areal figure point class-level attribute
HydrographyNetwork areal figure point extended-level attribute

5.7.9.1
Default Read Value
Simulator client-devices should assume an empty tile when data is not available.
5.7.9.2
Default Write Value
The files associated with this dataset for area covered by tile at a given LOD need not be created
if the source data is not available.
5.7.10Tiled Vector Composite Material Table (VCMT)The Vector Composite Material Table (VCMT) provides a list of the Composite Materials sharedby all vector datasets. There is one VCMT for each CDB Geocell.

Table 5-36: Vector Composite Material Table Component
File
Dataset Component
ExtensioNamenDataset 200, VectorMaterial
001
001
*.xml
Vector Composite
Material Table(VCMT)
CS1

CS2

Dataset Component Description
The VCMT can be referenced by the CMIX
attribute of the following datasets:
100_GSFeature
101_GTFeature
102_GeoPolitical
201_RoadNetwork
202_RailRoadNetwork
203_PowerLineNetwork
204_HydrographyNetwork

5.7.10.1 Data TypeThe Vector Composite Material Table follows the XML syntax described in Section 2.5.2.2,
Composite Material Tables (CMT).
5.7.10.2 Default Read Value
The default values for the Vector Composite Material Table (Default_Material_Layer) can befound in \CDB\Metadata\Defaults.xml and can be provided to the client-devices on demand. If
the default information cannot be found within the \CDB\Metadata\Defaults.xml file, the CDB© 2015 Open Geospatial Consortium

307

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Specification recommends defaulting to single substrate composite material whose base material
is Default_Base_Material (BM_LAND-MOOR).
5.7.10.3 Default Write Value
The files associated with the Vector Composite Material Table for the area covered by a tile at agiven LOD need not be created if the source data is not available. Tiles partially populated withdata are not permitted.
5.8

Tiled Model Datasets

5.8.1
Tiled GSModel Datasets
Table 5-37: Component Selectors for GSModel Datasets provides the dataset codes, the fileextension types and associated component selector values of GSModels geometry,
GSModelInteriors geometry and their associated Composite Material Tables.

Table 5-37: Component Selectors for GSModel Datasets
File
Component
Component
Extension
Name
Description
Dataset 300, GSModelGeometry
Dateset 305, GSModelInteriorGeometry
001
001..999*.flt
Individual One OpenFlight file containing the geometry of theGeometry shell or multiple files to represent the interior of a
GSModel as described in Chapter 6.
001
001
*.zip
Geometry One archive regrouping individual model geometry
Archive
OpenFlight files of a Tile-LOD.
Dataset 303, GSModelDescriptor
Dataset 307, GSModelInteriorDescriptor
001
001
.xml
Individual Provides the metadata associated with individual
Descriptor GSModels. See section 6.14, Metadata, for a
description of the content.
CS1

001

CS2

001

.zip

Descriptor
Archive

Dataset 301, GSModelTexture
Dataset 306, GSModelInteriorTexture*.rgb
Individual
TextureNOTE: A model descriptor includes a Composite
Material Table for the exclusive use by its
corresponding model geometry datasets above.
This CMT is not to be confused with the
GSModelCMT dataset below.
An archive of all model descriptors of a Tile-LOD.

Individual base and subordinate textures applied on
individual or tiled models of a Tile-LOD, see thecomplete list in section 5.3, CDB Model Textures.

© 2015 Open Geospatial Consortium

308

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
File
Component
Component
Extension
Name
Description
001
001
*.zip
TextureAn archive of all base and subordinate textures of aArchive
Tile-LOD.
Dataset 304, GSModelMaterial
Dataset 308, GSModelInteriorMaterial001
001..255*.tif
Composite Each texel is an index into the GSModelCMT.
Component selector 2 is the layer number.
Material
Index
002
001..254*.tif
Composite Each texel indicates the proportion (between 0.0
and 1.0) of the composite material found in the
Materialcorresponding material layer. Component Selector
Mixture2 is the layer number. When the texels are of
integral types, they are scaled to the range 0.0 to
1.0.
001
001
*.zip
Composite An archive of all layers of indices and mixtures of a
Tile-LOD.
Material
Archive
Dataset 309, GSModelCMT
001
001
*.xml
Composite Provides a local Composite Material Table per
Material
geocell; it contains the definition of the composite
Tablematerials referenced by the model material datasets
above. Its format is as specified in section 2.5.2.2,
Composite Material Tables (CMT)
CS1

CS2

5.8.2
Tiled T2DModel Datasets
Table 5-38 provides the component selectors for the T2DModel datasets.

Table 5-38: Component Selectors for T2DModel Datasets
File
Component
Component
Extension
Name
Description
Dataset 310, T2DModelGeometry
001
001
*.flt
Model
One OpenFlight file containing the geometry of theGeometry T2DModel of a Tile-LOD. The content of the file
is explained in Chapter 6.
CS1

CS2

© 2015 Open Geospatial Consortium

309

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 6
6
CDB OpenFlight Models
This portion of the CDB Specification defines a set of conventions to represent 2D and 3Dmodels based on version 16.0 of the OpenFlight Scene Description Database Specification as
annotated in Appendix C.
The conventions presented here address the needs of several types of simulation clients including
OTW, FLIR, NVG, CGF, radar, and laser, acoustic, magnetic, visual and thermal sensors.
6.1
OpenFlight File Header
The OpenFlight Header Record contains descriptive metadata about the manner vertices are
encoded, and how these vertices are applied to an earth model and a projection type. On theother hand, the CDB Specification itself mandates a prescribed set of conventions in this regard;
as a result; the following OpenFlight Header records must be set as follows:
Projection Type:o Flat Earth, value 0: This is the type of projection used by most CDB Models,
GTModel, GSModel, and MModel.
o Geodetic, value 5: This is the type of projection used by T2DModels.
Earth Ellipsoid Model:
o WGS-84, value 0: This is the Earth model to use with T2DModels. The fieldis ignored with other CDB Models.
6.2
OpenFlight Model Tree Structure
The internal structure of OpenFlight models is a tree structure that consists of nodes having childnodes as well as sibling nodes45. This type of tree structure is called a directed acyclic graph, orDAG. The general tree structure of a Model resembles that of Figure 6-1: General OpenFlight
Tree Structure.

45

In Appendix C, the section called Database Hierarchy explains in details how OpenFlight organizes its graph.

© 2015 Open Geospatial Consortium

311

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Headernode

Groupnode 1

LOD
node 1

DOF
node 1

Objectnode 1

LOD
node 2

Objectnode 3

DOF
node 2

Switchnode

Objectnode 4

Light
Point

Objectnode 2

Figure 6-1: General OpenFlight Tree Structure

The CDB Specification uses Group Nodes to arrange Models in a hierarchical manner. This wayof organizing models helps identify components of interest.
The CDB Specification refers to a number of OpenFlight nodes to store meaningful data forsimulation client-devices. For a complete list of nodes supported by the CDB Specification, see
Appendix C. The nodes listed here are the ones referred to by one or more CDB conventions.
An example of an ancillary record is the OpenFlight comment record. A comment record may
appear once, anywhere after a node’s primary record. The CDB Specification relies on comment
records to extend the definition of OpenFlight nodes. Instead of using the Extension Record tocreate new primary and ancillary records, the CDB Specification uses comments to store theextra attributes required by the specialization of existing OpenFlight nodes46. Comment records
were chosen over OpenFlight extensions in order to minimize any changes to the Creator tool or
the need to develop a plug-in to Creator. Using this approach, anybody can create CDBcompliant models using a plain version of Creator. Nevertheless, the development of Creator
CDB plug-ins would improve modeler’s efficiency. Such plug-ins could, for instance, offer a
46

CDB-compliant readers must ignore all OpenFlight extension records.

© 2015 Open Geospatial Consortium

312

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
menu-based GUI to allow modelers to enter and edit CDB comments, while ensuring that syntax
and conventions are fully adhered to.
The text contained in the comment record is formatted using the XML notation.
6.2.1
CDB Model Tree Structure
Based on Figure 6-1 above, the internal structure of CDB Models resemble this one:db

Global
Zone

Other
nodes

...

Figure 6-2: Internal Structure of CDB Models

All CDB Models have a global zone as their root node. This node identifies the model. Global
zones are defined in section 6.5.2 below.
6.2.2
T2DModel Tree Structure
A T2DModel being a collection of 2DModels, each individual 2DModel occupies its own
subtree of the graph. The general structure of a T2DModel is as follow:© 2015 Open Geospatial Consortium

313

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014db

Global
Zone

Zone

...

Group

...

Group

...

Mesh

2DModel #1

Group
Layer #0

Layer #1

Zone

2DModel #nLayer #n

LOD

(Optional)

ObjectFace(Conformal)

Mesh
#1

#n

Figure 6-3: Internal Structure of T2DModels

Each 2DModel is implemented as a Model Zone (section 6.5) with its own subgraph. 2DModels
are disjoint and non-overlapping. A 2DModel is comprised of multiple layers; the layer number
is expressed by the group’s relative priority (section 6.3.4). Each layer has an optional LOD
node followed by a fixed hierarchy of regular OpenFlight Object, Face, and Mesh nodes.

© 2015 Open Geospatial Consortium

314

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.2.2.1
Restrictions
T2DModels being an alternate representation of the terrain and its imagery and materials, anumber of restrictions are necessary to ensure client devices can consume the dataset efficiently.
1. A 2DModel has at least two layers, layer 0 and layer 1.
2. Layer 0 is always empty because it represents the terrain on top of which
subsequent layers are applied.
3. Each layer is composed of exactly one OpenFlight Object node.
4. All Face and Mesh nodes share exactly the same set of graphic attributes(color, textures, material, and other flags). Stated differently, the Face andMesh nodes provide the shape of the layer while the Object node controls its
appearance.
5. Subfaces are not permitted because coplanar geometry is implemented
through layers.
6.2.2.2
Node Attributes
For T2DModels, node attributes (section 6.12) are permitted only at the zone levels; that is, at
the global zone or at the individual 2DModel zones. Node attributes are not permitted at theGroup, LOD, Object, Face, and Mesh node levels.
6.2.3
The Use of Node Names
Although the CDB Specification defines naming conventions for objects stored in an OpenFlight
file, the Specification does not constrain the OpenFlight node names themselves. Instead, the
CDB Specification defines names that are assigned via XML tags stored in the comment record.
The following question arises, “Why not establish a set of CDB conventions around node
names?” The answer lies primarily around constraints imposed by tools used to edit/create
OpenFlight files. Tools such as Creator require unique node names throughout the OpenFlight
file. The OpenFlight format Specification itself does not state that node names must be unique;however, a tool such as Creator prevents the modeler from entering the same node name twice.
To circumvent this limitation, the CDB Specification provides naming conventions throughXML tags inserted in the comment record following a node’s primary record. This way of doing
things leaves modelers with the needed freedom in naming nodes. The CDB Specification
defines how to organize a model; all extra object attributes that do not fit in the current
OpenFlight records are stored in the comment record, including object names.
Here is an example of XML tags stored in the comment record for a Group Node.

© 2015 Open Geospatial Consortium

315

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-1: Sample XML Tag Used in a Comment Record<CDB:Zone
name = "zone name"/>

All XML tags defined by the CDB Specification belong to a single XML namespace that is
appropriately named CDB47.
6.2.4
Model Master File
A Model Master file is an OpenFlight file that contains only external references to other
OpenFlight files. The purpose of the master file is to ensure a Model is seen as a single “object”
even though its constituents are stored in separate files. The use of a model master file provides
a convenient means for modelers to reference all of the constituent files that make up the model.
There is no other purpose associated to the master file.
As of version 3.1 of the Specification, the concept of a Model Master file is used in a single case,to regroup all representations (all LODs) of a geotypical model into a single OpenFlight file.
However, the concept applies to all types of CDB Models. The concept can also be used toregroup a model’s shell with its interior. For this reason, expect new usage of the Model master
file in future version of the Specification.
The master file is useful in two circumstances: when modelers create or edit Models, and whenclient devices want to discover at once all constituents of Models.
For modelers, it is useful (if not required) to edit a model using a single source file to present a
coherent view of the model as a whole. For this reason, a master file with a set of LOD-XRefnodes is perfect to assemble and present a unified view of the model to edit.
Figure 6-4: Typical Structure of a Model Master File presents the general structure of a master
file.

47

The syntax to specify a XML namespace is <ns:element> where ns is the namespace and element is the XML
element name (or simply tag).

© 2015 Open Geospatial Consortium

316

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

db

Group

LOD

(coarsest)

...

XRef

LOD
(finest)XRefFigure 6-4: Typical Structure of a Model Master File

The value found in the Significant Size field of the above LOD nodes matches the values foundin Table 3-1: CDB LOD vs. Model Resolution. The next section provides details on XRef nodes
themselves.
6.2.5
Referencing Other OpenFlight Files
An OpenFlight external reference (XRef) node is used to refer to another OpenFlight file. The
reference is made by specifying the filename and its path (absolute or relative). The CDB
Specification requires that all references be made using a relative path. The XRef node (and its
External Reference record) supports a number of options: Override flags, View-As-BoundingBox flag, and Target Node Name. The CDB Specification supports none of these options.
Here are two cases to illustrate the use of XRef nodes.
6.2.5.1
Models Straddling Multiple Files
In the case of GTModels, GSModels, and MModels, the OpenFlight geometry can straddle
multiple files. It could be seen in a moving model (e.g., a helicopter) whose pilot could be stored
in a separate file. In that case, the file containing the pilot resides in the same directory as thefile containing the helicopter itself. The helicopter would be stored in file 1:\CDB\MModel\600_MModelGeometry\1_Platform\2_Air\225_United_States\21_Utility_Helo\1_2_225_21_x_x_x\
D600_S001_T001_1_2_225_21_x_x_x.flt© 2015 Open Geospatial Consortium

317

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The pilot would be stored in file 2:\CDB\MModel\600_MModelGeometry\1_Platform\2_Air\225_United_States\21_Utility_Helo\1_2_225_21_x_x_x\
D600_S001_T002_1_2_225_21_x_x_x.flt

The XRef node in file 1 would contain the following string:.\D600_S001_T002_1_2_225_21_x_x_x.flt

where 1_2_225_21_x_x_x is the complete DIS code of the helicopter.
6.2.5.2
Models with Multiple Model-LODs
This is the case of the master file of a geotypical model. The master file (known as the
GTModelGeometry Entry File) refers to all levels of details of the geometry files that reside indifferent sub-directories. Assuming a geotypical model representing a gothic church, the master
file itself would reside in a directory such as this one:
\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature\015_Building\
D500_S001_T001_AL015_050_Church-Gothic.flt

The targets of the XRef nodes would all reside in directories such as these:\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature\015_Building\Lnn\
D510_S001_T001_Lnn_AL015_050_Church-Gothic.flt

The resulting strings to use in the XRef nodes in the master file would resemble this:.\Lnn\D510_S001_T001_Lnn_AL015_050_Church-Gothic.flt

where Lnn corresponds to the LOD the XRef file resides in.
6.3

Modeling Conventions

6.3.1
Model Coordinate Systems
CDB Models use the same coordinate system convention as OpenFlight48. The X-axis traverses
the model from left to right, the Y-axis goes from the back to the front and the Z-axis extends
from the bottom to the top of the model. Figure 6-5: Model Coordinate System is a screenshot49of Creator showing a CAD view of a semi-transparent cube.

48

The DIS standard defines a different orientation for the axes of its coordinate system. DIS defines the X-axis as
pointing to the front of the entity; the Y-axis pointing to its right and the Z-axis pointing down. Adoption of the DIS
convention by the CDB Specification has been rejected due to the fact that the majority of models in existence havebeen created using tools such as Creator. The CDB Specification follows the same convention as the one used bythese commercial tools. Note that if the CDB Specification were to follow the DIS convention, modelers would be
required to create and edit their models upside down with respect to the reference plane provided by their tool.
49

Most figures in this chapter are actual screenshots from Creator.

© 2015 Open Geospatial Consortium

318

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-5: Model Coordinate System

6.3.1.1
OriginThe location of the model origin is defined in the following manner:
X

In the XY plane, the origin must be located at the center of the bounding
rectangle.
X
Along the Z axis, the origin is selected to allow the model to be correctly
positioned on ground for ground-related models, or on a water plan for surface
and subsurface platforms.
The following examples will illustrate the above two rules.
1.

Fixed wing aircraft – A KC-130 Hercules is illustrated below with its
landing gears fully extended.

© 2015 Open Geospatial Consortium

319

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-6: Coordinate System – Aircraft

2.

Helicopter – An AH-1W Super Cobra is shown below. Note that noequipment is mounted on its winglets.

Figure 6-7: Coordinate System – Helicopter

3.

Surface ship – Shown below is the Arleigh Burke DDG-51 guided missile
destroyer. Note how the XY plane defines the waterline.

© 2015 Open Geospatial Consortium

320

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-8: Coordinate System – Ship

4.

Land Platform – The M1A2 Abrams is a main battle tank shown here withits desert skin.

Figure 6-9: Coordinate System – Ground-based Model

5.

Lifeform – A human lifeform (a soldier) is presented here.

© 2015 Open Geospatial Consortium

321

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-10: Coordinate System – Lifeform

6.

Cultural Feature – When a Model represents a cultural feature, the origin
is the point of insertion of the model into the ground. In general, the XY
plane (at Z = 0) delimits the basement from the first floor.

Figure 6-11: Coordinate System – Cultural Feature© 2015 Open Geospatial Consortium

322

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 20147.

Power Pylon – In the case of an electricity pylon, the front (and back) of
the model is aligned with the general direction of the attached wires.

Figure 6-12: Coordinate System – Power Pylon

6.3.1.2
Local Coordinate Systems
Most OpenFlight nodes can have a local transformation used to create a local coordinate system.
The origin and orientation of this coordinate system are expressed by a single transformation
matrix.
When a transformation is specified for a node’s primary record, only the matrix record (opcode49) is considered by CDB client-devices. All other transformation records (opcode 76, 78, 79,
80, 81, 82 and 94) are discarded50.
6.3.1.3

Units

6.3.1.3.1 GSModels and GTModels
The MODL attribute of the GSFeature and GTFeature datasets are used to reference GSModels
and GTModels. In turn, the position of GSModels and GTModels are obtained from thecoordinates of each point of the Shapefile; these coordinates are interpreted as the latitude (y),longitude (x), and elevation (z) coordinates that position the model within the CDB51.

50

Typically, these transformations are used by modeling editing tools only.

51

The local origin of the model is translated to the (lat, long) coordinates of the point feature. The elevation
component is either obtained from the point feature (AHGT=True) or obtained from the elevation of the terrain at© 2015 Open Geospatial Consortium

323

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
GSModels and GTModels are drawn to real-world dimensions using meters as their unit ofmeasurement.
6.3.1.3.2 MModels
MModels are usually internally activated and positioned by the client-devices in response to arunning simulation.
In the case of Moving Model location features, the MMDC attribute of the GTFeature dataset isused to reference a MModel. Otherwise, the MModel behaves exactly as a GTModel as
described in section 6.3.1.3.1 above.
MModels are drawn to real-world dimensions using meters as their unit of measurement.
6.3.1.3.3 T2DModels
Vertex latitude (y) and longitude (x) coordinates are expressed in decimal degrees. The values
are relative to the file’s (implicit) origin which is the south-west corner of the tile. Notehowever, that the file’s origin and size are implicitly defined by the tile position and the tilelevel-of-detail. The absolute position of each vertex is obtained by adding the vertex relativevalue to the tile origin.
T2DModels are used to model features that have no significant height with respect to theneighboring terrain; they are generally conformed to the terrain using the “Surface Conformal
Mode” as explained in section 6.7, Model Conforming. Note that the vertices of T2DModels
need not have Z-coordinate values that are always zero. For example, it is permissible to modela road lineal that is modestly elevated with respect to the neighboring terrain. Client-devices
must be capable of handling T2DModels that are either perfectly surface-conformed to theterrain (all vertices have Z=0) or modestly elevated (vertices with Z>0) with respect to theterrain. Note that surface-conformed models with vertices with Z-coordinate values less thanzero are, by definition, below the terrain.
6.3.1.4
Roll, Pitch, Yaw
Pitch, Roll and Yaw angles refer to rotations around the X, Y, and Z axes, respectively. Angles
are measured in degrees. The Roll and Yaw angles vary from ±180 degrees while the Pitch
angle is limited to the range ±90 degrees.
6.3.2
Geometry
The CDB Specification assumes modelers adhere to the following set of constraints, rules andguidelines when creating the geometry of Models.

(lat, long) coordinates of the point-feature (AHGT=False). The model’s XY plane is rotated in accordance to thefeature’s AO1 attribute. The model’s Z-axis is adjusted so that it is tangential to the WGS-84 earth model.

© 2015 Open Geospatial Consortium

324

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1. Create convex polygons. All lines joining any two points in the interior of thepolygon also lie in the interior.
2. Create coplanar vertices. All of the vertices defining a polygon should lie in thesame plane (required by virtually all rendering engines).
3. A polygon’s front face is defined by a counter-clockwise ordering of its vertices.
4. Avoid T vertices. T-vertices occur when two or more adjacent polygons share anedge, and the polygons do not share a common vertex on that edge.
5. Avoid coplanar faces. A coplanar face is a polygon that lies directly on top of
another polygon. Z-buffer fighting can occur when a Z-buffer system cannot
resolve which polygon to display on top. The CDB Specification strongly
recommends changing one of the coplanar faces to be a subface of the other in thehierarchy so that the client device such as an Image Generator can draw the faces
in the correct order. An alternative is to use the Relative Priority field toimplement layering (see section 6.3.4 below).
6. Favor mesh over individual polygons. The OpenFlight Mesh record allows thecreation of triangle fans, triangle strips, quadrilateral strips, and indexed face sets.
This construct is by far preferable to individual polygons built using the
OpenFlight Face record.
7. Make use of instancing. Avoid repeating identical pieces of geometry. Create
one object and repeat it by having multiple instances in different locations.
Users of the Presagis Creator modeling software should carefully read the document entitled
Creating Models for Simulation, provided as part of the standard installation of the product. This
document provides guidelines to build models geared toward real-time application.
6.3.3
Roof Tagging
OpenFlight has a provision for tagging polygons that are part of a roof. The Roofline flag can befound in both the Face and Mesh records. This flag is useful to apply a geospecific texture to theroof. When the flag is set, the client-device can discard the texture referenced by the polygon
and use instead the geospecific texture that appears on the terrain.
More generally, the Roofline flag is used to tag any polygon whose texture can be replaced witha geospecific texture.
6.3.4
Relative Priority
The Relative Priority field appears in four OpenFlight primary records:
Face Record
Mesh Record
Object Record
Group Record
The field is required to implement layering, a method to handle coplanar geometry. By using theRelative Priority field, the modeler can construct more complex coplanar geometry than what is
possible with subfaces.
Here is the definition of the field according to OpenFlight 16.0:© 2015 Open Geospatial Consortium

325

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Relative priority specifies a fixed ordering of the node relative to its sibling nodes.
Ordering is from left (lesser values) to right (higher values). Nodes of equal
priority may be arbitrarily ordered. All nodes have an implicit (default) relative
priority value of zero.
The CDB Specification further restricts the use of the Relative Priority field for complex
coplanar geometry as follows. Using relative priorities, the modeler defines 'n' layers of coplanar
geometry. Layers are numbered from 0 to 'n-1'. Layer 0, the base layer, must contain geometrythat completely encompasses the geometry of subsequent layers. Other layers are processed inorder, one after the other. A layer is made of one or more nodes; all nodes of a given layer havethe same relative priority.
6.4

Model Identifiers

6.4.1
GSModel and GTModel Identifier
Although the name of the global zone of a GS or GT model is arbitrary, it is strongly suggested
to use the value of their MODL attribute to name the global zone.
For instance, a GTModel stored in a file called
D500_S001_T001_AL015_004_Castle.flt

Would have its global zone identified like this:<CDB:Zone
name="Castle"
/>

6.4.2
MModel Identifier
The MModel identifier is the common name of the moving model or the name of its part. The
actual name is not covered by the Specification. An example of a MModel identifier is “M1A2”
for the M1 Abrams tank whose DIS Entity Type is 1_1_225_1_1_3_0.
For instance, a moving model stored in a file called
D600_S001_T001_1_1_225_1_1_3_0.flt

Would have its global zone identified like this:<CDB:Zone
name="M1A2"
/>

6.4.3
2DModel Identifier
A T2DModel itself does not need to be identified per se. However, it is required to identify
individual 2DModels inside a T2DModel. This is done by assigning a unique zone name to each
2DModel. In addition, a 2DModel must have the same zone name across LODs and across tiles.
Note that when a 2DModel is clipped by tile boundaries, each of the clipped model fragments© 2015 Open Geospatial Consortium

326

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
will appear in distinct OpenFlight files of the T2DModel Dataset. When clipped, the 2DModel
Identifier must appear once, in each of the T2DModel Tile-LODs. This is necessary to identify
the parts of a 2DModel that straddle multiple Tile-LODs.
6.5
Model Zones
The concept of a model zone is of the utmost importance when creating models, particularly
those used in military simulation applications.
A model zone represents a component52 of interest on the Model. A model zone (as well as thecomponent it represents) occupies a certain volume and is delimited by a bounding box. At least
one simulator subsystem must be interested in a specific component to justify the creation of acorresponding zone. Examples of zones are a turret on a tank, or an engine on a platform, or an
entrance door on a building, etc.
Since the model itself is of interest to the simulation, it will have at least one zone, the global
zone. That will be the case for most Models used as cultural features; they will have a single
zone. However, Models used as moving models will typically be subdivided into several zones.
To implement the concept of model zones, the CDB Specification uses the OpenFlight Group
Node. Firstly, a Group Node can have child nodes to represent its own geometry as well as otherzones. Secondly, a Group Node can have a bounding volume encompassing its child nodes andthat can be used to represent the volume corresponding to the zone.
6.5.1
Definition
A Model Zone is an OpenFlight Group Node with a mandatory Bounding Box and the following
XML tags in the comment field.
Table 6-2: XML Tags for Zones<CDB:Zone name="name" volume="closed|open">... zone attributes</CDB:Zone>

The zone name is mandatory. Remember that if the zone exists, it is because it has its
importance for at least one client device. In general, all client devices interested in a zone willuse its name to identify and control it.
The volume attribute is optional and specifies whether the zone represents a closed or open
volume. By default, a zone represents a closed volume.
The following table lists the OpenFlight records required to represent a zone.

52

A dictionary of CDB Component Names is provided in Appendix F.

© 2015 Open Geospatial Consortium

327

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-3: OpenFlight Records for a ZoneGROUP
MATRIX (optional)
BOUNDING BOX (mandatory)
COMMENT (mandatory)

Note the use of the MATRIX record. It is necessary when the zone has a different position ororientation than its parent node. A zone can be thought of as a separate Model in itself. A zone
has a natural orientation and its local coordinate system must indicate where their front, right,
and back sides are. A zone is subject to the same convention as the model itself regarding theorientation of its coordinate system.
6.5.2
Global Zones
A CDB-compliant Model has at least one zone that encompasses the whole model and that iscalled the model global zone. The global zone is mandatory. Figure 6-13 illustrates the locationof the global zone in the graph hierarchy.

Figure 6-13: Model Global Zone

The global zone contains the name of the Model contained in the OpenFlight file.
6.5.3
Zone Attributes
A Model Zone can have any number of attributes using the general mechanism descrived later insection 6.12, Model Attributes. However, two specific attributes are described here because of
their particular relevance to the concept of Model Zone.
6.5.3.1
Material
The Material attribute provides an indication of the principal material the zone is made of. Since
the majority of man-made models are made of one principal material as well as several lessimportant materials, it is strongly suggested to use the Material attribute in the model global zone
to specify what that principal material is.
The Material attribute is an index into the Composite Material Table located within the Model
Descriptor file described in section 6.14. The value of the Material attribute is a strictly positive
integer. The syntax of the XML tag is:© 2015 Open Geospatial Consortium

328

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

<CDB:Zone><Material> index </Material></CDB:Zone>

The Material attribute can also be assigned to OpenFlight Object, Face, and Mesh nodes. The
preferred syntax would be the following:<CDB:Object><Material> index </Material></CDB:Object><CDB:Face><Material> index </Material></CDB:Face><CDB:Mesh><Material> index </Material></CDB:Mesh>

However, for compatibility with version 3.1 and 3.0 of the Specification, a simplified (butdeprecated) syntax is still supported for Object, Face, and Mesh nodes when the Material is the
only attribute.

<CDB:Material>
index</CDB:Material>

6.5.3.2
Temperature
When the zone has a heat source, such as an engine, it is known as a Hot Spot. The maximum
temperature the zone can reach is specified using the Temperature attribute as shown here:
Table 6-4: XML Tags for Hot Spots<CDB:Zone><Temperature> maximum temperature </Temperature></CDB:Zone>

The temperature is expressed in Celsius degrees. Only integer values are permitted.
Appendix F supplies a comprehensive list of zones that are candidates for hot spots. Typical hot
spot names are Engine and Chimney to name only these two. Other zones that are of interest for
hot spots simulation are wings leading edge and other surfaces subjected to friction.

© 2015 Open Geospatial Consortium

329

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.5.4
Implementation Guidelines
This section provides a set of guidelines to implement the concept of model zones. The
guidelines provided here are also applicable to Model Points described in section 6.6.
A zone is made of at least one Group Node.

Figure 6-14: Simple Zone

A zone may have an optional articulation by adding a DOF node.

Figure 6-15: Articulated Zone

To simplify the following diagrams, we will use a single circle to represent a zone, whether thezone is a single Group Node, or a pair of group and DOF nodes.
In general, a zone has a graphical representation as well as other child zones.

Figure 6-16: Zone Hierachy© 2015 Open Geospatial Consortium

330

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The graphical representation of a zone is itself subject to several possible implementations using
various OpenFlight nodes.
The simplest way to associate a graphical representation to a zone is to use an Object node with a
combination of graphic primitives available in OpenFlight: polygons, triangles, quads, andmeshes.

Figure 6-17: Simple Zone Graphical Representation

The modeler is also free to use a combination of LOD and Switch nodes to control the graphicalrepresentation of a zone.
For instance, an LOD node inserted before the object node is useful to inform the client device
on how significant the graphical representation is.

Figure 6-18: Additive LOD to Control the Graphical Representation© 2015 Open Geospatial Consortium

331

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
If the modeler wants to provide two (or more) graphical representations for a zone, he should use
two (or more) LOD nodes.

Figure 6-19: Exchange LODs to Select the Graphical Representation

Levels of details are discussed in length in Section 6.8, Model Levels-of-Detail.
If the modeler has several distinct graphical representations for the zone, he is also free to use aswitch node to select between these representations.

Figure 6-20: Switch Node to Select the Graphical Representation

CDB Switches are discussed in depth in Sections 6.9, Model Switch Nodes.
6.5.5
Model Zone Naming
A Model Zone Node is uniquely and unambiguously identified by concatenating withbackslashes (‘\’) the names of all Model Zones traversed to reach it. When sibling CDB nodes© 2015 Open Geospatial Consortium

332

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
have identical names, their name is appended with a sequence number in square brackets. Nodes
are numbered starting with 1. Siblings are sorted in ascending order according to their X, Y, andZ coordinates. The leftmost sibling has the smallest XYZ coordinate while the rightmost siblingnode has the largest XYZ coordinate. As a result, identical sibling CDB nodes are sorted fromleft to right (X-axis), then back to front (Y-axis), then bottom to top (Z-axis).
The following example provides a sample of Model Zone and Model Point names that would be
used for a tactical fighter aircraft; the fighter has two pylons per wing, each pylon having 3
attach points. The resulting paths to each Model Zones and Model Points are as follow:\Fighter\Fighter\Wing[1]\Fighter\Wing[1]\Pylon[1]\Fighter\Wing[1]\Pylon[1]\Attach_Point[1]\Fighter\Wing[1]\Pylon[1]\Attach_Point[2]\Fighter\Wing[1]\Pylon[1]\Attach_Point[3]\Fighter\Wing[1]\Pylon[2]\Fighter\Wing[1]\Pylon[2]\Attach_Point[1]\Fighter\Wing[1]\Pylon[2]\Attach_Point[2]\Fighter\Wing[1]\Pylon[2]\Attach_Point[3]\Fighter\Fuselage\Fighter\Fuselage\Attach_Point\Fighter\Wing[2]\Fighter\Wing[2]\Pylon[1]\Fighter\Wing[2]\Pylon[1]\Attach_Point[1]\Fighter\Wing[2]\Pylon[1]\Attach_Point[2]\Fighter\Wing[2]\Pylon[1]\Attach_Point[3]\Fighter\Wing[2]\Pylon[2]\Fighter\Wing[2]\Pylon[2]\Attach_Point[1]\Fighter\Wing[2]\Pylon[2]\Attach_Point[2]\Fighter\Wing[2]\Pylon[2]\Attach_Point[3]Here is how to interpret some of these paths:
The global zone is identified as \Fighter
The left wing is \Fighter\Wing[1]The leftmost attach point is \Fighter\Wing[1]\Pylon[1]\Attach_Point[1]The rightmost attach point is \Fighter\Wing[2]\Pylon[2]\Attach_Point[3]There is a single attach point on the fuselage, \Fighter\Fuselage\Attach_Point
The inner pylon on the left wing is \Fighter\Wing[1]\Pylon[2]The inner pylon on the right wing is \Fighter\Wing[2]\Pylon[1]© 2015 Open Geospatial Consortium333

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.5.6

Usages

6.5.6.1
Model Landing Zones
Landing zones are used primarily by the Computed Generated Forces (CGF) sub-system of thesimulator. The landing zone information can be used during the set-up of mission scenarios
since it provides CGF the location of known landing zones. Typically, landing zones are used to
specify the location and dimension of helipads, aircraft carrier decks, etc. Appendix F lists
several CDB Components that can act as landing zones.
Landing zones must have a bounding box that tightly fits the landing area. If required by thegeometry of the landing zone, the modeler should create a local coordinate system that is axiallyoriented with the landing zone. Inserting a MATRIX record after the GROUP record does this.
The width and the length of the landing zone can be extracted by the client-device from thebounding box associated with the Group Node representing the zone. The landing zone
geometry must be located under the Group Node to obtain meaningful dimensions.
6.5.6.2
Model Footprint Zones
A Model Footprint53 conceptually represents the footprint (i.e., the terrain surface outline) of amodel on the ground. The Model Footprint is modeled as a set of OpenFlight Face or Meshrecords.
Client-devices are required to assume that the geometry that is associated with a Model Footprint
Zone is hidden, regardless of the value of the OpenFlight Hidden flag of associated geometry.
However, CDB content creation tools are nonetheless required to set the Hidden flag of theassociated geometry54. The footprint geometry should be terrain conformed using the “Surface
Conformal Mode” as explained in section 6.7, Model Conforming. This instructs client-devices
to conform this footprint to the underlying terrain altimetry, regardless of its level-of-detail.
The Model Footprint is the set of polygons or meshes that result from the intersection of themodel geometry with its XY plane55.
A polygon that is tagged as Model Footprint can be used by client-devices to identify the portionof the terrain that is covered by a model. The Cultural Footprint can be used by client-devices
such as:
Map generators that may not be interested in the full 3D geometry of a Model.
53

The OpenFlight Face and Mesh records both have a flag called Terrain Culture Cutout. This flag iscommonly designated as the Cultural Footprint flag within the simulation industry.
54

This increases compatibility with OpenFlight readers that are not CDB-compliant.

55

The Model Footprint polygon is not an absolute Z-positioned 3D polygon generated by the intersection of
the model with the specific terrain it sits on - that would make the footprint of the model specific to that terrain.
Furthermore, a different 3D polygon would be required for each possible terrain LOD.

© 2015 Open Geospatial Consortium

334

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Procedural SE generation software that may use model footprints toautomatically extrude such footprints into 3D models.
Simulation of ground-based SAF entities that would use model footprints toavoid collisions with features such as buildings and trees.
The CDB Specification requires that the Model Footprint be placed under a CDB Footprint Zone
node. This CDB node facilitates the identification and discovering of footprints by clientdevices. The subgraph representing the Footprint is presented here.

Footprint(zone)

ObjectFace

MeshFigure 6-21: Footprint Zone Structure

The Footprint zone is followed by an OpenFlight Object node with the necessary OpenFlight
Face or Mesh nodes containing the footprint itself. All Face/Mesh nodes must have their Terrain
Culture Cutout flag set. A Footprint zone is defined by the following XML tags.
Table 6-5: Footprint Zone XML Tags
<CDB:Zone name = "Footprint"/>

6.5.6.3
Model Cutout Zones
A Model Cutout Zone conceptually represents clipping geometry that is used to cut out theterrain from a 2DModel or a 3DModel. Cutouts are typically used in conjunction with modelinteriors and tunnels. The Model Cutout geometry defines a simple 3D convex volume (open or
closed). A typical implementation of a Model Cutout Zone for a modeled building would consistof a simple cube. Similarly, the Model Cutout Zone for a tunnel entrance would consist of asimple cylinder or a partially-open cube (see Figure 5-9: Modeling of Wells, Overhanging Cliffs
and Tunnels).
The Model Cutout is modeled as a set of OpenFlight Face or Mesh records. Client-devices are
required to assume that the geometry that is associated with a Model Cut-Out Zone is hidden andcut-out. Client-devices should ignore the value of the OpenFlight Hidden and Terrain Culture© 2015 Open Geospatial Consortium

335

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Cutout flags of associated geometry. However, CDB content creation tools are required to set
the Hidden and Terrain Culture CutOut flags of the associated geometry56.
The Model Cutout geometry should be terrain conformed using the “Surface Conformal Mode”
as explained in the 6.7, Model Conforming. This instructs the client-device to conform theModel Cutout to the underlying terrain altimetry, regardless of its level-of-detail.
It is specified using the following XML syntax:
Table 6-6: XML Tags for Landing Zones<CDB:Zone name="Cutout">

Polygons or meshes that are tagged as Model Cutout can be used by client-devices to identify the
portion of the terrain that needs to be removed in order to reveal the interior of the model (say abuilding interior or a tunnel interior). The Model Cutout is necessary for models straddling theterrain surface and whose interior is modeled and viewed from within. The reason for this is thatwhen the model is altitude-conformed onto the terrain, a hole must be cut into the terrain-LOD,
so that the terrain itself does not visually interfere with the modeled building or tunnel interior.
The CDB Specification requires that the Cutout geometry be placed under a CDB Model Cutout
Zone node. This CDB node facilitates the identification and discovery of model cutouts byclient-devices. The subgraph representing the cutout is presented here.

Cutout(zone)

ObjectFace

MeshFigure 6-22: Cutout Zone Structure

56This increases compatibility with OpenFlight readers that are not CDB-compliant.

© 2015 Open Geospatial Consortium

336

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.5.6.4
Model Interior Zones
This section focuses on how to represent the interior of Models for an intelligent use by clientdevices.
A Model is composed of 2 parts: a shell, and an optional interior. The shell contains both theexterior and the pseudo-interior. Client-devices need only access the shell if they do not need topenetrate and interact with the interior of the models; otherwise, they require both the shell andthe interior. The shell of a Model is stored in five (5) datasets:
ModelGeometry
ModelTexture
ModelSignature
ModelDescriptor
ModelMaterial
The optional model interior is stored in four (4) datasets:
ModelInteriorGeometry
ModelInteriorTexture
ModelInteriorDescriptor
ModelInteriorMaterial
Refer to appendix A.5 for guidelines on Handling of Model Interiors.
6.5.6.4.1 Model Pseudo-Interior Zone
The pseudo-interior is the portion of the shell that contains geometry also represented in theinterior dataset. This geometry represents what is visible from the outside and is necessary toensure the integrity and completeness of the shell. Since the pseudo-interior is a placeholder forthe real interior, it must be placed under its own subgraph and identified by a CDB zone whosename is “Interior”.

© 2015 Open Geospatial Consortium

337

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

db

Shell

(global zone)

Footprint(zone)

Exterior(zone)

Interior(zone)

Figure 6-23: Model Shell Structure

The name “Interior” is a reserved component name allowing a client-device to identify the nodethat is to be replaced by an entire dataset, namely the ModelInteriorGeometry dataset. The
pseudo interior is mutually exclusive with the real interior defined in section 6.5.6.4.2, Model
Interior Zone, below.
Figure 6-23 also illustrates how to structure the shell of a Model that has a real interior. The
model is divided in three components: the footprint of its exterior, the geometry of its exterior,and the geometry of its pseudo-interior. Therefore the names of these three components are“Footprint”, “Exterior”, and “Interior” as illustrated by the following XML tags.

Table 6-7: Shell Zones XML Tags
<CDB:Zone name = "Footprint"/><CDB:Zone name = "Exterior"/><CDB:Zone name = "Interior"/>

Footprints were discussed earlier in section 6.5.6.2, Model Footprint Zones.
6.5.6.4.2 Model Interior Zone
The Model interior itself must have a global zone whose name is “Interior”. Accordingly, thegraph of the interior of the model will present the following structure. Note that real interior
must not include the modeled representation of the shell.

© 2015 Open Geospatial Consortium

338

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014db

Interior(global zone)

Figure 6-24: Model Interior Structure

The Interior zone contains one or more floors as well as the partitions separating these floors.
An Interior zone is defined by the following XML tags.

Table 6-8: Interior Zone XML Tags
<CDB:Zone name = "Interior"><Ground_Floor> index </Ground_Floor></CDB:Zone>

The <Ground_Floor> is optional. It contains the index of the Floor that represents the groundfloor of the model interior. By default, the ground floor is floor number 1.
The subgraph representing the Interior zone has the following structure.

Interior

Floor

Partition

Figure 6-25: Interior Zone Structure

The Interior zone has two (2) kinds of child nodes: Floor and Partition. The Interior has at least
one Floor. When the Interior has several Floors, the separating Partitions appear as siblings ofthe Floor nodes. These Partitions contain external Apertures that connect two Rooms on
different Floors. These external Apertures are later referenced by Rooms.

© 2015 Open Geospatial Consortium

339

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.5.6.4.2.1 Model Interior Topology
To navigate through the interior of Models, simulator client-devices need to know theconnections between the elements composing the interior, such as floors, rooms, doors, or
fixtures. In addition, these elements must be identified and attributed for use by computer
generated forces (CGF) client-devices. For this reason, the CDB Specification has opted forreuse and adoption of version 2 of the UHRB specification57.
The CDB Specification maps the UHRB Object Model to the OpenFlight Scene Graph using theconcept of CDB nodes.
The UHRB object model proposes twelve (12) classes. Of these, four (4) are abstract baseclasses and one (1) is a provision for future expansion of the UHRB specification. The
remaining seven (7) concrete classes are mapped to CDB Zone nodes. The UHRB Class Names
and their corresponding CDB Zone Names are:Table 6-9: UHRB Class Names and corresponding CDB Zone Names

UHRB Class NameCDB Zone NameUHRB_TEMPLATEInterior

UHRB_FLOOR_LEVEL_COMPONENTFloor

UHRB_SURFACE_COMPONENTSurface

UHRB_ROOM_COMPONENTRoomUHRB_FIXTURE_COMPONENT

FixtureUHRB_APERTURE_COMPONENT

Aperture

UHRB_FIXED_PARTITION_COMPONENTPartition

The above CDB nodes are treated the same way as any other CDB nodes. In particular, Floor,
Room, Partition, Aperture, Fixture, and Surface nodes are numbered following the conventions
established in section 6.5.5, Model Zone Naming; they also have zone attributes such as theMaterial Index.

57

See references [35] and [36] in section 10, Reference Documents.

© 2015 Open Geospatial Consortium

340

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.5.6.4.2.2 Model Interior Topology Attributes
This section describes the CDB mechanism that expresses the possible connections between
compartments and apertures. The definition of a CDB Zone is extended with the addition of one
XML tag indicating which other components are connected to this one.
The following table presents the revised syntax of the XML tags defining a CDB Zone. The
addition is highlighted in yellow.
Table 6-10: XML Tags for Zone Connections<CDB:Zone name="name" volume="closed|open"><Material> index </Material><Temperature> value </Temperature><ConnectTo> path </ConnectTo>...
</CDB:Zone>The	
  <ConnectTo>	
  tag may appear zero or more times, allowing for the definition of any
number of connections to other components. The other tags (Material and Temperature) retain
their current definition. In particular, the use of the <Material> tag is encouraged to define thematerial the components are made of.	
  
	  The presence of the <ConnectTo>	
  tag is restricted to a set of three (3) components: global
zone, compartments and apertures. A connection is unidirectional; it goes from the zone that
contains the <ConnectTo>	
  tag to the zone referenced by the path. The path is either relative or
absolute. When a relative path is used, it identifies a sibling of the current zone. Here are some
path examples.
	
  Table 6-11: Examples of Absolute and Relative Paths
Example 1:<CDB:Zone name="Interior"><ConnectTo> \Interior\Section[1]\Level[1]\Aperture[5] </ConnectTo></CDB:Zone>
Example 2:<CDB:Zone name="Aperture[5]"><ConnectTo> \Interior\Section[1]\Level[2]\Compartment[3] </ConnectTo></CDB:Zone>
Example 3:<CDB:Zone name="Compartment[3]"><ConnectTo> Aperture[1] </ConnectTo><ConnectTo> \Interior\Section[1]\Level[1]\Aperture[5] </ConnectTo></CDB:Zone>	  © 2015 Open Geospatial Consortium

341

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Example 1 is an absolute path, expressed as a directory name, starting with the topmost zone, theglobal zone. It tells us that there is one entrance into the model interior through the fifth aperture(Aperture[5]) on the first level (Level[1]) of the first section (Section[1]) of the model interior(\Interior).
Example 2 is also an absolute path. It tells us that the fifth aperture (Aperture[5]) has a single
connection to the third compartment (Compartment[3]) of the second level (Level[2]) of the firstsection (Section[1]) of the model interior (\Interior).
Example 3 illustrates how to use a relative path. It tells us that the third compartment(Compartment[3]) has two exits. The first exit is through the first aperture (Aperture[1]) of thecurrent level. The second exit is through the fifth aperture (Aperture[5]) on the first level(Level[1]) of the first section (Section[1]) of the model interior (\Interior).
Example 1 tells us to use Aperture 5 to enter into the model interior. Example 2 further informs
us that Aperture 5 brings us into Compartment 3. Example 3 says that we can exit Compartment
3 through either Aperture 1 or 5.
The global zone (the top level node) node provides the list of apertures representing entrances
into the model. If the global zone does not provide at least one aperture to enter the model, thenthe model interior is unreachable. To exit a compartment, it must connect to at least one
aperture; if not, you may be able to enter the compartment, but you will not be able to exit.
Finally, an aperture allows entrance into compartments. An aperture without connection is anexit point; in that case, a compartment must connect to the aperture.
Appendix J presents the XML schema governing the construction of a valid CDB Zone. The
schema includes provision for the <ConnectTo> tag.
6.5.6.4.3 Floor Zone
A Floor zone contains one or more Rooms, and all Partitions shared by these Rooms. A Floor isdefined by the following XML tags.

Table 6-12: Floor Zone XML Tags
<CDB:Zone name = "Floor"><Label> floor name </Label></CDB:Zone>

The <Label> is optional. It can be used to give the Floor a meaningful name such as “Ground
Floor”, “Basement”, “Mezzanine”, or “Penthouse”.
The subgraph representing a Floor has the following structure.

© 2015 Open Geospatial Consortium

342

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Floor

Footprint

Room

Partition

Figure 6-26: Floor Zone Structure

The Footprint of a Floor is the minimum enclosing polygon containing all of the footprints of allof the Rooms on the Floor as well as the footprints of all of the Partitions associated with thoseRooms. The Footprint is defined as per section 6.5.6.2, Model Footprint Zones. The Partitions
contain the Apertures that connect two Rooms together. These Apertures are later referenced by
Rooms.
6.5.6.4.4 Room Zone
A Room zone owns all its Surfaces and may contain Fixtures. A Room is defined by thefollowing XML tags.

Table 6-13: Room Zone XML Tags
<CDB:Zone name = "Room"><Label> room name </Label><Aperture> path to aperture 1 </Aperture>... other apertures as needed<Partition> path to partition 1 </Partition>... other partitions as needed</CDB:Zone>

The <Label> is optional. It can be used to better identify the Room by its usual name. Examples
are cubicle, toilet, conference room, atrium, office, electrical room, janitor room, etc.
The <Aperture> is optional but is likely to appear at least once, unless the Room is permanently
closed and cannot be accessed. It points to one Aperture that connects this Room with another
Room on this Floor or on another Floor. Two Rooms on the same Floor are connected throughan Aperture in a Partition on the current Floor. Two Rooms on two different Floors areconnected through an external Aperture in a Partition from the Interior zone. The path to an
Aperture is built as specified in section 6.5.5, Model Zone Naming.
The <Partition> is also optional, but again, is likely to appear several times since a typical Roomhas a floor, a set of walls, and a ceiling.

© 2015 Open Geospatial Consortium

343

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The subgraph representing a Room has the following structure.

Room

Footprint

FixtureBottomSurfaces(group)SideTop(group)(group)(group)Surface

Surface

Surface

Figure 6-27: Room Zone Structure

The footprint is the smallest polygon containing all of the bottom surfaces when projected onto
the XY plane58. There can be zero or more Fixtures in a Room. The Surfaces making up thevolume of the Room are separated in three (3) groups (Bottom, Side, and Top) as defined by the
UHRB specification.
6.5.6.4.5 Fixture Zone
A Fixture zone is defined in the same manner as a Room; it is made of a number of Surfaces
defining a closed volume. The Fixture is defined by the following XML tags.

Table 6-14: Fixture Zone XML Tags
<CDB:Zone name = "Fixture"><Label> fixture name </Label><Moveable> true/false </Moveable></CDB:Zone>

58

This definition of a room footprint comes from the UHRB Specification.

© 2015 Open Geospatial Consortium

344

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The <Label> is optional. It allows the modeler to describe what this fixture represents.
The <Moveable> flag is optional. It indicates whether or not the Fixture can move or if it isfixed. By default, the fixture does not move; if it does, the flag is set to true. A piece offurnitures is an example of moveable fixture while a column is an example of a fixed one.
The subgraph representing a Fixture is similar to that of a Room, except for the need todifferentiate between the kinds of Surfaces. Its structure is presented here.

FixtureFootprint

Surface

Figure 6-28: Fixture Zone Structure

The Footprint is the smallest polygon containing all of the Surfaces when projected onto the XY
plane. The Surfaces form a closed volume, meaning there is no hole in the Fixture.
Alternately, to permit reuse of common fixtures stored in the GTModel Library, the Fixture may
reference an existing model through the use of an XRef node. In that case, the following
subgraph is to be used.

FixtureXRefFigure 6-29: Fixture Zone Structure

6.5.6.4.6 Partition Zone
A Partition zone has Apertures, makes reference to all Surfaces composing it, and refers to its
adjacent Rooms. The Partition is defined by the following XML tags.

© 2015 Open Geospatial Consortium

345

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-15: Partition Zone XML Tags
<CDB:Zone name = "Partition"><Label> partition name </Label><Room> path to adjacent room 1 </Room><Room> path to adjacent room 2 </Room><Surface> path to surface 1 </Surface>... other surfaces as needed</CDB:Zone>

The <Label> is optional. It allows the modeler to better identify the type of Partition: wall, floor,
ceiling, etc.
The <Room> tag is mandatory and is used to identify the two Rooms adjacent to the Partition59.
For this reason, there must be exactly two <Room> tags. The path to an adjacent Room is as
specified in section 6.5.5, Model Zone Naming. Note that UHRB defines the concept of an“outside” room when the partition defines a building outside wall. In CDB, the path of thisoutside room is \Shell\Exterior as illustrated in 6.5.6.4.1, Model Pseudo-Interior.
The <Surface> tag appears as many times as necessary to refer to all Surfaces making up thisPartition. A path similar to the one used to refer to a Room is used to refer to a Surface. Notethat a Partition does not refer to the Surfaces that belong to its Aperture; that will be taken careof by the Apertures themselves.
The subgraph representing a Partition has the following structure.

Partition

Footprint

Aperture

Figure 6-30: Partition Zone Structure

The Footprint is the smallest polygon containing all of the referenced Surfaces when projected
onto the XY plane. A Partition can have zero or more Apertures in it.

59

Note that the CDB specification follows established UHRB conventions as it relates to partitions, namely that all
partitions must be clipped so that there are no more than two neighbouring rooms.

© 2015 Open Geospatial Consortium

346

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.5.6.4.7 Aperture Zone
An Aperture zone provides a mean by which one can enter or exit a Room. The Aperture zone isdefined by the following XML tags.

Table 6-16: Aperture Zone XML Tags
<CDB:Zone name = "Aperture"><Label> aperture name </Label><Is_Open> true/false </Is_Open><Is_Fixed> true/false </Is_Fixed><Damage_Level> percentage of damage </Damage_Level><Room> path to room 1 </Room><Room> path to room 2 </Room><Surface> path to surface 1 </Surface>... other surfaces as needed</CDB:Zone>

The <Label> is optional. It allows the modeler to better identify the type of Aperture: door,
window, trap, etc.
The <Is_Open> and <Is_Fixed> flags are both optional; they are considered false when notprovided.
The <Damage_Level> tag is also optional and provides a mean to indicate the level of damage of
the Aperture. The value is expressed as a percentage using an integer in the range 0 (no damage)to 100 (destroyed).
The <Room> tag appears exactly two times and points to the two Rooms connected by thisAperture. Sometimes one of these two rooms may be an “outside” room - a concept defined in
UHRB. In CDB, the path of this outside room is \Shell\Exterior as illustrated in 6.5.6.4.1, Model
Pseudo-Interior.

The <Surface> tag appears as many times as necessary to refer to all Surfaces making up thisAperture.
The subgraph representing an Aperture has the following structure.

© 2015 Open Geospatial Consortium

347

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Aperture

Footprint
Figure 6-31: Aperture Structure

The Footprint is the smallest polygon containing all of the referenced surfaces when projected
onto the XY plane.
6.5.6.4.8 Surface ZoneA Surface zone contains useful geometry. That’s all it does. The Surface zone is a plain CDB
zone. Its subgraph is presented here.

SurfaceObjectFace

MeshFigure 6-32: Surface Zone Structure

A Surface is composed of one or more OpenFlight Object nodes holding the geometry defining
the surface: face or mesh records.
6.6
Model Points
A model point is similar to a model zone; it identifies a location on the model that is of interest to
at least one simulation client device. A point defines a local coordinate system on the model.
Hence, a point has a position and an orientation.

© 2015 Open Geospatial Consortium

348

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In some respect, a point and a zone are similar and can be used interchangeably. A zone is used
when the component of interest is physically modeled and has a graphical representation. Whenthe zone is not modeled but still represents a component of interest, a point is used to indicate its
presence.
Again, the OpenFlight Group Node mechanism provides a convenient means of implementing
the concept of a point because a transformation can be added to the node.
6.6.1
Definition
The table below presents the syntax of the XML tags stored in the node’s comment record.
Table 6-17: XML Tags for Points<CDB:Point name = "name">... point attributes</CDB:Point>

The point name is mandatory while the point attributes are optional. In general, a point can havethe same name as a zone. The following table lists the OpenFlight records required to represent
a point.
Table 6-18: OpenFlight Records for a Point
GROUP
MATRIX (mandatory)
COMMENT (mandatory)

A model point is used in several occasions such as defining the attach point where another Modelcan anchor itself.
6.6.2

Usages

6.6.2.1
Model DIS Origin
A Model that is intended as a DIS entity requires a point that defines the origin of the entity’scoordinate system. This point is the center of the entity’s bounding volume excluding its
articulated and attached parts60. On a DIS network, the location of an entity is expressed relative
to this point. There must be a single definition of this point for all damage states and all levels ofdetails for a given model.
The following XML tag identifies the point.
Table 6-19: XML Tags for the DIS Origin<CDB:Point
name = "DIS_Origin"/>

If the DIS origin is not defined, it defaults to the model origin.
60

This definition can be found on page 3 of reference [4].

© 2015 Open Geospatial Consortium

349

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The CDB Point representing the DIS Origin must be positioned and oriented according thedefinition provided by the DIS Standard. This definition says that the DIS Origin is at the centerof the bounding box of the entity, without articulated and attached parts. The standard also says
what the orientation must be. The X-axis points forward, the Y-axis points to the right, and the
Z-axis points down. All axes are aligned with the bounding box defined above.
The intent of the DIS Standard is to have its axis system aligned with the body of the entity.
When it comes to air platform, the body is associated with the fuselage of the entity. To
illustrate the difference in orientation between the DIS entity’s bounding box and the CDB
Model’s bounding box, consider the Chinook helicopter shown below.

Figure 6-33: Orientation of the Chinook Helicopter

The fuselage of this helicopter has a pitch angle of approximately 1.6 degrees when resting on its
wheels. Below is a snapshot of its fuselage, without rotors and landing wheels.

© 2015 Open Geospatial Consortium

350

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-34: The Body of the Chinook Helicopter

From the snapshots above, it is clear that the orientation of the DIS origin must be such that its
XY plane makes an angle of 1.6 degrees with respect to the XY plane of the CDB axis system.
Here is a recommended way of defining the DIS Origin:
1.
2.
3.
4.
5.
6.
7.

Create the Group Node and tag it as a CDB Point whose name is
DIS_Origin.
Make the CDB Point a child of the zone that best represents the entity’sbounding volume without any articulated and attached parts.
Ensure the zone is properly oriented with respect to the CDB axis system.
Add a translation to position the origin at the center of the above bounding
volume.
Add a rotation to align the X-axis to the front of this bounding volume.
Add another rotation to align the Z-axis with the bottom of the bounding
volume.
By doing so, the Y-axis should already point correctly to the right side of
the box.

© 2015 Open Geospatial Consortium

351

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.6.2.1.1 Example
The snapshot below shows the proper location and orientation of the DIS origin on the Chinook.
The DIS origin is represented by a set of 3 orthogonal Blue-Red-Green arrows. The blue arrow
indicates the X axis; the green arrow points down and represents the Z axis.

Figure 6-35: The DIS Origin of the Chinook Helicopter

If you watch carefully, you will notice that the DIS axis system is aligned with the fuselage andmakes an angle with the CDB XY plane.
6.6.2.2
Model Viewpoint
To generate the correct view of the outside world from a model’s viewpoint, a client device
needs an indication of where is the viewpoint located with respect to the model’s origin. The
viewpoint corresponds to the pilot’s seat in an aircraft, the driver’s seat in a ground vehicle, thenavigation post on a ship bridge, the periscope on a submarine, or the eyes of a soldier. The
viewpoint’s local coordinate system is oriented such that the Y-axis indicates the viewing
direction and the Z-axis points up.
The viewpoint has optional attributes to define the field of view available from this position.
The field of view is defined by a frustum aligned along the local Y-axis. The horizontal field ofview lies in the local XY plane while the vertical field of view is in the YZ plane.

© 2015 Open Geospatial Consortium

352

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-20: XML Tags for a Viewpoint<CDB:Point name="Viewpoint"><FOV><Horizontal>min max</Horizontal><Vertical>min max</Vertical></FOV></CDB:Point>

All values are expressed in degrees using decimal numbers. The default values are ±30.0° in
both directions for a total of 60.0° of horizontal and vertical fields of view.
6.6.2.3
Model Attach PointA Model can be attached to another Model by mean of an attach point.
An attach point defines the position to which other (subordinate) models can attach themselves.
For instance, a fighter has a number of attach points defined to receive missiles or external fueltanks.
Table 6-21: XML Tags for Attach Point<CDB:Point
name = "Attach_Point"/>

The orientation of the attach point is used to indicate how the two models connect together. A
connection occurs by superimposing the coordinate system of the subordinate model with thecoordinate of the attach point.
6.6.2.4
Model Anchor Point
The anchor point defines the location where a subordinate Model attaches to a parent Model.
The anchor point is the counterpart to the attach point. Both can be seen as the male/female partof a connector and its receptacle.
Table 6-22: XML Tags for Anchor Point<CDB:Point
name = "Anchor_Point"/>

The orientation of the anchor point is used to indicate how the subordinate model connects to theparent model. A connection occurs by superimposing the anchor point (of the subordinate
model) with the attach point (of the parent model).
The default anchor point of a subordinate model is its origin.
6.6.2.5
Model Center of Mass
The Center of Mass (CM) of a Model is a specific point where, for many purposes, the Model
behaves as if its mass was concentrated there.

© 2015 Open Geospatial Consortium

353

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-23: XML Tags for Center of Mass
<CDB:Point
name = "Center_Of_Mass"/>

6.7
Model Conforming
Historically, the integration of models onto the terrain has been performed during the database
compilation process. These offline approaches varied considerably from vendor to vendor
because there were no standardized approaches related to terrain meshing structures, varying
visual priority and hidden-surface removal mechanisms, runtime LOD mechanisms, number ofLODs, etc.
This section describes a series of model conformal modes that instruct client-devices on how
they should conform models to the underlying terrain.
All of the conformal modes rely on the conforming of the model origin and/or model vertices
onto the terrain mesh directly beneath the model. Note that the Z-component of the model’svertices is with respect to model’s XY plane (as shown in Figure 6-36).
z
V1

y

z

V2

z

z

Vn

z

x

Elevv3z

Elevv1

Elevv2zzz

V3Conform	  vertices	
  to	
  terrain

ElevvnTerrain	
  profileFigure 6-36: Conforming Vertices to Terrain© 2015 Open Geospatial Consortium

354

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Note that by definition, all portions of the model below its XY plane represent some form ofunder ground basement. The conforming of models on steep or rough terrain may yield unusual
results because portions of the basement may be visible. This may require the modelers to level
the terrain in the immediate vicinity or adjust the model.
A modeler can specify a model’s conformal mode by adding the following XML tags to the zone
representing the model.

<CDB:Zone><Conformal mode="..."/></CDB:Zone>

The conformal modes are listed in Table 6-24 below.

Table 6-24: Conformal Modes
Conformal Mode
Absolute
Point
VertexLine
Plane
Surface

6.7.1
Non Conformal (Absolute) Mode
When attributed as a Non Conformal model, none of the model vertices are conformed to theunderlying terrain. Instead the model’s Z-values are used as-is, as elevation values. As a result
the model is absolutely positioned and behaves independently of the terrain. The shape andorientation of the model is preserved. This conformal mode is typically used for the modeled
representation of point-features. Typical use-cases include buildings, trees, and poles.
6.7.2
Point Conformal Mode
The Point Conformal mode conforms a single point of the model (its origin) onto the underlying
terrain. All of the other model vertices are translated along the Z-axis; as a result, the shape ofthe model is preserved by this conformal operation. In effect, the Point Conformal mode
dynamically positions a model on the underlying terrain so as to preserve the model’s relative
altitude over the terrain. Point-conforming is the default conformal mode for the modeled
representation of point-features. Typical use-cases include buildings, trees, and poles.

© 2015 Open Geospatial Consortium

355

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014zy
Hv
Model	  originx

Omodelzy

EtTerrain	
  profilex	
  Figure 6-37: Origin Conformal Mode

6.7.3
Vertex Conformal Mode
The Vertex Conformal mode conforms each of the vertices of a model on the underlying terrain.
The shape of the model is not preserved by this conformal operation. The model’s XY plane
defines a reference plane used by client-devices to adjust the elevation of each of the model’svertices. This conformal mode is used for 3D models that represent typically long 3D lineal
features or large 3D areal features that need to follow the terrain profile. Typical use include
fences, walls, trenches, and forest canopies.

© 2015 Open Geospatial Consortium

356

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Hv

Conform	  vertices	
  to	
  terrain

Ev

Et

Terrain	
  profileFigure 6-38: Vertex Conformal Mode Example

6.7.4
Line Conformal Mode
The Line Conformal mode conforms each of the two reference vertices of the “linear” model on
the underlying terrain. All of the other model vertices are sheared along this axis; as a result, theshape of the model is not preserved by this conformal operation. The model’s XY plane defines
a reference plane used by client-devices to adjust the elevation of the two reference vertices.
This conformal mode is used for models that represent lineal features such as powerlines andmonorails.

© 2015 Open Geospatial Consortium

357

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
z
y

Vs

Ve

x

Into	
  Terrain	
  coordinates

z

z

y

ElevvsTerrain	
  profile

Elevvex
Figure 6-39: Line Conformal Mode

The line that is used to specify the conforming is defined by a Face node with the following
XML tags:<CDB:Face><Conformal_Line/></CDB:Face>

This Face node defines a single line with two vertices, the first one, Vs, being the start and thesecond, Ve, the end of the line.
6.7.5
Plane Conformal Mode
The Plane Conformal mode conforms each of the three reference vertices of the “planar” modelon the underlying terrain. The resulting three vertices define a model transformation matrix that
can then be applied to the vertices of the model. As a result, the shape of the model is preserved© 2015 Open Geospatial Consortium

358

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
by this conformal operation, but the model undergoes a change in pitch and roll angles. Given
this property, there are relatively few cases where this conformal mode can be used61. However,as shown in Figure 6-41, this conformal mode is required when conforming the curved segmentsof 3D (raised profiled) modeled road features.

z
y

V p2

Mode

l	
  

z

V p3
V p1
O

O Vp1

x

Into	
  Terrain	
  coordinate
y

Vp

Vp

Model	  2

1

Vp
Figure 6-40: Plane Conformal Mode

61

Man-made structures and tree vegetation do not tilt regardless of the terrain they are on.

© 2015 Open Geospatial Consortium

359

3

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Plane	
  Conformal	  T2DModels

Vp1
Vs

Vp2	
  =	
  Vs

Ve	
  =	
  Vp2

Line	
  Conformal	  T2DModels
Figure 6-41: Application of Line and Plane Conformal Modes on 3D Roads

The plane that is used to specify the conforming is defined by a Face node with the following
XML tags:<CDB:Face><Conformal_Face/></CDB:Face>

The Face node has exactly 3 vertices defining the plane used for the conforming. The only
restriction on these 3 vertices is that they must not be collinear.
6.7.6
Surface Conformal Mode
This conformal mode is used for models whose points, edges and surfaces must all conform
exactly to the underlying terrain. The Surface Conformal mode requires that the model’s edges
and surfaces be clipped to the underlying terrain. The original vertices and the added vertices
resulting from the clipping operation are conformed to the underlying terrain. As a result, theshape of the model is not preserved by this conformal operation. This conformal mode is© 2015 Open Geospatial Consortium

360

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
primarily used for the modeled representation of 2D surface-feature such as paint markings andother terrain overlays. In addition, it can be used for 3D models that represent typically long orlarge 3D lineal and 3D areal features that need to perfectly follow the terrain profile. Note thatin most cases, the vertex conformal mode provides an adequate solution for 3D models and ismore economical to use than the surface conformal mode.
V

V

C

4

z

z

V

V

C

Clip	
  and	  conform	
  triangles	
  to	
  terrain

Elevv

Elevc

Elevv

Elevv

4

z

z

Clipped	  vertices

Terrain	
  profile
Elevc

Elevv

Figure 6-42: Surface	  Confomal	  Mode

6.8
Model Levels-of-DetailA levels-of-detail model structure is essential when the intent is to use a model in a real-time
application such as flight simulation. The level-of-detail mechanism provides client-devices
with the essential structure for deterministic operation. Deterministic operation can be achieved
only if a client-device can:control the paging bandwidth from the CDB main storage device
control client-device processing load
control client-device memory footprint
control run-time publishing processing load andcontrol run-time publishing memory footprint
For this reason, it is recommended to create LODs, especially for complex Models, and formodels that are used extensively, in great density in the CDB. This is most critical forgeospecific cultural models (especially in densely modeled geospecific areas of the synthetic
environment) since they can consume a significant portion of the paging bandwidth and memory
footprint of the client-devices. As a corollary, simple Models should not be made more complex© 2015 Open Geospatial Consortium

361

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
by adding unnecessary level of details. The CDB Specification provides rules for determining
model complexity, and selecting the appropriate LOD, as defined in Chapter 3.
OpenFlight LOD nodes now support two methods of specifying the criteria to determine if alevel of detail is active, that is if the user application should traverse the node and its children.
The first method, the classic one, is to specify the switch in and switch out distances in realworld units. Using this method, a level of detail is active when the distance from the viewpoint
to the center of the LOD is within the switch-in and switch-out distances. The second method
uses the Significant Size associated with the LOD node to determine when to activate the node.
The CDB Specification requires using the second method as it provides much better andmore accurate results than the classic method.
There are several problems associated with the classic, range-based method. In a visual system
for instance, the switching distance should be based on both range and the system resolution of
the entire visual system; a database designed to rely solely on a range-based switching criteria is
not truly portable, especially if the intent is to use it on systems with wildly different visual
resolution. Furthermore, the blending or morphing of models solely based on range criteria canlead to undesirable effects. When the viewpoint moves quickly, the distance over which themodel is LOD-transitioning should be large enough to avoid the “popping-in” of the higher LOD
version. On the other hand, if the viewpoint is moving very slowly, the distance over which themodel is LOD-transitioning should be reduced to avoid the “LOD-ghosting” of the higher LOD
version. These two constraints make implicit assumptions on the model’s speed. In applications
where the aircraft’s flight regime varies considerably (V22 for example), it is impossible to finda single set of LOD start and end points that simultaneously cater to all flight modes (hoverversus cruise). Here again, a database design that directly encodes the start and end points of amodel’s LOD transition is not truly portable, because it makes implicit assumptions on the speed
it will be used for. Thus, in a tactical fighter application, the start and end points of a model’s
LOD transition need to be widely spaced apart to prevent a popping effect at the onset of the
LOD transition. Conversely, in a tank application, the start and end points of a model’s LOD
transition need to be much more closely spaced to prevent a ghosting effect as the higher LOD
model is blended-in. If the client device wants to implement some form of transition between
LODs, the criteria should be based on a user-defined duration. Transitions between LODs caninvolve fading in the next LOD while fading out the current one. That fading operation should
not last forever. It should be accomplished in a relative short period of time. The second method
to transition from one LOD to the next is to use morphing. In the case of morphing, thetransition period is less critical because the client-device (typically an Image Generator) does notblend-in two models together.
The consequences of such implicit assumptions result in a database that is highly client-device,
and application-specific.
For all these reasons, the CDB Specification has selected the second method to control the LOD
mechanism.
Two methods exist to implement LODs, exchange or addition. The two methods can be usedsimultaneously and are not mutually exclusive.

© 2015 Open Geospatial Consortium

362

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In the first method, details are progressively added to the model, as the viewpoint gets closer.
With the second method, different representations of the same model are substituted for one
another based on the viewing distance. Figure 6-43: Exchange and Additive LOD Nodes,
illustrates the general organization of Models with both types of LOD nodes.
6.8.1
Exchange LODs
In the exchange LOD method, different representations of the same model are substituted for one
another based on the model’s Significant Size. It is up to the client-devices to derive appropriate
LOD transition viewing distance from the model’s Significant Size and the client-device’s fieldof-view and resolution parameters.
6.8.2
Additive LODs
Additive LOD is just a special case of the more general Exchange LOD paradigm. When a LOD
node has no sibling LOD, it becomes an Additive LOD node. That does not change the fact thatat most one LOD node gets selected when its Significant Size justifies it.

Figure 6-43: Exchange and Additive LOD Nodes

The LOD nodes in light brown represent Exchange LODs and are mutually exclusive. The two
dark brown shaded LOD nodes are considered Additive LODs because they do not have anothersibling node of type LOD.
Note that to make sense, the Significant Size of LOD node 2 must be less than the Significant
Size of LOD node 1. The same is true for the Significant Size of LOD node 3 with respect to
LOD node 2. Also, LOD node 3 has an additional constraint, its Significant Size must be greater© 2015 Open Geospatial Consortium

363

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
than the one assigned to LOD node 4. If these constraints are not followed, LOD node 4 will beselected before LOD nodes 2 or 3 have a chance of being displayed.
6.8.3
Significant Size
The concept of a Significant Size is a recent improvement of the OpenFlight Specification.
When a finer model LOD is created, the modeler typically adds additional geometric detail,additional features (such as markings), or refines the shape of curved surfaces (such as engines,
wheels), etc. When assigning a Significant Size to a model LOD, the modeler needs to answer
the following question: When I created a new model LOD, I did so to create additional detail in
my model. What is the largest dimensional change in geometry for this new model LOD? In
other words, what is the largest dimensional difference of a surface between this LOD and thenext coarser LOD? In effect, the value of Significant Size corresponds to the “modelingdifference” between the LOD and the next coarser LOD. At runtime, a client-device converts
this modeling difference value from its real-world dimensional value into a viewing error value(typically measured in pixels or degrees). The client-device can then activate the appropriate
model LOD because it knows that the modeler’s intent in creating the LOD was to showfeatures, eliminate all modeling discrepancies whose dimension equaled that of the Significant
Size dimension associated with that model’s LOD. This contribution of the LOD to the scene isbased on the LOD’s Significant Size as well as other parameters (such as system resolution)
relevant to the simulation model used by the client device. Note, that in the case of the coarsest
LOD, the Significant Size should be set to the bounding sphere dimension of the model (because
the “error” introduced by the coarsest LOD amounts to the entire model).
Version 16.0 of the OpenFlight Specification introduces the concept of Visual Significance thatis different from the concept of Significant Size. The concept of Visual Significancetranslates in two fields called Significance and they are found in the Group Record
and Object Records62. Here is the definition of this field as found in reference [11]:“Significance can be used to assist real-time culling and load balancing
mechanisms, by defining the visual significance of this group with respect to othergroups in the database. Normally the value of this attribute is zero”.
The CDB Specification mandates a value of zero for Visual Significance; the value zero
indicates the object or the group has no particular significance and is not more orless important than any other objects or groups. Any other values, whether negativeor positive, are reserved for future use by this Specification.

6.8.3.1
Significant Size – Coarsest LOD
Special consideration is required when generating a value for the Significant Size of the coarsest
LOD of a model, SSc. Ideally, the Significant Size is proportional to the “error” caused by the62

Users of Creator 3.0 will find the exact same definition for Significance in both the Group and Object Attributes
Help pages.

© 2015 Open Geospatial Consortium

364

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
fact the model’s coarsest LOD is blended-out and discarded. As a result, the nominal value for
SSc is simply the Size of the feature.
More specifically, we define the Significant Size of Models corresponding to Features:
Models of 2D Lineal Features: The Significant Size of the modeled
representation of 2D lineal feature is defined as the width of the lineal feature.
The Size of the feature is independent of its modeled LOD representation; it does
not vary with each level-of-detail representation. As a convention, it should be
set to the largest width of the feature’s finest level-of-detail representation.

𝑆𝑆𝑆𝑆 =   𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 = 𝑊𝑊𝑊𝑊𝑊𝑊𝑊𝑊ℎ(2𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷)

Models of 2D Areal Features: The Significant Size of the modeled
representation of a 2D areal feature is defined as the square root of the area
occupied by the areal feature. The Size of the feature is independent of its
modeled LOD representation; it does not vary with each level-of-detail
representation. As a convention, it should be set to the worst-case width of thefeature’s finest level-of-detail representation. Note that the areal does not need tomodel a single surface, i.e., an areal feature may consist of multiple discontinuous
surfaces. Features whose Significant Size is larger than 110 km (the dimension of
a geocell) must be clipped (if a continuous surface) or ungrouped (if multiple
discontinuous surfaces) until the maximum size criteria is met.

𝑆𝑆𝑆𝑆 =   𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐹𝐹𝐹𝐹𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 =𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴(2𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷)

Models of 3D Point Features: The Significant Size of the modeled
representation of a 3D point feature can be derived (through automation) from its
bounding box dimensions. The Size of the feature is independent of its modeled
LOD representation; it does not vary with each level-of-detail representation. The
Feature is usually inserted into thescene near the horizon by most client
devices. As a result, the optimalvalue for its Size is one thatapproximates a disk whose area is thesame as that of a cube of dimensions(H,W,L) viewed near the horizon(with a downward angle of 15 degrees) as follows:

𝑆𝑆𝑆𝑆 =   𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹)    =𝑆𝑆𝑆𝑆 =   𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹) =   𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 +    𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝑡𝑡𝑡𝑡𝑡𝑡

  𝜋𝜋

𝐻𝐻×cos  (15𝑜𝑜 )×𝑀𝑀𝑀𝑀𝑀𝑀 𝑊𝑊, 𝐿𝐿© 2015 Open Geospatial Consortium𝜋𝜋+    𝑊𝑊×𝐿𝐿×sin  (150 )  365Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Note that the Feature’s Size is based on the Feature’s bounding box dimensions.
In the case where the Feature occupies a relatively small portion of its boundingbox, then the Significant Size should be reduced by a factor proportional to thesquare root of the cross-sectional coverage; Fcs varies in the range of (0..1).
Finally, the value of 𝑆𝑆𝑆𝑆 can be adjusted (increased or decreased by as much as 2X from its
nominal value) to produce an “effective Significant Size” 𝑆𝑆𝑆𝑆 through a function that uses themodeler-provided Relative Tactical Importance (RTAI) attribute. Note that the function ensures
that…
𝑆𝑆𝑆𝑆 = 𝑆𝑆𝑆𝑆 when RTAI = 50,
𝑆𝑆𝑆𝑆 = 2𝑆𝑆𝑆𝑆 when RTAI = 100 and
𝑆𝑆𝑆𝑆 = 𝑆𝑆𝑆𝑆 /2 when RTAI = 0.
In summary, the Significant Size is as per the equations below…

SS nom = Size ( Feature )SS nom = SS nom × Fcs

SS c = f ( SS nom , RTAI feature )⎛ SS nom ⎞⎟ ≤ SS c ≤ (SS nom × 2 )⎜⎝ 2 ⎠SS c = f ( SS nom ,50)

Moving Models: The Significant Size of a Moving Model can be derived(through automation) from its bounding sphere dimensions. The Size of thefeature is independent of its modeled LOD representation; it does not vary witheach level-of-detail representation. Unlike features, moving models can berendered in any orientation; as a result, the value of Significant Size is its
Bounding Sphere Diameter:

𝑆𝑆𝑆𝑆 = 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀= 2  𝑥𝑥  𝐵𝐵𝐵𝐵𝐵𝐵

6.8.3.2
Significant Size – Other LODs
All 2D and 3D Features can have multiple modeled representations (aka 2DModel-LODs and3DModel-LODs). Each 2DModel-LOD and 3DModel-LOD is assigned a Significant Size value,
SSLOD that is representative of the dimension of the “modeling difference” between the LOD andthe next coarser LOD.

© 2015 Open Geospatial Consortium

366

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
This value can be derived through automation or explicitly provided by the modeler. In theevent it is not provided by the modeler, a default value is automatically generated as follows:
1. Compute the value of 𝑆𝑆𝑆𝑆    for the coarsest Model-LOD as described above.
2. Get the number of vertices (Vcoarsest) corresponding to LODcoarsest
3. Get the number of vertices (VLOD) corresponding to the Model-LOD.
𝑉𝑉
4. Compute the ratio of vertices 𝑅𝑅 =     𝑉𝑉

5. The Significant Size of the model’s current LOD is 𝑆𝑆𝑆𝑆′ = 

6.8.4
LOD Node Ordering
OpenFlight does not impose any constraint on the ordering of sibling LOD nodes. For thisreason, all nodes would have to be tested because the runtime system is searching for the LOD
node with the smallest Significant Size that still contributes to the resulting image.
Consequently, the CDB Specification requires that LOD nodes be ordered. This ordering
improves client device performance without being specific to any client-device (since it can be
costly to test all nodes to select just one).
To illustrate the need for ordering LOD nodes, consider the case where a modeler needs to createa realistic representation of a small town with several hundred buildings. The level of details of
the town must accommodate low altitude flight with a helicopter. After a few tests, the modeler
decides to model each building with three levels of details as shown in Figure 6-44: Exchange
LOD Nodes.

Figure 6-44: Exchange LOD Nodes

Now, consider the case where the simulated ownship has an entire city visible (thousands ofModels) within the field of view of the visual system. This situation forces the IG client device
to test all of the LOD nodes of all Models if these nodes are not sorted. However, if the nodes
are sorted, it is possible to test only a subset of all nodes to find out which ones to display.
Which order is best? Ascending or descending order?
If all buildings are visible, the majority will be located far from the viewpoint while only a few
will be near the viewpoint. In general, only few models fit near the viewpoint, and that number
increases with the distance.

© 2015 Open Geospatial Consortium

367

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
If LOD nodes are sorted in ascending order of their Significant Size, the client device quickly
selects the finest LOD of Models located near the viewpoint. Indeed, only one test is necessary
to select the correct LOD node in these models. However, for Models located farther, the client
device has to perform two or three tests to select the correct nodes. If LOD nodes are sorted inascending order, a single test is done on a small number of LOD nodes while two or three tests
are performed on the majority.
On the other hand, if nodes are sorted in decreasing order of their Significant Size, the client
device performs three tests to select the finest LOD only on a limited number of models near the
viewpoint. For a larger number of models, two tests are required. Moreover, for an even larger
number of models, the ones located far away from the viewpoint, a single test is enough to selectthe coarsest LOD, if it gets selected at all.
The second approach allows for a smaller number of tests to select the correct LODs, and is themethod selected by the CDB Specification. As a result, LOD nodes must be sorted in decreasingorder of their Significant Size attribute. As a corollary, the CDB Specification also requires thatsibling LOD nodes be mutually exclusive.
6.8.5
LOD Generation Guidelines
While the CDB Specification does not enforce the use of LODs for modeled OpenFlight culture,
it is strongly recommended. Without LODs, client-devices are heavily hampered in their effort
to assure an acceptable level of determinism. Given its mandate, the CDB Specification cannot
enforce guidelines that would favor some particular client-device types at the expense of others.
Nonetheless, it is clear that models built without LODs will be problematic to ALL clientdevices. Likewise, models built to wildly varying content (as opposed to content organized in ageometric progression) will also be problematic to ALL client-devices.
As a result, the CDB Specification provides the following guidelines to help modelers decide on
the number of LODs needed, their geometric complexity, their Significant Size, etc.
The coarsest LOD should be the simplest possible geometric representation of
the object; it can be as simple as a colored (or textured) box.
A model LOD is created by removing details from the next finer LOD (oralternately by adding details to the next coarser LOD). The model component
details to be included in a LOD must be consistent with the Significant Size
associated with the model LOD.
The geometric complexity of model LODs should follow a regularprogression with increasing LODs. Large increases in geometric complexity
for adjacent models LODs are discouraged because they reduce thedeterminism of client-devices63. The number of polygons in a model LOD

63Consider the case where a tank is modeled with only two levels of detail. The coarser LOD is a simple box. The
finer LOD is an extremely detailed representation of the tank complete with individual links on its tank treads; themodel has 100,000 polygons. Clearly a switch to the finer LOD representation produces a large step change in avisual system client-device memory footprint and in its computation load. The size of the step change will likely© 2015 Open Geospatial Consortium

368

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014provides a reasonable (first-order) measure of geometric complexity and ofcomputational load incurred by client-devices sensitive to geometriccomplexity.
NOTE: For a visual system, the subtended angle of a model on screen decreases by 2 when its
distance from the viewpoint increases by a factor 2. The human eye has an angular resolution of
about 1/60 of a degree or 1 minute of an arc. This means a 1-meter tall object appears as a single
point at distance of approximately 3.5 kilometers. At the other end, if the same object is 2
meters from your eyes, you could distinguish details that are as small as 0.5 millimeter.
Likewise, the angular surface area occupied by a model on screen decreases by 4 when its
distance from the viewpoint increases by a factor 2.
Refer to section 6.8.3, Significant Size for a description of the relationship between Significant
Size, Model LOD, and the number of vertices used to represent a model.
6.9
Model Switch Nodes
A Switch Node allows the selection of zero or more children by invoking a selector mask. Any
combination of children can be selected per masks and the number of definable masks isunlimited. The CDB Specification makes use of OpenFlight Switch Nodes to control the state ofModel Components (zones and points).
6.9.1
Definition
XML tags in the comment record are added to the switch’s primary record to identity it as a CDB
Switch.
Table 6-25: XML Tags to Create a CDB Switch<CDB:Switch name = "switch name">... switch attributes</CDB:Switch>

The switch must contain one mask per state. As an example, if the switch has 3 children, each
representing a separate state of the parent zone, then the switch needs 3 masks, each selecting
one child.
In addition to defining a mask for each switch state, the CDB Specification demands that eachmask be named. The name of the mask must be representative of the state selected by that mask.
The actual name is at the discretion of the modeler.
The corresponding OpenFlight records are as follow:

exceed any built-in margins (memory footprint or processing time) in the client-device and will lead to a nongraceful overload situation.

© 2015 Open Geospatial Consortium

369

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-26: OpenFlight Records to Create a CDB Switch
SWITCHCOMMENT (mandatory)
INDEXED STRING

Note that the first mask, mask index 0, is the default mask. This means that the value of theCurrent Mask field in the Switch record must be 0.
6.9.2

Usage

6.9.2.1
Articulations
Switch nodes provide an alternative to DOF nodes when an articulated part is implemented for
only a few positions. An example of this use of switches is the control of undercarriage orcontrol surfaces on aircraft. Suppose the modeler wants to represent the flaps in two distinct
positions: flaps up and flaps down. A switch is the simplest way to implement these two flaps
positions. In this example, the switch name could be “Flap Control” and the two mask names
could be “Flap Up” and “Flap Down”.
Suppose the modeler wants to provide two positions for the door on a hangar: open and close. In
addition, when the door is open, the modeler provides a representation for the interior of thehangar, which is not the case when the door is closed. Again, the use of a switch is appropriate
to provide the control over the door position. A proper name for the switch would be “Door
Position” and the appropriate names for the two masks would be “Door Closed” and “DoorOpen”.
6.9.2.2
Damage States
Switch nodes can be used to select one of many modeled representations of damages. A zone has
at least a normal (usually undamaged) state. When other states exist, an OpenFlight switch nodeis used to select which state is active. A single damage state can be active at any time. Figure
6-45: General Damage State Tree Structure shows the general organization of a zone withseveral states.

Figure 6-45: General Damage State Tree Structure© 2015 Open Geospatial Consortium

370

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Each damage state represents the zone with a certain level of damage. This level of damage isexpressed as a percentage from 0 to 100%. A level of damage of 0 % means the zone is notdamaged at all. At the opposite end, a percentage of damage of 100 % indicates the zone iscompletely destroyed.
To identify a damage state switch, use the following XML tags in the switch comment record.
Table 6-27: XML Tags for Damage State Switch<CDB:Switch name = "Damage_State"><Damage_Level>...</Damage_Level></CDB:Switch>

The XML element <Damage_Level> is a list of percentages representing the transitions between
child nodes of the switch. The list counts ‘n-1’ entries where ‘n’ is the number of states.
The percentages representing the transitions are limited to the range [0, 99]. The value 100 is notallowed because the level of damage must exceed the transition value in order to select thecorrect state.
To illustrate the concept of level of damage, assume a damage state switch has 3 child nodes
representing the zone in normal, damaged, and destroyed states. Also, assume that the modeler’s
intent is to switch to the damaged state when the level of damage exceeds 25 %, and to switch to
the destroyed state when the level of damage exceeds 75 %. Here, the XML tag associated withthe switch should look like this.
Table 6-28: Example of a Damage State Switch with Two Transitions<CDB:Switch name = "Damage_State"><Damage_Level>25 75</Damage_Level></CDB:Switch>

The ordering of damage states must be from left (normal state) to right (destroyed state). Allintermediate states must represent increasingly damaged states from a slightly damaged state toan almost destroyed state. The number of states is left to the discretion of the modeler.

© 2015 Open Geospatial Consortium

371

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-46: Damage States Ordering

While the number of damage states is left to the discretion of the modeler, some choices are
better than others. Since a Model is meant to be used in a simulator and since many simulators
are DIS-compliant, it is suggested to create the same number of CDB damage states as there are
DIS damage states for the corresponding entity.
For instance, if the Model represents a DIS land platform such as the M1A2 tank, the modeler
could create four damage states to match the four corresponding DIS damage states labeled No
Damage, Slight Damage, Moderate Damage and Destroyed.
The DIS and the HLA standards are relatively vague regarding the definition of damage states.
In the case of the DIS standard, the damage state is a field that belongs to a structure called the
Entity Appearance. The field has only 2 bits and, accordingly, accommodates four different
values. For HLA, version 2 of the RPR-FOM defines the damaged appearance as a 32-bit
enumeration for which only 4 values have been defined so far – the same values as the one
defined by DIS, that is No Damage, Slight Damage, Moderate Damage and Destroyed.
For both DIS and HLA, it is obvious that the damage state is meant to be a visual damage state.
The question to answer is the following: “What should the universally accepted visualappearance be for a slightly (or moderately) damaged state?”
In the DIS world, a platform is often qualified in terms of Mobility and Fire Power64. Using
these two criteria, it is possible to define the following guidelines.
A slightly damaged model should represent a platform with limited mobility.
However, its firepower is intact and it should be apparent that the entity is still
capable of firing its weapons.
64

Note that, on top of the Damage State field, the DIS Entity Appearance structure has two flags to describe the
Mobility and Fire Power of the entity. This is also true for HLA and version 2 of the RPR-FOM which provides for
two flags to describe the fire power and mobility of a physical entity on top of the field used to describe the damage
state.

© 2015 Open Geospatial Consortium

372

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
A moderately damaged model should represent a platform for which both
mobility and firepower are reduced without being completely out of service.
As a corollary, here are the definitions of normal and destroyed states.
An undamaged model should represent a platform for which both mobility
and fire power are completely operational.
A destroyed model should represent a platform for which both mobility andfirepower are completely out of service.
6.9.2.3
Temporal Anti-aliasing
Temporal anti-aliasing may be achieved with the use of special textures. These textures are often
required to aid IG client-devices to eliminate strobing effects on model rotating objects such as
helicopter rotors, aircraft propellers, or vehicle wheels.
Figure 6-47: Example of a Texture Representing a Rotor, is an example of a semi-transparent
texture used to simulate a rotating helicopter rotor.

Figure 6-47: Example of a Texture Representing a Rotor

Motion blur textures are general base textures with a Texture Kind of S001. The Texture Index(Tnn) is used to sequentially number several motion blur textures representing the same object.
The use of motion blur textures can be combined with DOF and Switch nodes to produce
efficient switching between several versions of a single rotating part.
The following subtree illustrates how four versions of the above rotor could be modeled using
one solid version and three blurred versions.

© 2015 Open Geospatial Consortium

373

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-48: Multiple Versions of Rotating Parts

In this example, three textures are used to represent an increasingly blurred rotor.
In order to detect the presence of the above construct, the following XML comment must be
added to the switch node.
Table 6-29: XML Tags for Motion Blur Switch<CDB:Switch name = "Motion_Blur"><Blurriness>...</Blurriness></CDB:Switch>

The children of the switch node could be any OpenFlight nodes. Most likely, the nodes that
contain the geometry will be OpenFlight Object nodes.
When modeling solid and blurred objects in this manner, the CDB Specification requires that theleftmost child node contains the solid version of the object while the sibling nodes to the rightcontain increasingly blurred version of the same object.
The XML element <Blurriness> is a list of percentages representing the transitions between childnodes of the switch. The list counts ‘n-1’ entries where ‘n’ is the number of child nodes.
The percentages representing the transitions are limited to the range [0, 99]. The value 100 is notallowed because the level of blurriness must exceed the transition value in order to select thecorrect child node.
To illustrate the concept of level of blurriness, assume a motion blur switch has two child nodes.
Also, assume that the modeler’s intent is to switch to the second node when the level ofblurriness exceeds 10 %. Here, the XML tag associated with the switch should look like this.

© 2015 Open Geospatial Consortium

374

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-30: Example of a Motion Blur Switch with One Transition<CDB:Switch name = "Motion_Blur"><Blurriness>10</Blurriness></CDB:Switch>

6.10

Model Articulations

6.10.1
Definition
An OpenFlight DOF node is used to implement the concept of a CDB Articulation. The node
gives the modeler controls over all 9 degrees of freedom, translation, rotation and scaling on all 3
axes. Generally, only one degree of freedom is allowed at a time and most often, that single
degree of freedom is a rotation about a single axis. However, the modeler is free to allow any
translation, rotation and, even scaling; even though stretching an articulation does not usually
produce a realistic effect.
Since only one articulation is allowed per zone, the zone name is sufficient to identify andcontrol the DOF node.
A CDB Articulation node is an OpenFlight DOF node with attributes in the form of XML tags.
The table below presents the syntax of the XML tags stored in the DOF node’s comment record.
Table 6-31: XML Tags for DOF<CDB:Articulation name="name" id="id"><Translation><X rate="value" /><Y rate="value" /><Z rate="value" /></Translation><Rotation><X rate="value" /><Y rate="value" /><Z rate="value" /></Rotation><Scaling><X rate="value" /><Y rate="value" /><Z rate="value" /></Scaling></CDB:Articulation>

The above XML tag is necessary in two circumstances:
1. The articulation represents a DIS Articulated Part.
2. The articulation is to be animated automatically.
A CDB Articulation node has an optional name that is used to self-document the articulation.
The optional identifier provides the corresponding DIS Articulated Part. It is suggested to use a© 2015 Open Geospatial Consortium

375

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014name inspired from the DIS Articulated Part ID, when the identifier is supplied. For instance,
DIS identifies as Primary Gun 1 the articulated part whose ID is 4416. That example would
generate the following XML tags:<CDB:Articulation name="Primary Gun 1" id="4416" />Section 4.7.3 in reference [4] provides a list of DIS Articulated Part IDs.
It is possible to specify an optional Rate-of-Change for each Degree of Freedom along their X,
Y, and Z axes for Translation, Rotation, and Scaling. The translation rate is expressed in meters
per second. The rotation rate is expressed in degrees per second. Finally, the scaling rate is inunits per second. When not specified, a default rate of zero is assumed.
For instance, a primary radar antenna that rotates at a rate of 10 degrees per second about its Zaxis would require the following XML tags:<CDB:Articulation name="Primary Radar 1" id="5376"><Rotation><Z rate="10"/></Rotation></CDB:Articulation>

Another example, to illustrate how to attribute a rotating wind mill; assuming the mill rotates
about the Y-axis at a rate of 5 degrees per second:<CDB:Articulation><Rotation><Y rate="5"/></Rotation></CDB:Articulation>

Gimbal limits are mandatory on DOF nodes and the appropriate flags must be set to specify
which degrees of freedom are controlled by a particular articulation. The Flags field is located atoffset 376 in the OpenFlight DOF record and its value cannot be zero because the articulationmust control at least one degree of freedom.
6.10.2Usage

6.10.2.1 Rotating Parts
A common problem in simulation is to correlate the linear speed of a model with the angularspeed of its wheels. More generally, the client device simulation models often require thedimension of rotating parts. This information can be obtained from the zone extent; thebounding box surrounding a zone provides the dimension of rotating parts.
6.11
Model Light Points
The CDB Specification does not make a distinction between light points and light sources. Bothrepresent real lights that emit light and that can illuminate neighboring objects. In most current
visual systems, a light point is a simple representation of a point source of light when viewed© 2015 Open Geospatial Consortium

376

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
from a distance; it has no observable lighting effect on its immediate surroundings. In real-life
however, as an observer moves closer to the light, its lighting or illuminating effect on thesurrounding objects becomes increasingly observable; furthermore, the actual shape of the lightalso becomes more distinct.
In a typical simulator, client-devices may choose to limit the representation of the light to asingle point and neglect the illuminating effect of the light on neighboring objects and terrain.
For this reason, it is up to the client (and its RTP) to determine whether a light can illuminate its
surroundings or not; the decision is based on the type of light and the inherent
capabilities/capacity of the client.
Another point to consider is the fact that a light may have a very different representation
depending on the client device. For instance, consider the visual representation of a light by an
IG compared with the representation required by a radar system, NVG device or a FLIR device.
For all of these considerations, the CDB Specification has adopted the following approach indefining lights. The OpenFlight file defines only the position, direction and the name of the light
type; no other attributes are specified. The CDB Specification provides a very elaborate lighttype naming convention. This convention permits clients to internally derive all of the properties
and parameters needed to render the light. The approach is entirely device-independent.
Modelers need not concern themselves with hundreds of parameters, many of which are often
specific to underlying algorithms within the client. The naming convention ensures that theclient has all of the information needed to capture the modeler’s intent. Because the approach isdevice-independent, the rendering is limited only by the client’s capabilities, not by the database
itself.
As a result, lights in OpenFlight are defined by inserting an Indexed Light Point record into the
OpenFlight scene graph. A vertex and a normal are stored in a Vertex List record that defines
the position and direction of the light. The name of the light type is stored in the Light Point
Appearance Palette record.
The light type’s name fully defines the appearance, animation and other characteristic relevant to
the field of simulation. It is the responsibility of the client to supply the internal parameters that
correspond to each of the light types supported by the CDB Specification.
Light type naming conventions are defined in Section 2.3, Light Naming, and the list of names ispresented in Appendix E.
A Vertex List record must follow the OpenFlight Indexed Light Point record. The list of vertices
contains one vertex if a single light point is defined. The list contains several vertices when
multiple independent light points are defined. An optional matrix and replication count permits
the definition of a light string.

© 2015 Open Geospatial Consortium

377

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 6-32: OpenFlight Records for a Light Point
INDEXED LIGHT POINT
MATRIX (optional)
REPLICATE (optional)
PUSH LEVELVERTEX LIST
POP LEVEL

6.12
Model Attributes
This section defines a general attribution mechanism to add CDB and Vendor-specific attributes
to any OpenFlight nodes. These attributes follows the rules of inheritance; they areautomatically propagated from higher levels through lower levels of the OpenFlight graph. A
child node inherits the attribution of its parent node.
6.12.1
Definition
Model attributes are added to OpenFlight nodes through a Comment record containing XML
tags. The general format is as follow:<CDB:node name="..."><ns:Attribute name="..." value="..."/>... other attributes</CDB:node><CDB:node> identifies the node to which the attributes are added. The node token can take thefollowing values:
Zone
Point
Group
ObjectSwitchFace
MeshArticulation
Light
XRef
LOD
The XML namespace (ns) of the attribute is optional; when present it identifies the owner of theattribute. When not specified, the default namespace is CDB.

Any CDB Attributes that are listed in section 5.7.1.3 can be used as node attributes. The name of
the attribute is the key to search for the matching symbol into the metadata file named
CDB_Attributes.xml; this file is described in section 5.1.7 and provides the means to interpretthe value of the attribute.

© 2015 Open Geospatial Consortium

378

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.12.2
Vendor Attributes
A vendor attribute is identified by its XML namespace. The Specification uses the CDB
namespace; a vendor may use any other string to identify itself. The definition of vendor
attributes must be stored in Vendor_Attributes.xml.
It is understood that vendor attributes are not interpreted by any other client-devices other thanthose supported by the vendor. Reliance by a vendor on Vendor Attributes can reduce theinteroperability of the CDB with other vendors.
6.12.3
ExamplesTo add the LPH attribute to a CDB Light node, use the following comment:<CDB:Light><Attribute name="LPH" value="300"/></CDB:Light>

Assume a T2DModel contains the Los Angeles International Airport as one of its 2DModels; thezone associated with the airport could use the APID attribute in the following manner:<CDB:Zone name="Los Angeles International Airport"><Attribute name="APID" value="KLAX"/></CDB:Zone>

A company named “Acme Inc.” uses the string “Acme” as the namespace qualifying its vendorspecific attributes. If the company wants to add the MyAttr attribute to a CDB Articulation, it
could do so by using the following XML tags:<CDB:Articulation name="Primary Gun 1" id="4416"><Acme:Attribute name="MyAttr" value="-1.23"/></CDB:Articulation>

To interpret the attribute, a client application searches the file Vendor_Attributes.xml for an
attribute whose symbol is MyAttr. When found, the application knows how to parse andinterpret the attribute’s value. Furthermore, if the client application recognizes the identificationof the vendor (Acme:), it knows what to do with MyAttr.

© 2015 Open Geospatial Consortium

379

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.13
Model Textures
To achieve a certain degree of realism, models require the use of textures. Furthermore, textures
add details to a model without increasing its polygon count. This is excellent to reduce thecomplexity of the geometry but at the same time, it creates a load management issue for client
devices that are interested in these textures. In the case of GTModels and MModels, textures are
separate files that must be loaded after the model geometry files are read and loaded by client
devices; in the case of GSModels and T2DModels, the textures can be loaded concurrently withthe model geometry files. A client device discovers the existence of textures while loading themodel.
One of the goals of the CDB Specification is to allow client devices to implement efficient load
management mechanisms. For this reason, the Specification decouples as much as possible thetexture aspect of a model from its geometry aspect. This is done by storing all textures related toModels in separate directories.
Recall that the texture filenames itself are constructed from the dataset number, the texture type(selectors 1 and 2), and the texture LOD and these are then concatenated to a modeler-specifictexture name. Section 6.13, Model Textures, provides a description and usage of all of the CDB
texture types for Models. The values of component selectors 1 and 2 convey a semantic meaning
to the texture (time-of-year, paint scheme, night map, light map, normal map, etc) and determine
whether the texture is to be used as base texture or as a subordinate texture and whether the
texture is switchable (described in the next section).
6.13.1
Handling of Multi-textures
In OpenFlight, several types of textures can be applied in various combinations. Textures fall in
two broad categories: Base and Subordinate.
6.13.1.1 Base Texture Layer
Base textures65 are set of mutually exclusive model textures that provide texture color/intensity
modulation for the model. While a model can have many base textures, only one base texture
can be referenced and applied to model geometry at a time.
The CDB Specification supports the following type of Base Textures:(1) Year-Round Texture: A year-round texture used with GTModels, MModels,
GSModels, T2DModels . In the case of MModels, base-textures are often
replaced with an appropriate Paint Scheme texture (Uniform, Camouflage or
Airline).
(2) Quarterly Textures: A set of 4 textures, each representative of a quarter within
the calendar year used with GTModels, GSModels, T2DModels . The textures
must be provided as a complete set, i.e., it is assumed that all 4 textures of thesame kind (i.e., all four textures have their component selector 1 set to 003) and65

The CDB Specification uses the term “base texture” the same way as OpenFlight and Creator do.

© 2015 Open Geospatial Consortium

380

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
are all present in the model’s texture directory. The presence of a quarterly texture
reference in model geometry tells the client-device that a quarterly texture set isavailable. This allows the client-device to select any one of the available 4
textures at rendering time. Only one of the textures need be referenced by the
OpenFlight scenegraph geometry, preferably the third quarter texture. It is also
assumed that all 4 textures share the same UV mapping.
(3) Monthly Textures: A set of 12 textures, each representative of a month within
the calendar year used with GTModels, GSModels, T2DModels . The textures
must be provided as a complete set, i.e., it is assumed that all the 12 textures areof the same kind (i.e., all twelve textures have their component selector CS1 =002) and are all present in the model’s texture directory. The presence of amonthly texture reference in model geometry tells the client-device that a montly
texture set is available. This allows the client-device to select any one of theavailable 12 textures at rendering time. Only one of the textures need bereferenced by the OpenFlight scenegraph geometry, preferably the June texture. It
is also assumed that all 12 textures share the same UVmapping.
(4) Uniform Paint Scheme Textures: Used on MModels with relatively uniform
paint schemes should make use of this texture kind. Colors are listed in Appendix
O. It is also assumed that all textures share the same UVmapping.
(5) Camouflage Paint Scheme Textures: Used on MModels with camouflage paintschemes should make use of this texture kind. Camouflages are listed inAppendix O. It is also assumed that all textures share the same UVmapping.
(6) Airline Paint Scheme Textures: Used on MModels that represent commercial
aviation airliners should make use of this texture kind to implement the airlines
paint scheme and logos. This base texture addresses the need for multiple skins
painted on identical aircraft type. For instance, the B767-300ER is operated bymore than 60 airlines throughout the world. Appendix O provides a complete listof Airliners. It is also assumed that all textures share the same UVmapping.
(7) Shadow Map Textures: Used on MModels as pre-computed orthographic
projections of the MModel. These textures are base textures used to accelerate
the rendering of MModel shadows. Shadow map usage conventions are describedin section 6.13.5.1, Model Shadow Textures.
(8) Motion Blur: Used on MModels as pre-computed motion blurred textures ofrotating parts (e.g., rotor disks). These textures are base textures used to aid
client-devices in eliminating temporal aliasing artifacts. Motion blur textures
conventions are described in section 6.9.2.3, Temporal Anti-aliasing.
6.13.1.2 Subordinate Texture Layer
Base textures can be supplemented with one or more66 subordinate textures. Subordinate
textures form a set of model textures that can be used to provide additional color/intensity
modulation or illumination modulation detail to the Base texture.
66

texture.

OpenFlight natively permits up to seven subordinate textures for a total of eight textures including the base© 2015 Open Geospatial Consortium

381

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The CDB Specification supports the following types of subordinate textures:
(1)

(2)

(3)
(4)

(5)
(6)
(7)
(8)

Night Map: This subordinate texture is used to represent changes to models intheir night configuration, typically as a result of lighting effects emanating frominside the model through windows. Night map textures conventions aredescribed in greater detail in section 6.13.5.3, Model Night Maps.
Detail Texture (Micro/Macro): This subordinate texture is used to add details
to a base texture that lacks the necessary resolution to provide the correct depth
perception. Detail textures conventions are described in greater detail in section
6.13.5.6, Model Detail Texture Maps.
Contaminants: These textures are used to simulate thin layers of matter that
accumulate on surface top. Contaminant textures conventions are described ingreater detail in section 6.13.5.7, Model Contaminant and Skid Mark Textures.
Normal Map: Normal mapping is a technique used for faking the lighting ofbumps and dents; when used in conjunction with a render’s light sources, it can
add surface detail without using more polygons. This subordinate texture is a 3component texture that encodes the normals at each texel. Tangent-spacenormal maps conventions are described in greater detail in section 6.13.5.5,
Model Tangent-space Normal Maps.
Reflection Map: Conventions are described in detail in section 6.13.5.8, Model
Cubic Reflection Maps.
Light Map: This subordinate texture is used to represent the effect of external
light sources onto a model. Light map textures conventions are described ingreater detail in section 6.13.5.4, Model Light Maps.
Gloss Map: A texture that describes whether a surface is matte or gloss;
described in section 6.13.5.9, Model Gloss Maps.
Material Texture: To specify the composite materials at the level of a single
texel; described in section 6.13.5.10, Model Material Textures.

Client-devices are required to use the modeler supplied layer number to determine the order inwhich the subordinate textures are to be rendered. The base layer is always rendered first,
followed by subordinate layer 1, 2, 3, etc. Gaps within the layer sequence are permitted.
Note that layer numbers are not assigned nor reserved to specific subordinate textures.
6.13.1.3 Texture Mapping Conventions
The following table provides the texture mapping for use with each kind of textures.

© 2015 Open Geospatial Consortium

382

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Base
TextureKind Mapping001
Modulate
002
Modulate
004
Modulate
005
Modulate
006
Modulate
007
Modulate
008
Modulate
009
Modulate

Subordinate
TextureKind Mapping
051
Decal
052
N/A
053
Modulate
054
Modulate
055
Modulate
056
Add
057
N/A
058
N/A

6.13.2
Default Gamma Corrections
The default gamma corrections of 3D model texture datasets are defined by the following set ofparameters found in the Defaults.xml metadata file.
Default_GSModelTexture_Gamma
Default_GSModelInteriorTexture_Gamma
Default_GTModelTexture_Gamma
Default_GTModelInteriorTexture_Gamma
Default_MModelTexture_Gamma
If a parameter is not found in Defaults.xml, or if Defaults.xml is not found in the metadata
directory, assume a default gamma correction of 1.0.
See Appendix S for the complete list of default parameters.
6.13.3
Texture Dimension
It is generally accepted by the modeling community to limit texture dimensions to a power of 2.
The CDB Specification goes a step further and enforces this practice.
To preserve the original texture resolution as much as possible, it is suggested to resize thesource texture to the nearest67 power of 2. For instance, if a source texture measures 72 pixels
wide by 13 pixels high, it is recommended to resize it to 64 by 16 pixels.
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇  𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 =    2   ×  2

Where n and m are positive integers (n, m ≥ 1).

6.13.3.1 Texture Mipmap
The CDB Specification demands that mipmaps associated with a given texture be present in the
texture directory. Furthermore, the Specification requires that mipmaps be stored in individual
files.

67

Note here that we do not recommend resizing to the next power of 2; instead, resize to the nearest power of 2.

© 2015 Open Geospatial Consortium

383

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁  𝑜𝑜𝑜𝑜  𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 = max 𝑛𝑛, 𝑚𝑚 + 1

For instance, a texture whose dimension is 23 × 24 has a total of 5 mipmaps.
6.13.3.2 Texture Size
The naming conventions of all model textures are described in Chapter 3. For texture file whosename uses the W field, the value of the field is a power of 2 representing the largest dimension ofa (possibly rectangular) texture.
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇  𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 2   Where W is a non-negative integer (W ≥ 0).

6.13.3.3 Texel Size
For texture file whose name uses the L field, the value of the field is related to the size of thetexels in accordance to Table 3-1: CDB LOD vs. Model Resolution.
6.13.4
Texture Palette
The OpenFlight Texture Palette record stores the names of all textures that are possiblyreferenced by the model; that includes all base and subordinate textures (i.e., all skins and allinterchangeable textures). Each palette entry contains the path and filename of one texture. The
CDB Specification demands that the path be relative to the OpenFlight file.
Below are examples of entries in the texture palette.
6.13.4.1 MModel Example
In the case of a moving model, the OpenFlight file resides in the MModelGeometry directory;
for instance, the M1A2 resides in\CDB\MModel\600_MModelGeometry\1_Platform\1_Land\225_United_States\1_Tank\1_1_225_1_1_3_0\

Its main texture is called M1A2 and resides in\CDB\MModel\601_MModelTexture\M\1\M1A2\

The corresponding palette entry would be..\..\..\..\..\..\601_MModelTexture\M\1\M1A2\
D601_S005_T001_W11_M1A2.rgb

6.13.4.2 GTModel Example
In the case of a geotypical power pylon model, the OpenFlight file resides in the GTModel
directory\CDB\GTModel\510_GTModelGeometry\A_Culture\T_Comm\040_Power_Pylon\Lxx\© 2015 Open Geospatial Consortium

384

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Assuming its texture is called Pylon, it resides in\CDB\GTModel\511_GTModelTexture\P\Y\Pylon\

The corresponding palette entry would be..\..\..\..\..\..\511_GTModelTexture\P\Y\Pylon\
D511_Sxxx_Txxx_Lxx_Pylon.rgb

6.13.4.3 GSModel Example
In the case of a geospecific model, its OpenFlight file resides in the GSModelGeometry
directory. An example is\CDB\Tiles\lat\lon\300_GSModelGeometry\Lxx\Ux\

If the model refers to a geospecific texture, it resides in\CDB\Tiles\lat\lon\301_GSModelTexture\Lxx\Ux\

The corresponding palette entry would be..\..\..\..\301_GSModelTexture\Lxx\Ux\latlon_D301_Sxxx_Txxx_Lxx_Ux_Rx_TNAM.rgb

If the model refers to a geotypical texture, it resides in\CDB\GTModel\511_GTModelTexture\T\N\TNAM

And the corresponding palette entry would be..\..\..\..\..\..\..\GTModel\511_GTModelTexture\T\N\TNAM\
D511_Sxxx_Txxx_Lxx_TNAM.rgb

6.13.4.4 T2DModel Example
In the case of a tiled 2D model, its OpenFlight file resides in the T2DModelGeometry directory.
An example is\CDB\Tiles\lat\lon\310_T2DModelGeometry\Lxx\Ux\

If the model refers to a geospecific texture, it resides in\CDB\Tiles\lat\lon\301_GSModelTexture\Lxx\Ux\

The corresponding palette entry would be..\..\..\..\301_GSModelTexture\Lxx\Ux\latlon_D301_Sxxx_Txxx_Lxx_Ux_Rx_TNAM.rgb

If the model refers to a geotypical texture, it resides in\CDB\GTModel\501_GTModelTexture\T\N\TNAM

And the corresponding palette entry would be..\..\..\..\..\..\..\GTModel\501_GTModelTexture\T\N\TNAM\
D511_Sxxx_Txxx_Lxx_TNAM.rgb© 2015 Open Geospatial Consortium

385

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.13.5

Usages6.13.5.1 Model Shadow Textures
Ideally, Model shadows should be generated at runtime by the client-device from the model’s
actual geometry. However, depending on the technique used by the client device, special
textures called projected shadow maps may be used to cast shadows from Models.
When the projected shadow map technique is used, special object nodes are used to store theshadow polygons.
6.13.5.1.1 Shadow Geometry
When geometry exists for the purpose of casting shadows, it must be located under an object
node whose Shadow flag is set.

Figure 6-49: Using Shadow Polygons

Several object nodes can be used to store several polygons all textured with projected shadow
maps. It may be desirable to also create separate shadow maps for major articulated parts andlocate these shadow objects just under their corresponding DOF nodes.
6.13.5.1.2 Shadow Maps
Projected shadow maps are created by applying one, two or three orthographic projections on themodel (or optionally on major articulated parts of the model). Figure 6-50: Example of a
Shadow Map in the XY Plane shows one example of a shadow map of an aircraft in the XY
plane. Similar maps can also be produced for the YZ and ZX planes.

© 2015 Open Geospatial Consortium

386

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-50: Example of a Shadow Map in the XY Plane

A projected shadow map is a monochrome (single-component) texture without transparency. It
represents the mask to cut out the contour of the model. In theory, a black and white texture
would be enough; however, shades of gray are permitted to represent semi-transparent surfacesthat could be present on the model. In any case, a value of 0 (black) means the model does notblock the passage of lights. The opposite value, 1 (white), indicates the model completely
obstruct the light.
Because the shape of the model may change with damage states, each model state should have its
own set of projected shadow maps. Section 6.9.2.2 describes damage states.
Shadow maps are general base textures. Their Texture Kind is 007 and their Texture Index is asequence number when several shadow maps exist for the same Model.
To illustrate the naming convention, assume the shadow map from Figure 6-50: Example of a
Shadow Map in the XY Plane, is called “aircraft”. According to Section 3.5.2.1,
MModelTexture Naming Convention, and Section 5.5, MModel Library Datasets, the resulting
file name would be:
D601_S007_T001_Wnn_aircraft.rgb

The value Wnn represents the texture size, 2nn, and is explained in Section 6.13.3.2, Texture
Size.

Note that if a client-device generates shadows on its own, without the support of pre-computed
projected shadow maps, it can ignore all OpenFlight object nodes whose Shadow flags are set aswell as all textures associated with these nodes.

© 2015 Open Geospatial Consortium

387

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.13.5.2 Model Skin Textures
Models skins are base textures that correspond to one or more moving models paint schemes or
one or more time-of-year representations of the cultural feature.
For instance, the same tank can be painted with several different colors to match various areas ofoperation. Below are two examples of the same tank, the M1A2 Abrams, painted for operation
in a desert area (Figure 6-51) or in a forest area (Figure 6-52).

Figure 6-51: The M1A2 Abrams with a Desert Camouflage© 2015 Open Geospatial Consortium

388

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-52: The M1A2 Abrams with a Forest Camouflage

The two different textures for this tank qualify for use as skins since they have been designed insuch a way that they can be exchanged for one another without affecting their mapping on theaffected polygons. The mapping of both textures must be identical since only the texture ischanged, not the UV mapping.
OpenFlight itself does not provide an explicit mechanism to change the base texture assigned to
faces. In fact, OpenFlight supports a single base texture per face record. The other textures thatcan be added to a face are called layers and none of them is a replacement for the base texture.
In order to have several skins for a single model, the CDB Specification provides the mechanism
defined in 6.14.5.2, Texture Switch. The enumeration values for each skin can be found in
Appendix O.
The M1A2 used in the above examples has two skins. Each skin is made of a single texture that
happens to be a mosaic of all the individual textures used by the model. Figure 6-53: M1A2
Desert Skin Mosaic below shows one of the M1A2 skins.

© 2015 Open Geospatial Consortium

389

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-53: M1A2 Desert Skin Mosaic

The following texture kinds implement the concept of model skins:
Kind 002 – Monthly Representation
Kind 009 – Quarterly Representation
Kind 004 – Uniform Paint Scheme
Kind 005 – Camouflage Paint Scheme
Kind 006 – Airline Paint Scheme
Paint schemes apply to moving models only. Appendix O lists available paint schemes.
Time-Of-Year representations are appropriate for cultural features. A good example is the caseof leafy trees. Depending on the hemisphere and the latitude, several textures represent leafy
trees at different stages during the year.
All texture kinds listed above are mutually exclusive; also, all instances of textures of a kind are
mutually exclusive. Since all texture kinds above are base textures, and because only one basetexture can be active at any one time on a face of a model, it follows that only one skin can be
active at a time.

© 2015 Open Geospatial Consortium

390

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.13.5.3 Model Night Maps
Night maps fall under the category of subordinate textures. Night and light maps (see next
section) are both used at night to represent how interior and exterior light sources change theappearance of a Model. It is possible for a Model to have both a night and a light map, or just alight map. However, it is not possible to have a night map alone.
Simulator client-devices invoke a night map when the (simulated) light sources located inside themodel need to change its appearance at night. This is the case when the interior light sources
shine through openings like windows and portholes. To simulate the effect of lights emitted
through these openings, a night map is created; it adds these bright window details normally
missing from the base day texture.
The creation of a night map for models is left to the discretion of the modeler. Creating
additional geometry for the windows and changing the material associated with the polygons toincorporate an emissive component can also produce a lighting effect similar to night maps.
However, this approach requires additional (unnecessary) model geometry that adds additional
computational load in the client-devices. For this reason, the use of night maps is recommended.
Light maps differ from night maps in that they combine the effect of exterior lighting withinterior lights. A light map acts as a (colored) filter to mask portions of the model that are nolonger visible at night when no ambient light exists.
A Model may have a relatively different aspect at night. This difference comes from twochanges in the environment. The ambient illumination provided by sunlight is totally absent atnight; only the moon and man-made light sources affect the appearance of objects. Whenpresent, the moon provides only a modest level of illumination when compared to the sun. In
addition, the model itself might have internal lights turned on that are not modeled in day versionof the texture but that do affect its appearance at night.
To illustrate these differences, imagine a building as seen during the day. No light seems tocome out of its windows because the average daytime sunlight overwhelms any man-madelighting (internal to the building and coming out of the windows). At night, the outside walls of
the building have not changed but light is now emanating from the windows. This is an
important change that requires a modification to the texture used to represent the walls.
Another example of the use of a night map is the case of an aircraft flying at night. During
daytime, the aircraft windows look dark while at night, light comes from the inside and thewindows appear white.
Night maps are used to add details to base textures; details that are not visible during the day andthat become visible at night. Therefore, a night map is not a replacement for the base texture. It
is used in conjunction with the base texture.
The next figures illustrate the purpose of night maps.
Figure 6-54: Base Texture is the base texture used in modeling a commercial aircraft, the Airbus
330, during the day. Notice that portholes are represented by dark rounded rectangles because© 2015 Open Geospatial Consortium

391

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
the lights in the cabin are off. The same is true for the cockpit windows located in the bottom
right of the texture.

Figure 6-54: Base Texture

Figure 6-55: Night Map, is the model’s corresponding night map and shows the same portholes
but this time brighter to reflect the fact that cabin lights are on. This time, notice the appearanceof the cockpit windows as well as the presence of colors in them. Remember that this texture isused to add details that may be missing from the base texture.

Figure 6-55: Night Map

There are constraints imposed on night maps:
A night map must have the same size as its base texture.
A night map uses the same UV mapping as its base texture.
A night map has a similar format as its base texture (RGB or Intensity) plus analpha channel.

© 2015 Open Geospatial Consortium

392

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.13.5.3.1 Night Map Generation
A night map is mapped on top of its base texture using a Decal texture environment. Since anight map is a subordinate texture, it is mapped on polygons using an OpenFlight multitexture
record. The Effect field of this multitexture record must contain the value 0 indicating to use the
Texture Environment mapping defined in the Texture Attribute file. The Environment Type
field found in the Texture Attribute file must contain the value 2 indicating a Decal environment
mapping.
The night map alpha channel is in fact a mask identifying which portions of the base texture are
replaced by the night map. Accordingly, the alpha channel contains a value of 0 when thecorresponding texel of the base texture is left intact. However, the alpha channel will contain thevalue 1 when the corresponding texel of the base texture is replaced by the equivalent night map
texel. Overall, the Decal environment mapping applies the following transformation to the basetexture.

C = Cb ⋅ (1 − An ) + Cn ⋅ An
where…

Cb is the color component (or intensity) of the base texture
C n is the color component (or intensity) of the night map
An is the alpha component of the night map
Since the values found in the night map alpha channel are limited to 0 and 1, the resulting color
will either be the one found in the base texture when An is 0 or the one found in the night map

when An is 1.

6.13.5.4 Model Light Maps
Light maps also fall under the category of subordinate textures. Night maps and light maps areboth used at night to represent how interior and exterior light sources change the appearance of a
Model. It is possible for a Model to have both a night map and a light map, or just a light map.
However, it is not possible to have a night map alone.
Light maps differ from night maps in that they combine the effect of exterior lighting withinterior lights. A light map acts as a (colored) filter to mask portions of the model that are nolonger visible at night when no ambient light exists.
A light map is used when active light sources are located on the outside of the model. This
technique is used to simulate the appearance of a model when lit by local spotlights. For
instance, spotlights may be used to illuminate a building at night. The light map provides theillumination pattern that represents the spotlight illumination on the building. The techniqueprovides a convenient mean to produce interesting and entirely predictable lighting effects© 2015 Open Geospatial Consortium

393

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
without resorting to computationally intensive local light sources. Their effects are alreadyincorporated into special textures called light maps.
A light map also contains a mask related to the night map when present. Remember that a light
map is a filter (a mask) to retain the detail associated with the base texture and its optional nightmap.
As opposed to a night map, a light map does not have constraints. More specifically:
A light map does not need to be of the same size as its base texture.
A light map has its own UV mapping.
A light map can be an intensity map or an RGB image.
Note that when light sources are modeled with light maps, they only affect the model onto which
they are applied.
The next set of figures illustrates how light maps contribute to the lighting of a model. Note thata light map is not applied directly to the model base texture. The light map is first modified totake into account the ambient lighting, and then the resulting lighting is applied to the model.
Figure 6-56: Light Map, is the light map matching the base texture in Figure 6-54: Base Texture.
Notice that it combines light lobes representing external light spots with the mask associatedwith internal light sources from the night map. This mask is used to key in details that stayvisible at night.

Figure 6-56: Light Map

Figure 6-57: Combined Effect of Base Textures and Light Maps, shows on the actual aircraft theresult of applying the light map from Figure 6-56: Light Map to the base texture from Figure
6-54: Base Texture. Notice that portholes and cockpit windows are still dark since the basetexture has not been modified by the night map yet.

© 2015 Open Geospatial Consortium

394

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-57: Combined Effect of Base Textures and Light Maps

Figure 6-58: Combined Effect of Night and Light Maps, shows the result of adding the night
map to the base texture and then applying the light map. This time, we can clearly see the lights
coming through portholes and cockpit windows.

Figure 6-58: Combined Effect of Night and Light Maps

6.13.5.4.1 How and When to Use Night Maps and Light Maps
The CDB Specification recommends the use of night maps to represent lights that are internal tothe model; this permits the client device to control the appearance of the model with internal
lights on or off. This condition is usually true at night, hence the name of the texture.
Similarly, the CDB Specification recommends the use of light maps to represent the effect oflights that are external to the model; this permits the client-device to control the appearance ofthe model with external spotlights on or off.
Note that night and light maps can be applied to any of the skins since skins are base textures.
6.13.5.4.2 How and When Not to Use Light Maps
A client device may discard light maps if the effect of external lights is internally generated by
its GPU. It can be envisioned that future development of specialized hardware – such asgraphics processor unit – will allow more of the lighting effects to be generated in real-time.
When this time comes, artificial textures generated off-line such as light maps will become
obsolete.

© 2015 Open Geospatial Consortium

395

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
6.13.5.5 Model Tangent-space Normal Maps
A normal map is an RGB texture (without an alpha channel) where the normal to the surface is
encoded in the Red, Green, and Blue channels. The normal (i, j, k) values are encoded in thefollowing manner into the 8-bit value of each channel:
R [0, 255] = i [-1.0, +1.0]
G [0, 255] = j [-1.0, +1.0]
B [0, 255] = k [-1.0, +1.0]
The mapping is identical on all channels; the range of all possible 8-bit values (0, 255) is mapped
linearly to the range of floating point values -1.0 to +1.0. This mapping provides a resolution of
2/255 or 0.0078.
In addition, the reader should note that the floating-point value 0.0 has no exact integer
equivalent68. Here, the closest value to 0.0 is approximately ±0.0039 and is obtained when thechannel contains 127 or 128.
Besides this particular encoding of the normal into the RGB channels, a normal map has all theother attributes of a standard RGB texture whose format is defined in Appendix P, SGI Image
File Format.
In the industry, there are at least two types of Normal Map: object-space normal map, andtangent-space normal map. Both types have their pros and cons. The CDB Specification opts
for tangent-space normal map. A sample is shown here.

68

The conventional OpenGL mapping specifies that -1 and 1 can be represented exactly, but 0 can not.

© 2015 Open Geospatial Consortium

396

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-59: Normal Map Sample

Typically, the normal points away from the surface, and not toward the underlying surface. For
this reason, the value of the k-component of the normal is positive, most of the time, resulting ina bluish tint of the map. A negative k-component could indicate the presence of a cliff with an
overhang, for instance.
6.13.5.6 Model Detail Texture Maps
A detail texture map is 1- or 3-component (aka channel) texture where each texel is represented
as an 8-bit unsigned integer. A detail texture exhibits two important properties; it has a neutral
luminance (intensity) and chrominance (color). This is achieved by applying the following
constraints:
The 8-bit unsigned value of each texel is scaled to a floating point value in therange -1.0 to 1.0
The average value of an individual component is always 0.0
The Detail texture is mapped on the underlying surface through a simple
addition operation
The net effect of applying a Detail Texture Map is to highlight (> 0) or darken (< 0) fragment
details on the underlying surface. When using a single component detail texture map, only theintensity of the resulting image is affected; when using a 3-component detail texture map, thecolor is also varied.

© 2015 Open Geospatial Consortium

397

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-60: Detail Texture Map Sample

Recall that a detail texture map is a mean of adding high-frequency (spatial) details to a rather
low-frequency image.
6.13.5.7 Model Contaminant and Skid Mark Textures
Historically, Image Generators of civil aviation simulators provided the means for flight
instructors to control the appearance of airport runways, taxiways, and roads with various surface
contaminants. To this end, the CDB provides a set of standardized Model Contaminant and Skid
Mark Textures that are commonly used in flight simulators and listed in Appendix O. These
textures are typically four-component (R, G, B, alpha) textures that act as an overlay to airport
surfaces.
6.13.5.8 Model Cubic Reflection Maps
Reflection mapping (aka environment mapping) is an efficient image-based lighting techniquefor approximating the appearance of a reflective surface by means of a precomputed texture
image. The texture is used to store the image of the distant environment surrounding therendered object.

© 2015 Open Geospatial Consortium

398

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-61: Environment Used to Produce Reflection Map

Figure 6-62: Resulting Reflection Map© 2015 Open Geospatial Consortium

399

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 6-63: Rendered Reflection Map onto Reflecting Cube

The CDB Specification assumes that the surrounding environment is stored using a cubic
mapping approach. In this technique, the environment is projected onto the six faces of a cubeand stored as six square textures or unfolded into six square regions of a single texture. The
reflection mapping approach is more efficient than the classical ray tracing approach ofcomputing the exact reflection by tracing a ray and following its optical path. The reflection
color used in the shading computation at a pixel is determined by calculating the reflection
vector at the point on the object and mapping it to the texel in the environment map. This
technique often produces results that are superficially similar to those generated by raytracing,but is less computationally expensive since the radiance value of the reflection comes from
calculating the angles of incidence and reflection, followed by a texture lookup, rather thanfollowed by tracing a ray against the scene geometry and computing the radiance of the ray,simplifying the GPU workload.
Note however that in most circumstances, a mapped reflection is only an approximation of thereal reflection. Environment mapping relies on four assumptions:
All radiance incident upon the statically-positioned object being shaded
comes from an infinite distance. When this is not the case, then a) thereflection of nearby geometry appears in the wrong place on the reflected
object, and b) no parallax is seen in the reflection.

© 2015 Open Geospatial Consortium

400

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The object being shaded is convex, such that it contains no selfinterreflections. When this is not the case the object does not appear in thereflection; only the environment does.
The environment map is valid for the location for which it was generated.
The environment is static.
6.13.5.9 Model Gloss Maps
A gloss map is a texture that describes whether a surface is matte or gloss. The texture is used tomodulate specular highlights in the same way the material shininess does. A gloss map is stored
as an 8-bit single channel texture (a grey-scale image) where texels are mapped to the range 0.0(matte) to 1.0 (glossy). The values in the gloss map play the same role as the single shininessvalue found in the OpenFlight material assigned to a polygon. In this way, the gloss map caneffectively modulate the specularity on a per-pixel basis. Note that if the material applied to thesurface has no specular component, then the gloss map has no effect.
6.13.5.10 Model Material Textures
Material textures fall under the category of subordinate textures. They are mapped to Models thesame way as any other textures. As such, the surfaces these textures are mapped to possess theirown set of UV mapping.
A material texture tells the interested client devices (e.g., FLIR, CGF) what the underlying
surface is made of. For this reason, a material texture is not at all related to a base texture. The
two are completely independent and exist separately. A material texture does not require that abase texture be applied to the model. In fact, it is perfectly possible to create a Model that does
not use texture except for a single material texture describing its various materials.
The <Material> tag presented in section 6.5.3 is a high level mean of providing material
information about the geometry of a model. With the use of a material texture, the modeler can
provide highly detailed material information about the same model.
In short, the <Material> tag supports a polygon-based approach of sensor client devices such as
FLIR, NVG, and RADAR. A Material texture is a texel-based approach supporting animplementation of such client devices with a much higher resolution.
In the case of the Raster Material dataset (dataset code 005) applied onto the terrain, it isconceivable that multiple layers and mixtures of materials are required to represent the richvariety of materials found on the earth surface. However, for Models, a single material layer isprobably adequate for the vast majority of man-made objects.
6.14
Model Descriptor (Metadata) Datasets
Each type of 3D Models has its set of ModelDescriptor datasets; they are:1. GSModelDescriptor
2. GSModelInteriorDescriptor© 2015 Open Geospatial Consortium

401

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3. GTModelDescriptor
4. GTModelInteriorDescriptor
5. MModelDescriptor
Each file is needed to summarize and regroup the information concerning one portion of amodel, its shell or its interior. The information are collected and stored in an XML file to help
client devices implement efficient load management mechanism.
The format of the model descriptor file is as follows:<Model_Metadata><Name>...</Name><Identification>...</Identification><Mass>...</Mass><Parts>...</Parts><Textures>...</Textures><Configurations>...</Configurations><Composite_Material_Table>...</Composite_Material_Table></Model_Metadata>

6.14.1Model Name
The <Name> is an arbitrary string from the character set presented in section 2.2. This name isthe human readable version of the model identification code that follows.
6.14.2Model Identification
Models are either modeled representation of cultural features or moving models. In both cases,
the CDB Specification has a unique way to identify them. For moving models, the identification
scheme corresponds to their DIS entity type. For cultural features, their FACC code is used.
6.14.2.1 Moving Model Identification
The DIS entity type is a list of up to seven integers and can be specified in two different
manners. All fields have a default value of zero.
First, you can use a list of one to seven integers as illustrated here:<Identification><DIS_Entity_Type><List>...</List></DIS_Entity_Type></Identification>

Or you can use this more verbose syntax to specify the value of individual fields:© 2015 Open Geospatial Consortium

402

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Identification><DIS_Entity_Type><Kind>...</Kind><Domain>...</Domain><Country>...</Country><Category>...</Category><Subcategory>...</Subcategory><Specific>...</Specific><Extra>...</Extra></DIS_Entity_Type></Identification>

All fields are limited to the range [0, 255] except the country code that can go up to 65535.
6.14.2.2 Cultural Feature Identification
For cultural features, their FACC code is specified in the following manner:<Identfication><Feature_Attribute_Catalog_Code><Code>...</Code><Subcode>...</Subcode></Feature_Attribute_Catalog_Code></Identification>

The FACC code has a fixed format of two letters followed by three digits; it is the same as the
FACC attribute described in section 5.7.1.3.24. The subcode is an optional integer in the range[0, 999].
6.14.3Model Mass
The model mass is optional. It makes sense only when the Model represents a moving model.
<Mass><Total>...</Total><Metal>...</Metal></Mass>

The total mass of the model is expressed in kilograms. The portion of the model that is made ofa metallic alloy is expressed as a percentage of the total mass. The value of <Metal> lies in therange [0.0, 1.0].
When the model mass is specified, the total mass is mandatory while the metallic portion is
optional. The total mass must be larger than zero. The metallic portion defaults to zero.
6.14.4Model Parts
A Model may be separated into several parts. If the complexity of a part justifies it, each partmay be split into multiple files.
The whole section is optional. It is required only if more than one part exists or if a part has
more than one file.
If present, the section is a list of at least one part formatted like this.

© 2015 Open Geospatial Consortium

403

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Parts><Part no="no" numFiles="numFiles" name="partName" />...
</Parts>

The part number is mandatory. It starts at 1 and increases by 1 for each subsequent part. The
first part is also referred to as the body of the model.
The number of files is optional and defaults to 1.
The part name69 is optional and is used only to improve the readability of the file.
6.14.5Model Textures
This section lists all textures that could be possibly used by the model. In the event the model
does not use texture, the whole section is omitted. The section contains a list of textures andoptional texture switches.
<Textures><Texture .../><Texture .../>...
<Switch .../><Switch .../>...
</Textures>

6.14.5.1 Texture Metadata
For each texture, the section provides the client device with the necessary information to decide
when and which texture mipmap should be loaded.
The section is formatted like this.
<Texture no="number" name="name"><Dataset>...</Dataset><Kind>...</Kind><Index>...</Index><Mipmap>min max</Mipmap><Resolution>...</Resolution><Coverage><U>min max</U><V>min max</V></Coverage></Texture>

The texture number is a strictly positive integer to uniquely identify the texture. The texturename corresponds to the TNAM field in the texture filename as defined in Section 3.5.2.1,
MModelTexture Naming Convention.

69

As a guideline, it is suggested to set the part name the same as the global zone name of that part. For instance, if
the part represents an external fuel tank, a good name for both the part and its global zone would be “External FuelTank”.

© 2015 Open Geospatial Consortium

404

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The <Dataset>, <Kind>, and <Index> fields correspond respectively to the dataset number andcomponent selectors 1 and 2; they match the D, S and T fields in the texture filename.
The mipmap field defines the smallest and largest mipmap available for this texture. The valueof this field is used to compose the W field in the texture filename of moving models (seeexamples in section 3.5.2.4).
The texture resolution is expressed in texels per meter70. It is the same for both the U and V axes
even though it is recognized that it can differ between the two dimensions. The intent is toprovide an indication of how precise the texture is when mapped to the model geometry. It helps
client device decide which mipmap is more appropriate to use.
The texture coverage is optional and defines the minimum and maximum values for the U and V
texture coordinates. This information indicates if the texture is repeated along one or both axes.
If the coverage is in the interval [0, 1], the texture is clamped; otherwise, it is repeated.
6.14.5.2 Texture Switch
A Texture Switch is defined when switchable textures appear in the list of textures. Switchable
textures are textures that can be exchanged for one another because they share the same UV
mapping, as explained in section 6.13.5.2, Model Skin Textures.
The section is formatted like this.
<Switch no="number" name="name"><State no="number" name="name" textures="list"/>...
</Switch>

The switch number is a unique positive integer identifying the switch. The switch name is aunique string limited to 32 characters; all switches are uniquely identified by a number and a
name.
A switch has two or more states; each state selecting a list of one or more textures. State
numbers are consecutive and start at 1. The state name is a unique string also limited to 32
characters. The list of textures associated with a state contains the texture numbers of theselected textures. Note that a state (e.g., a skin) may require more than one texture, hence theneed to specify a list of textures associated with a state.
6.14.5.2.1 Example
Assume that the following two textures are stored in the M1A2 texture folder:\CDB\MModel\601_MModelTexture\M\1\M1A2\
D601_S004_T005_Wxx_M1A2.rgb
D601_S005_T001_Wxx_M1A2.rgb
70This unit of measurement (texels per meter) is akin to DPI (dot per inch) used to quantify the resolution of printersand displays.

© 2015 Open Geospatial Consortium

405

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Here is an excerpt of the model metadata presenting the two textures, the switch, and the twocorresponding states.
<Textures><Texture no="3" name="M1A2"><Dataset>601</Dataset><Kind>4</Kind><Index>5</Index>...
</Texture><Texture no="10" name="M1A2"><Dataset>601</Dataset><Kind>5</Kind><Index>1</Index>...
</Texture>...
<Switch no="1" name="Paint Scheme"><State no="1" name="Uniform Beige Paint" textures="3"/><State no="2" name="Desert Camouflage" textures="10"/></Switch></Textures>

The texture switch is named “Paint Scheme” because it controls the selection of the paint scheme
to apply to the M1A2. The first state selects texture 3 which corresponds to a beige uniform
paint; the second state selects texture 10 corresponding to a desert camouflage.
Note that the texture switch mechanism is not limited to base textures; it can be used to switch
light maps for example.
6.14.6
Model Configurations
Often, a single Model – especially a moving model – comes with a variety of possible equipment
and/or ordnance. This can be as diversified as fuel tanks, missiles, radio emitters, etc. To
configure a model with its ordnance, the CBD Specification defines the concept of model
configuration. A configuration defines the set of equipment and ordnance attached to the various
stations found on the model.
The configuration section is optional. It is a list of one or more configurations defined like this.
<Configurations><Configuration>...</Configuration>...
</Configurations>6.14.6.1 Defining Stations in a Configuration
A configuration is a sequence of one or more stations, each defining one piece of equipment in
one location.

© 2015 Open Geospatial Consortium

406

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<Configuration name="ConfigName"><Station name="StationName"><Location>...</Location><Equipment>...</Equipment></Station>... other stations as needed</Configuration>

The configuration and station names are both optional and are used for documentation purposes
only.
The location of a station is defined by its fully qualified name as specified in section 6.5.5,
Model Zone Naming.
6.14.6.2 Defining Equipment in a Station
The equipment is defined by either its DIS identification or a reference to an external part, and an
optional anchor point.
<Equipment name="EquipmentName"><Identification>...</Identification><External_Part>...</External_Part><Anchor>...</Anchor></Equipment>

The equipment name is optional and is used for documentation purposes only.
The anchor point is specified in the same manner as the location of a station, by providing its
path (on the subordinate model) as specified in section 6.5.5, Model Zone Naming.
6.14.6.3 Defining Equipment Names
Either a DIS emitter name or a DIS entity type identifies the equipment. When the equipment is
an emitter, the syntax is as follow.
<Identification><DIS_Emitter_Name>...</DIS_Emitter_Name></Identification>

Emitter names are defined by the DIS standard. For DIS, refer to Section 8.1.1 of reference [4]for a list of DIS Emitter Names. For the HLA standard, the RPR-FOM lists all emitter names.
To avoid confusion, both DIS and HLA refer to emitter names using numbers. For instance, theNATO emitter AS 15 KENT altimeter is referred to as emitter 8735.
When the equipment is another entity (e.g., a missile), its DIS entity type is supplied in thefollowing manner.
<Identification><DIS_Entity_Type>...</DIS_Entity_Type></Identification>

Recall that the DIS entity type is a list of up to 7 numbers as defined by reference [4]. For
example, the AGM-114K-SAL Hellfire missile would be referred to as:© 2015 Open Geospatial Consortium

407

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
<DIS_Entity_Type><List>2 2 225 1 3 5 1</List></DIS_Entity_Type>or<DIS_Entity_Type><Kind>2</Kind><Domain>2</Domain><Country>225</Country><Category>1</Category><Subcategory>3</Subcategory><Specific>5</Specific><Extra>1</Extra></DIS_Entity_Type>

Equipment can also be defined by a reference to an external part if need be. A good example ofsuch equipment is a fuel tank.
<External_Part><Part_Number>...</Part_Number><Configuration>...<Configuration></External_Part>

The external part is identified by its part number as defined previously in the <Parts> section.
The external part may also require it own configuration. Take the example of a Hellfire missile
rack attached to an attack helicopter like the Apache. The rack can hold up to 4 missiles. Eachmissile attaches to one of four separate weapon stations located on the rack. For this more
complex example, assume the rack has only two missiles out of four. This configuration can be
specified with the following piece of XML.
<External_Part><Part_Number>1</Part_Number><Configuration><Station name="Missile 1"><Location>\Missile_Rack\Attach_Point[1]</Location><Equipment><Identification><DIS_Entity_Type><List>2 2 225 3 5 1</List></DIS_Entity_Type></Identification></Equipment></Station><Station name="Missile 2"><Location>\Missile_Rack\Attach_Point[2]</Location><Equipment><Identification><DIS_Entity_Type><List>2 2 225 3 5 1</List></DIS_Entity_Type></Identification></Equipment></Station><Configuration></External_Part>

With the help of model configurations, it is possible to create several variants of a single Model,
each variant defined by its own configuration.

© 2015 Open Geospatial Consortium

408

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
This way, one Apache can have two configurations, one when equipped with Hellfire missiles
and one when equipped with rocket launchers.
6.14.7
Model Composite Materials
The composite material table is the last component of the Model Metadata and is defined in
section 2.5.2.2, Composite Material Tables (CMT).

© 2015 Open Geospatial Consortium

409

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 7
7

CDB Radar Cross Section (RCS) Models

7.1
Introduction
For devices such as Radars, a geometric representation of a model may often provide a level offidelity which is insufficient or inappropriate for use in simulation or alternately, it may not be
feasible to compute a radar cross-section of the model in real-time. Alternately, a user may wish
to incorporate real-world RCS data into the simulator client-devices in order to further improve
simulation fidelity. To this end, the CDB Specification defines a RCS (Radar Cross-Section)model representation for use by Sensor Simulation client-devices such as Radar and/or Sonar. It
provides a signature model representing the overall relative reflectivity levels of a given Model
Representation when viewed at discrete azimuth and elevation angles. The RCS data is thenused in range and aspect calculations for the detection and classification of simulated targets(either ground or moving).
This chapter provides all of the information required to store RCS data within a CDB.
Section A.7 of Appendix A provides a primer on radar, basic principles of operation and radarcross sections (RCS).
7.2
RCS Data Model
This section concerns itself with the internal RCS model representation and its sub-structures,
which forms a complete dataset layer.
7.2.1
RCS Model Structure
The CDB RCS data is organized so that client-devices can easily retrieve the following
information from the RCS model (Figure 7-1: Graphical Representation of the 3D Model RCS
Shape Data) below:
X

The modeling (physical) parameters that were used to generate the RCS polardata.
X
The RCS polar representation corresponding to one or more levels of
resolution of the RCS polar data.
X
The RCS polar representation corresponding to distinct radar mode ofoperation.
X
The RCS polar representation corresponding to a distinct radar model type.
RCS resolution refers to the angular pitch used in gathering RCS data for the model in question.
At a given RCS resolution, it is possible to have two or more RCS polar representations due tothe fact that the RCS data is computed based on a number of physical modeling properties suchas the characteristics of the electromagnetic beam, its frequency, polarization, amplitude andphase. A simulated sensor operating in a given mode of operation, over a given range of© 2015 Open Geospatial Consortium

411

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
frequencies, will require the RCS data closest to this mode. It will therefore need to use theclosest matching Polar Diagram from the RCS model data.
7.3
RCS Polar Diagram Data Representation using Shapefile
This section provides a detailed description of the content and format of RCS data for the CDB.
7.3.1
Shapefile Internal Data Structure
Within a CDB, the RCS model is stored as a series of ShapeFiles in accordance with the ESRI
Shapefile Specification. This section describes the Shapefile internal data structure for the
representation of RCS model data. This format provides the required flexibility to create andvisualize the RCS data:
X
Easy modification of data attributes
X
Simple visualization of RCS data in polar form
X
Allow irregular steps in azimuth/elevation (X/Y)
X
Allow some possibly missing values
RCS data is inherently two-dimensional in nature and is naturally organized as a twodimensional array of RCS polar values computed at various azimuth and elevation angles fromthe target. Each element of this array represents the RCS data value over each uniformly
distributed azimuth angle and distinct elevation angle.
Therefore, each of such array element can be represented as a “Point” shape, with the azimuth
angle value (X) at a given elevation angle (Y), while at the same time storing the associatedattributes such as the RCS, Amplitude or Phase data in the instance attribute database (dbf file)associated to the Shapefile. Typical azimuth angles would range between -180° and +180°,
where as the elevation angles would cover from -90° to +90°. However, the RCS data set could
potentially only cover just a partial range of those angles if data is incomplete for example. Thiscan be visualized in the next diagram, showing RCS values at various azimuth angles
corresponding to an elevation angle of 20° with respect to the model (cube). Note that the axis
conventions follow those described in Section 6.3, Coordinate Systems.

© 2015 Open Geospatial Consortium

412

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 201420
Elevation
90
80
70
Azimuth

60
50

0

10

20

30

40

Green: Array of values for 20
degree elevation
White Dots: Point Shapes
for 1 quadrant of RCS values

Figure 7-1: Graphical Representation of the 3D Model RCS Shape Data

Partial RCS data is permitted, i.e., it is permitted to cover a sub-region of the RCS polar diagramwith only points corresponding to known values.
For example, consider an RCS model consisting of data values in 5o elevation increments and 2oazimuth increments covering the entire aspect angle range of the target. The CDB representation
would consist of (180°/5°)+1 = 37 sets of (360°/2°)+1 = 181 points (vertices) for a full target
aspect coverage; yielding 6697 point shapes with their attribute data. For each of those Shapefile
point vertices, the X component represents the azimuth angle (equivalent to longitude) and the Y
component represents the elevation angle (equivalent to latitude); the RCS value (and otherattributes) being stored in the instance attributes within the DBF file.
The CDB specification defines eight prescribed values for azimuth and elevation increments.
They are referred to herein as ModelSignature Significant Angle. The table below shows thecorrespondence between the ModelSignature LOD level number and the ModelSignature
Significant Angle.

© 2015 Open Geospatial Consortium

413

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table 7-1: ModelSignature Significant Angle per LOD
ModelSignature LOD
level

Significant Angle

090° ≤ Significant angle

12
3

45° ≤ Significant angle < 90°

22.5° ≤ Significant angle < 45°

11.25° ≤ Significant angle < 22.5°

45.625° ≤ Significant angle < 11.25°

6

1.40° ≤ Significant angle < 2.80°57

2.80° ≤ Significant angle < 5.625°
0.70° ≤ Significant angle < 1.40°

Number of values
Less than 8

between 8 and 32

between 32 and 128

between 128 and 512

between 512 and 2048

between 8192 and 32768

between 32768 and 131072

between 131072 and 524288

Such a data representation would typically produce the following diagram when viewed in 2D(Figure 7-2: Polar Diagram of RCS Data in Planar Representation) and 3D (Figure 7-3: Polar
Diagram of RCS Data in Spherical Representation) polar forms (color representing the RCSIntensity attribute):

Figure 7-2: Polar Diagram of RCS Data in Planar Representation© 2015 Open Geospatial Consortium

414

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Figure 7-3: Polar Diagram of RCS Data in Spherical Representation

In addition, specific attributes within the Shapefile are required to specify other characteristics of
the RCS data, like EM polarization mode and frequency that were used when characterizing thetarget’s RCS signature. Those are the class-level attributes and are described below.
The data for each distinct RCS representation model requires two different types of attributes;
RCS model class attributes and RCS instance attributes.
1. RCS Model Class-level attribution: These are attributes that can be shared by
all of the RCS model instances of the RCS representation. The attributes andtheir values are logically re-grouped under a classname that stands for theentire attributes specific to the RCS model. All of the classnames are regrouped into a model.dbf file referred to as the RCS Class Attribute file for
the RCS model. (See Section 7.4.1, Directory Structure) Each row of themodel.dbf file corresponds to a different classname. The first column of thefile is the classname attribute and acts as the primary key to access subsequent
table entries; all other columns correspond to the attributes represented by theclassname.
2. RCS Instance-level attribution: This is the data that represents a particularinstance of the RCS model for a RCS representation. The data is contained in© 2015 Open Geospatial Consortium

415

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
the attribution columns of the model.dbf file that accompanies the RCS’s*.shp file. This *.dbf file is referred to as the RCS Instance Attribute file of
the RCS model. (See Section 7.4.1, Directory Structure) The first column ofeach row is always the classname attribute. The other columns in a RCS
Instance Attribute file are used to describe further the associated shape.
In summary, for a single RCS model in the CDB, the data files consist of:XXX

One *.shp main file that provides the geometric aspect (Points) for each data
instance of a RCS model.
Two *.dbf files (one instance-level on a per RCS Shape basis, and one classlevel at the RCS model level) that collectively provide the attribution for all of
the possible RCS models of a given RCS Model.
One *.shx index file that stores the file offsets and content lengths for each of
the records of the main *.shp file. The only purpose of this file is to provide a
simple means for clients to step through the individual records of the *.shp file(i.e., it contains no CDB modeled data).

7.3.1.1
RCS Model Class-Level Attributes:
Many attributes within the Shapefile are required to specify the physical modeling parameters
corresponding to those used to produce the RCS data; this includes, for instance, the electromagnetic (EM) polarization mode and the frequency that were used when characterizing thetarget’s RCS signature.
The CDB RCS model representation offers a comprehensive set of class attributes that aredescribed below. It is important to note that these attributes are an elaborate set of fields toindicate in which physical environment the RCS data was computed, and does not necessarilyreflect a precise operating mode of a particular radar.
A description of the attribute information follows below. (The reader should keep in mind thatthe 10-character limitation of attribute names is imposed by the dBASE III+ file format used by
the Shapefile .DBF data format)
Table 7-2: XML Tags for Hot Spots
Attribute

FormatVERSIONSTRING

PROD_DAYINT

PROD_MTH

INT

PROD_YEA

INT

CLASSNAMESTRING

Description

Unique string identifying
the RCS model classattribute characteristics
String representing theversion level of the RCS
Data
Number representation of
the computation day
Number representation of
the computation month
Number representation of
the computation year

ValuesUnits

XX.YY.ZZ

String of 8
characters

DD

N/A

MM

N/A

YYYY

N/A

Uniquely identifiable character
string for the class name© 2015 Open Geospatial Consortium

String of 32
characters

416

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute

FormatDescription

DAT_SRC_T

INT

Data from which RCS wasderived

RCS_VARISTRING

3RD_PARTY

INT

Radar Model Variant(e.g., “AN/APG-65”)

POL_TYPE

INT

Polarization Mode of RFemissionused to characterize RCS

EX_AMPLDOUBLE

EY_AMPLDOUBLE

EX_PHASE

DOUBLE

Transmitted Ex-component
amplitude level
Transmitted Ey-component
amplitude level
Transmitted Ex-component
phase

CLASS_TYP

INTLevel of Classification

3rd party tool used for RCS
Production

Values

0 – 999
0 : UNKNOWN
1 : UNCLASSIFIED
2 : SECRET
3 : TOP SECRET
4 : DECLASSIFIED
999: OTHER
0 - 9990: UNKNOWN
100 : OPENFLIGHT
200 : EMPIRICAL
300 : THIRD-PARTY TOOL
400 : US Air Force
401 : US Army
402 : US Navy
999 : OTHER
7.3.2, Multi-Variant RCS Model
Applicability
0 - 9990: UNKNOWN
100 : RADBASE
200 : XPATCH
300 : MATHLAB/SIMULINK
999 : OTHER
0- 9990 : UNKNOWN
1 : LINEAR
2 : CIRCULAR
3 : ELLIPTICAL
4 : SINGLE HH
5 : SINGLE HV
6 : SINGLE VV
7 : SINGLE VH
8 : DUAL HH-HV
9 : DUAL VV-VH
10 : DUAL HH-VV
11 : ALTERNATING HH-HV
12 : ALTERNATING VV-VH
13 : POLARIMETRIC HH
14 : POLARIMETRIC VV
15 : POLARIMETRIC HV
16 : POLARIMETRIC VH
999: OTHER© 2015 Open Geospatial Consortium

Units

Enumerated

Enumerated

String of 10
characters

Enumerated

Enumerated

INTENS_TY
INTENS_TY
ANGL_TYP

417

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute

Format

EX_FREQDOUBLE

EY_FREQDOUBLEINTENS_TY

INTTransmitted Ey-component
phaseTransmitted Ex-component
frequency
Transmitted Ey-component
frequency
RCS Value units

ANGL_TYPINTRCS Angular Value units

FREQU_TYINTRCS Frequency Value units

TGT_TY

INT

Target Mode Value units

TIME_TY

INTTime Value units

RF_TY

INT

RF Emission Mode TypeLENGTH_TY

INTLength Value units

RF_FREQDOUBLE

Frequency of RF emission
used to characterize RCS

EY_PHASE

DOUBLE

Description

ValuesUnits

ANGL_TYPFREQU_TY
FREQU_TY

0 – 999
0 : UNKNOWN
1 : DB
2 : DBSM
3 : VOLTS
4 : SURFACE
5 : M2
999: OTHER
0 : UNKNOWN
1 : DEGREES
2 : RADIANS
3 : GRADIANS
4 : STERADIANS
0 : UNKNOWN
1 : HERTZ
2 : KILOHERTZ
3 : MEGAHERTZ
4 : GIGAHERTZ
5 : TERAHERTZ
6 : PETAHERTZ
0 : UNKNOWN
1 : NORMAL
2 : SLIGHTLY DAMAGED
3 : DAMAGED
4 : DESTROYED
0 : UNKNOWN
1 : SECONDS
2 : MILLI-SECONDS
3 : MICRO-SECONDS

N/A

0 : UNKNOWN
1 : CONTINUOUS WAVE
2 : PULSED

Enumerated

0 – 999
0 : UNKNOWN
1 : NANOMETER
2 : MICRON
3 : MILLIMETER
4 : CENTIMETER
5 : METER
6 : KILOMETER
999: OTHER

N/A© 2015 Open Geospatial Consortium

N/A

N/A

Enumerated

Enumerated

FREQU_TY

418

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute

FormatDescription

MLOBEGAINDOUBLE

Antenna Main Lobe Gain

INTENS_TY

MLOBEBWDOUBLE

ANGL_TYPSLOBE3DB

DOUBLE

Antenna Main Lobe
Bandwidth

RF_PWIDTHDOUBLE

RF_PRFDOUBLERCS_AVG_I

DOUBLERCS_AVG_A

DOUBLERCS_AVG_P

DOUBLERCS_NML_I

DOUBLERCS_NML_A

DOUBLERCS_NML_P

DOUBLERCS_SD_I

DOUBLERCS_SD_A

DOUBLERCS_SD_P

DOUBLERCS_DMG_I

DOUBLERCS_DMG_A

DOUBLETGT_SSDOUBLE

Significant size of input
Source Model Data

ValuesUnits

LENGTH_TY

Antenna Side Lobe 3dB
Point

ANGL_TYP

RF Pulse Width

TIME_TY

RF Pulse Repetition
Frequency

FREQU_TY

RCS Intensity Average (ormean) Value. This
represents the arithmetic
mean of the RCS table.
RCS Amplitude Average (ormean) Value. This
represents the arithmetic
mean of the RCS table.
RCS Phase Shift Average(or mean) Value. This
represents the arithmetic
mean of the RCS table.
Approximated RCSIntensity Value for ‘Normal’state
Approximated RCS
Amplitude Value for‘Normal’ state
Approximated RCS Phase
Shift Value for ‘Normal’state
Approximated RCSIntensity Value for ‘Slightly
Damaged’ state
Approximated RCS
Amplitude Value for‘Slightly Damaged’ state
Approximated RCS Phase
Shift Value for ‘Slightly
Damaged’ state
Approximated RCSIntensity Value for‘Damaged’ state
Approximated RCS
Amplitude Value for‘Damaged’ state© 2015 Open Geospatial Consortium

INTENS_TY

INTENS_TY

ANGL_TYPINTENS_TY
INTENS_TY
ANGL_TY
INTENS_TY
INTENS_TY
ANGL_TY
INTENS_TY
INTENS_TY

419

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute

FormatRCS_DST_I

DOUBLERCS_DST_A

DOUBLERCS_DST_P

DOUBLE

RCS_FLU_I

DOUBLE

RCS_FLU_A

DOUBLE

RCS_FLU_P

DOUBLERCS_SCINTDOUBLE

RCS_FLASHDOUBLE

EQ_SPH_RD

DOUBLE

MAX_VAL_I

DOUBLE

MAX_VAL_A

DOUBLE

MAX_VAL_P

DOUBLEMIN_VAL_I

DOUBLERCS_DMG_P

DOUBLE

Description

ValuesApproximated RCS Phase
Shift Value for ‘Damaged’
state
Approximated RCSIntensity Value for‘Destroyed’ state
Approximated RCS
Amplitude Value for‘Destroyed’ state
Approximated RCS Phase
Shift Value for ‘Destroyed’state
RCS Intensity Fluctuation(or Variance); the mean of
all squared deviations fromthe mean for all RCS values.
RCS Amplitude Fluctuation(or Variance); the mean of
all squared deviations fromthe mean for all RCS values.
RCS Phase Fluctuation (orVariance); the mean of all
squared deviations from themean for all RCS values.
This value specifies a level 7.3.3, Model’s Articulationsof scintillation to be added
Effect on RCS Data
to the simulated radar
signature when model parts
are being articulated.
RCS Intensity of Target
PA>GOB>P>==BK><MER:M Z
?:<>HK Z;:<D
degrees azimuth. This
“face” value is sometimes
necessary when viewpoint
turns around target and getsa “flash” at those specificangles.
Radius of an approximatedequivalent metallic sphere
substituting the model
RCS Table Max Intensity
Value
RCS Table Max Amplitude
Value
RCS Table Max Phase ShiftValue
RCS Table Min Intensity
Value© 2015 Open Geospatial Consortium

Units

ANGL_TY
INTENS_TY
INTENS_TY
ANGL_TY
N/A

N/A

N/A

INTENS_TY

INTENS_TY

LENGTH_TY
INTENS_TY
INTENS_TY
ANGL_TY
INTENS_TY

420

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute

FormatMIN_VAL_P

DOUBLEAZ_SSANGLDOUBLE

EL_SSANGLDOUBLEAZ_LSANGLDOUBLE

EL_LSANGLDOUBLEMIN_VAL_A

DOUBLE

Description

RCS Table Min Amplitude
Value
RCS Table Min Phase ShiftValue
Azimuth smallest significant
delta angle
Elevation smallest deltasignificant angle
Azimuth largest significant
delta angle
Elevation largest significant
delta angle

ValuesUnits

INTENS_TY
ANGL_TY

Smallest azimuth angle
increment found in data
Smallest elevation angle
increment found in data

ANGL_TYP

Smallest azimuth angle
increment found in data
Smallest elevation angle
increment found in data

ANGL_TYPANGL_TYPANGL_TYP

7.3.1.2
RCS Instance-Level Attribute Data
The data for an entire RCS model itself is stored as a series of Point Shapes, each representing
the RCS data values with respect to the model’s center for the corresponding azimuth andelevation angles as represented by the point X and Y coordinates. The *.dbf portion of the
Shapefile provides the instance attribute information for each of the RCS Point. A description of
the attribute information follows below:
ShapeType = POINT
Values:
X coordinate is the Azimuth angle of the RCS sample
Y coordinate is the Elevation angle of the RCS sample
NOTE:

The RCS of the model when viewed at +90° elevation (top view) is
significantly different than the one at -90° elevation (bottom view), so
there should be (180/EL_STEP)+1 point values to cover all elevations.
The azimuth, which has the same RCS value for +180° and -180° will
cover (360/AZ_STEP) point values.

Table 7-3: RCS Instance Attribute Fields
ATTRIBUTE

TYPE

DESCRIPTIONVALUES

CLASSNAMESTRING

String of 32 characters

RCS_INTE
RCS_AMPL
RCS_PHASDOUBLEDOUBLEDOUBLE

Unique string referring to
the RCS model classattribute name
RCS Intensity Level
RCS Amplitude Level
RCS Phase© 2015 Open Geospatial ConsortiumUNITS

INTEN_TY
INTEN_TY
ANGL_TYP

421

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Shapefile
(RCS)
.Dbf
.Dbf
.Shx
.Shp

RCS Instance
Attributes

RCS Instance
ValuesPoint Shape Attributes

Point Shape Geometry

RCS Model Class Attributes

Figure 7-4: UML Representation of the 3D Model RCS Shapefile Structure

For a given RCS curve in a Shapefile, an attribute “CLASSNAME” indicates which type of
sensor application the curve data is derived for, and under which resolution the data wasproduced. Therefore, the single Shapefile of the Model can regroup all sensor data pertaining tovarious RCS signature types and resolutions for a given RCS Model. Consider the next example.
The Shapefile format therefore does not preclude the capability to support multiple RCS curves
simultaneously for a given model.

© 2015 Open Geospatial Consortium

422

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

F16 Model RCS Dataset
POLARIZATION: LINEAR (1)F16 RCS Model Class Attributes
Classname: "CW "POL_TYPE=1
RF_FREQ=10000
RCS_AVG=...
RF_TY=1
AZ_SSANGL=10°
EL_SSANGL=10°
Classname: "PULSED "POL_TYPE=1
RF_FREQ=10000
RCS_AVG=...
RF_TY=0
AZ_SSANGL=5°
EL_SSANGL=5°Classname: "TEST "POL_TYPE=1
RF_FREQ=10000
RCS_AVG=...
AZ_SSANGL=2°
EL_SSANGL=2°

FREQUENCY: 10GHz (10000 MHz)

F16 Model RCS Shapefile

Instance Attributes:
Classname: "CW"RCS_INTE=...
RCS_AMPL=...
RCS_PHAS=...

Points:(180/5)+1=37 *(360/5)+1=73 Points per part==> 2701 points

Instance Attributes:
Classname: "PULSED"RCS_INTE=...
RCS_AMPL=...
RCS_PHAS=...

Points:(180/5)+1=37 *(360/5)+1=73 Points per part==> 2701 points...

Figure 7-5: Example of RCS Shapefile

7.3.2
Multi-Variant RCS Model Applicability
Each variant of the RCS model in the Shapefile has a 10-character string attribute called“RCS_VARI”. The string may contain the specific Radar model number (and possibly its
frequency band L-Band, S-Band, X-Band, Ku-Band) for which this RCS variant applies to. The
suggested string convention for this field is as described in reference [22]:For example: The “AN/APG-65” Radar model name represents a Pulse Doppler X-Band MultiMode Radar manufactured by Raytheon (Hughes) and used in F/A-18, AV-8B+ aircraft.

Table 7-4: Radar Model Numbers

AN/APA - Airborne Radar Auxiliary Assemblies
Model Number
AN/APA-1
AN/APA-2
AN/APA-3
AN/APA-4
AN/APA-5

Description
Indicator Unit (Remote Repeater Scope) used with US Navy ASB radar
Radar Antenna Equipment
Radar Antenna Equipment
Radar Alarm Unit
Auxiliary Electronic Bombsight Equipment; used in P-2© 2015 Open Geospatial Consortium

423

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APA-6
AN/APA-7
AN/APA-8
AN/APA-9
AN/APA-10
AN/APA-11
AN/APA-12
AN/APA-13
AN/APA-14
AN/APA-15
AN/APA-16
AN/APA-17
AN/APA-19
AN/APA-21
AN/APA-23
AN/APA-24
AN/APA-25
AN/APA-26
AN/APA-27
AN/APA-28
AN/APA-29
AN/APA-33
AN/APA-35
AN/APA-36
AN/APA-38
AN/APA-39
AN/APA-40
AN/APA-42
AN/APA-43
AN/APA-44
AN/APA-45
AN/APA-48
AN/APA-49
AN/APA-50
AN/APA-51
AN/APA-52
AN/APA-54
AN/APA-55
AN/APA-56

Description
Panoramic Radio Receiving Set; used with AN/APR-9 and AN/APR-14
Movie-Camera Photo Set
Video Amplifier; used with AN/APS-2
ECM Equipment; used in P2V-5
Panoramic Radio Receiving Set; used with AN/SPR-2
Panoramic Radio Receiving Set (Pulse Analyzer); used in B-52 EW pod, RC-121C,
P2V-5, PBM-5S used with AN/APR-9 and AN/APR-14;
Sector Scan Antenna Adapter; used with AN/APS-2
Component of AN/APS-15
Component of AN/APS-15
Elevation Stabilizer; used with AN/APS-15
Auxiliary Electronic Bombsight Equipment used in PBY-6A
250-1000 MHz Broadband Direction Finding Radar (used with search receivers);
manufactured by Hoffman Radio Corp., Aviola
Bombing Aid
Radar Bombing Compensating Unit
Automatic Tape Recorder; manufactured by Gamewell; used with AN/APR-1/2/4/5/6
50-280 MHz Direction Finding Radar (used with search receivers); manufactured byHeyer Products used in P4M-1Q
Radar Direction Finding Antenna Unit
S-Band Attenuator
Automatic Search & Jam Tuning Adapter
Multiple Indicator Equipment (6 displays); used with AN/APQ-13
Bombing Altitude Control Unit
Multiple Indicator Equipment (4 displays); used with AN/APQ-7
Radar Signal Recording Camera Unit
Remote Repeater Scope (modified AN/APA-1); used with AN/APQ-13
Panoramic Radio Receiving Set; used in PBM-5S
Radar Identification Unit
Bombing/Navigation System used with AN/APS-15; used in B-17
Bombing/Navigation System; used with AN/APS-23; used in XB-48 (see AN/APA59)
Airborne Searchlight Control
Ground Position Indicator System; manufactured by Bell Telephone Lab; used with
AN/ASB-3 and AN/APS-23/27/31 used in B-45 (together with AN/APS-23 to form
AN/APQ-24), RB-66
Radar Antenna Tilt Stabilizer Unit
Radar Homing Equipment, 140-300 MHz; manufactured by RRL
Radar Bombing Ground Position Indicator
Low Altitude Rocket Bombing Unit
Radar Indicator Unit
X-Band TACAN Doppler Navaid; used in F-8, SB-29
Radar Recorder Group (SHORAN); used in B-57
Radar Adapter Unit
Radar Display Console; used with AN/APS-45/95; used in EC-121© 2015 Open Geospatial Consortium

424

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APA-57
AN/APA-58
AN/APA-59
AN/APA-60
AN/APA-61
AN/APA-62
AN/APA-63
AN/APA-64
AN/APA-66
AN/APA-69
AN/APA-70
AN/APA-72
AN/APA-74
AN/APA-80
AN/APA-81
AN/APA-82
AN/APA-84
AN/APA-85
AN/APA-89
AN/APA-90
AN/APA-91
AN/APA-92
AN/APA-94
AN/APA-95
AN/APA-106
AN/APA-109
AN/APA-113
AN/APA-122
AN/APA-125
AN/APA-126
AN/APA-127
AN/APA-128
AN/APA-138
AN/APA-141
AN/APA-143
AN/APA-144
AN/APA-150

Description
Ground Position Indicator Group; used in AF-2W, P-2, S-2; replaced by AN/ASA-13
Ground Position Computer
Bombing/Navigation Computer "SRC-1"; manufactured by Sperry; used in B-36,
XB-48
Autopilot
Radar Bombing Navigational Computer
Panoramic Receiver
Autopilot
Radar Signal Analyzer used in P2V-4
Radar Monitor
Direction Finding Radar Set; used in RB-57D, A-1, C-47, P-2, P-5, S-2, RC-121C,
Z-1, ZPK
Direction Finder Group; used with AN/APR-9; used in AF-2W, P-2, S-2, TBM-3S
Signal Analyzer; used in E-2
Pulse Analyzer Group; manufactured by Loral; used in EB-66, A-3, EC-47, P-2, P-5,
Z-1, ZPK; replaced AN/APA-11
Control & Guidance Monitoring Group; used in AUM-N-2, HSL-1, P-2, P-5, S-2
Ground Position Indicator Group; used with AN/APS-20; used in AF-2W, EC-121
Direction Finder Group; used in B-52, C-130, C-133, C-135
Radar Intercept Targeting Computer; used with APG-37; used in F-86D/K
Control-Indicator Group; used with AN/APS-42 used in R6D-1
Coder Group; used in A-3, UH-1E
Indicator Group; used with AN/APW-11; used in B-57, B-66
used with AN/APS-33
ECM SetSignal Analyzer
Doppler Navigation Computer
Bomb Damage Evaluation Group; used with AN/APQ-24; used in B-50D
Radar Control; manufactured by Westinghouseused with AN/APS-62
Radar Set
Radar Display; used with AN/APS-80/82, AN/ASA-47; used in P-2H, P-3A, P-5, E1
Doppler Equipment; used in A-7
Sparrow Missile Fire Control System; manufactured by Raytheon; used in F-3, F4B/C
Sparrow Missile Radar Set Group; manufactured by Raytheon; used with AN/AWG7; used in XF8U-3, F-4
Radar Display; used with AN/AWG-7; used in XF8U-3
Radar Set; used in B-52G/H
Rotodome Antenna Group; manufactured by Dalmo Victor; used with AN/APS-96;
used in E-2A/B
Signal Analyzer Group; used in EA-1F, EC-121M, P-3A
Station Keeping System; used in SH-34J© 2015 Open Geospatial Consortium

425

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APA-153
AN/APA-157
AN/APA-159
AN/APA-160
AN/APA-161
AN/APA-162
AN/APA-164
AN/APA-165
AN/APA-167
AN/APA-170
AN/APA-171
AN/APA-172
AN/APA-173

Description
Cable Breakout Adapter Set; manufactured by AC Spark Plug; used with AN/APS104
Continuous Wave Illuminator (for AIM-7 targeting); manufactured by Raytheon;used in F-4B/C
Radar Set Group; manufactured by Hazeltine; used in EC-121D/H
Test Adapter; manufactured by Sperry; used with AN/APN-42
Station Keeping System used in ASW helicopters
Map Matcher
Rotodome; used with AN/APS-111; used in E-2A/B
Intercept Computer (for AIM-9 firing); manufactured by Raytheon; used with
AN/APQ-109 used in F-4D
used with AN/APG-53
Radar Set
Rotodome Antenna Group; used with AN/APS-120, AN/APX-76; used in E-2C
Control Indicator Group; used with AN/APS-120, AN/APX-76; used in E-2C
Test Bench

AN/APB - Airborne Bombing Radars
Model Number
AN/APB-1
AN/APB-2

Description
Radar Beacon
Bombing Radar; used in B-58

AN/APD - Airborne Direction Finding and Surveillance Radars
Model Number
AN/APD-1
AN/APD-2
AN/APD-4
AN/APD-5
AN/APD-7
AN/APD-8
AN/APD-9
AN/APD-10
AN/APD-11
AN/APD-12
AN/APD-13
AN/APD-14
AN/APD-501

Description
Homing Radar; used in TBF/TBM
Radar Direction Finding Set; used with AN/APR-1 and AN/APA-48
D/E/F-Bamd Radar Direction Finding System; manufactured by ITT; used in RB47H, B-52, EB-66C
Reconnaissance Radar
Radar Surveillance System; manufactured by Westinghouse; used in OV-1D, RA-5C
Side-Looking Reconnaissance Radar; manufactured by Westinghouse; proposed for
RF-111A
Radar Set
Side-Looking Reconnaissance and Mapping Radar; used in F-4, RF-4B/C, CP-140;
special tests in NC-141, C-130
Side-Looking Radar Reconnaissance Set; part of AN/UPD-6; used in RF-4E
I/J-band Side-Looking Reconnaissance System; manufactured by Lockheed Martin;
part of AN/UPD-8 and AN/UPD-9; used in Israeli RF-4B
QUICK LOOK Electronic Intelligence Subsystem; manufactured by Systems &Electronics; used in "Guardrail" RC-12
SAROS (SAR for Open Skies) Radar System; manufactured by Sandia; part of
AN/UPD-8; used in OC-135
Maritime Patrol Radar; used in Lancaster (Canada)© 2015 Open Geospatial Consortium

426

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

AN/APG - Airborne Fire Control Radars
Model Number
AN/APG-1
AN/APG-2
AN/APG-3
AN/APG-4
AN/APG-5
AN/APG-6
AN/APG-7
AN/APG-8
AN/APG-9
AN/APG-10
AN/APG-11
AN/APG-12
AN/APG-13
AN/APG-14
AN/APG-15
AN/APG-16
AN/APG-17
AN/APG-18
AN/APG-19
AN/APG-20
AN/APG-21
AN/APG-22
AN/APG-23
AN/APG-24
AN/APG-25
AN/APG-26
AN/APG-27
AN/APG-28
AN/APG-29
AN/APG-30
AN/APG-31
AN/APG-32
AN/APG-33
AN/APG-34
AN/APG-35

Description
S-Band Intercept Radar used in P-61B
S-Band Intercept & Gun Laying Radar used in P-61
Tail Gun Laying Radar; manufactured by General Electric used in B-29 and B-36B
L-Band Low Altitude Torpedo Release Radar "Sniffer" used in TBM
S-Band Gun Laying/Range-Finding Radar used in B-17, B-24 and F-86A (AN/APG5C)
L-Band Low Altitude Bomb Release Radar "Super Sniffer" (improved AN/APG-4)
Glide Bomb Control Radar "SRB" (Seeking Radar Bomb)
S-Band Turret Fire Control Radar used in B-29B
L-Band Low Altitude Bomb Release Radar (improved AN/APG-6)
Weapons System Radar
L-Band Toss Bombing Radar
L-Band Low Altitude Bomb Release Radar (improved AN/APG-9)
S-Band Nose Gun Laying Radar "Falcon"; manufactured by General Electric usedwith 75mm nose gun of B-25H
S-Band Gun Sight Radar used in B-29
S-Band Tail Gun Radar used in B-29B, PB4Y
X-Band Gun Laying Radar (modification of AN/APG-2) used in B-32, XB-48
S-Band Low Altitude Bomb Release Radar (improved AN/APG-4)
X-Band Turret Control Radar (improved AN/APG-5); manufactured by Martin usedwith "S-4" gunfightX-Band Fire Control Radar; manufactured by Martin (improved AN/APG-8 and -18)
S-Band Low Altitude Bomb Release Radar (improved AN/APG-6)
Ground-Ranging Radar
X-Band Gun Sight Radar; manufactured by Raytheon used with Mk.18/23 LeadComputing Gun Sights
Weapons System Radar used in B-36A
Weapons System Radar used in B-36B
X-Band Gun Tracking Radar used in F-100
Weapons System Tracking Radar; manufactured by Westinghouse used in F3D
Tail Gun Radar used in XB-46 and XB-48
Intercept Radar (modified AN/APG-1) used in F-82F
Night/All-Weather Fighter Fire-Control Radar (for Type D-1 Fire-Control System)
X-Band Fire Control Radar; manufactured by Sperry used in B-45, B-57, F-4E, F8A, F-84E, F-86A (final blocks only), F-86E/F, F-100, FJ-2, F2H-2
Gun Laying Radar; manufactured by Raytheon used in B-57
X-Band Tail Turret Autotrack Radar; manufactured by General Electric used in B36D/F, B-47E
X-Band Fire Control Radar; manufactured by Hughes used in TB-25K, F-94A/B, F89A
Computing Radar Gunfight used in F-104C
Radar used in F3D© 2015 Open Geospatial Consortium

427

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APG-36
AN/APG-37
AN/APG-39
AN/APG-40
AN/APG-41
AN/APG-43
AN/APG-45
AN/APG-46
AN/APG-48
AN/APG-50
AN/APG-51
AN/APG-53
AN/APG-55
AN/APG-56
AN/APG-57
AN/APG-59
AN/APG-60
AN/APG-61
AN/APG-63
AN/APG-64
AN/APG-65
AN/APG-66
AN/APG-67
AN/APG-68
AN/APG-69
AN/APG-70
AN/APG-71
AN/APG-73
AN/APG-74
AN/APG-76
AN/APG-77

Description
Search Radar used in F2H-2N, F-86D (replaced by AN/APG-37)
Search Radar; manufactured by Hughes used in F-86D/K/L, F2H-4
Gun Laying Radar used in B-47E
Fire Control Radar; manufactured by Hughes used in TB-25M, F-94C, F-89D, CF100 (Canada)
Tail Gun Radar (twin radomes); manufactured by General Electric used in B-36H
Continuous Wave Interception Radar; manufactured by Raytheon
Fire-Control Radar (miniaturized AN/APG-30); manufactured by General Electric;
intended for patrol aircraft gun turrets
Fire-Control Radar; tested in A-6A
Airborne Fire-Control System Mk.22
Intercept Radar used in F-4
Intercept Radar; manufactured by Hughes used in F3H-2, F3D
Weapons System Radar; manufactured by Stewart-Warner used in A-4
Pulse Doppler Intercept Radar; manufactured by Westinghouse
Fire Control Radar (similar to AN/APG-30) used in F-86 (only Australian models
with A-4 gun sight)
Fire-Control Radar; manufactured by Gould
Pulse-Doppler Gunnery Radar; manufactured by Westinghouse; part of AN/AWG-10
used in F-4J
Doppler Radar; part of AN/AWG-11 used in F-4K
Fire-Control Radar; part of AN/AWG-12 used in F-4M
Pulse Doppler X-Band Fire Control Radar (AN/APG-63(V)2 is an AESA variant);
manufactured by Raytheon (Hughes) used in F-15A/B/C/D/H/K
Fire-Control Radar (development of AN/APG-63); not produced
Pulse Doppler X-Band Multi-Mode Radar; manufactured by Raytheon (Hughes)
used in F/A-18A/B, F-4 ICE/Peace Ikarus 2000, AV-8B+ (upgraded)
Pulse Doppler X-Band Multi-Mode Radar; manufactured by Northrop Grumman(Westinghouse) used in F-16A/B, F-4EJ (Japan), Hawk 200 (UK)
Pulse Doppler X-Band Multi-Mode Radar; manufactured by Lockheed Martin(General Electric) (Model G-200) used in F-20, A-50 (Korea), F-5-2000 (Taiwan),
Ching Kuo (Taiwan)
Pulse Doppler X-Band Multi-Mode Radar (improved AN/APG-66); manufactured by
Northrop Grumman (Westinghouse) used in F-16C/D-30/40/50
Radar Set; manufactured by Emerson used in F-5E, AV-8?
Pulse Doppler X-Band Multi-Mode Radar (upgrade of AN/APG-63); manufactured
by Raytheon (Hughes) used in F-15C/D/E
Pulse Doppler X-Band Multi-Mode Radar; manufactured by Raytheon (Hughes)
used in F-14D
Pulse Doppler X-Band Multi-Mode Radar (upgrade of AN/APG-65); manufactured
by Raytheon (Hughes) used in F/A-18C/D/E/F
Pod-mounted Radar System; manufactured by Northrop Grumman (Norden)
Pulse Doppler Ku-Band Multi-Mode Radar; manufactured by Northrop Grumman(Norden) used in F-4E (Israel); tested in pod with F-16, S-3B
Pulse Doppler X-Band AESA (Active Electronically Scanned Array) Multi-ModeRadar; manufactured by Northrop Grumman/Raytheon used in F/A-22A© 2015 Open Geospatial Consortium

428

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APG-78
AN/APG-79
AN/APG-80
AN/APG-81
AN/APG-501
AN/APG-T1

Description
Fire Control Radar "Longbow"; manufactured by Northrop Grumman & Lockheed
Martin used on mast in AH-64D, RAH-66, underwing on AH-1W/Z
AESA (Active Electronically Scanned Array) Multi-Mode Radar (based on
AN/APG-73); manufactured by Raytheon used in F/A-18E/F/G as replacement for
AN/APG-73"Agile Beam Radar" AESA (Active Electronically Scanned Array) Multi-ModeRadar (based on AN/APG-68); manufactured by Northrop Grumman; intended for F16E/F
AESA (Active Electronically Scanned Array) Radar planned for F-35
X-Band Ranging Radar used in F-86
Radar Training Set for AN/APG-1

AN/APN - Airborne Navigation Radars
Model Number
AN/APN-1
AN/APN-2
AN/APN-3
AN/APN-4
AN/APN-5
AN/APN-6
AN/APN-7
AN/APN-8
AN/APN-9
AN/APN-10
AN/APN-11
AN/APN-12
AN/APN-13
AN/APN-14
AN/APN-15
AN/APN-16
AN/APN-18
AN/APN-19
AN/APN-20
AN/APN-21
AN/APN-22
AN/APN-23
AN/APN-24
AN/APN-25
AN/APN-26
AN/APN-29

Description
Radio Altimeter (improved AN/ARN-1) used in P-61, C-119, B-32, C-121, H-19, P5, AF-2W, AD-5, F2H-2/2N/2P, F3D, F6F-5N, F9F, XF10F-1, P2V-4, PB4Y-2,
PBM-5S, PBY-6A, R5C-1, R5D-2, R6D-1, SB2C-5, TBM-3S"Rebecca" Radio Beacon used with AN/PPN-1, AN/TPN-2
SHORAN used with AN/CPN-2 used in B-45A
LORAN; manufactured by Philco used in B-29, B-32, C-47, C-54, C-117, C-121,
P2V-4, PBM-5S, PBY-6A, PB4Y-2, R4Q-1, R6D-1
Radar Beacon Navigation Aid used in F-86
S-Band Beacon used with AN/PPN-10, AN/PPN-11
LORAN S-Band Beacon used with AN/APS-2
Radar Beacon
LORAN; manufactured by RCA used in B-29, B-32, RC-121, C-97 replaced
AN/APN-4"Rebecca" Interrogation Set
X-Band Beacon used with AN/APS-3/4/6/10/15/31/33 used in B-47, KC-97, XS-1
Rendezvous Radar (or 160-230 MHz "Rebecca" Interrogator) used in B-47, C-97
S-Band Beacon (improved AN/APN-7)
Navigation Aid
Low Level Altimeter Set; manufactured by Sperry used in B-52, CH-3C
Radar Beacon
Radar Beacon"Rosebud" S-Band Beacon used in F-82D
Radar Beacon
Radar Beacon
Radar Altimeter; manufactured by Electronic Assistance Corp used in A-3, B-66, C119, RC-121, C-130, RF-101C, OV-1, AD-5, P2V-5, R6D-1
Active Seeker used in KAY-1(XSAM-N-4)
Navigation Set
Doppler Navigator; manufactured by GPI
SG-Band (VHF) Beacon
SG-Band (VHF) Beacon© 2015 Open Geospatial Consortium

429

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APN-30
AN/APN-33
AN/APN-34
AN/APN-35
AN/APN-36
AN/APN-37
AN/APN-38
AN/APN-39
AN/APN-40
AN/APN-41
AN/APN-42
AN/APN-45
AN/APN-46
AN/APN-47
AN/APN-48
AN/APN-49
AN/APN-50
AN/APN-52
AN/APN-54
AN/APN-55
AN/APN-56
AN/APN-57
AN/APN-58
AN/APN-59
AN/APN-60
AN/APN-61
AN/APN-63
AN/APN-66
AN/APN-67
AN/APN-68
AN/APN-69
AN/APN-70
AN/APN-71
AN/APN-75
AN/APN-76
AN/APN-77
AN/APN-78
AN/APN-79
AN/APN-81
AN/APN-82

Description
Radar Beacon
S-Band Beacon; replaced AN/APN-7 used in XSSM-N-8
Distance Measuring Radar used in C-97C, R6D-1
Radar Beacon
Radar Beacon
Radar Beacon
Radar Beacon
Radar Beacon
Radar Beacon
Missile Beacon for LTV-N-2 replaced AN/APN-33
Radar Altimeter used in WC-130, WB-47E, B-52
Tracking Radar Beacon used in DC-130A
Radar Beacon
Radar Beacon
Radar Beacon
Radar Beacon
Navigation Radar; manufactured by Sperry
Radar Set
Radar Beacon
Radar Beacon (for missiles)
Navigation Radar; manufactured by Gould
Ground Position Indicator
Navigation Radar; manufactured by Sperry
Search & Weather Radar; manufactured by Sperry used in C-130, C-135, B-57, C133, C-141, KC-97
S-Band Beacon used in B-52
Radar Beacon used in XF-85
S-Band (Receive)/L-Band (Transmit) Beacon; manufactured by Melpar
Doppler Navigation Radar used in SM-62, B-47
Doppler Set used in P6M-1, NC-121 "Project Magnet", USN helicopters; tested in P2
IFF Beacon used with AN/APX-6
X-Band Rendezvous Beacon used in B-47, B-52, C-97, RB-57D, KC-135 used with
AN/APN-59
LORAN; manufactured by Dayton Aviation Radio & Equip Corp used in B-50, C54, C-119, C-121, RC-121D, C-130, C-135, P-2, P-3A, T-29C/D, Z-1, R6D-1
Flare-Out Unit
Rendezvous Radar used in B-47
Rendezvous Radar; manufactured by Olympic used in KC-97, B-47B/E
Doppler Set used in SZ-1B, USN helicopters
Doppler Set used in helicopters
Doppler Set manufactured by Teledyne Ryan used in helicopters
Doppler Set used in RB/WB-66, WB-50, C-130, KC-135
Doppler Navigation Radar (combination of AN/APN-81 and AN/ASN-6) used in
EB/RB/WB-66, KC-135© 2015 Open Geospatial Consortium

430

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APN-84
AN/APN-85
AN/APN-89
AN/APN-90
AN/APN-91
AN/APN-92
AN/APN-96
AN/APN-97
AN/APN-99
AN/APN-100
AN/APN-101
AN/APN-102
AN/APN-103
AN/APN-105
AN/APN-107
AN/APN-108
AN/APN-109
AN/APN-110
AN/APN-113
AN/APN-114
AN/APN-115
AN/APN-116
AN/APN-117
AN/APN-118
AN/APN-119
AN/APN-120
AN/APN-122
AN/APN-126
AN/APN-127
AN/APN-128
AN/APN-129
AN/APN-130
AN/APN-131
AN/APN-132
AN/APN-133
AN/APN-134
AN/APN-135

Description
SHORAN Set; manufactured by Hazeltine used in RC-130A
Navigation Radar; manufactured by Hazeltine
Doppler Set; part of AN/ASQ-38 used in B-52E/G/H
Doppler Set
Tracking Beacon used in BQM-34C
Navigation Radar
Doppler Set
Doppler Set; manufactured by Ryan used in UH-2A, SH-3, SH-34J
Doppler Navigation Set (combination of AN/APN-81 and AN/ASN-7) used in B-52,
AC-130A, KC-135
Radar Altimeter; manufactured by Litton used in CH-47A
Airborne Radar used in RF-4C, F-4E (possible confusion with AN/ARN-101)
Doppler Set; manufactured by GPI used in RB-47, WB-47E, RB-57F, WB-57F, F100C/F, RF-101
Navigational Computer System
All-Weather Doppler Navigation System; manufactured by LFE used in F-105B/D,
T-39B
Navigation Radar used in RB-57D
Doppler Set (derivative of AN/APN-89 with gyro components from AN/APN-81)
used in B-52E
Altimeter; manufactured by Honeywell
Doppler Navigation Set used in B-58, F-100D/F, RF-101
Doppler Radar; part of AN/ASQ-42 used in B-58
Automatic Landing System used with AN/GSN-5; tested in TF-102
Navigation Radar; manufactured by General Electric
Doppler Set
Low-Level Radar Altimeter (in combination with AN/APN-22); manufactured byElectronic Assistance Corp used in A-6A, P-2, S-2, SH-3A, H-13H, CH-47A, HH52, CH-53A
Doppler Navigation Set
Doppler Set
Radar Altimeter; planned for A-5, A-6A, but not produced
Doppler Navigation Set used in S-2, A-2, A-3, A-4, A-6, RA-5C, C-47, C-54, EC121, E-2, TF-8, P-2, P-3, P-5
Doppler Set
Collision Warning System
Navigation Radar; manufactured by Teledyne used in C-130
Doppler Navigation System; manufactured by Teledyne used in OV-1A/B
Doppler Radar; manufactured by Teledyne Ryan used in UH-2, SH-3, SH-34J, CH53D, Z-1
Doppler Navigation Radar used in F-105, T-39B, TF-8A
X-Band Beacon; manufactured by Motorola used in BQM-34A, QF-9G
High-Altitude Radar Altimeter (upgraded SCR-728) used in C-130, C-135
Ku-Band Beacon; manufactured by Bendix used in KC-135
X-Band Beacon (for in-flight refueling); manufactured by Bendix used in B-58

© 2015 Open Geospatial Consortium

431

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APN-136
AN/APN-140
AN/APN-141
AN/APN-142
AN/APN-144
AN/APN-145
AN/APN-146
AN/APN-147
AN/APN-148
AN/APN-149
AN/APN-150
AN/APN-151
AN/APN-152
AN/APN-153
AN/APN-154
AN/APN-155
AN/APN-157
AN/APN-158
AN/APN-159
AN/APN-161
AN/APN-162
AN/APN-163
AN/APN-165
AN/APN-167
AN/APN-168
AN/APN-169
AN/APN-170
AN/APN-171
AN/APN-172
AN/APN-174
AN/APN-175
AN/APN-176
AN/APN-177
AN/APN-178
AN/APN-179
AN/APN-180

Description
Ku-Band Beacon (for in-flight refueling); manufactured by Bendix used in B-58
Radar Altimeter
Low Altitude Radar Altimeter; manufactured by Bendix used in A/TA-4, A-6, A-7,
C-2, C-130, C-141, E-2C, F-4, F-8, F-104, F-105, P-3, S-2, T-39, SH-3
Navigation Radar used in F-4C
Doppler Navigation Radar used in EC-121, VC-137
LORAN C Set used in RC-135D
Radar Altimeter
Doppler Navigation System; manufactured by Canadian Marconi used in AC-119, C124C, C-130, WC-130B/E, RC-135A, WC-135B, C-135F, C-141
Doppler Navigation Radar used in F-105D/F
Terrain Avoidance Radar used in TF-8
Radar Altimeter used in CH-3C, B-52, C-130, EC-130E, C-135
LORAN C Receiver; manufactured by ITT used in RC-135B, C-141A, H-3
LORAN C Receiver
Doppler Navigation Radar used in A-6, A-4, EA-6A/B, A-7, C-130G, E-2, P-3A, S2E
X-Band Beacon Augmenter (Tracking Beacon); manufactured by Motorola used with
AN/TPB-1, AN/TPQ-10 used in A-4, A-7, F-14, A-6, AH-1T, H-46, CH-53
Low Altitude Radar Altimeter; manufactured by Stewart-Warner used in F-4
LORAN C Receiver; manufactured by ITT used in C-130, RC-135B, C-141, P-3C,
EP-3E
Weather Radar; manufactured by Collins used in HC-123B, U-8F, U-21A, CV-2
Radar Altimeter; manufactured by Stewart-Warner used in RF-4
High-Resolution Mapping Radar; manufactured by Sperry used in C-130
manufactured by Canadian Marconi
Doppler Navigation System
Terrain-Following/Ground-Mapping Radar; manufactured by Texas Instruments used
in OV-1
Radar Altimeter; manufactured by Honeywell used in F/FB-111A
Doppler Radar; manufactured by Canadian Marconi used with AN/AYA-3 used in
CH-53A, OV-1
Station-Keeping Radar; manufactured by Sierra Research used in C-130, C-141
Terrain Following Radar; manufactured by General Dynamics; tested in A-4C, B-52,
B-58
Radar Altimeter; manufactured by Honeywell used in C-130, E-2C, SH-2F, SH-3H,
OH-6A, CH-46, CH-53
Doppler Set; manufactured by Marconi used with AN/ASN-73 used in HH-53C, CH53G
Station-Keeping Subsystem; manufactured by Teledyne used in CH-46, CH-53
Doppler Radar used in C-130, CH-3B, HH-3E, MH-53
Radar Altimeter; manufactured by Texas Instruments used in FB-111A
Doppler Altimeter
Navigation Radar; manufactured by Sierra used in C-130
Doppler Navigation Radar; manufactured by Bendix used in EC-47
LORAN A Automatic Tracking Receiver used with AN/AYN-1 used in HH-3F© 2015 Open Geospatial Consortium

432

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APN-181
AN/APN-182
AN/APN-184
AN/APN-185
AN/APN-186
AN/APN-187
AN/APN-189
AN/APN-190
AN/APN-191
AN/APN-192
AN/APN-193
AN/APN-194

AN/APN-195
AN/APN-196
AN/APN-197
AN/APN-198
AN/APN-199
AN/APN-200
AN/APN-201
AN/APN-202
AN/APN-203
AN/APN-205
AN/APN-206
AN/APN-208
AN/APN-209
AN/APN-210
AN/APN-211
AN/APN-213
AN/APN-214
AN/APN-215
AN/APN-217
AN/APN-218

Description
LORAN C/D Receiver
Doppler Radar Navigation System; manufactured by Ryan used with AN/AYK-2
used in SH-3H, CH-46, HH-46A/D, SH-2D, UH-2C, RH-53
Radar Altimeter; manufactured by Bendix used in C-130, Hawker P-1127 (UK)
Doppler Navigation Radar; manufactured by Singer-Kearfott used in FB-111A, A7D, B-1A
Doppler System; tested in A-6 ILAAS (AN/ASQ-116)
Doppler Navigation Radar; manufactured by Singer-Kearfott used in P-3
Doppler Navigation Radar; manufactured by Marconi used in F-111D
Doppler Radar; manufactured by Singer-Kearfott used in A-7, AC-130E, F-111
Radar Altimeter used in A-7D
Short-Pulse Radar Altimeter; manufactured by Teledyne used in CH-47
Doppler Velocity Sensor; manufactured by Ryan
Radar Altimeter; manufactured by Honeywell used in F-14, A-6E, AH-1W, HH-60H,
EA-6B, AV-8B, C-2A, P-3C, EP-3E, F/A-18, SH-60B/F, T-45A, TA-4J, TC-130G,
S-3, A-4, A-7, A-10, B-1, TC-4C, QF-4, BQM-8D/F, MQM-8G, BQM-34S, AQM34U, RGM/UGM-109B
Nose-Mounted Radar; manufactured by Collins used in SH-3D, HH-3E
Doppler Radar used in F-105
STATE Airborne Station; manufactured by Honeywell used with AN/TPN-21,
AN/UPN-33; tested in C-123, C-131, T-39, CH-3
Radar Altimeter; manufactured by Honeywell used in F-104G, AV-8, Sea King(UK), Lynx (UK)LORAN Receiver; manufactured by Collins used in C-5A
Doppler Velocity Sensor; manufactured by Teledyne used in B-1, E-3, S-3
Radar Altimeter; manufactured by Hoffman Electronics used in S-3
Radar Beacon; manufactured by Motorola used with AN/SPN-46 ACLS (Automatic
Carrier Landing System) used in AV-8B, F/A-18, S-3, C-2, P-3C
Radar Altimeter; manufactured by Stewart-Warner used in T-43A
Doppler Radar; manufactured by Teledyne used in SH-2, SH-60B
Doppler Set used in B-1A
Doppler Navigation Radar; manufactured by Marconi used in HH-53H, Bell 412
Radar Altimeter; manufactured by Honeywell/Stewart-Warner used in AH-1F, UH1V, CH-47D, OH-58C/D, H-60, T-43A
Doppler Set; manufactured by Singer used in CH-53G
Navigation Radar; manufactured by Teledyne-Ryan used in helicopters
Doppler Velocity Sensor; manufactured by Litton (Teledyne-Ryan) used in E-3;
tested in KC-135
Radar Altimeter
Weather & Search Radar; manufactured by Bendix/King used in RU-38A, U-21, C130
Doppler Radar Navigation Sensor; manufactured by Litton (Teledyne-Ryan) used in
AH-1W, UH-1N, SH-2G, SH-3D, HH-3F, CH-46, CH-53E, MH-53E, RH-53D, HH60H/J, SH-60B/F/J, V-22
Doppler Radar Navigation System; manufactured by Litton (Teledyne-Ryan) used in
B-1B, B-52G/H, KC-135, C-130, F-111G© 2015 Open Geospatial Consortium

433

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APN-220
AN/APN-221
AN/APN-222
AN/APN-224
AN/APN-227
AN/APN-230
AN/APN-231
AN/APN-232
AN/APN-233
AN/APN-234
AN/APN-235
AN/APN-236
AN/APN-237
AN/APN-238
AN/APN-239
AN/APN-240
AN/APN-241
AN/APN-242
AN/APN-243
AN/APN-244
AN/APN-245
AN/APN-501
AN/APN-503
AN/APN-509
AN/APN-510
AN/APN-511
AN/APN-512
AN/APN-513
AN/APN-T6
AN/APN-T8
AN/APN-T10

Description
Doppler Radar; manufactured by Teledyne-Ryan
Doppler Radar (derived from AN/APN-208); manufactured by Marconi used in C141, HH-53H, MH-53J
Radar Altimeter; manufactured by Honeywell used in C-130, E-6A
Radar Altimeter; manufactured by Honeywell used in B-52G/H, B-1B
Doppler Radar used in P-3C
Doppler Navigation Radar (improved AN/APN-218) used in B-1B
Radar Navigation System; manufactured by Teledyne-Ryan used in EA-6A
CARA (Combined Altitude Radar Altimeter); manufactured by Gould used in C-5,
C-17, C-130, OC-135, C-141, F-16
Doppler Navigation Radar (developed from AN/APN-220); manufactured by
Teledyne-Ryan used in C-2, OV-10D, CH-47, S-2, Alpha Jet (Germany), DHC-5
Weather and SAR Radar (Model RDR-1400C; improved AN/APN-215);
manufactured by Telephonics (originally by Bendix/King) used in P-3, C-2
Doppler Navigation Set (development of AN/APN-221) used in HH-60A
Doppler Radar System; manufactured by Teledyne
Ku-Band Terrain-Following Radar; manufactured by Texas-Instruments; part of
AN/AAQ-13
Weather and SAR Radar (Model RDR-1400C, similar to AN/APN-234);
manufactured by Telephonics (originally by Bendix/King) used in HH-60G, MH60G
Station-Keeping System; manufactured by Sierra Research; replaced AN/APN-169
Weather & Navigation Radar; manufactured by Northrop Grumman (Westinghouse)used in C-130H/J, C-27J, HS-748 (Australia)
Weather & Navigation Radar; manufactured by Sperry; replacement for AN/APN-59
Station-Keeping Equipment; manufactured by Sierra Technologies used in C-17, C130J
E-TCAS (Enhanced Traffic Alert Collision Avoidance System); manufactured by
Honeywell (AlliedSignal) used in C-130E/H/J
Radar Beacon used with ACLS (Automatic Carrier Landing System) AN/SPN-46
used in F/A-18
Doppler Radar used in C-141(?)
Doppler Radar used in CP-121 (Canada)
Radar Altimeter
Doppler Navigation System used in CP-140 (Canada)
Radar Altimeter
Radar Altimeter used in CC-130E/H (Canada)
Doppler Radar Navigation Set used in CH-124A (Canada)
Radar Interpretation Trainer
Doppler System Trainer used with C-5
Radar Trainer used with C-5

AN/APQ - Airborne Multipurpose/Special Radars
Model Number

Description© 2015 Open Geospatial Consortium

434

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APQ-1
AN/APQ-2
AN/APQ-3
AN/APQ-4
AN/APQ-5
AN/APQ-7
AN/APQ-8
AN/APQ-9
AN/APQ-10
AN/APQ-11
AN/APQ-12
AN/APQ-13
AN/APQ-14
AN/APQ-15
AN/APQ-16
AN/APQ-17
AN/APQ-19
AN/APQ-20
AN/APQ-21
AN/APQ-22
AN/APQ-23
AN/APQ-24
AN/APQ-27
AN/APQ-29
AN/APQ-31
AN/APQ-32
AN/APQ-33
AN/APQ-34
AN/APQ-35
AN/APQ-36
AN/APQ-39
AN/APQ-41
AN/APQ-43
AN/APQ-46
AN/APQ-50

Description
Radar Jammer RT-26
450-750 MHz High Power Barrage Jamming Transmitter "Rug"; manufactured byGeneral Motors (Delco Div.) used in PB4Y-2
S-Band Radar Receiver; later redesignated AN/APR-5
Panoramic Radar Receiver; later redesignated AN/APR-6
Low Level Radar Bombsight; manufactured by Western Electric used with AN/APS2/3/15 used in B-24, B-25, B-32, PBJ, PBM
X-BAND Search & Bombing Radar "Eagle Mk.1"; manufactured by WesternElectric used in B-17, B-24, B-25J, B-29, B-32
Deception Radar "Spoofer"475-585 MHz High Power Barrage Jamming Transmitter "Carpet III"; manufactured
by General Motors (Delco Div.)X-Band High Altitude Bombing Radar "Eagle Mk.2"; manufactured by WesternElectric used in B-29
Torpedo Launching Radar (formerly SCR-626)
Torpedo & Bombing Radar (formerly SCR-631)
X-Band Bombing Radar "Mickey" (British equivalent is H2X); manufactured byWestern Electric used in B-29, B-32
Radar "Moth-1"
88-162 MHz Radar Spoofing Transmitter "Moonshine"; manufactured by RRL
Radar Bombing Aid
Radar Jammer
S-Band Search & Bombing Radar
S-Band Radar Jammer; manufactured by RRL, Delmont Radio; uses AN/APA-41,
AN/APR-10, AN/APT-10
Countermeasures Set; similar to AN/SPT-7
Radar System
X-Band High Altitude Bombing Radar used in B-29
K-1 Radar Navigation & Bombing System used in B-36B, B-45A, B-50, B-66B
Radar Jamming System; uses AN/APT-16 (2x), AN/APR-9
Radar Relay Set
Bombing & Navigation Radar
RT-119 Radar Jammer
Countermeasures Set used in AC-119K
K-Band Bombing Radar; manufactured by Western Electric
X-Band Search, Fire Control & Tail-Warning Radar (components are AN/APS-21,
AN/APS-28, AN/APG-26); manufactured by Westinghouse used in F3D, F2H, F3H
Search & Acquisition Radar; manufactured by Westinghouse used in F3D-2M, F7U3M
Weather Radar(?) used in B-52D
X-Band Search & Intercept Radar (improved AN/APQ-35); manufactured byWestinghouse used in F3D-2, F2H-3
Multipurpose Radar; designated AI22 in UK used in Javelin FAW.2/6 (UK)
Radar Set; proposed for F3D-3
X-Band Fighter Interceptor Radar; manufactured by Westinghouse used in F-4, F3H,
F4D; planned for F12F

© 2015 Open Geospatial Consortium

435

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APQ-51
AN/APQ-54
AN/APQ-55
AN/APQ-56
AN/APQ-57
AN/APQ-58
AN/APQ-59
AN/APQ-60
AN/APQ-62
AN/APQ-63
AN/APQ-64
AN/APQ-65
AN/APQ-67
AN/APQ-68
AN/APQ-69
AN/APQ-70
AN/APQ-72
AN/APQ-73
AN/APQ-74
AN/APQ-81
AN/APQ-83
AN/APQ-84
AN/APQ-86
AN/APQ-88
AN/APQ-89
AN/APQ-92
AN/APQ-93
AN/APQ-94
AN/APQ-95
AN/APQ-96
AN/APQ-97
AN/APQ-99
AN/APQ-100
AN/APQ-101
AN/APQ-102
AN/APQ-103
AN/APQ-104
AN/APQ-105

Description
X-Band Missile Radar; manufactured by Sperry used in F3H, F7U
Chronograph Set (projectile velocity measuring equipment)
K-Band Side-Looking Radar used in RF-4C
Side-Looking, Real-Aperture Radar; manufactured by Westinghouse used in RB57D, RB-47
Millimeter-Wavelength Navigation Radar
Millimeter-Wavelength Navigation Radar
Side-Looking Airborne Radar; manufactured by Westinghouse
Missile Illumination Radar; manufactured by Raytheon
Side-Looking Radar
Radar
Radar used in F5D with AAM-N-3/AIM-7B Sparrow II missile
Interception Radar used in Aquilon 203 (French-built D.H. Vampire)
Interception Radar; manufactured by Raytheon
HIRAN used in RC-130A
Experimental SLAR Pod for B-58; manufactured by Hughes
Millimeter-Wavelength Navigation Radar
X-Band Intercept Radar; manufactured by Westinghouse used in F-4 (replaced
AN/APQ-50); tested in F3D
Side-Looking Radar; planned for RS-70
X-Band Missile Control Radar used with AN/APA-138, AN/APX-20, AN/APN-22
Doppler Navigation Radar; manufactured by Northrop used in SM-62; planned for
F6D and tested in A-3
Fire-Control Radar; manufactured by Magnavox used in F-8D
Radar used in F-8
K-Band Side-Looking Surveillance & Mapping Radar; manufactured by Texas
Instruments used in RL-23D, RU-8D
Tracking Radar; manufactured by Naval Avionics used in A-6 (replaced by
AN/APQ-112)
Terrain Following Radar; tested in T-2
Ku-Band Search Radar; manufactured by Norden used in A-6, EA-6B, AP-2H
Synthetic-Aperture Ground-Mapping Radar
Radar Set; manufactured by Magnavox used in F-8D/E, T-39D
Collision Avoidance Radar used in helicopters
Radar Set used in OV-10A
K-Band Side-Looking Imaging Radar; manufactured by Westinghouse; tested in OV1A, YEA-3, DC-6
J-Band Forward-Looking Multipurpose Radar; manufactured by Texas Instruments
used in A-7A, RF-4B/C, RF-101
Search & Mapping Radar; manufactured by Westinghouse used in F-4C, RF-101
Terrain Following Radar; manufactured by Texas Instruments
Side-Looking Mapping Radar; manufactured by Goodyear used in RB-57, RF-4B/C
Search Radar; manufactured by Norden used in EA-6A, A-6B
Radar Set; manufactured by Magnavox (similar to AN/APQ-94 used in F-8E(FN)
Distance Integrating Set used in RC-135© 2015 Open Geospatial Consortium

436

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APQ-107
AN/APQ-108
AN/APQ-109
AN/APQ-110
AN/APQ-111
AN/APQ-112
AN/APQ-113
AN/APQ-114
AN/APQ-115
AN/APQ-116
AN/APQ-117
AN/APQ-118
AN/APQ-119
AN/APQ-120
AN/APQ-122
AN/APQ-123
AN/APQ-124
AN/APQ-125
AN/APQ-126
AN/APQ-127
AN/APQ-128
AN/APQ-129
AN/APQ-130
AN/APQ-131
AN/APQ-133
AN/APQ-134
AN/APQ-135
AN/APQ-136
AN/APQ-137
AN/APQ-138
AN/APQ-139

Description
Radar Altimeter Warning System used with AN/APN-117 used in CH-47A, P-3A/C,
EP-3E, S-2, SH-3H
Mapping Radar (SAR?); developed by Conductron used in SR-71
Fire Control & Search Radar; manufactured by Westinghouse used in F-4C/D/E
Ku-Band Terrain Following Radar; manufactured by Texas Instruments used in RF4C, F/FB-111
X-Band Altimeter-Recorder used with AN/ASQ-92 in KC-135
Tracking Radar; manufactured by Norden used in A-6
Ku-Band Search & Attack Radar; manufactured by General Electric used in F-111,
F-5E
Ku-Band Attack Radar; manufactured by General Electric used in F/FB-111A, F-4,
F-5E
Terrain Following Radar; manufactured by Texas Instruments used in "Combat
Talon" C-130E, A-7A, F-111, RF-4C
Terrain Following Radar; manufactured by Texas Instruments used in A-7A/B/C, C130
Terrain-Following & Attack Radar (development of AN/APQ-109) used in F-4D/E
Terrain Following Radar; manufactured by Norden used in MH-53H, AH-56A
Ground Mapping & Interception Radar (modified AN/APQ-113); manufactured byGeneral Electric used in F-111A/D
X-Band Fire Control Radar; manufactured by Westinghouse used in F-4D/E/F/G
X-Band Multimode (Terrain Mapping/Target Locating/Navigation/Weather) Radar;
manufactured by Raytheon (Texas Instruments) used in MC-130E/H, KC-135A, RC135A/C, T-43A, C-130, E-4B
used in F-111
Navigation & Fire-Control Radar; manufactured by Magnavox used in F-8J
Doppler Ranging Radar; manufactured by Magnavox used in F-8J
J-Band Terrain Following Radar; manufactured by Raytheon (Texas Instruments)
used in A-7D/E, T-39D, AC-130E, CH-53
Forward Looking Radar; manufactured by Sperry-Rand used with AN/ASQ-116;
tested in A-6
J-Band Terrain Following Radar; manufactured by Sperry used in A-7D/E, F111C/D
Search Radar used in EA-6B
Attack Radar; manufactured by Rockwell Autonetics used in F-111D
Target Acquisition Radar; manufactured by Texas Instruments used in OP-2E
X-Band Side Looking Tracking Radar; manufactured by Motorola used in AC-119K,
C-130, AC-130
Ku-Band Terrain Following Radar; manufactured by Texas Instruments used in
F/FB-111A
Sink-Rate Radar System used in A-4, F-4, F-8, C-130, CH-47
Search Radar; manufactured by Texas Instruments used in AC-119K, AC-130A
Moving Target Indicator Radar; manufactured by Emerson used in AH-1G
Radar Set
Ku-Band Multi-Mode Radar; manufactured by Texas Instruments used in B-57G© 2015 Open Geospatial Consortium

437

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APQ-140
AN/APQ-141
AN/APQ-142
AN/APQ-144
AN/APQ-145
AN/APQ-146
AN/APQ-148
AN/APQ-149
AN/APQ-150
AN/APQ-152
AN/APQ-153
AN/APQ-154
AN/APQ-155
AN/APQ-156
AN/APQ-157
AN/APQ-158
AN/APQ-159
AN/APQ-160
AN/APQ-161
AN/APQ-162
AN/APQ-163
AN/APQ-164
AN/APQ-165
AN/APQ-166
AN/APQ-167
AN/APQ-168
AN/APQ-169
AN/APQ-170
AN/APQ-171
AN/APQ-172
AN/APQ-173

Description
J-Band Multi-Mode Scan Radar; manufactured by Raytheon (E-Systems); planned
for B-1A; tested in KC-135
Terrain Following Radar; manufactured by Norden used in AH-56, HH-53 Pave Low
Surveillance Radar "Quick Look I" used in RV-1C
Ku-Band Attack Radar (improved AN/APQ-113); manufactured by General Electricused in F-111F, FB-111A
Mapping & Ranging Radar; manufactured by Stewart-Warner used in A4E/F/N/S/SU
Ku-Band Terrain Following Radar; manufactured by Texas Instruments used in F111F
J-Band Navigation & Attack Radar; manufactured by Norden used in A-6E, TC-4C
Navigation & Fire Control Radar used in F-8
Beacon Tracking Radar used in AC-130E/H
Topographical Mapping Radar; manufactured by Goodyear used in RC-130
I-Band Fire Control Radar; manufactured by System & Electronics Inc. (Emerson
Electric) used in F-5E/F
Terrain-Following Radar; manufactured by Texas Instruments used in HH-53C
Strategic Radar; manufactured by Northrop Grumman (Norden) used with AN/ASQ176 used in B-52H
J-Band Navigation & Attack Radar (improved AN/APQ-148); manufactured by
Northrop Grumman (Norden) used in A-6E, TC-4C
I-Band Fire Control Radar (modified AN/APQ-153); manufactured by System &Electronics Inc. (Emerson Electric) used in F-5E/F
Terrain Following Radar (improved AN/APQ-126); manufactured by Raytheon usedin MH-53J
I/J-Band Multipurpose Radar (improved AN/APQ-153); manufactured by System &Electronics Inc. (Emerson Electric) used in F-5E/F
Attack Radar used in EF-111A
Attack Radar; manufactured by General Electric used in F-111F
Forward Looking Radar (development of AN/APQ-99?) used in RF-4C
Forward Looking Radar; manufactured by General Electric used in B-1
Pulse Doppler I-Band Multimode Radar; manufactured by Northrop Grumman(Westinghouse) used in B-1B
Attack Radar; manufactured by Texas Instruments used in F-111C
Strategic Radar used in B-52G/H
Radar Set (development of AN/APQ-159); developed by ESCO used in T-47
Multi-Mode Radar; manufactured by Raytheon (Texas Instruments) used in HH-60D,
MH-60K; proposed for V-22
J-Band Attack Radar (upgraded AN/APQ-165); manufactured by Lockheed Martin(General Electric) used in F-111C
Terrain Following Radar; manufactured by System & Electronics used in MC-130H
Attack & Terrain Following Radar (improved AN/APQ-128/146); manufactured byRaytheon (Texas Instruments) used in F-111C/F
J-Band Terrain Following Radar (upgraded AN/APQ-99); manufactured byRaytheon (Texas Instruments) used in RF-4C
Radar Set; manufactured by Norden; proposed for A-6F

© 2015 Open Geospatial Consortium

438

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APQ-174
AN/APQ-175
AN/APQ-178
AN/APQ-179
AN/APQ-180
AN/APQ-181
AN/APQ-183
AN/APQ-186
AN/APQ-501
AN/APQ-T1
AN/APQ-T10
AN/APQ-T11
AN/APQ-T12

Description
Multi-Mode Radar; manufactured by Raytheon used in MV-22, MH-60K, MH-47E;
MH-53
X/Ku-Band Multi-Mode Radar; manufactured by Systems & Electronics Inc. used in
C-130E
used in E-2C (developmental item only?)
Control Indicator Set (Display System) used in E-2C
Pulse Doppler Attack Radar (modification of AN/APG-70); manufactured byRaytheon (Hughes) used in AC-130U
Synthetic Aperture J-Band Multi-Mode Radar; manufactured by Raytheon (Hughes)
used in B-2A
Multi-Mode Radar; manufactured by Northrop Grumman (Westinghouse); wasplanned for cancelled A-12A, a derivative was used in RQ-3A
Multi-Mode Radar (improved AN/APQ-174); manufactured by Raytheon used in
CV-22
Radar Altitude Warning System used in CP-140?; replaced AN/APQ-107
Trainer for Aircraft Gun Laying Radar
Bombing/Navigation Simulator used with B-52D
Bombing/Navigation Radar Trainer used with B-47, B-52, B-58
Bombing/Navigation Radar Trainer used with B-47, B-52, KC-97, KC-135

AN/APS - Airborne Search & Detection Radars
Model Number
AN/APS-1
AN/APS-2
AN/APS-3
AN/APS-4
AN/APS-5
AN/APS-6
AN/APS-7
AN/APS-8
AN/APS-9
AN/APS-10
AN/APS-11
AN/APS-12
AN/APS-13
AN/APS-14

Description
X-Band Radar (conflicting references to purpose: either Mapping/Bombing or TailWarning)
S-Band Search Radar & Beacon used with AN/APQ-5 used in PBJ-1 (if w/o
AN/APS-3), PBM-5S, PB4Y-2
X-Band Search & Bombing Radar used in PBJ-1, OA-10, PBY-6A, TBM-1D/3E, P82F
X-Band Intercept Radar; manufactured by Western Electric used in C-47, C-117, P38J, P-82D/F/H, AD, XBT2C-1, F4U-4E, F6F-3E/5E, SB2C-5, SBF-4E, TBF-3,
TBM-3S; tested in JRB; British designation is AI Mk XVIntercept Radar (development of AN/APS-4); manufactured by Western Electric usedin F4U-4N
Intercept Radar (development of US Navy AIA radar); manufactured by Sperry usedin P-38M, F2H-2N, F-82D, F6F-3N/5N, F7F-4N, F8F-1N/2N, F4U-4N/5N; tested in
SNB-1
Search Radar (or Tail-Warning Radar?); manufactured by Westinghouse
Conflicting data! I have references for: ASW Search Radar used in P-2E wingtip
pod; and Tracking Radar for KDB-1(MQM-39 used in AJ-2P
Search Radar used in FR-1N
X-Band Search Radar
Tail Warning Radar
Fire Control Radar
Tail Warning Radar used in P-38L, P-47D, P-51, P-61, P-63, P-82D, PBJ
Gun Laying Radar used in B-17, B-24

© 2015 Open Geospatial Consortium

439

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APS-15
AN/APS-16
AN/APS-17
AN/APS-18
AN/APS-19
AN/APS-20

AN/APS-21
AN/APS-23
AN/APS-24
AN/APS-25
AN/APS-27
AN/APS-28
AN/APS-29
AN/APS-30
AN/APS-31
AN/APS-32
AN/APS-33
AN/APS-34
AN/APS-35
AN/APS-37
AN/APS-38
AN/APS-42
AN/APS-44
AN/APS-45
AN/APS-46
AN/APS-48
AN/APS-49
AN/APS-50
AN/APS-54
AN/APS-57
AN/APS-59
AN/APS-60
AN/APS-61
AN/APS-62

Description
X-Band Bombing & Navigation Radar "Mickey" (equivalent to British "H2S");
manufactured by Philco used in B-29, PBM-3C/5/5E, B-17, B-24, PB4Y-2, PV-2,
PBM-5S
L-Band Bomber Tail Warning Radar
S-Band Bomber Tail Warning Radar
Early Warning Radar (another source has this as Drone Radar used with AN/ARR-9)
X-Band Search & Intercept Radar; manufactured by Sperry used in AD-4N/5/6,
F2H-2N, F4U-5N, F7F-4N, F8F-1N
S-Band Search & Early-Warning Radar; manufactured by Hazeltine/General Electricused with AN/ARW-35 and AN/ART-28 used in TBM-3W, WV-2, PB-1W, ZPG2W(EZ-1), AF-2W, HR2S-1W, P-2, WB-29, RC-121C, Gannet (UK), Shackleton(UK)
Search Radar; manufactured by Westinghouse; part of AN/APQ-35 used in F3D,
Meteor NF (UK)
Search Radar; manufactured by Western Electric; part of AN/ASB-3 used in B-36,
B-45C, B-47E, XB-48, B-50, B-52, C-130, C-135
Radar Set used with System 416L
Search Radar used in XF10F-1
Search Radar used in B-52, RB-66, C-130, C-135
Search Radar used in F3D
Search Radar
Search Radar used in AF-2S
Search Radar; manufactured by Westinghouse used in P5M, PBM-3, A-1, P-2, U-16,
AF-2S
Search Radar used in TBM-3
X-Band Search Radar used in S-2F, P4M, P2V-6, ZPG-1W, ZPK
Search Radar (similar to AN/APS-33)
Search & IFF Radar; manufactured by Philco?
Search Radar
Search Radar used in S-2
Weather Radar; manufactured by Bendix used in C-54, C-97, C-118, C-119, C-121,
C-124, C-130, C-131
Search Radar used in PB4Y-2, P-5
Height-Finding Radar; manufactured by Texas Instruments used in WV-2(EC-121)
Interception Radar used in F2H-2N
Unattended Radar
Rapid Scan Search Radar; manufactured by Hazeltine used for ASW
Search Radar; planned for F11F-1, but not used
Tail-Warning Radar System; manufactured by ITT used in B-47B/E, B-52, B-57,
EB-66B, F-101A/C, F-105D, "EF-101B" (Canada)
X-Band Search & Intercept Radar; manufactured by Western Electric used in Venom
NF.3 (UK; designated AI Mk 21)
Search Radar used in CP-109 (Canada)
High-Altitude Mapping Radar used in NRB-57A
Monopulse Radar
Height-Finding Radar used in ZPG-2W/3W© 2015 Open Geospatial Consortium

440

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APS-63
AN/APS-64
AN/APS-67
AN/APS-69
AN/APS-70
AN/APS-73
AN/APS-75
AN/APS-76
AN/APS-80
AN/APS-81
AN/APS-82
AN/APS-84
AN/APS-85
AN/APS-87
AN/APS-88
AN/APS-91
AN/APS-92
AN/APS-94
AN/APS-95
AN/APS-96
AN/APS-103
AN/APS-104
AN/APS-105
AN/APS-107
AN/APS-108
AN/APS-109
AN/APS-111
AN/APS-112
AN/APS-113
AN/APS-115
AN/APS-116
AN/APS-117

Description
Radar Set used in B-66, T-29, F-4C (tests?)
Search Radar used in WB-47E, B-52, RB-66B/C
Search Radar Set; manufactured by Magnavox used in F-8B, S-2
Height-Finding Radar used in ZPG-2W, P-2
Early-Warning Radar; manufactured by General Electric used in P2V-6, EC-121,
EZ-1C
X-Band Synthetic Aperture Radar; manufactured by Goodyear used in experimental
pod for B-58; tested in C-97, C-135, RF-4C; ground-component in AN/GSQ-28"SABRE" High-Resolution X-Band Side-Looking Radar; manufactured by General
Electric; under consideration for B-70
Search Radar used in EC-121
Maritime Surveillance Radar; manufactured by Texas Instruments used in E-1B, P3A/B, NP-3D, P5M-2
Search Radar used in B-52
Early Warning/Aircraft Direction Radar; manufactured by Hazeltine used in EC121L, E-1B, E-2; tested in SH-3G
Tracking Radar used with QB-47
Side-Looking Surveillance Radar; manufactured by Motorola used with RL-23D,
RU-8D
Early Warning Radar (development of AN/APS-82)
Search Radar; manufactured by Texas Instruments used in HU-16B, S-2
Early Warning Radar used in E-2
Radar Warning Receiver used in F-105D
Side-Looking Airborne Surveillance & Mapping Radar; manufactured by Motorola
used in OV-1B/D, P-2, P-3, EA-6A, UH-1 ALARM, B-26
Search & Warning Radar; manufactured by Hazeltine used in EC/RC-121
Air Surveillance Radar; manufactured by General Electric used in E-2A/B
Height Finding Radar used in EC/RC-121
Bombing/Navigation Radar System; part of AN/ASQ-48 used in B-52C/D
Radar Homing & Warning System; manufactured by Dalmo-Victor used in B-52
Radar Homing & Warning System; manufactured by Bendix used for targeting
AGM-78 used in A-7D, F-105G, F-111A, F-4D; improved version tested in F-4E
Search Radar; manufactured by Motorola/Raytheon used in B-52D
Radar Homing & Warning System; manufactured by Dalmo-Victor used in F111A/D/E/F, FB-111A
UHF Air Surveillance Radar (modified AN/APS-96); manufactured by Lockheed
Martin (General Electric) used in E-2A
Early Warning Radar AWACS (development of AN/APS-59)
Weather Radar; manufactured by Bendix; manufactured by Bendix used in EC-47,
UH-1
X-Band Sea Surveillance/ASW Radar; manufactured by Raytheon (Texas
Instruments) used in P-3C, SH-2D
X-Band Sea Surveillance/ASW Radar; manufactured by Raytheon (Texas
Instruments) used in EP-3E, S-3A, SH-3, CP-140 (Canada; Canadian version called
AN/APS-506), P-3C (Australia); proposed for cancelled U-2EPX
TIAS (Target Identification & Acquisition System) for AGM-45 used in some A-4© 2015 Open Geospatial Consortium

441

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APS-118
AN/APS-119
AN/APS-120
AN/APS-121
AN/APS-122
AN/APS-123
AN/APS-124
AN/APS-125
AN/APS-126
AN/APS-127
AN/APS-128
AN/APS-130
AN/APS-131
AN/APS-133
AN/APS-134

AN/APS-135
AN/APS-136
AN/APS-137

AN/APS-138
AN/APS-139
AN/APS-140
AN/APS-141
AN/APS-143

Description
TIAS (Target Identification & Acquisition System) for AGM-78; manufactured by
IBM used in A-6B (Mod 1)
Weather Avoidance Search Radar used in HC-130B
Air Surveillance Radar; manufactured by General Electric used in E-2C
Radar Set
Search Radar used in YSH-2E
Search Radar used in S-2D
Sea Surveillance/ASW Radar; manufactured by Raytheon used in SH-60B, YSH-2E;
tested in SH-3
Pulse Doppler UHF Air Surveillance Radar; manufactured by Lockheed Martin(General Electric) used in E-2C, EC-130V; replaced AN/APS-120
Surface Search Radar used in P-3
Raytheon Sea Surveillance Radar; manufactured by Raytheon used in HU-25A/B,
Gulfstream III (Denmark)Sea Surveillance Radar; manufactured by Telephonics used in E-9A, P-95 (Brazil),
D.3B (Spain)
Multimode Search Radar (derivative of AN/APG-156); manufactured by Northrop
Grumman (Norden) used in EA-6B
Sideways Looking Sea Surveillance Radar; manufactured by Motorola used in HU25B, C-130
X-Band Multifunction Radar; manufactured by Allied Signal (Model RDR-1F) used
in EA-6A, C-5, KC-10, C-17, EC-24A, VC-25, C-130, C-141, E-3, E-4, E-6, E-8
Multimode Search Radar; manufactured by Raytheon (Texas Instruments) used in P3B, EP-3E, HC-130H, CP-140A (Canada; Canadian version called AN/APS-507),
Atlantique (Germany/France), P-3K (New Zealand), Fokker 50 Mk 2 (Singapore),
CN-235MPA (Brunei), P-3C (South Korea)
Side-Looking Airborne Surveillance Radar; manufactured by Motorola used in HC130H
I-Band MTI Radar; planned for EH-60C
Pulse Doppler X-Band Sea Surveillance/ASW Radar; manufactured by Raytheonused in:- AN/APS-137(V)1: A-6E, S-3B
- AN/APS-137(V)2: PHM2 Hydrofoil- AN/APS-137(V)3: P-3C
- AN/APS-137(V)4: HC-130H- AN/APS-137(V)5: P-3C
- AN/APS-137(V)6: ES-3A- AN/APS-137(V)?: EP-3E
Pulse Doppler UHF Air Surveillance Radar (upgraded AN/APS-125); manufactured
by Lockheed Martin (General Electric) used in E-2C; planned for P-3AEW
Pulse Doppler UHF Air Surveillance Radar (upgraded AN/APS-138); manufactured
by Lockheed Martin used in E-2C(Grp.I)
I/J-Band Multimode Surveillance Radar (US version of AN/APS-504); manufactured
by Litton Canada
I/J-Band Multimode Surveillance Radar (US version of AN/APS-504(V)3);
manufactured by Litton Canada
X-Band Sea Surveillance Radar "Ocean Eye"; manufactured by Telephonics used in
E-9A, S-2E, HU-25, SH-60, SH-2G (Australia, New Zealand), and in aerostats© 2015 Open Geospatial Consortium

442

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APS-144
AN/APS-145
AN/APS-146
AN/APS-147
AN/APS-148
AN/APS-149
AN/APS-150
AN/APS-503
AN/APS-504
AN/APS-505
AN/APS-506
AN/APS-507
AN/APS-509
AN/APS-T1
AN/APS-T2

Description
Pulse Doppler Ku-Band Land Surveillance Radar; manufactured by AIL used in EO5, RQ-5A(BQM-155A); tested in C-27, UH-60A
Pulse Doppler UHF Air Surveillance Radar (upgraded AN/APS-139); manufactured
by Lockheed Martin used in E-2C(Grp.II), EC-130V
manufactured by Northrop Grumman; intended for EA-6B
Multi-Mode Surveillance Radar; manufactured by Telephonics used in MH-60R"SeaVue" Lightweight Multi-Platform Sea/Land Surveillance Radar; manufactured
by Raytheon
Pod-Mounted Surveillance Radar used on P-3C (to provide targeting coordinates ofmobile targets for the AGM-84H)
Sea Surveillance Radar; modified AN/APS-115 (or AN/APS-137?) for use with C130; probably used on HC-130H
I-Band Multimode Surveillance Radar; manufactured by Litton Canada used in CH124
I/J-Band Multimode Surveillance Radar (improved AN/APS-503); manufactured by
Litton Canada used in EC/RC-26D (AN/APS-504(V)5), CP-121
Beacon-Equipped Multimode Radar
Maritime Surveillance Radar (Canadian version of AN/APS-116); manufactured byRaytheon (Texas Instruments) used in CP-140
Maritime Surveillance Radar (Canadian version of AN/APS-134); manufactured byRaytheon (Texas Instruments) used in CP-140A
Search Radar used in S-2T
Air-to-Surface Vessel Radar Trainer
Air-to-Surface Vessel Radar Trainer

AN/APY - Airborne Surveillance Radars
Model Number
AN/APY-1
AN/APY-2
AN/APY-3
AN/APY-6
AN/APY-7
AN/APY-8
AN/APY-9
AN/APY-10
AN/APY-12
AN/APY-T1

Description
Pulse Doppler S-Band Air & Sea Surveillance Radar (AWACS); manufactured by
Northrop Grumman used in E-3
Pulse Doppler S-Band Air & Sea Surveillance Radar (AWACS); manufactured by
Northrop Grumman used in E-3
Sideways Looking Air-to-Ground Surveillance Radar (JSTARS); manufactured by
Northrop Grumman used in E-8
Multi-Mode High Resolution Surveillance Radar; manufactured by Northrop
Grumman; tested in NP-3C
Sideways Looking Air-to-Ground Surveillance Radar (improved AN/APY-3) used in
E-8"Lynx" SAR/GMTI (Synthetic Aperture Radar/Ground Moving Target Indicator);
manufactured by General Atomics; tested in C-12, U-21 and others; planned for use
in MQ-9A
UHF Air Surveillance Radar; manufactured by Lockheed Martin used in E-2D
Maritime Surveillance Radar; manufactured by Raytheon used in P-8A
"Phoenix" SAR (Synthetic Aperture Radar)
RMTS (Radar Maintenance Training Set); part of E-3 AWACS MTS (MaintenanceTraining System)© 2015 Open Geospatial Consortium

443

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Model Number
AN/APY-T2

Description
ARMTS (Advanced Radar Maintenance Training Set); part of E-3 AWACS MTS(Maintenance Training System)

7.3.3
Model’s Articulations Effect on RCS Data
Most man-made models (aircraft, tanks, trucks, etc.) have parts that can be articulated (flaps,
turrets, rotating antennae, landing gears, etc). It is impractical to pre-compute and store within
the CDB an RCS model for every possible position of those articulated parts taken individually.
Instead, a CDB RCS model attribute provides the means to store an overall RCS variation effect,
or otherwise called “scintillation effect”. The scintillation effect value is added to the RCS atrun-time during movement of any of such articulated parts of the model. It is a parameter in the
Shapefile called “RCS_SCINT” and this attribute can be used by the radar client-devices atruntime to provide a correlated (but approximated) variation level of the model RCS while anyof its parts are articulated.
For example, for a tank in the process of rotating its turret, the radar simulation client would takeits overall RCS (based on aspect angles) and add the scintillation factor on the end-result RCS
value to slightly alter the RCS to introduce the turning turret effect while the part is moving.
While this adds an approximation factor on the RCS, it provides a coherent and correlated
variation level to all clients using the RCS data set layer. The “RCS_SCINT” is therefore thevalue that represents a scaling factor of RCS noise that would be superimposed while the part isbeing articulated.

© 2015 Open Geospatial Consortium

444

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 8
8Glossary
Description

A
Aliasing

Spatial and/or temporal image defects or artifacts in a raster image.
They are due to interaction between the discrete sampling of the raster
format and the spatial and temporal frequencies inherent in thecomputed image of edges, surfaces and point features. Manifestationof spatial aliasing includes edge stair-stepping and crawling,
scintillation of narrow surfaces, break-up of long, narrow surfaces andpositional or angular motion of scene edges in discrete steps.
Temporal aliasing includes double image and loss of dynamic image
integrity due to the human eye’s ability to dynamically track individual
fields at certain angular rates of motion.

Ambient Illumination

See Illumination, Ambient.

Anti-aliasing

Active image processing techniques that reduce the perception of thealiasing phenomena.

Area, BackgroundAn area of unlimited size (up to whole earth) modeled in accordance tothe following criteria:(a) Elevation grid post spacing, 30 m.
(b) Terrain imagery resolution, 1 m.
(c) Contains all objects of height greater than, 33 m (100 ft).

Area, Corridor

A 10 nm wide corridor joining two target areas modeled in accordance
to the following criteria:(a) Elevation grid post spacing, 30 m.
(b) Terrain imagery resolution, 1 m.
(c) Contains all objects of height greater than, 33 m (100 ft).

Area, HLZ

A 0.1 nm x 0.1 nm area inside the target (see “Target” glossary entry)
modeled in accordance to the following criteria:(a) Elevation grid post spacing, 1 m.
(b) Terrain imagery resolution, 0.1 m.
(c) Contains all objects of height greater than, 0.15 m (0.5 ft).

Areal Feature

See Feature, Areal© 2015 Open Geospatial Consortium

445

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Area, Target
Perimeter

A 30 nm x 30 nm area surrounding the target area modeled inaccordance to the following criteria:(a) Elevation grid post spacing, 10 m.
(b) Terrain imagery resolution, 0.5 m.
(c) Contains all objects of height greater than, 15 m (50 ft).

Area, Target

A 6 nm x 6 nm area surrounding the target (see “Target” glossary
entry) modeled in accordance to the following criteria:(a) Elevation grid post spacing, 10 m.
(b) Terrain imagery resolution, 0.5 m.
(c) Contains all objects of height greater than, 3.3 m (10 ft).

Articulated PartA child part of a model (usually a moving model) that is allowed somedegree of motion with respect to the parent body of the model.
Examples of articulated parts include tank turrets, refueling drogues,
and helicopter rotor blades.

B
Background Area

See Area, Background.

Base Material

See Material, Base.

Base Material Table(BMT)

A data structure that contains a description of the Base Materials
available to the CDB. There is only one BMT per CDB. Each entry in
the BMT corresponds to a Base Material; the entry associates a nameto the Base Material.

C
CDB-compliant device

A device that can directly input synthetic environment data that
conforms to the format, structure and conventions of this Specification.
A device need not input and process all of the CDB datasets andattributes to be CDB-compliant.

CDB-compliant
simulator

A simulator whose client-devices can input synthetic environment datathat conforms to the format, structure and conventions of thisSpecification. Any subsystem or client-device that does not natively
conform to this Specification requires that CDB data be formatted andstructured to the device’s native format and structure through the useof a runtime publisher. A simulator need not input and process all of
the CDB datasets and attributes to be CDB-compliant.

© 2015 Open Geospatial Consortium

446

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
CDB Translator

An off-line software process that translates an environmental databasefrom its toolset-native format(s) to the CDB format.
NOTE: The CDB data formats are based on industry standard tool
formats; as a result a translation to the formats prescribed by thisSpecification may not be required.

CDB Server

Gateway platform to CDB mass storage and applicable infrastructure.
The CDB servers access, filter and distribute CDB data in response torequests from the Database Generation Facility (DBGF) and the clientdevices (or their runtime publishers).

CDB Geocell

Earth area, aligned to lines of latitude and longitude in accordance with
Table 2-2: Size of CDB Geocell per Zone.

ChannelA field of view segment within a visual system’s total viewing field forwhich a corresponding unique scene segment is calculated andpresented.

Client application

A software application that requires a complete or partial synthetic
representation of the world. CDB applications may require a CDB
runtime publisher to convert the CDB DB into a form it can directly
input. Used interchangeably with “Client-device” in this specification.

Client-device

Simulation sub-systems (Image Generators (IGs), Radar, Weather
Server, Computer Generated Forces (CGF) Terrain Server, etc.) that
require a complete or partial synthetic representation of the world. A
CDB client-device may require a CDB runtime publisher to convert
the CDB data into a form it can ingest.

Coordinate System

A system of notation, usually Three-Dimensional (3D), by which theposition of any point can be defined. Can be spherical, geodetic,
ellipsoid or Cartesian. Must have a point of origin (where all axes
have a magnitude of zero), an orientation, and a convention fortranslation along the axes.

Composite Material

See Material, Composite.

Composite Material
Table

A data structure that contains a description of the Composite Materials
available in a CDB tile or on a model. There is only one CMT per
CDB tile or model. Each entry in the CMT corresponds to a
Composite Material.

© 2015 Open Geospatial Consortium

447

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Coordinate System,
Geocentric

Coordinates used to define points in a Geocentric Spatial Frame (seeSpatial Frame, Geocentric).

Coordinate System,
Geographic

The Geographical coordinate system is the most commonly used
coordinate system to represent earth surfaces. The coordinates are
longitude, latitude and altitude above mean sea level. The reference
data is based on the WGS-84 ellipsoid, i.e., geographical latitude j andlongitude l are the angles of the normal on the WGS-84 reference
ellipsoid along the point to the equator and zero meridian. The angles
are given as degrees, minutes and seconds. Altitude above mean sea
level is the distance above and normal to the ellipsoid in meters. The
WGS-84 ellipsoidal earth models provides for accurate calculations
over long distances on the earth’s surface. The WGS-84 earth model
represents a good approximation of the shape of the earth over thesmoothed mean sea level (geoid gravitational equipotential) to within
about one hundred meters.

Correlation,
Algorithmic

The degree of informational consistency between the outputs of two or
more devices with equivalent Arithmetic Logic Units, each submitted
to the same input data. (e.g., consider two devices meshing terrain
from a regular grid of elevation points, one using a regular mesh ofright-handed triangles using the elevation points as vertices, and theother with a DeLauney triangulated mesh derived from the grid of
elevation points).

Correlation,
Numerical

The degree of informational consistency between the outputs of two or
more devices, each submitted to the same input data, (e.g., twodevices computing the sine of an angle, one with a series of 10 terms,
and another with an interpolation of a look-up table with 100 entries,
or one device using 32-bit signed integers for its internal computations
and the other using single-precision floats). The CDB Specification
addresses Runtime Source Database numerical accuracy correlation
errors because a single representation is used for each data set.

Correlation,
Parametric

The degree of informational consistency between the outputs of two or
more devices, each submitted to the same input data but to different
control parameters (e.g., consider two devices generating regularmeshes of right-handed triangles based on a regular grids of elevation
points organized by Level-of-Detail (LOD), one using an LOD
meshing tolerance parameter of 1m and the other 2m).

© 2015 Open Geospatial Consortium

448

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Correlation, Raw
Source DB

The degree of informational consistency between two or more sets ofraw data126 (i.e., inputs to a modeling station) representing aspects ofthe same environment (for instance, the correlation errors arising from
Digital Terrain Elevation Data (DTED) elevation data that does not
perfectly match the satellite raster imagery due to oblique view
distortions induced by the satellite). Correlation errors are intrinsic to
the process of gathering data because there is no means to gather all of
the required data from a single device, at a single instant in time.
Instead, datasets (e.g., elevation, raster imagery, geometry) are eachgathered from various devices of various types, at different times, etc.
As a result, this process inherently introduces (raw source) correlation
errors.

Correlation, Runtime
DB

The degree of informational consistency between two or more runtime
databases representing the same synthetic environment. The CDB
Specification eliminates database correlation errors since only one
database is used to represent the same synthetic environment. A
runtime database is a device-loadable database format that can beprocessed by a target device. The CDB Specification defines a format
that can be entered in runtime by client-devices that conform to theSpecification. By definition, the CDB Specification addresses all
runtime database-level correlation error.

Correlation, Source
DB

The degree of informational consistency between the internal datasetsof a source database produced by a DB generation toolset. To a large
extent, the effort expended by a modeler at their DB workstationconsists in eliminating (or at least reducing) correlation errors arisingfrom miss-correlated raw source data.

Corridor Area

See Area, Corridor.

CultureSee Feature, Cultural.

Culture, 2D

Short for 2D Cultural Feature. The 2D representation of a man-madeor natural object (such as a road, a runway, a forest canopy),
conformed to the terrain.

126

In this context, raw source denotes any input to the modeling workstation that is used to assemble the synthetic
environment; consequently, the data may have undergone some level of post-processing (such as image colorbalancing, image ortho-rectification, etc.) or may be in a specific source interchange format (such as SIF, SEDRIS,
etc.)© 2015 Open Geospatial Consortium

449

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Culture, 3D

Short for 3D Cultural Feature. The 3D representation of erect manmade or natural object (such as buildings, trees, towers) positioned on
top of and usually conformed to the terrain.

D
Data Dictionary

In database management systems, a file that defines the basicorganization of a database. Data dictionaries explicitly define data
content and how to access this content within a binary file (forexample, a data dictionary may contain a list of all files in the
database, the number of records in each file, and the names and typesof each field). Most database management systems keep the data
dictionary hidden from users to prevent them from accidentally
destroying its contents. Data dictionaries do not contain any actual
data from the database, only book keeping information for managing
it. Since there are no widely accepted standards for data dictionaries,
most of the CDB data content and structure are explicitly defined bythis CDB Specification rather than by the metadata held within a Data
Dictionary file.

Data Duplication

Data logically representing the same information, copied one or moretimes within a complex data structure. The CDB Specification
eliminates all duplication of data, i.e., the data appears once and only
once within the CDB structure.

Data Normalization

Data that has been manipulated to eliminate informational redundancy
and/or data duplication and anomalies. The normalization processensures internal consistency, minimizes informational redundancy, andmaximizes stability (associates attributes with entities based on theinherent properties of the data rather than on the application
requirements).

Data Redundancy

Information in the form of data that can readily be derived (within thelimits of technological/cost reasonability) and re-formatted, or rederived from other data.

DatasetOrganized group of related environmental data that cannot be broken
down into a smaller set used to describe a synthetic environment
element of the world.

© 2015 Open Geospatial Consortium

450

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Database Fidelity

Reflects the amount and type of synthetic environmental data neededby client-devices to simulate real-world environmental data withgreater fidelity. Consider for instance a simulator client-device
capable of supporting a single-surface earth skin representation versus
one capable of representing a multi-surface earth skin that represent
tunnels, bathymetric data, location-dependent tide heights, etc.

Database Assembly

In many database tools, the generation of the terrain plays a pivotal
role in the database assembly process because all of the culturalfeatures are conformed and constrained to the terrain representationand structure. Most client-devices in existence today haveinterdependent terrain geometry, raster imagery and culture; as a resultof this, most tools in use today resolve these inter-dependencies during
this critical and computationally expensive database assembly step.

Database Generation
Facility (DBGF)

A geo-graphically co-located group of workstation(s), computer
platforms, input devices (digitizing tablets, etc.), output devices (stereo
viewers, etc.), modeling software, visualization software, CDB Server,
CDB off-line publishing software and any other associated softwareand hardware used for the development/modification of the CDB. The
DBGF is used for the purpose of CDB creation and CDB updates.
Each workstation is equipped with one or more specialized tools. The
tool suite provides the means to generate and manipulate the synthetic
environment.

© 2015 Open Geospatial Consortium

451

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Database Generation
Timeline

Elapsed time from availability of Environmental DB requirements(geographic extent, fidelity, resolution, etc.) to availability of acompliant runtime Environmental DB, ready for use on all clientdevices of a simulator.

Database Publishing

A process (either off-line127 or on-line) where all of differences
between the tool-native representation and the client-device internal
representation of the synthetic environment database are resolved.
During this step, the publisher transforms the assembled database sothat it satisfies the client-device’s:§ internal formats§ internal data structure and organization§ internal naming conventions§ internal precision and number representation§ data fidelity requirements (typically parameters that match theclient-device algorithms)§ performance limitations§ level-of-detail representation and conventions

Database Publishing,
Offline

The process of performing the steps listed above in Database
Publishing, and then storing the result in a distinct SE database foreach client-device. (Note that the stored databases are different foreach client-device type and each vendor type). In many cases, thepublished databases are proprietary.

Database Publishing,
OnlineThe process of performing the steps listed above in Database
Publishing, on-the-fly, based on paging requests of a client-device.
Since the publishing is performed on-demand, it exists only
momentarily in memory; it is not stored on disk.

Database Resolution

Informational density (for instance, the number of elevation values per
km2, pixels per km2, polygons per km2) of a modeled dataset.

Data Precision

Corresponds to the numerical precision (i.e., number of bits allocated)
used to represent a unit.

Directional
Illumination

See Illumination, Directional.

E
127

When applied as an off-line process, the term “compilation” is often used instead.

© 2015 Open Geospatial Consortium

452

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Environmental Data
Coding Specification

An Environmental Data Coding Specification provides a mechanism to
specify the environmental "things" that a particular data model isintended to represent. That is, a feature such as building could be
represented alternatively as a Man-made Point Feature, a Shapefile
Radar RCS polar diagram or as an OpenFlight model, or somecombination of these. The representation of these is chosen by the data
modeler and is orthogonal to the semantic of the "thing" that isrepresented (and its location). The provision of such a "thing" results
in a shared understanding of "what the thing is and what it potentiallymeans" to all participating applications.

Environmental Data
Representation Model

A data representation model (EDRM) is a description used to provide
identification of all environmental data elements within a system,
including their attributes and the logical relationships between data
elements.

Environmental DB,
RuntimeA device-loadable database format that can be processed by a target
device. The CDB Specification defines a format that can be entered inruntime by simulator client-devices that conform to the Specification.

Eyepoint

A single point (monocular) location of the observer’s eye relative to ascene representation. Usually a point within the cockpit of thesimulated aircraft or vehicle.

Eyepoint, Pilot

The normal eyepoint position when the pilot’s seat is adjusted properly
for flying the aircraft. Defined by the aircraft manufacturer for eachpilot seating position. The eyepoint(s) for which the display design isnormally optimized and typically used for display testing purposes.

F
Feature Set

Describes a set of logically related datasets. Example: a Terrain
Feature set is comprised of the Elevation, Imagery, MinElevation,
MaxElevation, etc. datasets.

Feature, Areal

A representation of closed area-oriented features conformed relative tothe terrain such as forested areas, fields. The information includes
areal feature type identification, location, orientation, 2D geometry,
connectivity, attribution and other surface characteristics relevant tosimulation.

Feature, Cultural

A generalization of point, lineal and areal features.

© 2015 Open Geospatial Consortium

453

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Feature, Linear

The representation of predominantly man-made multi-segmented lineoriented features conformed relative to the terrain (such as runways,
roads, transmission lines, fences). The information includes linear
feature type identification, location, orientation, lineal geometry,
connectivity, attribution and other surface characteristics relevant tosimulation.

Feature, Point

The representation of a single location in space or on the earth’s
surface. It consists of a single <latitude, longitude> coordinate with orwithout an elevation. When a point feature does not have an elevation,
it is deemed to be on the surface of the earth. It is often associatedwith a 3D model. The information includes point-feature typeidentification, location, orientation, connectivity, attribution and othercharacteristics relevant to simulation.

Flat Earth

Jargon used in simulation community to signify the projection of theearth ellipsoid onto a flat surface. The flat Earth approximation retains
terrain relief but eliminates the effects of Earth surface curvature. If
you stay in the vicinity of a given fixed point, it may be a good enoughapproximation to consider the earth as "flat", and use a North, East,
Down rectangular coordinate system with origin at the fixed point.

FOV, Field of View

The horizontal and vertical subtended angles from a designatedeyepoint to the boundaries of a visual system channel (channel FOV)or all channels (system FOV).

G
Geocell

Short form for geographic cell. A 1o of latitude by 1 o of longitude areaon the surface of the earth. At the equator, this corresponds to an areaof approximately of 111,319m × 111,319m. (See also CDB Geocell).

Geocentric Spatial
Frame

See Spatial Frame, Geocentric.

Geographic Extent

An earth surface area that has been modeled.

Geographic Projection

Geographic projections are a way of showing the curved surface of the
Earth on a flat surface like a piece of paper.

Geospecific Model

A model is said to be geospecific if it is instanced once and only once
within a CDB. Geospecific models usually correspond to unique (ineither shape, size, texture, materials or attribution), man-made, realworld 3D cultural features.

© 2015 Open Geospatial Consortium

454

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Geotypical Model

A model is said to be geotypical if it instanced multiple times within a
CDB. Geotypical models correspond to representative (in shape, size,
texture, materials and attribution) models of real-world man-made or
natural 3D cultural features.

H
HLZ Area

See Area, HLZ.

I
Illumination

One or more sources of illumination for the objects in the scene, suchas daylight, twilight, landing lights.

Illumination, ambient

The non-directional component of illumination for the scene.
Daylight, twilight and moonlight have ambient components over theentire scene. Landing lights typically provide ambient-typeillumination over a limited area of the scene.

Illumination,
Directional

Scene illumination provided by an illumination source at a particular
position or direction in the environmental database spatial frame. The
effect on object luminance depends on the angle between theillumination source and object surface normal.

J
K
L
Latency

The time interval from a request to a prescribed response from thetargeted device.

Level-of-Detail (LOD)

Representations of the same thing that differ only in the amount offidelity. An LOD is said to be coarse if it contains little detail or fine if
it contains considerable detail.

Light Point

A database element used to model a point source of light (e.g., ataxiway lights, street lights, collision lights).

Light String

A group of lights, usually a series of light points sharing common
spacing characteristics and are of a common type.

Lineal Feature

See Feature, Lineal.

© 2015 Open Geospatial Consortium

455

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Local Vertical Spatial
Frame

See Spatial Frame, Local Vertical.

M
Material

Shorthand for either Base Material or Composite Material.

Material, Base

Symbolic representation of a basic material in the CDB. Basicmaterials are inputs to production or manufacturing processes. They
are often raw, that is unprocessed, but are sometimes processed before
being used in more advanced production processes. Basic materials
represent the substances out of which a thing is or can be made.
Examples are materials such as steel, aluminum, copper, sand, soil,stone, glass, concrete, wood, water, rubber. Base materials are chosen
for their relevance to simulation.

Material, Composite

A symbolic representation that corresponds to a composite material
that is made up of a primary substrate and one or more secondary
substrates. Each substrate is composed of one or more base materials
entries. The substrates can each be assigned a thickness.

Metadata

Data about data. Metadata describes how and when and by whom aparticular set of data was collected, and how the data is formatted.

Mission Functions

A set of low-level simulator query functions performed on thesynthetic environment; includes such functions as Height Above
Terrain (HAT), Height Above Culture (HAC), Collision Detection(CD), Line-Of-Sight (LOS), Laser Range Finder (LRF), etc.

Model

A term which stands for the 2D or 3D representation of features(exclusive of the terrain and/or bathymetry itself) within the synthetic
environment database. Models can be statically positioned on theterrain (i.e., a cultural feature), or they are freely moving (i.e., amoving model). Models are often a 3D representation of a man-madeor a natural object positioned and conformed relative to the terrain.
The information includes its geometry, articulations, raster imagery(texture, normal map, light map, etc.), lighting systems, and othercharacteristics relevant to simulation.

Model, 2D

Refers to the modeled representations of 2D features; i.e., lineal or
areal features that have no significant height with respect to theunderlying terrain; 2DModels generally conform to the terrain profile.

© 2015 Open Geospatial Consortium

456

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Model, 3D

Refers to the modeled representation of 3D features that can be readily
distinguished from the underlying terrain. In the case where they are
unique, they are referred to as GSModels. In the case where they are
instanced, they are referred to as GTModels. 3DModels capable ofmovement are called MModels. In the case where MModels are
positioned by the modeler, they are called statically-positioned
MModels.

Model, Cultural

A model that is statically positioned on the terrain or bathymetry skin.
Cultural models are often a 3D representation of a man-made or anatural object positioned and conformed relative to the terrain. The
information includes its geometry, articulations, raster imagery(texture, normal map, light map, etc.), lighting systems, and othercharacteristics relevant to simulation.

Model, GS

The geospecific representation of a cultural feature that is unique
within the CDB.

Model, GT

The geotypical representation of a cultural feature that can be reused
several times throughout the CDB.

Model, Moving

A model that is not fixed at one location in the synthetic environment
database. The simulation host can update the position and orientationof a moving model at every simulation iteration cycle. A moving
model is a 3D representation of man-made and natural objects free tomove within the CDB. The information includes feature typeidentification, (vehicle class, type, model, etc.), geometry,articulations, raster imagery (texture, normal map, light map, etc.),lighting systems, connectivity to special effects, attribution and othercharacteristics relevant to simulation.

Model-LOD

Refers to a specific level of detail of the modeled representation of afeature; a general term encompassing both 2D and 3D Model-LOD

Model-LOD, 2D

Refers to a specific level of detail of a 2D model.

Model-LOD, 3D

Refers to a specific level of detail of a 3D model.

Modeler

The person who creates and assembles a synthetic environment
database.

N© 2015 Open Geospatial Consortium

457

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Navigational Data

Is a representation of ARINC-424 and DAFIF data in the form of
NAVAIDs (VHF, ILS/MLS, NDB, Markers), Communications
Stations, Airport/Heliport (including SIDs, STARs, Terminal
Procedure/Approaches, Gates), Runway/Helipad, Waypoints, Routes,
Holding Patterns, Airways and Airspace.

Normal Vector

A vector of unit length perpendicular to a surface.

Numerical Correlation

See Correlation, Numerical.

O
Ownship

The vehicle (aircraft, ship, tank, etc.) being simulated.

P
Parametric
Correlation

See Correlation, Parametric.

Pilot Eyepoint

See Eyepoint, Pilot.

Point Feature

See Feature, Point.

Q
R
Raw Source

A term generally used to describe the data imported into the databasegeneration workstation for the purpose of off-line assembling andbuilding the synthetic environment. The level of pre-processing
applied to the source may vary considerably (from raw data directlyfrom sensors such as unprocessed satellite raster imagery or photos todata directly usable by simulator client-devices). Source data need not
be in digital form (e.g., photos).

Raw Source DB
Correlation

See Correlation, Raw Source DB.

Runtime Publisher

A real-time software process (either shared or dedicated to a computer
platform) that a simulation application client-device uses to transformor translate CDB data into a format that can be directly input by theclient-device it serves.

Runtime DB
Correlation

See Correlation, Runtime DB.

© 2015 Open Geospatial Consortium

458

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
S
Sensor Environmental
Model (SEM)

A simulation of the synthetic environment over a portion of theelectromagnetic spectrum that is relevant to a client-device. A SEM is
usually based on mathematical model of the environment for the
portion of the electromagnetic spectrum of interest.

Sensor Simulation
Model (SSM)

A simulation of a real-world sensor over a portion of theelectromagnetic spectrum that is relevant to the sensor being
simulated. A SSM is usually based on mathematical model of the realworld sensor for the portion of the electromagnetic spectrum ofinterest.

Simulator CDB
Repository

The simulator CDB repository consists of a mass storage system(typically a storage array) and its associated network infrastructure. It
is connected to the UMC (primarily for update purposes) and the CDB
Servers (for simulator client-device runtime access).

Source DB
Correlation

See Correlation, Source DB.

Spatial Coordinate
System

A spatial coordinate system is a means of associating a uniquecoordinate with a point in object-space.

Spatial Frame (SF)A spatial reference frame is a spatial coordinate system for a region of
object-space.

Spatial Frame,
Geocentric

An earth-centered spatial frame that defines 3D Euclidian space withrespect to the geometric centre of the reference ellipsoid, the centre of
the earth128. The reference datum of the earth-centered SF is based on
the WGS-84 ellipsoid reference model. In this SF, the z-axis ispointing at the North Pole, the x-axis is pointing at the intersection of
the equator and the Greenwich meridian, the prime meridian, and they-axis is pointing at the intersection of the equator and 90 degrees east
longitude.

128

In this coordinate system, the z-axis is defined by the earth’s axis of rotation. Furthermore, the equatorial plane
is defined by a plane normal to the z-axis, halfway from the North and South Pole (using gravitational
equipotential).

© 2015 Open Geospatial Consortium

459

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
Spatial Frame, Local
VerticalThe Local Vertical Coordinate System (LVCS) SF defines a 3D
Euclidian space. It is SF similar to the Geocentric SF except that theorigin of the SF is translated and rotated to a point on the surface of the
WGS-84 ellipsoid. At that point, the x-y plane is tangent to the surfaceof the earth and the z-axis is normal to the ellipsoid.

T
TargetA 1 nm x 1 nm area modeled in accordance to the following criteria:(a) Elevation grid post spacing, 3 m.
(b) Terrain imagery resolution, 0.25 m.
(c) Contains all objects of height greater than, 1 m (3 ft).

Target Area

See Area, Target.

Target Perimeter Area See Area, Target Perimeter.
TerrainA representation of earth surface shape/elevation, raster imagery,surface attribution and other earth surface characteristics relevant tosimulation. Also includes bodies of water such as oceans, lakes.

Terrain Profile

See Terrain.

Terrain Skin

See Terrain.

UV
Viewpoint

The viewpoint is the position from which the synthetic environment
database is being observed.

W
X
Y
Z
0-9
2D Feature

See Culture, 2D.

2D ModelSee Model, 2D© 2015 Open Geospatial Consortium

460

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Description
2D Model-LOD

See Model-LOD, 2D

3D Feature

See Culture, 3D.

3D ModelSee Model, 3D

3D Model-LOD

See Model-LOD, 3D© 2015 Open Geospatial Consortium

461

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 99Acronyms and Abbreviations
Definition

A
ADF

Automatic Direction Finder

ATS

Air Traffic Simulation

B
BMT

Base Material Table

BW

Black and WhiteC
CD

Collision Detection

CDT

Complex Data Type

CDB

Common Database (for Real-time Simulation)

CGF

Computer Generated Forces

COMMS

Communication Systems

COTS

Commercial-off-the-shelf

CMT

Composite Material Table

CPU

Central Processing Unit

D
DAFIF

Digital Aeronautical Flight Information FileDB

Database

DBGF

DataBase Generation Facility© 2015 Open Geospatial Consortium

463

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Definition
DFAD

Digital Feature Analysis Data

DGIWG

Digital Geographic Information Working GroupDIGEST

Digital Geographic Exchange Standard

DRM

Data Representation Model

DTED

Digital Terrain Elevation Data

DNS

Doppler Navigation System

E
EDCS

Environmental Data Coding Specification

EDRM

Environment Data Representation Model

EW

Electronic Warfare

ERM

Earth Reference ModelF
FACC

Features and Attributes Catalog Codes

FC

Fiber Channel

FDD

Feature Data Dictionary

FFS

Full Flight Simulator

FLIR

Forward Looking InfraRed

FMS

Full Mission Simulator

FSC

FACC Sub CodeFsE

Fast Ethernet

ft

Feet

G
GPS

Global Positioning System© 2015 Open Geospatial Consortium

464

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Definition
GB

GigaByte

GbE

Gigabit Ethernet

H
HAC

Height Above Culture

HAO

Height Above Ocean

HAT

Height Above Terrain

HLAHigh Level Architecture

HLZ

Helicopter Landing Zone

HOC

Height Of Culture

HOO

Height Of Ocean

HOT

Height Of Terrain

Hz

Hertz

I
ICAO

International Civil Aviation Organization

ICD

Interface Control Document

ID

Identification

IEEE

Institute of Electrical and Electronics Engineers

IG

Image Generator

ILS

Instrument Landing System

INU

Inertial Navigation Unit

IO

Input Output

IPInternet Protocol

IPIntellectual Property© 2015 Open Geospatial Consortium

465

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Definition
IR

InfraRedJ
JPEG

Joint Photographic Expert GroupK
Km

kilometers

L
LOD

Level of Detail

LOSLine of Sight

LRF

Laser Ranging Function

LVCS

Local Vertical Coordinate System

LZW

Lempel-Ziv-Welch (compression algorithm)

Mmmeter(s)MB

MegaByte

MIF

Mission Functions

MIP

Multium In Parvo (“many in a small place”)

MLS

Microwave Landing System

MR

Mission Rehearsal

N
NAV

Navigation System

NAVSTAR

Navigation System Using Timing and Ranging

NDB

Non-Directional Beacons

NIMA

National Imagery and Mapping Agency© 2015 Open Geospatial Consortium

466

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Definition
nm

nanometer

NVG

Night Vision GoggleO
OneSAFOne Semi-Automated Forces

OS

Operating System

OTW

Out The WindowP
PB

PetaByte

PLS

Personnel Locating System

Q
R
RCS

Radar Cross Section

RGB

Red Green Blue

RF

Radio Frequency

ROI

Region of Interest

RTP

Run Time Publisher

S
SAF

Semi-Automated ForcesSE

Synthetic Environment

SEDRIS

Synthetic Environment Data Representation & Interchange
Specification

SEM

Sensor Environment Model

SID

Standard Instrument Departure© 2015 Open Geospatial Consortium

467

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Definition
SIF

Standard Interchange Format

SF

Spatial Frame

SM

Spatial Model

SSM

Sensor Simulation ModelSTAR

Standard Terminal Arrival Route

T
TACAN

Tactical Air Navigation

TB

TeraByteU
UHRB

Ultra High Resolution Buildings (OneSAF)

UM

Update Manager

UMS

Update Manager Server (software)

UMC

Update Manager Client (software)

UML

Unified Modeling Language

UTM

Universal Transverse Mercator

V
VHF

Very High Frequency

VOR

VHF Omni Range

VSTI

Visible Spectrum Terrain Imagery

VSTLM

Visible Spectrum Terrain Light Map

W
WGSWorld Geodetic System

WX

Weather or Weather Simulation© 2015 Open Geospatial Consortium

468

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Definition
X
XML

Extensible Mark-up Language

Y
Z
0-9
1D

Unidimensional

2D

Bidimensional

3D

Three-Dimensional© 2015 Open Geospatial Consortium

469

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 10
Reference Documents

10This table lists the documentation referenced throughout this document.

Ref Title

Description

1

ARINC Standard 424-16

Navigation System Data Base, Aeronautical Radio Inc., August 30, 2002.

2

ASTARS-04 CDB

Systems Requirements

3

Digital Geographic Information
Exchange Standard (DIGEST),
Standard V2.1

The document can be obtained at the following address:
http://www.digest.org/

4

Enumeration and Bit Encoded
Values for use with Protocols forDistributed Interactive Simulation
Applications.

This is document SISO-REF-010. It accompanies IEEE Std 1278.1-1995
and can be obtained from the Simulation Interoperability Standards
Organization at http://www.sisostds.org/

5

Extensible Markup Language(XML) 1.0 (Third Edition)

Bray, Tim, et al.
http://www.w3.org/TR/2004/REC-xml-20040204/
W3C Recommendation, February 04, 2004.

6

Guide - PD6777, BSI's Guide to
the practical implementation of
JPEG 2000

The document can be found at:
http://www.jpeg.org/
Other useful sites include:
http://en.wikipedia.org/wiki/SRGB_color_space
The document is targeted at managers; application software developers
and end-users who want to know more about JPEG 2000.

7

IEEE Standard for Distributed
Interactive Simulation Application Protocols

IEEE Std 1278.1-1995

8

JPEG 2000: Image Compression
Fundamentals, Standards andPractice

Kluwer International Series in Engineering and Computer Science, Secs
642, by David S. Taubman and Michael W. Marcellin© 2015 Open Geospatial Consortium

471

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Ref Title

Description

9

The Raster Product Format (RPF) is a standard data structure forgeospatial databases composed of rectangular arrays of pixel values (e.g.,
in digitized maps or images) in compressed or uncompressed form. RPF
defines a common format for the interchange of raster-formatted digital
geospatial data among DoD Components.

MIL-STD-2411 Raster ProductFormat Specification

Department of Defense Information Technology Standards Registry
Baseline Release 04-2.0.
http://earth-info.nga.mil/publications/specs/printed/2411/2411_RPF.pdf
10

MIL-C-89041 Controlled Image
Base Specification

Controlled Image Base (CIB). This Specification provides requirements
for the preparation and use of the RPF CIB data. CIB is a dataset oforthophotos, made from rectified grayscale aerial images.
http://www.fas.org/irp/program/core/mil-c-89041-cib.htm

11

OpenFlight Scene Description
Database Standard, Version 16.0,
Revision A, November 2004,
Presagis Inc

The original document has been annotated by CAE to create the CDBannotated OpenFlight Standard.

12

Product Standard for the Digital
Aeronautical Flight Information
File (DAFIF), Eight Edition, Doc.
# PS/1FD/086

National Imagery and Mapping Agency (NIMA), April 2003.

13

SEDRIS™ - Synthetic
Environment Data Representation
Interchange Specification

The Source for Synthetic environment Representation and Interchange.
http://www.sedris.org

14

Shapefile Technical Description an ESRI White Paper—July 1998

The original document has been annotated by CAE Inc to create the CDBannotated Shapefile Technical Description.

15

The SGI Image File Format,
Version 1.00, Paul Haeberli,
Silicon Graphics Computer
Systems

This specification can be found at:

TIFF rev 6.0 Adobe Developers
Association, Adobe Systems
Incorporated, 1585 Charleston
Road and P.O. Box 7900Mountain
View, CA 94039-7900

A copy of this original standard can be found at:
http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

16

http://paulbourke.net/dataformats/sgirgb/sgiversion.html

and at:ftp://ftp.adobe.com/pub/adobe/
DeveloperSupport/TechNotes/PDFfiles
The original document has been annotated by CAE Inc to create the CDBannotated TIFF Standard.

17

XML Schema Part 0: Primer
Second Edition

Fallside, David, Priscilla Walmsley.
http://www.w3.org/TR/xmlschema-0/
W3C Recommendation, October 28, 2004.

© 2015 Open Geospatial Consortium

472

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Ref Title

Description

18

Thompson, Henry S., et al.

XML Schema Part 1: Structures
Second Edition

http://www.w3.org/TR/xmlschema-1/
W3C Recommendation, October 28, 2004.

19

XML Schema Part 2: Datatypes
Second Edition

Biron, Paul V., Ashok Malhotra.
http://www.w3.org/TR/xmlschema-2/
W3C Recommendation, October 28, 2004.

20

ICAO Airline Designator

List of ICAO Airline Codes,
http://en.wikipedia.org/wiki/Airline_codes

21

22

23

Radar Signatures and Relations toRadar Cross-Section. Mr. P E R
Galloway, Roke Manor ResearchLtd, Romsey, Hampshire, United
Kingdom.

This document can be obtained at the following Internet address:

AN/APA to AN/APD Equipment Listing.

This document can be obtained at the following Internet address:

Radar Polarimetry - Fundamentals
of Remote Sensing.

This document can be obtained at the following Internet address:

http://www.designation-systems.net/usmilav/jetds/an-apa2apd.html#_APA

National Resources Canada.
24

http://aircraftdesign.nuaa.edu.cn/lo/Ref/General%20Topics/radar_signatur
es_and_relations_to_rcs.pdf

RCS in Radar Range Calculationsfor Maritime Targets, by Ingo
Harre. Bremen,https://www.nrcan.gc.ca/earth-sciences/geomatics/satellite-imagery-airphotos/satellite-imagery-products/educational-resources/9275
This document can be obtained at the following Internet address:
http://www.mar-it.de/Radar/RCS/RCS_xx.pdf

Germany. (V2.0-20040206).
25

Decibels relative to a square meter– dBsm. By Zhao Shengyun.

This document can be obtained at the following Internet address:

26

MIL-C-89041

Controlled Image Base (CIB)27

MIL-STD-2411

Defense Mapping Agency, Military Standard, Raster Product Format
(RPF)

28

MIL-STD-2411-1

Defense Mapping Agency, Registered Data Values for Raster ProductFormat29

MIL-STD-2411-2

Defense Mapping Agency, Incorporation of Raster Product Format (RPF)
Data in National Imagery Transmission Format (NITF).

http://radarproblems.com/chapters/ch06.dir/ch06pr.dir/c06p11.dir/c06p11.
htm© 2015 Open Geospatial Consortium

473

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Ref Title

Description

30

IEEE Std 1516-2000

IEEE Standard for Modeling and Simulation (M&S) High Level
Architecture (HLA)31

RPR-FOM Version 2 Draft 17

Real-time Platform Reference (RPR) Federation Object Model (FOM)
This RPR-FOM maps the DIS standard to the HLA standard.
The document can be obtained from the Simulation Interoperability
Standards Organization at the following address:
http://www.sisostds.org/

32

Performance Specification Vector Smart Map (VMAP Level 0), 28
September 1999

MIL-PRF-89039 Amendment 2

http://en.wikipedia.org/wiki/Vector_Map
http://earth-info.nga.mil/publications/specs/printed/VMAP0/vmap0.html
33

MIL-PRF-89033 Amendment 1

Performance Specification Vector Smart Map (VMAP Level 1), 27 May
1998

34

MIL-PRF-89035A

Urban Vector Map (UVMap), 1st August, 2002

35

OneSAF Ultra High Resolution
Building (UHRB) Object Model

OneSAF UHRB Object Model (Version 2.2, Document Revision E, March
7th, 2008, Contract #: N61339-00-D-0710, Task Order: 28.)
http://www.onesaf.net/community/systemdocuments/v.3.0/MaintenanceM
anual/erc/UHRB_2_Object_Model.pdf

36

OneSAF Ultra High Resolution
Building (UHRB) On-Disk
FormatOneSAF UHRB On-Disk Format Model (Version 2.2, Document Revision
E, March 7th, 2008, Contract #: N61339-00-D-0710, Task Order: 28.)
http://www.onesaf.net/community/systemdocuments/v.3.0/MaintenanceM
anual/erc/UHRB_2_On_Disk_Format.pdf

37

U.S. Department ofTransportation - Federal Aviation
Administration – Advisory
Circular 150/5340-1J

Standards for Airport Markings, AC- 150/5340-1J, dated 4/29/2005

38

Federal Aviation Administration –Aeronautical Information Manual

Official Guide to Basic Flight Information and ATC Procedures, dated
14th February, 2008

© 2015 Open Geospatial Consortium

474

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014

Chapter 11

11
List of Contributors
The CDB Specification has been developed from active collaboration between many
individuals from different organization levels. They are listed below in alphabeticalorder.

CDB Authors
Bernard Lalonde, CAE

Bernard Leclerc,

CAE

Michel Lagacé, CAE
Pierre Samson , CAE

CDB Contributors and Reviewers
Arnaud Banel, CAE
Brian Ford, FSIDavid Nadeau , Presagis
Frédérick St-Laurent, Presagis
Hermann Brassard, Presagis
John Oliver, Presagis
Nick Giannias, Presagis
Patrick Lavoie, Presagis
Richard Pitre, Presagis
Roland Humphries, XPI Simulation
Ryan Franz, FSI© 2015 Open Geospatial Consortium

475

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CDB Project Instigators
Earl Miller, U.S. Government
Jill Ashby, U.S. Government
Joe Preston, U.S. Government
Kevin Mobley, U.S. Government
Larry Grice, U.S. Government
Rita Simons, U.S. Government
Victor Colon, U.S. Government© 2015 Open Geospatial Consortium

476