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-vol2/1.0
Internal reference number of this OGC® document:

15-004

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

OGC Common DataBase
Volume 2 Appendices
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

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.

i.

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

ii.

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.

iii.

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

iv.

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 2.

vi

Copyright © 2015 Open Geospatial Consortium

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version Error! Unknown document property name. published 19 March 2014

2. Common DataBase (CDB) Version 3.2 Specification Volume 2	  Table of ContentsA.	
   Guidelines, Clarifications, Rationales, Primers, Information ................................................. 1	
  B.	
   TIFF Specification 6.0 – Annotated...................................................................................... 89	
  C.	
   OpenFlight v16.0 Technical Description - Annotated ........................................................ 211	
  D.	
   ShapeFile and dBASE July 1998 Technical Description – Annotated ............................... 387	  E.	
   CDB Light Names and Hierarchy ....................................................................................... 433	  F.	
   CDB Model Components .................................................................................................... 445	  G.	
   Gamma Tutorial .................................................................................................................. 447	  H.	
   Navaids Attribution ............................................................................................................. 463	
  
I.	
  

Navaids Attribution Enumeration Values ........................................................................... 571	
  

J.	
  

XML Schema Definitions ................................................................................................... 645	  K.	
   CDB Coordinate Systems ................................................................................................... 647	  L.	
   CDB Base Materials ........................................................................................................... 661	  M.	
   CDB Directory Naming and Structure ................................................................................ 662	  N.	
   CDB Feature Data Dictionary ............................................................................................. 663	  O.	
   List of Texture Component Selectors ................................................................................. 665	  P.	
   SGI Image File Format ....................................................................................................... 681	  Q.	
   Table of Dataset Codes ....................................................................................................... 695	  R.	
   Derived Datasets within the CDB ....................................................................................... 699	  S.	
   Default Read and Write values to be used by Simulator Client-Devices ........................... 703	  T.	
   JEPG 2000 File Format Syntax........................................................................................... 705	  U.	
   ZIP File Format Specification ............................................................................................. 731	  vii

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 A-1: Typical Electrical Pylon .............................................................................................. 1	  Figure A-2: Pylon Orientation ........................................................................................................ 2	  Figure A-3: Attach Point Orientation ............................................................................................. 4	  Figure A-4: UHRB Class Diagram ............................................................................................... 13	
  Figure A-5: UHRB Association Diagram ..................................................................................... 14	
  Figure A-6: CDB Model Interior Object Model ........................................................................... 15	  Figure A-7: Application of Constraint Point - Uniformly-Sampled Terrain ................................ 17	
  Figure A-8: Application of Constraint Line - Uniformly-Sampled Terrain ................................. 18	
  Figure A-9: Application of Constraint Triangle - Uniformly-Sampled Terrain ........................... 20	  Figure A-10: Application of Constraint Point – Non-uniform Grid ............................................. 22	
  Figure A-11: Application of Constraint Lineal – Non-uniform Grid ........................................... 24	
  Figure A-12: Application of Constraint Areal – Non-uniform Grid............................................. 26	
  Figure A-13: Client-device Read Behavior .................................................................................. 28	
  Figure A-14: Paging of Terrain Imagery with an LOD Structure ................................................ 41	
  Figure A-15: Paging of Terrain Imagery without an LOD Structure ........................................... 42	
  Figure A-16: Case 1 – No Intersection ......................................................................................... 43	
  Figure A-17: Case 2 – Potential Intersection ................................................................................ 43	
  Figure A-18: Case 3 – Guaranteed Intersection ............................................................................ 44	
  Figure A-19: Relative Azimuth (α) and Elevation (φ) Angles ..................................................... 45	
  Figure A-20: Polar Diagram of RCS data in Decibels at a given elevation angle ........................ 46	
  Figure A-21: Linear Diagram of RCS data in Decibels at a given elevation angle ...................... 46	
  Figure A-22: Horizontal and Vertical Polarization of a plane of EM wave ................................. 47	
  Figure A-23: Examples of Ocean Tide Simulation Fidelity in Simulator .................................... 50	
  Figure A-24: Concurrent Usage of CDB Versions ....................................................................... 59	
  Figure A-25: Handling Tile-LOD Overflows in GSModel Dataset ............................................. 61	
  Figure A-26: Compacting the GSModel Dataset .......................................................................... 63	
  Figure A-27: Handling Tile-LOD Overflows within the T2DModel Dataset Hierarchy ............. 71	
  Figure A-28: Compacting the T2DModels Dataset Hierarchy ..................................................... 73	
  Figure A-31: Example of Lineal Features .................................................................................... 79	
  Figure A-32: Radar Beam Simulation .......................................................................................... 80	
  Figure A-33: Network Dataset Used to Describe a Navigable Network ...................................... 81	
  Figure A-34: Objects Represented on a Terrain Tile .................................................................... 82	
  Figure A-35: Incident Angle ......................................................................................................... 83	
  Figure A-36: Beam Simulation ..................................................................................................... 84	
  Figure A-37: Four Areal Features Stored in the Tile .................................................................... 85	
  Figure A-38: Radar Beam Simulation .......................................................................................... 87	
  Figure G-1: Typical Handling of Gamma at DBGF and Simulator............................................ 455	
  Figure K-1: Cartesian Model positioned to WGS-84 Coordinates ............................................. 648	  Figure K-2: CDB 3D Model Coordinate System ........................................................................ 656	
  Figure K-3: DIS Entity Coordinate System ................................................................................ 656	
  ix

Copyright © 2015 Open Geospatial Consortium

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

Appendix A
A. Guidelines, Clarifications, Rationales, Primers, Information
A.1
Guideline: Creating a 3D Model for a Powerline Pylon
The goal of this guideline is to model a typical high voltage electrical pylon resembling the one
in this figure. This guideline is based on version 3.1 of the Specification, but is applicable toversion 3.0 as well.

Figure A-1: Typical Electrical Pylon

A.1.1
Pylon Model Orientation
The front (and back) of a powerline pylon is aligned with the general direction of the attachedwires as illustrated below.

© 2015 Open Geospatial Consortium

1

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

Figure A-2: Pylon Orientation

The above snapshot is similar to the one found in Figure 6–10 of the Specification.

A.1.2
OpenFlight Graph
The graph of the above pylon exposes the 3 cross-arms, each with 2 insulators where wires areattached. Here are the names of the components that are used to model this power pylon:
Pylon (global zone)
Arm (horizontal cross-arm at the top of the structure)
Insulator (ceramic insulator string attached at the end of each arm)
These 3 names are used to create CDB Zones as explained in section 6.5 of the Specification.
Here is the first level of the resulting graph.
Pylon

ObjectArm[1]

Arm[2]

Arm[3]The rounded rectangle named Object is an OpenFlight object node containing the geometry of
the concrete base and lattice steel structure of the pylon, but excluding the geometry of the crossarms. Arm[1] is the lowest cross-arm; Arm[2] is the middle one; Arm[3] is the top one. Eacharm is then made of a steel structure and 2 insulators.
Arm[n]

ObjectInsulator[1]Insulator[2]© 2015 Open Geospatial Consortium2

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Again, Object represents the steel structure of the cross-arm without the insulators. Whenlooking at one of the cross-arm of the power pylon from the back, Insulator[1] is to the left while
Insulator[2] is to the right. Finally, each insulator has an attach point to indicate where toconnect an eventual wire.
Insulator[n]ObjectAttach_Point

The node Object contains the geometry of the insulator.
As explained in section 6.8 of the Specification, the resulting list of paths is as follow:\Pylon\Pylon\Arm[1]\Pylon\Arm[1]\Insulator[1]\Pylon\Arm[1]\Insulator[1]\Attach_Point\Pylon\Arm[1]\Insulator[2]\Pylon\Arm[1]\Insulator[2]\Attach_Point\Pylon\Arm[2]\Pylon\Arm[2]\Insulator[1]\Pylon\Arm[2]\Insulator[1]\Attach_Point\Pylon\Arm[2]\Insulator[2]\Pylon\Arm[2]\Insulator[2]\Attach_Point\Pylon\Arm[3]\Pylon\Arm[3]\Insulator[1]\Pylon\Arm[3]\Insulator[1]\Attach_Point\Pylon\Arm[3]\Insulator[2]\Pylon\Arm[3]\Insulator[2]\Attach_Point
Note the presence of a total of 6 attach points (1 attach point per insulator × 2 insulators per
cross-arm × 3 cross-arms per pylon = 6 attach points per pylon). Even though all attach points
have the same name, there is a unique path to reach each one. For this reason, there is noambiguity identifying and locating each point.

A.1.3
Attach Point Orientation
When creating the attach point of the insulator, pay attention to its orientation. Since the cableattaches underneath the insulator, the Z-axis of the local coordinate system (LCS) must be
pointing down. To achieve a proper positioning of the attach point, the modeler usually inserts
two transformations in the node, one translation and one rotation. The translation positions thepoint underneath the insulator while the rotation changes the orientation of the Z-axis. Make
sure to leave the Y-axis in the direction of the wire as in the figure below.

© 2015 Open Geospatial Consortium

3

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

Figure A-3: Attach Point Orientation

In this figure, the position and orientation of the attach point is identified by the blue-red-green
axis system beneath the insulator. The Y-axis is in red and points in the same direction as themodel’s Y-axis, which is toward the front of the model. The Z-axis is in green and points down
indicating that wires attach under the insulator.

A.2
Guideline: Generating Wires between Pylons of a Powerline
This guideline is intended for both modelers and developers responsible for the creation of:
CDB content such as 3D models representing pylons
Tools used to generate the Powerline Network datasets
Client-devices that use the Powerline Network datasets to generate pylons andwires along the transmission line.
The article is based on version 3.0 of the CDB Specification.

A.2.1
Powerline Network Attributes
The table below is the collection of class and instance-level attributes from tables 5-46 and 5-47of the CDB Specification.

© 2015 Open Geospatial Consortium

4

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

Table A-1: Powerline Attributes
Required
Attributes

Optional
Attributes

CMIX

AHGT

CNAM

AO1

DIR

BBH

EJID

BBL

FACC

BBW

FSC

BSR

JID

HGT

LENL

MODL

RTAI

MODT

SJID

SCALn

WGP

The occurrence of some of the optional attributes depends on the occurrence of other optional
attributes. In particular, when MODL is present, other attributes become required while others
remain optional. The table below provides the relation between MODL and other attributes.

Table A-2: MODL-related Attributes
Required Optional
BSR

AO1

HGT

BBH, BBL, BBW

MODT

SCALn

As a result of the above tables, a CDB-compliant Powerline Network dataset requires 11
mandatory attributes (listed in the first column of Table A-1). Optionally, when a 3D model
representing a pylon is provided, 4 additional attributes are required (MODL obviously, plus
BSR, HGT, and MODT) and 5 others remain optional (AO1, BBH, BBL, BBW, and SCALn).

© 2015 Open Geospatial Consortium

5

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

A.2.2
Generation of HGT
The HGT attribute represents a special case because table 5-47 suggests that the attribute is
optional while, in fact, it should always be present. If you carefully read its description inparagraph 5.3.1.2.3.17, you realize that HGT is required in both the lineal and figure point
features of the Powerline Network.
In the lineal features, HGT represents the average height above ground of the powerline when no
MODL is specified, as suggested by the discussion about HGT in section 5.3.1.17 of theSpecification. In the figure point features, HGT represents the height above ground of the pylon,
whether or not a MODL is provided. In either file, when MODL is supplied, HGT represents theheight of the 3D model above the ground.
You should read guideline A.3 for a complete discussion about HGT

A.2.3
Pylon Orientation
If the orientation of the pylon is specified by AO1, then use the value as-is. If the orientation is
not specified, the client device must compute its value using the orientation of the segments of
the lineal that are adjacent to the pylon. In the case of the first and last segments, the orientationof the segment is also the orientation of the pylon. For the other segments, the orientation of thepylon is the average of the orientation of the two adjacent segments.

A.2.4
Number of Wires
When no MODL is provided at all – meaning no MODL for the lineal and none for the figure
points – and because there is no attribute specifying the number of wires along the transmissionline, the client device must assume a generic powerline with two wires separated by a width of
WGP meters connecting generic posts (simple pylons) of HGT meters high.
When a common MODL is specified for the whole lineal and no figure points are provided, it ispossible to determine the number of wires by counting the number of attach points in the 3Dmodel. Refer to guideline A.1.2 for details on how to detect attach points.
If specific MODLs are defined through figure points, the number of attach points in each 3Dmodel of the collection of all MODLs referenced by the powerline network must be identical.
For instance, if the lineal refers to a generic pylon supporting 4 wires, then all specific pylons
referenced as figure points must also support 4 wires. Furthermore, the general configuration of
all pylons must be identical. If the general pylon supports 6 wires configured as a matrix of 2
wires horizontally by 3 wires vertically, then all specific pylons must also share the same
configuration.

© 2015 Open Geospatial Consortium

6

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
A.2.5
How to Connect Wires to Attach Points
If the client device has a single generic pylon along the line, then there is no problem connecting
wires and attach points. That is when multiple pylons are used along the same line that problems
arise. The client has to match attach points from one type of pylon to attach points on anotherpylon that may be of a different type. In CDB Spec 3.0, the algorithm to determine how toconnect pylons of different types is left to the client device. The future version of CDB
Specification will provide a robust and deterministic approach on how to connect the wires.

A.3
Guideline: How to Interpret the AHGT, HGT, BSR, BBH, and Z Attributes
The goal of this guideline is to promote a correct use of five CDB attributes: AHGT, HGT, BSR,
BBH, and Z. The article is aimed to both developers and users of content creation tools as well
as developers of client applications. The guideline is based on version 3.1 of the Specification,
but remains applicable to version 3.0 as well.

BSR

A picture being worth a thousand words, the following diagram should help understand therelations between the AHGT, HGT, BSR, BBH, and Z attributes.

HGT

BBH

MODL
Za

XY	
  PlaneGroundZr

Here is a reminder of what these attributes are. The complete definitions can be found in Section
5.3.1.3, CDB Attributes.
AHGT (Absolute Height) is a flag to interpret correctly the value of the Z
coordinate of a feature. When false, the value of Z is relative to the ground(Zr); when true, Z is the absolute altitude (Za).
AHGT is not related with HGT even though their names are similar.
HGT (Height Above Surface Level) is the distance from the top of the modelto the ground.
BBH (Bounding Box Height) is the distance from the top of the model to its
XY plane.
BSR (Bounding Sphere Radius) encompasses the portion of the model that is
above its XY plane.
Z is the altitude of a feature, either absolute or relative to the ground.
In the diagram above, a model (MODL) is positioned above the ground. This is indicated by thefact that the model’s XY plane does not lie directly on the ground. The distance above the© 2015 Open Geospatial Consortium

7

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
ground is represented by Zr. The diagram clearly shows the relation between HGT, BBH, andZr.
𝐻𝐻𝐻𝐻𝐻𝐻 = 𝐵𝐵𝐵𝐵𝐵𝐵 + 𝑍𝑍𝑍𝑍When the value of Zr is not readily available from the instance of the feature itself (because
AHGT is true), it can be computed using the ground height (Gh).
𝑍𝑍𝑍𝑍 = 𝑍𝑍𝑍𝑍 − 𝐺𝐺ℎThe BBH attribute is optional and defaults to twice the value of BSR, which is mandatory for a
MODL model.
𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑  𝐵𝐵𝐵𝐵𝐵𝐵 = 2×𝐵𝐵𝐵𝐵𝐵𝐵

𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑  𝐵𝐵𝐵𝐵𝐵𝐵 ≥ 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟  𝐵𝐵𝐵𝐵𝐵𝐵
A.3.1
Typical Use-case
Typically, a model is positioned relative to the ground without any offset. As a result, AHGT isfalse, and Zr is set to zero. Hence…
𝐻𝐻𝐻𝐻𝐻𝐻 = 𝐵𝐵𝐵𝐵𝐵𝐵
A.3.2
Light Points
In the case of airport and environmental light points, no model of a light fixture is provided (theMODL attribute is not allowed). Hence…
𝐵𝐵𝐵𝐵𝐵𝐵 = 0   → 𝐵𝐵𝐵𝐵𝐵𝐵 = 0

Since, in version 3.1 of the CDB Specification, the light point datasets do not allow the HGTattribute, the client application may have to compute its value using the equation given
previously…

where BBH is null.

𝐻𝐻𝐻𝐻𝐻𝐻 = 𝐵𝐵𝐵𝐵𝐵𝐵 + 𝑍𝑍𝑍𝑍
𝐻𝐻𝐻𝐻𝐻𝐻 = 𝑍𝑍𝑍𝑍

And if the light point is positioned at an absolute height (AHGT is true), then…
𝐻𝐻𝐻𝐻𝐻𝐻 = 𝑍𝑍𝑍𝑍 − 𝐺𝐺ℎ© 2015 Open Geospatial Consortium

8

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
A.3.3
Recommendation
Refrain from using AHGT. There are several advantages to leave this flag to false. First, 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 elevation dataset can be updated
without the need to recompute and update all features that have an absolute altitude.
Second, when a feature has an absolute altitude, it is possible that it will end up being displayed
below the ground by a given client. How is this possible? Isn’t it an error in the database itself?
No, this is not an error. It is perfectly possible to create content that is valid and – still – produce
an incorrect result at the client level. Consider a feature that is positioned with an absoluteheight in a valley between two mountains of a high resolution terrain profile. At coarse LOD of
terrain elevation, the valley and the mountains may (and will) be flattened producing a terrainskin that may no longer pass underneath the feature. Now imagine a client that uses that coarse
LOD of elevation to create a terrain skin and then draw the feature at its absolute altitude, whichhappen to be underneath the terrain skin. The feature will not be visible or will be partiallyoccluded by the terrain.
These reasons explain why the use of the AHGT flag should be avoided whenever possible.

A.3.4
When should AHGT be used?
Limit the use of AHGT to data whose source is inherently absolute. Such source data
include geodetic marks or survey marks that provide a known position in terms of latitude,
longitude, and altitude. Good examples of such markers are boundary markers between
countries.

A.4
Guideline: How to Model a Wind Turbine
This text proposes a way to create a 3D model representing an articulated wind turbine. The
articulations of interest are the yaw control to orient the turbine in the direction of the wind, theroll control to allow rotation of the rotor, and, optionally, the pitch control to change theorientation of the blades, if needed.
Besideinterest

is a typical Horizontal Axis Wind Turbine. The components ofare the following:

Looking
is notversionTurbineRotor
Blade
at appendix F – CDB Model Components – we note that Turbine
listed and, consequently, will be proposed for addition to futureof the CDB Specification.

© 2015 Open Geospatial Consortium

9

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Appendix N provides the proper FACC-FSC code for a Wind Turbine, AD010-005. The code
indicates the presence of a man-made point feature.
A = Culture
D = Power Generator
010 = Power Plant
005 = Wind
The hierarchy graph of the OpenFlight model could look like theone on the right. If individual control of the pitch of each blade
is required, the Blades object (the lower right node) could be
replaced with three (3) sub-trees each containing a Blade zone, a
DOF node, and an object node.
With the proposed layout, a client device will detect the presenceof a wind turbine through its FACC, and recognize and control
two articulations, the Turbine Yaw angle, and Rotor Roll angle.

Wind Turbine(Global Zone)

Mast(Object)

Turbine(Zone)

A last note: to comply with the prescribed orientation of the
CDB coordinate system as defined in section 6.3, the rotor must
represent the front of the wind turbine (and not its right side).
Reference: http://en.wikipedia.org/wiki/Wind_turbine

Yaw Control(DOF)

Nacelle(Object)

Rotor(Zone)

Roll Control
(DOF)

Hub
(Object)

Blades(Object)

A.5
Guideline: Handling of Model Interiors
CDB 3.1 introduces the concept of the interior of a 3D model. The concept is developed in
section 6.18, Model Interior, of volume 1 of CDB Specification 3.1. The following text serves as
a complement to the specification to understand how the concept has been developed and how
model interior is intended to be used.

© 2015 Open Geospatial Consortium

10

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
A.5.1
Relationship between Model Shell and Model Interior
The ModelInteriorGeometry dataset is a subordinate dataset of the ‘regular’ ModelGeometry
dataset. It depends directly on it. This is best illustrated by an example.

LOD

ModelGeometry

ModelInteriorGeometry

…
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
…

Coarsest Shell
Medium Shell
Fine Shell
Finest Shell-

Medium Interior
Fine Interior
Finest Interior-(Shell)(Interior)

In the above table, the Shell column represents what is called the ‘regular’ ModelGeometry
dataset. In this example, the model appears at LOD 2, a better version exists at LOD 6, an evenbetter at LOD 8, and finally, the most detailed shell is at LOD 10. The Interior column shows 3
different LODs of interiors. There cannot be more Interior LODs than Shell LODs. Also, once
an interior is provided (here at LOD 6), it must be provided for all subsequent (finer) LODs of
the shell (LOD 8 and 10). Which means… interior at LOD 8 and 10 must exist.

A.5.2
Detecting Presence of a Model Interior
It is expected that a client will first request the shell of the model, then discover that the model
has an interior because of the presence of a CDB Zone whose name is Interior (see 6.18.2,© 2015 Open Geospatial Consortium

11

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Pseudo-Interior), and then decide if the pseudo interior is sufficient for the application or if thereal interior is necessary.

A.5.3
Access of a Model Interior
Client applications that are interested in 3D models will typically perform the following
sequence of actions:
1. Load the GS Features of a tile
2. Load the GS and GT Models referenced by the GS Features
3. For each model, traverse its graph and detect the presence of an optional
Interior (Zone name = Interior)
4. Decide to load the corresponding Interior (or not)Interior datasets exists for both geospecific and geotypical models; hence, all features can be
represented by a 3D model and all 3D models can have a separately modeled interior. Note thesymmetry between the file names of shell and interior datasets. For geospecific models, thenames of geometry files are…
GeoCell_D300_S001_T001_Lxx_Ux_Rx_FACC_FSC_MODL.flt
GeoCell_D305_S001_T001_Lxx_Ux_Rx_FACC_FSC_MODL.flt

For geotypical models, the file names become…

D510_S001_T001_Lxx_FACC_FSC_MODL.flt
D515_S001_T001_Lxx_FACC_FSC_MODL.flt

Note that in both cases, the only difference between the name of the shell and the name of thecorresponding interior is the dataset code; and in both cases, a value of 5 is added to the‘regular’ ModelGeometry dataset code.

A.5.4
UHRB vs CDB Object Models
To help understand how CDB Model Interior maps to UHRB concepts, three (3) diagrams areprovided below. The first two diagrams illustrate the UHRB Object Model1 while the third
diagram presents the corresponding CDB Object Model.
The first diagram is the UHRB Class Diagram presented in Figure A-4 below. The class
diagram presents twelve classes of which eight are concrete classes that can be used to represent
tangible objects. The UHRB_EDM_COMPLEX_FEATURE class implements an extension
mechanism that is not required in the context of the CDB Specification. The remaining seven
UHRB classes will be mapped to CDB zones.

1

The two UHRB diagrams presented here come from the document entitled UHRB_2_Object_Model.pdf available
on the OneSAF web site: www.onesaf.net.

© 2015 Open Geospatial Consortium

12

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

Figure A-4: UHRB Class Diagram

The second diagram is the UHRB Association Diagram of Figure A-5; it shows all permissible
associations between the UHRB classes.

© 2015 Open Geospatial Consortium

13

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

Figure A-5: UHRB Association Diagram

The third diagram, in Figure A-6 below, presents the Object Model proposed by CDB Model
Interior objects. The UML diagram is both the class and association diagram of CDB zones
listed in table 6-27 of section 6.18.5 of CDB 3.1.

© 2015 Open Geospatial Consortium

14

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

Interior-Ground_Floor

1..*
Floor
-Label

*

*

1..*

2

-Adjacent Rooms

RoomPartition-List of Room Partitions-Label-Apertures-Partitions-Connected Rooms*-Label-Room-Surface

2*
Aperture-List of Room Apertures0..**

Fixture-Label-Is_Open-Is_Fixed-Damage_Level-Rooms-Surfaces-Label-Moveable***
Surface*-List of Aperture Surfaces-List of Partition Surfaces

Classes holding
real geometry

Classes holding
only footprints

Figure A-6: CDB Model Interior Object Model

A.6

Guideline: Applying Constraints to Uniformly Gridded TerrainThe	
  following	
  sub-­‐sections	
  describe	
  the	
  handling	
  of	
  point,	
  lineals	
  and	  areal	  constraint	
  features	
  
into	
  a	
  Uniformly	  Gridded	
  Terrain	
  Elevation	
  dataset	
  (e.g.	
  terrain	
  x,y	
  offset	
  datasets	
  are	  not	  available)	
  © 2015 Open Geospatial Consortium

15

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014Note	
  that	  the	
  rendering	
  outcome	
  into	  the	  Elevation	
  dataset	
  may	
  vary	  depending	
  on	
  the	  rendering	
  order	  of	
  overlapping	
  points,	
  lines	  or	
  areals.	
  	
  In	
  order	
  to	
  achieve	
  deterministic	  outcome	  by	
  all	  types	
  of	
  client-­‐devices,	
  client-­‐devices	
  are	
  required	
  to	
  sort	  features	
  by	
  their	
  layer	  priority	
  number	  LPN	  before	
  using	  them	  to	
  constrain	
  the	
  terrain	
  elevation	
  dataset.	
  	
  
The	
  rendering	
  of	
  a	
  point,	
  a	
  lineal	
  or	
  areal	
  features	
  into	  the	
  Uniformly	
  Sampled	
  Terrain	
  Elevation	  dataset	  is	
  performed	
  into	  the	
  same	  LOD	  as	
  the	
  LOD	  in	
  which	  the	
  vector	  feature	
  appeared.	
  	
  

A.6.1

Constraint PointsThis	
  section	
  describes	
  the	
  required	
  client-­‐device	
  behavior	
  for	  PointZ	
  and	  MultiPointZ	
  features	
  
used	
  as	
  terrain	
  elevation	
  constraint	  points	
  (AHGT	
  is	
  true)	
  into	  a	
  uniformly	
  sampled	
  terrain	
  elevation	
  dataset.	
  The	
  application	
  of	
  a	
  constraint	  point	
  P	
  is	
  very	  much	  like	  drawing	
  an	
  anti-­‐aliased	
  rectangle	
  centered	
  on	
  P	
  into	  the	
  uniform	
  terrain	
  elevation	  	
  grid.	
  	  	  The	  rectangle	
  shape	
  is	
  defined	
  by	
  feature	
  attributes	
  BBL,	
  BBH	
  and	  AO1.	
  Consider	
  a	
  terrain	
  grid	  element	
  A	
  in	
  the	
  immediate	
  vaccinity	
  of	
  a	
  constraint	  point	
  P.	
  After	
  applying	
  the	  constraint	
  P	
  to	
  terrain	
  grid	  element	
  A,	
  the	  new	
  elevation	
  𝐸𝐸   is:	  	
  where…	  𝐸𝐸    =    𝐸𝐸 ∗ 𝐴𝐴𝐴𝐴𝐴𝐴 +    𝐸𝐸 ∗    𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴   	
  

𝐸𝐸 	
  is	
  elevation	
  of	
  grid	  element	
  A	
  

𝐸𝐸 	
  is	
  elevation	
  of	
  constraint	  point	
  P	
  𝐴𝐴𝐴𝐴𝐴𝐴 	
  is	
  the	  percentage	
  overlap	
  of	
  constraint	  point	
  P	
  onto	  grid	  element	
  A	
  𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 	
  =	
   1   −    𝐴𝐴𝐴𝐴𝐴𝐴 	  © 2015 Open Geospatial Consortium

16

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

AinPA

A

B

AOI

D

BBL

P

BBW

C

Figure A-7: Application of Constraint Point - Uniformly-Sampled Terrain

A.6.2

Constraint LinealsThis	
  section	
  describes	
  the	
  required	
  client-­‐device	
  behavior	
  for	  PolyLineZ	
  features	
  used	  as	
  terrain	
  elevation	
  constraint	
  lineal	  (AHGT	
  is	
  true)	
  into	  a	
  uniformly	
  sampled	
  terrain	
  elevation	
  dataset.	
  First,	
  the	  PolyLineZ	
  feature	
  is	
  broken	
  into	
  a	
  series	  of	
  constraint	
  lines.	
  The	
  application	
  of	
  each	  constraint	
  lineal	
  L	
  is	
  very	  much	  like	  drawing	
  an	
  anti-­‐aliased	
  line	  centered	
  on	
  L	
  into	  the	
  uniform	
  terrain	
  elevation	
  grid.	
  	  	  The	
  width	
  of	
  the	
  line	  is	
  defined	
  by	
  feature	
  attribute	
  WGP.	
  	
  Consider	
  a	
  terrain	
  grid	  element	
  A	
  in	
  the	
  immediate	
  vaccinity	
  of	
  a	
  constraint	
  lineal	
  L,	
  defined	
  by	
  vertices	
  V1	
  
and	
  V2.	
  After	
  applying	
  the	  constraint	
  lineal	
  L	
  to	
  terrain	
  grid	  element	
  A,	
  the	  new	
  elevation	
  𝐸𝐸   is:	  	
  where…	  𝐸𝐸    =    𝐸𝐸 ∗ 𝐴𝐴𝐴𝐴𝐴𝐴 +    𝐸𝐸 ∗    𝐴𝐴𝐴𝐴𝑢𝑢𝑢𝑢   	
  © 2015 Open Geospatial Consortium

17

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
𝐸𝐸 	
  is	
  elevation	
  of	
  grid	  element	  A	
  𝐸𝐸 	  is	
  interpolated	
  elevation	
  of	
  constraint	
  lineal	
  L	
  at	
  grid	  element	
  A	
  𝐴𝐴𝐴𝐴𝐴𝐴 	
  is	
  the	  percentage	
  overlap	
  of	
  constraint	
  lineal	
  L	
  onto	  grid	  element	
  A	
  𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 	
  =	
   1   −    𝐴𝐴𝐴𝐴𝐴𝐴 	
  

	
  

AinLA

WGP

V1

A
V2

Figure A-8: Application of Constraint Line - Uniformly-Sampled Terrain© 2015 Open Geospatial Consortium

18

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

A.6.3

Constraint ArealsThis	
  section	
  describes	
  the	
  required	
  client-­‐device	
  behavior	
  of	
  PolygonZ	
  and	  MultiPatch	
  features	
  
used	
  as	
  terrain	
  elevation	
  constraint	  points	
  (AHGT	
  is	
  true)	
  into	  a	
  uniformly	
  sampled	
  terrain	
  elevation	
  dataset.	
  Each	
  ShapeFile	  PolygonZ	
  feature	
  consists	
  of	
  a	
  number	  of	
  rings	  (or	  parts).	
  	
  Each	  ring	  is	
  a	
  closed	
  (the	  first	  vertex	
  is	
  
same	
  as	
  the	
  last	  vertex),	
  non-­‐self-­‐intersecting	
  loop.	
  	
  A	
  
PolygonZ	
  feature	
  may	  contain	
  multiple	
  outer	  rings.	
  	
  A	
  
sequence	
  of	
  rings	
  can	  describe	  a	
  convex	
  or	
  concave	
  feature	
  outline.	
  	
  	
  	
  In	
  the	
  CDB	
  specification,	
  rings	
  can	
  only	  be	
  made	  up	
  of	
  triangles.	
  	
  	
  	
  	
  
Each	
  ShapeFile	
  MultiPatch	
  feature	
  consists	
  of	
  a	
  number	  of	
  rings	  (or	  parts).	
  	
  Each	  ring	  is	
  a	
  closed	
  (the	  first	  vertex	
  is	
  
same	
  as	
  the	
  last	  vertex),	
  non-­‐self-­‐intersecting	
  loop.	
  	  A	
  sequence	
  of	
  rings	
  can	  describe	  a	
  convex	  or	
  concave	
  feature	
  outline.	
  While	  the	
  ShapeFile	
  MultiPatch	
  feature	
  permits	  multiple	
  inner	  rings	
  (aka	
  parts),	
  this	  capability	
  is	
  dis-­‐allowed	
  in	
  CDB.	
  	
  Furthermore,	
  rings	
  can	
  only	  be	
  made	
  up	
  of	
  
triangles.	
  The	
  rendering	
  of	
  the	
  ShapeFile	
  feature	
  is	
  handled	
  as	
  a	
  series	  of	
  constraint	
  triangles	
  applied	
  in	
  
the	
  order	
  in	
  which	  they	  appear	
  within	
  the	
  ShapeFile	  PolygonZ	
  record.	
  	
  The	
  application	
  of	
  each	  constraint	
  triangle	
  T	
  is	
  very	  much	  like	  drawing	
  an	
  anti-­‐aliased	
  triangle	
  into	  the	
  uniform	
  terrain	
  elevation	  	
  grid.	
  	  	  Consider	
  a	
  terrain	
  grid	  element	
  A	
  in	
  the	
  immediate	
  vaccinity	
  of	
  a	
  constraint	
  triangle	
  T,	
  defined	
  by	
  vertices	
  V1,	  V2	  and	
  V3.	
  After	
  applying	
  the	  constraint	
  triangle	
  T	
  to	
  terrain	
  grid	
  element	
  A,	
  the	  new	
  elevation	
  𝐸𝐸   is:	  	
  where…	  𝐸𝐸    =    𝐸𝐸 ∗ 𝐴𝐴𝐴𝐴𝐴𝐴  +    𝐸𝐸 ∗    𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴   	
  

𝐸𝐸 	
  is	
  elevation	
  of	
  grid	  element	  A	
  𝐸𝐸 	  is	
  interpolated	
  elevation	
  of	
  constraint	
  triangle	
  T	
  at	
  grid	  element	
  A	
  𝐴𝐴𝐴𝐴𝐴𝐴  	  is	  the	  percentage	
  overlap	
  of	
  constraint	
  lineal	
  T	
  onto	  grid	  element	
  A	
  

	
  

𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 	
  =	
   1   −    𝐴𝐴𝐴𝐴𝐴𝐴  	  © 2015 Open Geospatial Consortium

19

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

AinTA
V1

A
V2

V3
Figure A-9: Application of Constraint Triangle - Uniformly-Sampled Terrain

A.7

Guideline: Applying Constraints to Non-Uniform Gridded TerrainThe	
  following	
  sub-­‐sections	
  describe	
  the	
  rendering	
  of	
  point	
  ,	
  lineals	
  and	  areals	
  into	  a	
  Non-­‐
Uniformly	  Gridded	
  Terrain	
  Elevation	
  dataset	
  described	
  in	
  addendum	
  “CDB	  Specification	  Addendum	
  –	
  Non-­‐Uniform	
  Sampled	
  Terrain	
  Elevation”	
  Note	
  that	  the	
  rendering	
  outcome	
  into	  the	  Elevation	
  dataset	
  may	
  vary	  depending	
  on	
  the	  rendering	
  order	  of	
  overlapping	
  points,	
  lines	  or	
  areals.	
  	
  The	  Layer	
  Priority	
  Number	
  (LPN)	
  attribute	
  is	
  used	  to	
  achieve	
  deterministic	
  outcome	  by	
  all	  types	
  of	
  client-­‐devices.	
  	
  When	  ECP	  is	
  supplied,	
  client-­‐devices	
  are	
  required	
  to	
  sort	  overlapping	
  constraint	  points,	
  lineals	
  and	  areals	
  in	
  low-­‐to-­‐high	
  order	  and	  then	  render	  them	  in	
  that	  order.	
  	
  	
  Value	
  of	
  LPN	
  can	
  range	
  from	  0-­‐32767.	
  	
  	
  

© 2015 Open Geospatial Consortium

20

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014The	
  rendering	
  of	
  a	
  point,	
  a	
  lineal	
  or	
  areal	
  features	
  into	  the	
  Non-­‐uniformly	
  Sampled	
  Terrain	  Elevation	
  dataset	
  is	
  performed	
  into	  the	
  same	  LOD	  as	
  the	
  LOD	  in	
  which	  the	
  vector	  feature	
  appeared.	
  	
  

A.7.1

Constraint PointsThis	
  section	
  describes	
  the	
  required	
  client-­‐device	
  behavior	
  for	  PointZ	
  and	  MultiPointZ	
  features	
  
used	
  as	
  terrain	
  elevation	
  constraint	  points	
  (AHGT	
  is	
  true)	
  into	
  a	
  non-­‐uniformly	
  sampled	
  terrain	
  elevation	
  dataset.	
  	
  
The	
  application	
  of	
  a	
  constraint	  point	
  P	
  is	
  applied	
  as	
  follows:	
  1. The	   x,y	   address	
   of	
   the	   affected	
   terrain	
   grid	
   element	
   is	
   computed	
   by	
   truncating	  the	
  lat-­‐long	
  coordinates	
  of	
  point	
  P;	
  note	  that	  the	
  truncation	  operation	
  varies	  in	
  accordance	
   to	
   LOD	   of	
   the	   terrain;	
   however,	
   it	   always	
   yields	
   grid	
   element	
  addresses	
  in	
  the	
  range	
  of	
  0-­‐1023.	
  2. The	  x,y	
  offset	
  of	
  the	
  affected	
  terrain	
  grid	  element	
  is	
  computed	
  by	
  performing	
  a	
  
MOD	
  of	
  	
  the	
  lat-­‐long	
  coordinates	
  of	
  point	
  P	
  in	
  accordance	
  to	
  its	
  LOD.	
  © 2015 Open Geospatial Consortium

21

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

P

Vertices	  of	
  terrain	
  gridConstrain	  point

Figure A-10: Application of Constraint Point – Non-uniform Grid

A.7.2

Constraint LinealsThis	
  section	
  describes	
  the	
  required	
  client-­‐device	
  behavior	
  for	  PolyLineZ	
  features	
  used	  as	
  terrain	
  elevation	
  constraint	
  lineal	  (AHGT	
  is	
  true)	
  into	
  a	
  non-­‐uniformly	
  sampled	
  terrain	
  elevation	  dataset.	
  First,	
  the	  PolyLineZ	
  feature	
  consisting	
  of	
  n	
  vertices	
  is	
  broken-­‐down	
  into	  (n-­‐1)	
  line	  segments	
  defined	
  by	
  successive	  pairs	  of	  vertices.	
  	
  
The	
  application	
  of	
  a	
  constraint	
  line	  segment	
  L	
  is	
  applied	
  as	
  follows:	
  © 2015 Open Geospatial Consortium

22

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
1. The	  x,y	
  offsets	
  of	
  the	
  grid	  elements	
  of	
  each	  vertex	   are	   computed.	
   (see	   application	
   of	  constraint	
   points	
   into	
   non-­‐uniformly	
  sampled	
  terrain	
  (case	  1).	
  2. The	  offsets	
  of	
  all	  of	
  the	
  other	  grid	  elements	
  that	
  are	
  intersected	
  by	
  the	
  line	  segment	
  are	
  handled	
   in	
   accordance	
   to	
   the	   illustration	  shown	
  here.	
  (case	  2	
  to	
  Case	
  5	
  	
  

© 2015 Open Geospatial Consortium

23

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

V1
V2

V3

Vertices	  of	
  terrain	
  gridConstrain	  Line	  Vertex
Constrain	  Line	  Vertex

Figure A-11: Application of Constraint Lineal – Non-uniform Grid

A.7.3

Constraint arealsThis	
  section	
  describes	
  the	
  required	
  client-­‐device	
  behavior	
  of	
  PolygonZ	
  and	  MultiPatch	
  features	
  
used	
  as	
  terrain	
  elevation	
  constraint	  points	
  (AHGT	
  is	
  true)	
  into	
  a	
  non-­‐uniformly	
  sampled	
  terrain	
  elevation	
  dataset.	
  Each	
  ShapeFile	  PolygonZ	
  feature	
  consists	
  of	
  a	
  number	
  of	
  rings	  (or	  parts).	
  	
  Each	  ring	  is	
  a	
  closed	  (the	
  first	  vertex	
  is	
  same	  as	
  the	
  last	  vertex),	
  non-­‐self-­‐intersecting	
  loop.	
  	  A	  PolygonZ	
  feature	
  may	  contain	
  multiple	
  outer	  rings.	
  	
  A	  sequence	
  of	
  rings	
  can	  describe	  a	
  convex	
  or	
  concave	
  feature	
  outline.	
  	  In	  the	
  CDB	
  specification,	
  rings	
  can	
  only	  be	
  made	  up	
  of	
  triangles.	
  © 2015 Open Geospatial Consortium

24

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Each	
  ShapeFile	
  MultiPatch	
  feature	
  consists	
  of	
  a	
  number	  of	
  rings	  (or	  parts).	
  	
  Each	  ring	  is	
  a	
  closed	
  (the	  first	  vertex	
  is	
  
same	
  as	
  the	
  last	  vertex),	
  non-­‐self-­‐intersecting	
  loop.	
  	
  A	
  
sequence	
  of	
  rings	
  can	  describe	  a	
  convex	
  or	
  concave	
  feature	
  outline.	
  While	  the	
  ShapeFile	
  MultiPatch	
  feature	
  permits	  multiple	
  inner	  rings	
  (aka	  parts),	
  this	  capability	
  is	
  dis-­‐
allowed	  in	
  CDB.	
  	
  Furthermore,	
  rings	
  can	
  only	  be	
  made	
  up	
  of	
  
triangles.	
  The	
  application	
  of	
  a	
  constraint	
  triangle	
  T	
  is	
  applied	
  as	
  follows:	
  

	
  

	
  

1. The	  x,y	
  offsets	
  of	
  the	
  grid	  elements	
  of	
  each	  vertex	  are	
  computed.	
  (see	  application	
  of	
  constraint	  points	
  into	
  non-­‐uniformly	
  sampled	
  terrain	
  (case	  1). 	  2. The	   x,y	   offsets	
   of	   all	   the	   other	
   grid	  elements	
   that	   are	   intersected	
   by	
   the	   line	  segments	
  are	
  handled	
  in	
  accordance	
  to	
  the	
  illustration	
  shown	
  here.	
  (case	  2	
  to	
  Case	  5)	
  3. The	   x,y	   offsets	
   of	   all	   the	   other	
   grid	  elements	
   elevation	
   are	   set	   to	   0	   and	   the	  elevation	
   at	
   that	   lat-­‐long	
   is	
   interpolated	
  using	   	
   the	   elevation	
   at	
   the	   triangle’s	
  vertices.	
  

	
  
	
  
	
  
	
  
	
  

© 2015 Open Geospatial Consortium

25

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

V1
V2

V3

Vertices	  of	
  terrain	  Constrain	  Triangle	
  Vertex
Constrain	  Triangle	  Outline

Figure A-12: Application of Constraint Areal – Non-uniform Grid

A.8
Guideline: LOD Read Behavior of Subordinate Datasets
In version 3.1 of the CDB Specification, LOD read behavior of subordinated datasets was
mentioned only briefly in…
Section 5.2.1.2.3 Subordinate Terrain Elevation Components: which stated “TheCDB Specification does not permit the use of subordinate Terrain Elevation
component when the primary Terrain Elevation component is not generated.”
Section 5.2.1.3.4 Default Read Value: which stated “Simulator client-devices
should assume … if the data values are not available (files associated with the
Subordinate Terrain Elevation component for the area covered by a tile, at a given
LOD or coarser, are either missing or cannot be accessed).

© 2015 Open Geospatial Consortium

26

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Section 5.2.1.6 Subordinate Bathymetry Component: which stated “Furthermore,since the Bathymetry values are relative to Terrain Elevation component, eachvalue in the Bathymetry component must be matched to the finest available LOD
elevation values of the Terrain Elevation component”.
Section 5.2.1.7.3 Default Read Value: which stated “Simulator client-devices
should assume … if the data values are not available (files associated with the
Subordinate Terrain Elevation component for the area covered by a tile, at a given
LOD or coarser, are either missing or cannot be accessed).
Section 5.2.2.3.2 Default Read Value: which stated “Simulator client-devices
should assume … if the data values are not available (files associated with the
Subordinate Terrain Elevation component for the area covered by a tile, at a given
LOD or coarser, are either missing or cannot be accessed).
This guideline provides clarification on the client-device LOD read behavior of subordinateddatasets; it describes the mandated behavior of a simulator client-device when reading a LOD ofa Primary Elevation Component and combining it with another LOD of a Subordinate Terrain
Elevation Component
Consider the case where a simulator client-device is attempting to read CDB data for a given
region of the CDB at LOD = p. The CDB region has a Primary Elevation Component populatedwith data ranging from LOD = -10 to LOD = m, and a Subordinate Elevation Component
populated with data ranging from LOD = -10 to LOD = n.

The required client-device read behavior is illustrated in Figure A-13 below, and can besummarized as follows:
For -10 ≤ p ≤ m, the client-device accesses the primary elevation data at LOD = p.
For p > m ≥ -10, the client-device accesses the primary elevation data at LOD =m.
For -10 ≤ p ≤ n, the client-device accesses the subordinate elevation data at LOD= p.
For p > n ≥ -10, the client-device accesses the primary elevation data at LOD = n.
For p > m and p < n and m < n, the client-device interpolates the primaryelevation data from LOD = m to LOD = p before combining it with thesubordinate elevation data of LOD = p.
For p > m and p > n and m < n, the client-device interpolates the primaryelevation data from LOD = m to LOD = n before combining it with thesubordinate elevation data of LOD = n.

© 2015 Open Geospatial Consortium

27

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
For p < m and p > n and m > n, the client-device interpolates the subordinate
elevation data from LOD = n to LOD = p before combining it with the primaryelevation data of LOD = p.
For p > m and p > n and m > n, the client-device interpolates the subordinate
elevation data from LOD = n to LOD = m before combining it with the primaryelevation data of LOD = m.
For n = φ (unavailable) and p > m ≥ -10, the client-device accesses the default
value in Defaults.xml for the subordinate elevation data.
The combination of (m = φ (unavailable) and n ≥ -10), is not permitted, i.e., thegeneration of Subordinate Terrain Elevation LODs is not permitted if the Primary
Terrain Elevation component have not been generated.
If the default value for the Primary Elevation dataset is unavailable in
Defaults.xml, or if Defaults.xml file is missing, then the client-device must revert
to the client-device’s internal default value for this dataset.
If the default value for the Subordinate Elevation dataset is unavailable in
Defaults.xml, or if Defaults.xml file is missing, then the client-device must revert
to the client-device’s internal default value for this dataset.

Figure A-13: Client-device Read Behavior© 2015 Open Geospatial Consortium

28

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

The default value for the Primary Terrain Elevation component is the constantPrimary_Elevation, which can be found in \CDB\Metadata\Defaults.xml. The CDB
Specification recommends that the value for Primary_Elevation = 0. In the case where thedefault value cannot be found within the Defaults.xml file, or that the Defaults.xml file cannot befound, the CDB Specification recommends that client-devices internally generate a default valueof Primary_Elevation = 0.
The default values for the Subordinate Terrain Elevation layer “n” (where “n” is the subordinate
elevation layer number, e.g., a value from 2 to 99) is the constant Subordinate_Elevation-n,which can be found in \CDB\Metadata\Defaults.xml. The CDB Specification recommends thatthe value for Subordinate_Elevation-n = 0. In the case where the default value cannot be foundwithin the Defaults.xml file, or that the Defaults.xml file cannot be found, the CDB Specification
recommends that client-devices internally generate a default value of Subordinate_Elevation-n =0.
The CDB Specification does not permit the use of Subordinate Terrain Elevation components
when the Primary Terrain Elevation component is not generated.
A.9
Clarification: Publisher Considerations
The CDB specification does not provide guidelines regarding its implementation within vendor
SE toolsets and vendor simulation architectures. This clearly falls outside of the CDB
specification mandate. Like other standards such as SIF and SEDRIS, the CDB Specification issolely a data schema for Synthetic Environmental information (i.e., it merely describes data) for
use in simulation.
However, unlike SIF and SEDRIS, the CDB data schema lends itself to a real-time
implementation within simulation architectures. As a result of this greater capability, many
vendors have opted to achieve real-time capability with the CDB (CDB used as a runtime
repository). This capability requires that the vendor’s client-device be adapted with a Run-Timepublishing (RTP) software function which transforms the CDB data into the client-device’s
internal legacy/proprietary format. This is a new concept for the simulation industry andconsequently there is considerable confusion regarding the implementation of Off-line and Runtime Publishers (RTPs). While much of the attention has focused on RTPs, a similar set of
considerations apply to the implementation of an off-line CDB capability (CDB is used as a
Refined Source Data Repository). In this latter case, the capability requires that the vendor
develop an off-line CDB import function which ingests the CDB into his Synthetic Environment
Creation toolset; once imported, the toolset produces (as always) the vendor’s proprietary data
format through an off-line compilation function.
By definition, the function of an RTP is to bridge the “gap” (or adapt) between CDB data schema
and the client-device’s internal (proprietary) data schema. Since this gap is unknown, it is
impossible in this addendum to provide hard-and-fast rules and detailed estimates for the
implementation of an RTP (or a CDB import function).

© 2015 Open Geospatial Consortium

29

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Note that there are many alternatives open to a vendor when considering the level of compliancy
he wishes to achieve. The level-of-effort is essentially a function of the level-of-compliancy thevendor wishes to achieve, and the size of the intrinsic “gap” between the CDB data schema andhis device’s internal schema.
Nonetheless, this section highlights aspects of the CDB that are particularly significant when
considering such implementations. These aspects dominate the level-of-effort required to achieve
ideal CDB compliancy.
The CDB Specification limits itself to a description of a data schema for Synthetic
Environmental information (i.e. it merely describes data) for use in simulation. The CDB
specification provides a rigorous definition of the semantic meaning for each dataset, each
attribute and establishes the structure/organization of that data as a schema comprised of a folder
hierarchy and files with internal (industry-standard) formats. This ensures that the all CDB data
is understood, interpreted and efficiently accessed in the same way by each client-device. The
CDB specification does not include detailed guidelines regarding off-line database compliers or
run-time publisher implementations, since this would be tantamount to dictating internal vendor
formats which are by their very nature proprietary.

The CDB Specification is solely a data schema for Synthetic Environmental
information (i.e. it merely describes data) for use in simulation. Given thismandate, it is entirely platform independent, i.e. it does NOT provide theimplementation details of specific off-line database compilers or runtime
publishers attached to specific client-devices.

As a result the CDB specification DOES NOT provide:[ The implementation details of an off-line CDB import function that can then be
used to compile the imported Synthetic Environmental data into one or more typesof proprietary runtime databases (only the client-device vendor has thisknowledge and control)[ The implementation details or algorithms of runtime publishers attached to
specific client-device (only the client-device vendor has this knowledge andcontrol)[ The implementation details or algorithms of client-devices that use CDB data
(only the client-device vendor has this knowledge and control)© 2015 Open Geospatial Consortium

30

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
While the CDB specification does not govern the actual implementation ofclient-devices, it is expected that the CDB specification will have a “unifying”
effect on the implementation of each vendor’s client-device by virtue of the factthat they will share the exact same Synthetic Environmental data. It is expectedthat side-by-side comparisons will be easier to undertake due to the fact thatdevices will run off the exact same runtime data. Prior to the advent of the CDB
specification, side-by-side comparisons were considerably more difficult toundertake due to the fact the entire SE creation chain starting from raw source
was implicated in such evaluations.

If we set aside legacy considerations, the simplest approach to adopting the CDB would requirethat client-devices ingest the CDB natively, i.e., client-devices would handle all of the CDB data
schema/semantics without any off-line or run-time intermediary.
In practice however, most vendors have extensive legacy SE assets and cannot afford to
obsolesce these. As a result, most client-devices must continue to support their own proprietary
legacy runtime databases. Given these considerations, two solutions are possible:a) No change to the Client-device: In this approach, vendors have chosen toachieve an off-line CDB capability (CDB is used as a Refined Source Data
Repository). This capability requires that the vendor develops an off-line
CDB import function which ingests the CDB into his Synthetic Environment
Creation toolset; once imported, the toolset produces (as always) the vendor’s
proprietary data format through an off-line compilation function.

b)

Insertion of a Runtime Publisher: In this approach, vendors have opted toachieve real-time capability with the CDB (CDB is used as a runtime
repository). This capability requires that the vendor’s client-device beadapted with a Run-Time publishing (RTP) software function whichtransforms the CDB data into the client-device’s internal legacy/proprietary
format.

A.9.1
Level-of-Effort of a Publisher Implementation
The following discussion attempts to qualify the level-of-effort to achieve CDB compliancy.
The discussion applies equally to both paradigms, i.e., the CDB Runtime Publishing paradigm
and the CDB import-then-compile paradigm.
In the case where a client-device already supports most of data schema and semantics conceptsof the CDB, then the RTP (or import-then-compile) software is proportionally less complex. For
instance, if an IG already supports the concepts of tiles, of levels-of-detail, of layers andunderstands the concepts of datasets such as terrain texture, gridded terrain elevation, gridded
terrain materials, etc. then there is a modest amount of work to be performed by an RTP.

© 2015 Open Geospatial Consortium

31

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The level-of-effort in adopting the CDB data schema is proportion to thedifference between the CDB data schema and client-device’s internal
proprietary data schema.

Clearly, the algorithmic complexity of an RTP and the computational load imposed on the RTP
is directly proportional to the above-mentioned “gap”. The larger the “gap”, the more expensive
a RTP is to develop and the more computational resources need to be allocated to implement it.
Conversely, with a smaller “gap”, the RTP development is straightforward and relatively few
computational resources need to be allocated to this function.
In order to assess the level-of-effort to adopt the CDB schema, the vendor must first evaluate thesimilarity of data schemas between the CDB and his client-device, in particular, he must assess
whether he espouses the following fundamental CDB concepts:v Independent Tiles (used for paging of all SE data)v Independent Levels-of-Detail (for all SE data)v Independent Layers (Dataset Layering)v Following dataset concepts and semantics:
Ø Semantic understanding of all CDB layers
Ø Geo-gridded data layers consisting of terrain altimetry, terrain texture, terrainmaterials/mixturesØ Geo-defined vector features (points, lineals, areals)
With/without modeled 3D representations
Feature attributionØ 3D Modeled representation of features (using a data schema similar to or
equivalent to OpenFlight)
Instanced geotypical models
Instanced model geometry
Instanced model texture
Non-instanced geospecific modelsØ Conforming of features to terrain skin (e.g. height conforming)Ø Topological networksØ JPEG-2K compression
Ø Generation of device-specific NVG/FLIR rendering parameters for lightpoints and materials© 2015 Open Geospatial Consortium

32

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In the case where a client-device does not intrinsically support one or more of
the above-mentioned CDB concepts, the RTP must perform SE conversions
that will likely fall beyond those of mere format/structure manipulations. Such
conversions may affect the precision of the data, its semantic meaning, etc, andthus can compromise certain aspects of runtime correlation.

The CDB data schema favors modern up-to-date implementations of client-devices. In effect,
the level-of-effort to develop an RTP for an obsolete legacy device is likely to be greater than fora modern device. This is because early approaches in digital computer based flight simulation
were more severely constrained by severe hardware, software and data source limitations.
Consequently, simulation engineers made important compromises between a subsystem’s
targeted fidelity and its level of generality, scalability, abstraction, and correlation with othersimulator client-devices. In many cases, engineers reverted to complex support data structures(generated off-line) in order to reduce the computational load at runtime.
A classic example of this was the use of Binary Separation Planes (BSPs) data structures2
which were required prior to the widespread adoption of Z-buffers by the IG vendors. The CDB
specification does not make provisions for this and as such, the RTP for legacy BSP-based IG
devices would be burdened with the rather difficult task to generate BSPs in real-time.
Given their tremendous benefit, the concepts of database paging (e.g. tiles) and levels-of-details
have steadily been adopted by simulation vendors over the past 15-20 years and have been
applied to most datasets, notably terrain and imagery datasets. (See Appendix “A” of the CDB
Specification for a rationale for Tiles and Levels-of-detail). As a result, it is not expected that the
CDB tiles and LOD concepts will be a problem for most vendors. Note however that CDB
applies these two concepts to ALL dataset layers including vector features and 3D models.

A.9.2
Typical Functions Performed by a Publisher Implementation
The following discussion provides a typical list of software functions that must be developed inorder to achieve CDB compliancy. The discussion applies equally to both paradigms, i.e. the
CDB Runtime Publishing paradigm and the CDB import-then-compile paradigm.
Virtually all simulation client-devices in existence today natively ingest their own proprietarynative runtime formats. In order to ingest CDB directly, vendors must adapt the device’s
software to natively ingest the CDB format (e.g. TIFF, Shape, OpenFlight, etc.) or alternately, he
can insert a runtime publisher function that transforms the CDB data formats 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.
2

Such BSP data structures where required by most IG vendors prior to ~1995 due to the fact that the IGs did nothave sub-pixel level Z-buffer capability.

© 2015 Open Geospatial Consortium

33

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The runtime publishers are nothing more than well-optimized offline database publishers capableof responding to the on-demand compilation of datasets as they are being paged-in by therespective client devices. The function of a runtime publisher is no different than that of aconventional offline database publisher, i.e., it…
a) transforms the assembled database so that it satisfies the client-device’s
internal data structure and formatb) transforms the assembled database so that it satisfies the client-device’s
internal naming conventionsc) transforms the assembled database so that it satisfies the client-device’s
number precision and number representationd) transforms the assembled database into parameters compatible with the client
device’s internal algorithms (typically light parameters, FLIR/NVG
parameters, etc.
e) transforms the assembled database so that it satisfies the client-device’s data
fidelity requirementsf) transforms the assembled database so that it satisfies the client-device’s
performance and internal memory limitationsg) transforms the assembled database so that it satisfies the client-device’s level
of-detail representation requirements.

Ideally, the scope of an RTP should be purely limited to manipulations of data
format and data structure and internal naming conventions (items 1-7 above).
Under such circumstances, it is possible to achieve perfect runtime correlation
between client-devices.

A.9.3
Publisher Implementation Recommendations
The use of the CDB data schema “as-is” by a client-device achieves all of the benefits stated in
sections 1.4 and 1.5 of the CDB specification, namely:a) Improved SE generation timeline and deploymentb) Interoperable simulation-ready SEc) Improved client-device robustness/determinismd) Increase SE longevitye) Reduced SE storage infrastructure costf) Platform independence and scalabilityg) SE scalability and adaptability© 2015 Open Geospatial Consortium

34

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In the case where a client-device does not adhere to one or more of the above-mentioned“fundamental CDB concepts”, fewer of the CDB benefits will be realizable.
For instance, a client-device incapable of dealing with levels-of-detail will not have the samelevel SE scalability (a benefit explained in section 1.4.7 of the CDB specification) as one thatfully espouses that concept. While the latter may be acceptable, it is clearly a less-compliant andan inferior implementation of the CDB than the former.
Changes to the modeled representation of features are generally not advisable since it invariably
affects the accuracy of the modeled representation. Most image generators in use today caningest a (one-for-one correspondence) the CDB modeled polygonal representation of 3Dfeatures. However, in the case of terrain, there are two dominant approaches in industry, either aregular grid with LODs or alternately, the Terrain Irregular Network (TIN) mesh. The CDB
specification has opted for the former given its greater scalability, determinism and compatibility
with tiling schemes. Clearly, implementations where such conversions are not necessary areadvantaged and provide more of the above-mentioned CDB benefits.
Furthermore, the CDB is designed to provide both the semantic (e.g. vector data/attribution) andthe modeled representation of features. Since the CDB specification provides both, it is notadvisable to ignore or replace the modeled representation (if provided) nor is it advisable tosynthesize a non-CDB modeled representation if none was supplied within the CDB. While the
CDB specification does not forbid vendors to interpret CDB feature data for the purpose ofprocedurally synthesizing more detailed feature data or synthesizing modeled data from thefeature data, this practice is not recommended as this would severely compromise correlationand inter-operability. In the context of correlated synthetic environments, such approaches are
viable if and only if all client-devices in a federation are equipped with the exact sameprocedural algorithms. Currently, this is not possible because there are no industry-standard,
open-source procedural algorithms endorsed by all simulation vendors.
In the case of the CDB Runtime Publishing paradigm and the CDB import-thencompile paradigm, it is not advisable to ignore or replace the modeled
representation (if provided) nor is it advisable to synthesize a non-CDB modeled
representation if none was supplied within the CDB.

A.10
Rationale: Sensor Simulation - Achieving Device-Independence
One of the primary objectives of this Specification is to provide and integrate all of the datarequired by all sensor devices, not just Image Generators producing the OTW scenes. The
purpose of this integration, among other things, is to achieve and maintain a high level ofcorrelation among the many client-devices (subsystems) within a simulator. Furthermore, thisintegration must be done independently of the client-device or the sensor type, with little or no
duplication of data amongst clients. In addition to the OTW, many simulator client-devices are
required to simulate the synthetic environment over different portions of the electromagnetic
spectrum, infrared (e.g. FLIR, NVG), microwaves (e.g. radar), audio (e.g. sonar), etc. Up tonow, the current state of the art approaches to the simulation of sensors has typically been quite© 2015 Open Geospatial Consortium

35

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
proprietary to the client-device implementation of the various vendors. There have been nouniversally accepted simulation models suitable for use in simulation.
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). In
the past, the SEM relied heavily on environmental database whose content was designed tomatch the functionality, fidelity, structure and format requirements of the SEM. The level ofrealism possible by the SEM depended heavily on the quality, quantity and completeness of thedata available. The environmental database was highly device-specific and could not be readily
ported to other platforms.
A SEM is usually based on mathematical model of the environment for the portion of theelectromagnetic spectrum of interest. The SEM acts much as a black box that produces a
response in accordance to input data. A significant portion of this data must come from the
CDB; however, the key is to segregate all device-dependent data and all SEM-dependent datafrom the modeling data that represents the synthetic environment. In order to accommodate themost different kind of sensors possible, a common denominator must be chosen. In the CDB
specification, this common denominator is called a material. This is the subject of this chapter.
One of the fundamental issues of sensor simulation involves the handling of material properties.
As discussed earlier, the determination of which material properties should be supported heavily
depends on:a) the sensor types to be supported.

b) the vendors’ sensor simulation implementations to be supported.

c) the level of fidelity, functionality and precision of the SEMs to be supported.
Clearly, the task of determining a definitive list of material properties that would accommodate
all of the above requirements for the today’s sensor types, vendor implementations and SEMs
would be a significant challenge. Furthermore, once released, the materials properties would
limit any SEM innovation by the industry. As a result, the CDB specification limits its
jurisdiction over the material properties.
Instead, the CDB specification defines and publicly defines a list of materials that can be used ina CDB. It is the responsibility of each vendor to define the properties (that satisfies the sensortype) for these CDB materials. As a result, vendors are totally free to select material properties
that satisfy the fidelity, functionality and precision requirements of the SEM for the sensor typeof interest. Alternately, if the vendors have their own list of materials, they can create a mapping
between CDB materials and their internally supported list of materials. This approach allows
client-devices to retain their SEMs as well as their own sets of material properties.
The next section describes how materials are defined and modeled within a CDB.

© 2015 Open Geospatial Consortium

36

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Appendix L enumerates the base materials supported by this Specification.

A.11
Rationale: Partitioning the Earth into Tiles
This section provides rationale for partitioning the world into tiles.
The design of the CDB specification tile representation is centered on three primaryconsiderations:(1)

A tile representation comprehensive enough to accommodate the entire earth.

(2)

A tile representation that lends itself to real-time implementation by a CDB
system and all of its attached simulator client-devices.
A numerically straightforward mapping (such as a simple scaling) to map latlong coordinates into CDB coordinates and vice versa is highly desirable forreal-time implementation considerations.

(3)

A tile representation with a system of units that conforms as much as possible
to geographic standards.
One of the underlying motivations driving the CDB tile representation is theneed for a system that will remain as close to the raw source data as possible
which currently is DTED and GeoTIFF; DTED uses a geographic coordinate
system defined by latitudes and longitudes. The basic unit in DTED is a geocell, which always has a height and width of one degree. In order to maintaina density of data that does not increase inordinately when moving towards thepoles, the grid post intervals (measured in degrees or arc-sec) along thelongitudinal axis are increased at specific latitudes; for instance, at DTED
level 2, the latitude interval is always one second of arc but the longitudeinterval is one second of arc at latitudes from 0 to 50 degrees, from latitudes
50 to 70 the interval is two arc seconds and so on as shown in Table A-3.
INTERVALS FOR DTED LEVEL 2.

Table A-3. INTERVALS FOR DTED LEVEL 2
DTED Latitude Range Latitude Interval Longitude Interval
Zone(Degrees)(Arc seconds)(Arc seconds)
I
0 – 50 N-S
1
1
II
50 – 70 N-S
1
2
III
70 – 75 N-S
1
3IV
75 – 80 N-S
1
4© 2015 Open Geospatial Consortium

37

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

80 – 90 N-S

1

6

Before going into the detailed design of the CDB tile representation, it is worth stating theguiding principles that constrain the approach used by the CDB tile representation:(1)

The earth model is divided (in latitude) into slices.

(2)

The slice’s x-axis is aligned to WGS-84 lines of latitude.

(3)

The slice’s y-axis is aligned to WGS-84 lines of longitude.

(4)

The number of units along the slice’s y-axis for a given level of detail is thesame for all slices.
The earth surface geodetic dimension in arc-second of y-axis units within an
earth slice and in all earth slices is exactly the same, regardless of latitude.

(5)

The geodetic dimension of an x-axis unit in arc-second is constant within azone, but is re-defined at pre-selected latitudes to achieve a greater level ofspatial sampling uniformity in all tiles; this overcomes the narrowing effect ofincreased latitudes on longitudinal distances. The definition of zones in the
CDB is the same as those in DTED (with the exception of the poles).

(6)

The number of units along the slice’s x-axis for a given level of detail is thesame within each zone.

(7)

The number of units along the slice’s y-axis is constrained to a 2n-multiple inall slices.
Many simulator client devices impose constraints related to the run-time useof binary pyramidal structures (such as mip-maps, quadtrees, etc.). A binary
pyramidal structure is simply a collection of two-dimensional arrays; eacharray represents the same content but at successively finer levels of resolution.

© 2015 Open Geospatial Consortium

38

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

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 the conceptof a CDBGeocell, which differs slightly from a DTED Geocell. A DTED cellis always 1 × 1 degrees. In contrast, a CDBGeocell always has a height of
1 degree but has a varying width depending on its latitude. Table A-4. Sizeof CDB Geocell per zone shows the dimensions of a CDBGeocell per zonesof latitude. For instance, in latitude zone 5, which goes from –50 to 50
degrees latitude, a CDBGeocell is 1 × 1 degree, in zone 4 and 6 which goesfrom latitude 50 to 70 degrees the cell size is 1 × 2 degrees. The main reason
to introduce this concept is to maintain a reasonable eccentricity between thesides by trying to keep them as close to a square as possible. Two criteria areused to define the size of a CDB Geocell:(a) A CDBGeocell must contain a whole number of DTED Geocells; in otherwords a CDBGeocell must start and end on a whole degree along thelongitudinal axis. This is done so as to facilitate mapping from
CDBGeocells to DTED Geocells.
(b) The length of the CDBGeocell 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 A-4. Size of CDB Geocell per zone
CDB Latitude Range
CDBGeocell size
Zone
(Degrees)(deg Lat × deg Lon))0
1 X 12–90 lat < –891
1X6–89 lat < –802
1X4–80 lat < –753
1X3–75 lat < –704
1X2–70 lat < –50
5
1X1–50 lat < +50
61x2+50 lat < +70
7
1x3+70 lat < +75
81x4+75 lat < +80
91x6+80 lat < +89
10
1 x 12+89 lat < +90

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

The variable CDBGeocell size in the CDB specification has the following benefit:© 2015 Open Geospatial Consortium

39

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014(a) Reduces the simulator client processing overheads associated with theswitching from one zone to another. (Due to the small number of zones
across the earth.)(b) Reduces the variation of longitudinal dimensions (in meters) to a
maximum of 50%.
(c) Improves storage efficiency.
A.12
Rationale: Importance of Level-of-Details
The availability of LODs for most datasets is critical for real-time performance. Many simulator
client-devices can readily take advantage of an LOD structure because many clients naturally
require less detail with increasing distance away from the simulated ownship position. For
example, the projection of screen pixels (i.e. pixels in an IG image plane) onto near-field terrain
subtends much less area than the projection of screen pixel onto far-field terrain near the horizon;
as a result, much less detail is required at far range. In addition, clients may need to revert to analternate coarser representation if they cannot cope with the paging bandwidths, memory
footprint or computational requirements of finer LODs. This provides a solid basis on whichclient-devices can build paging managers, load management and memory management
algorithms.
The following example illustrates the important performance considerations and the inherent
performance advantage that can be achieved with an LOD structure. Consider a simulator clientdevice, with a capability to display terrain imagery out to 128 km; the imagery is 1m at its finest
available resolution and the simulated ownship is flying at 100 m/s. Under these conditions, andwithout the benefit of an LOD organization (as illustrated in Figure A-15: Paging of Terrain
Imagery without an LOD Structure), the client-device would require access to the imagery at a
rate of ~100 Mpixels/sec. Consider on the other hand the same operating conditions but with theclient-device accessing LOD-organized imagery (as illustrated in Figure A-14: Paging of Terrain
Imagery with an LOD Structure). Furthermore, assume that the client-device only requires 1mimagery for ranges less than 1/2 km, 2m for ranges less than 1km, 4m for ranges less than 2km,
and so on. With the benefit of an LOD structure, the client-device would require access to theimagery at a much lower rate of ~1 Mpixels/sec, reducing access bandwidth by a factor of ~100x
over the non-LOD approach. Clearly, such performance gains cannot be ignored for real-time
applications such as flight simulators, especially when one realizes that access bandwidth
increases as the square of the imagery resolution.
In addition to a reduction in access bandwidth, the LOD structure also benefits simulator clientdevices that have a requirement to dynamically filter the data to control aliasing. In effect, partof the client-device filtering process is relegated to an off-line process.
The CDB specification does not enforce, nor does it specify the type of filter used to compute thedata element values of raster-organized or list-organized datasets. Yet, it is clear that inadequate© 2015 Open Geospatial Consortium

40

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
off-line filter may affect the rendering quality of the affected client-devices. As a result, the
CDB specification provides guidelines to govern the quality of the off-line LOD process; theseguidelines are provided with each of the raster-organized dataset (or list-organized datasets infuture releases of the CDB specification).

Figure A-14: Paging of Terrain Imagery with an LOD Structure© 2015 Open Geospatial Consortium

41

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

Figure A-15: Paging of Terrain Imagery without an LOD Structure

A.13

Primer: Line-of-Sight Algorithms Using MinElevation and MaxElevation
Components
The purpose of the MinElevation and MaxElevation components is to provide the CDB with thenecessary data and structure to achieve the required level of determinism in the computation lineof-sight calculations with the terrain. The values of each component are with respect to meansea level. Since both the MinElevation and the MaxElevation values are provided by thisSpecification, any line-of-sight algorithm can rapidly assess an intersection status of the line-ofsight vector with the terrain.

There are three cases to consider:

1. CASE 1 – No intersection: If all of the LOS Bounding Boxes are above the
MinMax Bounding Boxes, then there is no intersection between the line-ofsight vector and the terrain. No further testing is required. (Refer to Figure
A-16: Case 1 – No Intersection.)© 2015 Open Geospatial Consortium

42

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

Figure A-16: Case 1 – No Intersection

2. CASE 2 – Potential intersection: If one or more of the LOS Bounding
Boxes overlap with a MinMax Bounding Box, then there is a potential
intersection between the line-of-sight vector and the terrain. This step must be
repeated with progressively finer level-of-detail versions of the MinElevationand MaxElevation values until Case 1 or Case 3 is encountered. If the finest
level-of-detail is reached and the LOS result still yields a potential intersection
status (Case 2), then the LOS algorithm must perform a LOS intersection withthe finest LOD of the Primary Terrain Elevation component using theprescribed CDB meshing convention. (Refer to Figure A-17: Case 2 –Potential Intersection.)

Figure A-17: Case 2 – Potential Intersection© 2015 Open Geospatial Consortium

43

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
3. CASE 3 – Intersection: If one or more of the LOS Bounding Boxes are
below the MinMax Bounding Boxes, then there is an intersection between theline-of-sight vector and the terrain. No further testing is required to determine
whether there is intersection or not. (Refer to Figure A-18: Case 3 –Guaranteed Intersection.) However, to determine the intersection point, the
LOS algorithm must perform the following additional steps. If (starting with
the LOS point-of-origin) one or more of the LOS Bounding Boxes overlap
with a MinMax Bounding Boxes, then there is a potential intersection between
the line-of-sight vector and the terrain for that MinMax Bounding Box. This
step must be repeated with progressively finer level-of-detail versions of the
MinElevation and MaxElevation values until Case 1 or Case 3 is encountered.
If the finest level-of-detail is reached and the LOS result still yields a potential
intersection status (Case 2), then the LOS algorithm must perform a LOS
intersection with the finest LOD of the Primary Terrain Elevation component
using the prescribed CDB meshing convention.

Figure A-18: Case 3 – Guaranteed Intersection

A.14
Primer: Radar Cross Sections (RCS)This section provides technical description of the RCS data and its usage in real-time simulation.

The Radar Cross-Section (RCS) of a target is a measure of the radar reflection characteristics ofa target (usually expressed in m2, dBsm, or volts). It is equal to the power reflected back to theradar divided by power density of the wave striking the target. For most targets, the radar crosssection corresponds to the area of the cross section of the sphere that would reflect the sameenergy back to the radar, if a metal sphere were substituted. A sphere is sometimes used since
the RCS of a sphere is independent of frequency if operating in the far field region of the radar.
(Reference [24])© 2015 Open Geospatial Consortium

44

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The RCS data unit of measure for the intensity are usually referenced as a normalized ratio in
Decibels relative to a square meter (reference [25]), or otherwise known as dBsm. Another datameasure that is linked to the intensity measure is also the ‘phase shift’ angle (in degrees) of the
returned energy. It can provide some additional information about the reflective attributes of theelements reflecting back to the radar.

However, the RCS defines the echo at the radar for the model (target) in question, which varies
considerably depending on the target’s orientation, its relative distance and size with respect tothe simulated radar’s antenna. The viewing angles are shown in the diagram below.

Figure A-19: Relative Azimuth (α) and Elevation (φ) Angles

RCS curves are normally produced using highly specialized off-line tools which input the model
geometry and material attributes (typically an OpenFlight file) and applies physics-based
processing like geometric ray-tracing, optical reflections/refractions, corner detection, material
absorption and so on to the geometric data representation of the model. This processing iscomputationally expensive and is usually performed in non real-time. The end-result of thiscomputation (usually 2D arrays of data points in elevation and azimuth) provides data that can beused more efficiently by simulation modeling such as radar at run-time. Those data curves are
stored in a polar-type representation table, which provide specific reflectivity levels given a setof azimuth and elevation aspect angles.
A.14.1
Functional Description
To simulate a target for most modes of operation, the Radar software uses an RCS Polar
Diagram as shown below:© 2015 Open Geospatial Consortium

45

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

Figure A-20: Polar Diagram of RCS data in Decibels at a given elevation angle

The polar diagram allows the radar to use an RCS value array (indexed by azimuth/elevation
angles) for getting an approximation of the overall RCS of distant targets. The approximated
RCS data is a function of the model’s materials, geometry, view angles, and multi-paths
reflections generated within the model itself.

It can also be depicted more linearly as shown in the following diagram:

Figure A-21: Linear Diagram of RCS data in Decibels at a given elevation angle

As it can be seen in the example above, relative intensities are much greater when viewing themodel directly in front (0° azimuth), from the back (±180° azimuth) and on the sides (-90° and+90° azimuth).

© 2015 Open Geospatial Consortium

46

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

The RCS data is often characterized by its data resolution and physical modeling parameters.
The data resolution determines the angular increments between successive RCS values, andmodeling parameters specify the attributes of the physical parameters used to drive the RCS
mathematical model computations (such as the Electro-Magnetic properties of the simulated
electric field).

Both wavelength and polarization affect how a radar system “sees” the elements in the scene.
Therefore, radar using different polarization and wavelength combinations may provide different
and complementary information, which can be used to enhance the radar image in a specificway.
A.14.2
Wave Polarization
When computing an RCS model, it is important to consider microwave energy propagation andscattering, and also the polarization of the radiation, which is an important property. For a planeelectromagnetic (EM) wave, polarization refers to the locus of the electric field vector in theplane perpendicular to the direction of propagation. The length of the vector represents theamplitude of the wave, and the rotation rate of the vector represents the frequency of the wave.
Polarization refers to the orientation and shape of the pattern traced by the tip of the vector.
(Reference [23])Figure A-22: Horizontal and Vertical Polarization of a plane of EM wave

The waveform of the electric field strength (voltage) of an EM wave can be predictable (thewave is polarized) or random (the wave is un-polarized), or a combination of both. In the latter
case, the degree of polarization describes the ratio of polarized power to total power of the wave.
An example of a fully polarized wave would be a monochromatic sine wave, with a single,
constant frequency and stable amplitude.

© 2015 Open Geospatial Consortium

47

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

Many types of radar antennae are designed to transmit and/or receive microwave radiation that iseither horizontally (H) or vertically (V) polarized, or a combination of both. A transmitted waveof either polarization can generate a backscattered wave with a variety of polarizations, thus anequal amount of resulting RCS curves.

Polarization type on either transmission or reception mode can be synthesized by using H and V
components, with a well-defined relationship between them. For this reason, systems thattransmit and receive both of these linear polarizations are commonly used. With these radars,
there can be four combinations of transmit and receive polarizations:

HH - for horizontal transmit and horizontal receive
VV - for vertical transmit and vertical receive
HV - for horizontal transmit and vertical receive, and
VH - for vertical transmit and horizontal receive.

The first two polarization combinations are referred to as “like-polarized” because transmit andreceive polarization types are the same. The last two combinations are referred to as “crosspolarized” because transmit and receive polarizations are orthogonal to one another.
Radar systems can have one, two, or all four of these transmit/receive polarization combinations.
Examples include the following types of radar systems:

Single polarized
Dual polarized
Alternating polarization
Polarimetric

HH or VV (or possibly HV or VH)
HH and HV, VV and VH, or HH and VV
HH and HV, alternating with VV and VH
HH, VV, HV, and VH

Both wavelength and polarization affect how a radar system “sees” the elements in the scene.
Therefore, radar using different polarization and wavelength combinations may provide different
and complementary information, which can be used to enhance the radar image in a specificway.

© 2015 Open Geospatial Consortium

48

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Therefore, polarization information is an important part of the CDB’s RCS Data representation.

A.14.3
Wave Parameters
In addition to the wave polarization explained above, other physical parameters of the modeled
electromagnetic wave are also a contributing factor to the RCS of a target when seen by Radar.
Therefore those parameters are available in conjunction with the RCS data curves:

Those parameters are generally as follows:-

Radar Mode (Continuous wave or Pulsed)-

Radiating Frequency-

Antenna Main Lobe Gain-

Antenna Main Lobe Bandwidth-

Antenna Side Lobe 3dB point-

Radar Pulse width (if pulsed radar mode)-

Radar Pulse Repetition Frequency (if pulsed radar mode)

A.15
Information: Tide Simulation Modeling Alternatives
The availability of a Tide component permits realistic simulation of tides with a minimal
computational overhead by the simulation application. Furthermore, the Tide component also
permits simulation of tides whose amplitude varies differently 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.

Figure A-23: Examples of Ocean Tide Simulation Fidelity in Simulator, illustrates examples of
how tide simulation might be handled. At the low-end of the fidelity spectrum, the tide level(expressed as a value between –100% (average low tide) and 100% (average high tide) could be
provided directly at the simulator’s control console. In a high-end simulation, one could develop
a simulation of the earth’s oceans that takes into account Bathymetry profile of the oceans andthe ephemeris model (particularly moon and sun) as a function of time and date. Regardless of
simulation fidelity, the CDB internal representation facilitates the work of simulation client
devices that are interested in obtaining the shoreline profile and ocean heights.

© 2015 Open Geospatial Consortium

49

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

Figure A-23: Examples of Ocean Tide Simulation Fidelity in Simulator

A.16
Information: Comparison of CDB to FalconView Structure
While the CDB file naming convention and its directory structure are somewhat different fromthat used in FalconView, it is possible to find equivalent files between the two.
The FalconView directory structure contains some metadata describing its content and area
coverage; it has a three level directory structure. The first level “rpf” is a raster product format:
the second level being the dataset such as “gnc” (global navigation chart): and the third level
relates to the zones; all files are under the third level. The file name is eight characters long
followed by a three-character file extension, and the file name portion uses a radix 34 numbering
notation that is based on the position of the frame in the zone as well as revision info and the
producer ID key. The file extension is based on the dataset and the zone. Note that frames areequivalent to CDB tiles.
From information such as a given lat/lon, a given resolution such as one-meter pixel size and thedataset such as global navigation chart, it is possible to generate the corresponding FalconView
file name and its path. Similarly, given a lat/lon, an LOD and a dataset it is possible to generate
a CDB file name and its path. Though not identical in coverage and resolution these two files
should be similar in content for the same dataset.
Note that when given a CDB file name, it is possible to extract the tile position in lat/lon, thedataset it belongs to, and the LOD, even its full path name, i.e. the file name is unique for the© 2015 Open Geospatial Consortium

50

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
entire CDB. This is not the case for FalconView. Since the resolution is not implicit in thename, the file itself must be read to extract this information; the dataset and zone info can beextracted from the file extension. Also note that directories in FalconView can potentially bevery large since all files in a zone reside in the same directory; this is especially true for fineresolutions.
The FalconView directory structure follows the guidelines and conventions specified by MILSTD-2411.
The algorithms used to find file name are given by examples within the MIL-C-89041 Controlled
Image Base (CIB) document; in that document, zones are shown as overlapping. Note that thismay not reflect the manner in which FalconView was implemented; nonetheless this does notaffect the methodology provided in this section.

A.16.1
FalconView Directory structure
In FalconView, a top-level directory contains files that are metadata containing information
about the various datasets and files in the directories.
The FalconView directory structure is as follows:
Falconviewmaps+---covdata

Coverage data|

cgnc.cov

Global Navigation charts|

cjga.cov

Joint Operation Graphics Air|

cjnc.cov

Jet Navigation Chart|

conc.cov

Operational Navigation Chart|

ctpc.cov

Tactical Pilotage Chart|

mm100.cov

1:100,000 maps|

mm250.cov

1:250,000 maps|

sigfile.sig|

trs_8km.cov

Township Range Section|+---rpf

Raster Product Format© 2015 Open Geospatial Consortium

51

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
| +---cgnc

Global Navigation Map| | +---1

Zone

| | |

File Name

00023023.GN1

A.16.2
FalconView Zones definition
MIL-STD-2411 divides the world into 18 zones, nine in the northern hemisphere and nine in thesouthern hemisphere. The first eight zones in both hemispheres are divided into frames, which
in turn are divided into sub-frames. Frames are made of pixels with 1536 x 1536 pixels in aframe; there are 36, 6x6 sub-frames per frame. Between each zone, there is an overlap of one
frame; this implies that the size of zones will vary slightly depending on the resolution that isused. Table A-5 Zones Range No Overlap gives the approximate range of each zones; 1 – 9 in
the north, A - J in the south. The two extreme zones, which cover the north and south poles, usea different scheme and are not discussed here.
Table A-5 Zones Range No Overlap
Zone
Zone Extent

Zone extent

No overlap (deg)No overlap (deg)

1, A

0

32

2, B

32

48

3, C

48

56

4, D

56

64

5, E

64

68

6, F

68

72

7, G

72

76

8, H

76

80

9, J

80

90

A.16.3
FalconView Zone resolution
Along lines of constant longitude, the pixel constant used to determine the size of frames is afunction of the resolution but is independent of the zone. Along lines of constant latitude theconstant is a function of both resolution and zone and is based on the mid latitude of the zone.

© 2015 Open Geospatial Consortium

52

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table A-6 Example Resolution east-west pixel constants that is extracted from MIL-C-89041
enumerates the factors for three resolutions.
Table A-6 Example Resolution east-west pixel constants
Zone

Pixel constant

Pixel constant

Pixel constant(10 meter product)(5 meter product)(1 meter product)

1,A

3,696,640

7,393,280

36,966,400

2,B

3,025,920

6,051,840

30,259,200

3,C

2,457,600

4,915,200

24,576,000

4,D

1,991,680

3,983,360

19,916,800

5,E

1,633,280

3,266,560

16,332,800

6,F

1,372,160

2,744,320

13,721,600

7,G

1,100,800

2,201,600

11,008,000

8,H

824,320

1,648,640

8,243,200

Lat

1,000,960

2,001,920

10,009,600

The north-south or latitudinal pixel constant is the number of pixels from the equator to the pole(90°). The east-west pixel constant is the number of pixels longitudinally from the 180° west
longitude meridian going 360° in an easterly direction along the zone midpoint.

A.16.4
FalconView Zone extension based on resolution
To illustrate, we will use as an example a resolution of 10 meters. To calculate the exact
latitudinal zone extent for a given resolution, first calculate the number of pixels in a degree of1000960
latitude for the resolution N φ == 11121.7777
90
The number of frames needed to reach the nominal zone boundary is the number of pixels per
degree of latitude multiplied by the nominal zone boundary (in degrees), divided by 1536, thenumber of pixels rows in a frame, and rounded up to the nearest integer. For example in the first⎛ 32 N φ ⎞zone the number of frames is Roundup⎜⎜ 1536 ⎟⎟ = 232⎝⎠© 2015 Open Geospatial Consortium

53

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The extent of the zone is then

1536 × 232= 32.0409207
Nφ

In order to find the extent of the next zone we use the following method, which applies to allzones from 2 to 8 or B to H.

Since there is an overlap of one frame the start point of the zone 2 will be

1536 × 231= 31.9028133 the number of frames required to reach the next zone which nominallyNφ⎛ (48 − 31.9028133)N φ ⎞is at 48 is: Roundup⎜⎟⎟ = 117
⎜
1536
⎝
⎠

31.9028133 +and the extent is1536 × 117= 48.0613811
Nφ

The number of longitudinal frames and subframes is computed by determining the number ofsubframes to reach around the earth along a parallel at the zone midpoint. The east-west pixel
constant is divided by 256 pixels to determine the number of subframes. The results are divided
by 6 and rounded up to obtain the number of frame columns.

⎛ 3696640 ⎞⎟ = 14440 subframes and⎝ 256 ⎠For example longitudinally in the first zone we get Roundup⎜⎛ 14400 ⎞Roundup⎜⎟ = 2407 frames. Table A-7 Frame/Subframe Sizes for Source Image GSD of⎝ 6 ⎠

10 Meters, shows the complete set for a resolution of 10 meters.

Table A-7 Frame/Subframe Sizes for Source Image GSD of 10 Meters

Zone Number

Subframes in
Zone (Rows)
Latitudinal

Frame Rows
in Zone
Latitudinal

Equator-ward
Zone Extent
with Overlap

Pole-ward
Zone Extent
with Overlap

1,A

1,392

232

0°

32.0409207

2,B

702

117

31.9028133

48.0613811

3,C

354

59

47.9232737

56.0716113© 2015 Open Geospatial Consortium

54

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

348

58

55.9335038

64.0818414

5,E

180

30

63.9437340

68.0869565

6,F

180

30

67.9488491

72.0920716

7,G

180

30

71.9539642

76.0971867

8,H

180

30

75.9590793

80.1023018

9,J

———

———

varies90°© 2015 Open Geospatial Consortium

55

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

Subframes(Columns)
Longitudinal

Frames(Columns)
Longitudinal

E-W Pixel Constant

1,A

14,4402,407

3,696,640

2,B

11,8201,970

3,025,920

3,C

9,600

1,600

2,457,600

4,D

7,780

1,297

1,991,680

5,E

6,380

1,064

1,633,280

6,F

5,360

894

1,372,160

7,G

4,300

717

1,100,800

8,H

3,220

537

824,320

A.16.5
FalconView Frame Position
MIL-C-89041 states that “the origin for counting nonpolar frame rows and columns is thesouthernmost latitude of the zone and 180° west longitude, with columns counted in an easterly
direction from that origin, as opposed to frames and subframes where “the origin for thesubframe and pixel numbering within frames and subframes shall be from the upper left corner”.

For a given latitude φ and longitude λ the row and column for the frame where thatgeographic position is situated can be computed. The determination of the zone is derived fromthe latitude except at the border of zones where an overlap exists and the zone must be picked.

⎛ (φ − φszr )Nφr ⎞The row is given by FR = int ⎜⎜⎟⎟ where φ szr is the bottom southern most latitude of the
1536
⎝
⎠
zone at resolution r and N φr is the number of pixels per degrees of latitude at resolution r.

⎛ (180 + λ )N λzr ⎞Similarly the column corresponding to the longitude is given by FC = int ⎜⎟ where1536⎝⎠
N λzr is the number of pixel per longitudinal degrees in zone z at resolution r, λ ranges from –180
to 180.

As an example, for latitude of 36 degrees and longitude of –88 degrees we would get for a
resolution of 10 meters© 2015 Open Geospatial Consortium

56

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

1000960= 11121.778
903025920
N λzr =
= 8405.333 since we are in zone 2360⎛ (36 − 31.9028133) × 11121.778 ⎞
FR = int ⎜⎟ = 291536⎝⎠⎛ (180 + (−88) ) × 8405.333 ⎞
FC = int ⎜⎟ = 5031536⎝⎠
N φr =

A.16.6
FalconView File Naming Convention
MIL-C-89041 for Controlled Image Base (CIB) states that:“The naming convention for all resolutions of images registered in MIL-STD-2411-1, where it isintended for producers to provide contiguous [frame file] coverage, shall conform to MIL-STD2411. In addition, the CIB [frame file] names are further restricted to conform to the form
“ffffffvp.ccz.” The “ffffff” portion of the name shall be a radix 34 value that encodes the uniquecumulative frame number within a zone in base 34, with the right-most digit being the leastsignificant position. The radix 34 value incorporates the numbers 0 through 9 and letters A
through Z exclusive of the letters “I” and “O” as they are easily confused with the numbers “1”and “0”. For example, the “ffffff” portion of the names would start with “000000,”
proceed through “000009,” “00000Z,” “000010,” and so forth until “ZZZZZZ.” This allows
1,544,804,416 unique [frame file] names; a contiguous grid of frame names down to a resolutionof 0.2 meters (approximately 8 inches) can be defined. The “v” portion of the name shall be aradix 34 value that encodes the successive version number. The “p” portion of the name shall bea radix 34 value that designates the producer code ID, as defined in MIL-STD-2411-1. The“cc” and “z” portions of the name extension shall encode the data series code and the zone,
respectively, as defined in MIL-STD-2411-1. The CIB producers are responsible to ensure that[frame files] for all image resolutions, zones, and revisions, have unique names.”
In our case:ffffff = FC + FR × N crz… where N czt is the number of columns in zone z for a resolution r

In the example of a lat of 36 and lon –88 with a resolution of 10 meters we get:© 2015 Open Geospatial Consortium

57

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
ffffff = 503+29x1970=57633 or 001FV3(34)… where 1970 is number columns in zone 2 as given in Table A-7 Frame/Subframe Sizes for
Source Image GSD of 10 Meters, and in RADIX 34 we get ffffff = 001FV3 ; for a global
navigation chart dataset a version level 0, a manufacturer code of 3 and zone 2 the file namewould be equal to “001FV303.GN2”
Note that nothing in the file name defines the resolution for the data; this information is part ofthe [coverage section] in the file itself (see section 3.12.3 in MIL-C-89041). Also note that thefile name is unique only to the zone at a given resolution.
On the other hand a similar file for imagery (VSTI, Visible Spectrum Terrain Imagery) in the
CDB convention for an LOD of 04 which has a resolution of approximately 8 meters; at position
lat 36 and lon –88 we would get for the file name:\CDB\Tiles\N36\W088\004_Imagery\L04\U0\
N36W088_D004_S001_T001_L04_U0_R0.jp2

Note that the file name itself is unique worldwide and that from it we can derive the directory
path to which it belongs.
A.17
Information: JPEG-2000
The CDB specification supports JPEG2000 for both VSTI and VSTLM component data.

As a result of the high rates of compression there are no real advantages to be gained insupporting a broad range of alternate color representations (such as single channel
representations, indexed color representations, RGB-triplet color encoding such as 5-6-5, etc.).
The underlying motivation behind all such schemes is driven by a desire to reduce storage andtransmission bandwidths. JPEG-2000 achieves these goals and many others, refer to Table A-8
JPEG 2000 Features.

Table A-8 JPEG 2000 Features
High compression efficiency:
High dynamic range:
Compression better than 0.25 bits per pixels, 20%
Compress images with various
compression efficiency improvement over JPEG. dynamic ranges (e.g. 1-16 bit) for eachcolor component.

© 2015 Open Geospatial Consortium

58

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Lossless and lossy compression:
Lossless compression ratios approx. 1.7:1.

Seamless quality / resolution
scalability:
Without having to download the entire
file.
Large images sizes - up to (232 - 1).

Progressive image reconstruction:
Allows images to be reconstructed with increasing
pixel accuracy and resolution.
Perceptual color space internal coding.
Single decompression architecture.
Region of interest coding:
Error resilience during transfers.
Permits certain ROI’s in the image to be coded andtransmitted with better quality and less distortion than
the rest of the image.

A.18
Information: Managing CDB Versions
The incremental versioning mechanism of the CDB provides a fast method of creating versionsof the CDB changes since all the data changes are located under a single root directory. The
creation and the managing of the (incremental) data files are however under the application
control.
A CDB can simultaneously hold multiple incremental versions of the data. As a result, it ispossible to select any of the versions without transferring or copying files. Consider the casewhere a database generation facility, a database quality assurance facility, a simulator mission
planning facility, a mission rehearsal facility and a mission debrief are all operating concurrently
on distinct versions of the CDB. This is illustrated in Figure 3 2: Concurrent Usage of Versionsof the CDB. By the fourth day, there are four versions of the CDB, say the active default CDB(v1) and three incremental versions (v2, v3, v4). Any of these four versions can be instantly
invoked (without copying or transferring files) by the simulator operator at the Mission
Rehearsal facility, or by an instructor at the Mission Debrief facility.

Figure A-24: Concurrent Usage of CDB Versions© 2015 Open Geospatial Consortium

59

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

The underlying CDB versioning mechanism is a fine-grained file-level mechanism, i.e., only theaffected files of the geographic areas of the CDB need to be versioned, leaving the rest of the
CDB intact. This approach is invaluable in mission rehearsal applications where the target areasof the CDB require frequent updates based on the latest intelligence data.
The approach can also be applied to the handling of classified secure data. In this case, a CDB
version can be used to hold the portion of the CDB that contains the classified information. The
incremental versioning mechanism would be used to segregate the classified portion of the CDB
onto a separate storage medium. Since the classified portion of the CDB is embedded within theoverall CDB structure, it is possible for the runtime publishers to instantly switch back and forth
between the classified and non-classified versions of the database.
A.19
Guideline: Handling of GS and T2D Models
A.19.1
GSModels
A.19.1.1 GSModel Levels-of-detail
The insertion of a 3DModel-LOD into the LOD hierarchy of the GSModel Dataset is solely
dependent on its Location, its Significant Size and on its Storage Size.
The location and Significant Size of a 3DModel-LOD determines where it is nominally inserted
into the GSModel Dataset hierarchy. This approach ensures that the modeled content isorganized in files that contain co-located objects of similar size. This approach provides clientdevice with an optimal means of accessing and filtering modeled content (by location and bysize).

© 2015 Open Geospatial Consortium

60

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

Figure A-25: Handling Tile-LOD Overflows in GSModel Dataset

3DModel-LODs are accumulated into the Tile-LODs of the GSModel hierarchy. The size ofthese Tile-LODs is capped to GSModelFileSize. In the event that a group of 3DModel-LODs
nominally assigned to a Tile-LOD causes this limit to be exceeded, the 3DModel-LODs that are
deemed to have the lowest contribution to the Tile-LOD are moved to finer (children) Tile-LODs
until the Tile-LOD is once again within its size limit (illustrated in Figure A-25: Handling TileLOD Overflows in GSModel Dataset). In the event that a 3DModel-LOD is itself larger than
GSModelFileSize, the 3DModel-LOD is moved to the 4 finer Tile-LODs of the GSModel© 2015 Open Geospatial Consortium

61

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Dataset hierarchy. This approach ensures that the modeled content is accessible in chunks thatare bounded; this improves the allocation and management of memory allocation in the clientdevices.

NOTE: The Significant Size of a 3DModel-LOD determines where it is nominallyinserted into the 3DModel LOD hierarchy. In this nominal case, each Tile-LODof the 3DModel Dataset holds a group of 3DModels-LODs that have similar
Significant Sizes. This enables the client-devices to determine the range at
which the 3DModel-LOD can be optimally blended-in to the scene (so that themodel falls within a specified angular error criterion).
The bounding criterion of 3DModel Tiles can lead to LOD migration, thus breaking
the relationship between the Significant Size of a 3DModel-LOD and thenominal CDB LOD it belongs to. As a result, client-devices can no longer
guarantee the range at which the 3DModel-LOD will be blended-in to the scene.
In effect, each time the 3DModel-LOD is migrated by one LOD, the client-device
will likely shorten the range at which it is blended into the scene by a factor of
2X, leading to potentially distracting artifacts. The severity of the artifacts is
proportional to the amount of content that has migrated to finer LODs and to thenumber of LODs by which the content has moved.
While the CDB Specification allows the migration of 3DModel-LODs to finer LODs
when Tile-LODs overflows are encountered, it is understood that this may leadto rendering artifacts that might be considered unsatisfactory. Consequently, it
is strongly recommended that tools (that generate the CDB hierarchy) be
designed to optionally disallow the migration of 3DModel-LODs to finer
LODs upon overflows, and instead flag the overflow condition and thenabort. Upon such cases, modelers can then re-assess which 3DModels should
be discarded or remodeled in order to simultaneously satisfy the CDB bounding
criteria and the application requirements.

Each of the 3DModel-LODs is nominally configured as exchange-LODs. The exchange-LOD
mechanism assumes that client-devices gradually substitute a coarser 3DModel-LOD located in acoarser Tile-LOD with a finer 3DModel-LOD located in a finer Tile-LOD.
While this exchange-LOD mechanism is simple, it can lead to inefficiencies when extremely finefeatures cause the GSModel Dataset hierarchy to be extended by several LODs. Consider thecase of a 1 meter road sign located next to a large building (30m wide x 30m long x 10 m high).
As we will see in the following section, the road sign would nominally be inserted at LOD 9 of
the GSModel Dataset hierarchy. Conversely, the large modeled building would nominally be© 2015 Open Geospatial Consortium

62

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
inserted at LOD 4. The road sign forces the GSModel Dataset hierarchy to be extended by 5
additional LODs.

Figure A-26: Compacting the GSModel Dataset

In order to reduce the depth of the LOD hierarchy, the GSModel Dataset is post-processed andsubjected to a “compaction” process, starting from the finest LOD (e.g. LODmax) and progressing
to the coarser levels. The compaction process takes finer 3DModel-LODs and appends them to© 2015 Open Geospatial Consortium

63

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
the corresponding 3DModels in coarser Tile-LODs of the GSModel Dataset. The appended(finer) 3DModel-LOD must have an explicit OpenFlight LOD node with the Significant Size ofthe 3DModel-LOD; this provides the necessary information for the client-device to control therange at which the 3DModel-LOD will be introduced into the rendered scene. The process isrecursively applied to the coarser LODs until the parent LOD is packed to capacity. Thisapproach ensures that the modeled content is accessible in similarly-sized chunks of processing;
this provides the means to improve internal parallelism and pipelining (i.e. improves clientdevice determinism)
The access and selection of 3DModel-LODs is done through the GSFeature Dataset. Each of the
Tile-LODs of the GSFeature Dataset contains a list of Features; each Feature in turn points to a
3DModel-LOD at the appropriate LOD. In effect, the appearance of a Feature (along with its
modeled representation) and the evolution of its modeled representation are entirely controlled
by the GSFeature Dataset. As a result, the 3DModel-LODs of a 3DModel need not be located inconsecutive LODs of GSModel Dataset hierarchy.
A.19.1.2 CDB LOD versus GSModel Significant Size
Chapter 6 provides a set of guidelines to establish the values for Significant Size SSc and SSLOD
for GSModels.
Table 3 1: CDB LOD vs. Model Resolution shows the nominal position of a GSModel within the
LOD hierarchy of the GSModel Dataset. Note all of the GSModel-LODs of a GSModel
normally fall within a range of 8 levels-of-detail (i.e. the smallest tile size the GSModel can siton). However, it is possible to extend this range by breaking up a GSModel-LOD into several
OpenFlight files.
Here is a summary of the rules required by the CDB Specification in order to ensure
deterministic operation from client-devices:
1. Each feature may have multiple modeled representations at progressively coarser
levels of detail. Each of the modeled representations is referred to as a GSModelLOD. In absence of pre-modeled coarser LOD representations, the tools may
automatically generate coarser modeled levels-of-detail.
2. A GSModel-LOD consists of a group of polygons that represent a feature at a
specific level-of-detail; this group of polygons shares a unique Model Identifier
derived from the Feature Attribute Code (FACC), a Feature Sub-Code (FSC), a
Model Name (MODL or MMDC), the GSModel-LOD’s Significant Size SS’LOD.
3. Each GSModel has a distinct Significant Size SS’ value based on its dimensions.
In turn, each GSModel-LOD of a same GSModel has a distinct Significant Sizevalue SS’LOD based on its modeled accuracy.
4. Insertion of a GSModel-LOD into the GSModel Dataset hierarchy proceeds asfollows. Starting with LODmax (LODmax is a variable set by the user that sets the
maximum depth of the LOD hierarchy) and progressing to coarser LODs…
a. For each Tile-LOD, create a Model_List that is constructed from the
GSModel-LODs that straddle the Tile-LOD.

© 2015 Open Geospatial Consortium

64

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
i. If the GSModel-LOD is not the coarsest LOD and its Significant Size is inaccordance toTable 3 1: CDB LOD vs. Model Resolution, then add it to
the Tile-LOD. Only the coarser GSModel-LODs of this GSModel areavailable for future insertion into the GSModel LOD hierarchy.
ii. If the GSModel-LOD is the coarsest LOD of the GSModel and its Significant
Size is in accordance to Table 3 1: CDB LOD vs. Model Resolution, theninsert it at this LOD of the hierarchy. If the GSModel-LOD matches the TileLOD, remove it from the list for the processing of the coarser Tile-LOD.
b. If the Model_List is less than GSModelFileSize, no further processing isrequired.
NOTE:
zero.

The Storage Size of (statically-positioned) MModels is assumed to bec. The Model_List of each Tile-LOD is sorted in decreasing order of Diff, where
Diff is the difference between the Significant Size SS of the Model and the
Significant Size as specified in Table 2.
d. If the size of the Model_List is greater than GSModelFileSize, then (startingwith the first entry in the sorted Model_List), Models are simplified one-byone until the size of the Model_List is less than GSModelFileSize. When asimplification occurs, the Model_List is re-sorted using the Diff value.
e. If a) the Model_List is deemed non-reducible and b) the Model_List is still
greater than GSModelFileSize …
i. If LOD < LODmax, then…
(1) a Temp_Model_List is created and initialized with the contents of theModel_list. Starting from the end of the Model_List, Models are
removed one-by-one from the Model_list (starting with the first Modelin the Model_List) and are copied into the Temp_Model_List until the
Model_List reaches GSModelFileSize.
(2) The Temp_Model_List is merged to the children Tile-LODs and thechildren are re-processed using steps 4a to 4e. The process is iterative,i.e., the “overflow” is propagated into the finer LODs of the GSModelhierarchy.
ii. Else…
(1) Models are removed one-by-one, starting with the first Model in the
Model_List, until the Model_List is less than GSModelFileSize. The
corresponding GSModels are removed from the CDB and a warning isissued stating that content was removed
NOTE: It is strongly recommended that GSModels be modeled using several
GSModel-LODs, spanning a wide range of fidelity. The availability of many
LODs ensures suitability of the resulting CDB for real-time use with a minimum
degradation in fidelity. Conversely, a low number of LODs can lead to
unacceptably large steps in fidelity.

© 2015 Open Geospatial Consortium

65

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
NOTE: It is strongly recommended that the coarsest modeled LOD of GSModels
have no more than 128 vertices; this reduces the likelihood that the coarsest
modeled LOD need be propagated to a finer LOD of the hierarchy.

NOTE: This algorithm preserves the highest available modeled content while
ensuring that the runtime constraint file size limits are respected. While the
CDB data model allows for infinitely-sized GSModel-LODs, a client-device may
refuse to render the GSModel-LOD if it has insufficient memory to load all of the
OpenFlight files that make-up the GSModel-LODs.

5. Each GSModel-LOD is subject to an OpenFlight file size limit of
GSModelFileSize, i.e. several OpenFlight files, each within the GSModelFileSize
limit, can be used to represent a very complex GSModel-LOD. Each of
OpenFlight files that form the GSModel-LOD share the same GSModel-LOD
Identifier (see rule 2) and GSModel-LOD origin. Client-devices must render the
GSModel-LOD in its entirety, even if it is allocated to several OpenFlight files.
NOTE: While the CDB data model allows for infinitely-sized GSModel-LODs, aclient-device may refuse to render the GSModel-LOD if it has insufficient
memory to load all of the OpenFlight files that make-up the GSModel-LODs.

6. Each Tile-LOD is subject to a file size limit of GSModelFileSize.
7. All of the GSModel-LODs in a GSModel OpenFlight file are nominallyexchange-LODs (see exception in next rule).
8. The depth of the GSModel LOD hierarchy should be reduced by folding-in thefiner GSModel-LOD located in a finer Tile-LOD to the next coarser Tile-LOD of
the hierarchy. Failure to perform this “compaction step” may result insignificantly deeper GSModel LOD hierarchy when the finest GSModel-LODsconsist of small features or small details on the same features (e.g., small posts
next to a terminal building or fine window details on a large building).
9. The finer modeled representation of a GSModel (i.e. a GSModel-LOD with asmaller Significant Size) always appears in finer LODs of the GSModel Dataset
LOD hierarchy than a coarser GSModel-LOD.
10. A Tile-LOD cannot contain more than one GSModel-LOD of the same GSModel.
11. Once inserted into the GSModel Dataset LOD hierarchy, there is no mandatory
requirement to clip the contents of a GSModel Tile-LOD against its Tile-LOD
boundaries. However, the contents of the GSModel Tile-LOD cannot protrude
Tile-LODs by more than ½ the dimension of the Tile-LOD.

© 2015 Open Geospatial Consortium

66

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
12. There is no mandatory requirement to have consecutive GSModel-LODs inconsecutive LODs of Tile-LOD hierarchy; it is permissible to have gaps within
the Tile-LOD hierarchy.
13. Gaps in the LOD file hierarchy of the GSFeature Dataset are not permitted. This
may result in Tile-LODs that are empty (e.g. without any GSFeatures). The
presence of an empty Tile-LOD file for the GSFeature Dataset indicates theavailability of modeled content invoked by finer LODs of the GSFeature
hierarchy.
A.19.1.3 Example – Insertion of a GSModel with 3 LODs into the CDB Hierarchy
Consider an industrial building 200m wide x 200m length x 10m high. The modeler has not
supplied any values for its Significant Size, nor has he provided a value for RTAI. It is modeledin three distinct levels of detail as follows:a) Coarsest level: 5 polygonsb) Mid level: 60 polygonsc) Finest level: 300 polygons
Based on this information, we can derive Significant Size values for each of the modeled
representation as follows and determine where within the hierarchy each of the GSModel-LODs
should be inserted:a. Coarsest level-of-detail:a. Compute the model’s Significant Size …
𝑆𝑆𝑆𝑆 =   10×.96)×200 +    200×200×.259  𝜋𝜋𝑆𝑆𝑆𝑆 =   62.5𝑚𝑚

b. Since the model is opaque and has no assigned value for RTAI, the final value
for SS’ is 62.5m.
c.
Table 3 1: CDB LOD vs. Model Resolution, tells us that the (coarsest
LOD) of the model should be nominally inserted at LOD 3 of the Tile-LOD(assuming its file size limit is not exceeded)b. Mid level-of-detail:a. Compute the ratio of vertices
60
𝑉𝑉
=
= 12
  𝑅𝑅 =     𝑉𝑉
5b. Compute the Significant Size of the GSModel-LOD…
𝑆𝑆𝑆𝑆′
𝑆𝑆𝑆𝑆′ == 18.04𝑚𝑚
12c. Since the model is opaque and has no assigned value for RTAI, the final value
for SS’ is 18.04m.

© 2015 Open Geospatial Consortium

67

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
d. d.
Table 3 1: CDB LOD vs. Model Resolution, tells us that the (mid- LOD)
of the model should be nominally inserted at LOD = 5 of the Tile-LOD(assuming its file size limit is not exceeded)c. Finest level-of-detail:a. Compute the ratio of vertices
300
𝑉𝑉
  𝑅𝑅 =     𝑉𝑉==5
60
b. Compute the Significant Size of the GSModel-LOD…
𝑆𝑆𝑆𝑆′
𝑆𝑆𝑆𝑆′ == 8.07𝑚𝑚
5c. Since the model is opaque and has no assigned value for RTAI, the final value
for 𝑆𝑆𝑆𝑆′ is 8.07.
d. d.
Table 3 1: CDB LOD vs. Model Resolution, tells us that the (finest-LOD)of the model should be nominally inserted at LOD = 6 of the Tile-LOD(assuming its file size limit is not exceeded)
A.19.2
T2DModels
The T2DModels are stored in the OpenFlight format. The CDB conventions described herein
are designed to facilitate the integration of such models onto the terrain tile, hence the name“Tiled 2D Models”. Each 2DModel can have one or more modeled representation (called a2DModel-LOD) that represents the feature to a certain level of fidelity. 2DModel-LODs are regrouped into T2DModel Tile-LODs; this re-grouping approach is designed to reduce theoverheads associated with the access of 2DModel-LODs. Furthermore, T2DModel-LODs can beaccessed without a prior reference to a corresponding feature in the GSFeature dataset.
The integration of T2DModels to the underlying terrain skin is performed by the client-devices atruntime. Historically, this integration has always been performed by the tools and was “bakedin” into the SE terrain skin during the offline database generation process. Many client-specificconsiderations went into the mechanisms required to support this integration and as a result, theresulting synthetic environments were very client-specific and did not scale easily to higher
resolutions.
In line with CDB principles, the T2DModel Dataset defers this integration and imposes it on the
consumers (not the producers) of synthetic environments. As a result, client-devices can
independently access, manage and control each dataset, i.e., the Primary Elevation, the VSTI
Imagery, the T2DModel, etc. This layered approach to synthetic environment production andconsumption provides a much greater level of abstraction between the SE data model and thedata models internal to each client-device. It is understood, that the deferral of the integration
process imposes added functionality and computational requirements on the part of the CDB
client-devices.
While it would be possible, in theory, to use the T2DModel Dataset for the modeling of theterrain skin, this use-case is specifically forbidden because the T2DModel Dataset does notprovide a guarantee of full tile coverage. As a result, the Primary Elevation Dataset is always
required regardless of whether a corresponding Tile-LOD of the T2DModel is present or not.

© 2015 Open Geospatial Consortium

68

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Furthermore, since CDB forbids the duplication of information, the terrain skin cannot be
duplicated by the T2DModel Dataset.
Client-devices must always access the Primary Elevation prior to any other raster datasets. Oncea Tile-LOD of the Primary Elevation is loaded, a client-device can then access the T2DModel
Dataset at an “appropriate” LOD3. Following this, the client-device must integrate the models
found within the T2DModel Tile-LOD with the terrain found in the Primary Elevation dataset.
A.19.2.1 T2DModel Levels-of-detailAs with 3D features, 2D features can have modeled representations at varying levels of detail.
Each of these modeled-representations is referred to as a 2DModel-LOD. A 2DModel-LOD
consists of a group of polygons that represent a 2D feature at a specific level-of-detail.
Once a 2DModel-LOD is inserted into the T2DModel Dataset hierarchy, it is then referred to asa T2DModel-LOD. The insertion of a 2DModel-LOD into the LOD hierarchy of the T2DModel
Dataset is solely dependent on its Location, its Significant Size and on its Storage Size.
2DModel-LODs are regrouped into files called T2DModel Tile-LODs. Note that when a2DModel is clipped to the T2DModel’s Tile-LOD boundaries, each of the clipped modelfragments will appear in distinct OpenFlight files of the T2DModel Dataset. The T2DModel
Tile-LODs are assembled into a hierarchy of Tile-LODs called the T2DModel Dataset.
The organization of the modeled content into files that contain co-located objects of similar size
greatly improves runtime performance. The location and Significant Size of a 2DModel-LOD
determines where it is nominally inserted into the T2DModel LOD hierarchy. This approachensures that the modeled content is organized in files that contain co-located objects of similarly
size. This approach provides client-device with an optimal means of accessing and filteringmodeled content (by location and by size).
2DModel-LODs are accumulated into Tiles for each LOD of the T2DModel hierarchy. The sizeof these T2DModel Tiles is capped to T2DModelFileSize4. In the event that the insertion of a2DModel-LOD causes this limit to be exceeded, the 2DModel-LODs that are deemed to have thelowest contribution to the Tile are moved to finer Tiles of the T2DModel hierarchy until the Tile
is once again within its size limit. In the event that the 2DModel-LOD is larger than
T2DModelFileSize, the 2DModel-LOD can be moved to the 4 finer Tiles of the T2DModelhierarchy and clipped against the Tile boundaries as illustrated in Figure A-27: Handling TileLOD Overflows within the T2DModel Dataset Hierarchy. This approach ensures that themodeled content is accessible in chunks that are bounded; this is critical to the effective
allocation and management of memory in the client-devices as well as improving client-device
performance and determinism.

3

In this context, “appropriate” means a LOD that falls within the capabilities of the client-device.

4

The T2DModelFileSize storage size limit for T2DModel Tile-LODs is critical in achieving runtime
determinism.

© 2015 Open Geospatial Consortium

69

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

NOTE: The Significant Size of a 2DModel-LOD determines where it is nominallyinserted into the T2DModel LOD hierarchy. In this nominal case, each Tile-LODof the T2DModel Dataset holds a group of 2DModel-LODs that have similar
Significant Sizes. This enables the client-devices to determine the range at
which the T2DModel-LOD can be optimally blended into the scene so that themodel falls within a specified angular error criterion.
The bounding criterion of T2DModel Tiles can lead to LOD migration, thus
breaking the relationship between the Significant Size of a 2DModel-LOD andthe nominal CDB LOD it belongs to. As a result, client-devices can no longer
guarantee the range at which the 2DModel-LOD will be blended into the scene.
In effect, each time the 2DModel-LOD is migrated by one LOD, the client-device
will likely shorten the range at which it is blended into the scene by a factor of 2,
leading to potentially distracting artifacts. The severity of the artifacts is
proportional to the amount of content that has migrated to finer LODs and to thenumber of LODs by which the content has moved.
While the CDB Specification allows the migration of 2DModel-LODs to finer LODs
when Tile-LODs overflows are encountered, it is understood that this may leadto rendering artifacts that might be considered unsatisfactory. Consequently, it
is strongly recommended that tools (that generate the CDB hierarchy) be
designed to optionally disallow the migration of T2DModel-LODs to finer
LODs upon overflows, and instead flag the overflow condition and thenabort. Upon such cases, modelers can then re-assess which T2DModels
should be discarded or remodeled in order to simultaneously satisfy the CDB
bounding criteria and the application requirements.

Each of the Tile-LODs of the T2DModel Dataset is nominally configured as exchange-LODs(aka substitution-LODs) as defined in chapter 6.
The exchange-LOD mechanism assumes that client-devices gradually substitute a coarser TileLOD with a four finer Tile-LODs.
While this exchange-LOD mechanism is simple, it can lead to inefficiencies when extremely finefeatures cause the T2DModel Dataset hierarchy to be extended by several LODs. Consider thecase of 13m road lineals overlaid with 6 cm stripe lineals. As we will see in the following
section, insertion of the Stripe lineal would nominally occur at LOD=7 of the T2DModelhierarchy while the Road lineal would occur at LOD=-1. The Stripe lineals force the T2DModel
Dataset hierarchy to be extended (and clipped) to 8 additional LODs. In effect, the Road lineals
are repeated5 in LODs 0 through 7 leading to important storage inefficiencies and greater
computational burden by the client-devices.

5

Since the nominal LOD mechanism is the exchange-LOD, and that gaps are not permitted in the LOD hierarchy© 2015 Open Geospatial Consortium

70

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

Figure A-27: Handling Tile-LOD Overflows within the T2DModel Dataset Hierarchy

In order to resolve this use-case, the T2DModel Dataset is post-processed and subjected to a“compaction” process, starting from the finest LOD (e.g. LODmax) and progressing to the coarser
levels. The compaction process takes the content of the Tile-LODs located at LODmax and packs
them as an additive LODs of the parent Tile-LOD at (LODmax – 1) of the parent Tile-LOD. The
process is recursively applied to the coarser LODs until the parent LOD is packed to capacity.
This approach ensures that the modeled content is accessible in similarly-sized chunks ofprocessing; this provides the means to improve internal parallelism and pipelining (ie. improves
client-device determinism). The result is a LOD hierarchy which is less deep, and with content
which is more uniformly distributed; both of these characteristics improve runtime performanceand determinism.

© 2015 Open Geospatial Consortium

71

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The T2DModel LOD structure is continuous i.e. there is no gap in the LOD hierarchy. Thismeans that once a 2DModel-LOD is inserted into a finer level of the T2DModel hierarchy, thesame 2DModel-LOD is propagated to coarser LODs until a coarser 2DModel-LOD is available.
Note that some client-devices may be sensitive to the precision of clipped vertices; some clientdevices may demand that the clipped vertices be shared at the tile boundary between two tiles ofthe same LODs. This can be done as follow:-­‐ The X coordinate (longitude) of clipped vertices along the top or bottom edges of
the tile can be used to uniquely identify the matching coordinate in an adjacent tile.
-­‐ The Y coordinate (latitude) of clipped vertices along the right or left edges of thetiles can be used to uniquely identify the matching coordinate in an adjacent tile.

© 2015 Open Geospatial Consortium

72

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

Figure A-28: Compacting the T2DModels Dataset Hierarchy

A.19.2.2 CDB LOD versus T2DModel Significant Size
Chapter 6 provides a set of guidelines to establish the values for Significant Size SSc and SSLOD
for T2D Models (for both lineals and areals).
Table 3 32: T2DModel LOD versus Significant Size, shows us the relationship between SSc and
SSLOD. They are offset by 3 LODs. The implication of this statement is in the case of a modelwith two LOD, the finer 2DModel-LOD must have sufficient detail to justify its existence.

© 2015 Open Geospatial Consortium73

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Note: Each of the 2DModel-LODs of a 2DModel must differ by at least one CDB
LOD. Some 2DModel-LODs will be discarded if this relationship is notrespected.

Consider for example a 12m lineal road feature with two modeled representations. The nominal
CDB LOD for the coarsest 2DModel-LOD is LOD=3 in accordance to the table below. The
Significant Size of the finer 2DModel-LOD is obtained by “walking” around its outline; wedetermine that the largest value of d for successive vertex triplets is 3m, hence SSLOD = 3m.
Table A-9: T2DModel LOD versus Significant Size, tells us that the 2DModel-LOD should also
be nominally inserted at CDB LOD = 3. Since both 2DModel-LODs have the same nominal
CDB LOD, only one of them is retained (preferably the more detailed of the two)

Table A-9: T2DModel LOD versus Significant Size

Significant Size
T2DModelCDB Level

Significant Size
SSc
(Coarsest Model-LOD)

SSLOD(Other Model-LODs)
OTHER Interp.

Tile-LODSize

Max Error with respect tofinest-10

56 km < SS < 110 km

SS < 14 km

110 km-928 km < SS ≤ 56 km

SS < 6.9 km

110 km-8

14 km < SS ≤ 28 km

SS < 3.5 km

110 km-7

6.9 km < SS ≤ 14 km

SS < 1.7 km

110 km-6

3.4 km < SS ≤ 6.9 km

SS < 870 m

110 km-5

1.7 km < SS ≤ 3.4 km

SS < 430 m

110 km-4

860 m < SS ≤ 1.7 km

SS < 220 m

110 km-3

430 m < SS ≤ 860 m

SS < 110 m

110 km-2

220 m < SS ≤ 430 m

SS < 54 m

56 km

-1

110 m < SS ≤ 220 m

SS < 27 m

28 km© 2015 Open Geospatial Consortium

74

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
054 m < SS ≤ 110 m

SS < 13 m

14 km

1

27 m < SS ≤ 54 m

SS < 6.8 m

6.9 km

2

13 m < SS ≤ 27 m

SS < 3.4 m

3.4 km3

6.7 m < SS ≤ 13 m

SS < 1.7 m

1.7 km4

3.4 m < SS ≤ 6.7 m

SS < 840 mm

860 m

5

1.7 m < SS ≤ 3.4 m

SS < 420 mm

430 m

6

840 mm < SS ≤ 1.7 m

SS < 210 mm

220 m

7

420 mm < SS ≤ 840 mm

SS < 110 mm

110 m

8

210 mm < SS ≤ 420 mm

SS < 52 mm

54 m

9

110 mm < SS ≤ 210 mm

SS < 26 mm

27 m

10

52 mm < SS ≤ 110 mm

SS < 13 mm

13 m

11

26 mm < SS ≤ 52 mm

SS < 6.6 mm

6.7 m

12

13 mm < SS ≤ 26 mm

SS < 3.3 mm

3.4 m

13

6.7 mm < SS ≤ 13 mm

SS < 1.6 mm

1.7 m

14

3.4 mm < SS ≤ 6.7 mm

SS < 820 um

840 mm15

1.7 mm < SS ≤ 3.4 mm

SS < 410 um

420 mm16

820 um < SS ≤ 1.7 mm

SS < 210 um

210 mm17

410 um < SS ≤ 820 um

SS < 100 um

110 mm18

210 um < SS ≤ 410 um

SS < 51 um

52 mm

19

110 um < SS ≤ 210 um

SS < 26 um

26 mm

20

52 um < SS ≤ 110 um

SS < 13 um

13 mm

21

26 um < SS ≤ 52 um

SS < 6.7 um

6.7 mm22

13 um < SS ≤ 26 um

SS < 3.4 um

3.4 mm© 2015 Open Geospatial Consortium

75

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

SS ≤ 13 um

SS < 1.7 um

1.7 mm

A.19.2.3 Rules Governing T2DModel LOD Hierarchy
Here is a summary of the rules required by the specification in order to ensure deterministic
operation from client-devices:
1. Each feature may have multiple modeled representations at progressively coarser
levels of detail. Each of the modeled representations is referred to as a 2DModelLOD. In absence of pre-modeled coarser LOD representations, the tools may
automatically generate coarser modeled levels-of-detail.
2. A 2DModel-LOD consists of a group of polygons that represent a feature at a
specific level-of-detail; this group of polygons shares a common Feature Attribute
Code (FACC), a Feature Sub-Code (FSC), a Model Name (MODL) and
2DModel-LOD’s Significant Size SS’LOD.
3. Each 2DModel has a distinct Significant Size value SS’ based on its dimensions.
In turn, each of the 2DModel-LODs of a 2DModel has a distinct Significant Sizevalue SS’LOD based on its modeled accuracy.
4. Insertion of a 2DModel-LOD into the T2DModel Dataset hierarchy proceeds asfollows. Starting with LODmax (LODmax is a variable set by the user that sets the
maximum depth of the LOD hierarchy) and progressing to coarser LODs…
a. For each Tile-LOD, create a Model_List that is constructed from the2DModel-LODs that straddle the Tile-LOD.
i. If the 2DModel-LOD is not the coarsest LOD and its Significant Size is inaccordance to Table A-9: T2DModel LOD versus Significant Size, theniteratively simplify the 2DModel-LOD (iterate until its Significant Size is
no longer in accordance to Table A-9: T2DModel LOD versus Significant
Size and keep results of previous iteration) and add it to the Tile-LOD.
Only the coarser 2DModel-LODs of this 2DModel are available for future
insertion into the T2DModel hierarchy.
ii. If the 2DModel-LOD is the coarsest LOD of the 2DModel and its
Significant Size is in accordance to Table A-9: T2DModel LOD versus
Significant Size, insert it at this LOD of the hierarchy. If the 2DModelLOD matches the Tile-LOD, remove it from the list for the processing of
the coarser Tile-LOD.
b. If the Model_List is less than T2DModelFileSize, no further processing isrequired.
c. The Model_List of each Tile-LOD is sorted in decreasing order of Diff, where
Diff is the difference between the Significant Size SS of the Model and the
Significant Size as specified in Table 3.
d. If the Model_List is greater than T2DModelFileSize, then (starting with thefirst entry in the sorted Model_List), Models are simplified one-by-one until
the size of the Model_List is less than T2DModelFileSize. When asimplification occurs, the Model_List is re-sorted using the Diff value.

© 2015 Open Geospatial Consortium

76

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
e. If a) the Model_List is deemed non-reducible and b) the Model_List is still
greater than T2DModelFileSize …
i. If LOD < LODmax, then…
(1) a Temp_Model_List is created and initialized with the contents of theModel_list. Starting from the end of the Model_List, Models are
removed one-by-one from the Model_list (starting with the first Modelin the Model_List) and are copied into the Temp_Model_List until the
Model_List reaches T2DModelFileSize.
(2) The Temp_Model_List is merged to the children Tile-LODs and thechildren are re-processed using steps 4a to 4e. The process is iterative,i.e., the “overflow” is propagated into the finer LODs of the
T2DModel hierarchy.
ii. Else…
(1) Models are removed one-by-one, starting with the first Model in the
Model_List, until the Model_List is less than T2DModelFileSize. The
corresponding T2DModels are removed from the CDB and a warning
is issued stating that content was removed.
NOTE: The algorithm preserves the highest available modeled content while
ensuring that the runtime constraint file size limits are respected. While the
CDB data model allows for infinitely-sized 2DModel-LODs, a client-device may
refuse to render the 2DModel-LOD if it has insufficient memory to load all of the
OpenFlight files that make-up the 2DModel-LOD.

5. Each T2DModel Tile-LOD is subject to an OpenFlight file size limit of
T2DModelFileSize, i.e., several OpenFlight files, each within the
T2DModelFileSize file size limit, can be used to represent a very complex
T2DModel Tile-LOD. Each of T2DModel-LODs of an T2DModel Tile-LOD
share the same T2DModel-LOD Identifier (see rule 2)
6. Each Tile-LOD is subject to a file size limit of T2DModelFileSize.
7. All of the 2DModel-LODs in a T2DModel Tile-LOD are nominally exchangeLODs (see exception in next rule).
8. The depth of the T2DModel LOD hierarchy should be reduced by folding-in the
Tile-Models_List of finer Tile-LODs as an additive LOD to the Tile-Model_Listof a coarser Tile-LOD. Failure to perform this “compaction step” may result insignificantly deeper T2DModel LOD hierarchy when the finest 2DModel-LODsconsist of small details (e.g., thin stripes and markings on roads), and reduce thepaging performance of client-devices.
9. The finer modeled representation of a T2DModel (i.e., a 2DModel-LOD with asmaller Significant Size) always appears in finer LODs of the Tile-LOD hierarchy
than a coarser 2DModel-LOD.
10. A Tile-LOD cannot contain more than one 2DModel-LOD of the same
T2DModel.

© 2015 Open Geospatial Consortium

77

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
11. All T2DModels are clipped against the Tile-LOD boundaries.
12. Gaps in the LOD file hierarchy of the T2DModel Dataset are not permitted. This
may result in Tile-LODs that are empty (e.g., without any T2DModels). The
presence of an empty Tile-LOD file indicates the availability of content in
T2DModel files located in finer LODs of the T2DModel hierarchy.

A.20
Guideline: Examples of Vector Dataset Usages
A.20.1
Lineal Feature Radar Simulation Example
The following diagram represents a typical usage of a lineal model in the CDB for a typical radarclient-device.
The radar application first extracts the lineal feature from the CDB and constructs an object. The
constructed object contains the necessary information for the radar to compute the equivalentradar image using the radar cross-section (RCS) of the lineal features with material attributes anddirectivity, etc.

NOTE:

With the introduction of version 3.2 of the CDB Specification, it is recommended thatthe terrain-conformal features be modeled using T2DModels and that radar clientdevices use this modeled representation instead of the vector lineal and areal
features.

Figure A-31: Example of Lineal Features, illustrates three lineal features stored in the tile in
Shape format. The junction nodes of each lineal feature represents the start and end junctions of
the lineal feature. In this example, there is only one chain per lineal feature.

8

The SGI format is fully supported by the CDB Specification but a single file extension used, *.rgb. Consequently,
all image formats (int, inta, rgb, and rgba) are stored in .rgb files regardless of the number of channels in the image.

© 2015 Open Geospatial Consortium

78

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

Figure A-31: Example of Lineal Features

The radar uses the position of the lineal coordinates to construct a line representation of the radar
image. It extracts the lineal feature information from the chains to construct an internal local
representation. The necessary information needed by radar is:
1.

2.

3.

4.

Network Datasets:
The datasets along with the Feature Attribution Code (FACC) indicate if
the feature is a road, a highway, or river for example. In the above
illustration, we have a river, a powerline and a railway. The CDB
Specification represents this in the *.dbf file of the Shapefile
representation.
Composite Material IndeX (CMIX):
The Composite Material IndeX attribute points to the Composite Material
Table and provides the Radar the types of Base Materials that the feature
is made of. This information is used, in addition to the geometry of thelineal feature or a generic RCS, to provide a radar signature of the target,
which is proportional to the reflection value of the various materials. The
intensity of the radar image represents the interaction of the simulated
Radar Beam with the features in the synthetic environment. Each lineal
contains a reference to a composite material which in turn is mapped to areflectivity factor value in the radar simulation.
Width (WGP):The width of the lineal features is also taken into consideration. This
information is part of the Shapefile data used to construct a 2D radar
image of the terrain. The width information is encoded as an attribute of
the lineal feature.
Height (HGT):The height of the lineal feature is used to indicate the height of eachpoint/lineal with respect to the terrain height.

© 2015 Open Geospatial Consortium

79

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

5.

NOTE: The height value is a delta height above the terrain and is only
provided for objects that require it such as the powerlines or the train
tracks in this example.
The height property is especially valuable to radar client-devices because
erect objects in the database produce significant returns and occultation
areas in the displayed radar image. The height property can be assigned tothe train tracks, long fences and the powerlines each with average
altitudes.
Position:
This information is contained in the lineal *.shp files. The x and ycoordinate of each point is extracted from those objects.

Figure A-32: Radar Beam Simulation

The radar then uses a beam simulation to process the above information and construct an image
representing the content of each small beam sections. The intersection of the beam pie slice iscompared with the lineal feature’s position and converted into an image whose intensity is basedon the computed RCS of the lineal features. As mentioned above, the RCS value (which ismodeled internally in the radar simulation) takes into account the properties (which are derived
from the attributes) of each lineal feature.
A.20.2
Road Following Example
Figure A-33: Network Dataset Used to Describe a Navigable Network, illustrates how lineal
features can be used to describe a navigable network; the example could represent a network ofroads. First, the application reads a lineal shape file describing the chains, then the point shape
file describing the junction nodes. For each junction nodes the application makes up a list of
attached chains ending up with a network as illustrated in Figure A-33: Network Dataset Used to
Describe a Navigable Network, where there are six chains (labeled in this example as CSLID1 to© 2015 Open Geospatial Consortium80

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CSLID6) that are joined through intersection nodes (labeled in this example as CSZID1 to
CSZID6). The small black dots represent points forming the segments of a chain; they are
essentially used to describe the deviation from a straight line between nodes.
In Figure A-33: Network Dataset Used to Describe a Navigable Network, the green line shows
an example of what a shortest path algorithm could determine if asked to find the shortest route
between CSZID1 and CSZID5 based on the lengths of the chains. First, the algorithm would
move to CSZID2 via the chain CSLID1; when at CSZID2 it has two alternatives, either take
CSLID4 or use CSLID3 and CSLID6. In our example it would have determined that the latter
alternative is the shortest path; the entity would then follow the path given by the green line
going through all the segments in the chains.
CSLID chainID
CSZID Node ID

CSZID1CSLID1v
CSZID2v

CSLID3CSZID3v
CSLID6
CSLID4v

CSLID2CSZID5v

CSZID4v
v

CSLID5CSZID6

Figure A-33: Network Dataset Used to Describe a Navigable Network

A.20.3
Point Feature Radar Simulation Example
The following diagram represents a typical usage of a point feature as modeled in the CDB for atypical radar client-device. The radar client-device extracts the point feature from the databaseusing the format described in the Specification and constructs an object. The constructed object
will contain the necessary information for the radar to compute the equivalent radar image using
the radar cross-section (RCS) of the object over the terrain; the RCS is derived from the point
features characteristics.

© 2015 Open Geospatial Consortium

81

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
NOTE: The example below illustrates the use of point-feature data by a radar client-device.
However, we recommend that the radar client-devices use the modeled
representation of the feature rather than the feature location, type and attribution
data.

In Figure A-34: Objects Represented on a Terrain Tile, a series of different objects are
represented on a terrain tile. The objects are modeled as single point of zero dimensions in radar.
The radar will position the different points according to their geographic position and altitude.
The height data corresponds to a height of the feature with respect to the terrain.

Figure A-34: Objects Represented on a Terrain Tile

The necessary information needed by radar is typically:
6.

7.

Feature Attribution Code (FACC):
This information indicates if the feature is a tree, a pylon, or a church forexample. In the above drawing this would mean a tree, an industry, ahouse or a radio station antenna.
Composite Material IndeX (CMIX):
The Composite Material IndeX attribute points to the Composite Material
Table and provides the Radar client-device with the type of material thatthe feature is made of. This information is used, in addition to the width© 2015 Open Geospatial Consortium82

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

8.

9.

10.

11.

of the point feature, to provide a generic RCS of the target, which is
proportional to the reflection value of the various materials. The RCS isthen used by radar to determine the intensity of the radar image
representing the point feature, based on the aspect and grazing angles to
the Radar Beam. Each point contains a reference to a Composite Material.
Bounding Sphere Radius (BSR):
The radius of the point is also taken into consideration. This information
is part of the shape data used to construct a 2D radar image of the terrain.
The width is part of the point object attributes.
Height (HGT):
Since the radar sees the terrain with a perspective angle that can becomputed using the radar altitude and the feature distance, the height ofobjects on the terrain becomes important to create the radar display image.
This attribute of the point is used to indicate the differential height of eachpoint with respect to the terrain height. In the example above, the trees all
have the same average altitude. The other point features have different
height.
Position:
The object point location in the CDB. The x and y coordinate of eachpoint is extracted from those objects. The position when combined withthe delta heights will create a pseudo-3D point feature object.
Orientation (AO1):
The radar needs the orientation of each point feature. This is needed
because radar has a series of RCS tables, one for each of the Feature
Identification Code. Those RCS tables give the RCS value for each
incident angle of the radar beam. This angle is computed by taking into
account the radar beam angle and the point feature orientation. For
example, in the above drawing, the radio antenna has an orientation of 90
degrees. This means that if a radar beam comes from the right and points
to the antenna at 270 degrees, the RCS value will be at maximum. The
radar simulation would use a RCS table that represents the RCS withrespect to the incident angle as follows:

Figure A-35: Incident Angle© 2015 Open Geospatial Consortium83

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

Figure A-36: Beam Simulation

The radar then uses a beam simulation to process the above information and construct an image
representing the content of each small beam sections. The intersection of the beam pie slice iscompared with the point’s position and converted into an image whose intensity is based on thecomputed RCS of the points. As mentioned above, this RCS takes into account the attributes ofeach point feature.
If the size of the object referred to by the point feature is much larger than a specific threshold,the simulation could in addition use the MODL field of that point feature to extract a more
precise geometrical 3D model from the CDB to increase the simulation fidelity.
A.20.4
Areal Feature Radar Simulation Example
The following diagram represents a typical usage of an areal feature as modeled in the CDB for aradar client-device.
NOTE:

With the introduction of version 3.2 of the CDB Specification,we recommend that theterrain-conformal features be modeled using T2DModels and that radar clientdevices use this modeled representation instead of the vector linear and areal
features.

In a manner similar to the lineal example, the Radar extracts this areal (aka polygon or polyline)from the database using the Shape (*.shp) file and construct a tile in its memory. The
constructed tile will contain the necessary information for the radar to compute the equivalentradar image using the radar cross-section (RCS) of the represented surface polygon over the
terrain intersecting the Radar beam.

© 2015 Open Geospatial Consortium

84

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
In Figure A-37: Four Areal Features Stored in the Tile, four areal features are stored in the tile
with their surface material and feature classification attributes. Each of the features points to anarray of segments.

Figure A-37: Four Areal Features Stored in the Tile

The radar simulation uses the segment coordinates to construct a polygonal representation on theradar image. It extracts the areal feature attribute information from the segments and constructs
its tile data in memory. The necessary information needed by the radar simulation is typically:
12.

13.

Feature Classification Code (FACC):
This information is the identification of the surface feature. It indicates if
the areal feature represents a forest, a lake, or an airport runway forexample. In the above drawing, this would translate to a forested area, agrassy area, a concrete section and a dual runway intersection.
Composite Material IndeX (CMIX):
The Composite Material IndeX Surface Material Code attribute points to
the Composite Material Table and provides to the Radar with the type ofmaterial that the feature is made of. This information is used, in addition
to the shape of the areal feature, to provide a generic RCS of the simulated
area. This RCS is proportional to the reflection value of the various
materials constituting the polygon or the simulated texture of its
components (e.g., an industrial area made up of metallic roofs). The RCS© 2015 Open Geospatial Consortium

85

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014is then used by radar to determine the intensity of the radar image
representing the areal feature, based on the aspect and grazing angles to
the Radar Beam. Each chain will contain a reference to a material
namespace object in the CDB.
14.
Height (HGT):
Normally, the radar simulation sees the terrain with a perspective angle
that can be computed using the radar altitude and the feature distance.
Because of this angle, the height of objects on the terrain becomes
important to create the image that the radar “sees”. This attribute of thechain is used to indicate the average height of each areal object. In theexample above, the forested area could be elevated to roughly 25 or 30
feet to produce a forest ”canopy” which will look elevated to the radar.
The following image shows how a typical radar beam would intersect the different parts of areal
features that are part of the terrain represented previously.
Figure A-38: Radar Beam Simulation, shows the radar using a beam simulation to extract theabove information and construct an image representing the content of each small beam sections(aka bins). The intersection of the beam pie slice is performed against the areal feature polygons.
Then the material of the polygon falling in the beam bin is converted into image intensity, whichis relative to the computed RCS of that polygon’s material. As mentioned above, this RCS takes
into account the attributes of the segment of each areal feature.

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

Figure A-38: Radar Beam Simulation© 2015 Open Geospatial Consortium

87

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

Appendix B
B. TIFF Specification 6.0 – AnnotatedThis document has been annotated to reflect the conventions established by the CDB
Specification. Collectively, these conventions are referred to as TIFF/CDB. The conventions
define how TIFF files are interpreted by a CDB-compliant TIFF reader; the stated conventions
supersede or replace related aspects of this annotated specification. Unless stated otherwise,
CDB-compliant TIFF readers will ignore any data that fails to conform to the stated conventions.

© 2015 Open Geospatial Consortium

89

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

Annotated w ith C DB conventi ons© 2015 Open Geospatial Consortium

90

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

© 2015 Open Geospatial Consortium91

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

© 2015 Open Geospatial Consortium92

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

© 2015 Open Geospatial Consortium

93

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

© 2015 Open Geospatial Consortium

94

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

© 2015 Open Geospatial Consortium

95

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

© 2015 Open Geospatial Consortium

96

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

© 2015 Open Geospatial Consortium

97

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

© 2015 Open Geospatial Consortium98

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

© 2015 Open Geospatial Consortium

99

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

© 2015 Open Geospatial Consortium

100

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

© 2015 Open Geospatial Consortium

101

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

CDB -compl iant TIFF readers do notconsi der TIFF image and DEM datai n big-endian byte order.

© 2015 Open Geospatial Consortium

102

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

© 2015 Open Geospatial Consortium

103

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

© 2015 Open Geospatial Consortium

104

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

TIFF/ CDB
Readers:
The
CDB
Specif ication does not take advantage ofmul tipl e im ages per TIF F f il e.

© 2015 Open Geospatial Consortium

105

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

CDB -compl iant TIFF readersconsi der bi-level i mage data.

do

not

CDB -compl iant TIFF readers do
consider W hiteIsZero image data.

not

CDB -compl iant TIFF readers do
consider compressed TIFF im age.

not

© 2015 Open Geospatial Consortium

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

The CD B speci fi cati on recomm ends t hat
theproduct
ofImageLength
andImageWidth be less than 4,194,304 (2K x
2K).
CDB -compliant TIFF readers require thi sfield to be a power of 2. Im ageLengthneed not be equal to ImageWi dth.

CDB -compliant TIFF readers require thi sfield to be a pow er of 2. ImageWi dthneed not be equal to ImageLengt h.

CDB -compl iant TIFF readersconsi der this TIFF tag.

do

not

© 2015 Open Geospatial Consortium

107

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

CDB -compl iant TIFF readersconsi der this TIFF tag.

do

not

CDB -compliant TIFF readersconsi der this TIFF tag.

do

not

© 2015 Open Geospatial Consortium

108

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

© 2015 Open Geospatial Consortium

109

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

© 2015 Open Geospatial Consortium

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

CDB -compl iant TIFF readers do
consider compressed TIFF im age.

not

© 2015 Open Geospatial Consortium

111

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

CDB -compl iant TIFF readers do notconsi der palette -color i mages,i.e.
Photometri cInterpretati on=
3(P l tt C l )CDB -compliant TIFF readers do notconsi der palette -color im ages; as a result,
this tag is ignored.

© 2015 Open Geospatial Consortium

112

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

© 2015 Open Geospatial Consortium

113

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

© 2015 Open Geospatial Consortium

114

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

CDB -compl iant TIFF readers consi der
only type ‘II’, (l ittle-endian) byte ordereddata.

The CDB specif i cat ion does not t ake
advantage of m ultiple i mages per fil e.

© 2015 Open Geospatial Consortium

115

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

CDB -compliant T IFF readers requi reImageWidth and ImageLength fiel ds t o bea power of 2. Im ageW i dth need not be
the same as ImageLength.
C DBcompl iant TIFF readers do not consi derdata that does not conf orm to thi si

CDB -compliant TIFF readers do notconsi derthe
XResolution
andYResoluti on TIFF tags.

CDB -compliant TIFF readers do notconsi der the ResolutionUni t TIFF tag.

© 2015 Open Geospatial Consortium

116

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

CDB -compl iant TIFF readersconsi der the Artist TIFF tag.

do

not

© 2015 Open Geospatial Consortium

117

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

CDB -compliant TIFF readers do notconsi der the Cell Length TIFF tag.
The lengt h of the di thering or hal f toni ng
mat rix used to create a dithered orhalf t oned bil evel fi le. Tag = 265 (109. H)
Type = SHOR T N = 1 Thi s f iel d shoul donly be present if Threshhol ding = 2 N o
d f lt Sl
Th
hh l di

CDB -compl iant TIFF readers do
consi der the Cell W idth TIFF tag.

not

CDB -compliant TIFF readers do
consi der the ColorM ap TIFF tag.

not

© 2015 Open Geospatial Consortium

118

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

CDB -compl iant TIFF readers do
consider compressed TIFF im age.

not

© 2015 Open Geospatial Consortium

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

CDB -compliant TIFF readers do
consi der the Copyright TIFF tag.

not

CDB -compliant TIFF readers do
consider the DateTi me T IFF tag.

not

© 2015 Open Geospatial Consortium

120

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

CDB -compliant TIFF readers do
consi der unassociated al pha data.

not© 2015 Open Geospatial Consortium

121

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

CDB -compliant TIFF readers do notconsi der the FreeByteCounts TIFF tag.

CDB -compliant TIFF readers do
consider the FreeO ffsets T IFF tag.

not

The CD B speci f icati on assum es that t hegray response curve of TIFF im age fil es
to be l inear. As a result, CDB -compl iant
TIFF readers do not consi der the
GrayResponseCurve Tag data.

The CD B speci f icati on assum es that t hegray response curve of TIFF im age fil es
to be linear. As a result, CDB -compl iant
TIFF readers do not consi der the
GrayResponseUni t Tag data.

© 2015 Open Geospatial Consortium

122

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

CDB -compliant TIFF readers do notconsi der the HostC om puter T IFF tag.

CDB -compliant TIFF readers do notconsi der the ImageD escription TIFF tag.

CDB -compliant T IFF readers requi reImageW idth and Im ageLength fi el ds to bea power of 2. ImageLengt h need not be
the sam e as ImageW idth. CDB -compl iant
TIFF readers do not consider i mage that
does not conform to thi s requirement.

© 2015 Open Geospatial Consortium

123

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

CDB -compliant Ti f f readersconsi der the Make TIFF tag.

do

not

The CDB speci fi cati on establ ishes t hat
the MaxSampleValue to be always equal
to the maxim um value t hat can be
represented by the number format
representation.
As a resul t, C DB compl iant TIFF readers do not consi der

The CDB speci fi cati on establ ishes t hat
the M inSampleValue to be al ways equal
to 0 for im age data and to mini mum valuethat can be represented by the number
form at representation. As a resul t, C DB compl iant TIFF readers do not consi derh Mi Sl TIFF

CDB -compliant TIFF readersconsi der the Model TIFF tag.

do

not

© 2015 Open Geospatial Consortium

124

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

The CD B speci f icati on assum es that t hedata i s full or reduced resol uti on only.
As a result, CDB-compl iant TIFF readers
only consi der i mages and DEM s datawhose
P hotometri cInterpretati on
Tag
l
i 1
2

The CD B speci f icati on assum es that t hedata i s organized such t hat t he 0t h row
represents the visual top of the grid data(or image), and the 0th col umn represents
the vi sual l eft -hand side. As a resul t ,CDB -compliant TIFF readers do notconsi der im age and DEM data whose© 2015 Open Geospatial Consortium

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

CDB -compliant
T IFF
readers
onl yconsideri mages
whose
Phot om etricInterpretation Tag val ue is 1
2
CDB -compliant TIFF readersconsider W hiteIsZero i mages.

do

not

CDB -compliant TIFF readers do notconsi derpalette -colori mages,i .e.
Phot om etricInterpretation = 3 (Pal ette
C l )CDB -compliant simul ator T IFF readers
do not consi der transparency maski magery
data,
i .e.
Phot om etricInterpretation=
4© 2015 Open Geospatial Consortium

126

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

The CD B speci fi cati on establi shes a seri esof conventi ons that govern the resoluti on
of TIFF fil es. As a result, CD B-compl iant
TIFF readers do not consi der the
ResolutionUni t TIFF tag.

© 2015 Open Geospatial Consortium

127

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

CDB -compliant TIFF readersconsi der the Software TIFF tag.

do

not

© 2015 Open Geospatial Consortium

128

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

© 2015 Open Geospatial Consortium

129

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

CDB -compliant TIFF readers do notconsi der i mage whose Subfil e type = 3.

CDB -compliant TIFF readers do notconsi der im age data w hose Thresholdi ng
TIFF tag is not equal 1.

The CD B speci fi cati on establi shes a seri esof conventi ons that govern the resoluti on
of TIFF fil es. As a result, CDB -compl iant
TIFF readers do not consi der this T IFF
tag.

The CD B speci fi cati on establi shes a seri esof conventi ons that govern the resoluti on
of TIFF fil es. As a result, CDB -compl iant
TIFF readers do not consi der this TIFF
tag.

© 2015 Open Geospatial Consortium

130

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

CDB -compliant TIFF readers do notconsider PackBits com press ed TIFF data.
As a resul t, secti on 9 is not appli cable to
CDB -compliant TIFF readers.

© 2015 Open Geospatial Consortium

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

CDB -compliant TIFF readers do notconsi der Modi fied Huffm an com pressed
TIFF data. As a resul t, secti on 10 i s notappli cabletoC DB-compl iant
TIFF
readers© 2015 Open Geospatial Consortium

132

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

© 2015 Open Geospatial Consortium

133

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

© 2015 Open Geospatial Consortium

134

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

© 2015 Open Geospatial Consortium

135

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

© 2015 Open Geospatial Consortium

136

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

© 2015 Open Geospatial Consortium

137

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

CDB -compliant TIFF readers do notconsider CC ITT Bi -l evel encoded TIFF
data.
As a resul t, section 11 i s notappli cabletoC DB-compl iant
TIFF
d© 2015 Open Geospatial Consortium

138

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

© 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

© 2015 Open Geospatial Consortium

141

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

© 2015 Open Geospatial Consortium

142

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

© 2015 Open Geospatial Consortium

143

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

CDB -compliant TIFF readers do notconsider all TIFF tags related to
document storage and retri eval . As aresult, section 12 is not appl icabl e to
CDB -compliant TIFF readers.

© 2015 Open Geospatial Consortium

144

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

© 2015 Open Geospatial Consortium

145

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

© 2015 Open Geospatial Consortium

146

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

© 2015 Open Geospatial Consortium

147

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

© 2015 Open Geospatial Consortium

148

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

© 2015 Open Geospatial Consortium

149

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

© 2015 Open Geospatial Consortium

150

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

© 2015 Open Geospatial Consortium

151

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

© 2015 Open Geospatial Consortium

152

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

CDB -compliant Ti ff readers do notconsiderDifferencing
Predictor
compressed TIFF data.
As a result,section 14 i s not appl i cabl e to C DBcompl iant TIFF readers© 2015 Open Geospatial Consortium

153

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

© 2015 Open Geospatial Consortium

154

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

© 2015 Open Geospatial Consortium

155

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

© 2015 Open Geospatial Consortium

156

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

© 2015 Open Geospatial Consortium

157

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

CDB -compl iant TIFF readers do notconsider CM YK encoded color i mage
TIFF i mage data. A s a result, secti on 16
i s not appli cable to CDB -compl iant TIFF

© 2015 Open Geospatial Consortium

158

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

© 2015 Open Geospatial Consortium

159

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

© 2015 Open Geospatial Consortium

160

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

CDB -compl iant TIFF readers do notconsi der any of the TIFF tags related tohalf t one hints. As a resul t, secti on 17 i s
not appli cabl e to CDB-compl iant TIFF

© 2015 Open Geospatial Consortium

161

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

© 2015 Open Geospatial Consortium

162

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

© 2015 Open Geospatial Consortium

163

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

© 2015 Open Geospatial Consortium

164

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

© 2015 Open Geospatial Consortium

165

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

© 2015 Open Geospatial Consortium

166

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

CDB -compliant TIFF readers do notconsi der unassociated al pha i mage data.

© 2015 Open Geospatial Consortium

167

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

© 2015 Open Geospatial Consortium

168

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

The CDB speci fi cat i on establ ishes theconventions
thatgoverntheSampl eForm at of TIFF im age and DEM
data. As a resul t, CD B-compl iant TIFF
readers do not consi der i mage and DEM
data when the value of the Sam pleFormat
tag does not conform to CDB conventions.

W hil e the above -ment ioned sam ple data
form ats are possible, CDB cl ients expect
i mage and DEM data to be i n the format
as speci fi ed in the C DB conventi ons andconstraints.
CDB -compliant TIFF readers do notconsi der the SMi nSampl eV alue T IFF tag.

© 2015 Open Geospatial Consortium

169

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

CDB -compliant TIFF readers do notconsi der the SMaxSampl eValue TIFF tag.

© 2015 Open Geospatial Consortium

170

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

CDB -compliant TIFF readers do notconsi der any of the TIFF tags descri bes i n
this section.

© 2015 Open Geospatial Consortium

171

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

© 2015 Open Geospatial Consortium

172

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

© 2015 Open Geospatial Consortium173

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

© 2015 Open Geospatial Consortium

174

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

© 2015 Open Geospatial Consortium

175

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

© 2015 Open Geospatial Consortium

176

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

© 2015 Open Geospatial Consortium

177

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

CDB -compliant TIFF readers do notconsider YC b C r color encoded TIFF im age
data.
As a result, secti on 21 i s notappli cabletoC DB-compl iant
TIFF

© 2015 Open Geospatial Consortium

178

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

© 2015 Open Geospatial Consortium

179

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

© 2015 Open Geospatial Consortium

180

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

© 2015 Open Geospatial Consortium

181

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

© 2015 Open Geospatial Consortium

182

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

© 2015 Open Geospatial Consortium

183

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CDB -compl iant TIFF readers do not consider JPEG color encoded TIFF image data. As a resul t,
section 22 i s not appli cabl e to C DB -compliant TIFF readers.

© 2015 Open Geospatial Consortium

184

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

© 2015 Open Geospatial Consortium

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

© 2015 Open Geospatial Consortium

186

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

© 2015 Open Geospatial Consortium

187

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

© 2015 Open Geospatial Consortium

188

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

© 2015 Open Geospatial Consortium

189

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

© 2015 Open Geospatial Consortium

190

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

© 2015 Open Geospatial Consortium

191

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

© 2015 Open Geospatial Consortium

192

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

© 2015 Open Geospatial Consortium

193

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

© 2015 Open Geospatial Consortium

194

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

© 2015 Open Geospatial Consortium

195

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

© 2015 Open Geospatial Consortium

196

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

© 2015 Open Geospatial Consortium

197

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

© 2015 Open Geospatial Consortium

198

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

CDB -compl iant TIFF readers do notconsi der CIE L*a*b* color encoded TIFF
image data. As a result, secti on 23 is notappli cabletoC DB-compl iant
TIFF
d© 2015 Open Geospatial Consortium

199

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

© 2015 Open Geospatial Consortium

200

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

© 2015 Open Geospatial Consortium

201

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

© 2015 Open Geospatial Consortium

202

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

© 2015 Open Geospatial Consortium203

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

© 2015 Open Geospatial Consortium

204

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

© 2015 Open Geospatial Consortium

205

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

© 2015 Open Geospatial Consortium

206

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

© 2015 Open Geospatial Consortium

207

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

© 2015 Open Geospatial Consortium

208

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

© 2015 Open Geospatial Consortium

209

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

© 2015 Open Geospatial Consortium

210

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

Appendix C
C. OpenFlight v16.0 Technical Description - AnnotatedThis document has been annotated to reflect the conventions established by the CDB
Specification. Collectively, these conventions are referred to as OpenFlight/CDB. The
conventions define how OpenFlight files are interpreted by a CDB-compliant OpenFlight reader;the stated conventions supersede or replace related aspects of this annotated specification.
Unless stated otherwise, CDB-compliant OpenFlight readers will ignore any data that fails to
conform to the stated conventions.

© 2015 Open Geospatial Consortium

211

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

OpenFlight
Scene Description
Database Specification®

Annotated with CDB conventions

Version 16.0
Document Revision A
November 2004

© 2015 Open Geospatial Consortium

212

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
OpenFlight Scene Description Database Specification, version 16.0. November, 2004
©2004 MultiGen-Paradigm, Inc.. All trademarks, trade names, service marks and logos referenced herein belong to their respective
companies. All rights reserved.
MultiGen-Paradigm Inc. (MultiGen-Paradigm) PROVIDES THIS MATERIAL AS IS, WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
MultiGen-Paradigm may make improvements and changes to the product described in this manual at any time without notice.
MultiGen-Paradigm assumes no responsibility for the use of the product or this document except as expressly set forth in theapplicable MultiGen-Paradigm agreement or agreements and subject to terms and conditions set forth therein and applicableMultiGen-Paradigm policies and procedures. This document may contain technical inaccuracies or typographical errors. Periodic
changes may be made to the information contained herein. If necessary, these changes will be incorporated in new editions of the
document.
MultiGen-Paradigm, Inc. is the owner of all intellectual property rights in and to this document and any proprietary software that
accompanies this documentation, including but not limited to, copyrights in and to this document and any derivative works therefrom.
Use of this document is subject to the terms and conditions of the MultiGen-Paradigm Software License Agreement included with thisproduct.
No part of this publication may be stored in a retrieval system, transmitted, distributed or reproduced, in whole or in part, in any way,
including, but not limited to, photocopy, photograph, magnetic, or other record, without the prior written permission of MultiGenParadigm, Inc.
Use, duplication, or disclosure by the government is subject to restrictions set forth in subparagraph (c)(1)(ii) of the Rights inTechnical Data and Computer Software clause and DFARS 52.227-7013 and in similar clauses in the FAR and NASA FAR
Supplement.
Printed in the U.S.A.
November 2004

© 2015 Open Geospatial Consortium

213

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
ADOPTER REGISTRATION AGREEMENTFOROPENFLIGHT® SCENE DESCRIPTIONDATABASE SPECIFICATION
The purpose of this agreement is to enable third parties who agree to adopt the MultiGen-Paradigm OpenFlight Scene
Description Database Specification, on a non-exclusive basis, to receive ongoing access to technical updates to OpenFlight.
Registered “Adopters” may also receive marketing support on MultiGen-Paradigm, Inc.'s World Wide Web (WWW) site once
your product is completed. To become a registered adopter, complete and sign this registration form and return to MultiGenParadigm, Inc., 550 S. Winchester Blvd, Ste 500, San Jose, CA 95128, Attn.: OpenFlight Registration c/o Todd Griffith, or fax
thecompleted
form
to
(408)
878-0895.
_________________________________________________________________________,

whose

place

of

businessis______________________________________________________________________________, (hereinafter “User”)
desires to obtain a copy of the OpenFlight Scene Description Database Specification (hereinafter “OpenFlight”). OpenFlight
contains information belonging to MultiGen-Paradigm, Inc., a California corporation located in San Jose, California. The parties
wish to define their rights with respect to OpenFlight. Therefore, it is agreed as follows:
OpenFlight is the property of MultiGen-Paradigm, Inc. and is protected under the copyright and trademark laws of the UnitedStates of America. MultiGen-Paradigm, Inc. hereby grants to User a non-exclusive, non-transferable limited right to use
OpenFlight as follows:a.

For reading OpenFlight into a computer program or database for in-house use, or as a feature of a commercial
product.

b.

For writing data from a computer program or database into OpenFlight for in-house use or as a feature of acommercial product.

Any attempt to sub-license, assign, or transfer all or any part of the OpenFlight Specification is prohibited without the priorwritten consent of MultiGen-Paradigm, Inc.
OpenFlight, MultiGen and Creator are registered trademarks of MultiGen-Paradigm, Inc. User agrees to indicate that MultiGenParadigm, Inc. is owner of its own trademarks in any of User's published references to such trademarks. User shall not at any
time use any name or trademark which is confusingly similar to a MultiGen-Paradigm, Inc. trademark.
OPENFLIGHT IS OFFERED FOR USE BY USER “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. ALL SUCH WARRANTIES ARE EXPRESSLY AND SPECIFICALLYDISCLAIMED. IN NO EVENT SHALL MULTIGEN-PARADIGM, INC. BE RESPONSIBLE FOR ANY INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF USE OF OPENFLIGHT.
Adopter (User):
Signature ______________________________________________ Date ____________________________________
Print Name __________________________________________ Title _______________________________________

OpenFlight® Scene Description Database Specification version 16.0 (November, 2004)© 2015 Open Geospatial Consortium

214

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

Contents
OpenFlight Concepts .................................................................................................................. 9
Database Hierarchy ..................................................................................................................... 9Node Attributes ......................................................................................................................... 12
Palettes ...................................................................................................................................... 12
Instancing .................................................................................................................................. 13
Replication. ............................................................................................................................... 14
Bounding Volumes ................................................................................................................... 14
Multitexture............................................................................................................................... 14
OpenFlight Record Types ......................................................................................................... 15
Control Records ........................................................................................................................ 16
Hierarchy Level Change Records ............................................................................................. 16
Push Level Record ............................................................................................................ 17
Pop Level Record .............................................................................................................. 17
Push Subface Record ........................................................................................................ 17
Pop Subface Record .......................................................................................................... 17
Push Extension Record .................................................................................................... 17
Pop Extension Record. ...................................................................................................... 17
Push Attribute Record. ..................................................................................................... 18
Pop Attribute Record. ....................................................................................................... 18
Hierarchy Instancing Records. .......................................................................................... 18
Instance Definition Record ............................................................................................... 18
Instance Reference Record. .............................................................................................. 19
Node Primary Records .............................................................................................................. 19
Header Record ................................................................................................................. .19
Group Record.. ................................................................................................................. .22
Object Record. ................................................................................................................. .25
Face Record. .................................................................................................................... .26
Mesh Nodes ...................................................................................................................... 28
Mesh Record. .......................................................................................................... . 29
Local Vertex Pool Record. ........................................................................................ 30
Mesh Primitive Record. ............................................................................................ 32
Light Point Nodes ............................................................................................................. 34
Indexed Light Point Record. .................................................................................... 34
Light Point Record. .................................................................................................. 34
Light Point System Record. .............................................................................................. 37
Degree of Freedom Record ............................................................................................... 37
Vertex List Record ............................................................................................................ 39
Morph Vertex List Record. ............................................................................................... 39
Binary Separating Plane Record ....................................................................................... 40
External Reference Record. .............................................................................................. 41
Level of Detail Record ...................................................................................................... 41
Sound Record .................................................................................................................... 43
Light Source Record ......................................................................................................... 44
Road Segment Record....................................................................................................... 44
Road Construction Record. ............................................................................................... 45
Clip Region Record.......................................................................................................... .47
Text Record ....................................................................................................................... 47
Switch Record. .................................................................................................................. 49
CAT Record ...................................................................................................................... 50
Extension Record. ............................................................................................................ .51
Curve Record .................................................................................................................... 51
Ancillary Records .................................................................................................................... .52
Comment Record .............................................................................................................. 53
Lond ID Record ................................................................................................................ 53
Indexed String Record ...................................................................................................... 53
Multitexture....................................................................................................................... 54
Multitexture Record ................................................................................................. 54
UV List Record ........................................................................................................ 55© 2015 Open Geospatial Consortium

215

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Replicate Record ............................................................................................................... 57
Road Zone Record ............................................................................................................ 58
Transformation Records.................................................................................................... 58
Matrix Record .......................................................................................................... 59
Rotate About Edge Record ...................................................................................... 59
Translate Record ...................................................................................................... 59
Scale Record ............................................................................................................ 59
Rotate and/or Scale to Point Record ......................................................................... 60
Put Record ................................................................................................................ 60
General Matrix Record ............................................................................................ 60
Rotate About Point Record ...................................................................................... 60
Vector Record ................................................................................................................... 61
Bounding Volume Records ............................................................................................... 61
Bounding Box Record............................................................................................... 62
Bounding Sphere Record .......................................................................................... 62
Bounding Cylinder Record ....................................................................................... 62
Bounding Convex Hull Record ................................................................................ 62
Bounding Histogram Record ................................................................................... 62
Bounding Volume Center Record ............................................................................ 63
Bounding Volume Orientation Record .................................................................... 63
CAT Data Record ............................................................................................................. 63
Extension Attribute Record............................................................................................... 64
Continuation Record ......................................................................................................... 65
Palette Records.......................................................................................................................... 66
Vertex Palette Records ...................................................................................................... 66
Vertex Palette Record .............................................................................................. 67
Vertex with Color Record ......................................................................................... 68
Vertex with Color and Normal Record .................................................................... 68
Vertex with Color and UV Record .......................................................................... 69
Vertex with Color, Normal and UV Record ............................................................ 69
Color Palette Record ......................................................................................................... 70
Name Table Record .......................................................................................................... 71
Material Palette Record..................................................................................................... 71
Texture Palette Record ...................................................................................................... 73
Eyepoint and Trackplane Palette Record .......................................................................... 73
Key Table Records ............................................................................................................ 76
Linkage Palette Record ..................................................................................................... 77
Sound Palette Record ........................................................................................................ 80
Light Source Palette Record ............................................................................................. 81
Light Point Appearance Palette Record ............................................................................ 82
Light Point Animation Palette Record .............................................................................. 85
Line Style Palette Record.................................................................................................. 85
Texture Mapping Palette Record ...................................................................................... 86
Texture Pattern Files ................................................................................................................. 93
Texture Attribute Files .............................................................................................................. 93
Vertex Node Parameters ......................................................................................................... 103
Face Node Parameters............................................................................................................. 103
Object Node Parameters ......................................................................................................... 104
LOD Node Parameters ............................................................................................................ 104
Group Node Parameters .......................................................................................................... 104
DOF Node Parameters ............................................................................................................ 105
Sound Node Parameters .......................................................................................................... 106
Switch Node Parameters ......................................................................................................... 106
Text Node Parameters ............................................................................................................. 107
Light Source Node Parameters ............................................................................................... 107
Clip Node Parameters ............................................................................................................. 107
Valid Opcodes ......................................................................................................................... 109
Obsolete Opcodes................................... ................. ...............................................................111
Overview ........................................................................................................................ 113
Format Changes ...................................................................................................................... 113
Continuation Record ............................................................................................................... 113© 2015 Open Geospatial Consortium

216

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Header Record ........................................................................................................................ 114
Mesh Nodes ............................................................................................................................ 114
Mesh Record .......................................................................................................................... 115
Local Vertex Pool Record ...................................................................................................... 116
Mesh Primitive Record .......................................................................................................... 118
Multitexture............................................................................................................................. 120
Multitexture Record ............................................................................................................... 120
UV List Record ...................................................................................................................... 122
Texture Attribute File ............................................................................................................. 123
Subtexture .............................................................................................................................. 123
Overview ........................................................................................................................ 125
Document Corrections ............................................................................................................ 125
Text Record ............................................................................................................................. 126
CAT Record ............................................................................................................................ 126
Header Record ........................................................................................................................ 127
Group Record .......................................................................................................................... 128
Level of Detail Record ............................................................................................................ 129
External Reference Record ..................................................................................................... 130
Indexed String Record ............................................................................................................ 130
Face Record ............................................................................................................................ 131
Mesh Record ........................................................................................................................... 131
Local Vertex Pool Record ....................................................................................................... 132
Vertex Palette Records ............................................................................................................ 133
Light Points ............................................................................................................................. 136
Light Point Appearance Palette Record ................................................................................. 136
Light Point Animation Record ............................................................................................... 139
Indexed Light Point Record ................................................................................................... 140
Light Point System Record .................................................................................................... 140
Texture Mapping Palette Record ............................................................................................ 141
Parameters for 3 Point Put Texture Mapping (Type 1 ........................................................... 141
Parameters for 4 Point Put Texture Mapping (Type 2 ........................................................... 141
Overview........................................................................................................................ 143
Document Corrections ............................................................................................................ 143
Header Record ........................................................................................................................ 143
Face Record ............................................................................................................................ 144
Mesh Record ........................................................................................................................... 144
Switch Record ......................................................................................................................... 145
Texture Mapping Palette Record ............................................................................................ 145
Indexed String Record ............................................................................................................ 147
Bounding Convex Hull Record ............................................................................................... 147
Bounding Histogram Record .................................................................................................. 147
Format Changes ...................................................................................................................... 147
External Reference Record ..................................................................................................... 147
Face Record ............................................................................................................................ 148
Mesh Record ........................................................................................................................... 148
Light Point Appearance Palette Record .................................................................................. 148
Shader Palette Record ............................................................................................................. 149
Texture Attribute File ............................................................................................................. 149
Texture Mapping Palette Record ............................................................................................ 150
Parameters for 3 Point Put Texture Mapping (Type 1 ........................................................... 150© 2015 Open Geospatial Consortium

217

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

1

OpenFlight® Scene Description
The following symbols have been used throughout the document to specify theconventions established by OpenFlight/CDB.
ü =The record, field or value is supported by OpenFlight/CDB readers and follows
the same conventions and usage as the OpenFlight Standard = The record, field is not considered by OpenFlight/CDB readers (e.g. ignored) = The record, field or value is specific to MultiGen-Paradigm and therefore is notconsidered by OpenFlight/CDB readers (e.g. ignored) = The value for the specified field is not supported by OpenFlight/CDB readers.
OpenFlight/CDB readers ignore any fields with values that are not supported.

 = The record, field or value is specific to MultiGen’s Creator tool and therefore isnot considered by OpenFlight/CDB readers (e.g. ignored)

This document describes the OpenFlight Scene Description Database Specification, commonlyreferred to as simply “OpenFlight”. OpenFlight is a 3D scene description file format that was
created and is maintained by MultiGen-Paradigm, Inc. While OpenFlight databases are typicallycreated and edited using MultiGen-Paradigm software tools, the format is widely adopted and as
a result, many tools exist to read and write OpenFlight database files.
The primary audience for this document includes software developers whose applications areintended to read and/or write OpenFlight database files. To this end, this document discusses
concepts incorporated in OpenFlight and contains a detailed description of the physical layout of
OpenFlight files as represented on disk.

© 2015 Open Geospatial Consortium

218

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

OpenFlight Concepts
The OpenFlight database format supports both simple and relatively sophisticated real-time
software applications. The full implementation of OpenFlight supports variable levels of detail,degrees of freedom, sound, instancing (both within a file and to external files), replication, animation sequences, bounding volumes for real-time culling, scene lighting features, light points
and light point strings, transparency, texture mapping, material properties, and many other features.
A simple application that interprets an OpenFlight database can implement a subset of thedatabase specification and use databases that contain that subset. Such an application could simply scan for the color palette, faces, and vertices, and ignores groups, objects, and other moresophisticated features.

Database Hierarchy
The OpenFlight database hierarchy organizes the visual database into logical groupings andfacilitates real-time functions such as field-of-view culling, level-of-detail switching, and instancing. Each OpenFlight database is organized in a tree structure.
The database tree structure consists of nodes (historically called beads). Most nodes can havechild nodes as well as sibling nodes. In general, nodes can be thought of in three hierarchicalclasses. Starting from the top of the hierarchy, these three node classes include container nodes,
geometry nodes and vertex nodes.
Container nodes are nodes that impose some logical grouping or behavior on the set of nodes it
contains. The group node, for example allows you to “collect” similar nodes under one common
parent for whatever reason your application needs. You might choose to group your nodes spatially or by some other criteria important to your application. Another common container node,
the level of detail node, imposes a particular visual behavior on the nodes it contains. It defines arange of distances inside which the nodes it contains are visible.
Geometry nodes are nodes that actually represent some physical (renderable) geometry. The attributes of geometry nodes typically include visual attributes such as color, material, texture, etc.
The two main geometry nodes in OpenFlight are the face and mesh nodes. Other geometry nodes
include the light point and text node. Though OpenFlight allows it, there are very few cases inwhich at least one geometry node is not contained somewhere below a container node.
Vertex nodes are the building blocks of geometry nodes. Individually, a vertex node represents a
discrete point in space. Collected together under a geometry node such as a face node, a set ofvertex nodes define a closed (or unclosed) loop. A closed loop of vertex nodes defines a face (orpolygon). The “front” side of the face is determined by the ordering in which the vertex nodes
appear under the face node. An unclosed loop of vertex nodes defines a set of line segments,
again oriented according to the order in which the vertex nodes appear.
Each node type has data attributes specific to its function in the database. The principal nodetypes in OpenFlight are described here:
Header: There is one header node per database file. It is always the first node in the file andrepresents the top of the database hierarchy and tree structure. For more information, see “Header
Record” on page 19.

© 2015 Open Geospatial Consortium

219

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Group: A group node distinguishes a logical subset of the database. Group nodes can be transformed (translated, rotated, scaled, etc.). The transformation applies to itself and to all its children. Groups can have child nodes and sibling nodes of any type, except a header node. For more
information, see “Group Record” on page 22.
Object: An object node contains a logical collection of geometry. It is effectively a low-levelgroup node that offers some attributes distinct from the group node. For more information, see“Object Record” on page 25.
Face: A face node represents geometry. Its children are limited to a set of vertices that describe apolygon, line, or point. For a polygon, the front side of the face is viewed from an in-order
traversal of the vertices. Face attributes include color, texture, material, and transparency. For
more information, see “Face Record” on page 26.
Mesh: A mesh node defines geometric primitives that share attributes and vertices. See For more
information, see “Mesh Nodes” on page 28.
Light point: A light point node represents a collection of light point vertices or a replicated stringof a single light point vertex. A light point is visible as one or more self-illuminated small points
that do not illuminate surrounding objects. For more information, see “Light Point Nodes” onpage 34.
Light point system: A light point system enables you to collect a set of light points andenable/disable or brighten/dim them as a group. For more information, see “Light Point System
Record” on page 37.
Subface: A subface node is a face node that is assumed to be coplanar to, and drawn on top of, its
superface. Subfaces can themselves be superfaces to allow multiple levels of “nesting”. This
construct resolves the display of coplanar faces. A subface is introduced, after a face node, by apush subface control record and concluded by a pop subface control record. Note that the
OpenFlight format does not enforce a subface to be coplanar with its superface but this is recommended.
Light source: A light source node serves as the location and orientation of a light source. The
light source position and direction are transformed by the transformations above it in the tree (ifany). For more information, see “Light Source Record” on page 44.
Sound: A sound node serves as the location for a sound emitter. The emitter position is the soundoffset transformed by the transformations above it in the tree (if any). For more information, see“Sound Record” on page 43.
Text: A text node draws text in a string with a specified font, without injecting the actual geometry into the database as face nodes. This is a leaf node and therefore cannot have any children.
For more information, see “Text Record” on page 47.
Vertex: A vertex node represents a point in space, expressed as a double precision 3D coordinates. Each vertex is stored in the vertex palette record. Vertex attributes include x, y, z andoptionally include color, normal and texture mapping information. Vertex nodes are the childrenof face nodes and light point nodes. For more information, see “Vertex List Record” on page 39,“Morph Vertex List Record” on page 39 and “Vertex Palette Records” on page 66.
Morph vertex: A morph vertex node is a second vertex node. The vertex and morph vertex represent the two endpoints of a path between which the actual vertex may be interpolated. One
endpoint represents the minimum (non morphed) weighting and the other represents the maximum (fully morphed) weighting. Each endpoint (or weight) is a reference into the vertex paletterecord. All vertex attributes may be morphed. Morph vertex nodes are the children of face nodes.

© 2015 Open Geospatial Consortium

220

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
For more information, see For more information, see “Morph Vertex List Record” on page 39.
Clip region: A clip node defines a set of clipping planes. Any geometry, of the clip node’s children, that falls outside the specified clipping planes is not displayed. For more information, see“Clip Region Record” on page 47.
Degree of freedom: A degree of freedom (DOF) node serves as a local coordinate system with apredefined set of internal transformations. It specifies the articulation of parts in the database andset limits on the motion of those parts. For more information, see “Degree of Freedom Record”
on page 37.
Level of detail: A level of detail (LOD) node serves as a switch to turn the display of everything
below it on or off based on its range from the viewer, according to its switch-in, switch-out distance and center location. For more information, see “Level of Detail Record” on page 41.
Switch: A switch node is a more general case of an LOD node. It allows the selection of zero or
more children by invoking a selector mask. Any combination of children can be selected permask and the number of definable masks is unlimited. For more information, see “Switch
Record” on page 49.
External reference: An external reference node serves to reference a node in another database
file, or an entire database file. The referenced (child) node or database is considered an externalpart of the referencing (parent) database. For more information, see “External Reference Record”
on page 41.

Node Attributes
Nodes in the OpenFlight scene contain attributes whose values describe different properties orcharacteristics of the node. Most attributes are represented directly on the node itself and are
geared toward describing the specific characteristics of that type of node. The level of detail(LOD) node, for example, defines a switch in and switch out distance. Used together, these distances define a range within which the geometry contained in the LOD is visible.
Other attributes are represented indirectly on a node, using a lookup index into a table (palette) of
attributes to describe the characteristics of a node. The face node, for example, defines several
indirect attributes, including color index, material index and texture index. The values of theseindex attributes are used to map specific colors, materials and textures to the face node. The
definitions of the colors, materials and textures referenced by these index attributes are stored inpalettes in the database rather than directly on the nodes themselves.
This mechanism of indirect attribute mapping via palettes has some advantages. It can both save
space in the OpenFlight file and can simplify the task of making global changes to nodes in the
database.
To see how this indirection saves space, consider the material index attribute on the face node. A
material is defined by over 15 separate color and other visual attributes. If each of these attributes
were maintained per face in the database, the size of the database would get large quickly. Since
it is common to map a single material to hundreds (or even thousands) of faces in the database, it
is much more efficient to store a single material index attribute per face rather than storing theentire material definition.
Also, in terms of changing the appearance of a particular material in your database, when you dochange the material definition in the palette, the faces that reference that material get updated© 2015 Open Geospatial Consortium

221

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
automatically. This can make global changes much more simple to accomplish.

Palettes
In the previous section, indirect attribute mapping was introduced. As part of that discussion, thenotion of database palettes was also mentioned briefly. In fact, indirect attribute mapping is notpossible without a robust implementation of database palettes. A database palette is a collection(or set) of attribute definitions. As mentioned in the previous section, the material palette defines
a set of materials, each material being composed of several different color and visual attributes.
The OpenFlight database supports many different palettes. The most obvious palettes are thecolor, material and texture palettes. Most palettes support variable numbers of elements whileothers enforce fixed size constraints. The material and texture palettes are both variable sized
palettes that can contain zero or more entries. The color palette, in contrast, is a fixed size palettethat contains exactly 1024 entries.
Database palettes are not limited to supporting indirect attribute mapping. The vertex palette forexample, defines a set of “shared” vertex nodes that can be indirectly referenced by multiple faces
and/or light point nodes in the database. Similar to the space savings achieved by attributepalettes, the vertex palette also saves much disk space in the OpenFlight file when many geometry nodes share references to the same exact point in space (vertex).
All the database palettes supported by OpenFlight are described in “Palette Records” on page 66.
Specific palettes in OpenFlight include:[”Color Palette Record” on page 70[”Material Palette Record” on page 71[”Texture Palette Record” on page 73[”Texture Mapping Palette Record” on page 86[”Sound Palette Record” on page 80[”Line Style Palette Record” on page 85[”Light Source Palette Record” on page 81[”Light Point Appearance Palette Record” on page 82[”Light Point Animation Palette Record” on page 85[”Vertex Palette Records” on page 66[”Name Table Record” on page 71[”Eyepoint and Trackplane Palette Record” on page 73[”Linkage Palette Record” on page 77

Instancing
Instancing is the ability to define all or part of a database once, then reference it one or moretimes while applying various transformations. This allows you to define a piece of geometry onceand place it multiple times in the scene. OpenFlight supports internal and external instancing with
operations such as Rotate, Translate, Scale, and Put.
An internal instance is a subtree of the database that has been declared as an instance definition.
An instance definition represents the root of a stand-alone subtree within the database. It is introduced by an instance definition record that contains a unique instance definition number. An
instance definition is invoked by an instance reference record in a subsequent part of the database© 2015 Open Geospatial Consortium

222

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014tree.
An external instance refers to an entire database file. It is introduced by an external reference
node. An external reference node contains the name of the (child) database file to attach to thatpoint in the referencing (parent) database tree. It also includes attributes that determine whether
the child uses its own color, material, and texture palettes, or those of its parent.
Instance definitions can themselves contain instance definitions and references. Internal instances
cannot reference themselves. External instances should not reference themselves directly or
indirectly. The result of such use is undefined.
Instance definition and instance reference records are described in “Hierarchy Instancing
Records” on page 18. External reference records are described in “External Reference Record” onpage 41.

Replication
Replication instances a subtree of the database several times, applying a transformation eachtime. For example, a string of trees can be represented by a single group node that is instantiatedand translated to a new position several times.
Replication is legal for group, face, and light point nodes. Therefore a replication record is anancillary record of a group, face, or light point node. In conjunction with a replication record
there will be one or more ancillary transformation records.

Bounding Volumes
Bounding volumes can be used by the application to determine if a particular subtree of the database is in view. A bounding volume can be a box, a sphere, or a cylinder. Each group node canhave only one bounding volume. The volume normally encompasses the full geometric extent of
the group node’s children, including any instances and replications. A bounding volume record isan ancillary record of a group node.

Multitexture
OpenFlight supports eight textures per polygon or mesh as well as eight uv values per vertex. The
texture information stored directly on the face, mesh and vertex record is referred to as “the basetexture” or “texture layer 0”. Each additional texture layer is stored in ancillary records to theface, mesh and vertex list records and is referred to as “texture layer N” (for N=1..7). See“Multitexture” on page 54 for more information.

© 2015 Open Geospatial Consortium

223

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

2

OpenFlight File Format
The hierarchical structure of an OpenFlight database is stored on disk as a file. The fileconsists of a linear stream of binary records. Byte ordering in the file is big endian. All
OpenFlight records begin with a 4 byte sequence. The first two bytes of this sequence
identifies the record type (opcode) and the second two bytes specify the length of the record.
Note that the length includes this 4 byte sequence so the minimum length of any record(that does not contain any additional data) will be 4. Given this very regular structure,
OpenFlight records can be read from disk and parsed easily.
WAll OpenFlight records are a multiple of 4 bytes in length. When a record contains less than anfull multiple of 4 bytes of data, the record is padded up (bytes added to the end of the record) to
be a multiple of 4 bytes in length. In some cases, OpenFlight records are padded up to be
multiples of 8 bytes in length.
WThe length of all records (and fields in all records) as well as the offset of all fields are expressedin bytes.
WUnless explicitly stated otherwise, bit fields and masks are counted starting at 0 (i.e., the first bit
is bit number 0).
WUnless explicitly stated otherwise, the elements of matrix records stored in OpenFlight appear inrow major order. That is, the elements of the matrix appear in the following order:
row0col0, row0col1, row0col2, row0col3,
row1col0, row1col1, row1col2, row1col3,
row2col0, row2col1, row2col2, row2col3,
row3col0, row3col1, row3col2, row3col3

WThe length of all OpenFlight records is limited to the largest value that can be encodedwith 2 bytes or 16 bits (65535). For fixed-size records, this maximum size is sufficient. For
variable-size records, this limitation is addressed with the Continuation Record. For more
information, see “Continuation Record” on page 65.

OpenFlight Record Types
There are four major categories of records: control records, node primary records,
ancillary records and continuation records.
Control records mark the hierarchy of the tree. A push control record (a record containing
the push opcode) indicates an increase in the depth of the tree. A push control record drops
you down one level in the tree. A pop control record (a record containing a pop opcode)
returns you to the previous level of hierarchy. All records between a push and a pop
represent sibling nodes at the same level of hierarchy. Other control records include:
instance definition, instance reference, push subface, pop subface, push attribute, and pop
attribute.
Each node is represented on disk by one primary record and zero or more ancillary
records. The primary record identifies a node type and includes most of the node attributedata. Additional node attributes, such as comments, long ID, and transformations, arestored in subsequent ancillary records. Ancillary records follow the primary record, but
precede any control records. Child nodes are introduced by a push control record and areconcluded by a pop control record.

© 2015 Open Geospatial Consortium

224

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Palette records are ancillary records of the header node. Palette records generally follow theheader node’s primary record, with the exception of behavior (linkage) palette records.
Behavior palette records, if present, are the last (non-control) records in the file.
Continuation records are used to “continue” a record in the OpenFlight Scene Description
file stream, when the original record is larger than 65535 bytes. The continuation record
appears in the stream immediately following the record that it “continues”. The datacontained in the continuation record is defined by the original record and is assumed to be
directly appended onto the content of the original record. Multiple continuation records may
follow a record, in which case all continuation records would be appended (in sequence) to theoriginal record
Many records include an eight character ASCII ID consisting of the first seven charactersof the node name plus a terminating <nil> character. If the node ID is longer than sevencharacters, an ancillary long ID record containing the complete ID follows the node
primary record.
For example, a record with an object opcode is followed by a push control record. Next
comes a record with a face opcode, also followed by a push control record. After that comesthe vertex list record(s) that describe the vertices of the face, and then a pop control record.
This, in turn, may be followed by another face record for the next face in the same object,
or by a pop record to return to object level.
The fields within each OpenFlight record are stored in big-endian byte order. OpenFlightdatabase files have the extension “.flt” by convention.

Control Records
Control records indicate a change in the level of the database hierarchy. The three basic
types of control records are: level changes, instance definition, and instance reference. Level
changes are indicated by push and pop control records. Instance definitions and references
are indicated by instance definition and instance reference control records.
Hierarchy Level Change Records
A database contains three distinct types of hierarchy: generic, subface, and attribute.
Hierarchy may be skipped by scanning past the push control record for the corresponding
pop control record.
Generic

A push level control record introduces a generic subtree of the databasehierarchy. A pop level control record concludes that subtree.

Subface

A push subface control record introduces a subtree of coplanar faces. A pop
subface control record concludes that subtree.

Extension A push extension control record introduces a subtree of user defined records.
A pop extension control records concludes that subtree.
Attribute

A push attribute control record introduces a subtree of records reserved forinternal use by MultiGen-Paradigm, Inc.. A pop attribute control record
concludes that subtree.

Push Level Record© 2015 Open Geospatial Consortium

225

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

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Push Level Opcode 10
Length - length of the record

CDB OpenFlight
Readerüü

Pop Level Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Pop Level Opcode 11
Length - length of the record

CDB OpenFlight
Readerüü

Push Subface Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Push Subface Opcode 19
Length - length of the record

CDB OpenFlight
ReaderüüPop Subface Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Pop Subface Opcode 20
Length - length of the record

CDB OpenFlight
Readerüü

Push Extension Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Unsigned
Int

0
2

2
2

Push Extension Opcode 21
Length - length of the record

4
22

18
2

Reserved
Vertex reference index; -1 if
not vertex extension© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader
ü
ü




226

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Pop Extension Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Unsigned
Int

0
2

2
2

Pop Extension Opcode 22
Length - length of the record

4
22

18
2

Reserved
Vertex reference index; -1 if
not vertex extension

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Int

0
2

2
2

Push Attribute Opcode 122
Length - length of the record

44Vertex reference index; -1 if
not vertex attribute

CDB OpenFlight
Reader
ü
ü




Push Attribute Record
CDB OpenFlight
Readerüü

Pop Attribute Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Pop Attribute Opcode 123
Length - length of the record

CDB OpenFlight
Readerüü

Hierarchy Instancing Records
An instance definition record introduces a stand-alone subtree of the database. The subtree
is referenced one or more times from different branches in the database by instancereference records. At the point of reference, the subtree is copied (or possibly shared) as achild of the current parent node.
The instance definition record must appear in the file stream prior to the first instancereference record that references it. A typical usage of these records might look like:
INSTANCE DEFINITION 1
PUSH
The records between this PUSH and POP define thestand-alone subtree that is INSTANCE DEFINITION 1
POP
...
GROUP
MATRIXPUSH
INSTANCE REFERENCE 1
POP
GROUP
MATRIX© 2015 Open Geospatial Consortium

227

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
PUSH
INSTANCE REFERENCE 1
POP

In this example, both groups reference instance definition number 1, each presumably
applying a different matrix to place the instance in different locations in the scene.

Instance Definition Record
Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
Int

2

2

Instance Definition Opcode
62
Length - length of the record

4
6

2
2

Reserved
Instance definition number

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
Int

2

2

Instance Reference Opcode
61
Length - length of the record

4
6

2
2

Reserved
Instance definition number

CDB OpenFlight
Reader
ü
ü


ü

Instance Reference Record
CDB OpenFlight
Reader
ü
ü


ü

Node Primary Records
Header Record
The header record is the primary record of the header node and is always the first record in
the database file. Attributes within the header record provide important information about
the database file as a whole.
Format revision level indicates the OpenFlight version of the file. Correctly interpreting theattributes of other records, such as the face and vertex records, depends upon the format
revision. The format revision encompasses both Flight and OpenFlight versions.

© 2015 Open Geospatial Consortium

228

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Some representative values for format revision are:Format Revision Value
11
12
14
1420
1510
1540
1550
1560
1570
1580
1600

Flight/OpenFlight Version
Flight V11
Flight V12
OpenFlight v14.0 and v14.1
OpenFlight v14.2
OpenFlight v15.1
OpenFlight v15.4
OpenFlight v15.5
OpenFlight v15.6
OpenFlight v15.7
OpenFlight v15.8
OpenFlight v16.0

CDB OpenFlight Reader











ü

This document describes OpenFlight version 16.0, therefore the attribute descriptions are
based upon a format revision level of 1600.
Geographic attributes such as projection type, latitude, and longitude may be stored in theheader record. The MultiGen Series II and Creator Terrain options set the value of these
attributes when creating terrain databases. Positive latitudes reference the northernhemisphere and negative longitudes reference the western hemisphere.
Delta x, y and z attributes indicate the placement of the database when several separate
databases, each with a local origin of zero, are used to represent an area.

© 2015 Open Geospatial Consortium

229

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

Data Type

OffsetLengthInt
Unsigned Int
Char

0
2
4

2
2
8

Int
Int
Char
Int
Int
Int
Int
Int
Int

12
16
20
52
54
56
58
60
62

4
4
32
2
2
2
2
2
1

Int
Int

63
64

1
4

Int
Int

68
92

4*6
4

Int
Int
Int

96
124
126

4*7
2
2

Header Record

Description

Header Opcode 1
Length - length of the record
7 char ASCII ID; 0 terminates(usually set to “db”)
Format revision level
Edit revision level
Date and time of last revision
Next Group node ID number
Next LOD node ID number
Next Object node ID number
Next Face node ID number
Unit multiplier (always 1)
Vertex coordinate units
0 = Meters
1 = Kilometers
4 = Feet
5 = Inches
8 = Nautical miles
if TRUE set texwhite on new faces
Flags (bits, from left to right)
0 = Save vertex normals
1 = Packed Color mode
2 = CAD View mode
3-31 = SpareReserved
Projection type
0 = Flat earth
1 = Trapezoidal
2 = Round earth
3 = Lambert
4 = UTM
5 = Geodetic
6 = GeocentricReserved
Next DOF node ID number
Vertex storage type
1 = Double precision float - should
always be 1

© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader
ü
ü
ü

ü







ü
ü











ü
ü




ü






230

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Header Record (Continued)
Data TypeInt

DoubleDoubleDoubleDouble
Int
Int
Int
Int
Int
Int
Int
Int
DoubleDoubleDoubleDoubleDoubleDoubleDoubleDouble
Int
Int
Int
Int
Int
Int
Int
Int
Int

OffsetLength

128

4

132
140
148
156
164
166
168
176
178
180
182
184
188
196
204
212
220
228
236
244
252
254
256
258
260
262
264
266
268

8
8
8
8
2
2
4*2
2
2
2
2
4
8
8
8
8
8
8
8
8
2
2
2
2
2
2
2
2
4

Description
Database origin
100 = OpenFlight
200 = DIG I/DIG II
300 = Evans and Sutherland
CT5A/CT6
400 = PSP DIG
600 = General Electric
CIV/CV/PT2000
700 = Evans and Sutherland GDFSouthwest database coordinate x
Southwest database coordinate yDelta x to place database
Delta y to place database
Next sound node ID number
Next path node ID number
Reserved
Next Clip node ID number
Next Text node ID number
Next BSP node ID number
Next Switch node ID number
Reserved
Southwest corner latitude
Southwest corner longitude
Northeast corner latitude
Northeast corner longitude
Origin latitude
Origin longitude
Lambert upper latitude
Lambert lower latitude
Next Light source node ID number
Next Light point node ID number
Next Road node ID number
Next CAT node ID number
Reserved
Reserved
Reserved
Reserved
Earth ellipsoid model
0 = WGS 1984

© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader







































231

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

Int
Int
Int

272
274
276

2
2
2

Char

278

6

1 = WGS 1972
2 = Bessel
3 = Clarke 1866
4 = NAD 1927
-1 = User defined ellipsoid
Next Adaptive node ID number
Next Curve node ID number
UTM zone (for UTM projections negative value means Southernhemisphere)
Reserved© 2015 Open Geospatial Consortium











232

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Header Record (Continued)
Data Type

OffsetLengthDescription

Double284

8Double292

8

Unsignedint
Unsigned
int
Int
Double300

2Delta z to place database(used in conjunction withexisting Delta x and Delta yvalues)Radius (distance fromdatabase origin to farthest
corner)Next Mesh node ID number

302

2

304
308

4
8

Double316

8

CDB OpenFlight
Reader

Next Light Point System ID
numberReserved
Earth major axis (for user
defined ellipsoid) in meters
Earth minor axis (for user
defined ellipsoid) in meters






Group Record
The group record is the primary record of the group node. Groups are the most generichierarchical node present in the database tree. Attributes within the group record provide
bounding volumes that encompass the group’s children and real-time control flags.
Relative priority specifies a fixed ordering of the group relative to its sibling nodes. Ordering
is from left (lesser values) to right (higher values). Nodes of equal priority may bearbitrarily ordered. All nodes have an implicit (default) relative priority value of zero.
A group can represent an animation sequence in which case each immediate child of thegroup represents one frame of the sequence. An animation sequence is made of one or more
loops.
For a group with N children, both forward and backward loops consist of N frames. The
frames of forward and backward loops are:Direction

Frame 1

Frame 2

Frame 3...

Frame N

ForwardBackward

Child 1Child NChild 2Child N-1

Child 3
Child N-2...
...

Child NChild 1

Independent of the direction of the loop, a loop can optionally swing. A swing loop is one
that plays its children in the primary direction and then plays them in the opposite
direction. Note that as the loop swings from the current direction to the opposite direction,
the last frame in the current direction is not repeated. Therefore, for a group with N
children, the first loop of both forward swing and backward swing animations© 2015 Open Geospatial Consortium

233

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
consist of M frames where M equals ((2*N)-1) frames. Subsequent loops of swing
animations consist of M-1 frames. The frames of the first loop of forward and backward
swing animations are:Direction

Frame 1

Frame 2...

Frame N

ForwardChild 1Child 2

Backward

Child NChild
N-1... ChildN... Child
1

Frame N+1

Frame N+2...

Frame M

Child N1Child 2Child N2Child 3... Child 1... Child N

The frames of subsequent loops of forward and backward swing animations are:Direction

Frame 1

Frame 2...

Frame N

ForwardChild 2Child 3

Backward

Child
N-1

Child
N-2

... ChildN... Child
1

Frame N+1

Frame N+2...

Frame M1

Child N1Child 2Child N2Child 3... Child 1... Child N

The number of times an animation loop repeats within the sequence is specified by the loop
count attribute. A loop count of 0 indicates that the loop is to repeat forever.
The duration of one loop within the sequence is specified by the loop duration attribute andis measured in seconds. A loop duration of 0 indicates that the loop is to play as fast as
possible.
For finite animation sequences (those with positive, non-zero loop count values), theduration that the last frame of the last loop is extended after the sequence has finish is
specified by the last frame duration attribute and is measured in seconds. A last frame
duration of 0 indicates that the last frame is not displayed any longer after the sequence
finishes.
Special effect ID1 and ID2 are application-defined attributes. Their values can be used toenhance the meaning of existing attributes, such as the animation flags, or extend theinterpretation of the group node. Normally, the value of these attributes is zero.
Significance can be used to assist real-time culling and load balancing mechanisms, bydefining the visual significance of this group with respect to other groups in the database.
Normally the value of this attribute is zero.
Layer ID is used by the Instrumentation Tools in the modeling products to identify (fordisplay) a collection of groups, independent of their locations in the hierarchy. Normally thevalue of this attribute is zero.

© 2015 Open Geospatial Consortium

234

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Group Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Group Opcode 2
Length - length of the record

4

8

Int
Int
Int

12
14
16

2
2
4

7 char ASCII ID; 0
terminates
Relative priority
Reserved
Flags (bits, from left toright)
0 = Reserved
1 = Forward animation
2 = Swing animation
3 = Bounding box follows
4 = Freeze bounding box
5 = Default parent
6 = Backward animation
7-31 = SpareSpecial effect ID1 application definedSpecial effect ID2 application definedSignificance

Int

20

2

Int

22

2

Int

24

2

Int
Int
Int
Int
Float
Float

26
27
28
32
36
40

1
1
4
4
4
4

Layer code
Reserved
Reserved
Loop countLoop duration in seconds
Last frame duration inseconds© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü

ü

ü

ü
ü



ü



üper CDB
convention




ü
ü
ü

235

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Here are some examples that show how the values of the animation flags (forward
animation, backward animation and swing animation) affect the animation. Note that theseflags define how one “loop” of the animation sequence behaves.
ForwardAnimation

Backward
Animation

0
1
0
1
0
1

0
0
1
0
1
1

Group Animation Flags Examples
Swing
Animation

0
0
0
1
1
Any

ResultGroup is not animatedAnimation loop is forward, no swing.
Animation loop is backward, no swing.
Animation loop is forward with swing.
Animation loop is backward with swing.
Undefined, must be either forward or backward(not both).

Here are some examples that show how the loop duration, loop count and last frame
duration attributes affect the animation. Note that these values are independent of theanimation flags from above.

Group Animation Count Examples

Loop
Duration

Loop
Count

Last Frame
Duration

0

0

Any

T

0

Any

0

N

0

0

N

T

T1

N

0

T1

N

T2

ResultEach loop plays as fast as possible.
Loops are played forever.
Last Frame Duration not applicable.
Each loop lasts T seconds.
Loops are played forever.
Last Frame Duration not applicable.
Each loop plays as fast as possible.
N loops are played.
Last frame displayed as long as any other frame.
Each loop plays as fast as possible.
N loops are played.
Last frame of last (Nth) loop displayed T seconds
longer than any other frame.
Each loop lasts T1 seconds.
N loops are played.
Last frame of last (Nth) loop displayed as long as anyother frame.
Each loop lasts T1 seconds.
N loops are played.
Last frame of last (Nth) loop displayed T2 seconds
longer than any other frame.

Object Record
The object record is the primary record of the object node. Objects are low-level grouping
nodes that contain attributes pertaining to the state of it child geometry. Only face and lightpoint nodes may be the children of object nodes.

© 2015 Open Geospatial Consortium

236

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The time-of-day object flags can be used to inhibit the display of certain objects, dependingon the current time of day.
The illumination flag, when set, makes an object self-illuminating, and is not subject tolighting calculations. In practice, geometric normals should be ignored.
The flat shading flag, when set, indicates that lighting calculations should produce a faceted
appearance to the object’s geometry. In practice, geometric normals should be constrained
to face normals.
The shadow flag indicates the object represents the shadow of the rest of the group. Whenused as part of a moving model (e.g., an aircraft), the application can apply appropriate
distortions, creating a realistic shadow on the terrain or runway.
Relative priority specifies a fixed ordering of the object relative to its sibling nodes. Ordering
is from left (lesser values) to right (higher values). Nodes of equal priority may bearbitrarily ordered. All nodes have an implicit (default) value of zero.
When used, transparency applies to all an object’s children (geometry). The value should be
modulated with the transparency of the geometry and material alpha calculation, as
described in the Face Record, Mesh Record and Material Record sections.
Note:

The MultiGen-Paradigm, Inc. modeling environment does not use the object
transparency value for rendering as described above.

However, when an object’s transparency value is set in Creator, that value is set on all children
faces of the object. Runtime applications may choose to use the transparency value at the object
level at their discretion.

Object Record

Data Type

OffsetLengthDescription

OpenFlight CDB
ReaderInt
Unsigned
Int
Char

0
2

2
2

Object Opcode 4
Length - length of the record

48

7 char ASCII ID; 0
terminates

ü

Int

12

4

Int

16

2

Flags (bits from to right)
0 = Don't display in daylight
1 = Don't display at dusk
2 = Don't display at night3 = Don't illuminate
4 = Flat shaded
5 = Group's shadow object
6-31 = Spare
Relative priority

ü
ü
ü
ü
ü
ü
ü

ü

Unsigned
Int

18

2

Transparency

ü

ü
ü

0 = Opaque© 2015 Open Geospatial Consortium

237

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

Int

20

2

Int

22

2

Int

24

2

Int

26

2

65535 = Totally clear
Special effect ID1 application definedSpecial effect ID2 application definedSignificanceReservedü

Per CDB conventions

Face Record
The face record is the primary record of the face node. A face contains attributes describing
the visual state of its child vertices. Only vertex and morph vertex nodes may be children offaces. This should not be confused with the fact that faces may have subfaces.
If a face contains a non-negative material index, its apparent color is a combination of theface color and material color, as described in “Material Palette Record” on page 71. If a facecontains a nonaddictive material with an alpha component and the transparency field is set,
the total transparency is the product of the material alpha and face transparency.
Note: As mentioned in “Object Record” on page 25, the object transparency is not used in theMultiGen-Paradigm, Inc. modeling environment to determine the actual transparency
value of a face.
If a face is a unidirectional or bidirectional light point, the face record is followed by avector record (Vector Opcode 50) that contains the unit vector indicating the direction inwhich the primary color is displayed. For bidirectional light points, the alternate color isdisplayed in the opposite direction (180 degrees opposed).
Note: This method of defining light points is obsolete after OpenFlight version 15.2. Such lightpoint faces will be turned into the new light point record when it is read into MultiGen IIv1.4 or later.
Relative priority specifies a fixed ordering of the face relative to its sibling nodes. Ordering
is from left (lesser values) to right (higher values). Nodes of equal priority may bearbitrarily ordered. All nodes have an implicit (default) value of zero.

© 2015 Open Geospatial Consortium

238

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

Data Type

OffsetLengthDescription

Int
Unsigned Int
Char
Int
Int
Int

0
2
4
12
16
18

2
2
8
4
2
1

Face Opcode 5
Length - length of the record
7 char ASCII ID; 0 terminates
IR color code
Relative priority
Draw type
0 = Draw solid with backface culling(front side only)
1 = Draw solid, no backface culling(both sides visible)
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light
Texture white = if TRUE, draw textured
face white
Color name index
Alternate color name index
Reserved
Template (billboard)
0 = Fixed, no alpha blending
1 = Fixed, alpha blending
2 = Axial rotate with alpha blending
4 = Point rotate with alpha blending
Detail texture pattern index, -1 if none

Int

19

1

Unsigned Int
Unsigned Int
Int
Int

20
22
24
25

2
2
1
1

Int

26

2

Int
Int
Int

28
30
32

2
2
2

Texture pattern index, -1 if none
Material index, -1 if none
Surface material code (for DFAD)

Int
Int
Unsigned Int

34
36
40

2
4
2

Unsigned Int

42

1

Feature ID (for DFAD)
IR material code
Transparency
0 = Opaque65535 = Totally clear
LOD generation control© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü

ü
ü
ü
ü








ü
ü


ü
ü
ü
ü
ü


Note: Detail textures
are IRIS GL specific

ü
ü
ü

(tentative)



ü


239

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

43
44

1
4

Unsigned Int

48

1

Char
Unsigned Int

49
56

7
4

Unsigned Int

60

4

Int
Int
Unsigned Int
Unsigned Int
Int
Int

64
66
68
72
76
78

2
2
4
4
2
2

Line style index
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = Spare
Light mode
0 = Use face color, not illuminated
1 = Use vertex colors, not illuminated
2 = Use face color and vertex normals
3 = Use vertex colors and vertex normals
Reserved
Packed color, primary (a, b, g, r) - only b,g, r used
Packed color, alternate (a, b, g, r) - onlyb, g, r used
Texture mapping index
Reserved
Primary color index
Alternate color index
Reserved
Shader index, -1 if none

© 2015 Open Geospatial Consortium


ü
ü
ü
ü
ü
ü
ü
ü

ü
ü
ü
ü
ü

ü
ü


ü
ü



240

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

Mesh Nodes
A mesh node defines a set of geometric primitives that share attributes and vertices. Prior to
OpenFlight version 15.7, the fundamental geometric construct was the face (polygon) which
was represented by a unique set of attributes and vertices. Meshes, by contrast, represent“sets” of related polygons, each sharing common attributes and vertices. Using a mesh,related polygons can be represented in a much more compact format. Each mesh consists of
one set of “polygon” attributes (color, material, texture, etc.), a common “vertex pool” andone or more geometric primitives that use the shared attributes and vertices. Using a mesh,
you can represent triangle strips, triangle fans, quadrilateral strips and indexed face sets.
A mesh node is defined by three distinct record types:
WMesh Record - defines the “polygon” attributes associated to all geometric primitives of themesh.
WLocal Vertex Pool Record - defines the set of vertices that are referenced by the geometricprimitives of the mesh.
WMesh Primitive Record - defines a geometric primitive (triangle-strip, triangle-fan,quadrilateral-strip or indexed face set) for the mesh.
A mesh node consists of one mesh record, one local vertex pool record, and one or moremesh primitive records. The mesh primitive records are delimited by push and pop control
records as shown in the following example:
MESH
LOCAL VERTEX POOL
PUSH
MESH PRIMITIVEMESH PRIMITIVE...
MESH PRIMITIVEPOP© 2015 Open Geospatial Consortium

241

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Mesh Record
The mesh record is the primary record of a mesh node and defines the common “face-like”
attributes associated to all geometric primitives of the mesh. These attributes are identicalto those of the face record. See “Face Record” on page 26.

Mesh Record

Data Type

OffsetLengthDescription

CDB OpenFlight
ReaderInt
Unsigned
Int
Char
Int
Int
Int
Int

0
2

2
2

Mesh Opcode 84
Length - length of the record

4
4
16
20
22

8
4
4
2
1

7 char ASCII ID; 0 terminates
Reserved
IR color code
Relative priority
Draw type
0 = Draw solid with backface culling(front side only)
1 = Draw solid, no backface culling(both sides visible)
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe inalternate color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light
Texture white = if TRUE, draw
textured face white

ü


ü
ü
ü

ü
ü

ü








Int

23

1

Unsigned
Int
Unsigned
Int

24

2

Color name index

ü

26

2

Alternate color name index

ü

Int
Int

28
29

1
1

Int

30

2

Reserved
Template (billboard)
0 = Fixed, no alpha blending
1 = Fixed, alpha blending
2 = Axial rotate with alpha blending
4 = Point rotate with alpha blending
Detail texture pattern index, -1 if
none


ü
ü
ü
ü
ü


Int
Int

32
34

2
2

Texture pattern index, -1 if none
Material index, -1 if none

© 2015 Open Geospatial Consortium

Note: Detail textures
are IRIS GL specific

ü
ü

242

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

36

2

Surface material code (for DFAD)

Int
Int
Unsigned
Int

38
40
44

2
4
2

Feature ID (for DFAD)
IR material code
Transparency

Unsigned
Int
Unsigned
Int
Int

46

1

0 = Opaque65535 = Totally clear
LOD generation control



47

1

Line style index



48

4

Unsigned
Int

52

1

Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = Spare
Light mode

ü
ü
ü
ü
ü
ü
ü
ü

ü
ü
ü

Char
Unsigned
Int
Unsigned
Int
Int
Int
Unsigned
Int
Unsigned
Int
Int
Int

ü

(tentative)



ü

53
60

7
4

64

4

68
70
72

2
2
4

0 = Use mesh color, not illuminated
1 = Use vertex colors, notilluminated
2 = Use mesh color and vertex
normals
3 = Use vertex colors and vertex
normals
Reserved
Packed color, primary (a, b, g, r) only b, g, r used
Packed color, alternate (a, b, g, r) only b, g, r used
Texture mapping index
Reserved
Primary color index

76

4

Alternate color index

ü

80
82

2
2

Reserved
Shader index, -1 if none

© 2015 Open Geospatial Consortium

ü
ü

ü
ü


ü

243

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Local Vertex Pool Record
This record defines a set of vertices that is referenced by the geometry (primitives) of the
mesh.
Note:

Currently the Local Vertex Pool is used exclusively in the context of mesh nodes, but it isdesigned in a general way so that it may appear in other contexts in future versions of the
OpenFlight Scene Description.

Data
Type
Int
Unsigned
Int

OffsetLength02

2
2

Unsigned
Int
Unsigned
Int

4

4

8

4

Local Vertex Pool Record
Description
Local Vertex Pool Opcode 85
Length - length of the record
Note: Since the length of this record
is represented by an unsigned short,the maximum length of the vertex
pool is 216- 1 (or 65535 bytes). If theentire vertex pool cannot fit into thissize, one or more continuation records
will follow. (See “Continuation
Record” on page 65.)
Number of vertices - number ofvertices in the local vertex pool
Attribute mask - Bit mask indicating
what kind of vertex information is
specified for each vertex in the local
vertex pool. Bits are ordered from left
to right as follows:
Bit#Description0
Has Position - if set, data foreach vertex in will include x, y, and z
coordinates (3 doubles)1
Has Color Index - if set, data
for each vertex will include a color
value that specifies a color table index
as well as an alpha value
2
Has RGBA Color - if set, data
for each vertex will include a color
value that is a packed RGBA color
value
Note: Bits 1and 2 are mutually
exclusive - a vertex can have either
color index or RGB color value orneither, but not both.
3
Has Normal - if set, data foreach vertex will include a normal (3floats)© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü
ü

ü
ü

ü

ü

ü

244

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 20144
Has Base UV - if set, data foreach vertex will include uv texture
coordinates for the base texture (2floats)5
Has UV Layer 1 - if set, data
for each vertex will include uv texture
coordinates for layer 1 (2 floats)
6
Has UV Layer 2 - if set, data
for each vertex will include uv texture
coordinates for layer 2 (2 floats)
7
Has UV Layer 3 - if set, data
for each vertex will include uv texture
coordinates for layer 3 (2 floats)
8
Has UV Layer 4 - if set, data
for each vertex will include uv texture
coordinates for layer 4 (2 floats)
9
Has UV Layer 5 - if set, data
for each vertex will include uv texture
coordinates for layer 5 (2 floats)
10
Has UV Layer 6 - if set, data
for each vertex will include uv texture
coordinates for layer 6 (2 floats)
11
Has UV Layer 7 - if set, data
for each vertex will include uv texture
coordinates for layer 7 (2 floats)
12-31 Spare© 2015 Open Geospatial Consortium

ü

ü
ü
ü
ü
ü
ü
ü


245

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Local Vertex Pool Record (Continued)
Then beginning at offset 12, the following fields are repeated for eachvertex in the local vertex pool, depending on the bits set in the Attributemask field above.
In the fields listed below, N ranges from 0 to Number of vertices - 1.
DoubleVaries 8*3
CoordinateN - Coordinate of vertex N(x, y, z) - present if Attribute mask
includes Has Position.
Unsigned Int
Varies 4
colorN - Color for vertex N - present
if Attribute mask includes Has Color
Index or Has RGBA Color.
If Has Color Index, lower 3 bytes
specify color table index, upper 1
byte is Alpha.
If Has RGBA Color, 4 bytes specify(a, b, g, r) values.
Float
Varies 4*3
normalN - Normal for vertex N (i, j, k)- present if Attribute mask includes
Has Normal.
Float
Varies 4*2
uvBaseN - Texture coordinates (u, v)
for base texture layer of vertex N present if Attribute mask includes
Has Base UV.
Float
Varies 4*2
uv1N - Texture coordinates (u, v) for
layer 1 of vertex N - present if
Attribute mask includes Has UVLayer 1.
Float
Varies 4*2
uv2N - Texture coordinates (u, v) for
layer 2 of vertex N - present if
Attribute mask includes Has UVLayer 2.
Float
Varies 4*2
uv3N - Texture coordinates (u, v) for
layer 3 of vertex N - present if
Attribute mask includes Has UVLayer 3.
Float
Varies 4*2
uv4N - Texture coordinates (u, v) for
layer 4 of vertex N - present if
Attribute mask includes Has UVLayer 4.
Float
Varies 4*2
uv5N - Texture coordinates (u, v) for
layer 5 of vertex N - present if
Attribute mask includes Has UVLayer 5.
Float
Varies 4*2
uv6N - Texture coordinates (u, v) for
layer 6 of vertex N - present if
Attribute mask includes Has UVLayer 6.
Float
Varies 4*2
uv7N - Texture coordinates (u, v) for© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü
ü

ü

ü

ü

ü

ü

ü

ü

246

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
layer 7 of vertex N - present if
Attribute mask includes Has UVLayer 7.

Mesh Primitive Record
This record defines a geometric primitive (triangle strip, triangle fan, quadrilateral strip, or
indexed polygon) for a mesh.

Mesh Primitive Record

Data Type

OffsetLengthInt
Unsigned
Int
Int

0
2

2
2

Description

Mesh Primitive Opcode 86
Length - length of therecord4
2
Primitive Type - specifies
how the vertices of theprimitive are interpreted
1 = Triangle Strip
2 = Triangle Fan
3 = Quadrilateral Strip
4 = Indexed Polygon
Unsigned
62
Index Size - specifies theIntlength (in bytes) of each of
the vertex indices that
follow - will be either 1, 2,
or 4
Unsigned
84Vertex Count- number ofIntvertices contained in thisprimitive.
The following field is repeated for each vertex referenced by themesh primitive. These vertices are interpreted according toPrimitive Type. In the field below, N ranges from 0 to Vertex
Count - 1.
12+(N*Index
Int
Index
IndexN - Index of vertex N
Size)
Size
of the mesh primitive.

© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü
ü
ü
ü
ü

ü
ü

ü

247

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Each mesh primitive is represented using the Mesh Primitive record above. The following
descriptions explain how the vertices of each primitive type are interpreted as geometry:
W Triangle Strip - This mesh primitive defines a connected group of triangles in the context ofthe enclosing mesh. Each triangle shares the “polygon” attributes defined by the enclosing
mesh. This primitive contains a sequence of indices that reference vertices from the local
vertex pool. One triangle is defined for each vertex presented after the first two vertices. For
odd n, vertices n, n+1, and n+2 define triangle n. For even n, vertices n+1, n, and n+2 define
triangle n. The first triangle is n=1. The first vertex in the vertex pool is n=1. N vertices
represent N-2 triangles.
W Triangle Fan - Like the Triangle Strip, this mesh primitive also defines a connected group of
triangles in the context of the enclosing mesh. Each triangle shares the “polygon” attributes
defined by the enclosing mesh. This primitive contains a sequence of indices that reference
vertices from the local vertex pool. One triangle is defined for each vertex presented after the
first two vertices. Vertices 1, n+1, and n+2 define triangle n. The first triangle is n=1. The
first vertex in the vertex pool is n=1. N vertices represent N-2 triangles.
W Quadrilateral Strip - This mesh primitive defines a connected group of quadrilaterals in thecontext of the enclosing mesh. Each quadrilateral shares the “polygon” attributes defined by
the enclosing mesh. This primitive contains a sequence of indices that reference vertices fromthe local vertex pool. One quadrilateral is defined for each pair of vertices presented after the
first pair. Vertices 2n-1, 2n, 2n+2, and 2n+1 define quadrilateral n. The first quadrilateral isn=1. The first vertex in the vertex pool is n=1. N vertices represent (N/2)-1 quadrilaterals.
W Indexed Polygon -This mesh primitive defines a single polygon in the context of theenclosing mesh. This primitive is similar to the other mesh primitives in that it also shares thepolygon attributes of the enclosing mesh. It is different from the other mesh primitive types inthat while triangle strips/fans and quadrilateral strips describe a set of connected
triangles/quadrilaterals, the indexed polygon defines a single polygon. This primitive contains
a sequence of indices that reference vertices from the local vertex pool. One polygon isdefined by the sequence of vertices in this record. N vertices represent 1 N-sided closed
polygon or 1 (N-1)-sided unclosed polygon.
Light Point Nodes
The OpenFlight format supports two kinds of light point records, indexed and inline. In
indexed light point records, the attributes are stored in two palettes; the light point
appearance palette and the light point animation palette. The indexed light point record
simply stores indices into these two palettes. In inline light point records, all the attributes
are stored directly in the light point record itself. This section describes both of theserecords.

© 2015 Open Geospatial Consortium

248

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

Indexed Light Point Record
The indexed light point record is one of the records that can represent a light point node.
The appearance index specifies an entry in the light point appearance palette that contains
the visual attributes of the light point.
The animation index specifies an entry in the light point animation palette that contains the
behavioral attributes of the light point.
The palette entries referenced by the indexed light point record describe the visual state of
the light point’s child vertices. Only vertex nodes may be children of light point nodes.

Indexed Light Point Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

Indexed Light Point Record
Opcode 130
Length - length of the record

4

8

Int
Int
Int

12
16
24

4
20
4

Int

28

4

7 char ASCII ID; 0
terminates
Appearance index
Animation index
Draw order (for calligraphic
lights)Reserved

CDB OpenFlight
Reader

ü
ü
ü

ü




Light Point Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Light Point

Records.

The light point record is one of the records that can represent a light point node. The lightpoint record contains attributes describing the visual state of its child vertices. Only vertex
nodes may be children of light point nodes.
Light points are geometric points that represent real world light sources such as runway
lights, vehicle lights, street lights, and rotating beacons. Light points differ from lightsources in that they do not illuminate the scene around them. They are primarily used tomodel important visual cues without incurring the tremendous rendering overhead
associated with light sources.
Most light point attributes are specific to these unique requirements. Light points can bedisplayed on special purpose calligraphic imaging systems, the more familiar raster variety,or even hybrid raster/calligraphic (RASCAL) systems.

© 2015 Open Geospatial Consortium

249

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

Data TypeInt
Unsigned Int
Char
Int
Int
Unsigned Int
Int

Offset
0
2
4
12
14
16
20

Length
2
2
8
2
2
4
4

Float
Float
Float
Float
Int

24
28
32
36
40

4
4
4
4
4

Int

44

4

Int

48

4

Int

52

4

Float
Float
Float
Float

56
60
64
68

4
4
4
4

Float

72

4

Float

76

4

Float

80

4

Float

84

4

Float
Float

88
92

4
4

Light Point Record

Description
Light Point Record Opcode 111
Length - length of the record
7 char ASCII ID; 0 terminates
Surface material code
Feature ID
Back color for bidirectional points
Display mode
0 = RASTER
1 = CALLIGRAPHIC
2 = EITHER
Intensity - scalar for front colors
Back intensity - scalar for back color
Minimum defocus - (0.0 - 1.0) for calligraphic points
Maximum defocus - (0.0 - 1.0) for calligraphic points
Fading mode
0 = Enable perspective fading calculations
1 = Disable calculations
Fog Punch mode
0 = Enable fog punch through calculations
1 = Disable calculations
Directional mode
0 = Enable directional calculations
1 = Disable calculations
Range mode
0 = Use depth (Z) buffer calculation
1 = Use slant range calculation
Min pixel size - minimum diameter of points in pixels
Max pixel size - maximum diameter of points in pixels
Actual size - actual diameter of points in database units
Transparent falloff pixel size - diameter in pixels whenpoints become transparent
Transparent falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Transparent falloff scalar> 0 - falloff multiplier scale factor
Transparent falloff clamp - minimum permissible falloff
multiplier result
Fog scalar>= 0 - adjusts range of points for punch threw effect.
Reserved
Size difference threshold - point size transition hint torenderer© 2015 Open Geospatial Consortium

250

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Light Point Record (Continued)
Data TypeInt

Offset96

Length
4

Float
Float
Float

100
104
108

4
4
4

Float

112

4

Float
Float
Float
Float
Float

116
120
124
128
132

4
4
4
4
4

Int
Int

136
140

4
4

Description
Directionality
0 = OMNIDIRECTIONAL
1 = UNIDIRECTIONAL
2 = BIDIRECTIONAL
Horizontal lobe angle - total angle in degrees
Vertical lobe angle - total angle in degrees
Lobe roll angle - rotation of lobe about local Y axis in degrees
Directional falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Directional ambient intensity - of points viewed off axis
Animation period in seconds
Animation phase delay in seconds - from start of period
Animation enabled period in seconds
Significance - drop out priority for RASCAL lights (0.0 1.0)
Calligraphic draw order - for rendering consistency
Flags (bits, from left to right)
0 = reserved
1 = No back color
TRUE = don’t use back color for bidirectional
points
FALSE = use back color for bidirectional points
2 = reserved
3 = Calligraphic proximity occulting (Debunching)
4 = Reflective, non-emissive point
5-7 = Randomize intensity
0 = never
1 = low
2 = medium
3 = high
8 = Perspective mode
9 = Flashing
10 = Rotating
11 = Rotate Counter Clockwise
Direction of rotation about local Z axis
12 = reserved
13-14 = Quality
0 = Low
1 = Medium
2 = High
3 = Undefined
15 = Visible during day
16 = Visible during dusk
17 = Visible during night
18-31 = Spare© 2015 Open Geospatial Consortium

251

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

144

4*3

Axis of rotation for rotating animation (i, j, k)Light Point System Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Light
Point System Records.
The light point system record enables you to collect a set of light points and enable/disableor brighten/dim them as a group.
Data TypeInt
Unsigned Int
Char
Float
Int

Offset
0
2
4
12
16

Int

20

Light Point System Record
Length
2
2
8
4
4

4

Description
Light Point System Record Opcode 130
Length - length of the record
7 char ASCII ID; 0 terminates
Intensity
Animation state
0 = On1 = Off
2 = Random
Flags (bits, from left to right)
0 = Enabled
1-31 = Spare

Degree of Freedom Record
The degree of freedom (DOF) record is the primary record of the DOF node. The DOF
node specifies a local coordinate system and the range allowed for translation, rotation, andscale with respect to that coordinate system.
The DOF record can be viewed as a series of applied transformations consisting of thefollowing elements:[PTTTRRRSSSP]
where “P” denotes “put,” “T” denotes “translate,” “R” denotes “rotate,” and “S” denotes“scale.”It is important to understand the order in which these transformations are applied to thegeometry. A pre-multiplication is assumed, so the sequence of transformations must be readfrom right to left, in order to describe its effect on the geometry contained below the DOF.
In this manner, a DOF is interpreted as a Put followed by three Scales, three Rotates, three
Translates, and a Put.
Taking the transformations in right to left order, they represent:
1. A Put (3 point to 3 point transformation). This matrix brings the DOF coordinate system tothe world origin, with its x-axis aligned along the world x-axis and its y-axis in the world x-yplane. Testing against the DOF's constraints is performed in this standard position. Thismatrix is therefore the inverse of the last (see step 11 below).
2. Scale in x.
3. Scale in y.

© 2015 Open Geospatial Consortium

252

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
4. Scale in z.

© 2015 Open Geospatial Consortium

253

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
5. Rotation about z (yaw).
6. Rotation about y (roll).
7. Rotation about x (pitch).
8. Translation in x.
9. Translation in y.
10. Translation in z.
11. A final Put. This matrix moves the DOF coordinate system back to its original position in thescene.
The DOF record specifies the minimum, maximum, and current values for eachtransformation. Only the current value affects the actual transformation applied to thegeometry. The increment value specifies discrete allowable values within the range oflegal values represented by the DOF.

© 2015 Open Geospatial Consortium

254

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Degree of Freedom Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Int
Double0222Degree-of-Freedom Opcode 14
Length - length of the record

4
12
16

8
4
8*3

Double40

8*3

Double64

8*3

Double88

8

Double96

8

Double104

8

DoubleDouble

112
120

8
8

Double128

8

Double136

8DoubleDouble

144
152

8
8

Double160

8

Double168

8DoubleDouble

176
184

8
8

DoubleDoubleDoubleDouble

192
200
208
216

8
8
8
8

DoubleDoubleDoubleDouble

224
232
240
248

8
8
8
8

7 char ASCII ID; 0 terminates
Reserved
Origin of DOF's local coordinate
system (x, y, z)
Point on x axis of DOF's local
coordinate system (x, y, z)
Point in xy plane of DOF's local
coordinate system (x, y, z)
Min z value with respect to local
coordinate system
Max z value with respect to local
coordinate system
Current z value with respect tolocal coordinate system
Increment in z
Min y value with respect to local
coordinate system
Max y value with respect to the
local coordinate system
Current y value with respect tolocal coordinate system
Increment in y
Min x value with respect to local
coordinate system
Max x value with respect to local
coordinate system
Current x value with respect tolocal coordinate system
Increment in x
Min pitch (rotation about the xaxis)
Max pitch
Current pitch
Increment in pitch
Min roll (rotation about the yaxis)
Max roll
Current roll
Increment in roll
Min yaw (rotation about the zaxis)© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü

ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü

255

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

256
264
272
280
288

8
8
8
8
8

Max yaw
Current yaw
Increment in yaw
Min z scale (about local origin)
Max z scale (about local origin)© 2015 Open Geospatial Consortium

ü
ü
ü
ü
ü

256

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Degree of Freedom Record (Continued)

Data Type

OffsetLengthDescription

Double296

8DoubleDouble

304
312

8
8

Double320

8

Double328

8DoubleDouble

336
344

8
8

Double352

8

Double360

8Double
Int

368
376

8
4

Current z scale (about
local origin)
Increment for scale in z
Min y scale (about local
origin)Max y scale (about local
origin)Current y scale (about
local origin)
Increment for scale in y
Min x scale (about local
origin)Max x scale (about local
origin)Current x scale (about
local origin)
Increment for scale in x
Flags (bits, from left toright)
0 = x translation islimited
1 = y translation islimited
2 = z translation islimited
3 = Pitch rotation islimited
4 = Roll rotation islimited
5 = Yaw rotation islimited
6 = x scale is limited
7 = y scale is limited
8 = z scale is limited
9 = Reserved
10 = Reserved
11-31 = SpareReserved

Int

380

4

© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü

ü
ü
ü





257

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

Vertex List Record
A vertex list record is the primary record of a vertex node. Each record references one ormore vertices in the vertex palette. See “Vertex Palette Records” on page 66. A vertex node isa leaf node in the database and therefore cannot have any children.

Vertex List Record
Data Type

OffsetLengthDescription

CDB OpenFlight
ReaderInt
0
2
Vertex List Opcode 72ü
Unsigned
2
2
Length - length of the recordüIntThe following field is repeated for each vertex contained in the vertex list record.
In the field below, N ranges from 0 to Number of vertices - 1, where Number of vertices =(Length - 4) / 4
Int4+(N*4) 4
OffsetN - Byte offset intoüvertex palette of the actual
vertex for vertex N.
Morph Vertex List Record
A morph vertex list record is the primary record of a morph vertex node. Like the vertex
list record, each morph vertex list record references one or more vertices in the vertex
palette. See: “Vertex Palette Records” on page 66. A morph vertex node is a leaf node in the
database and therefore cannot have any children.
Each record references one or more pairs of vertices (weights) in the vertex palette. One
weight is the 0 percent morph attributes and the other weight is the 100 percent morph
attributes. Since each weight references a vertex, all vertex attributes including color,
normal, and texture coordinates may be morphed.
When the eyepoint approaches the switch-in distance, the vertex attributes displayed are
100 percent morphed. When the eyepoint reaches the distance computed by LOD switch-in
distance minus LOD transition range, the vertex attributes displayed are 0 percent
morphed. Within the LOD transition range, the vertex attributes displayed are interpolated
between the two known vertex attributes.
Geometric morphing is controlled by the parent LOD node. Only morph vertex nodes areaffected. Both morphing and static geometry (vertices) may exist within the same branch of
the database hierarchy.
Data
Type
Int
Unsigned
Int

Offset
0
2

Lengt
h
2
2

Morph Vertex List Record
Description

Morph Vertex List Opcode 89
Length - length of the record© 2015 Open Geospatial Consortium

CDB OpenFlight
Readerüü

258

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The following fields are repeated for each vertex containedin the morph vertex list record.
In the fields below, N ranges from 0 to Number of vertices 1, where
Number of vertices = (Length - 4) / 8
Int4+(N* 4
Offset 0N - Offset into vertex
8)
palette of Nth 0% vertex.
Int
8+(N* 4
Offset 100N - Offset into
8)
vertex palette of Nth 100%vertex.

üüü

Binary Separating Plane Record
The binary separating plane (BSP) record is the primary record of the BSP node. A BSP
allows you to model 3D databases without depth (Z) buffer support.
An application uses this information to cull portions of the database according to which sideof the plane the subtree is situated on with regard to eyepoint position and viewing
direction.
This record contains an equation ax + by + cz + d = 0 that describes the separating plane.

Binary Separating Plane Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

4

8

Int
Double

12
16

4
8*4

Binary Separating Plane(BSP) Opcode 55
Length - length of therecord7 char ASCII ID; 0
terminates
Reserved
Plane equation coefficients(a, b, c, d)© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü


ü

259

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

External Reference Record
The external reference record is the primary record of the external reference node.
External references allow one database to reference, or instance, a node in another database(or an entire database). At the point of reference, the referenced node/database is copied (orpossibly shared) as a child of the current parent node.
The override flags allow the referencing (parent) database to control use of the referenced(child) node/database palettes. If an override flag (e.g., material) is set, the childnode/database uses its own (material) palette. Otherwise, the child node/database uses thecurrent (parent’s) palette. The override flags are hierarchical and may affect references
made by the child node/database.
The view as bounding box field is used by the MultiGen-Paradigm, Inc. modelingenvironment and is not expected to be used by runtime applications.

External Reference Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

External Reference Opcode
63
Length - length of the record

4

200

Int
Int

204
208

4
4

Int

212

2

199-char ASCII path; 0
terminates
Format of this string is:filename<node name>if <node name> absent,
references entire file
Reserved
Flags (bits, from left to right)
0 = Color palette override
1 = Material palette override
2 = Texture and texture
mapping palette override
3 = Line style paletteoverride
4 = Sound palette override
5 = Light source paletteoverride
6 = Light point paletteoverride
7 = Shader palette override
8-31 = Spare
View as bounding box
0 = View external reference
normally
1 = View external reference
as bounding box© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
















260

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

214

2

ReservedLevel of Detail Record
The level of detail (LOD) record is the primary record of the LOD node. LOD’s are perhaps
the most important hierarchical node present in the database tree. Proper use of level-ofdetail modeling concepts can vastly improve real-time playback of large databases.
Attributes within the LOD record provide switching and transition distances for real-timeculling and load management mechanisms.
The center coordinate can be used by a real-time application to calculate the slant range
distance from the eyepoint to the LOD. Based upon the result of this calculation, a real-time
application can choose not to display the LOD’s children and thus reduce system load. The
center of the LOD is generally the transformed center of the geometry of the LOD’s
children. This should include the effects of instancing and (parent) group replication as
well.
The use previous slant range flag indicates that the slant range for this LOD is the same as
the previous (sibling) LOD, implying the center coordinate is also the same. The real-time
application can reuse the previous slant range calculation when evaluating this LOD,
thereby improving performance.
If the freeze center flag is not set, the MultiGen-Paradigm, Inc. modeling environment aswell as OpenFlight API based applications will recalculate the center point of the LOD
when the OpenFlight file is saved.
Transition range specifies the range over which real-time smoothing effects should be
employed while switching from one LOD to another. Smoothing effects include geometricmorphing and image blending. The smoothing effect is active between: switch-in distanceminus transition range (near), and switch-in distance (far). The center distance of the effectis therefore switch-in distance minus one half the transition range.
Significant size is a value used to calculate switch in and out distances based on viewing parameters of your simulation display system. This value is used internally by MultiGenParadigm and will be enhanced in future versions of OpenFlight.

© 2015 Open Geospatial Consortium

261

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

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Level-of-Detail Opcode 73
Length - length of the record

4

8

Int
DoubleDouble
Int

12
16
24
32

4
8
8
2

Int

34

2

Int

36

4

7 char ASCII ID; 0
terminates
Reserved
Switch-in distance
Switch-out distanceSpecial effect ID1 application definedSpecial effect ID2 application defined
Flags (bits, from left toright)

DoubleDoubleDoubleDoubleDouble

40
48
56
64
72

8
8
8
8
8

0 = Use previous slant range
1 = Reserved
2 = Freeze center (don'trecalculate)
3-31 = Spare
Center coordinate x of LOD
Center coordinate y of LOD
Center coordinate z of LOD
Transition range
Significant size

© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü


ü
ü


ü
ü



ü
ü
ü
ü
ü

262

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

Sound Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Sound
Records.
The sound record is the primary record of the sound node. A sound node represents the
position and orientation of a sound emitter in the database.
Amplitude and pitch blend are relative to the amplitude in the waveform file. Falloff defines
how amplitude falls off when approaching the edge of the sound lobe, with maximum
amplitude at the center of the lobe.
Priority determines which sounds are played when more emitters populate a scene than thesound system can play simultaneously.
Width defines the half angle of the sound lobe. Direction sets the type of sound lobe.
Doppler, absorption, and delay flags enable or disable the modeling of Doppler, atmosphericabsorption, and propagation delay in the sound environment.
Active indicates a sound is to be activated when read in to the modeling environment.

Sound Record

Data TypeInt
Unsigned Int
Char
Int
Int
Int
DoubleFloat

Offset
0
2
4
12
16
20
24
48

Length
2
2
8
4
4
4
8*3
4*3

Float
Float
Float
Float
Float
Int

60
64
68
72
76
80

4
4
4
4
4
4

Int

84

4

Description
Sound Node Opcode 91
Length - length of the record
7 char ASCII ID; 0 terminates
Reserved
Index into sound palette
Reserved
Coordinate of offset from local origin (x, y, z)
Sound direction (vector) wrt local coordinate
axes (i, j, k)
Amplitude of soundPitch bend of soundPriority of soundFalloff of soundWidth of sound lobe
Flags (bits, from left to right)
0 = Doppler
1 = Atmospheric absorption
2 = Delay
3-4 = Direction:
0 = Omnidirectional
1 = Unidirectional
2 = Bidirectional
5 = Active
6-31 = SpareReserved© 2015 Open Geospatial Consortium

263

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

Light Source Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Light
Source Records.
The light source record is the primary record of the light source node. Light sources
illuminate the database. They contain position and rotation data (overriding any
information stored in the light palette), an index into the light palette, and information on
how the light behaves within the hierarchy.
The enabled flag indicates whether the light is turned on and, therefore, a factor of thelighting (rendering) model.
The global flag specifies whether the light shines on the entire database or only on its
children (for example, the cabin light in a car).

Light Source Record

Data TypeInt
Unsigned Int
Char
Int
Int
Int
Int

Offset
0
2
4
12
16
20
24

Length
2
2
8
4
4
4
4

Int
Double

28
32

4
8*3

Float
Float

56
60

4
4

Description
Light Source Record Opcode 101
Length - length of the record
7 char ASCII ID; 0 terminates
Reserved
Index into light palette
Reserved
Flags (bits, from left to right)
0 = Enabled
1 = Global
2 = Reserved
3 = Export
4 = Reserved
5-31 = SpareReserved
Position (for Local or Spot lights only) (x, y,z)
Yaw (azimuth for Infinite or Spot lights only)
Pitch (elevation for Infinite or Spot lights
only)© 2015 Open Geospatial Consortium

264

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

Road Segment Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Road
Segment Records.
A road segment record is the primary record of a road segment node. It stores theattributes used to create and modify a road segment. The children of the road node
represent the geometry and paths of the road and should not be manually edited. Any
modification invalidates the road segment.
Data TypeInt
Unsigned Int
Char

Offset024Road Segment Record

Length228Description
Road Segment Opcode 87
Length of record
7 char ASCII ID; 0 terminates

Road Construction Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Road
Construction Records.
A road construction record is the primary record of a road construction node. It supersedes
the Road Segment Record described previously. It is created by the Pathfinder option ofMultiGen II Pro v1.5 as well as the Road Tool option beginning with Creator v2.1. It storesthe parameters defining the road path construction for one road section. In practice, thechildren of the road construction node usually represent the geometry and paths of the roadsection. Although every field in the road construction record may be modified, this data
makes the most sense when it is kept in sync with the geometry that is created from it.
Therefore, typical usage will be read-only access from applications able to analyze the roadsurface from this given data.
The Road type field dictates how the following fields define the current road section. For allroad types, the Entry and Exit control points lie on the boundaries of the road section. The
Alignment control point is only necessary for the Curve type as it defines a horizontal
tangent with the other control points.
Other fields particular to the Curve type are the horizontal curve parameters. The
horizontal components of the Curve type start and end with spiral transitions of specified
lengths. An Arc Radius length is used to define the constant curve area. The Superelevationis specified in a rise over run slope measured laterally across the road for the maximumbanking which is used throughout the constant curve component. The banking transitions
along the spiral sections in one of three ways defined by the Spiral type field.
Both the Curve and Hill types may have a vertical curve component defined by theremaining fields. Slopes are given at both the entry and exit of the section. If the given
slopes don't intersect within the road segment then two vertical parabolas are constructed
instead of one, and the Additional vertical parabola flag is set. Note that this flag’s value isonly valid when the Road Tools version field is 3 or later. This flag may also be set whenconvergence of the slopes creates a vertical curve length less than Minimum curve length.

© 2015 Open Geospatial Consortium

265

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Otherwise, Vertical curve length is used to define the horizontal distance covered by thesingle parabola vertical curve.

Data TypeInt
Unsigned Int
Char
Char
Int

Offset
0
2
4
12
16

Int
DoubleDoubleDoubleDoubleDoubleDouble

20
24
48
72
96
104
112

Road Construction Record
Length
2
2
8
4
4

4
8*3
8*3
8*3
8
8
8

Description
Road Construction Opcode 127
Length of record
7 char ASCII ID; 0 terminates
Reserved
Road type
0 = Curve
1 = Hill
2 = StraightRoad Tools version
Entry control point (x, y, z)
Alignment control point (x, y, z)
Exit control point (x, y, z)
Arc radius
Entry spiral length
Exit spiral length© 2015 Open Geospatial Consortium

266

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Road Construction Record (Continued)

Data TypeDoubleInt

Offset120
128

Length8
4Int
DoubleDoubleDoubleDouble

132
136
144
152
160

4
8
8
8
8

Description
Superelevation
Spiral type
0 = Linear with length
1 = Linear with angle
2 = Cosine with length
Additional vertical parabola flag
Vertical curve length
Minimum curve length
Entry slope
Exit slope

Road Path Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Road
Path Records.
A road path record is the primary record of a road path node. A road path node is a childof a road segment node. It describes a lane of the parent road segment. The child of a road
path node is a face node whose vertices provide the coordinates of the center of the lane.
Road path record attributes may also be written to an ASCII file for easy access by theapplication. The format of the file is described in “Road Path Files,” page 99.

Road Path Record

Data TypeInt
Unsigned Int
Char
Int
Char
DoubleBooleanInt

Offset
0
2
4
12
16
136
144
148

Length
2
2
8
4
120
8
4
4

Int

152

480

Description
Road Path Opcode 92
Length of record
7 char ASCII ID; 0 terminates
Reserved
Path name; 0 terminates
Speed limit
No passing
Vertex normal type
0 = Up-vector
1 = Heading, Pitch, Roll
Reserved© 2015 Open Geospatial Consortium

267

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

Clip Region Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Clip
Region Records.
A clip region record is the primary record of a clip node. It defines those regions in 3D
space in which drawing occurs. Clip regions only clip the geometry below the clip node in
the hierarchy.
The coordinates create a four-sided face that defines the clip region in space. Planes areformed along the edges of the four-sided face normal to the face; a fifth plane clips the backside of the face.

Data TypeInt
Unsigned Int
Char
Int
Int
Char

Offset
0
2
4
12
16
18

Length
2
2
8
4
2
5

Char
DoubleDoubleDoubleDoubleDouble

23
24
48
72
96
120

1
8*3
8*3
8*3
8*3
8*20

Clip Region Record

Description
Clip Region Opcode 98
Length of record
7 char ASCII ID; 0 terminates
Reserved
Reserved
Flags for enabling the individual clip planes
Char 0 is flag for edge defined by coordinate 0 and 1
Char 1 is flag for edge defined by coordinate 1 and 2Char 2 is flag for edge defined by coordinate 2 and 3
Char 3 is flag for edge defined by coordinate 3 and 0Char 5 is flag for plane that clips the half space behindthe clip region
Reserved
1st coordinate defining the clip region (x, y, z)
2nd coordinate defining the clip region (x, y, z)
3rd coordinate defining the clip region (x, y, z)
4th coordinate defining the clip region (x, y, z)
Five plane equation coefficients (ax + by +cz + d)
Coefficients are ordered:a 0, a 1, a 2, a 3, a 4
b 0, b 1, b 2, b 3, b 4
c 0, c 1, c 2, c 3, c 4
d 0, d 1, d 2, d 3, d 4© 2015 Open Geospatial Consortium

268

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

Text Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Text
Records.
The text record is the primary record of the text node. Text draws a string of data using a
specified font. The record specifies the visual characteristics of the text and formatting
information.
The actual string for the text is stored in the comment record immediately following. The
format of the text record is:

Data TypeInt
Unsigned Int
Char
Int
Int
Int

Offset
0
2
4
12
16
20

Length
2
2
8
4
4
4

Int

24

4

Int

28

4

Double
Int
Int
Int

32
40
44
64

8
4
4*5
4

Int
Int
Int
Int
Int
Int
Int
Int

68
72
76
80
84
88
92
96

4
4
4
4
4
4
4
4

Text Record

Description
Text Opcode 95
Length of record
7 char ASCII ID; 0 terminates
Reserved
ReservedType-1 = Static
0 = Text String
1 = Float
2 = Integer
Draw type
0 = Solid
1 = Wireframe and close
2 = Wireframe
3 = Surround with wireframe in alternate color
Justification
0 = Left
1 = Right
2 = Center
Floating point value
Integer value
Reserved
Flags (bits, from left to right)
0 = Boxable (Unused)
1-31 = Spare
Color
Color 2 (Unused)
Material
Reserved
Maximum number of lines (Unused)
Maximum number of characters
Current length of text (Unused)
Next line number available (Unused)© 2015 Open Geospatial Consortium

269

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

100
104
112
128
152
176
296
300
304
308
312
316

4
4*2
8*2
8*3
8*3
120
4
4
4
4
4
4

Line number at top of display (Unused)
Low/high values for integers
Low/high values for floats
Lower-left corner of rectangle around text (x, y, z)
Upper-right corner of rectangle around text (x, y, z)
Font name
Draw vertical
Draw italic
Draw bold
Draw underline
Line style
Reserved

Switch Record
A switch record is the primary record of a switch node. A switch represents a set of masksthat control the display of the switch’s children.
Each mask contains one bit for each child of the switch. Each mask bit indicates that thecorresponding child is selected (1) or deselected (0). Each mask selects some, none, or all of
the children for display according to the state of the mask bits.
Both the switch children and mask bits begin counting from 0. Therefore the selection state,
for a particular switch child is derived from a given mask with the following calculation:mask_bit = 1 << (child_num % 32)
mask_word = mask_words [mask_num * num_words + child_num / 32]
child_selected = mask_word & mask_bit
The current mask value is an index into the set of masks and indicates the selected mask.
The masks of a switch node can be named. These names are stored in the ancillary record,
indexed string record. See “Indexed String Record” on page 53.

Switch Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Switch Opcode 96
Length of record

4

8

Int
Int
Int
Int

12
16
20
24

4
4
4
4

7 char ASCII ID; 0
terminates
Reserved
Current mask
Number of masks
Number of words per mask
- the number of 32 bit words
required for each mask,
calculated as follows:(number of children / 32) +© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü


ü
ü
ü

270

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

UnsignedInt

28

VariableX
where X equals:
0 if (number of children
modulo 32) is zero
1 if (number of children
modulo 32) is nonzero
Mask words.
The length (in bytes) can becalculated as follows:
Number of words per mask
* Number of masks * 4
bytes© 2015 Open Geospatial Consortium

ü

271

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

CAT Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider CAT Records.
A continuously adaptive terrain(CAT) record is the primary record of
CAT node. A continuously adaptive
terrain skin is a hierarchical triangle
mesh designed for high fidelity, realviewing. A CAT skin is represented in
OpenFlight by a record stream
consisting of: a CAT record, a set of
CAT data records, a push record, theCAT hierarchy and geometry, and arecord. CAT hierarchy and geometry
represented by standard OpenFlight
constructs of LOD’s, groups, externalreferences, faces, and vertices.

© 2015 Open Geospatial Consortium

a
time

pop
is

272

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

Data TypeInt
Unsigned Int
Char
Int
Int
Int

Offset
0
2
4
12
16
20

Length
2
2
8
4
4
1

Int

21

1

Int
Unsigned Int
Unsigned Int
Int
Int
Int
Int
Int
Int
Int
Int
Unsigned Int
Unsigned Int

22
24
26
28
30
32
34
36
40
48
50
52
56

2
2
2
2
2
2
2
4
4*2
2
2
4
4

Description
CAT Opcode 115
Length - length of the record
7 char ASCII ID; 0 terminates
Reserved
IR color code
Draw type
0 = Hidden, don’t draw
1 = Draw solid, no backface
2 = Draw wireframe
Texture white = if TRUE, draw textured face
white
Reserved
Color name index
Alternate color name index
Detail texture pattern index, -1 if none
Texture pattern index, -1 if none
Material index, -1 if none
Surface material code (for DFAD)
IR material code
Reserved
Texture mapping index
Reserved
Primary color index
Alternate color index© 2015 Open Geospatial Consortium

273

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CAT Record (Continued)

Data TypeInt
DoubleInt

Offset60
64
72

Length
4
8
4

Int

76

4

Description
Reserved
Reserved
Flags (bits, from left to right)
0 = No color
1 = No alternate color
2-31 = SpareReserved

Extension Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Extension Records.
An extension node record is the primary record of an extension node. It introduces a user
defined node type that is defined by an extension site that utilizes the extensibility of the
OpenFlight format. It specifies the site information for a third party record which contains
additional data that is not represented by the standard OpenFlight records. The content of
the data itself is transparent to users other than the extension site. The data can be accessedby the combination of the OpenFlight API and the data dictionary defined by the extension
site.
The relationship of an extension node relative to other hierarchical nodes is defined by thestandard push and pop control records. For more information about extensions, pleaserefer to the “OpenFlight API User’s Guide, Level 3: Extensions”.
The extension record (Opcode 100) may also introduce new attributes to existing nodes (See
“Extension Attribute Record” on page 64.)

Extension Record

Data TypeInt
Unsigned Int
Char
Char

Offset0
2
4
12

Length
2
2
8
8

Int
Int
Unsigned Int
Char

20
21
22
24

1
1
2
VariesDescription
Extension Opcode 100
Length of the total extension record
7 char ASCII ID; 0 terminates
Site ID - Unique site name. 7 char ASCII ID;
0 terminates
Reserved
Revision - site specific
Record code - site specific
Extended data - site specific© 2015 Open Geospatial Consortium

274

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

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Curve Records.
A curve record is the primary record of a curve node. A curve node represents one or morecurve segments joined together with at least G0 continuity. Let a curve segment be definedby 4 geometric constraints. We will call these geometric constraints control points in the
curve record. The way the control points are grouped and used will be discussed below.
Let each control point be a double precision 3D coordinate, P = (x, y, z).
Let the group of control points be (P0, P1,..., Pk).
The currently defined curve types are B-spline, Cardinal, and Bezier.
If the curve type is Bezier, P0, P1, P2, and P3 form the first curve segment. P3, P4, P5, and P6
form the next segment, and so on. Notice that the last control point in the first segment
becomes the first control point in the second segment.
If the curve type is either B-spline or Cardinal, P0, P1, P2, and P3 form the first curve
segment. P1, P2, P3, and P4 from the next segment, and so on. Notice that the second control
point in the first segment becomes the first control point in the second segment.
Note that the smoothness of the curve depends on how many times your renderer samples
the curve equation into piece-wise linear elements. In the MultiGen-Paradigm, Inc.
modeling environment, each curve segment is evenly sampled 11 times to produce 10 lines
per curve segment.

Curve Record

Data TypeInt
Unsigned Int
Char
Int
Int

Offset0
2
4
12
16

Length
2
2
8
4
4

Int
Char
Double

20
24
32

4
8
Variable

Description
Curve Opcode 126
Length of the total curve record
7 char ASCII ID; 0 terminates
Reserved
Curve type
4 = B-spline
5 = Cardinal
6 = Bezier
Number of control points
Reserved
Coordinates of control points. Eachcoordinate is (x, y, z)
Coordinates are ordered:
cp0x, cp0y, cp0z,
cp1x, cp1y, cp1z,...
cpNx, cpNy, cpNz
where N is Number of control points - 1(Length = Number of control points * 3 * 8
bytes.)

Ancillary Records© 2015 Open Geospatial Consortium

275

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Ancillary records follow node primary records. They contain supplementary attribute data for thenode they follow. Ancillary records are optional but must precede any control record, following thenode primary record, when present, as shown in this example:
GROUP
COMMENTLONG ID
PUSH
...
POP
In this example, the comment and long ID ancillary records apply to the group record. There is noorder dependency between ancillary records. The comment could appear before or after the long ID
record in the example above, but must appear before any control record.

Comment Record
A comment record is an ancillary record that contains text data that belongs to the preceding node
primary record. The text description is a variable length ASCII string terminated by a <nil>character.

Data Type

OffsetLengthInt
Unsigned
Int
Char

0
2

2
2

4

Length 4

Comment Record
Description

Comment Opcode 31
Length - length of therecordText description of node; 0terminates© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü

276

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

Long ID Record
A long ID record is an ancillary record that contains the full name of the preceding node. It ispresent only when the name exceeds eight characters (seven characters plus a terminating <nil>character).

Note that the ID field found in third field of every primary OpenField record must be
unique. The ID itself can be in Short or Long form. In Short form, the ID is limited to a
7 char ASCII string. In Long form, the ID can be of up to (64K – 5) characters in length.
The Long ID record, when present, replaces the 7 char string found in the third of the
primary record.
Long ID Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Long ID Opcode 33
Length - length of the record

4Length 4

ASCII ID of node; 0terminates

CDB OpenFlight
ReaderüüüIndexed String Record
An indexed string record is an ancillary record that contains an integer index followed by a variable
length character string. In this way, arbitrary strings can be associated to indices in a general way.
Currently, indexed string records are only used in the context of switch nodes, for which they
represent the names of the masks contained in the switch node. The index specifies the mask number
for which the string specifies the name. Mask numbers start at 0. Not all masks are required to havenames.

Indexed String Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Unsigned
Int
Char

0
2

2
2

Indexed string Opcode 132
Length - length of the record

4

4

Index

ü

8

Length 8

ASCII string; 0 terminatesü© 2015 Open Geospatial Consortium

CDB OpenFlight
Readerüü277

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Multitexture
OpenFlight supports eight textures per polygon or mesh as well as eight uv values per vertex. The
current texture information stored on the polygon is referred to as “the base texture” or “texture
layer 0”. Each additional texture is referred to as “texture layer N”. Therefore, to support eighttextures per polygon, a base texture is required as well as seven additional texture layers. Not alllayers are required. Nor is any mandate set forth requiring that layers be contiguous after the baselayer. The additional texture layers for each polygon, mesh, and vertex are represented in ancillary
records at the face, mesh and vertex primary node level as shown in the following example:

FACE
MULTITEXTURE
PUSH
VERTEX LISTUV LISTPOP
The records that are used to represent multitexture in the OpenFlight file are described in thefollowing sections.

Multitexture Record
The multitexture record is an ancillary record of face and mesh nodes. It specifies the texture layer
information for the face or mesh.

Data Type

OffsetLengthUnsigned Int
Unsigned Int
Int

0
2
4

2
2
4

Multitexture Record
Description

Multitexture Opcode 52
Length - length of the record
Attribute mask - Bit mask indicating
what kind of multitexture information
is present in this record. Bits are ordered from left to right and have thefollowing definitions:Bit #Description0
Has
Layer 1 - if set, multitexture
information for texture layer 1 ispresent.
1
Has Layer 2 - if set,
multitexture information for texture
layer 2 is present.
2
Has Layer 3 - if set,
multitexture information for texture
layer 3 is present.
3
Has Layer 4 - if set,
multitexture information for texture
layer 4 is present.

© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü

ü

ü
ü
ü

278

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 20144
Has Layer 5 - if set,
multitexture information for texture
layer 5 is present.
5
Has Layer 6 - if set,
multitexture information for texture
layer 6 is present.
6
Has Layer 7 - if set,
multitexture information for texture
layer 7 is present.
7-31 Spare
The following fields are repeated for each multitexture layer that is
specified as present by the bits set in the Attribute mask field above. Thismechanism allows for “sparse” multitexture layer information to be present
and does not require that the information present be contiguous.
Unsigned Int
Varies2
textureN - Texture index for texture
layer N
Unsigned Int
Varies2effectN - Multitexture effect for
texture layer N
0 = Texture environment

Unsigned Int

Varies2

Unsigned Int

Varies2

1 = Bump map
2-100 = Reserved by MultiGenParadigm, Inc.
>100 = user (runtime) defined
mappingN - Texture mapping index
for texture layer N
dataN - Texture data for layer N. Thisis user defined.
For example, it may be used as a
blend percentage or color or any otherdata needed by the runtime todescribe texture layer N© 2015 Open Geospatial Consortium

ü
ü
ü


ü
ü
ü
ü


ü
ü

279

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
UV List Record
The uv list record is an ancillary record of vertex nodes. This record (if present) always
follows the vertex list or morph vertex list record and contains texture layer information for
the vertices represented in the vertex list record it follows.

UV List Record

Data Type

OffsetLengthDescription

Unsigned Int
Unsigned Int
Int

0
2
4

2
2
4

UV List Opcode 53
Length - length of the record
Attribute mask - Bit mask
indicating what kind of multitexture information is present inthis record. Bits are orderedfrom left to right as follows:
Bit # Description0
Has Layer 1 - if set, uvs
for layer 1 are present
1
Has Layer 2 - if set,uvs for layer 2 are present
2
Has Layer 3 - if set,uvs for layer 3 are present
3
Has Layer 4 - if set,uvs for layer 4 are present
4
Has Layer 5 - if set,uvs for layer 5 are present
5
Has Layer 6 - if set,uvs for layer 6 are present
6
Has Layer 7 - if set,uvs for layer 7 are present
7-31 SpareCDB OpenFlight
Reader

ü
ü
ü

ü
ü
ü
ü
ü
ü
ü


The following fields are repeated for each vertex contained in the corresponding vertex list or
morph vertex list record.
If this uv list record follows a vertex list record, the following fields are repeated for each layer
present (as specified by the bits set in Attribute mask).
Data Type
OffsetLengthFloat
4ui, N - Texture coordinate U for vertex i, layer N
Float
4vi, N - Texture coordinate V for vertex i, layer N
The number of vertices represented in the uv list record that follows a vertex list record must be
identical to the number of vertices contained in that vertex list record. This number can also be
calculated as follows:
Number of vertices = (Length - 8) / (8 * X), where X is the number of bits set in Attribute mask.
If this uv list record follows a morph vertex list record, the following fields are repeated for eachlayer present (as specified by the bits set in Attribute mask).

© 2015 Open Geospatial Consortium

280

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

Data Type
Float
Float
Float
Float

Offset4
4
4
4

Lengthu0i, N - Texture U for the 0% vertex i, layer N
v0i, N - Texture V for the 0% vertex i, layer N
u100i, N - Texture U for the 100% vertex i, layer N
v100i, N - Texture V for the 100% vertex i, layer N

Again, the number of vertices represented in the uv list record that follows a morph vertex list
record must be identical to the number of vertices contained in that morph vertex list record. This
number can also be calculated as follows:
Number of vertices = (Length - 8) / (16 * X), where X is the number of bits set in Attribute mask.

ExampleConsider a triangular face (3 vertices) that contains morph vertex information and has
texture layers 1 and 3 defined. The following example shows the contents of the uv list
record corresponding to the morph vertex list record representing this triangle:
Data TypeopcodelengthuvmaskOffsetUnsigned Int
Unsigned Int
Unsigned Int

Length22
4

u0 1,1v0 1,1
u100 1,1v100 1,1
u0 1,3v0 1,3u100 1,3v100 1,3
u0 2,1v0 2,1
u100 2,1
v100 2,1
u0 2,3v0 2,3u100 2,3v100 2,3
u0 3,1v0 3,1
u100 3,1
v100 3,1
u0 3,3v0 3,3u100 3,3v100 3,3

Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float

8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8

Description
53 (UV List opcode).
200 (Length of the record)
1010 0000 0000 0000 (layers 1and 3 ON,
others OFF)
Texture U for the 0% vertex 1, layer 1.
Texture V for the 0% vertex 1, layer 1.
Texture U for the 100% vertex 1, layer 1.
Texture V for the 100% vertex 1, layer 1.
Texture U for the 0% vertex 1, layer 3.
Texture V for the 0% vertex 1, layer 3.
Texture U for the 100% vertex 1, layer 3.
Texture V for the 100% vertex 1, layer 3.
Texture U for the 0% vertex 2, layer 1.
Texture V for the 0% vertex 2, layer 1.
Texture U for the 100% vertex 2, layer 1.
Texture V for the 100% vertex 2, layer 1.
Texture U for the 0% vertex 2, layer 3.
Texture V for the 0% vertex 2, layer 3.
Texture U for the 100% vertex 2, layer 3.
Texture V for the 100% vertex 2, layer 3.
Texture U for the 0% vertex 3, layer 1.
Texture V for the 0% vertex 3, layer 1.
Texture U for the 100% vertex 3, layer 1.
Texture V for the 100% vertex 3, layer 1.
Texture U for the 0% vertex 3, layer 3.
Texture V for the 0% vertex 3, layer 3.
Texture U for the 100% vertex 3, layer 3.
Texture V for the 100% vertex 3, layer 3© 2015 Open Geospatial Consortium

281

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Replicate Record
A replicate record is an ancillary record of group, face, and light (string) point nodes. It
indicates the number of times the group, face, or light (string) point is instantiated. An
ancillary transformation record must also be present. The transformation is iteratively
applied to each instance to uniquely place it in the database.

Data Type

OffsetLengthInt
Unsigned
Int
Int
Int

0
2

2
2

4
6

2
2

Replicate Record
Description

Replicate Opcode 60
Length - length of therecordNumber of replications
Reserved

CDB OpenFlight
Reader

ü
ü

ü


Road Zone Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Road Zone Records.
The road zone record is an ancillary record of the header node. It references a road zone
file that contains gridded elevation data. The format of the file is described in “Road Zone
Files,” page 101.
Data TypeInt
Unsigned Int
CharInt
DoubleDoubleDoubleDoubleDoubleInt
Int

Offset
0
2
4
124
128
136
144
152
160
168
172

Road Zone Record

Length
2
2
120
4
8
8
8
8
8
4
4

Description
Road Path Opcode 88
Length - length of the record
Zone file name; 0 terminates
Reserved
Lower-left x coordinate
Lower-left y coordinate
Upper-right x coordinate
Upper-right y coordinate
Grid interval
Number of posts along x axis
Number of posts along y axis

Transformation Records

CDB OpenFlight Readers: CDB-compliant OpenFlight readers consider only the Matrix
Transformation Records. The Rotate About Edge Record, Translate Record, Scale Record, Rotate About
Point Record, Rotate and/or Scale to Point Record, Put Record and General Matrix Record are specific to
the MultiGen Creator tool; as a result, CDB OpenFlight readers do not consider them.
Transformation records may be ancillary records of most nodes. All hierarchical nodes may© 2015 Open Geospatial Consortium

282

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
be transformed except the header node. Some nodes may only be transformed implicitly, as
part of some other operation, such as point replication within a light point string.
There are several distinct types of transformation records. For a transformation applied to
any node, a matrix record is always present and represents the final (composite)transformation. When present, the transformation records that follow a matrix record
represent the individual transformations applied to the node. If an application only needs
the final transformation, the matrix record is sufficient and the transformation records that
follow the matrix record can be ignored. The records following the matrix record are only
needed by the application if it needs to decompose the transformation. The MultiGenParadigm, Inc. modeling environment uses these records in order to allow the modeler tomodify any of the discrete transformations applied to a node.
Again, each record that follows the matrix record represents a discrete transformation thathas been concatenated to form the composite matrix. Concatenation is done in the orderthat the records are encountered, using pre-multiplication.
Note: The final and general matrices are only single-precision, while the discrete transformations

are double-precision.

Matrix Record

Data TypeInt
Unsigned Int
Float

Offset0
2
4

Length22
4*16

Description
Matrix Opcode 49
Length - length of the record
4x4 matrix, row major order

Data TypeInt
Unsigned Int
Int
DoubleDoubleFloat
Int

Offset
0
2
4
8
32
56
60

Length
2
2
4
8*3
8*3
4
4

Description
Rotate About Edge Opcode 76
Length - length of the record
Reserved
First point on edge (x, y, z)Second point on edge (x, y, z)
Angle by which to rotate
Reserved

Data TypeInt
Unsigned Int
Int
DoubleDoubleOffset02
4
832

Length
2
2
4
8*3
8*3

Description
Translate Opcode 78
Length - length of the record
Reserved
From point (x, y, z)
Delta to translate (x, y, z)Rotate About Edge Record

Translate Record© 2015 Open Geospatial Consortium

283

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

Data TypeInt
Unsigned Int
Int
Double
Float
Float
Float
Int

Offset
0
2
4
8
32
36
40
44

Length
2
2
4
8*3
4
4
4
4

Description
Scale Opcode 79
Length - length of the record
Reserved
Scale center (x, y, z)
x scale factor
y scale factor
z scale factor
Reserved

Data TypeInt
Unsigned Int
Int
Double
Float
Float
Float
Float

Offset
0
2
4
8
32
36
40
44

Length
2
2
4
8*3
4
4
4
4

Data TypeInt
Unsigned Int
Int
DoubleDoubleDouble
Float
Float
Float
Int

Offset
0
2
4
8
32
56
80
84
88
92

Length
2
2
4
8*3
8*3
8*3
4
4
4
4

Description
Rotate and/or Scale Opcode 81
Length - length of the record
Reserved
Scale center (x, y, z)
Reference point (x, y, z)
To point (x, y, z)Overall scale factor
Scale factor in direction of axis
Angle by which to rotate
Reserved

Data TypeInt
Unsigned Int
Int
DoubleDoubleDoubleDoubleDoubleDoubleOffset
0
2
4
8
32
56
80
104
128

Length
2
2
4
8*3
8*3
8*3
8*3
8*3
8*3

Description
Put Opcode 82
Length - length of the record
Reserved
From point origin (x, y, z)
From point align (x, y, z)
From point track (x, y, z)
To point origin (x, y, z)
To point align (x, y, z)
To point track (x, y, z)Rotate About Point Record

Description
Rotate About Point Opcode 80
Length - length of the record
Reserved
Rotation center point (x, y, z)i, axis of rotationj, axis of rotationk, axis of rotation
Angle by which to rotate

Rotate and/or Scale to Point Record

Put Record© 2015 Open Geospatial Consortium

284

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

Data TypeInt
Unsigned Int
Float

Offset0
2
4

Length22
4*16

General Matrix Record

Description
General Matrix Opcode 82
Length - length of the record
4x4 matrix, row major order

Vector Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Vector Records.
A vector record is an ancillary record of the (pre v15.4) face node. Its only use is to provide
the direction vector for old-style unidirectional and bidirectional light point faces.
Data TypeInt
Unsigned Int
Float
Float
Float

Offset024812Vector Record

Length22444Description
Vector Opcode 50
Length - length of the record
i component
j component
k component

Bounding Volume Records
Bounding volumes are ancillary records for group nodes only. They generally encompass all
the geometry of a group’s children. A bounding volume may describe a box, sphere,
cylinder, convex hull or histogram.
The center coordinate of a bounding volume is stored as a separate record. The orientationof a bounding volume is also stored as a separate record. The convex hull data isrepresented by a sequence of triangles forming the convex hull around the group geometry.
Applications may use the bounding volume information with culling and collision detection
algorithms.

© 2015 Open Geospatial Consortium

285

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

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Int
Double0222Bounding Box Opcode 74
Length - length of the record

4
8

4
8

Double16

8

Double24

8

Double32

8

Double40

8

Double48

8

Reserved
x coordinate of lowest
cornery coordinate of lowest
cornerz coordinate of lowest
cornerx coordinate of highest
cornery coordinate of highest
cornerz coordinate of highest
cornerCDB OpenFlight
Reader

ü
ü


ü
ü
ü
ü
ü
ü

Bounding Sphere Record
Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
Double22

Bounding Sphere Opcode
105
Length - length of the record

4
8

4
8

Reserved
Radius of the sphere

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
DoubleDouble22

Bounding Cylinder Opcode
106
Length - length of the record

4
8
16

4
8
8

Reserved
Radius of the cylinder base
Height of the cylinder

CDB OpenFlight
Reader

ü
ü


ü

Bounding Cylinder Record© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü


ü
ü

286

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Bounding Convex Hull Record
Data
Type
Int

OffsetLength02

Description

Bounding Convex Hull
Opcode 107
Unsigned 2
2
Length - length of theInt
recordInt
4
4
Number of triangles
The following fields are repeated for each triangle represented
in the convex hull data.
In the fields listed below, N ranges from 0 to Number oftriangles-1.
Double8+(N*72)8
x coordinate of vertex 1 oftriangleN
Double16+(N*72) 8
y coordinate of vertex 1 oftriangleN
Double24+(N*72) 8
z coordinate of vertex 1 oftriangleN
Double32+(N*72) 8
x coordinate of vertex 2 oftriangleN
Double40+(N*72) 8
y coordinate of vertex 2 oftriangleN
Double48+(N*72) 8
z coordinate of vertex 2 oftriangleN
Double56+(N*72) 8
x coordinate of vertex 3 oftriangleN
Double64+(N*72) 8
y coordinate of vertex 3 oftriangleN
Double72+(N*72) 8
z coordinate of vertex 3 oftriangleN© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü

ü
ü
ü
ü
ü
ü
ü
ü
ü

287

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Bounding Histogram Record
Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

4

Variable

Bounding Histogram
Opcode 119
Length - length of therecordThe contents of this record
is reserved for use by MultiGen-Paradigm.

CDB OpenFlight
ReaderBounding Volume Center Record
Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
DoubleDoubleDouble22

Bounding Volume Center
Opcode 108
Length - length of the record

4
8
16
24

4
8
8
8

Reserved
x coordinate of centery coordinate of centerz coordinate of center

CDB OpenFlight
Reader

ü
ü


ü
ü
ü

Bounding Volume Orientation Record
Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
DoubleDoubleDouble22

Bounding Volume
Orientation Opcode 109
Length - length of the record

4
8
16
24

4
8
8
8

Reserved
Yaw angle
Pitch angle
Roll angle© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü


ü
ü
ü

288

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

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider CAT Records.
The CAT data records contain the information needed to reconstruct a Continuously
Adaptive Terrain skin from its OpenFlight representation. They provide the information
which links faces between levels of detail within a CAT skin. CAT data is stored as a key
table with an opcode of 116. For specific detail please refer to “Key Table Records” onpage 76.
Each CAT data record describes how a face within a CAT skin is related to faces at the next
finer level of detail. The coarsest level of detail is level zero. The next finer level of detail isone, and so forth. Each data record is stored in the key table using an ordinal key, counting
up from zero. The face node ID is stored in the data record, thereby providing the crossreference to the OpenFlight face node that represents it.
In OpenFlight, each CAT level of detail is parented by a LOD node. Each CAT triangle
strip is parented by a group node.

CAT Data Header Record

Data TypeInt
Unsigned Int
Int

Offset0
2
4

Length
2
2
4

Int
Int

8
12

4
4

Description
CAT Data Opcode 116
Length - length of the record
Subtype
1 = indicates this record is a key table header
Max number - maximum number of face keys
Actual number - actual number of face keys

CAT Data Header Record (Continued)

Data Type
OffsetLengthDescription
Int
16
4
Total length of packed face dataInt
20
4
Reserved
Int
24
4
Reserved
Int
28
4
Reserved
The following fields are repeated for each face record represented in the CAT data.
In the fields listed below, N ranges from 0 to Actual number - 1.
Int
32+(N*12) 4
Face indexN - index of face N
Int
36+(N*12) 4
ReservedN - reserved space for face N
Int
40+(N*12) 4
Face data offsetN - offset for face data record N in the
CAT data.
Note: This offset is measured relative to the Packed
face data field in the CAT data face record described
below.

© 2015 Open Geospatial Consortium

289

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

Data TypeInt
Unsigned Int
Int

Offset0
2
4

CAT Data Face Record

Length224Description
CAT Data Opcode 116
Length - length of the record
Subtype2 = indicates this record is a key data record
Int84
Total length of all packed face records
The following fields constitute one face record and are repeated for each face record represented
in the CAT data. In the fields listed below, N ranges from 0 to Actual number - 1. Actual
number is from the CAT data header record.
Int
Varies4
LODN - Level of detail to which this face N belongs.
Int
Varies4Child index 1N - The 1st child (within this table) of faceN, or -1 for no face.
Int
Varies4Child index 2N - The 2nd child (within this table) offace N, or -1 for no face.
Int
Varies4Child index 3N - The 3rd child index (within this table)of face N, or -1 for no face.
Int
Varies4Child index 4N - The 4th child index (within this table)of face N, or -1 for no face.
Int
Varies4
ID LengthN - length of face node ID string which
follows
Char
VariesVariesIDN - ASCII ID of the face to which this record applies.

© 2015 Open Geospatial Consortium

290

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

Extension Attribute Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Extension Attribute

Records.

The extension attribute record is an ancillary record defined by an extension site thatutilizes the extensibility of the OpenFlight format. It specifies the site information of a third
party extended record which describes additional data that is not represented by thestandard OpenFlight records. The data itself is transparent to users other than theextension site. The data can be accessed by the combination of the OpenFlight API and thedata dictionary defined by the extension site.
Any hierarchical node can contain extension attribute records. Extension attributes are
introduced by an push extension control record and concluded by a pop extension control
record.
The extension record (Opcode 100) may also introduce a new node type (See “Extension
Record” on page 51.)
Data TypeInt
Unsigned Int
Char
Char
Int
Int
Unsigned Int
Char

Offset
0
2
4
12
20
21
22
24

Extension Attribute Record
Length
2
2
8
8
1
1
2
Variable

Description
Extension Opcode 100
Length of the total extension record
7 char ASCII ID; 0 terminates
Site ID - Unique site nameReserved
Revision - site specific
Record code - site specific
Extended data - site specific

Continuation Record
All OpenFlight records begin with a 4 byte sequence. The first two bytes identify the record(opcode) and the second two bytes specify the length of the record. Given this regularrecord structure, the length of all OpenFlight records is limited to the largest value that canbe encoded with 2 bytes or 16 bits (65535). For fixed-size records, this maximum size issufficient. For variable-size records, this limitation is addressed with the continuation
record which is described in this section.
The continuation record accommodates variable size records in the OpenFlight Scene
Description. The continuation record is used to “continue” a record in the OpenFlight filestream. It appears in the stream immediately following the record that it “continues” (therecord that is being continued will be referred to as the “original” record). In this way, thecontinuation record is an ancillary record to any other record type. The data contained in
the continuation record is defined by the original record and is assumed to be directly
appended onto the content of the original record.
Note:

Multiple continuation records may follow a record, in which case all continuation
records would be appended (in sequence) to the original record.

© 2015 Open Geospatial Consortium

291

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

Continuation Record

Data Type

OffsetLengthDescription

Unsigned
Int
UnsignedInt
Varies

0

2

2

2

4

Length4

Continuation Record
Opcode 23
Length - length of therecordDepends on the originalrecord. The contents of thisfield are to be appended
directly to the end of theoriginal record contents(before the original record
contents are parsed)

CDB OpenFlight
ReaderüüüIn theory, any OpenFlight record may be “continued”, but in practice only variable length
records, whose length is likely to exceed 65535 bytes, are. Following is a list of the variable
length OpenFlight record types to which the continuation record is likely to apply:
W“Extension Record” on page 51

W“Name Table Record” on page 71

W“Local Vertex Pool Record” on page 30

W“Mesh Primitive Record” on page 32

Example: In the following example, the color name table is “too” big to fit in 65535 bytes so
the primary palette record, NAME TABLE, is followed by one (or more) CONTINUATION
records. The contents of each of the continuation records is appended to the contents of thename table record before the name table data is parsed.
NAME TABLE
CONTINUATIONCONTINUATION© 2015 Open Geospatial Consortium

292

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

Palette Records
Palette records are ancillary records of the header node. They contain attribute data
globally shared by other nodes in the database. Other nodes, such as face nodes, reference
the palette data by index.
Individual palettes contain resources such as vertex, material, light source, texture pattern,
and line style definitions.
Vertex Palette Records
Double precision vertex records are stored in a vertex palette for the entire database.
Vertices shared by one or more geometric entities are written only one time in the vertex
palette. This reduces the overall size of the OpenFlight file by writing only “unique”
vertices. Vertex palette records are referenced by faces and light points via vertex list andmorph vertex list records. See “Vertex List Record” on page 39 and “Morph Vertex List
Record” on page 39 for more information.
The vertices referenced by mesh nodes are not contained in vertex palette records.
Instead, they are contained in local vertex pool records. See “Local Vertex Pool Record” onpage 30. The vertex palette record signifies the start of the vertex palette. It contains a one
word entry specifying the total length of the vertex palette, which is equal to the length of
this header record plus the length of the following vertex records. The individual vertex
records follow this header, each starting with its own opcode. The length field in the vertex
palette record makes it possible to skip over vertex records until the data is actually needed.
Note:

As stated above, vertices may be shared, and are accessed through the vertex and morph
vertex list records following each face record. A face may contain all morph vertices, allnon-morph vertices, or a mixture of both. Thus there can be one or more list records
following each face. Consecutive vertices with the same type are grouped together within alist record. The length of each list record is determined by the number of consecutive
vertices of each type. For each vertex, there is a one word field pointing to its vertex recordin the vertex palette. Since this offset includes the length of the vertex palette record, thevalue of the first pointer is 8.
Data Type

OffsetInt

Vertex Palette Record
LengthDescription

02

Unsigned Int

2

2

Int

4

4

Vertex Palette Opcode
67
Length - length of therecordLength of this record
plus length of the vertex
paletteCDB OpenFlight
ReaderüüüThe vertex palette record is immediately followed by vertex records. Each vertex record
contains all the attributes of a vertex that has been referenced one or more times in the
database.
The Color name index references a name in the color name palette.

© 2015 Open Geospatial Consortium

293

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The Hard edge flag indicates this vertex starts an edge that is to be preserved by polygon
reduction or decimation algorithms.
The Normal frozen flag indicates the normal is not to be updated by shading or lighting
algorithms.
The No color flag indicates the vertex does not have a color. If set, neither the Packed color
or Vertex color index fields are defined.
When a vertex has a color (the No color flag is not set), the Packed color field is always
specified (regardless of the value of the Packed color flag) and contains the red, green, blue
and alpha color components. For alpha, 0 represents fully transparent, 255 fully opaque. If
the Packed color flag is set, the Vertex color index field will be undefined.
Here are some examples that show how vertex palette records can represent vertex colors:
PackedColor
Flag

PackedColor

VertexColorIndex

Result0a, g, b, r

N

Vertex color index and Packed color attributes
are both specified.
a, b, g, r specify the vertex color components.
g, b, r components match those of color index Nin palette.
Vertex color index attribute is not specified,
only packed color.
a, b, g, r specify the vertex color components.

1

a, g, b, r

Not defined

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Unsigned
Int
Int

2

2

4

2

Vertex with Color Opcode
68
Length - length of therecordColor name index

62Vertex with Color Record

Double
Int

8
32

8*3
4

Unsigned
Int

36

4

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Packed color (a, b, g, r) always specified when thevertex has color
Vertex color index - valid
only if vertex has color andPacked color flag is not set© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü
ü

294

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

Data Type

Vertex with Color and Normal Record
OffsetLengthDescription

Int

0

2

Unsigned
Int
Unsigned
Int
Int

2

2

4

2

Vertex with Color andNormal Opcode 69
Length - length of therecordColor name index

62

Double
Float
Int

8
32
44

8*3
4*3
4

Unsigned
Int

48

4

Int

52

4

Data Type

OffsetInt
Unsigned
Int
Unsigned
Int
Int

DoubleFloat

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Vertex normal (i, j, k)
Packed color (a, b, g, r) always specified when thevertex has color
Vertex color index - valid
only if vertex has color andPacked color flag is not set
Reserved

Vertex with Color and UV Record
LengthDescription

0

2

2

2

4

2

Vertex with Color and UVOpcode 71
Length - length of therecordColor name index

6

2

8
32

8*3
4*2

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Texture coordinate (u, v)© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü
ü
ü

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü

295

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

40

4

Packed color (a, b, g, r) always specified when thevertex has color
Vertex color index - valid
only if vertex has color andPacked color flag is not set

Unsigned
Int

44

4

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Unsigned
Int
Int

2

2

4

2

Vertex with Color, Normal
and UV Opcode 70
Length - length of therecordColor name index

6

2

ü
ü

Vertex with Color, Normal and UV Record

Double
Float
Float
Int

8
32
44
52

8*3
4*3
4*2
4

Unsigned
Int

56

4

Int

60

4

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Vertex normal (i, j, k)
Texture coordinate (u, v)
Packed color (a, b, g, r) always specified when thevertex has color
Vertex color index - valid
only if vertex has color andPacked color flag is not set
Reserved© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü
ü
ü
ü


296

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

Color Palette Record
The color palette record contains all colors indexed by face and vertex nodes in the
database.
The color record is divided into two sections: one for color entries and one for color names.
All color entries are in 32-bit packed format (a, b, g, r). Each color consists of red, green,
and blue components of 8 bits each, plus 8 bits reserved for alpha (future). Currently alphais always 0xff (fully opaque). The color entry section consists of 1024 ramped colors of 128
intensities each.
The color name section may or may not be included. If the length of the color palette record
is greater than 4228, then you can assume that the color name section is included. When it ispresent, the color name section consists of a header followed by 0 or more color nameentries. The header contains the number of names in the palette. If this value is 0, there areno names following in the palette. Each color name entry contains the name string, pointerto the associated color entry, and other reserved information. The name field is a variablelength, null-terminated ASCII string, with a maximum of 80 bytes.

Color Palette Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Int

0
2

2
2

Color Palette Opcode 32
Length - length of the record

4
132

128
4

Int

136

4

etc.
Int

...
4224

...
4

Reserved
Brightest RGB of color 0,
intensity 127 (a, b, g, r)
Brightest RGB of color 1,
intensity 127 (a, b, g, r)

Brightest RGB of color 1023,
intensity 127 (a, b, g, r)
As stated above, if the length of the color palette record is greaterthan 4228, then it also contains a color name section as shown below:
Int
4228
4
Number of color names
The following fields are repeated for each color name entry present in
the color palette record.
In the fields listed below, N ranges from 0 to Number of color names- 1.
Unsigned
Varies2
LengthN - length of color nameInt
subrecord N. This length is thetotal length of this field plus
the length of the next 3 fields
plus the length of the Color
nameN field.
Int
Varies2
ReservedN - reserved space for© 2015 Open Geospatial Consortium

CDB
OpenFlight
Reader

ü
ü


ü
ü
ü
ü
ü
ü

ü



297

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

Varies2

Int

Varies2

Char

VariesLengthN8

color name N
Color indexN - index of color
in palette corresponding tocolor name N
ReservedN - reserved space forcolor name N
Color nameN - color name N; 0
terminates, max 80 bytes

ü

ü

Name Table Record
The name table contains a lookup table of names referenced within the database. These
names are typically used as attributes (e.g., color name index in the face record). The
primary benefit of the name table is to allow name referencing, so each name string is only
stored once. Each name entry in the name table contains fields for the its length, index, andstring. The name index is used by the database to reference names within the table. The
name string is a variable-length, null-terminated ASCII string, with a maximum of 80
bytes.

Data Type

OffsetInt
0
Unsigned
2
Int
Int
4
Unsigned
8
Int
Name Table Entry 0Int
10
Unsigned
14
Int
Char
16

Length22Name Table Record
Description

Name Table Opcode 114
Length - length of therecordNumber of names
Next available name index

4
2

ü
ü

ü


Length0 - length of entry 0
Name index0 - index
corresponding to entry 0
Name string0 - name forentry 0; 0 terminates.
Variable length, maximumof 80 charsüü

Length1 - length of entry 1
Name index1 - index
corresponding to entry 1
VariesName string1 - name forentry 1; 0 terminates.
Variable length, maximumof 80 chars
...
...
...
...
Name Table Entry N, where N is Number of names - 1üüName Table Entry 1
Int
VariesUnsigned
VariesInt
Char
Varies4
2

CDB OpenFlight
ReaderVaries4
2© 2015 Open Geospatial Consortium

ü

ü

298

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

VariesVaries4
2

VariesVariesLengthN - length of entry N
Name indexN - index
corresponding to entry N
Name stringN - name forentry N; 0 terminates.
Variable length, maximumof 80 chars

ü
ü
ü

Material Palette Record
The material palette contains descriptions of materials used while drawing geometry. It is
composed of an arbitrary number of material palette records. The material palette records
must follow the header record and precede the first push.
The appearance of a face or mesh in OpenFlight is a combination of the geometry (face ormesh) color and the material properties. The geometry color is factored into the material
properties as follows:
Ambient:
The displayed material's ambient component is the product of the ambient component of
the material and the geometry color:
Displayed ambient (red) = Material ambient (red)* geometry color (red)Displayed ambient (green) = Material ambient (green)* geometry color (green)
Displayed ambient (blue) = Material ambient (blue)* geometry color (blue)
For example, suppose the material has an ambient component of {1.0,.5,.5} and thegeometry color is {100, 100, 100}. The displayed material has as its ambient color {100, 50,
50}.
Diffuse:As with the ambient component, the diffuse component is the product of the diffuse
component of the material and the geometry color:
Displayed diffuse (red) = Material diffuse (red)* geometry color (red)Displayed diffuse (green) = Material diffuse (green)* geometry color (green)
Displayed diffuse (blue) = Material diffuse (blue)* geometry color (blue)
Specular:
Unlike ambient and diffuse components, the displayed specular component is taken directlyfrom the material:
Displayed specular (red) = Material specular (red)Displayed specular (green) = Material specular (green)
Displayed specular (blue) = Material specular (blue)© 2015 Open Geospatial Consortium

299

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Emissive:
The displayed emissive component is taken directly from the material:
Displayed emissive (red) = Material emissive (red)Displayed emissive (green) = Material emissive (green)
Displayed emissive (blue) = Material emissive (blue)
Shininess:
The MultiGen-Paradigm, Inc. modeling environment uses the shininess directly from thematerial. Specular highlights are tighter, with higher shininess values.
Alpha:An alpha of 1.0 is fully opaque, while 0.0 is fully transparent. The final alpha applied is acombination of the transparency value of the geometry (face or mesh) with the alpha valueof the material record. The final alpha value is a floating point number between 0.0(transparent) and 1.0 (opaque), and is computed as follows:
Final alpha = material alpha * (1.0 - (geometry transparency / 65535))

Material Palette Record

Data
Type
Int
Int
Int
Char
Int

OffsetLengthDescription

0
2
4
8
20

2
2
4
12
4

Float

24

4*3

Float

36

4*3

Float

48

4*3

Float

60

4*3

Float
Float

72
76

4
4

Int

80

4

Material Palette Opcode 113
Length - length of the record
Material index
Material name
Flags
0 = Material is used
1-31 = Spare
Ambient component ofmaterial (r, g, b) *Diffuse component ofmaterial (r, g, b) *Specular component ofmaterial (r, g, b) *Emissive component ofmaterial (r, g, b) *Shininess - (0.0-128.0)
Alpha - (0.0-1.0) where 1.0
is opaque
Reserved

CDB OpenFlight
Reader* normalized values between 0.0 and 1.0, inclusive.

ü
ü
ü
ü
ü
ü

ü
ü
ü
ü
ü
ü


Texture Palette Record
There is one record for each texture pattern referenced in the database. These records must
follow the header record and precede the first push.
A palette and pattern system can be used to reference the texture patterns. A texture palette© 2015 Open Geospatial Consortium

300

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014is made up of 256 patterns. The pattern index for the first palette is 0 - 255, for the second
palette 256 - 511, etc. Note: If less than 256 patterns exist on a palette, several patternindices are unused. The x and y palette locations are used to store offset locations in thepalette for display.

Texture Palette Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Int
Int

0
2

2
2

Texture Palette Opcode 64
Length - length of the record

4
204
208

200
4
4*2

File name of texture pattern
Texture pattern index
Location in the texture
palette (x, y)© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü
ü


301

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Eyepoint and Trackplane Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Eyepoint andTrackplane Palette Records.

OpenFlight files can contain up to ten eyepoint and trackplane positions. The first eyepoint
and trackplane in the file is reserved as the “last” one set during the modeling session. The
other nine are user-defined. Both the eyepoints and trackplanes are combined in the
Eyepoint and Trackplane palette record which is described in this section.

Eyepoint and Trackplane Palette Record

Data Type
OffsetLengthDescription
Int
02
Eyepoint and Trackplane Palette Opcode 83
Unsigned Int
22
Length - length of the record
Int
4
4
Reserved
The following fields are repeated for 10 eyepoints
Eyepoint 0 - 272 bytes
Double
8
Float
32
Float
44
Float
108
Float
112
Float
116
Float
120
Float
124
Float
188
Float
200
Float
204
Float
208
Int
220
Int
224
Int
228
Int
232
Int
236
Int
240
Int
244
Int
276
Eyepoint 1
280

8*3
4*3
16*4
4
4
4
4
16*4
3*4
4
4
3*4
4
4
4
4
4
4
4*8
4
272

Eyepoint 2

552

272

Eyepoint 3

824

272

Eyepoint 4

1096

272

Eyepoint 5

1368

272

Rotation center (x, y, z)
Yaw, pitch, and roll angles
4x4 rotation matrix, row major order
Field of view
Scale
Near clipping plane
Far clipping plane
4x4 fly-through matrix, row major order
Eyepoint position (x, y, z)
Yaw of fly-throughPitch of fly-throughEyepoint direction vector (i, j, k)
No fly through - 1 if no fly-throughOrtho view - 1 if ortho drawing mode
Valid eyepoint - 1 if this is a valid eyepoint
Image offset x
Image offset y
Image zoom
Reserved
Reserved
Eyepoint 1 - the fields listed above arerepeated here.
Eyepoint 2 - the fields listed above arerepeated here.
Eyepoint 3 - the fields listed above arerepeated here.
Eyepoint 4 - the fields listed above arerepeated here.
Eyepoint 5 - the fields listed above arerepeated here.

© 2015 Open Geospatial Consortium302

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

1640

272

Eyepoint 7

1912

272

Eyepoint 8

2184

272

Eyepoint 9

2456

272

Eyepoint 6 - the fields listed above arerepeated here.
Eyepoint 7 - the fields listed above arerepeated here.
Eyepoint 8 - the fields listed above arerepeated here.
Eyepoint 9 - the fields listed above arerepeated here.

Eyepoint and Trackplane Palette Record (Continued)

Data Type
OffsetLengthDescription
The following fields are repeated for 10 trackplanes
Trackplane 0 - 128 bytes
Int
2728
Int
2732
Double2736
Double2760
Double2784
Boolean
2808
Int
2809

4
4
8*3
8*3
8*3
1
1

Int

2810

1

Int
Float
DoubleDoubleInt
Int
Boolean
Int
Int
DoubleBooleanInt
Trackplane 1

2811
2812
2816
2824
2832
2833
2834
2835
2836
2840
2848
2852
2856

1
4
8
8
1
1
1
1
4
8
4
4
128

Trackplane 2

2984

128

Trackplane 3

3112

128

Trackplane 4

3240

128

Trackplane 5

3368

128

Valid trackplane - 1 if this is a valid trackplane
Reserved
Trackplane origin coordinate (x, y, z)
Trackplane alignment coordinate (x, y, z)
Trackplane plane coordinate (x, y, z)
Grid visible - 1 if grid is visible
Grid type flag
0 = rectangular grid
1 = radial grid
Grid under flag
0 = draw grid over scene
1 = draw grid under scene
2 = draw grid depth buffered
Reserved
Grid angle for radial grid
Grid spacing in X. Radius if radial grid.
Grid spacing in Y
Radial grid spacing direction control
Rectangular grid spacing direction control
Snap cursor to grid - 1 if snap cursor to grid is on
Reserved
Reserved
Grid size (a power of 2)
Mask of visible grid quadrants
Reserved
Trackplane 1 - the fields listed above are repeatedhere.
Trackplane 2 - the fields listed above are repeatedhere.
Trackplane 3 - the fields listed above are repeatedhere.
Trackplane 4 - the fields listed above are repeatedhere.
Trackplane 5 - the fields listed above are repeated© 2015 Open Geospatial Consortium

303

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

Trackplane 6

3496

128

Trackplane 7

3624

128

Trackplane 8

3752

128

Trackplane 9

3880

128

here.
Trackplane 6 - the fields listed above are repeatedhere.
Trackplane 7 - the fields listed above are repeatedhere.
Trackplane 8 - the fields listed above are repeatedhere.
Trackplane 9 - the fields listed above are repeatedhere.

Key Table Records

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Key Table

Records.

Key table records store variable length data records and their identifiers. The linkage
editor, sound palette, and CAT Data are stored as key table records. The first key table
record contains the key table header and a set of keys. If all the keys cannot fit into the firstrecord, additional key records are written. This is followed by one or more key table data

records.
A key table consists of: For an example of the use of key table records, see “Sound PaletteRecord” on page 108.

Data TypeInt

Offset0

Key Table Header Record
Length2

Description
Opcode - opcode of record using key table
for storage
Unsigned Int 2
2
Length - length of the record
Int44
Subtype
1 = indicates this record is a key table
headerInt
8
4
Max number - maximum number of entries
Int
12
4
Actual number - actual number of entries
Int
16
4
Total length of packed data
Int
20
4*3
Reserved
The following fields are repeated for each key in the key table.
In the fields listed below, N ranges from 0 to Actual number - 1.

© 2015 Open Geospatial Consortium

304

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

32+(N*12)
36+(N*12)

4
4

Int

40+(N*12)

4

Key valueN - key value N
ReservedN - reserved space for key N,
defined by record using key table for storage
Data offsetN - offset for data corresponding
to key N.
Note: This offset is measured relative to the
Packed data field in the key table data record
described below.

© 2015 Open Geospatial Consortium

305

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

Data TypeInt
Unsigned Int
Int

Offset0
2
4

Length
2
2
4

Int
Char

8
12

4
Data
lengthKey Table Data

Description
Opcode - opcode of record using key table for storage
Length - length of the record
Subtype2 = indicates this record is a key table data record
Data length
Packed data
Data is always 4 byte aligned, with unused bytes set to 0.
Data length can be calculated as follows: Length - 12

Linkage Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Linkage PaletteRecords.

Database linkages use key table records. Linkage data consists of two different constructs:
nodes and arcs. Nodes usually contain data pertaining to database entities such as DOFs. In
addition, the nodes may represent modeling driver functions and code nodes. The arcs
contain information on how all the nodes are connected to each other. For most nodes, thevalue of the node is contained in the following Entity name subrecord. For example, thisnode value can be a node name, when the node represents a database entity, or a mathformula as a string, in the case of a formula node. Names are stored as null-terminated
ASCII strings.
See “Linkage Editor Parameter IDs” on page 103 for parameter ID values and descriptions.
Data TypeInt
Unsigned Int
Int

Offset0
2
4Linkage Palette Header Record

Length224Description
Linkage Palette Opcode 90
Length - length of the record
Subtype
1 = indicates this record is a key table headerInt
8
4
Max number - maximum number of entries. Each entry iseither a node, arc, or entity name.
Int
12
4Actual number - actual number of entries. Each entry iseither a node, arc, or entity name.
Int
16
4
Total length of data
Int
20
4*3
Reserved
The following fields are repeated for each key in the key table.
In the fields listed below, N ranges from 0 to Actual number - 1.
Int
32+(N*12) 4
Key valueN - key value N
Int
36+(N*12) 4
Data typeN - data type for key N
0x12120001 = Node data
0x12120002 = Arc data
0x12120004 = Database entity nameInt
40+(N*12) 4
Data offsetN - offset for data corresponding to key N.
Note: This offset is measured relative to the Packed data
field in the linkage palette data record described below.

© 2015 Open Geospatial Consortium

306

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

Linkage Palette Data Record

Data TypeInt
Unsigned Int
Int

Offset0
2
4

Length224Description
Linkage Palette Opcode 90
Length - length of the record
Subtype2 = indicates this record is a key data record
Int
8
4
Data length
Char
12
Data
Packed data. Each packed data item is either a nodelengthdata subrecord, arc data subrecord or entity namesubrecord. Node data subrecords can be either
general nodes, formula nodes, or driver nodes. All
these subrecords are described in the following
sections.
Data length can be calculated as follows: Length - 12
The offsets listed in the following subrecords are measured from the start of the subrecord, not fromthe start of the linkage palette data record that contains this packed data.
Data Type
Int
Int
Int

Offset0
4
8

Length
4
4
4

Int
Int
Int
Int
Int
Int
Int

12
28
32
36
40
44
48

4*4
4
4
4
4
4
4

General Node Data Subrecord

Description
Identifier
Reserved
Node type0x12120003 = Header node
0x12120005 = Database entity node
Reserved
Sinks
Sources
Next node identifier
Previous node identifier
Arc source identifier
Arc sink identifier© 2015 Open Geospatial Consortium

307

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Formula Node Data Subrecord

Data Type
Int
Int
Int

Offset0
4
8

Length
4
4
4

Int
Int
Int
Int
Int
Int
Int
Int
Int
Int
Int

12
16
20
24
28
32
36
40
44
48
52

4
4
4
4
4
4
4
4
4
4
4

Description
Identifier
Reserved
Data type0x12150000 = Formula node
Reserved
Reserved
Reserved
Reserved
Sinks
Sources
Next node identifier
Previous node identifier
Arc source identifier
Arc sink identifier
Reserved© 2015 Open Geospatial Consortium

308

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Formula Node Data Subrecord (Continued)

Data Type
Int
Int
Int
Int
Int
Int
Int

Offset
56
60
64
68
72
76
80

Length
4
4
4
4
4
4
4

Data Type
Int
Int
Int

Offset0
4
8

Length
4
4
4

Int
Int
Int
Int
Int
Int
Int
Int
Int
Int
Float
Float
Float
Float
Float
Float
Float
Int
Int
Int
Int

12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
84
88
92

4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4

Description
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved

Driver Node Data Subrecord

Description
Identifier
Reserved
Node type0x12140001 = Ramp driver node
0x12140004 = Variable driver node
0x12140005 = External file driver node
Reserved
Reserved
Reserved
Reserved
Sinks
Sources
Next node identifier
Previous node identifier
Arc source identifier
Arc sink identifier
Current value
Min amplitude
Max amplitude
Wave offset
Min time
Max time
Time steps
Reserved
Reserved
Reserved
Reserved© 2015 Open Geospatial Consortium

309

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

Data Type
Int
Int
Int

Offset0
4
8

Length
4
4
4

Int
Int
Int

12
16
20

4
4
4

Description
Identifier
Reserved
Data type0x12120002 = Arc data subrecord
Reserved
Reserved
Priority© 2015 Open Geospatial Consortium

310

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Arc Data Subrecord (Continued)

Data TypeInt

Offset
24

Int

28

4

Int
Int
Int
Int
Int

32
36
40
44
48

4
4
4
4
4

Data TypeChar

Offset0

Length4

Description
Source parameter - parameter ID if source node is anode
Sink parameter - parameter ID if sink node is a node
number (0...7) for variables (x1...x8)
Only valid if sink node is a formula
Reserved
Next source identifier
Next sink identifier
Node source identifier
Node sink identifier

Entity Name Subrecord

LengthVariable

Description
ASCII string; 0 terminates© 2015 Open Geospatial Consortium

311

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

Sound Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Sound PaletteRecords.

The sound palette uses key table records to store the sound index and file name. The index
is the key value, and the file name is the data record, formatted as a null-terminated ASCII
string. The sound palette header record indicates the number of sounds associated with the
database.
Data TypeInt
Unsigned Int
Int

Offset02
4Sound Palette Header Record
Length224Description
Sound Palette Opcode 93
Length - length of the record
Subtype
1 = indicates this record is a key table headerInt
8
4
Max number - the maximum number of sounds inpaletteInt
12
4
Actual number - the actual number of sounds inpaletteInt
16
4
Total length - total length of the sound file names
contained in the sound palette key data record,
which follows this record and is described below
Int
20
4*3
Reserved
The following fields are repeated for each sound represented in the palette.
In the fields listed below, N ranges from 0 to Actual number - 1.
Int
32+(N*12) 4
Sound indexN - index of sound N in the paletteInt
36+(N+12) 4
ReservedN - reserved space for sound N in thepaletteInt
40+(N*12) 4File name offsetN - starting offset for file name ofsound N in the palette. This offset is measured
relative to the Packed file names field in the soundpalette data record described below.

© 2015 Open Geospatial Consortium

312

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Sound Palette Data Record

Data TypeInt
Unsigned
Int
Int

Offset0
2

Length22

Description
Sound Palette Opcode 93
Length - length of the record

4

4

Int
Char

8
12

4
Data length

Subtype2 = indicates this record is a key data record
Total length of all packed sound file names
Packed file names.
Use File name offsets contained in sound palette key table
header to locate individual names in this data blocks.
Data length can be calculated as follows: Length - 12

Light Source Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Light Source

Records.

These records represent entries in the light source palette. Entries are referenced by lightsource nodes using the palette index. Lights can be flagged as modeling lights, which
illuminate a scene without being stored as part of the hierarchy. A modeling light is always
positioned at the eye; its direction is stored in the palette. A light referenced by a node
obtains its position and direction from the node. In this case, the palette yaw and pitch
components are ignored.
Data TypeInt
Unsigned
Int
Int
Int
Char
Int
Float
Float
Float
Int

Offset0
2

Length
2
2

4
8
16
36
40
56
72
88

4
2*4
20
4
4*4
4*4
4*4
4

Int
Float
Float
Float
Float
Float
Float
Float
Int

92
132
136
140
144
148
152
156
160

4*10
4
4
4
4
4
4
4
4

Light Source Palette Record

Description
Light Source Palette Opcode 102
Length - length of the record
Light source index
Reserved
Light source name; 0 terminates
Reserved
Ambient component of light source (r, g, b, a) - alpha unused
Diffuse component of light source (r, g, b, a) - alpha unused
Specular component of light source (r, g, b, a) - alpha unused
Light type
0 = Infinite
1 = Local
2 = Spot
Reserved
Spot exponential drop-off term
Spot cutoff angle (in degrees)
Yaw
Pitch
Constant attenuation coefficientLinear attenuation coefficient
Quadratic attenuation coefficient
Modeling light© 2015 Open Geospatial Consortium

313

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

Int

164

0 = Light source is not active during modeling
1 = Light source is active during modelingReserved

4*19Light Point Appearance Palette Record
The light point appearance palette record defines the visual attributes of light points.

Light Point Appearance Palette Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned Int
Int
Char

2
4
8

2
4
256

Int
Int
Int
Unsigned Int
Int

264
268
270
272
276

4
2
2
4
4

Float
Float
Float

280
284
288

4
4
4

Float

292

4

Int

296

4

Int

300

4

Int

304

4

Int

308

4

Light Point Appearance Palette
Opcode 128
Length - length of the record
Reserved
Light Point Type Name
0 terminates
Appearance
Surface material code
Feature ID
Back color for bidirectional points
Display mode
0 = RASTER
1 = CALLIGRAPHIC
2 = EITHER
Intensity - scalar for front colors
Back intensity - scalar for back color
Minimum defocus - (0.0 - 1.0) for
calligraphic points
Maximum defocus - (0.0 - 1.0) for
calligraphic points
Fading mode
0 = Enable perspective fading
calculations
1 = Disable calculations
Fog Punch mode
0 = Enable fog punch throughcalculations
1 = Disable calculations
Directional mode
0 = Enable directional calculations
1 = Disable calculations
Range mode
0 = Use depth (Z) buffer calculation
1 = Use slant range calculation© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü

ü

ü
ü
























314

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

312

4

Float

316

4

Float

320

4

Float

324

4

Float

328

4

Float

332

4

Float

336

4

Float

340

4

Float
Float

344
348

4
4

Int

352

4

Float

356

4

Float

360

4

Float

364

4

Float

368

4

Float

372

4

Float

376

4

Int

380

4

Min pixel size - minimum diameterof points in pixels
Max pixel size - maximum diameterof points in pixels
Actual size - actual diameter ofpoints in database units
Transparent falloff pixel size diameter in pixels when points
become transparent
Transparent falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Transparent falloff scalar> 0 - falloff multiplier scale factor
Transparent falloff clamp - minimum
permissible falloff multiplier result
Fog scalar>= 0 - adjusts range of points forpunch threw effect.
Fog intensity
Size difference threshold - point sizetransition hint to renderer
Directionality
0 = OMNIDIRECTIONAL
1 = UNIDIRECTIONAL
2 = BIDIRECTIONAL
Horizontal lobe angle - total angle indegrees
Vertical lobe angle - total angle indegrees
Lobe roll angle - rotation of lobe
about local Y axis in degrees
Directional falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Directional ambient intensity - ofpoints viewed off axis
Significance - drop out priority for
RASCAL lights (0.0 - 1.0)
Flags (bits, from left to right)
0 = reserved
1 = No back color
TRUE = don’t use back color forbidirectional points
FALSE = use back color forbidirectional points
2 = reserved
3 = Calligraphic proximity occulting(Debunching)
4 = Reflective, non-emissive point© 2015 Open Geospatial Consortium




































315

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

Float
Float

384
388

4
4

Float

392

4

Float

396

4

Float

400

4

Float

404

4

Int
Int

408
410

2
2

5-7 = Randomize intensity
0 = never
1 = low
2 = medium
3 = high
8 = Perspective mode
9 = Flashing
10 = Rotating
11 = Rotate Counter Clockwise
Direction of rotation about local Z
axis
12 = reserved
13-14 = Quality
0 = Low
1 = Medium
2 = High
3 = Undefined
15 = Visible during day
16 = Visible during dusk
17 = Visible during night
18-31 = Spare
Visibility range (> 0.0)
Fade range ratio - percentage of
total range at which light points
start to fade (0.0 - 1.0)
Fade in duration - time it takes(seconds) light point to fade inwhen turned on
Fade out duration - time it takes(seconds) light point to fade out
when turned off
LOD range ratio - percentage of
total range at which light points
LODs are active (0.0 - 1.0)
LOD scale - size of light point LOD
polygon relative to light point
diameter
Texture pattern index, -1 if none
Reserved© 2015 Open Geospatial Consortium






























316

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Light Point Animation Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Light Point

Animation Palette Records.

The light point animation palette record defines the behavioral attributes of light points.
Data TypeInt
Unsigned Int
Int
char
Int
Float
Float
Float
Float
Int

Offset
0
2
4
8
264
268
272
276
280
292

Light Point Animation Palette Record

Length
2
2
4
256
4
4
4
4
4*3
4

Description
Light Point Animation Opcode 129
Length - length of the record
Reserved
Animation name; 0 terminates
Animation index
Animation period in seconds. Note: Rate = 1/Period
Animation phase delay in seconds - from start of period
Animation enabled period (time on) in seconds
Axis of rotation for rotating animation (i, j, k)Flags (bits, from left to right)
0 = Flashing
1 = Rotating
2 = Rotate counter clockwise
3-31 = Spare
Int
296
4
Animation type
0 = Flashing sequence
1 = Rotating
2 = Strobe
3 = Morse code
Int
300
4
Morse code timing
0 = Standard timing
1 = Farnsworth timing
Int
304
4
Word rate (for Farnsworth timing)
Int
308
4
Character rate (for Farnsworth timing)
char
312
1024
Morse code string
Int
1336
4
Number of sequences (for Flashing sequence)
The following fields are repeated for each sequence represented in the light point animation palette entry.
In the fields listed below, N ranges from 0 to Number of sequences - 1.
1340+(N*12)
Unsigned Int
4
Sequence StateN - state of sequence N
0 = On1 = Off
2 = Color change
1344+(N*12)
Float
4
Sequence DurationN - duration of sequence N in seconds
1348+(N*12)
Unsigned Int
4
Sequence ColorN - color for sequence N.
Defined if Sequence state is On or Color changeLine Style Palette Record© 2015 Open Geospatial Consortium

317

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Line Style

Palette Records.

Line style records define the outline displayed around faces in wireframe or wireframeover-solid mode. The Pattern field defines a mask to control the display of segments of theline. For example, if all the bits of the mask are set, the line is drawn as a solid line. If every
other bit is on, the line is displayed as a dashed line. The Line Width field controls the widthof the line in pixels. Line style 0 is the default. Faces are assigned line styles in the Line Style
field of the face record. One of these records appears for each line style defined in the
OpenFlight file.
Data Type
Int
Int
Int
Int
Int

Offset02468Line Style Palette Record

Length22224Description
Line Style Palette Record Opcode 97
Length of record
Line style index
Pattern mask
Line width

Texture Mapping Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider any of the
Texture Mapping Palette Records.
The texture mapping palette record defines methods and parameters used to map textures
onto geometry. One record is created for each texture mapping reference in the palette.
These records must follow the header record and precede the first push.

Texture Mapping Palette Record

Data Type
Int
Int
Int
Int
Char
Int

Offset
0
2
4
8
12
32

Length
2
2
4
4
20
4

Int
Double

36
40

4
8*16

Description
Texture Mapping Palette Opcode 112
Length - length of the record
Reserved
Texture mapping index
Texture mapping name
Texture mapping type
0 = None
1 = Put
2 = 4 Point Put
3 = Reserved
4 = Spherical Project
5 = Radial Project
6 = Reserved
Warped flag; if TRUE, 8 point warp applied
4x4 Transformation matrix (for types 1, 2, 4 & 5),
row major

The parameters for put texture mapping will appear immediately following the texture
mapping palette record if Texture mapping type is 1.

© 2015 Open Geospatial Consortium

318

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Parameters for Put Texture Mapping (Type 1)

Data TypeInt

Offset168

Length
4

Int

172

4

Double176

8*3

Double

200

8*3

Int

224

4*3

Int
DoubleDoubleDoubleDoubleDoubleDouble
Int

236
240
264
288
312
336
360
384

4
8*3
8*3
8*3
8*3
8*3
8*3
4

Int

388

4

Float
Float

392
396

4
4

Description
State of Put Texture tool
0 = Start state - no points entered
1 = One point entered
2 = Two points entered
3 = Three points entered
Active geometry point
1 = Origin point
2 = Alignment point
3 = Shear point
Lower-left corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Upper-right corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Use real world size flags for each of the put
pointsReserved
Texture origin point (x, y, z)
Texture alignment point (x, y, z)
Texture shear point (x, y, z)Geometry origin point (x, y, z)Geometry alignment point (x, y, z)Geometry shear point (x, y, z)
Active texture point
1 = Origin point
2 = Alignment point
3 = Shear point
UV display type
1 = XY
2 = UVU Repetition
V Repetition© 2015 Open Geospatial Consortium

319

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The parameters for 4 point put texture mapping will appear immediately following the texture
mapping palette record if Texture mapping type is 2

Data TypeInt

Parameters for 4 Point Put Texture Mapping (Type 2)
Offset168

Length
4

Int

172

4

Double176

8*3

Double

200

8*3

Int

224

3*4

Int
DoubleDoubleDoubleDoubleDoubleDoubleDoubleDouble
Int

236
240
264
288
312
336
360
384
408
432

4
8*3
8*3
8*3
8*3
8*3
8*3
8*3
8*3
4

Int

436

4

Float
Int
Double

440
444
448

4
4
8*16

Float
Float

576
580

4
4

Description
State of 4 Point Put Texture tool
0 = Start state - no points entered
1 = One point entered
2 = Two points entered
3 = Three points entered
4 = Four points entered
Active geometry point
1 = Origin point
2 = Alignment point
3 = Shear point
4 = Perspective point
Lower-left corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Upper-right corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Use real world size flags for each of the put
pointsReserved
Texture origin point (x, y, z)
Texture alignment point (x, y, z)
Texture shear point (x, y, z)
Texture perspective point (x, y, z)Geometry origin point (x, y, z)Geometry alignment point (x, y, z)Geometry shear point (x, y, z)Geometry perspective point (x, y, z)
Active texture point
1 = Origin point
2 = Alignment point
3 = Shear point
4 = Perspective point
UV display type
1 = XY
2 = UV
Depth scale factor
Reserved
4x4 Transformation matrix for the 4 point
projection plane, row major order
U Repetition
V Repetition© 2015 Open Geospatial Consortium

320

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The parameters for spherical project mapping will appear immediately following the
texture mapping palette record if Texture mapping type is 4.
Data Type
Float
DoubleFloat
Float

Parameters for Spherical Project Mapping (Type 4)
Offset168
172
196

Length
4
8*3
4

200

4

Description
Scale
Center of the projection sphere (x, y, z)
Scale / (maximum dimension of the mapped
geometry bounding box
Maximum dimension of the mapped geometrybounding box when mapping was created

The parameters for radial project mapping will appear immediately following the texture
map- ping palette record if Texture mapping type is 5.
Data TypeInt

Parameters for Radial Project Mapping (Type 5)
Offset168

Length
4

Int
Float
Float
Double

172
176
180
184

4
4
4
8*16

DoubleDouble

312
336

8*3
8*3

Description
Active geometry point
1 = End point 1 of cylinder center line
2 = End point 2 of cylinder center line
Reserved
Radial scale
Scale along length of cylinder
4x4 Trackplane to XY plane transformation
matrix,row major order
End point 1 of cylinder center line (x, y, z)
End point 2 of cylinder center line (x, y, z)© 2015 Open Geospatial Consortium

321

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The parameters for warped mapping will be included if the Warped flag is set in the
texture mapping palette record. This parameter block will appear immediately following
the texture mapping parameter block to which the warp applies. In the offset fields below,
X is equal to the size of the texture mapping palette record plus the size of the texture
mapping parameter block to which the warp applies.

Data TypeInt

Parameters for Warped Mapping (Warped Flag Set)
OffsetX+0

Length
4

Int

X+4

4

Int
Double

X+8
X+16

8
8*8*2

Double

X+144

8*8*2

Description
Active geometry point
0 = First warp FROM point
1 = Second warp FROM point
2 = Third warp FROM point
3 = Fourth warp FROM point
4 = Fifth warp FROM point
5 = Sixth warp FROM point
6 = Seventh warp FROM point
7 = Eighth warp FROM point
8 = First warp TO point
9 = Second warp TO point
10 = Third warp TO point
11 = Fourth warp TO point
12 = Fifth warp TO point
13 = Sixth warp TO point
14 = Seventh warp TO point
15 = Eighth warp TO point
Warp tool state
0 = Start state - no points entered
1 = One FROM point entered
2 = Two FROM point entered
3 = Three FROM point entered
4 = Four FROM point entered
5 = Five FROM point entered
6 = Six FROM point entered
7 = Seven FROM point entered
8 = All FROM point enteredReserved
FROM points transformed to XY plane by
above matrix.
8 FROM points are ordered 1, 2, ... 8. Eachpoint is (x, y)
TO points transformed to XY plane by above
matrix.
8 TO points are ordered 1, 2, ... 8. Each pointis (x, y)© 2015 Open Geospatial Consortium

322

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

Shader Palette Record
The shader palette contains descriptions of shaders used while drawing geometry. It is composed of an arbitrary number of shader palette records. The shader palette records must
follow the header record and precede the first push.

Shader Palette Record

Data Type

OffsetLengthDescription

Int

0

2

Shader Opcode 133

Unsigned
Int
Int
Int

2

2

Length - length of the record

4
8

4
4

char
char

12
1036

1024
1024

char

2060

1024

Int

3084

4

Int

3088

4

char

3092

256

char

3348

256

Shader index
Shader type
0 = Cg
1 = CgFX
2 = OpenGL Shading
Language
Shader name; 0 terminates
Vertex program file name; 0terminates(Cg Shader type specific)
Fragment program filename; 0 terminates(Cg Shader type specific)
Vertex program profile (CgShader type specific)
Fragment program profile(Cg Shader type specific)
Vertex program entry point(Cg Shader type specific)
Fragment program entry
point (Cg Shader typespecific)© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader
















323

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

Texture Files

Texture Pattern Files
OpenFlight does not have its own texture pattern format, but rather uses existingtexture formats and references patterns by file name. See “Texture Palette Record” onpage 73.
File formats currently supported include:[AT&T® image 8 format (8-bit color lookup)[AT&T image 8 template format[SGI intensity modulation (*.int)[SGI intensity modulation with alpha (*.inta)[SGI RGB (*.rgb)[SGI RGB with alpha (*.rgba)[GIF[JPEG/JFIF (*.jpg)[TIFF (*.tif)[IFF/ILBM[BMP/DIB
[PCX
[PNG
[PPM
[Sun™ Raster[Direct Draw Surface (DDS)[Targa™
[Alias™ Pix[SGI clip texture

CDB OpenFlight
Readers


ü8
ü8
ü
ü8














The format of the file is determined by the file name extension, the magic numbers
within the file, or the texture attribute file, as described in the following section.

8

The SGI format is fully supported by the CDB Specification but a single file extension used, *.rgb.
Consequently, all image formats (int, inta, rgb, and rgba) are stored in .rgb files regardless of the number ofchannels in the image.

© 2015 Open Geospatial Consortium

325

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

Texture Attribute Files
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider

texture attribute (*.attr) files.

A corresponding attribute file is created for each texture pattern, with the name of
the attribute file the same as the texture file, followed by the extension “.attr”. These
attribute files are used by the modeling software, and may not be necessary for theapplication using the database.
The attribute file contains information specifying how to parse the texture patternfile, set the texture hardware and software environment for the texture pattern, or
position the image in a database.
The format of the texture attribute file is described in this section.

Texture Attribute File Format

Data
Type
Int
Int
Int
Int
Int
Int
Int

OffsetLengthDescription

0
4
8
12
16
20
24

4
4
4
4
4
4
4

Int

28

4

Int

32

4

Number of texels in u direction
Number of texels in v direction
Real world size u direction (obsolete - not used)
Real world size v direction (obsolete - not used)
x component of up vector
y component of up vector
File format type
0 = AT&T image 8 pattern
1 = AT&T image 8 template
2 = SGI intensity modulation
3 = SGI intensity w/alpha4 = SGI RGB
5 = SGI RGB w/alphaMinification filter type
0 = Point
1 = Bilinear
2 = Mipmap (obsolete)
3 = Mipmap Point
4 = Mipmap linear
5 = Mipmap bilinear
6 = Mipmap trilinear
7 = None
8 = Bicubic
9 = Bilinear greater/equal
10 = Bilinear less/equal
11 = Bicubic greater/equal
12 = Bicubic less/equal
Magnification filter type
0 = Point© 2015 Open Geospatial Consortium

326

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

Int

36

4

Int

40

4

Int

44

4

Int
Int
Int
Int

48
52
56
60

4
4
4
4

Int

64

4

Int
DoubleDouble
Int
Int
Int

68
100
108
116
120
124

4*8
8
8
4
4
4

1 = Bilinear
2 = None
3 = Bicubic
4 = Sharpen
5 = Add Detail6 = Modulate Detail
7 = Bilinear greater/equal
8 = Bilinear less/equal
9 = Bicubic greater/equal
10 = Bicubic less/equal
Wrap method u,v - only used when either Wrapmethod u or Wrap method v is set to None
0 = Repeat
1 = Clamp
4 = Mirrored Repeat
Wrap method u
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat
Wrap method v
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat
Modified flag - for internal use only
x pivot point for rotating textures
y pivot point for rotating textures
Environment type
0 = Modulate
1 = Blend
2 = Decal
3 = Replace
4 = Add
TRUE if intensity pattern to be loaded in alpha withwhite in color
Reserved
Real world size u direction
Real world size v direction
Code for origin of imported texture
Kernel version number
Internal format type
0 = Default
1 = TX_I_12A_4
2 = TX_IA_8
3 = TX_RGB_5
4 = TX_RGBA_4
5 = TX_IA_12© 2015 Open Geospatial Consortium

327

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

Int

128

4

Int

132

4

Float
Int
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Int

136
168
172
176
180
184
188
192
196
200
204
208
212
216
220
224
228
232
236
240

4*8
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4

Int

244

4

6 = TX_RGBA_8
7 = TX_RGBA_12
8 = TX_I_16 (shadow mode only)
9 = TX_RGB_12
External format type
0 = Default
1 = TX_PACK_8
2 = TX_PACK_16
TRUE if using following 8 floats for MIPMAP
kernel8 floats for kernel of separable symmetric filter
if TRUE send:
LOD0 for TX_CONTROL_POINT
SCALE0 for TX_CONTROL_POINT
LOD1 for TX_CONTROL_POINT
SCALE1 for TX_CONTROL_POINT
LOD2 for TX_CONTROL_POINT
SCALE2 for TX_CONTROL_POINT
LOD3 for TX_CONTROL_POINT
SCALE3 for TX_CONTROL_POINT
LOD4 for TX_CONTROL_POINT
SCALE4 for TX_CONTROL_POINT
LOD5 for TX_CONTROL_POINT
SCALE5 for TX_CONTROL_POINT
LOD6 for TX_CONTROL_POINT
SCALE6 for TX_CONTROL_POINT
LOD7 for TX_CONTROL_POINT
SCALE7 for TX_CONTROL_POINT
Control Clamp
Magnification filter type for alpha0 = Point
1 = Bilinear
2 = None
3 = Bicubic
4 = Sharpen
5 = Add Detail6 = Modulate Detail
7 = Bilinear greater/equal
8 = Bilinear less/equal
9 = Bicubic greater/equal
10 = Bicubic less/equal
Magnification filter type for color
0 = Point
1 = Bilinear
2 = None
3 = Bicubic
4 = Sharpen
5 = Add Detail6 = Modulate Detail
7 = Bilinear greater/equal
8 = Bilinear less/equal
9 = Bicubic greater/equal© 2015 Open Geospatial Consortium

328

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

Float
Float
DoubleDoubleDoubleDouble
Float
Int
Int
Int
Int
Int
Int
Int
Float
Float
Float
Float
Int

248
252
284
292
300
308
316
336
340
344
348
352
356
360
364
368
372
376
380

4
4*8
8
8
8
8
4*5
4
4
4
4
4
4
4
4
4
4
4
4

Int

384

4

Int
Int
Int

388
392
396

4
4
4

Int

400

4

Int
Int
Int

404
408
412

4
4
4

Int
Int
Int
Char

416
420
424
1020

4
4
149*4
512

10 = Bicubic less/equal
Reserved
Reserved
Lambert conic projection central meridian
Lambert conic projection upper latitude
Lambert conic projection lower latitude
Reserved
Reserved
TRUE if using next 5 integers for TX_DETAIL
J argument for TX_DETAIL
K argument for TX_DETAIL
M argument for TX_DETAIL
N argument for TX_DETAIL
Scramble argument for TX_DETAILTRUE if using next 4 floats for TX_TILE
Lower-left u value for TX_TILE
Lower-left v value for TX_TILE
Upper-right u value for TX_TILE
Upper-right v value for TX_TILE
Projection
0 = Flat earth
3 = Lambert conic
4 = UTM
7 = Undefined projection
Earth model
0 = WGS84
1 = WGS72
2 = Bessel
3 = Clark 1866
4 = NAD27
Reserved
UTM zone
Image origin
0 = Lower left
1 = Upper left
Geospecific points units
0 = Degrees
1 = Meters
2 = Pixels
Reserved
Reserved
Hemisphere for geospecific points units
0 = Southern
1 = Northern
Reserved
Reserved
Reserved
Comments; 0 terminates© 2015 Open Geospatial Consortium

329

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

1538
1584
1588

13*4
4
4

Reserved
Attribute file version number
Number of geospecific control points

If the value of the Number of geospecific control points field is greater than 0, thefollowing fields are also contained in the attribute file:

Geospecific Control Point subrecord

Data Type
OffsetLengthInt
4Reserved
The following fields are repeated for each geospecific control point in the texture
attribute file.
Note: In the fields below, N ranges from 0 to Number of geospecific control points – 1.
The earth coordinates depend on the projection, earth model, and geospecific points
units.
DoubleDoubleDoubleDouble8888Texel uN - texel u of control point
Texel vN - texel v of control point
Earth coordinate xN - earth x coordinate of control point.
Earth coordinate yN - earth y coordinate of control point.

If the value of the Number of geospecific control points field is greater than 0, thefollowing fields are also contained in the attribute file:
Data
Type
Int

OffsetLength4

Number of subtextures

If the value of the Number of subtextures field is greater than 0, the following fields arerepeated for each subtexture in the texture attribute file.
In the fields below, N ranges from 0 to Number of subtextures - 1.
The Left, Bottom, Right and Top fields are all measured in texels.

Data
Type
Char
Int
Int
Int
Int

Subtexture subrecord

OffsetLength32
44
44NameN - name of subtexture N; 0 terminates
LeftN - Coordinate of left edge of subtexture N
BottomN - Coordinate of bottom edge of subtexture N
RightN - Coordinate of right edge of subtexture N
TopN - Coordinate of top edge of subtexture N© 2015 Open Geospatial Consortium

330

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

4

Road Path Files
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Road

Path Files.

A road path file contains the attributes of a road path node in ASCII format. The name of
the file is user defined. Each attribute is denoted by a keyword, a literal colon, a space,
and the value(s). Boolean values are denoted by the string literals “TRUE” and“FALSE”. For the “POINT” keyword its values consist of an XYZ coordinate and an
orientation vector, separated by spaces. The orientation vector is specified as either anormal up-vector, or in degrees of heading, pitch, and roll. The “STORE_HPR”
keyword specifies which method is used. For path nodes that define the road’s centerline
path, construction information for the correlated road section is also stored withadditional keywords. Here’s an example:

5

Road Zone Files© 2015 Open Geospatial Consortium

331

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Road

Zone Files.

Zone files are gridded posts files containing elevation and attribute data for a road.
The zone data is followed immediately by a series of:(Number of data points in x) * (Number of data points in y) elevation data points.
The elevation data points are followed immediately by a series of:(Number of data points in x) * (Number of data points in y) surface types
corresponding to each of the elevation data points above.
The elevation data points as well as the surface types begin at the lower-left corner.
Values are ordered from bottom to top, then in columns from left to right.
Data TypeInt
Int
DoubleDoubleDouble
Int
Int
Float
Float
Char

Road Zone File Format

Offset
0
4
8
32
56
64
68
72
76
80

Length
4
4
8*3
8*3
8
4
4
4
4
440

Data Type
Version - road tools format version
Reserved
Lower left corner (x, y, z)
Upper right corner (x, y, z)
Grid interval - spacing between data points
Number of data points in x
Number of data points in y
Low z elevation data point
High z elevation data point
Reserved

The following field is repeated for each data point in the road zone file.
In this field, N ranges from 0 to Number of data points - 1, where
Number of data points = Number of data points in x * Number of data points in y.
Data Type
Float

OffsetElevation Data Point subrecord

520+(N*4)

Length4

Data TypeZN - elevation value for data point N

The following field is repeated for each data point in the road zone file.
In this field, N ranges from 0 to Number of data points - 1, where
Number of data points = Number of data points in x * Number of data points in yand M is equal to Number of data points.
Data TypeChar

OffsetSurface Type subrecord

520+(M*4)+N

Length1

Data TypeSurface typeN - user defined surface type fordata point N

6 Linkage Editor Parameter IDs

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Linkage

Editor Parameter IDs.

© 2015 Open Geospatial Consortium

332

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

Vertex Node Parameters
ID
258
259
260
261
262
265
266
267
269
270
271

Description
X coordinate
Y coordinate
Z coordinate
Texture U coordinate
Texture V coordinate
Color
Hard edge flag
Freeze normal flag
Normal I component
Normal J component
Normal K component

Face Node Parameters
ID
514
515
516
518
519
520
521
522
523
525
526
527
529
530
534
535
536
537
538
539
540

Description
Color
Polygon drawing
Lighting mode
Relative priority
Draw both sides flag
Texture index
Template
InfraredTerrain flag
Material index
Feature ID
Surface material code
Draw textured faces white
IR material
Detail texture index
Transparency
Alternate color
LOD control
Line style index
Light point directional mode
Texture mapping© 2015 Open Geospatial Consortium333

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

Object Node Parameters
ID
770
771
772
773
774
775
776
777
778
779
782

Description
Relative priority
Inhibit during day flag
Inhibit during dusk flag
Inhibit during night flag
No illumination flag
Flat shading flag
Shadow flag
Transparency
Special #1
Special #2
SignificanceLOD Node Parameters
ID
1026
1027
1028
1029
1030
1031
1032
1033
1034
1036
1037

Description
Switch-in distance
Switch-out distanceSpecial #1
Special #2
Use previous range flag
Center X coordinate
Center Y coordinate
Freeze center flag
Center Z coordinate
Additive LOD’s below flag
Transition distanceGroup Node Parameters
ID
1282
1284
1286
1287
1288
1289
1290
1291

Description
Relative priority
Animation type
Bounding volume typeSpecial #1
Special #2
Replication countSignificanceLayer© 2015 Open Geospatial Consortium

334

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

DOF Node Parameters
ID
1538
1539
1540
1542
1543
1544
1546
1547
1548
1550
1551
1552
1554
1555
1556
1558
1559
1560
1562
1563
1564
1566
1567
1568
1570
1571
1572
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584

Description
Current Z
Minimum Z
Maximum Z
Current Y
Minimum Y
Maximum Y
Current X
Minimum X
Maximum X
Current pitch
Minimum pitch
Maximum pitch
Current roll
Minimum roll
Maximum rollCurrent yaw
Minimum yaw
Maximum yaw
Current Z scale
Minimum Z scale
Maximum Z scale
Current Y scale
Minimum Y scale
Maximum Y scale
Current X scale
Minimum X scale
Maximum X scale
X constrained motion flag
Y constrained motion flag
Z constrained motion flag
Pitch constrained motion flag
Roll constrained motion flag
Yaw constrained motion flag
X scale constrained motion flag
Y scale constrained motion flag
Z scale constrained motion flag
Repeating texture flag
Membrane mode flag

© 2015 Open Geospatial Consortium

335

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

Sound Node Parameters
ID
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1812

Description
Amplitude
Pitch bend
Priority
Falloff
Width
Doppler
Absorption
Delay
Directivity
X coordinate
Y coordinate
Z coordinate
Direction vector I component
Direction vector J component
Direction vector K component
Active flag

Switch Node Parameters
ID
2050

Description
Current mask index© 2015 Open Geospatial Consortium

336

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

Text Node Parameters
ID
2307
2308
2310
2311
2312
2315
2316
2317
2318
2325
2326
2327
2329
2330
2331
2332
2333
2334

Description
Text type
Draw type
Color
Alternate color
Material index
Integer value minimum
Integer value maximum
Float value minimum
Float value maximum
Current integer value
Current float value
Decimal places for float value
Line style index
Justification type
Vertical flag
Bold flag
Italic flag
Underline flag

Light Source Node Parameters
ID
2819
2820
2821
2822
2823
2824
2825

Description
Enabled flag
Global flag
X coordinate
Y coordinate
Z coordinate
Yaw
Pitch

Clip Node Parameters
ID
3074
3075
3076
3077
3078

Description
Plane 0 enable
Plane 1 enable
Plane 2 enable
Plane 3 enable
Plane 4 enable© 2015 Open Geospatial Consortium

337

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

7

OpenFlight Opcodes

Valid Opcodes
OpcodeRecord TypeFor more information, see…

1
2
4
5
10

HeaderGroup
ObjectFace
Push Level

11

Pop Level

14

Degree of Freedom

19

Push Subface

20

Pop Subface

21

Push Extension

22

Pop Extension

23

Continuation

31

Comment

32

Color Palette

33
49
50
52

Long ID
Matrix
VectorMultitexture

53
55

UV ListBinary Separating Plane

60
61

Replicate
Instance Reference

62

Instance Definition

63

External Reference“Header Record” on page 19“Group Record” on page 22“Object Record” on page 25“Face Record” on page 26“Push Level Record” onpage 17“Pop Level Record” onpage 17“Degree of Freedom Record”
on page 37“Push Subface Record” onpage 17“Pop Subface Record” onpage 17“Push Extension Record” onpage 17“Pop Extension Record” onpage 17“Continuation Record” onpage 65“Comment Record” onpage 53“Color Palette Record” onpage 70“Long ID Record” on page 53“Matrix Record” on page 59“Vector Record” on page 61“Multitexture Record” onpage 54“UV List Record” on page 55“Binary Separating Plane
Record” on page 40“Replicate Record” on page 57“Instance Reference Record”
on page 19“Instance Definition Record”
on page 19“External Reference Record”© 2015 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü
ü
ü
ü
ü
ü



ü
ü
ü
ü
ü

ü
ü
ü
ü
ü
ü
ü

339

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

Texture Palette

67

Vertex Palette

68

Vertex with Color

69

72

Vertex with Color andNormalVertex with Color,
Normal and UVVertex with Color and
UV
Vertex List

73

Level of Detail74

Bounding Box

76

Rotate About Edge

78
79
80

Translate
Scale
Rotate About Point

81

84
85

Rotate and/or Scale to
Point
Put
Eyepoint and Trackplane
PaletteMesh
Local Vertex Pool86

Mesh Primitive

87

Road Segment

88

Road Zone

89

Morph Vertex List

90

Linkage Palette

91
92

Sound
Road Path

93

Sound Palette

70
71

82
83

on page 41“Texture Palette Record” onpage 73“Vertex Palette Record” onpage 67“Vertex with Color Record”
on page 68“Vertex with Color andNormal Record” on page 68“Vertex with Color, Normal
and UV Record” on page 69“Vertex with Color and UVRecord” on page 69“Vertex List Record” onpage 39“Level of Detail Record” onpage 41“Bounding Box Record” onpage 62“Rotate About Edge Record”
on page 59“Translate Record” on page 59“Scale Record” on page 59“Rotate About Point Record”
on page 60“Rotate and/or Scale to Point
Record” on page 60“Put Record” on page 60“Eyepoint and Trackplane
Palette Record” on page 73“Mesh Record” on page 29“Local Vertex Pool Record”
on page 30“Mesh Primitive Record” onpage 32“Road Segment Record” onpage 44“Road Zone Record” onpage 58“Morph Vertex List Record”
on page 39“Linkage Palette Record” onpage 77“Sound Record” on page 43“Road Path Record” onpage 46“Sound Palette Record” onpage 80© 2015 Open Geospatial Consortium

ü
ü
ü
ü
ü
ü
ü
ü
ü







ü
ü
ü


ü





340

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

General Matrix

95
96
97

Text
SwitchLine Style Palette

98

Clip Region

100

Extension

101

Light Source

102

Light Source Palette

103
104
105

Reserved
Reserved
Bounding Sphere

106

Bounding Cylinder

107

Bounding Convex Hull

108

Bounding Volume
CenterBounding Volume
Orientation

109“General Matrix Record” onpage 60“Text Record” on page 47“Switch Record” on page 49“Line Style Palette Record” onpage 85“Clip Region Record” onpage 47“Extension Record” onpage 51“Light Source Record” onpage 44“Light Source Palette Record”
on page 81

110
111

Reserved
Light Point112

Texture Mapping Palette

113

Material Palette

114

Name Table

115
116

Continuously Adaptive
Terrain (CAT)CAT Data

117
118
119

Reserved
Reserved
Bounding Histogram

120
121
122

Reserved
Reserved
Push Attribute“Bounding Sphere Record” onpage 62“Bounding Cylinder Record”
on page 62“Bounding Convex Hull
Record” on page 62“Bounding Volume Center
Record” on page 63“Bounding Volume
Orientation Record” onpage 63“Light Point Record” onpage 34“Texture Mapping PaletteRecord” on page 86“Material Palette Record” onpage 71“Name Table Record” onpage 71“CAT Record” on page 50“CAT Data Record” onpage 63“Bounding Histogram Record”
on page 62“Push Attribute Record” on© 2015 Open Geospatial Consortium



ü







ü
ü
ü
ü
ü



ü
ü









341

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
page 18“Pop Attribute Record” onpage 18

123

Pop Attribute

124
125
126
127

Reserved
Reserved
Curve
Road Construction

128

130

Light Point Appearance
PaletteLight Point Animation
PaletteIndexed Light Point

131

Light Point System

132

Indexed String

133

Shader Palette

129“Curve Record” on page 51“Road Construction Record”
on page 45“Light Point Appearance
Palette Record” on page 82“Light Point Animation PaletteRecord” on page 85“Indexed Light Point Record”
on page 34“Light Point System Record”
on page 37“Indexed String Record” onpage 53“Shader Palette Record” onpage 91© 2015 Open Geospatial Consortium






ü

ü

ü


342

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

Obsolete Opcodes
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider thefollowing obsolete OpenFlight opcodes.
Opcode
3
6
7
8
9
12
13
16
17
40
41
42
43
44
45
46
47
48
51
65
66
77

Record Type
Level of Detail (single precision floating point, replaced by Opcode 73)
Vertex with ID (scaled integer coordinates, replaced by Opcodes 68-71)
Short Vertex w/o ID (scaled integer coordinates, replaced by Opcodes 68-71)
Vertex with Color (scaled integer coordinates, replaced by Opcodes 68-71)
Vertex with Color and Normal (scaled integer coordinates, replaced by Opcodes 6871)
Translate (replaced by Opcode 78)
Degree of Freedom (scaled integer coordinates, replaced by Opcode 14)
Instance Reference (replaced by Opcode 61)
Instance Definition (replaced by Opcode 62)
Translate (replaced by Opcode 78)
Rotate about Point (replaced by Opcode 80)
Rotate about Edge (replaced by Opcode 76)
Scale (replaced by Opcode 79)
Translate (replaced by Opcode 78)
Scale nonuniform (replaced by Opcode 79)
Rotate about Point (replaced by Opcode 80)
Rotate and/or Scale to Point (replaced by Opcode 81)
Put (replaced by Opcode 82)
Bounding Box (replaced by Opcode 74)
Eyepoint Palette (only eyepoints, replaced by Opcode 83)
Material Palette (fixed size 64 entries, replaced by Opcode 80)
Scale (replaced by Opcode 79)© 2015 Open Geospatial Consortium

343

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

A Summary of Changes Version 15.7
CDB OpenFlight Readers: This section is not applicable to CDB-compliant OpenFlight
readers. The first version of the CDB standard is based on OpenFlight v16.0.

Overview
This section describes the changes in the OpenFlight Scene Description between
versions 15.6 and 15.7. OpenFlight version 15.7 coincides with MultiGen Creator
versions 2.4 through 2.5.1 and the OpenFlight API versions 2.4 through 2.5.1. Thechanges made for this version are:[”Continuation Record “ on this page.
[”Header Record” on page 114[”Mesh Record” on page 115[”Local Vertex Pool Record” on page 116[”Mesh Primitive Record” on page 118[”Multitexture Record” on page 120[”UV List Record” on page 122[”Texture Attribute File” on page 123

Format Changes
Continuation Record
All OpenFlight records begin with a 4 byte sequence. The first two bytes identify therecord (opcode) and the second two bytes specify the length of the record. Given thisregular record structure, the length of all OpenFlight records is limited to thelargest value that can be encoded with 2 bytes or 16 bits (65535). In most cases, thismaximum size is sufficient but there are cases where it is not. For fixed size records,
this is not a problem. For variable size records, this limitation is being addressedwith this version.
A new record, called the continuation record is introduced in this version toaccommodate variable size records in the OpenFlight Scene Description. The
continuation record is used to “continue” a record in the OpenFlight Scene
Description file stream. It would appear in the stream immediately following therecord that it “continues” (the record that is being continued will be referred to as
the “original” record). The data contained in the continuation record is defined by
the original record and is assumed to be directly appended onto the content of theoriginal record.

© 2015 Open Geospatial Consortium

345

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Note: Multiple continuation records may follow a record, in which case all continuation
records would be appended (in sequence) to the original record.

Data Type
Unsigned Int
Unsigned Int
VariesOffset0
2
4

Continuation Record
New record for OpenFlight 15.7
Length2
2
Length-4

Description
Continuation Record Opcode 23
Length - length of the record
Depends on the original record. The contentsof this field are to be appended directly to theend of the original record contents (before theoriginal record contents are parsed)

Header Record
New attributes have been appended to the end of the existing header record (see“Header Record” on page 19). The following fields were added at the specified offsets
in the header record.

Header Record changes for OpenFlight15.7
New Fields

Data TypeDoubleOffset284

Length
8

Double292

8

Unsigned Int
Unsigned Int

300
302

2
2

Description
Delta z to place database (used in conjunction
with existing Delta x and Delta y values)
Radius (distance from database origin to
farthest corner)
Next Mesh node ID number
Reserved

Mesh Nodes
A mesh node defines a set of geometric primitives that share attributes and vertices.
In previous versions of OpenFlight, the fundamental geometric construct was thepolygon. Each polygon has a unique set of attributes and vertices. Meshes are used
to represent “sets” of related polygons, each sharing common attributes andvertices. Using a mesh, related polygons can be represented in a much morecompact format. Each mesh will share one set of “polygon” attributes (color,material, texture, etc.), a common “vertex pool” and one or more geometricprimitives that use the shared attributes and vertices. Using a mesh you canrepresent triangle strips, triangle fans, quadrilateral strips and indexed face sets.
A mesh node is defined by three distinct record types:[Mesh Record - defines the “polygon” attributes associated to all geometric primitives ofthe mesh.

© 2015 Open Geospatial Consortium

346

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
[Local Vertex Pool Record - defines the set of vertices that are referenced by thegeometric primitives of the mesh.
[Mesh Primitive Record - defines a geometric primitive (triangle-strip, triangle-fan,quadrilateral-strip or indexed face set) for the mesh.
A mesh node consists of one mesh record, one local vertex pool record, and one ormore mesh primitive records. The mesh primitive records are delimited by pushand pop control records as shown in the following example:
MESH
LOCAL VERTEX POOL
PUSH MESHPRIMITIVE
MESH PRIMITIVE...
MESH PRIMITIVEPOP

Mesh Record
The mesh record is the primary record of a mesh node and defines the common“face-like” attributes associated to all geometric primitives of the mesh. These
attributes are identical to those of the face record. See “Face Record” on page 26.

Mesh Record
New record for OpenFlight 15.7

Data TypeInt
Unsigned Int
Char
Int
Int
Int

Offset
0
2
4
12
16
18

Length
2
2
8
4
2
1

Int

19

1

Unsigned Int
Unsigned Int
Int

20
22
24

2
2
1

Description
Mesh Opcode 84
Length - length of the record
7 char ASCII ID; 0 terminates
IR color code
Relative priority
Draw type
0 = Draw solid with backface culling
1 = Draw solid, no backface culling
2 = Draw wireframe
3 = Draw wireframe and close
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light
Texture white = if TRUE, draw textured face
white
Color name index
Alternate color name index
Reserved© 2015 Open Geospatial Consortium

347

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Mesh Record
New record for OpenFlight 15.7 (Continued)

Data TypeInt

Offset25

Length
1

Int
Int
Int
Int
Int
Int
Unsigned Int

26
28
30
32
34
36
40

2
2
2
2
2
4
2

Unsigned Int
Unsigned Int
Int

42
43
44

1
1
4

Unsigned Int

48

1

Char
Unsigned Int
Unsigned Int
Int
Int
Unsigned Int
Unsigned Int
Int

49
56
60
64
66
68
72
76

7
4
4
2
2
4
4
4

Description
Template (billboard)
0 = Fixed, no alpha blending
1 = Fixed, alpha blending
2 = Axial rotate with alpha blending
4 = Point rotate with alpha blending
Detail texture pattern index, -1 if none
Texture pattern index, -1 if none
Material index, -1 if none
Surface material code (for DFAD)
Feature ID (for DFAD)
IR material code
Transparency
0 = Opaque65535 = Totally clear
LOD generation control
Line style index
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6-31 = Spare
Light mode
0 = Use mesh color, not illuminated
1 = Use vertex colors, not illuminated
2 = Use mesh color and vertex normals
3 = Use vertex colors and vertex normals
Reserved
Packed color, primary (a, b, g, r)
Packed color, alternate (a, b, g, r)
Texture mapping index
Reserved
Primary color index
Alternate color index
Reserved

Local Vertex Pool Record
This record defines a set of vertices that is referenced by the geometry (primitives)of the mesh.

© 2015 Open Geospatial Consortium

348

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

Currently the Local Vertex Pool is used exclusively in the context of mesh nodes,
but it is designed in a general way so that it may appear in other contexts in futureversions of the OpenFlight Scene Description.

Data TypeInt
Unsigned
Int

Offset0
2

Length2
2

Unsigned
Int
Unsigned
Int

4

4

8

4

Local Vertex Pool Record
New record for OpenFlight 15.7

Description
Local Vertex Pool Opcode 85
Length - length of the record
Note: Since the length of this record is represented by an unsigned
short, the maximum length of the vertex pool is 216- 1 (or 65535
bytes). If the entire vertex pool cannot fit into this size, one or more
continuation records will follow. (See “Continuation Record” onpage 65.)
Number of vertices - number of vertices in the local vertex pool
Attribute mask - Bit mask indicating what kind of vertex information is specified for each vertex in the local vertex pool. Bits areordered from left to right as follows:Bit #Description0
Has Position - if set, data for each vertex in will include x,y, and z coordinates (3 doubles)1
Has Color Index - if set, data for each vertex will include acolor value that is a color table index (1 int)
2
Has RGB Color - if set, data for each vertex will include acolor value that is a packed RGB color (1 int)
Note: Bits 1and 2 are mutually exclusive - a vertex can have either
color index or RGB color value or neither, but not both.
3
Has Normal - if set, data for each vertex will include a
normal (3 floats)
4
Has Base UV - if set, data for each vertex will include uv
texture coordinates for the base texture (2 floats)
5
Has UV Layer 1 - if set, data for each vertex will include
uv texture coordinates for layer 1 (2 floats)
6
Has UV Layer 2 - if set, data for each vertex will include
uv texture coordinates for layer 2 (2 floats)
7
Has UV Layer 3 - if set, data for each vertex will include
uv texture coordinates for layer 3 (2 floats)
8
Has UV Layer 4 - if set, data for each vertex will include
uv texture coordinates for layer 4 (2 floats)
9
Has UV Layer 5 - if set, data for each vertex will include
uv texture coordinates for layer 5 (2 floats)
10
Has UV Layer 6 - if set, data for each vertex will include
uv texture coordinates for layer 6 (2 floats)
11
Has UV Layer 7 - if set, data for each vertex will include
uv texture coordinates for layer 7 (2 floats)
12-31 Spare© 2015 Open Geospatial Consortium

349

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Local Vertex Pool Record
New record for OpenFlight 15.7 (Continued)

Then beginning at offset 12, the following fields are repeated for each vertex in the local
vertex pool, depending on the bits set in the Attribute mask field above:
In the fields listed below, N ranges from 0 to Number of vertices - 1.
DoubleVaries 8*3
CoordinateN - Coordinate of vertex N (x, y, z) - present if
Attribute mask includes Has Position.
Unsigned
Varies 4
colorN - Color for vertex N - present if Attribute maskIntincludes Has Color Index or Has RGB Color.
If Has Color Index, specifies color table index.
If Has RGB Color, 4 bytes specify (a, b, g, r) values (alphaignored).
Float
Varies 4*3
normalN - Normal for vertex N (i, j, k) - present if Attributemask includes Has Normal.
Float
Varies 4*2
uvBaseN - Texture coordinates (u, v) for base texture layerof vertex N - present if Attribute mask includes Has Base
UV.
Float
Varies 4*2
uv1N - Texture coordinates (u, v) for layer 1 of vertex N present if Attribute mask includes Has UV Layer 1.
Float
Varies 4*2
uv2N - Texture coordinates (u, v) for layer 2 of vertex N present if Attribute mask includes Has UV Layer 2.
Float
Varies 4*2
uv3N - Texture coordinates (u, v) for layer 3 of vertex N present if Attribute mask includes Has UV Layer 3.
Float
Varies 4*2
uv4N - Texture coordinates (u, v) for layer 4 of vertex N present if Attribute mask includes Has UV Layer 4.
Float
Varies 4*2
uv5N - Texture coordinates (u, v) for layer 5 of vertex N present if Attribute mask includes Has UV Layer 5.
Float
Varies 4*2
uv6N - Texture coordinates (u, v) for layer 6 of vertex N present if Attribute mask includes Has UV Layer 6.
Float
Varies 4*2
uv7N - Texture coordinates (u, v) for layer 7 of vertex N present if Attribute mask includes Has UV Layer 7.
Mesh Primitive Record
This record defines a geometric primitive (triangle strip, triangle fan, quadrilateral
strip, or indexed polygon) for a mesh.

© 2015 Open Geospatial Consortium

350

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

Data TypeInt
Unsigned Int
Int

Offset0
2
4

Mesh Primitive Record
New record for OpenFlight 15.7
Length222

Description
Mesh Primitive Opcode 86
Length - length of the record
Primitive Type - specifies how the verticesof the primitive are interpreted
1 = Triangle Strip
2 = Triangle Fan
3 = Quadrilateral Strip
4 = Indexed Polygon
Unsigned Int
62
Index Size - specifies the length (in bytes) ofeach of the vertex indices that follow - will
be either 1, 2, or 4
Unsigned Int
84
Vertex Count - number of vertices in thisprimitive.
The following field is repeated for each vertex referenced by the mesh primitive. Thesevertices are interpreted according to Primitive Type. In the field below, N ranges from 0
to Vertex Count - 1.
12+(N*Index Size)
Int
Index
IndexN - Index of vertex N of the meshSizeprimitive.
Each mesh primitive is represented using the Mesh Primitive record above. The
following descriptions explain how the vertices of each primitive type are interpreted asgeometry:[Triangle Strip - This mesh primitive defines a connected group of triangles in thecontext of the enclosing mesh. Each triangle shares the “polygon” attributes defined by
the enclosing mesh. This primitive contains a sequence of indices that reference vertices
from the local vertex pool. One triangle is defined for each vertex presented after the firsttwo vertices. For odd n, vertices n, n+1, and n+2 define triangle n. For even n, vertices
n+1, n, and n+2 define triangle n. The first triangle is n=1. The first vertex in the vertex
pool is n=1. N vertices represent N-2 triangles.
[Triangle Fan - Like the Triangle Strip, this mesh primitive also defines a connectedgroup of triangles in the context of the enclosing mesh. Each triangle shares the“polygon” attributes defined by the enclosing mesh. This primitive contains a sequenceof indices that reference vertices from the local vertex pool. One triangle is defined foreach vertex presented after the first two vertices. Vertices 1, n+1, and n+2 define triangle
n. The first triangle is n=1. The first vertex in the vertex pool is n=1. N vertices represent
N-2 triangles.
[Quadrilateral Strip - This mesh primitive defines a connected group of quadrilaterals
in the context of the enclosing mesh. Each quadrilateral shares the “polygon” attributes
defined by the enclosing mesh. This primitive contains a sequence of indices thatreference vertices from the local vertex pool. One quadrilateral is defined for each pair ofvertices presented after the first pair. Vertices 2n-1, 2n, 2n+2, and 2n+1 define
quadrilateral n. The first quadrilateral is n=1. The first vertex in the vertex pool is n=1. N
vertices represent (N/2)-1 quadrilaterals.
[Indexed Polygon -This mesh primitive defines a single polygon in the context of theenclosing mesh. This primitive is similar to the other mesh primitives in that it also shares© 2015 Open Geospatial Consortium

351

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
the polygon attributes of the enclosing mesh. It is different from the other mesh primitive
types in that while triangle strips/fans and quadrilateral strips describe a set of connected
triangles/quadrilaterals, the indexed polygon defines a single polygon. This primitive
contains a sequence of indices that reference vertices from the local vertex pool. One
polygon is defined by the sequence of vertices in this record. N vertices represent 1 Nsided closed polygon or 1 (N-1)-sided unclosed polygon.
Multitexture
OpenFlight supports 8 textures per polygon or mesh as well as 8 uv's per vertex.
The current texture information stored on the polygon is referred to as “the basetexture” or “texture layer 0”. Each additional texture is referred to as “texture layer
N”. Therefore, to support 8 textures per polygon, a base texture is required as well
as 7 additional texture layers. The additional texture layers for each polygon, mesh,and vertex will be represented in ancillary records at the Face, Mesh, and Vertex
primary node levels as shown in the following example:
FACE
MULTITEXTURE
PUSH
VERTEX LISTUV LISTPOP

The records that are used to represent multitexture in the OpenFlight file aredescribed in the following sections.
Multitexture Record
The multitexture record is an ancillary record of face and mesh nodes. It specifies
the texture layer information for the face or mesh.

© 2015 Open Geospatial Consortium

352

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

Data Type
Unsigned Int
Unsigned Int
Int

Offset02
4Multitexture Record
New record for OpenFlight 15.7

Length224Description
Multitexture Opcode 52
Length - length of the record
Attribute mask - Bit mask indicating what kind of
multitexture information is present in this record. Bits
are ordered from left to right as follows:
Bit # Description0
Has Layer 1 - if this bit is set, multitexture
information for texture layer 1 is present.
1
Has Layer 2 - if this bit is set, multitexture
information for texture layer 2 is present.
2
Has Layer 3 - if this bit is set, multitexture
information for texture layer 3 is present.
3
Has Layer 4 - if this bit is set, multitexture
information for texture layer 4 is present.
4
Has Layer 5 - if this bit is set, multitexture
information for texture layer 5 is present.
5
Has Layer 6 - if this bit is set, multitexture
information for texture layer 6 is present.
6
Has Layer 7 - if this bit is set, multitexture
information for texture layer 7 is present.
7-31 Spare
The following fields are repeated for each multitexture layer that is specified as present by thebits set in the Attribute mask field above. This mechanism allows for “sparse” multitexture layer
information to be present and does not require that the information present be contiguous.
Unsigned Int Varies
2
textureN - Texture index for texture layer N
Unsigned Int Varies
2
effectN - Multitexture effect for texture layer N
0 = Texture environment
1 = Bump map
2-100 = Reserved by MultiGen-Paradigm>100 = user (runtime) defined
Unsigned Int Varies
2
mappingN - Texture mapping index for texture layer N
Unsigned Int Varies
2
dataN - Texture data for layer N. This is user defined.
For example, it may be used as a blend percentage orcolor or any other data needed by the runtime todescribe texture layer N© 2015 Open Geospatial Consortium

353

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

UV List Record
The uv list record is an ancillary record of vertex nodes. This record (if present)
always follows the vertex list or morph vertex list record and contains texture layer
information for the vertices represented in the vertex list record it follows.

Data Type
Unsigned Int
Unsigned Int
Int

Offset0
2
4

UV List Record
New record for OpenFlight 15.7

Length224Description
UV List Opcode 53
Length - length of the record
Attribute mask - Bit mask indicating what kind of
multitexture information is present in this record. Bits
are ordered from left to right as follows:Bit #Description0
Has Layer 1 - if set, uvs for layer 1 are present
1
Has Layer 2 - if set, uvs for layer 2 are present
2
Has Layer 3 - if set, uvs for layer 3 are present
3
Has Layer 4 - if set, uvs for layer 4 are present
4
Has Layer 5 - if set, uvs for layer 5 are present
5
Has Layer 6 - if set, uvs for layer 6 are present
6
Has Layer 7 - if set, uvs for layer 7 are present
7-31 Spare

The following fields are repeated for each vertex contained in the corresponding vertex
list or morph vertex list record.
If this uv list record follows a vertex list record, the following fields are repeated for eachlayer present (as specified by the bits set in the Attribute mask field).
Data Type
Float
Float

Offset4
4

Descriptionui, N - Texture U for vertex i, layer Nvi, N - Texture V for vertex i, layer N

If this uv list record follows a morph vertex list record, the following fields are repeatedfor each layer present (as specified by the bits set in the Attribute mask field).
Data Type
Float
Float
Float
Float

Offset44
4
4Description
u0i, N - Texture U for the 0% vertex i, layer N
v0i, N - Texture V for the 0% vertex i, layer N
u100i, N - Texture U for the 100% vertex i, layer N
v100i, N - Texture V for the 100% vertex i, layer N© 2015 Open Geospatial Consortium

354

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

Texture Attribute File
Subtexture
Subtexture definitions have been added to the end of the Texture Attribute File (see“Texture Attribute Files” on page 93). After all the geospecific control points arelisted, the following subtexture information now appears:

Texture Attribute File Format changes for OpenFlight 15.7
New Fields

Data TypeInt

Length4

Description
Number of subtextures

If the value of the Number of subtextures field is greater than 0-, the following fields arerepeated for each subtexture in the texture attribute file.
The Left, Bottom, Right and Top fields are all measured in texels.
Data Type
Char
Int
Int
Int
Int

Length32
4444Description
NameN - name of subtexture N; 0 terminates
LeftN - Coordinate of left edge of subtexture N
BottomN - Coordinate of bottom edge of subtexture N
RightN - Coordinate of right edge of subtexture N
TopN - Coordinate of top edge of subtexture N© 2015 Open Geospatial Consortium

355

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

B Summary of Changes Version 15.8
Overview
This section describes the changes in the OpenFlight Scene Description between
versions 15.7 and 15.8 as well as the errors contained in previous versions of thisdocument that have been corrected in this version.
OpenFlight version 15.8 coincides with MultiGen Creator version 2.6 and the
OpenFlight API version 2.6. The changes made for this version are:
[
[
[
[
[
[
[
[
[
[
[
[
[
[

“Header Record” on page 127“Group Record” on page 128“Level of Detail Record” on page 129“External Reference Record” on page 130“Indexed String Record” on page 130 (for Switch nodes)“Face Record” on page 131“Mesh Record” on page 131“Local Vertex Pool Record” on page 132“Vertex Palette Records” on page 133“Light Point Appearance Palette Record” on page 136“Light Point Animation Record” on page 139“Indexed Light Point Record” on page 140“Light Point System Record” on page 140“Texture Mapping Palette Record” on page 141

Also new in this version of the document is the addition of the “offset” column in therecord format tables.

Document Corrections
The errors corrected in this version of the document are described in the sections
that follow.

© 2015 Open Geospatial Consortium

356

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

Text Record
The Reserved field, previously omitted in prior versions of this document, has been
documented in the specification for OpenFlight 15.8. The offsets of fields following
this field have been adjusted accordingly.

Text Record error corrected in OpenFlight 15.8 specification
Reserved field (documented)

Data TypeInt

Offset16

Length4

Description
Reserved

The Draw bold field, previously omitted in prior versions of this document, has been
documented in the specification for OpenFlight 15.8. The offsets of fields following thisfield have been adjusted accordingly.

Text Record error corrected in OpenFlight 15.8 specification
Draw bold field (documented)

Data TypeInt

Offset304

Length4

Description
Draw bold

For a complete description of the text record, see “Text record” on page 47.
CAT Record
The Relative priority field, included erroneously in the previous version of thisdocument, has been removed from the specification for OpenFlight 15.8. The offsetsof fields following this field have been adjusted accordingly.

CAT Record error corrected in OpenFlight 15.8 specification
Relative priority field (removed)

Data TypeInt

Offset20

Length2

Description
Relative priority

The Feature ID field, included erroneously in the previous version of this document,
has been removed from the specification for OpenFlight 15.8. The offsets of fields
following this field have been adjusted accordingly.

CAT Record error corrected in OpenFlight 15.8 specification
Feature ID field (removed)

Data TypeInt

Offset38

Length2

Description
Relative priority© 2015 Open Geospatial Consortium

357

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The Reserved field, previously omitted in prior version of this document, has been
documented in the specification for OpenFlight 15.8. The offsets of fields following
this field have been adjusted accordingly.

CAT Record error corrected in OpenFlight 15.8 specification
Reserved field (documented)

Data TypeInt

Offset60

Length4

Description
Reserved

Format Changes
Header Record
The header record has been modified to include additional projection attributes.
New attributes have been appended to the end of the existing header record andsome of the existing fields have new values possible.
The following fields were added to the end (at the specified offsets) of the header
record.

Header Record changes for OpenFlight15.8
New Fields

Data Type
Unsigned Int
Int
DoubleOffset302
304
308

Length2
48

Double316

8

Description
Next Light Point System ID number
Reserved
Earth major axis (for user defined ellipsoid) inmetersEarth minor axis (for user defined ellipsoid) inmetersThe Projection type field has been changed to include two new possible values,
Geocentric and Geodetic as shown here. New values are shown in bold font:

Data TypeInt

Header Record changes for OpenFlight15.8
Projection type field

Offset92

Length4

Description
Projection type
0 = Flat earth
1 = Trapezoidal
2 = Round earth
3 = Lambert
4 = UTM
5 = Geocentric
6 = Geodetic© 2015 Open Geospatial Consortium

358

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The Earth ellipsoid model field has been changed to include one new possible value,
User defined ellipsoid as shown here. This new value is shown in bold font.

Data TypeInt

Header Record changes for OpenFlight15.8
Earth ellipsoid field

Offset268

Length4

Description
Earth ellipsoid model
0 = WGS 1984
1 = WGS 1972
2 = Bessel
3 = Clarke 1866
4 = NAD 1927
5 = User defined ellipsoid

A field, previously labeled “Reserved” in prior versions of this document, has been
described. It is the UTM zone for UTM projections and is shown here.

Data TypeInt

Header Record changes for OpenFlight15.8
UTM zone field

Offset276

Length2

Description
UTM zone (for UTM projections - negativevalue means Southern hemisphere)

For a complete description of the header record, see “Header Record” on page 22.
Group Record
The group record has been modified to include additional animation attributes. New
attributes have been appended to the end of the existing group record and some ofthe existing fields have new values possible.
The following fields were added to the end (at the specified offsets) of the group
record.

Data Type
Int
Float
Float

Group Record changes for OpenFlight15.8
New Fields

Offset32
36
40

Length444Description
Loop countLoop duration in seconds
Last frame duration in seconds© 2015 Open Geospatial Consortium

359

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The Flags field has been changed to include a new bit which can be used to specify
backwards animations as shown here. The new bit is shown in bold font.

Data TypeInt

Group Record changes for OpenFlight15.8
Flags field

Offset16

Length4

Description
Flags (bits, from left to right)
0 = Reserved
1 = Forward animation
2 = Swing animation
3 = Bounding box follows
4 = Freeze bounding box
5 = Default parent
6 = Backward animation
7-31 = Spare

For a complete description of the group record, see “Group Record” on page 22.
Level of Detail Record
The level of detail record has been modified to include an additional attribute,Significant size. This new value helps an application to calculate switch ranges forthe geometry more effectively for different display settings (field of view, screen size
and resolution).
The following field was added to the end (at the specified offset) of the level of detailrecord.

Data TypeDoubleLOD Record changes for OpenFlight15.8
New Field

Offset72

Length8

Description
Significant size

For a complete description of the level of detail record, see “Level of Detail Record” onpage 41.

© 2015 Open Geospatial Consortium

360

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

External Reference Record
The Flags field of the external reference record has been modified to include a new
bit, Light point palette override, which is used to specify that the light point
appearance and animation palettes override those contained in the master file. The
new bit is shown in bold font.

Data TypeInt

External Reference Record changes for OpenFlight15.8
Flags field
Offset208

Length4

Description
Flags (bits, from left to right)
0 = Color palette override
1 = Material palette override
2 = Texture and texture mapping paletteoverride
3 = Line style palette override
4 = Sound palette override
5 = Light source palette override
6 = Light point palette override
7-31 = Spare

For a complete description of the external reference record, see “External Reference
Record” on page 41.
Indexed String Record
Switch nodes now allow individual masks to be named. These names are stored in a
new ancillary record called the Indexed String record. While these new ancillary
records are currently only applicable to Switch records, they are not limited toSwitch records and may be useful in future versions of OpenFlight in other contexts.
The new Indexed String Record is an ancillary record that contains an integer index
followed by a variable length character string. In this way, arbitrary strings can beassociated to indices in a general way.
With respect to Switch mask names, the index specifies the mask number for which
the string specifies a name. Mask numbers start at 0. Not all masks are required tohave names.

Data TypeInt
Unsigned Int
Unsigned Int
Char

Offset02
4
8

Indexed String Record
New record for OpenFlight 15.8
Length2
2
2
Length - 8

Description
Indexed string Opcode 132
Length - length of the record
Index
ASCII string; 0 terminates

For a completed description of the indexed string record, see “Indexed String Record” onpage 53.

© 2015 Open Geospatial Consortium

361

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Face Record
The Flags field of the face record has been modified to include a new bit, Roofline,
which is used to specify that a face is part of a building’s roof as viewed from above.
The new specification of the Flags field is shown here. The new bit is shown in bold
font.

Data TypeInt

Face Record changes for OpenFlight15.8
Flags field

Offset44

Length4

Description
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = SpareMesh Record
Similar to the Face record described above, the Flags field of the mesh record has
been modified to include a new bit, Roofline, which is used to specify that a mesh ispart of a building’s roof as viewed from above. The new specification of the Flags
field is shown here. The new bit is shown in bold font.

Data TypeInt

Mesh Record changes for OpenFlight15.8
Flags field

Offset44

Length4

Description
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = Spare© 2015 Open Geospatial Consortium

362

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

Local Vertex Pool Record
The Local Vertex Pool record has been modified to include an alpha color
component for those vertices in the pool that have color. The alpha color component
is represented as a 1 byte integer value whose range is 0 (fully transparent) to 255(fully opaque).
The definition of the Attribute mask field has been changed as shown here.
Note: The physical layout of this field has not changed, only its definition. The bits forwhich new definitions apply are shown in bold font:

Data Type

Local Vertex Pool Record changes for OpenFlight15.8
Attribute mask field

Unsigned Int

OffsetLengthDescription

8

4

Attribute mask - Bit mask indicating what kind ofvertex information is specified for each vertex in
the local vertex pool. Bits are ordered from left toright as follows:
Bit
Description#0
Has Position - if set, data for each vertex inwill include x, y, and z coordinates (3doubles)1
Has Color Index - if set, data for eachvertex will include a color value thatspecifies a color table index as well as analpha value
2
Has RGBA Color - if set, data for eachvertex will include a color value that is apacked RGBA color value
Note: Bits 1and 2 are mutually exclusive - a vertex
can have either color index or RGB color value orneither, but not both.
3
Has Normal - if set, data for each vertex will
include a normal (3 floats)
4
Has Base UV - if set, data for each vertex
will include uv texture coordinates for thebase texture (2 floats)
5
Has UV Layer 1 - if set, data for each vertex
will include uv texture coordinates for layer
1 (2 floats)
6
Has UV Layer 2 - if set, data for each vertex
will include uv texture coordinates for layer
2 (2 floats)
7
Has UV Layer 3 - if set, data for each vertex
will include uv texture coordinates for layer
3 (2 floats)© 2015 Open Geospatial Consortium

363

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
8
9
10
11
1231

Has UV Layer 4 - if set, data for each vertex
will include uv texture coordinates for layer
4 (2 floats)
Has UV Layer 5 - if set, data for each vertex
will include uv texture coordinates for layer
5 (2 floats)
Has UV Layer 6 - if set, data for each vertex
will include uv texture coordinates for layer
6 (2 floats)
Has UV Layer 7 - if set, data for each vertex
will include uv texture coordinates for layer
7 (2 floats)Spare© 2015 Open Geospatial Consortium

364

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The color field of the vertex pool data (data for each vertex) has been modified toinclude an alpha color component as shown here. The affected field is shown in bold
font.

Local Vertex Pool Record changes for OpenFlight15.8
Color field

Data Type
Unsigned Int

Offset4

Description
colorN - Color for vertex N - present if Attribute mask
includes Has Color Index or Has RGBA Color.
If Has Color Index, lower 3 bytes specify color tableindex, upper 1 byte is Alpha.
If Has RGBA Color, 4 bytes specify (a, b, g, r) values.

For a complete description of the local vertex pool record, see “Local Vertex Pool
Record” on page 30.
Vertex Palette Records
Vertex Palette Records have been modified to include an alpha color component.
The alpha color component is represented as a 1 byte integer value whose range is 0
(fully transparent) to 255 (opaque).
Prior to OpenFlight version 15.8, vertex colors were represented in vertex paletterecords in one of two ways: Packed Color or Color Index. Depending on the value ofthe Packed color flag, either the Packed color (a, b, g, r) attribute or the Vertex color
index attribute was valid, but not both. For example, if the Packed color flag was
TRUE, then the Packed color attribute contained the RGB components of the vertex
color and the Vertex color index attribute was not specified. Conversely, if the
Packed color flag was FALSE, then the Vertex color index attribute contained theindex (in the Color Palette) of the vertex color and the Packed color attribute was
not specified. Furthermore, the A (alpha) component of the Packed color attribute
was not valid and was ignored.
In OpenFlight version 15.8, the A (alpha) component of the Packed color attribute isvalid and all vertex records include the Packed color (a, b, g, r) attribute, even thosethat also include the Vertex color index attribute. For those vertices that include theVertex color index attribute, the RGB components of the Packed color attribute will
match those of the color specified by the Vertex color index attribute if it was looked
up in the color palette. This implies that an application concerned only with the
RGB components of a vertex color can simply reference the Packed color attributeand ignore the Vertex color index attribute in all cases.
All the updated vertex palette records are shown here. The Packed color is shown inbold font to emphasize that it is always specified (for both color index and packed
color specifications).

© 2015 Open Geospatial Consortium

365

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Vertex with Color Record changes for OpenFlight 15.8
Packed color field

Data typeInt
Unsigned Int
Unsigned Int
Int

Offset0
2
4
6

Length22
2
2

Double
Int

8
32

8*3
4

Unsigned Int

36

4

Description
Vertex with Color Opcode 68
Length - length of the record
Color name index
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Packed color (a, b, g, r) - always specified
when the vertex has color
Vertex color index - valid only if vertex has
color and Packed color flag is not set

Vertex with Color and Normal Record changes for OpenFlight 15.8
Packed color field

Data typeInt
Unsigned Int
Unsigned Int
Int

Offset0
2
4
6

Length22
2
2

Double
Float
Int

8
32
44

8*3
4*3
4

Unsigned Int

48

4

Int

52

4

Description
Vertex with Color and Normal Opcode 69
Length - length of the record
Color name index
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Vertex normal (i, j, k)
Packed color (a, b, g, r) - always specified
when the vertex has color
Vertex color index - valid only if vertex has
color and Packed color flag is not set
Reserved© 2015 Open Geospatial Consortium

366

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Vertex with Color and UV Record changes for OpenFlight 15.8
Packed color field

Data typeInt
Unsigned Int
Unsigned Int
Int

Offset0
2
4
6

Length22
2
2

Double
Float
Int

8
32
40

8*3
4*2
4

Unsigned Int

44

4

Description
Vertex with Color and UV Opcode 71
Length - length of the record
Color name index
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Texture coordinate (u, v)
Packed color (a, b, g, r) - always specified
when the vertex has color
Vertex color index - valid only if vertex has
color and Packed color flag is not set

Vertex with Color, Normal and UV Record changes for OpenFlight 15.8
Packed color field

Data typeInt

Offset0

Length2

Description
Vertex with Color, Normal and UV Opcode
70
Unsigned Int 2
2
Length - length of the record
Unsigned Int 42
Color name index
Int
62
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Double8
8*3Vertex coordinate (x, y, z)
Float
36
4*3
Vertex normal (i, j, k)
Float
44
4*2
Texture coordinate (u, v)
Int
52
4
Packed color (a, b, g, r) - always specified
when the vertex has color
Unsigned Int 56
4Vertex color index - valid only if vertex has
color and Packed color flag is not set
Int
60
4
Reserved
For a complete description of the vertex palette records, see “Vertex Palette Records” onpage 66.

© 2015 Open Geospatial Consortium

367

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Light Points
The representation of Light Points in OpenFlight version 15.8 is significantly
different from prior versions. Previously, all light point attributes were describedcompletely within the primary record of the light point node.
In OpenFlight version 15.8, light point attributes have been divided into two
categories, appearance and behavioral. To accommodate this, two new palettes havebeen created, the Light Point Appearance Palette and the Light Point Animation
palette. A new Indexed Light Point node record has been added that references
entries from the Light Point Appearance and Animation palettes. In effect, thismoves the light point attributes out of the node record itself into entries of the two
palettes and makes it much easier to share common attributes between multiple
light points.
Note that the Light Point Record (Opcode 111) used in previous versions of
OpenFlight remains valid for applications that require the data in this other format.
Creator and the OpenFlight API versions 2.6 support both light point formats.
Following is a description of the new records in OpenFlight version 15.8 used todescribe Light Point Palettes and Indexed Light Points.

Light Point Appearance Palette Record
The light point appearance palette record defines the visual attributes of lightpoints.

Light Point Appearance Palette Record
New record for OpenFlight 15.8

Data TypeInt
Unsigned Int
Int
Char
Int
Int
Int
Unsigned Int
Int

Offset
0
2
4
8
264
268
270
272
276

Length
2
2
4
256
4
2
2
4
4

Float
Float
Float

280
284
288

4
4
4

Float

292

4

Int

296

4

Description
Light Point Appearance Palette Opcode 128
Length - length of the record
Reserved
Appearance name; 0 terminates
Appearance index
Surface material code
Feature ID
Back color for bidirectional points
Display mode
0 = RASTER
1 = CALLIGRAPHIC
2 = EITHER
Intensity - scalar for front colors
Back intensity - scalar for back color
Minimum defocus - (0.0 - 1.0) for calligraphic
pointsMaximum defocus - (0.0 - 1.0) for
calligraphic points
Fading mode
0 = Enable perspective fading calculations
1 = Disable calculations© 2015 Open Geospatial Consortium

368

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Light Point Appearance Palette Record
New record for OpenFlight 15.8 (Continued)

Data TypeInt

Offset300

Length
4

Int

304

4

Int

308

4

Float
Float
Float
Float

312
316
320
324

4
4
4
4

Float

328

4

Float

332

4

Float

336

4

Float

340

4

Float
Float

344
348

4
4

Int

352

4

Float
Float
Float

356
360
364

4
4
4

Float

368

4

Float
Float

372
376

4
4

Description
Fog Punch mode
0 = Enable fog punch through calculations
1 = Disable calculations
Directional mode
0 = Enable directional calculations
1 = Disable calculations
Range mode
0 = Use depth (Z) buffer calculation
1 = Use slant range calculation
Min pixel size - minimum diameter of points in pixels
Max pixel size - maximum diameter of points in pixels
Actual size - actual diameter of points in database units
Transparent falloff pixel size - diameter in pixels when points
become transparent
Transparent falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Transparent falloff scalar> 0 - falloff multiplier scale factor
Transparent falloff clamp - minimum permissible falloff
multiplier result
Fog scalar>= 0 - adjusts range of points for punch threw effect.
Fog intensity
Size difference threshold - point size transition hint to renderer
Directionality
0 = OMNIDIRECTIONAL
1 = UNIDIRECTIONAL
2 = BIDIRECTIONAL
Horizontal lobe angle - total angle in degrees
Vertical lobe angle - total angle in degrees
Lobe roll angle - rotation of lobe about local Y axis in degrees
Directional falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Directional ambient intensity - of points viewed off axis
Significance - drop out priority for RASCAL lights (0.0 - 1.0)

© 2015 Open Geospatial Consortium

369

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

Data TypeInt

Light Point Appearance Palette Record
New record for OpenFlight 15.8 (Continued)
Offset380

Length
4

Float
Float

384
388

4
4

Float

392

4

Float

396

4

Float

400

4

Float

404

4

Description
Flags (bits, from left to right)
0 = reserved
1 = No back color
TRUE = don’t use back color forbidirectional points
FALSE = use back color forbidirectional points
2 = reserved
3 = Calligraphic proximity occulting(Debunching)
4 = Reflective, non-emissive point
5-7 = Randomize intensity
0 = never
1 = low
2 = medium
3 = high
8 = Perspective mode
9 = Flashing
10 = Rotating
11 = Rotate Counter Clockwise
Direction of rotation about local Z axis
12 = reserved
13-14 = Quality
0 = Low
1 = Medium
2 = High
3 = Undefined
15 = Visible during day
16 = Visible during dusk
17 = Visible during night
18-31 = Spare
Visibility range (> 0.0)
Fade range ratio - percentage of total range
at which light points start to fade (0.0 - 1.0)
Fade in duration - time it takes (seconds)
light point to fade in when turned on
Fade out duration - time it takes (seconds)
light point to fade out when turned off
LOD range ratio - percentage of total range
at which light points LODs are active (0.0 1.0)
LOD scale - size of light point LOD
polygon relative to light point diameter© 2015 Open Geospatial Consortium

370

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Light Point Animation Record
The light point animation palette record defines the behavioral attributes of lightpointsData TypeInt
Unsigned Int
Int
char
Int
Float
Float
Float
Float
Float
Float
Int

Offset
0
2
4
8
264
268
272
276
280
284
288
292

Light Point Animation Palette Record
New record for OpenFlight 15.8
Length
2
2
4
256
4
4
4
4
4
4
4
4

Description
Light Point Animation Opcode 129
Length - length of the record
Reserved
Animation name; 0 terminates
Animation index
Animation period in seconds. Note: Rate = 1/Period
Animation phase delay in seconds - from start of period
Animation enabled period (time on) in seconds
Axis of rotation for rotating animation, I
Axis of rotation for rotating animation, J
Axis of rotation for rotating animation, K
Flags (bits, from left to right)
0 = Flashing
1 = Rotating
2 = Rotate counter clockwise
3-31 = Spare
Int
296
4
Animation type
0 = Flashing sequence
1 = Rotating
2 = Strobe
3 = Morse code
Int
300
4
Morse code timing
0 = Standard timing
1 = Farnsworth timing
Int
304
4
Word rate (for Farnsworth timing)
Int
308
4
Character rate (for Farnsworth timing)
char
312
1024
Morse code string
Int
1336
4
Number of sequences (for Flashing sequence)
The following fields are repeated for each sequence represented in the light point animation palette entry.
In the fields listed below, N ranges from 0 to Number of sequences - 1.
1340+(N*12)
Unsigned Int
4
Sequence StateN - state of sequence N
0 = On1 = Off
2 = Color change
1344+(N*12)
Float
4
Sequence DurationN - duration of sequence N in seconds
1348+(N*12)
Unsigned Int
4
Sequence ColorN - color for sequence N.
Defined if Sequence state is On or Color change
For a complete description of the light point animation palette record, see “Light Point
Animation Palette Record” on page 85.

© 2015 Open Geospatial Consortium

371

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Indexed Light Point Record
The indexed light point record is one of the records that can represent a light point
node.
The appearance index specifies an entry in the light point appearance palette that
contains the visual attributes of the light point.
The animation index specifies an entry in the light point animation palette that
contains the behavioral attributes of the light point.
The palette entries referenced by the indexed light point record describe the visualstate of the light point’s child vertices. Only vertex nodes may be children of lightpoint nodes.

Data TypeInt
Unsigned Int
Char
Int
Int
Int
Int

Offset
0
2
4
12
16
20
24

Indexed Light Point Record
New record for OpenFlight 15.8
Length
2
2
8
4
4
4
4

Description
Indexed Light Point Record Opcode 130
Length - length of the record
7 char ASCII ID; 0 terminates
Appearance index
Animation index
Draw order (for calligraphic lights)
Reserved

For a complete description of the light point records, see “Indexed Light Point
Record” on page 34.

Light Point System Record
The light point system record enables you to collect a set of light points andenable/disable or brighten/dim them as a group.

Data TypeInt
Unsigned Int
Char
Float
Int

Offset
0
2
4
12
16

Int

20

Light Point System Record
New record for OpenFlight 15.8
Length
2
2
8
4
4

4

Description
Light Point System Record Opcode 130
Length - length of the record
7 char ASCII ID; 0 terminates
Intensity
Animation state
0 = On1 = Off
2 = Random
Flags (bits, from left to right)
0 = Enabled
1-31 = Spare

For a complete description of the light point system record, see “Light Point System
Record” on page 37.

© 2015 Open Geospatial Consortium

372

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

Texture Mapping Palette Record
Parameters for 3 Point Put Texture Mapping (Type 1)
The UV display type field, previously labeled Reserved in prior versions of thisdocument, has been re-labeled in the specification for OpenFlight 15.8. The physicallayout of the record was not changed.

Data TypeInt

Parameters for 3 Point Put Texture Mapping (Type 2)changes for OpenFlight15.8
UV display type field (re-labeled)
Offset388

Length4

Description
UV display type
1 = XY
2 = UV

Parameters for 4 Point Put Texture Mapping (Type 2)
The following fields were added to the end (at the specified offsets) of the parameter
subrecord.

Data Type
Float
Float

Parameters for 4 Point Put Texture Mapping (Type 2)changes for OpenFlight15.8
New Fields
Offset576
580

Length44Description
U Repetition
V Repetition

The UV display type field, previously labeled Reserved in prior versions of the
document, has been re-labeled in the specification for Open Flight 15.8. The physicallayout of the record was not changed.

Data TypeInt

Parameters for 4 Point Put Texture Mapping (Type 2)changes for OpenFlight15.8
UV display type field (re-labeled)
Offset436

Length4

Description
UV display type
1 = XY
2 = UV© 2015 Open Geospatial Consortium

373

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

C Summary of Changes Version 16.0
Overview
This section describes the changes in the OpenFlight Scene Description between
versions 15.8 and 16.0 as well as the errors contained in previous versions of thisdocument that have been corrected in this version.
OpenFlight version 16.0 coincides with MultiGen Creator version 3.0 and the
OpenFlight API version 3.0. The changes made for this version are:
[
[
[
[
[
[
[

“External Reference Record” on page 147“Face Record” on page 148“Mesh Record” on page 148“Light Point Appearance Palette Record” on page 148“Shader Palette Record” on page 149“Texture Attribute File” on page 149“Texture Mapping Palette Record” on page 150

Document Corrections
The errors corrected in this version of the document are described in the sections
that follow.
Header Record
The value corresponding to User defined ellipsoid for the Earth ellipsoid model fieldhas been corrected. It was previously listed as having a value of 5. The correct valueis -1. The corrected value is shown in bold font.

Header Record error corrected in OpenFlight 16.0 specification
Earth ellipsoid model field (corrected)

Data TypeInt

Offset268

Length4

Description
Earth ellipsoid model
0 = WGS 1984
1 = WGS 1972
2 = Bessel
3 = Clarke 1866
4 = NAD 1927
-1 = User defined ellipsoid© 2015 Open Geospatial Consortium

375

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

Face Record
The possible values listed for the Draw type field have been corrected. The affectedvalues are shown in bold font.

Face Record error corrected in OpenFlight 16.0 specification
Draw type field (corrected)

Data TypeInt

Offset18

Length1

Description
Draw type
0 = Draw solid with backface culling
1 = Draw solid, no backface culling
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light

For a complete description of the face record, see “Face Record” on page 26.
Mesh Record
The Reserved field at offset 12, previously omitted in prior versions of thisdocument, has been documented in the specification for OpenFlight 16.0. The offsetsof fields following this field have been adjusted accordingly.

Mesh Record error corrected in OpenFlight 16.0 specification
Reserved field (documented)

Data TypeInt

Offset12

Length4

Description
Reserved

The possible values listed for the Draw type field have been corrected. The affectedvalues are shown in bold font.

Mesh Record error corrected in OpenFlight 16.0 specification
Draw type field (corrected)

Data TypeInt

Offset18

Length1

Description
Draw type
0 = Draw solid with backface culling
1 = Draw solid, no backface culling
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light© 2015 Open Geospatial Consortium

376

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

For a complete description of the mesh record, see “Mesh Record” on page 29.
Switch Record
The order of the fields were corrected. The affected fields are shown here.

Switch Record error corrected in OpenFlight 16.0 specification
field order (corrected)

Data TypeInt
Int

Offset20
24

Length44Description
Number of masks
Number of words per mask - the number of 32
bit words required for each mask, calculated
as follows:(number of children / 32) + X
where X equals:
0 if (number of children modulo 32) is zero
1 if (number of children modulo 32) isnonzeroFor a complete description of the switch record, see “Switch Record” on page 49.
Texture Mapping Palette Record
The parameters for warped mapping in the texture mapping palette record werecorrected. The 128 byte 4x4 Trackplane to XY plane transformation matrix waserroneously listed where an 8 byte reserved field was located. The entire record isshown here. The corrected field and offsets are shown in bold font:© 2015 Open Geospatial Consortium

377

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Parameters for Warped Mapping error corrected in OpenFlight 16.0
specification
Reserved field (corrected)

Data TypeInt

OffsetX+0

Length
4

Int

X+4

4

Int
Double

X+8
X+16

8
8*8*2

Double

X+144

8*8*2

Description
Active geometry point
0 = First warp FROM point
1 = Second warp FROM point
2 = Third warp FROM point
3 = Fourth warp FROM point
4 = Fifth warp FROM point
5 = Sixth warp FROM point
6 = Seventh warp FROM point
7 = Eighth warp FROM point
8 = First warp TO point
9 = Second warp TO point
10 = Third warp TO point
11 = Fourth warp TO point
12 = Fifth warp TO point
13 = Sixth warp TO point
14 = Seventh warp TO point
15 = Eighth warp TO point
Warp tool state
0 = Start state - no points entered
1 = One FROM point entered
2 = Two FROM point entered
3 = Three FROM point entered
4 = Four FROM point entered
5 = Five FROM point entered
6 = Six FROM point entered
7 = Seven FROM point entered
8 = All FROM point enteredReserved
FROM points transformed to XY plane by
above matrix.
8 FROM points are ordered 1, 2, ... 8. Eachpoint is (x, y)
TO points transformed to XY plane by above
matrix.
8 TO points are ordered 1, 2, ... 8. Each pointis (x, y)

For a complete description of the texture mapping palette record, see “Texture Mapping
Palette Record” on page 86.

© 2015 Open Geospatial Consortium

378

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Indexed String Record
The length of the Index field has been corrected. It was previously listed as 2 bytes.
The correct length is 4 bytes. The corrected field and length are shown in bold font:
Data TypeInt
Unsigned Int
Unsigned Int
Char

Offset02
4
8

Indexed String Record

Length2
2
4
Length - 8

Description
Indexed string Opcode 132
Length - length of the record
Index
ASCII string; 0 terminates

Bounding Convex Hull Record
The description of this previously undocumented record has been added to thespecification. For a complete description of this record, see “Bounding Convex Hull
Record” on page 62.
Bounding Histogram Record
The description of this previously undocumented record has been added to thespecification. For a complete description of this record, see “Bounding Histogram
Record” on page 62.

Format Changes
External Reference Record
The Flags field of the external reference record has been modified to include a new
bit, Shader palette override, which is used to specify that the shader palette override
those contained in the master file. The new bit is shown in bold font.

Data TypeInt

External Reference Record changes for OpenFlight15.8
Flags field
Offset208

Length4

Description
Flags (bits, from left to right)
0 = Color palette override
1 = Material palette override
2 = Texture and texture mapping paletteoverride
3 = Line style palette override
4 = Sound palette override
5 = Light source palette override
6 = Light point palette override
7 = Shader palette override
8-31 = Spare
For a complete description of the external reference record, see “External Reference
Record” on page 41.

© 2015 Open Geospatial Consortium

379

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Face Record
The face record has been modified to include a new attribute, Shader index, which isused to specify the shader (if any) that is applied to the face.

Data TypeInt

Face Record changes for OpenFlight 16.0
Flags field

Offset78

Length2

Description
Shader index, -1 if none

For a complete description of the face record, see “Face Record” on page 26.
Mesh Record
Similar to the Face record described above, the mesh record has been modified toinclude a new attribute, Shader index, which is used to specify the shader (if any)that is applied to the mesh.

Data TypeInt

Mesh Record changes for OpenFlight 16.0
Flags field

Offset78

Length2

Description
Shader index, -1 if none

For a complete description of the mesh record, see “Mesh Record” on page 29.
Light Point Appearance Palette Record
The light point appearance palette record has been modified to include a new
attribute, Texture pattern index, which is used to specify the texture (if any) that is
applied to the light point appearance.

Light Point Appearance Record changes for OpenFlight 16.0
Texture pattern index field

Data TypeInt
Int

Offset408
410

Length22

Description
Texture pattern index, -1 if none
Reserved

For a complete description of the light point appearance palette record, see “Light Point
Appearance Palette Record” on page 82.

© 2015 Open Geospatial Consortium

380

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Shader Palette Record
The shader palette contains descriptions of shaders used while drawing geometry. It
is composed of an arbitrary number of shader palette records. The shader paletterecords must follow the header record and precede the first push.

Shader Palette Record
New record for OpenFlight 16.0

Data TypeInt
Unsigned Int
Int
Int

Offset0
2
4
8

Length
2
2
4
4

char
char

12
1036

1024
1024

char

2060

1024

Int
Int
char
Char

3084
3088
3092
3348

4
4
256
256

Description
Shader Opcode 133
Length - length of the record
Shader index
Shader type
0 = Cg
1 = CgFX
2 = OpenGL Shading Language
Shader name; 0 terminates
Vertex program file name; 0 terminates(Cg Shader type specific)
Fragment program file name; 0 terminates(Cg Shader type specific)
Vertex program profile (Cg Shader type specific)
Fragment program profile (Cg Shader type specific)
Vertex program entry point (Cg Shader type specific)
Fragment program entry point (Cg Shader typespecific)

Texture Attribute File
The Wrap method fields (Wrap method u,v, Wrap method u and Wrap method v)
have been changed to include a new possible value, Mirrored repeat as shown here.
This new value is shown in bold font:.

Texture Attribute File Format changes for OpenFlight 16.0Wrap method
fieldsData TypeInt

Offset36

Length
4

Int

40

4

Description
Wrap method u,v - only used when either
Wrap method u or Wrap method v is set toNone
0 = Repeat
1 = Clamp
4 = Mirrored Repeat
Wrap method u
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat© 2015 Open Geospatial Consortium

381

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Attribute File Format changes for OpenFlight 16.0Wrap method
fieldsData TypeInt

Offset44

Length4

Description
Wrap method v
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat

The Environment type field has been changed to include a new possible value, Add
as shown here. This new value is shown in bold font.

Texture Attribute File Format changes for OpenFlight 16.0Environment
type field

Data TypeInt

Offset60

Length4

Description
Environment type
0 = Modulate
1 = Blend
2 = Decal
3 = Replace
4 = Add

Texture Mapping Palette Record
Parameters for 3 Point Put Texture Mapping (Type 1)
The following fields were added to the end (at the specified offsets) of the parameter
subrecord.

Data Type
Float
Float

Parameters for 3 Point Put Texture Mapping (Type 1)changes for OpenFlight 16.0
New Fields
Offset392
396

Length44Description
U Repetition
V Repetition© 2015 Open Geospatial Consortium

382

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

Index
B

C

D

E

Binary separating plane record 40
Bounding volumes 61
overview 14
bounding box record 62
bounding convex hull record 62
bounding cylinder record 62
bounding histogram record 62
bounding sphere record 62
bounding volume center record
63bounding volume orientation
record 63
CAT data
key data record 64
key header record 63
CAT record 50
Clip region
overview 11
clip region record 47
Color palette record 70
Comment record 53
Continuation record 66
Control records
overview 16
push level record 17
pop level record 17
push subface record 17
pop subface record 17
push extension record 17
pop extension record 17
push attribute record 18
pop attribute record 18
Curve record 52
Database hierarchy 9
Degree of freedom
overview 11
degree of freedom record 38
Extension attribute record 65
Extension record 51
External reference

overview 12
external reference record 41
Eyepoint palette record 74

F

G

H

I

K
L

Face

overview 10
face record 27

General matrix record 60
see also Transformations
Geospecific control points 98
see also Texture attribute fileGroupoverview 10
group record 24
Headeroverview 10
header record 20

Indexed string record 54, 147
Instancing 18
overview 13
Key table data record 77
Key table header record 76
Level of detailoverview 11
level of detail record 41
Light point
overview 10
indexed light point record 34
light point record 35
Light point animation palette record 85
Light point appearance palette record 82
Light point system
overview 10
light point system record 37
Light source
overview 11
light source record 44
Light source palette record 81© 2015 Open Geospatial Consortium

383

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Line style palette record 86
Linkage palette dataarc data subrecord 79
driver node data subrecord 79
entity name data subrecord 80
formula node data subrecord 78
general node data subrecord 78
Linkage palette data record 78
Linkage palette header record 77
Local vertex pool record 31
Long ID record 53

M

NO

Pop extension record 17
Pop level record 17
Pop subface record 17
Push attribute record 18
Push extension record 17
Push level record 17
Push subface record 17
Put record 60
see also Transformations

R

Material palette record 73
Matrix record 59
see also Transformations
Meshoverview 10
local vertex pool record 31
mesh primitive record 33
mesh record 29
Mesh primitive record 33
Morph vertex 11
Morph vertex list record 40
Multitexture
overview 14
multitexture record 55
UV list record 56
Name table record 71

S

Objectoverview 10
object record 26
Opcodeslist of obsolete 111
list of valid 109

P

Palette records 66
Pop attribute record 18

T

Replicate record 58
Replication
overview 14
Road construction record 45
Road path record 46
Road segment record 44
Road zone fileelevation data point subrecord
101
surface type subrecord 101
Road zone record 58
Rotate about edge record 59
see also Transformations
Rotate about point record 60
see also Transformations
Rotate and/or scale to point record 60
see also Transformations
Scale record 59
see also Transformations
Shader palette record 91
Sound
overview 11
sound record 43
Sound palette data record 81
Sound palette header record 80
Subface 11
Subtexture 98
see also Texture attribute file
Switchoverview 11
switch record 49
Text

overview 11© 2015 Open Geospatial Consortium

384

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

Texturetext Record 48

supported formats 93
Texture attribute file
overview 93
format 94
geospecific control point
subrecord 98
subtexture subrecord 98
Texture mapping paletteparameters for 4 put texture
mapping 88
parameters for put texture
mapping 87
parameters for radial projectmapping 89
parameters for spherical projectmapping 89
parameters for warped mapping
90, 146
texture mapping palette record
86
Texture palette record 73
Texture pattern file 93
Trackplane palette record 74
Transformations 58
general matrix record 60
matrix record 59
put record 60
rotate about edge record 59
rotate about point record 60
rotate and/or scale to point
record 60
scale record 59
translate record 59
Translate record 59
see also Transformations

U
Vvertex with color record 68
vertex with color, normal anduv record 69
Vertex list record 39

UV list record 56
Vector record 61
Vertexoverview 11
morph vertex list record 40
vertex palette header record 67
vertex with color and normal
record 68
vertex with color and uv record
69© 2015 Open Geospatial Consortium

385

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

Appendix D
D. ShapeFile and dBASE July 1998 Technical Description – AnnotatedThis document has been annotated to reflect the conventions established by the CDB
Specification. Collectively, these conventions are referred to as Shapefile/CDB. The
conventions define how Shape files are interpreted by a CDB-compliant Shapefile reader; thestated conventions supersede or replace related aspects of this annotated specification. Unlessstated otherwise, CDB-compliant Shapefile readers will ignore any data that fails to conform to
the stated conventions.

© 2015 Open Geospatial Consortium

387

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

Annotated w ith C DB conventi ons© 2015 Open Geospatial Consortium

388

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

© 2015 Open Geospatial Consortium

389

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

© 2015 Open Geospatial Consortium

390

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

© 2015 Open Geospatial Consortium

391

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

© 2015 Open Geospatial Consortium

392

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

Shape/CDB Readers: The CD B
standard globall y provides a set of
di rectoryandf il enam e
conventions. The conventi ons do
not l i mit fil enam es t o the 8. 3
nami ng conventi on© 2015 Open Geospatial Consortium

393

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

© 2015 Open Geospatial Consortium

394

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

© 2015 Open Geospatial Consortium

395

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

© 2015 Open Geospatial Consortium

396

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

© 2015 Open Geospatial Consortium

397

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

© 2015 Open Geospatial Consortium

398

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

© 2015 Open Geospatial Consortium

399

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

© 2015 Open Geospatial Consortium

400

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

© 2015 Open Geospatial Consortium

401

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

© 2015 Open Geospatial Consortium

402

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

© 2015 Open Geospatial Consortium

403

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

© 2015 Open Geospatial Consortium

404

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

© 2015 Open Geospatial Consortium

405

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

© 2015 Open Geospatial Consortium

406

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

© 2015 Open Geospatial Consortium

407

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

© 2015 Open Geospatial Consortium

408

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

© 2015 Open Geospatial Consortium

409

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

© 2015 Open Geospatial Consortium

410

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

© 2015 Open Geospatial Consortium

411

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

© 2015 Open Geospatial Consortium

412

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

© 2015 Open Geospatial Consortium

413

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

© 2015 Open Geospatial Consortium

414

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

© 2015 Open Geospatial Consortium

415

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

© 2015 Open Geospatial Consortium

416

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

© 2015 Open Geospatial Consortium

417

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

© 2015 Open Geospatial Consortium

418

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

© 2015 Open Geospatial Consortium

419

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

© 2015 Open Geospatial Consortium

420

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

© 2015 Open Geospatial Consortium

421

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
dBASE .DBF File Structure
by Borland Developer Support Staff

Technical Information Database
This document has been annotated to reflect the conventions established by the CDB Specification.
Collectively, these conventions are referred to as dBASE/CDB. The conventions define how dBASE files areinterpreted by a CDB-compliant dBASE reader; the stated conventions supersede or replace related aspectsof this annotated specification. Unless stated otherwise, CDB-compliant dBASE readers will ignore any datathat fails to conform to the stated conventions.
TI838D.txt dBASE .DBF File Structure
Category :Database Programming
Platform :All
Product :Delphi All
Description:
Sometimes it is necessary to delve into a dBASE table outside the control of the Borland Database Engine (BDE).
For instance, if the .DBT file (that contains memo data) for a given table is irretrievably lost, the file will not be
usable because the byte in the file header indicates that there should be a corresponding memo file. This necessitates
toggling this byte to indicate no such accompanying memo file. Or, you may just want to write your own data accessroutine.
Below are the file structures for dBASE table files. Represented are the file structures as used for various versions ofdBASE: dBASE III PLUS 1.1, dBASE IV 2.0, dBASE 5.0 for DOS, and dBASE 5.0 for Windows.
**************************************************************************The data file header structure for dBASE III PLUS table file.
**************************************************************************© 2015 Open Geospatial Consortium

422

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The table file header:======================
Byte Contents Description----- -------- -------------------------------------------------------0 1 byte
Valid dBASE III PLUS table file (03h without a memo(.DBT file; 83h with a memo).
1-3 3 bytes Date of last update; in YYMMDD format.
4-7 32-bit
Number of records in the table.
number
8-9 16-bit
Number of bytes in the header.
number
10-11 16-bit
Number of bytes in the record.
number12-14 3 bytes Reserved bytes.
15-27 13 bytes Reserved for dBASE III PLUS on a LAN.
28-31 4 bytes Reserved bytes.
32-n 32 bytes Field descriptor array (the structure of this array is
eachshown below)
n+1 1 byte
0Dh stored as the field terminator.
n above is the last byte in the field descriptor array. The size of thearray depends on the number of fields in the table file.
Table Field Descriptor Bytes============================
Byte Contents Description----- -------- -------------------------------------------------------0-10 11 bytes Field name in ASCII (zero-filled).
11 1 byte
Field type in ASCII (C, D, L, M, or N).
12-15 4 bytes Field data address (address is set in memory; not usefulon disk).
16 1 byte
Field length in binary.
17 1 byte
Field decimal count in binary.
18-19 2 bytes Reserved for dBASE III PLUS on a LAN.
20 1 byte
Work area ID.
21-22 2 bytes Reserved for dBASE III PLUS on a LAN.
23 1 byte
SET FIELDS flag.
24-31 1 byte
Reserved bytes.
Table Records=============The records follow the header in the table file. Data records are preceded by one byte, that is, a space (20h) if therecord is not deleted, an asterisk (2Ah) if the record is deleted. Fields are packed into records without field
separators or record terminators. The end of the file is mark by a single byte, with the end-of-file marker, an OEM
code page character value of 26 (1Ah). You can input OEM code page data as indicated below.

© 2015 Open Geospatial Consortium

423

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Allowable Input for dBASE Data Types====================================
Data Type
Data Input-------------- ----------------------------------------------------------C (Character) All OEM code page characters.
D (Date)Numbers and a character to separate month, day, and year
(stored internally as 8 digits in YYYYMMDD format).
N (Numeric) - . 0 1 2 3 4 5 6 7 8 9L (Logical) ? Y y N n T t F f (? when not initialized).
M (Memo)All OEM code page characters (stored internally as 10
digits representing a .DBT block number).
Binary, Memo, and OLE Fields And .DBT Files===========================================
Memo fields store data in .DBT files consisting of blocks numbered sequentially (0, 1, 2, and so on). The size ofthese blocks are internally set to 512 bytes. The first block in the .DBT file, block 0, is the .DBTfile header.
Memo field of each record in the .DBF file contains the number of the block (in OEM code page values) where thefield's data actually begins. If a field contains no data, the .DBF file contains blanks (20h) rather than a number.
When data is changed in a field, the block numbers may also change and the number in the .DBF may be changed toreflect the new location.
This information is from the Using dBASE III PLUS manual, Appendix C.
**************************************************************************The data file header structure for dBASE IV 2.0 table file.
**************************************************************************© 2015 Open Geospatial Consortium

424

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
File Structure:===============
Byte Contents
Meaning------- ---------- ------------------------------------------------0
1byte
Valid dBASE IV file; bits 0-2 indicate version
number, bit 3 the presence of a dBASE IV memo
file, bits 4-6 the presence of an SQL table, bit
7 the presence of any memo file (either dBASE III
PLUS or dBASE IV).
1-3
3 bytes
Date of last update; formatted as YYMMDD.
4-7
32-bit number Number of records in the file.
8-9
16-bit number Number of bytes in the header.
10-11 16-bit number Number of bytes in the record.
12-13 2 bytes
Reserved; fill with 0.
14
1 byteFlag indicating incomplete transaction.
15
1 byteEncryption flag.
16-27 12 bytes
Reserved for dBASE IV in a multi-user environment.
28
1 bytes
Production MDX file flag; 01H if there is an MDX,
00H if not.
29
1 byteLanguage driver ID.
30-31 2 bytes
Reserved; fill with 0.
32-n* 32 bytes each Field descriptor array (see below).
n + 1 1 byte
0DH as the field terminator.
* n is the last byte in the field descriptor array. The size of the array depends on the number of fields in the databasefile.
The field descriptor array:===========================
Byte Contents
Meaning------- ------------ -------------------------------------------------0-10 11 bytes
Field name in ASCII (zero-filled).
11
1 byteField type in ASCII (C, D, F, L, M, or N).
12-15 4 bytes
Reserved.
16
1 byteField length in binary.
17
1 byteField decimal count in binary.
18-19 2 bytes
Reserved.
20
1 byteWork area ID.
21-30 10 bytes
Reserved.
31
1 byteProduction MDX field flag; 01H if field has anindex tag in the production MDX file, 00H if not.
Database records:=================The records follow the header in the database file. Data records are preceded by one byte; that is, a space (20H) if
the record is not deleted, an asterisk (2AH) if the record is deleted. Fields are packed into records without field
separators or record terminators. The end of the file is marked by a single byte, with the end-of-file marker an
ASCII 26 (1AH) character.

© 2015 Open Geospatial Consortium

425

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Allowable Input for dBASE Data Types:====================================
Data Type
Data Input---- ---------- ----------------------------------------------------C (Character) All OEM code page characters.
D (Date)Numbers and a character to separate month, day, andyear (stored internally as 8 digits in YYYYMMDD
format).
F (Floating-.0123456789
point binary
numeric)
N (Binary-.0123456789
coded decimal
numeric)
L (Logical)? Y y N n T t F f (? when not initialized).
M (Memo)All OEM code page characters (stored internally as 10
digits representing a .DBT block number).
Memo Fields And .DBT Files===========================================
Memo fields store data in .DBT files consisting of blocks numbered sequentially (0, 1, 2, and so on). SETBLOCKSIZE determines the size of each block. The first block in the .DBT file, block 0, is the .DBT file header.
Each memo field of each record in the .DBF file contains the number of the block (in OEM code page values) where
the field's data actually begins. If a field contains no data, the .DBF file contains blanks (20h) rather than a number.
When data is changed in a field, the block numbers may also change and the number in the .DBF may be changed toreflect the new location.
This information is from the dBASE IV Language Reference manual, Appendix D.
**************************************************************************The data file header structure for dBASE 5.0 for DOS table file.
**************************************************************************© 2015 Open Geospatial Consortium

426

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The table file header:======================
Byte Contents Description----- -------- -------------------------------------------------------0 1 byte
Valid dBASE for Windows table file; bits 0-2 indicate
version number; bit 3 indicates presence of a dBASE IV
or dBASE for Windows memo file; bits 4-6 indicate thepresence of a dBASE IV SQL table; bit 7 indicates thepresence of any .DBT memo file (either a dBASE III PLUS
type or a dBASE IV or dBASE for Windows memo file).
1-3 3 bytes Date of last update; in YYMMDD format.
4-7 32-bit
Number of records in the table.
number
8-9 16-bit
Number of bytes in the header.
number
10-11 16-bit
Number of bytes in the record.
number12-13 2 bytes Reserved; filled with zeros.
14 1 byte
Flag indicating incomplete dBASE transaction.
15 1 byte
Encryption flag.
16-27 12 bytes Reserved for multi-user processing.
28 1 byte
Production MDX flag; 01h stored in this byte if a production .MDX file exists for this table; 00h if no .MDX
file exists.
29 1 byte
Language driver ID.
30-31 2 bytes Reserved; filled with zeros.
32-n 32 bytes Field descriptor array (the structure of this array is
eachshown below)
n+1 1 byte
0Dh stored as the field terminator.
n above is the last byte in the field descriptor array. The size of the array depends on the number of fields in the table
file.
Table Field Descriptor Bytes============================
Byte Contents Description----- -------- -------------------------------------------------------0-10 11 bytes Field name in ASCII (zero-filled).
11 1 byte
Field type in ASCII (B, C, D, F, G, L, M, or N).
12-15 4 bytes Reserved.
16 1 byte
Field length in binary.
17 1 byte
Field decimal count in binary.
18-19 2 bytes Reserved.
20 1 byte
Work area ID.
21-30 10 bytes Reserved.
31 1 byte
Production .MDX field flag; 01h if field has an index
tag in the production .MDX file; 00h if the field is notindexed.

© 2015 Open Geospatial Consortium

427

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table Records=============The records follow the header in the table file. Data records are preceded by one byte, that is, a space (20h) if therecord is not deleted, an asterisk (2Ah) if the record is deleted. Fields are packed into records without field
separators or record terminators. The end of the file is marked by a single byte, with the end-of-file marker, an OEM
code page character value of 26 (1Ah). You can input OEM code page data as indicated below.
Allowable Input for dBASE Data Types====================================
Data Type
Data Input-------------- ----------------------------------------------------------C (Character) All OEM code page characters.
D (Date)Numbers and a character to separate month, day, and year
(stored internally as 8 digits in YYYYMMDD format).
F (Floating - . 0 1 2 3 4 5 6 7 8 9point binary
numeric)
N (Numeric) - . 0 1 2 3 4 5 6 7 8 9L (Logical) ? Y y N n T t F f (? when not initialized).
M (Memo)All OEM code page characters (stored internally as 10
digits representing a .DBT block number).
Memo Fields And .DBT Files===========================================
Memo fields store data in .DBT files consisting of blocks numbered sequentially (0, 1, 2, and so on). SETBLOCKSIZE determines the size of each block. The first block in the .DBT file, block 0, is the .DBT file header.
Each memo field of each record in the .DBF file contains the number of the block (in OEM code page values) where
the field's data actually begins. If a field contains no data, the .DBF file contains blanks (20h) rather than a number.
When data is changed in a field, the block numbers may also change and the number in the .DBF may be changed toreflect the new location.
Unlike dBASE III PLUS, if you delete text in a memo field, dBASE 5.0 for DOS may reuse the space from thedeleted text when you input new text. dBASE III PLUS always appends new text to the end of the .DBT file. In
dBASE III PLUS, the .DBT file size grows whenever new text is added, even if other text in the file is deleted.

© 2015 Open Geospatial Consortium

428

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
This information is from the dBASE for DOS Language Reference manual, Appendix C.
**************************************************************************The data file header structure for dBASE 5.0 for Windows table file.
**************************************************************************The table file header:======================
Byte Contents Description----- -------- -------------------------------------------------------0 1 byte
Valid dBASE for Windows table file; bits 0-2 indicate
version number; bit 3 indicates presence of a dBASE IV
or dBASE for Windows memo file; bits 4-6 indicate thepresence of a dBASE IV SQL table; bit 7 indicates thepresence of any .DBT memo file (either a dBASE III PLUS
type or a dBASE IV or dBASE for Windows memo file).
1-3 3 bytes Date of last update; in YYMMDD format.
4-7 32-bit
Number of records in the table.
number
8-9 16-bit
Number of bytes in the header.
number
10-11 16-bit
Number of bytes in the record.
number12-13 2 bytes Reserved; filled with zeros.
14 1 byte
Flag indicating incomplete dBASE IV transaction.
15 1 bytedBASE IV encryption flag.
16-27 12 bytes Reserved for multi-user processing.
28 1 byte
Production MDX flag; 01h stored in this byte if a production .MDX file exists for this table; 00h if no .MDX
file exists.
29 1 byte
Language driver ID.
30-31 2 bytes Reserved; filled with zeros.
32-n 32 bytes Field descriptor array (the structure of this array is
eachshown below)
n+1 1 byte
0Dh stored as the field terminator.
n above is the last byte in the field descriptor array. The size of the array depends on the number of fields in the tablefile.

© 2015 Open Geospatial Consortium

429

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Table Field Descriptor Bytes============================
Byte Contents Description----- -------- -------------------------------------------------------0-10 11 bytes Field name in ASCII (zero-filled).
11 1 byte
Field type in ASCII (B, C, D, F, G, L, M, or N).
12-15 4 bytes Reserved.
16 1 byte
Field length in binary.
17 1 byte
Field decimal count in binary.
18-19 2 bytes Reserved.
20 1 byte
Work area ID.
21-30 10 bytes Reserved.
31 1 byte
Production .MDX field flag; 01h if field has an index
tag in the production .MDX file; 00h if the field is notindexed.
Table Records=============The records follow the header in the table file. Data records are preceded by one byte, that is, a space (20h) if therecord is not deleted, an asterisk (2Ah) if the record is deleted. Fields are packed into records without field
separators or record terminators. The end of the file is marked by a single byte, with the end-of-file marker, an OEM
code page character value of 26 (1Ah). You can input OEM code page data as indicated below.
Allowable Input for dBASE Data Types====================================
Data Type
Data Input-------------- ----------------------------------------------------------B (Binary) All OEM code page characters (stored internally as 10
digits representing a .DBT block number).
C (Character) All OEM code page characters.
D (Date)Numbers and a character to separate month, day, and year
(stored internally as 8 digits in YYYYMMDD format).
G (General All OEM code page characters (stored internally as 10
digits or OLE) representing a .DBT block number).
N (Numeric) - . 0 1 2 3 4 5 6 7 8 9L (Logical) ? Y y N n T t F f (? when not initialized).
M (Memo)All OEM code page characters (stored internally as 10
digits representing a .DBT block number).
Binary, Memo, and OLE Fields And .DBT Files===========================================
Binary, memo, and OLE fields store data in .DBT files consisting of blocks numbered sequentially (0, 1, 2, and soon). SET BLOCKSIZE determines the size of each block. The first block in the .DBT file, block 0, is the .DBT fileheader.
Each binary, memo, or OLE field of each record in the .DBF file contains the number of the block (in OEM code
page values) where the field's data actually begins. If a field contains no data, the .DBF file contains blanks (20h)rather than a number.
When data is changed in a field, the block numbers may also change and the number in the .DBF may be changed toreflect the new location.

© 2015 Open Geospatial Consortium

430

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Unlike dBASE III PLUS, if you delete text in a memo field (or binary and OLE fields), dBASE for Windows(unlike dBASE IV) may reuse the space from the deleted text when you input new text. dBASE III PLUS always
appends new text to the end of the .DBT file. In dBASE III PLUS, the .DBT file size grows whenever new text is
added, even if other text in the file is deleted.
This information is from the dBASE for Windows Language Reference manual, Appendix C.

© 2015 Open Geospatial Consortium

431

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

Appendix E
E. CDB Light Names and Hierarchy
CDB Lights are listed below; the XML file are also delivered with the Specification in:\CDB\Metadata\Lights.xml	  © 2015 Open Geospatial Consortium

433

---

---

---

---

---

Omni

---

---

---

---

---

Color

(normalized)

Duty_Cycle

Omni

1|1|1

(Hz)

Frequency

1|1|1

0.6

(normalized)

Intensity_Res

0.6

Generic Platform Light(degrees)

All purpose generic Light1(degrees)

01

Directionality

0(normalized
RGB)

0

Description(normalized)

Width_Vert

Light

Width_Hor

1

v3.0
v3.1
Light
Light Light
Code
Code CodeIntensity

Light Hierarchy(type)

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

2

Platform

1

3

Air

2

2

2

Generic Aircraft Lights

0.6

1|1|1

Omni

---

---

---

---

---

3

3

3

Generic Light for Aircraft and Helicopters

0.6

1|1|1

Omni

---

---

---

---

---

4

4

4

Generic Anti collision Light - normally red flashing

0.6

1|0|0

Omni

---

---

---

---

---

5

5

5

Anti-collision found on bottom of the fuselage

0.6

1|0|0

Omni

---

---

---

---

---

6

6

6

Anti-collision found on bottom of the fuselage in NVG Mode

0.6

1|0|0

Omni

---

---

---

---

---

7

7

7

Anti-collision found on Top of the fuselage

0.6

1|0|0

Omni

---

---

---

---

---

8

8

8

Anti-collision found on Top of the fuselage in NVG Mode

0.6

1|0|0

Omni

---

---

---

---

---

501

501

High Intensity Anti-collision Light

0.95

1|0|0

Omni

---

---

---

0.7

0.25

4
5
6

Aircraft_Helos
Anti-collision
Bottom_Light
NVG_Bottom_Light

7
8

Top_Light
NVG_Top_Light

910

High_Intensity
999Florescent formation strip Lights

0.6

1|1|1

Omni

---

---

---

---

---

10

10

10

White flood Lights used to illuminate the ground or part of
the aircraft

0.8

1|1|1

Omni

---

---

---

---

---

Head_Light

11

11

11

Head Light used to allow pilots to see ahead

0.6

1|1|1

Omni

---

---

---

---

---

Identification_Strobe

12

12

12

Generic Strobe Lights used in fLight to indicate position

0.6

1|1|1

Omni

---

---

---

1

0.05

11

Formation_Light

12

Flood_Light

13
14
15

Red_Light

13

13

13

Red identification strobe Light

0.6

1|0|0

Omni

---

---

---

1

0.05

16

White_Light

14

14

14

White identification strobe Light

0.6

1|1|1

Omni

---

---

---

1

0.05

15

15

15

Infrared Lights used to indicate position using infrared
instruments

0.6

1|1|1

Omni

---

---

---

---

---

16

16

White Lights used on Landing approach

0.9

1|1|1

Dir

60

60

---

---

-----

17

IR_Light

18

Landing_Light

16

19

Navigation

17

17

17

Generic Lights used in fLight to indicate position

0.6

1|1|1

Omni

---

---

---

---

18

18

18

Red Navigation Light found on the left wing

0.6

1|0|0

Omni

---

---

---

---

---

502

502

Flashing Red Navigation Light found on the left wing

0.6

1|0|0

Omni

---

---

---

1

0.5

19

19

Green Navigation Light found on the right wing

0.6

0|1|0

Omni

---

---

---

---

---

503

503

Flashing Green Navigation Light found on the right wing

0.6

0|1|0

Omni

---

---

---

1

0.5

20

20

White Navigation Light found on the tail wing

0.6

1|1|1

Omni

---

---

---

---

---

504

504

Flashing White Navigation Light found on the tail wing

0.6

1|1|1

Omni

---

---

---

1

0.5
---

20

Red_Light
Flashing_Red_Light

21
22

Green_Light

24

White_Light

27

20

Flashing_White_Light

25
26

19

Flashing_Green_Light23

NVG_Light
Tail_Light

21

21

21

Navigation Light used in NVG Mode

0.6

1|1|1

Omni

---

---

---

---

22

22

22

White Tail Light

0.6

1|1|1

Omni

---

---

---

---

---

23

23

23

Flood Light used to illuminated the tail, showing off the logo
or markings

0.8

1|1|1

Omni

---

---

---

---

---

28

Tail_Flood29

Taxi_Light

24

24

24

White Lights used when Aircrafts taxi on the ground

0.8

1|1|1

Dir

40

40

---

---

---

30

Wingtip_Obstruction

25

25

25

Generic Wintip obstruction Light

0.6

1|0|0

Omni

---

---

---

0.5

0.33

Red_Light

26

26

26

Red Obstruction Light found on left wing

0.6

1|0|0

Omni

---

---

---

0.5

0.33

Green_Light

27

27

27

Green Obstruction Light found on right wing

0.6

0|1|0

Omni

---

---

---

0.5

0.33

28

28

28

Generic Civil aircraft Lights

0.6

1|1|1

Omni

---

---

---

---

---

31
32
33

Civil

34

Business

29

29

29

0.6

1|1|1

Omni

---

---

---

---

---

35

Regional

30

30

30

0.6

1|1|1

Omni

---

---

---

---

---

36

Transport

31

31

31

0.6

1|1|1

Omni

---

---

---

---

---

37

Widebody

32

32

32

0.6

1|1|1

Omni

---

---

---

---

---

33

33

33

Generic Military aircrafts Lights

0.6

1|1|1

Omni

---

---

---

---

---

38
39
40

Military
Cargo_Light
IR

34

34

34

Cargo Light

0.6

1|1|1

Dir

180

60

---

---

---

35

35

35

Infrared Cargo Light

0.6

1|1|1

Dir

180

60

---

---

---

41

Refueling_Light

36

36

36

Refueling Light

0.6

1|1|1

Dir

60

60

---

---

---

42

Search_Light

37

37

37

Search Light

0.9

1|1|1

Dir

10

10

---

---

---

43

NVG_Light

38

38

38

Search Light used in NVG Mode

0.9

1|1|1

Dir

10

10

---

---

---

44

ASW_Patrol

39

39

39

GenericASW Patrol Aircraft Lights

0.6

1|1|1

Omni

---

---

---

---

---

45

Bomber40

40

40Generic Bomber Aircraft Lights

0.6

1|1|1

Omni

---

---

---

---

---

46

Cargo_Tanker

41

41

41

Generic Cargo Tanker Aircraft Lights

0.6

1|1|1

Omni

---

---

---

---

---

47

Pod_Light

425

466

466

Generic Pod Lights on Cargo Tanker

0.6

1|1|1

Omni

---

---

---

---

---

426

467

467

Generic Starboard Pod Lights on Cargo Tanker

0.6

1|1|1

Omni

---

---

---

---

---

48

Starboard

49

Green_Light

427

468

468

Green Light Aft of Starboard pod

0.6

0|1|0

Omni

---

---

---

---

---

50

Red_Light

428

469

469

Red Light Aft of Starboard pod

0.6

1|0|0

Omni

---

---

---

---

---

© 2015 Open Geospatial Consortium

434

---

---

---

---

---

Omni

---

---

---

---

---

Color

(normalized)

Duty_Cycle

Omni

1|1|1

(Hz)

Frequency

1|1|0

0.6

(normalized)

Intensity_Res

0.6

Generic Port Pod Lights on Cargo Tanker(degrees)

Yellow Light Aft of Starboard pod

471(degrees)

470

471

Directionality

470

430

(normalized
RGB)

429

Description(normalized)

Width_Vert

Port

52

Width_Hor

Yellow_Light

51

v3.0
v3.1
Light
Light Light
Code
Code CodeIntensity

Light Hierarchy(type)

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

53

Green_Light

431

472

472

Green Light Aft of Port pod

0.6

0|1|0

Omni

---

---

---

---

---

54

Red_Light

432

473

473

Red Light Aft of Port pod

0.6

1|0|0

Omni

---

---

---

---

---

55

Yellow_Light

433

474

474

Yellow Light Aft of Port pod

0.6

1|1|0

Omni

---

---

---

---

-----

56

Aldus_Light

434

475

475

Generic Aldus Lights on Cargo Tanker

0.6

1|1|1

Omni

---

---

---

---

57

Starboard

435

476

476

Generic Starboard Aldus Lights on Cargo Tanker

0.6

1|1|1

Omni

---

---

---

---

---

58

Amber_Light

436

477

477

Amber aldus Light at Starboard Aft door

0.6

1 | 0.6 | 0

Omni

---

---

---

---

---

59

Green_Light

437

478

478

Green aldus Light at Starboard Aft door

0.6

0|1|0

Omni

---

---

---

---

---

60

Red_Light

438

479

479

Red aldus Light at Starboard Aft door

0.6

1|0|0

Omni

---

---

---

---

---

61

Yellow_Light

439

480

480

Yellow aldus Light at Starboard Aft door

0.6

1|1|0

Omni

---

---

---

---

---

440

481

481

Generic Port Aldus Lights on Cargo Tanker

0.6

1|1|1

Omni

---

---

---

---

---

Port

62
63

Amber_Light

441

482

482

Amber aldus Light at Port Aft door

0.6

1 | 0.6 | 0

Omni

---

---

---

---

---

64

Green_Light

442

483

483

Green aldus Light at Port Aft door

0.6

0|1|0

Omni

---

---

---

---

---

65

Red_Light

443

484

484

Red aldus Light at Port Aft door

0.6

1|0|0

Omni

---

---

---

---

---

Yellow_Light

444

485

485

Yellow aldus Light at Port Aft door

0.6

1|1|0

Omni

---

---

---

---

---

66
67

Fighter

42

42

42

Generic Fighter Light

0.6

1|1|1

Omni

---

---

---

---

---

68

Helicopter

43

43

43

Specific Military Helicopter Lights

0.6

1|1|1

Omni

---

---

---

---

---

69

Slung_Load_Light

44

44

44

Light used to Illuminate objects carried on a slung load

0.7

1|1|1

Omni

---

---

---

---

---

70

Attack45

45

45

Generic Attack Helicopter Light

0.6

1|1|1

Omni

---

---

---

---

---

71

Cargo

46

46

46

Generic Cargo Helicopter Light

0.6

1|1|1

Omni

---

---

---

---

---

72

Special_Ops

47

47

47

Generic Special-Ops Helicopter Light

0.6

1|1|1

Omni

---

---

---

---

---

MH47-E

445

486

486

Generic Special-OpsMH-47-E Helicopter Light

0.6

1|1|1

Omni

---

---

---

---

---

446

487

487

Lower White on bottom of Aft pylon near exhaust

0.6

1|1|1

Omni

---

---

---

---

---

48

48

48

Generic Utility Helicopter Light

0.6

1|1|1

Omni

---

---

---

---

---

49

49

Generic Tanker Light

0.6

1|1|1

Omni

---

---

---

---

---

50

50

Generic Military Unmanned Aerial Vehicle (UAV) Lights

0.6

1|1|1

Omni

---

---

---

---

---

494

494

Generic Nav Lights on UAVs to indicate position

0.6

1|1|1

Omni

---

---

---

---

---

Red_Light

495

495

Red navigation Light found on left wing

0.6

1|0|0

Omni

---

---

---

---

---

80

Green_Light

496

496

Green navigation Light found on right wing

0.6

0|1|0

Omni

---

---

---

---

---

81

White_Light

497

497

White navigation Light usually on the tail

0.6

1|1|1

Omni

---

---

---

---

---

498

498

Generic Position Lights on UAVs to indicate position

0.6

1|1|1

Omni

---

---

---

---

---

499

499

Orange position Light

0.6

1 | 0.5 | 0

Omni

---

---

---

---

---

73

Porch_Light

74
75

Utility76

Tanker49

77

Unmanned

50

Navigation

78
79

Position

82

Orange_Light

83

85
86

500

500

White position Light

0.6

1|1|1

Omni

---

---

---

---

---

51

51

51

Generic Land Vehicle Light

0.6

1|1|1

Omni

---

---

---

---

---

52

52

52

White Lights that indication a vehicle backing up

0.3

1|1|1

Omni

---

---

---

---

---

53

53

53

Yellow flashing emergency Lights (i.e. 4-way flashingindicator Light

0.4

1|1|0

Omni

---

---

---

0.5

0.5
0.5

White_Light

84

Land
Backup_Light

87

Blinking_Emergency_Light

88

Blinking_Turn_Light

54

54

54

Yellow blinking turning indicator Light

0.4

1|1|0

Omni

---

---

---

0.5

89

Brake_Light

55

55

55

Red Lights when brakes are applied

0.4

1|0|0

Omni

---

---

---

---

---

90

Headlight

56

56

56

Generic Headlight on a Land Vehicle that allow a driver to
see ahead

0.5

1|1|1

Omni

---

---

---

---

-----

91

Low_Beam_Light

57

57

57

Low beam head Lights

0.5

1|1|1

Omni

---

---

---

---

92

High_Beam_Light

58

58

58

High beam head Lights

0.6

1|1|1

Omni

---

---

---

---

---

93

Perimeter_Amber_Light

59

59

59

Perimeter Lights

0.4

1 | 0.6 | 0

Omni

---

---

---

---

---

94

Strobing_Blue_Light

60

60

60

Blue strobe (Flashing)

0.5

0|0|1

Omni

---

---

---

1

0.05

95

Strobing_Red_Light

61

61

61

Red strobe (Flashing)

0.5

1|0|0

Omni

---

---

---

1

0.05

96

Strobing_White_Light

62

62

62

White Strobe (Flashing)

0.5

1|1|1

Omni

---

---

---

1

0.05

97

Strobing_Yellow_Light

63

63

63

Yellow Strobe (Flashing)

0.5

1|1|0

Omni

---

---

---

1

0.05

98

Tail_Light

64

64

64

Red tail Lights

0.4

1|0|0

Omni

---

---

---

---

---

99

Turn_Signal_Light

65

65

65

Yellow turning indicator Light

0.4

1|1|0

Omni

---

---

---

---

---

100

Car

66

66

66

Generic Car Lights

0.4

1|1|1

Omni

---

---

---

---

---

© 2015 Open Geospatial Consortium

435

Omni

---

---

---

---

---

102

Truck

1|1|1

Omni

---

---

---

---

---

103

Ambulance

69

69

69

Generic Ambulance Lights

0.4

1|1|1

Omni

---

---

---

---

---

104

Firetruck

70

70

70

Generic Fire truck Lights

0.4

1|1|1

Omni

---

---

---

---

---

105

Train

71

71

71

Generic Train Lights

0.4

1|1|1

Omni

---

---

---

---

---

Color

Intensity(normalized)

Duty_Cycle

1|1|1

0.4

(Hz)

Frequency

0.4

Generic Truck Lights(normalized)

Intensity_Res

Generic Transport Lights

68(degrees)

Width_Vert

67

68(degrees)

Width_Hor

67

68

Description

Directionality

67

101

v3.0
v3.1
Light
Light Light
Code
Code Code(normalized
RGB)

Transport_Van

Light Hierarchy(normalized)(type)

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

Caboose_Rear_Light

72

72

72

Caboose red Light at rear of a train

0.4

1|0|0

Omni

---

---

---

---

---

107

Engine_Head_Light

73

73

73

Train engine white head Light

0.7

1|1|1

Omni

---

---

---

---

---

Tank

74

74

74

Generic Tank Lights

0.6

1|1|1

Omni

---

---

---

---

---

109

Surface

75

75

75

Generic Surface Vehicle Light

0.6

1|1|1

Omni

---

---

---

---

---

110

Buoy

76

76

76

Generic Buoy Lights found on a Surface Vehicle

0.6

1|1|1

Omni

---

---

---

0.22

0.8

108

111

Green_Light

77

77

77

Green Buoy Light

0.6

0|1|0

Omni

---

---

---

0.22

0.8

112

Red_Light

78

78

78

Red Buoy Light

0.6

1|0|0

Omni

---

---

---

0.22

0.8

113

White_Light

79

79

79

White Buoy Light

0.6

1|1|1

Omni

---

---

---

0.22

0.8

114

Yellow_Light

80

80

80

Yellow Buoy Light

0.6

1|1|0

Omni

---

---

---

0.22

0.8

81

81

81

Generic Marine Entry Light

0.6

1|1|1

Omni

---

---

---

---

---

82

82

Green Light

0.6

0|1|0

Omni

---

---

---

---

---

115

Marine_entry

116

Green_Light

82

117

Red_Light

83

83

83

Red Light

0.6

1|0|0

Omni

---

---

---

---

---

84

84

84

Generic Ship/boat Lights

0.6

1|1|1

Omni

---

---

---

---

---

85

85

85

Generic Navigation Lights on a Ship Boat

0.6

1|1|1

Omni

---

---

---

---

---

86

86

86

Generic Directional navigation Lights

0.6

1|1|1

Dir

180

180

---

---

---

118
119
120

Ship_Boat
Navigation
Directional

121

Green_Light

87

87

87

Green directional navigation Light

0.6

0|1|0

Dir

180

180

---

---

---

122

Red_Light

88

88

88

Red directional navigation Light

0.6

1|0|0

Dir

180

180

---

---

---

123

White_Light

89

89

89

White directional navigation Light

0.6

1|1|1

Dir

180

180

---

---

---

124

Omnidirectional

90

90

90

Generic Omnidirectional navigation Lights

0.6

1|1|1

Omni

---

---

---

---

---

125

Green_Light

91

91

91

Green omnidirectional navigation Light

0.6

0|1|0

Omni

---

---

---

---

---

126

Red_Light

92

92

92

Red omnidirectional navigation Light

0.6

1|0|0

Omni

---

---

---

---

---

127

White_Light

93

93

93

White omnidirectional navigation Light

0.6

1|1|1

Omni

---

---

---

---

---

128

Search_Light

94

94

94

Search Light

0.9

1|1|1

Dir

10

10

---

---

---

129

NVG_Light

95

95

95

Search Light used in NVG mode

0.9

1|1|1

Dir

10

10

---

---

---

96

96

96

Generic Ship/boat civil Lights

0.6

1|1|1

Omni

---

---

---

---

---

130

Civil

131

Anchor_Light

97

97

97

Lights used to illuminate the anchor

0.6

1|1|1

Dir

150

120

---

---

---

132

Flood_Light

98

98

98

Lights used to illuminate the ground or the deck

0.6

1|1|1

Dir

30

30

---

---

---

Mast

99

99

99

Generic Lights found on a mast of the civilian ship

0.6

1|1|1

Dir

225

120

---

---

---

133
134

Amber_Light

100

100

100

Amber Mast Light

0.6

1 | 0.6 | 0

Dir

225

120

---

---

---

135

Green_Light

101

101

101

Green Mast Light

0.6

0|1|0

Dir

225

120

---

---

---

136

Red_Light

102

102

102

Red Mast Light

0.6

1|0|0

Dir

225

120

---

---

---

White_Light

103

103

103

White Mast Light

0.6

1|1|1

Dir

225

120

---

---

---

137
138

Cargo

104

104

104

Generic Cargo Lights

0.6

1|1|1

Omni

---

---

---

---

---

139

Container_Vessel

105

105

105

Generic Container Vessel Lights

0.6

1|1|1

Omni

---

---

---

---

---

140

Ferry

106

106

106

Generic Ferry Lights

0.6

1|1|1

Omni

---

---

---

---

---

141

Fishing_Vessel

107

107

107

Generic Fishing Vessel Lights

0.6

1|1|1

Omni

---

---

---

---

---

142

Ocean_Liner

108

108

108

Generic Ocean Liner specific Lights

0.6

1|1|1

Omni

---

---

---

---

---

143

Oil_Rig

109

109

109

Generic Oil Rig Lights

0.6

1|1|1

Omni

---

---

---

---

---

144

Tanker

110

110

110

generic Tanker Lights

0.6

1|1|1

Omni

---

---

---

---

---

111

111

111

Generic Military Ship/Boat Lights

0.6

1|1|1

Omni

---

---

---

---

---

Flare_Light

112

112

112

Light effect from a Flare

0.8

1|1|1

Omni

---

---

---

---

---

147

Flood_Light

113

113

113

Lights used to illuminate the ground or the deck

0.6

1|1|1

Dir

30

30

---

---

---

148

Mast

114

114

114

Generic Lights found on a mast of the military ship

0.6

1|1|1

Dir

225

120

---

---

---

145
146

Military

149

Amber_Light

115

115

115

Amber Mast Light

0.6

1 | 0.6 | 0

Dir

225

120

---

---

---

150

Green_Light

116

116

116

Green Mast Light

0.6

0|1|0

Dir

225

120

---

---

---

© 2015 Open Geospatial Consortium436

Duty_Cycle

Dir

225

120

---

---

---

White_Light

1|1|1

Dir

225

120

---

---

---

447

447

447

Generic High-Intensity Radiated Fields Lights

0.6

1|1|1

Omni

---

---

---

---

---

Amber_Light

448

448

448

Amber HIRF Light

0.6

1 | 0.6 | 0

Omni

---

---

---

---

---

155

Red_Light

449

449

449

Red HIRF Light

0.6

1|0|0

Omni

---

---

---

---

---

156

Horizon_Bar

119

119

119

Generic Horizon Bar Lights for landing on ship

0.8

0|1|0

Omni

---

---

---

---

---

152
153
154

HIRF

(degrees)

Intensity(normalized)

Frequency

1|0|0

0.6

(Hz)

Intensity_Res

0.6

White Mast Light(normalized)(degrees)

Red Mast Light

118

Width_Vert

117

118

Width_Hor

117

118

Description(type)

Directionality

117

151

v3.0
v3.1
Light
Light Light
Code
Code CodeColor

Red_Light

Light Hierarchy(normalized)(normalized
RGB)

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

157

Green_Light

120

120

120

Green horizon bar Light

0.8

0|1|0

Omni

---

---

---

---

---

158

White_Light

121

121

121

White horizon bar Light

0.8

1|1|1

Omni

---

---

---

---

---

450

450

450

Generic Stern Light

0.6

1|1|1

Omni

---

---

---

---

---

159

Stern

160

Port_Light

451

451

451

Port stern Light

0.6

1|1|1

Omni

---

---

---

---

---

161

Starboard_Light

452

452

452

Starboard stern Light

0.6

1|1|1

Omni

---

---

---

---

---

162

VertRep_Light

453

453

453

Vertical Replenishment Light

0.6

1|1|1

Omni

---

---

---

---

---

163

Aircraft_Carrier

122

122

122

Generic aircraft carrier Light

0.6

1|1|1

Omni

---

---

---

---

---

164

Approach_Light

123

123

123

Aircraft Carrier approach Lights

0.8

1|1|1

Dir

75

75

---

---

---

165

Approach_Strobe_Light

124

124

124

Aircraft Carrier approach strobe Lights

0.9

1|1|1

Dir

75

75

---

2

0.1

166

Deck

125

125

125

Generic Deck Light

0.8

1|1|1

Omni

---

---

---

---

---

167

Aft_Light

126

126

126

Deck Aft area 1/4 mark

0.8

1|1|1

Omni

---

---

---

---

---

168

Fore_Light

127

127

127

Deck Fore area 3/4 mark

0.8

1|1|1

Omni

---

---

---

---

---

169

Edge

128

128

128

Generic Edge Light found on a Deck

0.8

0|0|1

Omni

---

---

---

---

---

170

Blue_Light

129

129

129

Blue Deck edge Light

0.8

0|0|1

Omni

---

---

---

---

---

171

Red_Light

454

454

454

Red Deck edge Light

0.8

1|0|0

Omni

---

---

---

---

---

172

White_Light

130

130

130

White Deck edge Light

0.8

1|1|1

Omni

---

---

---

---

---

131

131

131

Deck Light indicating the presence of an object which isdangerous to an aircraft

0.8

1|0|0

Omni

---

---

---

0.5

0.33

173

Obstruction_Light

174

Mark_Area

132

132

132

Generic Mark Area found on a deck0.7

1 | 0.6 | 0

Omni

---

---

---

---

---

175

Amber_Light

133

133

133

Amber deck Light

0.7

1 | 0.6 | 0

Omni

---

---

---

---

---

176

Green_Light

134

134

134

Green deck Light

0.7

0|1|0

Omni

---

---

---

---

---

177

Red_Light

135

135

135

Red deck Light

0.7

1|0|0

Omni

---

---

---

---

---

178

Ready_Light

136

136

136

Generic Deck Ready Lights

0.8

1|1|1

Omni

---

---

---

---

---

179

Status

137

137

137

Generic Status Light indicating the authority for flying
operations to the FLight Deck Officer or Pilot

0.8

1 | 0.6 | 0

Omni

---

---

---

---

---

180

Amber_Light

138

138

138

Amber status Light

0.8

1 | 0.6 | 0

Omni

---

---

---

---

---

181

Green_Light

139

139

139

Green status Light (Go signal)

0.8

0|1|0

Omni

---

---

---

---

---

182

Red_Light

140

140

140

Red status Light (Stop signal)

0.8

1|0|0

Omni

---

---

---

---

-----

183

Flood_Light

141

141

141

Lights used to illuminate the ground or the deck

0.8

1|1|1

Dir

30

30

---

---

184

GPI

142

142

142

Generic Glide path indicator Lights

0.7

1 | 0.6 | 0

Dir

180

54

---

---

---

143

143

Green Flashing GPI

0.7

0|1|0

Dir

120

20

---

1.5

0.17

185

Flashing_Green_Light

143

186

Flashing_Orange_Light

144

144

144

Orange Flashing GPI

0.7

1 | 0.6 | 0

Dir

180

54

---

3.9

0.065

187

Amber_Light

145

145

145

Amber GPI Light

0.7

1 | 0.6 | 0

Dir

30

8

---

---

---

188

Green_Light

146

146

146

Green GPI Light

0.7

0|1|0

Dir

30

2

---

---

---

189

Red_Light

147

147

147

Red GPI Light

0.7

1|0|0

Dir

30

6

---

---

---

148

148

148

Generic Horizontal Approach Path Indicator Lights

0.8

1|1|1

Dir

80

18

---

---

---

Red_Light

149

149

149

Red HAPI Light

0.8

1|0|0

Dir

80

18

---

---

---

White_Light

150

150

150

White HAPI Light

0.8

1|1|1

Dir

80

18

---

---

---

190
191
192

HAPI

193

Homing_Beacon_Light

151

151

151

Used to identify the vessel to an approaching aircraft

0.8

1|1|1

Omni

---

---

---

---

---

194

HPI_Light

152

152

152

Horizontal Path Indicator

0.8

1|1|1

Omni

---

---

---

---

---

195

No-Go_Light

153

153

153

Abort go Light

0.8

1|1|1

Dir

180

180

---

---

---

196

Nozzle_Rotation_Light

154

154

154

Nozzle rotation Light

0.6

1|1|1

Omni

---

---

---

---

---

197

Pri-Fly_Light

455

455

455

Primary FLight control Lights

0.6

1|1|1

Omni

---

---

---

---

---

198

SGSI

155

155

155

Generic Stabilized Glide Slope Indicator (approach Light
indicator)

0.8

1 | 0.6 | 0

Dir

40

6.5

---

---

---

199

Amber_Light

156

156

156

Amber SGSI Light

0.8

1 | 0.6 | 0

Dir

40

1.5

---

---

---

200

Blue_Light

157

157

157

Blue SGSI Light

0.8

0|0|1

Dir

40

1

---

---

---

© 2015 Open Geospatial Consortium

437

Dir

40

1

---

---

---

202

Red_Light

1|0|0

Dir

40

6.5

---

---

---

203

Standby_Light

160

160

160

A means of indicating an aircraft to be at standby

0.8

1|1|1

Omni

---

---

---

---

---

204

Steady_Ship_Light

161

161

161

Steady ship Light

0.8

1|1|1

Omni

---

---

---

---

---

205

STOL

162

162

162

Generic Short Takeoff and landing Lights

0.8

1|1|1

Omni

---

---

---

---

-----

Intensity(normalized)

Duty_Cycle

0|1|0

0.8

(Hz)

Frequency

0.8

Red SGSI Light(normalized)

Intensity_Res

Green SGSI Light

159(degrees)

Width_Vert

158

159

(degrees)

Width_Hor

158

159

Description(type)

Directionality

158

201

v3.0
v3.1
Light
Light Light
Code
Code Code

Color

Green_Light

Light Hierarchy(normalized)(normalized
RGB)

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

206

Dropline_Light

163

163

163

STOL Dropline Light

0.8

1|1|1

Omni

---

---

---

---

207

Lineup_Centerline_Light

164

164

164

STOL Lineup Centerline Light

0.8

1|1|1

Omni

---

---

---

---

---

165

165

165

A means of indicating to approaching aircraft that recovery is
not permitted and should be aborted immediately.

0.8

1|1|1

Omni

---

---

---

2

0.33

Cruiser

166

166

166

Generic Cruiser Lights

0.6

1|1|1

Omni

---

---

---

---

---

210

Destroyer

167

167

167

Generic Destroyer Lights

0.6

1|1|1

Omni

---

---

---

---

---

211

Frigate

168

168

168

Generic Frigate Lights

0.6

1|1|1

Omni

---

---

---

---

---

212

Patrol

169

169

169

Generic Patrol ship Lights

0.6

1|1|1

Omni

---

---

---

---

---

213

Battleship

170

170

170

Generic Battleship Lights

0.6

1|1|1

Omni

---

---

---

---

---

214

Cargo

171

171

171

Generic Cargo Lights

0.6

1|1|1

Omni

---

---

---

---

---

Waveoff_Light

208
209

215

Subsurface

172

172

172

Generic Subsurface Vehicle Lights

0.6

1|1|1

Omni

---

---

---

---

---

216

Submarine

173

173

173

Generic Submarine Lights

0.6

1|1|1

Omni

---

---

---

---

---

174

174

174

Generic Munition Light

0.5

1|1|1

Omni

---

---

---

---

---

217

Munition

218

Tracer_Light

175

175

175

Light created by tracer fire effect in a bullet

0.5

1 | 0.6 | 0

Omni

---

---

---

---

---

219

Decoy_Flare_Light

176

176

176

Decoy flare Light

0.9

1|1|1

Omni

---

---

---

---

---

220

Distress_Flare_Light

177

177

177

Distress flare Light

0.9

1|0|0

Omni

---

---

---

---

---

221

Fireworks_Distress_Flare_Light

178

178

178

Fireworks flare Light

0.9

1|0|0

Omni

---

---

---

---

---

222

Flare_Light

179

179

179

0.9

1|1|1

Omni

---

---

---

---

---

180

180

180

0.5

1|1|1

Omni

---

---

---

---

---

181

181

181

0.7

1|1|1

Omni

---

---

---

---

---

Flashlight_Light

182

182

182

Hand held flashLight

0.5

1|1|1

Dir

45

45

---

---

---

226

Marshaller

183

183

183

Generic Marshaller Lights

0.7

1|1|1

Omni

---

---

---

---

---

227

Ground_Personel

184

184

184

GenericGround Personnel Lights

0.6

1|1|1

Omni

---

---

---

---

---

228

Survivor

185

185

185

GenericSurvivor Lights (on ground or sea)

0.7

1|1|1

Omni

---

---

---

1

0.33

186

186

186

Generic Cultural Ground base Light

0.8

1|1|1

Omni

---

---

---

---

---

187

187

Generic Point based Light

0.8

1|1|1

Omni

---

---

---

---

---

223
224
225

229

Chaff_Light

Lifeform

Cultural

Flare defensive counter measure Light effect (vs. IR guided
missile)Chaff defensive counter measure Light effect (vs. Radar
guided missiles)
Generic Lifefrom Light (regroups all Lights that could be
assigned to ainly human lifeforms)

230

Point-Based

187

231

Flood_Light

188

188

188

Lights used to illuminate the ground

0.8

1|1|1

Omni

---

---

---

---

---

232

Obstruction

189

189

189

Generic Obstruction Light - A Light indicating the presenceof an object which is dangerous to an aircraft in fLight.

0.9

1|0|0

Omni

---

---

---

---

---

233

Red

514

Generic Red Obstruction Light

0.9

1|0|0

Omni

---

---

---

0.5

0.5

515

A flashing red obstruction Light with 20-40 flashes per
minute (FAA type L-864)

0.9

1|0|0

Omni

---

---

---

0.5

0.5

516

A flashing red obstruction Light with 60 flashes per minute(FAA type L-885)

0.9

1|0|0

Omni

---

---

---

1

0.5

517

A steady-burning red obstruction Light (FAA type L-810)

0.5

1|0|0

Omni

---

---

---

---

---

518

Generic White Obstruction Light

1.0

1|1|1

Omni

---

---

---

0.66

0.1

519

A high intensity flashing white obstruction Light with 40
flashes per minute (FAA type L-856)

1.0

1|1|1

Omni

---

---

---

0.66

0.1

520

A high intensity flashing white obstruction Light with 60
flashes per minute (FAA type L-857)

1.0

1|1|1

Omni

---

---

---

1

0.1

521

A medium intensity flashing white obstruction Light with 40
flashes per minute (FAA type L-865)

0.5

1|1|1

Omni

---

---

---

0.66

0.1

522

A medium intensity flashing white obstruction Light with 60
flashes per minute (FAA type L-866)

0.5

1|1|1

Omni

---

---

---

1.0

0.1

234

Type_L864_Light

235

Type _L885_Light
Type_L810_Light

236
237

White
Type_L856_Light

238

Type_L857_Light

239

Type_L865_Light

240

Type_L866_Light

241

Strobe_Light

190

190

190

Flashing Ground Light that helps to indicate position

0.8

1|1|1

Omni

---

---

---

1

0.05

243

Communication_Tower

191

191

191

Generic Communication Tower Lights

0.8

1|1|1

Omni

---

---

---

---

---

244

FARP

192

192

192

Generic Forward Area Rearm/Refuel Point Lights

0.8

1|1|1

Omni

---

---

---

---

---

242

245

IR_Light

193

193

193

Forward Area Rearm/Refuel Point IR Light

0.8

1|1|1

Omni

---

---

---

---

---

246

Strobe_Light

194

194

194

Forward Area Rearm/Refuel Point strobe Light

0.9

1|1|1

Omni

---

---

---

1

0.05

247

Y_Light

195

195

195

Forward Area Rearm/Refuel Point Y-shaped Light

0.8

1|1|1

Omni

---

---

---

---

---

248

Harbour_Light

196

196

196

Harbour Light

0.7

1|1|1

Omni

---

---

---

---

---

249

Pylon

197

197

197

Generic Power Pylon Lights

0.8

1|1|1

Omni

---

---

---

---

---

Railroad_Junction

198

198

198

Generic Railroad Junction Lights

0.8

1|0|0

Omni

---

---

---

0.67

0.5

250

© 2015 Open Geospatial Consortium438

Duty_Cycle

---

---

---

0.67

0.5

Omni

---

---

---

---

---

Color

(normalized)

(Hz)

Omni

1|1|1

Frequency

1|0|0

0.7

(normalized)

Intensity_Res

0.8

Generic Highway Junction Lights(degrees)

Flashing Red rail road crossing stop Lights

200(degrees)

199

200

Directionality

199(normalized
RGB)

199

Description(normalized)

Width_Vert

Flashing_Red_Light

Width_Hor

251

v3.0
v3.1
Light
Light Light
Code
Code CodeIntensity

Light Hierarchy(type)

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

Highway_Junction

200

253

Bridge

201

201

201

Generic Bridge Lights

0.7

1|1|1

Omni

---

---

---

---

---

254

Hazard

202

202

202

Generic Harzard Light - A White Light indicating thepresence of an hazard around the airport

0.8

1|1|1

Omni

---

---

---

---

---

255

Flashing_Light

203

203

203

White hazard flashing Light

0.8

1|1|1

Omni

---

---

---

---

---

256

Hi_Intensity_Light

204

204

204

White Hi-Intensity hazard Light

0.9

1|1|1

Omni

---

---

---

---

---

205

205

205

Generic Line based Lights (Linear features as Roads)

0.8

1|1|1

Omni

---

---

---

---

---

257

Line-Based

258

Fluorescent_Light

206

206

206

Fluorescent based Light

0.8

1|1|1

Omni

---

---

---

---

---

259

Incandescent_Light

207

207

207

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

260

Mercury_Light

208

208

208

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

261

Metal_Halide_Light

209

209

209

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

262

Sodium_Light

210

210

210

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

263

Multilane_Divided_Hwy

211

211

211

Generic Multi-lane divided highway Lights

0.8

1|1|1

Omni

---

---

---

---

---

264

Incandescent_Light

212

212

212

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

265

Mercury_Light

213

213

213

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

266

Metal_Halide_Light

214

214

214

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

267

Sodium_Light

215

215

215

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

268

Median

216

216

216

Median divider Lights

0.8

1|1|1

Omni

---

---

---

---

---

269

Edge

217

217

217

Highway edge/sidewalk Lights

0.8

1|1|1

Omni

---

---

---

---

---

218

218

218

Generic Multi-lane highway Lights

0.8

1|1|1

Omni

---

---

---

---

---

270

Multilane_Hwy

271

Incandescent_Light

219

219

219

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

272

Mercury_Light

220

220

220

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

273

Metal_Halide_Light

221

221

221

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

274

Sodium_Light

222

222

222

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

275

Median

223

223

223

Median divider Lights

0.8

1|1|1

Omni

---

---

---

---

---

276

Edge

224

224

224

Highway edge/sidewalk Lights

0.8

1|1|1

Omni

---

---

---

---

---

Highway

225

225

225

Generic Single Lane Highway

0.8

1|1|1

Omni

---

---

---

---

---

277
278

Incandescent_Light

226

226

226

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

279

Mercury_Light

227

227

227

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

280

Metal_Halide_Light

228

228

228

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

281

Sodium_Light

229

229

229

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

230

230

230

Generic Road Lights

0.8

1|1|1

Omni

---

---

---

---

---

Incandescent_Light

231

231

231

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

284

Mercury_Light

232

232

232

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

285

Metal_Halide_Light

233

233

233

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

286

Sodium_Light

234

234

234

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

235

235

235

Generic Boulevard Lights

0.8

1|1|1

Omni

---

---

---

---

---

282
283

287

Road

Boulevard

288

Incandescent_Light

236

236

236

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

289

Mercury_Light

237

237

237

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

290

Metal_Halide_Light

238

238

238

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

Sodium_Light

239

239

239

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

240

240

240

Generic Small street Lights

0.8

1|1|1

Omni

---

---

---

---

---

291
292

Street293

Incandescent_Light

241

241

241

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

294

Mercury_Light

242

242

242

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

295

Metal_Halide_Light

243

243

243

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

296

Sodium_Light

244

244

244

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

245

245

245

Generic line based Light

0.8

1|1|1

Omni

---

---

---

---

---

246

246

246

Incandescent based Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

247

247

247

Generic Area Lights which cover a larger area

0.8

1|1|1

Omni

---

---

---

---

---

248

248

248

Fluorescent based Light

0.8

1|1|1

Omni

---

---

---

---

---

297
298
299
300

Lane
Incandescent_Light

Area-Based
Fluorescent_Light© 2015 Open Geospatial Consortium

439

Frequency

Duty_Cycle

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

Mercury based Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

303

Metal_Halide_Light

251

251

251

Metal Halide based Light

0.8

1|1|1

Omni

---

---

---

---

---

304

Sodium_Light

252

252

252

Sodium based Light

0.8

1|1|0

Omni

---

---

---

---

---

305

Residential_Area

253

253

253

Generic Residential Area based Lights

0.8

1|1|1

Omni

---

---

---

---

---

254

254

254

Generic Bright residential area Lights

0.8

1|1|1

Omni

---

---

---

---

---

255

255

Incandescent bright Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

306

BrightIntensity(normalized)

Intensity_Res

Incandescent based Light

250

(Hz)

Width_Vert

249

250

(normalized)

Width_Hor

249

250

(degrees)(type)

249

Mercury_Light(degrees)

Directionality

Incandescent_Light

302

Description(normalized
RGB)

301

v3.0
v3.1
Light
Light Light
Code
Code CodeLight Hierarchy(normalized)

Color

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

307

Incandescent_Light

255

308

Mercury_Light

256

256

256

Mercury bright Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

257

257

257

Generic Dim residential area Lights

0.7

1|1|1

Omni

---

---

---

---

---

Incandescent_Light

258

258

258

Incandescent dim Light

0.7

1 | 0.6 | 0.3

Omni

---

---

---

---

---

Mercury_Light

259

259

259

Mercury dim Light

0.7

0.9 | 0.9 | 1

Omni

---

---

---

---

---

309

Dim

310
311
312

Industrial_Area

260

260

260

Generic Industrial Area based Lights

0.8

1|1|1

Omni

---

---

---

---

---

313

Bright

261

261

261

Generic Bright industrial area Lights

0.8

1|1|1

Omni

---

---

---

---

---

262

262

Incandescent bright Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

314

Incandescent_Light

262

315

Mercury_Light

263

263

263

Mercury bright Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

264

264

264

Generic dim industrial area Lights

0.7

1|1|1

Omni

---

---

---

---

---

316

Dim

317

Incandescent_Light

265

265

265

Incandescent dim Light

0.7

1 | 0.6 | 0.3

Omni

---

---

---

---

---

318

Mercury_Light

266

266

266

Mercury dim Light

0.7

0.9 | 0.9 | 1

Omni

---

---

---

---

---

267

267

267

Generic City Downtown Area Lights

0.8

1|1|1

Omni

---

---

---

---

---

268

268

268

Generic bright downtown area Lights

0.8

1|1|1

Omni

---

---

---

---

---

269

269

Incandescent bright Light

0.8

1 | 0.6 | 0.3

Omni

---

---

---

---

---

319
320

Downtown_Area
Bright321

Incandescent_Light

269

322

Mercury_Light

270

270

270

Mercury bright Light

0.8

0.9 | 0.9 | 1

Omni

---

---

---

---

---

271

271

271

Generic dim downtown area Lights

0.7

1|1|1

Omni

---

---

---

---

---

323

Dim

324

Incandescent_Light

272

272

272

Incandescent dim Light

0.7

1 | 0.6 | 0.3

Omni

---

---

---

---

---

325

Mercury_Light

273

273

273

Mercury dim Light

0.7

0.9 | 0.9 | 1

Omni

---

---

---

---

---

274

274

274

Generic Airport Lighting

0.9

1|1|1

Omni

---

---

---

---

---

275

275

275

Generic Apron Light

0.9

1|1|1

Omni

---

---

---

---

---

276

276

Apron entrance Light from runway or taxiway

0.9

1|1|1

Omni

---

---

---

---

---

326
327

Airport_Lighting
Apron

328

Entrance_Light

276

329

Flood_Light

277

277

277

Flood Light to illuminated the Apron

0.9

1|1|1

Omni

---

---

---

---

---

278

278

278

Generic Beacon Light

0.9

1|1|1

Omni

---

---

---

0.33

0.33

279

279

279

Identification Beacon Light

0.9

1|1|1

Omni

---

---

---

0.33

0.33

523

Red UK Pundit Light where XX denotes two-letter Pundit
code. NOTE: Red Omni flashing pattern is equivalent to the
two-letter morse code for XX)

0.9

1|0|0

Omni

---

---

---

---

---

0.33

330
331

BeaconID_Beacon_Light

332

UK_Pundit_Light-XX

333

Double_White_Rotating_2sec_Light

427

427

427

Double peak White 2 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.5

334

Double_White_Rotating_3sec_Light

428

428

428

Double peak White 3 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.33

0.33

335

Double_White_Rotating_5sec_Light

429

429

429

Double peak White 5 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.2

0.33

336

Double_White_Rotating_10sec_Light

439

439

439

Double peak White 10 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.1

0.33

337

White_Rotating_2sec_Light

280

280

280

White 2 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.5

0.33

338

White_Rotating_3sec_Light

281

281

281

White 3 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.33

0.33

339

White_Rotating_5sec_Light

282

282

282

White 5 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.2

0.33

340

White_Rotating_10sec_Light

445

445

445

White 10 sec interval Rotating Beacon

0.9

1|1|1

Omni

---

---

---

0.1

0.33

341

Green_Rotating_2sec_Light

283

283

283

Green 2 sec interval Rotating Beacon

0.9

0|1|0

Omni

---

---

---

0.5

0.33

342

Green_Rotating_3sec_Light

284

284

284

Green 3 sec interval Rotating Beacon

0.9

0|1|0

Omni

---

---

---

0.33

0.33

343

Green_Rotating_5sec_Light

285

285

285

Green 5 sec interval Rotating Beacon

0.9

0|1|0

Omni

---

---

---

0.2

0.33

344

Green_Rotating_10sec_Light

440

440

440

Green 10 sec interval Rotating Beacon

0.9

0|1|0

Omni

---

---

---

0.1

0.33

345

Yellow_Rotating_2sec_Light

430

430

430

Yellow 2 sec interval Rotating Beacon

0.9

1|1|0

Omni

---

---

---

0.5

0.33

346

Yellow_Rotating_3sec_Light

431

431

431

Yellow 3 sec interval Rotating Beacon

0.9

1|1|0

Omni

---

---

---

0.33

0.33

347

Yellow_Rotating_5sec_Light

432

432

432

Yellow 5 sec interval Rotating Beacon

0.9

1|1|0

Omni

---

---

---

0.2

0.33

348

Yellow_Rotating_10sec_Light

441

441

441

Yellow 10 sec interval Rotating Beacon

0.9

1|1|0

Omni

---

---

---

0.1

0.33

349

Double_White_Flashing_2sec_Light

433

433

433

Double peak White 2 sec interval Flashing Beacon

0.9

1|1|1

Omni

---

---

---

0.5

0.33

350

Double_White_Flashing_3sec_Light

434

434

434

Double peak White 3 sec interval Flashing Beacon

0.9

1|1|1

Omni

---

---

---

0.33

0.33

© 2015 Open Geospatial Consortium440

1|1|1

Omni

---

---

---

0.2

0.33

0.9

1|1|1

Omni

---

---

---

0.1

0.33

353

White_Flashing_2sec_Light

286

286

286

White 2 sec interval Flashing Beacon

0.9

1|1|1

Omni

---

---

---

0.5

0.33

354

White_Flashing_3sec_Light

287

287

287

White 3 sec interval Flashing Beacon

0.9

1|1|1

Omni

---

---

---

0.33

0.33

355

White_Flashing_5sec_Light

288

288

288

White 5 sec interval Flashing Beacon

0.9

1|1|1

Omni

---

---

---

0.2

0.33

356

White_Flashing_10sec_Light

446

446

446

White 10 sec interval Flashing Beacon

0.9

1|1|1

Omni

---

---

---

0.1

0.33

357

Green_Flashing_2sec_Light

289

289

289

Green 2 sec interval Flashing Beacon

0.9

0|1|0

Omni

---

---

---

0.5

0.33

358

Green_Flashing_3sec_Light

290

290

290

Green 3 sec interval Flashing Beacon

0.9

0|1|0

Omni

---

---

---

0.33

0.33

359

Green_Flashing_5sec_Light

291

291

291

Green 5 sec interval Flashing Beacon

0.9

0|1|0

Omni

---

---

---

0.2

0.33

360

Green_Flashing_10sec_Light

443

443

443

Green 10 sec interval Flashing Beacon

0.9

0|1|0

Omni

---

---

---

0.1

0.33

361

Yellow_Flashing_2sec_Light

436

436

436

Yellow 2 sec interval Flashing Beacon

0.9

1|1|0

Omni

---

---

---

0.5

0.33

362

Yellow_Flashing_3sec_Light

437

437

437

Yellow 3 sec interval Flashing Beacon

0.9

1|1|0

Omni

---

---

---

0.33

0.33

363

Yellow_Flashing_5sec_Light

438

438

438

Yellow 5 sec interval Flashing Beacon

0.9

1|1|0

Omni

---

---

---

0.2

0.33

Yellow_Flashing_10sec_Light(normalized)

Color

Intensity

Duty_Cycle

0.9

Double peak White 10 sec interval Flashing Beacon(Hz)

Frequency

Double peak White 5 sec interval Flashing Beacon442(normalized)

Intensity_Res

435

442

(degrees)

Width_Vert

435

442

(degrees)

Width_Hor435

Double_White_Flashing_10sec_Light

Description

Directionality

Double_White_Flashing_5sec_Light

352

v3.0
v3.1
Light
Light Light
Code
Code Code(normalized
RGB)

351

Light Hierarchy(normalized)(type)

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

444

444

444

Yellow 10 sec interval Flashing Beacon

0.9

1|1|0

Omni

---

---

---

0.1

0.33

365

Docking_Sytem

292

292

292

Generic Docking System Light

0.9

1 | 0.6 | 0

Omni

---

---

---

---

---

366

Amber_Light

293

293

293

Amber Docking System Light

0.9

1 | 0.6 | 0

Omni

---

---

---

---

---

367

Green_Light

294

294

294

Green Docking System Light

0.9

0|1|0

Omni

---

---

---

---

---

368

Red_Light

295

295

295

Red Docking System Light

0.9

1|0|0

Omni

---

---

---

---

---

296

Generic Obstruction Light - A red Light indicating thepresence of an object which is dangerous to an aircraft inflight.

0.85

1|0|0

Omni

---

---

---

0.5

0.33

Red Obstruction flashing Light (deprecated in CDB v3.2)

0.85

1|0|0

Omni

---

---

---

0.5

0.33

364

369
370
371
372
373
374

296

296

Flashing_Light

297

297

Hi_Intensity_Light

298

298

Red Hi-Intensity obstruction Light (deprecated in CDB v3.2)

0.9

1|0|0

Omni

---

---

---

0.5

0.33

299

299

299

Generic Runway Lights

0.9

1|1|1

Omni

---

---

---

---

---

300

300

300

Generic Airport Approach Lighting Systems

0.9

1|1|1

Dir

75

75

---

---

---

301

301

301

Generic Barrette Light

0.9

1|1|1

Dir

75

75

---

---

---

Obstruction

RunwayApproach_System
Barrette

375

Red_Light

302

302

302

Red barrette Light

0.9

1|0|0

Dir

75

75

---

---

---

376

White_Light

303

303

303

White barrette Light

0.9

1|1|1

Dir

75

75

---

---

---

Green_Light

488

488

488

Green barrette Light

0.9

0|1|0

Dir

75

75

---

---

---

304

304

304

Circling Guidance Light which helps on a circling approach

0.9

1|1|1

Dir

75

75

---

---

---

305

305

305

Marking Lights that illuminate any markings that need to bevisible on the runway in low visibility

0.9

1|1|1

Omni

---

---

---

---

---

377
378

Circling_Guidance_Light

379

Landing_Marking_Light

380

Lead-in_Light

306

306

306

LDIN - lead-in Light system Lights

0.9

1|1|1

Dir

50

110

---

---

---

381

Optical_Landing_System

307

307

307

Optical landing system Lights

0.9

1|1|1

Omni

---

---

---

---

---

382

High_Intensity_Light

308

308

308

High intensity approach Light

0.9

1|1|1

Dir

75

75

---

---

---

383

Low_Intensity_Light

309

309

309

Low intensity approach Light

0.85

1|1|1

Dir

75

75

---

---

---

384

ODAL_Light

310

310

310

Omni directional approach Light

0.9

1|1|1

Omni

---

---

---

---

---

0.95

1|1|1

Dir

75

10

---

---

---

0.95

1|1|1

Dir

75

10

---

---

---

0.95

1|1|1

Dir

75

10

---

---

---

385
386
387

PAPI
APAPI_Close_Light
APAPI_Far_Light

Generic Precision approach path indicator. Provides visualglide slope indication using a single row of two or four Light
units.
Abbreviated Precision Approach Path Indicator closest to
runwayAbbreviated Precision Approach Path Indicator farthest to
runway

311

311

311

312

312

312

313

313

313

314

314

PAPI A (farthest from runway)

0.95

1|1|1

Dir

75

10

---

---

---

388

TypeA_Light

314

389

TypeB_Light

315

315

315

PAPI B (3rd from runway)

0.95

1|1|1

Dir

75

10

---

---

---

390

TypeC_Light

316

316

316

PAPI C (2rd from runway)

0.95

1|1|1

Dir

75

10

---

---

---

391

TypeD_Light

317

317

317

PAPI D (Closest from runway)

0.95

1|1|1

Dir

75

10

---

---

---

318

318

Runway alignment indicator Lights

0.9

1|1|1

Dir

75

75

---

---

0.33

RAIL_Light

318

393

REIL_Light

319

319

319

Runway End Identifier Lights

0.95

1|1|1

Dir

75

75

---

2

0.1

394

SFL

320

320

320

Generic Sequence Flashing Lights

0.9

1|1|1

Dir

75

75

---

2

0.1

321

321

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

0.1

392

395

CAT-I

321

396

CAT-II

322

322

322

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

0.1

397

CALVERT-I

323

323

323

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

0.1

398

CALVERT-II

324

324

324

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

0.1

399

ALSF-1

325

325

325

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

0.1

400

ALSF-II

326

326

326

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

0.1

© 2015 Open Geospatial Consortium

441

Dir

75

75

---

2

0.1

402

SSALR

1|1|1

Dir

75

75

---

2

0.1

403

MALSF

329

329

329

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

0.1

404

MALSR

330

330

330

Approach Lighting System with sequenced flashing

0.9

1|1|1

Dir

75

75

---

2

---

331

331

331

Generic Visual Approach Slope Indicator System (VASI)

0.9

1|1|1

Dir

75

10

---

---

---

332

332

332

Generic 2 Bar Component VASI

0.9

1|1|1

Dir

75

10

---

---

---

405
406

VASI
2Bar

Intensity(normalized)

Duty_Cycle

1|1|1

0.9

(Hz)

Frequency

0.9

Approach Lighting System with sequenced flashing(normalized)

Intensity_Res

Approach Lighting System with sequenced flashing328(degrees)

Width_Vert

327

328

(degrees)

Width_Hor

327

328

Description(type)

Directionality

327

401

v3.0
v3.1
Light
Light Light
Code
Code Code

Color

SSALF

Light Hierarchy(normalized)(normalized
RGB)

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

407

First_Light

333

333

333

2-Bar VASIS (1st bar closest to threshold)

0.9

1|1|1

Dir

75

10

---

---

---

408

Second_Light

334

334

334

2-Bar VASIS (2nd bar farthest from threshold)

0.9

1|1|1

Dir

75

10

---

---

---

335

335

335

Generic 3 Bar component VASI

0.9

1|1|1

Dir

75

10

---

---

---

409

3Bar

410

First_Light

336

336

336

3-Bar VASIS (1st bar closest to threshold)

0.9

1|1|1

Dir

75

10

---

---

---

411

Second_Light

337

337

337

3-Bar VASIS (2nd bar, In between 1st and 3rd)

0.9

1|1|1

Dir

75

10

---

---

---

412

Third_Light

338

338

338

3-Bar VASIS (3rd bar farthest from threshold)

0.9

1|1|1

Dir

75

10

---

---

---

413

LCVASI_Light

339

339

339

Low-cost VASI Light

0.9

1|1|1

Dir

75

10

---

---

---

414

TypeP_Light

340

340

340

PVASI pulsating Light

0.9

1|1|1

Dir

75

10

---

---

---

415

TypeT

341

341

341

Generic T Shaped VASI (T-VASIS)

0.9

1|1|1

Dir

75

10

---

---

---

342

342

Fly Down Lights

0.9

1|1|1

Dir

75

7

---

---

-----

416

Fly-down_Light

342

417

Wing_Bar_Light

343

343

343

T-VASIS wing bar Light

0.9

1|1|1

Dir

75

10

---

---

418

2.50_Degree

344

344

344

Generic 2.50 degree T-VASI

0.9

1|1|1

Dir

75

2.5

---

---

---

345

345

345

0.9

1|1|1

Dir

75

2.5

---

---

---

346

346

346

0.9

1|1|1

Dir

75

2.4166

---

---

---

347

347

347

0.9

1|1|1

Dir

75

2.3334

---

---

---

348

348

348

0.9

1|1|1

Dir

75

2.75

---

---

---

349

349

349

0.9

1|1|1

Dir

75

2.75

---

---

---

0.9

1|1|1

Dir

75

2.6666

---

---

---

0.9

1|1|1

Dir

75

2.5834

---

---

---

0.9

1|1|1

Dir

75

3

---

---

---

0.9

1|1|1

Dir

75

3

---

---

---

0.9

1|1|1

Dir

75

2.9166

---

---

---

0.9

1|1|1

Dir

75

2.8334

---

---

---

0.9

1|1|1

Dir

75

3.25

---

---

---

0.9

1|1|1

Dir

75

3.25

---

---

---

0.9

1|1|1

Dir

75

3.1666

---

---

---

0.9

1|1|1

Dir

75

3.0834

---

---

---

0.9

1|1|1

Dir

75

3.5

---

---

---

0.9

1|1|1

Dir

75

3.5

---

---

---

0.9

1|1|1

Dir

75

3.4166

---

---

---

0.9

1|1|1

Dir

75

3.3334

---

---

---

0.9

1|1|1

Dir

75

3.75

---

---

---

0.9

1|1|1

Dir

75

3.75

---

---

---

0.9

1|1|1

Dir

75

3.6666

---

---

---

0.9

1|1|1

Dir

75

3.5834

---

---

---

0.9

1|1|1

Dir

75

4

---

---

---

0.9

1|1|1

Dir

75

4

---

---

---

0.9

1|1|1

Dir

75

3.9166

---

---

---

0.9

1|1|1

Dir

75

3.8334

---

---

---

419

Fly-Up1_Light

420

Fly-Up2_Light
Fly-Up3_Light

421
422

2.75_Degree423

Fly-Up1_Light

424

Fly-Up2_Light

425

Fly-Up3_Light

426

3.00_Degree427

Fly-Up1_Light

428

Fly-Up2_Light
Fly-Up3_Light

429
430

3.25_Degree431

Fly-Up1_Light

432

Fly-Up2_Light
Fly-Up3_Light

433
434

3.50_Degree435

Fly-Up1_Light

436

Fly-Up2_Light

437

Fly-Up3_Light

438

3.75_Degree439

Fly-Up1_Light

440

Fly-Up2_Light
Fly-Up3_Light

441
442

4.00_Degree443

Fly-Up1_Light

444

Fly-Up2_Light

445

Fly-Up3_Light

446

Centerline

350

350

350

351

351

351

352

352

352

353

353

353

354

354

354

355

355

355

356

356

356

357

357

357

358

358

358

359

359

359

360

360

360

361

361

361

362

362

362

363

363

363

364

364

364

365

365

365

T-VASIS Fly-up 1 (closest to Wing Bar) for 2.5 degree Glideslope
T-VASIS Fly-up 2 (closest to Wing Bar) for 2.5 degree Glideslope
T-VASIS Fly-up 3 (farthest to Wing Bar) for 2.5 degree Glide
slope
Generic 2.75 degree T-VASI
T-VASIS Fly-up 1 (closest to Wing Bar) for 2.7 degree Glideslope
T-VASIS Fly-up 2 (closest to Wing Bar) for 2.7 degree Glideslope
T-VASIS Fly-up 3 (farthest to Wing Bar) for 2.7 degree Glide
slope
Generic 3.00 degree T-VASI
T-VASIS Fly-up 1 (closest to Wing Bar) for 3.0 degree Glideslope
T-VASIS Fly-up 2 (closest to Wing Bar) for 3.0 degree Glideslope
T-VASIS Fly-up 3 (farthest to Wing Bar) for 3.0 degree Glide
slope
Generic 3.25 degree T-VASI
T-VASIS Fly-up 1 (closest to Wing Bar) for 3.25 degree
Glide slope
T-VASIS Fly-up 2 (closest to Wing Bar) for 3.25 degree
Glide slope
T-VASIS Fly-up 3 (farthest to Wing Bar) for 3.25 degree
Glide slope
Generic 3.5 degree T-VASI
T-VASIS Fly-up 1 (closest to Wing Bar) for 3.5 degree Glideslope
T-VASIS Fly-up 2 (closest to Wing Bar) for 3.5 degree Glideslope
T-VASIS Fly-up 3 (farthest to Wing Bar) for 3.5 degree Glide
slope
Generic 3.75 degree T-VASI
T-VASIS Fly-up 1 (closest to Wing Bar) for 3.75 degree
Glide slope
T-VASIS Fly-up 2 (closest to Wing Bar) for 3.75 degree
Glide slope
T-VASIS Fly-up 3 (farthest to Wing Bar) for 3.75 degree
Glide slope

366

366

366

367

367

367

368

368

368

369

369

369

370

370

370

371

371

371

372

372

372

Generic runway centerline Light

0.9

1|1|1

Bi-Dir

75

75

---

---

---

Dir

75

75

---

---

---

Generic 4.00 degree T-VASI
T-VASIS Fly-up 1 (closest to Wing Bar) for 4.0 degree Glideslope
T-VASIS Fly-up 2 (closest to Wing Bar) for 4.0 degree Glideslope
T-VASIS Fly-up 3 (farthest to Wing Bar) for 4.0 degree Glide
slope

447

Red_Light

373

373

373

Unidirectional Red runway centerline Light

0.9

1|0|0

448

White_Light

374

374

374

Unidirectional White runway centerline Light

0.9

1|1|1

Dir

75

75

---

---

---

449

White_White_Light

375

375

375

Bidirectional White runway centerline Light

0.9

1|1|1

Bi-Dir

75

75

---

---

---

450

White_Red_Light

376

376

376

Bidirectional White/Red runway centerline Light

0.9

1|1|1

Bi-Dir

75

75

---

---

---

© 2015 Open Geospatial Consortium

442

451
452

(normalized)

Duty_Cycle(Hz)

Frequency(normalized)

Intensity_Res(degrees)

Width_Vert(degrees)

Width_Hor(type)

Directionality(normalized
RGB)

511

511

Bidirectional Red runway centerline Light

0.9

1|0|0

Bi-Dir

75

75

---

---

---

377

377

377

Generic Runway Edge Lights

0.9

1|1|1

Bi-Dir

180

180

---

---

---

Red_Red_Light
Edge

Description

Color

v3.0
v3.1
Light
Light Light
Code
Code CodeIntensity

Light Hierarchy(normalized)

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

453

White_Light

378

378

378

Unidirectional White Edge Light

0.9

1|1|1

Dir

180

180

---

---

---

454

Amber_Light

379

379

379

Unidirectional Amber Edge Light

0.9

1 | 0.6 | 0

Dir

180

180

---

---

---

455

Red_Light

380

380

380

Unidirectional Red Edge Light

0.9

1|0|0

Dir

180

180

---

---

---

456

Blue_Light

381

381

381

Unidirectional Blue Edge Light

0.9

0|0|1

Dir

180

180

---

---

---

457

White_White_Light

382

382

382

Bidirectional White Edge Light

0.9

1|1|1

Bi-Dir

180

180

---

---

---

458

White_Amber_Light

383

383

383

White-Amber Edge Light

0.9

1|1|1

Bi-Dir

180

180

---

---

---

459

White_Red_Light

384

384

384

White-Red Edge Light

0.9

1|1|1

Bi-Dir

180

180

---

---

---

460

White_Blue_Light

385

385

385

White-Blue Edge Light

0.9

1|1|1

Bi-Dir

180

180

---

---

---

461

Amber_Amber_Light

386

386

386

Bidirectional Amber Edge Light

0.9

1 | 0.6 | 0

Bi-Dir

180

180

---

---

---

462

Amber_Red_Light

387

387

387

Amber-Red Edge Light

0.9

1 | 0.6 | 0

Bi-Dir

180

180

---

---

---

463

Amber_Blue_Light

388

388

388

Amber-Blue Edge Light

0.9

1 | 0.6 | 0

Bi-Dir

180

180

---

---

---

464

Blue_Red_Light

389

389

389

Blue-Red Edge Light

0.9

0|0|1

Bi-Dir

180

180

---

---

---

465

Red_Red_Light

390

390

390

Bidirectional Red Edge Light

0.9

1|0|0

Bi-Dir

180

180

---

---

---

Blue_Blue_Light

391

391

391

Bidirectional Blue Edge Light

0.9

0|0|1

Bi-Dir

180

180

---

---

---

Dir

180

180

---

---

-----

466
467

End_Wing_Light

392

392

392

Runway End Wing Lights

0.9

1|0|0

468

End_Light

393

393

393

Runway End Lights

0.9

1|0|0

Dir

180

180

---

---

469

Flood_Light

394

394

394

Runway flood Lights

0.9

1|1|1

Omni

---

---

---

---

---

470

Overrun

395

395

395

Generic Overun Light - A Light which indicated runway overrun area

0.9

1 | 0.6 | 0

Dir

150

90

---

---

---

471

Amber_Light

396

396

396

Amber overrun Light

0.9

1 | 0.6 | 0

Dir

150

90

---

---

---

472

Blue_Light

397

397

397

Blue overrun Light

0.9

0|0|1

Dir

150

90

---

---

---

Red_Light

398

398

398

Red overrun Light

0.9

1|0|0

Dir

150

90

---

---

---

399

399

399

Threshold wing Lights

0.9

0|1|0

Dir

180

180

---

---

---

400

400

400

0.9

0|1|0

Dir

180

180

---

---

---

401

401

401

402

402

402

473
474

Threshold_Wing_Light

475

Threshold_Light

476

Touchdown_Zone_Light

477
478

LAHSO_Light
Taxiway

Runway threshold Lights: used to identify the landing
threshold of the runway
Touchdown Zone Lights: used to identify the appropriate
landing area on the runway after the threshold
Land and hold Short Operations Light: runway intersecting
stop Lights

0.9

1|1|1

Dir

180

180

---

---

---

0.9

1 | 0.6 | 0

Omni

---

---

---

---

---

403

403

403

Generic Airport Taxiway Lights

0.9

0|0|1

Omni

---

---

---

---

---

404

404

404

Apron Entrance Light which indication area where taxi entersapron area

0.9

0|0|1

Omni

---

---

---

---

---

479

Apron_Entrance_Light

480

CAT-III_Hold_Bar_Light

405

405

405

Category III Hold bar Light

0.9

0|1|0

Dir

180

180

---

---

---

481

Centerline

406

406

406

Generic Centerline Taxiway Lights

0.9

0|1|0

Dir

90

110

---

---

---

Aligned_Light

407

407

407

ALighted Light for a straight sequence of a taxiway

0.9

0|1|0

Dir

90

110

---

---

---

Curved_Light

408

408

408

Curved Lights for a curved sequence of a taxiway

0.9

0|1|0

Dir

50

110

---

---

---

409

409

409

Generic Taxiway edge Lights

0.9

0|0|1

Omni

---

---

---

---

---

482
483
484

Edge

485

Blue_Light

425

425

425

Blue Taxi edge Light

0.9

0|0|1

Omni

---

---

---

---

---

486

White_Light

426

426

426

White Taxi edge Light

0.9

1|1|1

Omni

---

---

---

---

---

410

410

410

Generic Taxiway high speed area Lights

0.9

1 | 0.6 | 0

Dir

50

110

---

---

---

487

High-speed

488

Amber_Light

411

411

411

Amber high-speed Lights

0.9

1 | 0.6 | 0

Dir

50

110

---

---

---

489

Green_Light

412

412

412

Green high-speed Lights

0.9

0|1|0

Dir

50

110

---

---

---

413

413

413

Generic Lead-On Light

0.9

0|1|0

Omni

---

---

---

---

---

490

Lead-on491

Green_Light

489

489

Green Lead-On Light

0.9

0|1|0

Omni

---

---

---

---

---

492

Yellow_Light

490

490

Yellow Lead-On Light

0.9

1|1|0

Omni

---

---

---

---

---

491

491

Generic Lead-Off Light

0.9

0|1|0

Omni

---

---

---

---

---

493

Lead-off

494

Green_Light

492

492

Green Lead-Off Light

0.9

0|1|0

Omni

---

---

---

---

---

495

Yellow_Light

493

493

Yellow Lead-Off Light

0.9

1|1|0

Omni

---

---

---

---

---

496

No-entry_Light

414

414

414

No entry zone Lights

0.9

1|0|0

Omni

---

---

---

---

---

497

Runway_Guard

415

415

415

Runway guard Lights

0.9

1|1|1

Omni

---

---

---

---

---

498

Stop_Bar_Light

416

416

416

Stop Bar Lights

0.9

1|0|0

Dir

180

180

---

---

---

499

Clearance

417

417

417

0.9

1|1|0

Dir

---

---

---

---

---

0.9

0|1|0

Dir

7

7

---

---

---

500

Unidirectional_Light

512

Generic Clearance bar Light. They are located at "hold short"positions on taxiways in order to increase the visibility of
Unidirectional Taxiway Clearance Light (used when the holdis intended for one direction only)© 2015 Open Geospatial Consortium

443

Guard418

418

Bidirectional Taxiway Clearance Light (used when the hold isintended for two directions)
Generic RGL (Runway Guard Light) is used to enhance thevisibility of taxiway holding positions on an airport

---

---

---

(degrees)(type)

Color(normalized)

---

---

(Hz)

---

---

(normalized)

7---(degrees)

7

Omni

Width_Hor

Dir

1|1|1

Directionality

1|1|0

0.9

(normalized
RGB)

0.9

(normalized)

Duty_Cycle

418

Frequency

502

513

Bidirectional_Light

Description

Intensity_Res

501

v3.0 v3.1
Light
Light Light
Code
Code CodeIntensity

Light Hierarchy

Width_Vert

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

(deprecated in CDB v3.1)

0.9

1|1|1

Omni

---

---

---

---

---

503

Type1_Light

419

504

Type2_Light420(deprecated in CDB v3.1)

0.9

1|1|1

Omni

---

---

---

---

---

505

Type3_Light

421(deprecated in CDB v3.1)

0.9

1|1|1

Omni

---

---

---

---

---

506

Type4_Light

422(deprecated in CDB v3.1)

0.9

1|1|1

Omni

---

---

---

---

-----

507

Wind_Indicator_Light

508

Windsock_Light

509

Heliport

423

423

423

Wind indicator Light

0.9

1|1|1

Omni

---

---

---

---

424

424

424

Windsock Light used to illuminate the windsock in poor
visibility

0.9

1|1|1

Omni

---

---

---

---

---

457

457

457

Generic Heliport Lights

0.9

0|0|1

Omni

---

---

---

---

-----

458

458

458

Generic Heliport Approach System Lights

0.9

0|1|0

Dir

90

110

---

---

Landing_Marking

460

460

460

Generic Landing Marking Light on Heliport Approach
System

0.9

1|1|1

Dir

75

10

---

---

---

512

Amber_Light

465

465

465

Heliport Approach Landing Marking Amber Light

0.9

1|1|1

Dir

75

10

---

---

---

513

Green_Light

463

463

463

Heliport Approach Landing Marking Green Light

0.9

1|1|1

Dir

75

10

---

---

---

514

Red_Light

464

464

464

Heliport Approach Landing Marking Red Light

0.9

1|1|1

Dir

75

10

---

---

---

459

459

459

Generic Heliport Edge Lights

0.9

0|0|1

Omni

---

---

---

---

---

510

Approach_System

511

515

Edge

516

White_White_Light

462

462

462

White White Heliport Edge Light

0.9

0|0|1

Omni

---

---

---

---

---

517

White_Light

461

461

461

White Heliport Edge Light

0.9

1|1|1

Omni

---

---

---

---

---

© 2015 Open Geospatial Consortium

444

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

Appendix F
F. CDB Model Components
Model components represent concrete parts found on 3D models whether the model is used as amoving model or a cultural feature. This appendix constitutes a data dictionary of names thatcan be used for zone names, as defined in chapter 6. Note that names are independent fromsimulation models and client devices since they represent real and tangible objects orcomponents found on 3D models. The XML file containing the CDB Model Components is partof the CDB Specification Distribution Package and can be found in the following file:\CDB\Metadata\Model_Components.xml

Note: As of CDB Specification 3.2, the list of CDB model components is no longer presented
here to avoid the risk of miscorrelation between the appendix and the metadata. The list is now
exclusively found in the Metadata folder.

© 2015 Open Geospatial Consortium

445

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

Appendix G
G. Gamma Tutorial
G.1
Introduction9
There is nominally no gamma correction done to the stored samples of CDB imagery files. As aresult, a gamma of 1/2.2 should be applied to imagery data when viewing it through a (sRGBcalibrated) monitor with gamma of 2.2. The CDB specification recommends the sRGB IEC
61966-2 standard when performing the calibration of displays (at DBGF or a simulator). The
sRGB standard provides the necessary guidelines for the handling of gamma, and of color (in adevice-independent fashion) under specified viewing conditions.

It would be convenient for graphics programmers if all of the components of an imaging systemwere linear. The voltage coming from an electronic camera would be directly proportional to theintensity (power) of light in the scene; the light emitted by a CRT would be directly proportional
to its input voltage, and so on. However, real-world devices do not behave in this way.

Real imaging systems will have several components, and more than one of these can be
nonlinear. If all of the components have transfer characteristics that are power functions, then
the transfer function of the entire system is also a power function. The exponent (gamma) of thewhole system's transfer function is just the product of all of the individual exponents (gammas)of the separate stages in the system. Also, stages that are linear pose no problem, since a powerfunction with an exponent of 1.0 is really a linear function. So a linear transfer function is just a
special case of a power function, with a gamma of 1.0. Thus, as long as our imaging system
contains only stages with linear and power-law transfer functions, we can meaningfully talkabout the gamma of the entire system. This is indeed the case with most real imaging systems.

If the overall gamma of an imaging system is 1.0, its output is linearly proportional to its input.
This means that the ratio between the intensities of any two areas in the reproduced image willbe the same as it was in the original scene. It might seem that this should always be the goal of
an imaging system: to accurately reproduce the tones of the original scene. Alas, that is not thecase.

When the reproduced image is to be viewed in “bright surround” conditions, where other white
objects nearby in the room have about the same brightness as white in the image, then an overall
gamma of 1.0 does indeed give real-looking reproduction of a natural scene. Photographic prints
9

Graphics Specification (see http://www.w3.org/TR/PNG-GammaAppendix )© 2015 Open Geospatial Consortium

447

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
viewed under room light and computer displays in bright room light are typical “bright surround”
viewing conditions.

However, sometimes images are intended to be viewed in “dark surround” conditions, where theroom is substantially black except for the image. This is typical of the way movies and slides(transparencies) are viewed by projection. Under these circumstances, an accurate reproductionof the original scene results in an image that human viewers judge as “flat” and lacking incontrast. It turns out that the projected image needs to have a gamma of about 1.5 relative to theoriginal scene for viewers to judge it “natural”. Thus, slide film is designed to have a gamma of
about 1.5, not 1.0.
There is also an intermediate condition called “dim surround”, where the rest of the room is stillvisible to the viewer, but is noticeably darker than the reproduced image itself. This is typical of
television viewing, at least in the evening, as well as subdued-light computer work areas. In dim
surround conditions, the reproduced image needs to have a gamma of about 1.25 relative to theoriginal scene in order to look natural.

The requirement for boosted contrast (gamma) in dark surround conditions is due to the way thehuman visual system works, and applies equally well to computer monitors. Thus, a modeler
trying to achieve the maximum realism for the images it displays really needs to know what theroom lighting conditions are, and adjust the gamma of the displayed image accordingly.

If asking the user about room lighting conditions is inappropriate or too difficult, it is reasonable
to assume that the overall gamma (viewing_gamma as defined below) is somewhere between 1.0
and 1.25. That's all that most systems that implement gamma correction do.

According to PNG (Portable Network Graphics) Specification Version 1.0, W3C
Recommendation 01-October-1996 Appendix, Gamma Tutorial,(http://www.w3.org/TR/PNG-GammaAppendix ):“All display systems, almost all photographic film, and many electronic cameras have nonlinear
signal-to-light-intensity or intensity-to-signal characteristics. Fortunately, all of these nonlinear
devices have a transfer function that is approximated fairly well by a single type of mathematical
function: a power function. This power function has the general equation© 2015 Open Geospatial Consortium

448

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
output = input ^ gamma

where ^ denotes exponentiation, and “gamma” (often printed using the Greek letter gamma, thus
the name) is simply the exponent of the power function.

By convention, “input” and “output” are both scaled to the range [0..1], with 0 representing blackand 1 representing maximum white. Normalized in this way, the power function is completely
described by a single number, the exponent “gamma”.

So, given a particular device, we can measure its output as a function of its input, fit a powerfunction to this measured transfer function, extract the exponent, and call it gamma10. We often
say “this device has a gamma of 2.5” as a shorthand for “this device has a power-law responsewith an exponent of 2.5”. We can also talk about the gamma of a mathematical transform, or ofa lookup table in a frame buffer, so long as the input and output of the thing are related by thepower-law expression above.

Real imaging systems will have several components, and more than one of these can be
nonlinear. If all of the components have transfer characteristics that are power functions, then
the transfer function of the entire system is also a power function. The exponent (gamma) of thewhole system's transfer function is just the product of all of the individual exponents (gammas)of the separate stages in the system.

Also, stages that are linear pose no problem, since a power function with an exponent of 1.0 isreally a linear function. So a linear transfer function is just a special case of a power function,with a gamma of 1.0.

10

Gamma refers to the measured transfer function that represents the non-linear response of the device. CRT
devices have traditionally dominated the computer graphics/television industry and have an exponential
response; as a result, the “gamma” of a device is often represented as a single value representing the “best-fit”
exponent of power-law response of the device. A more accurate and general approach to gamma involves alook-up table which captures the (arbitrary) response of the device.

© 2015 Open Geospatial Consortium

449

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Thus, as long as our imaging system contains only stages with linear and power-law transfer
functions, we can meaningfully talk about the gamma of the entire system. This is indeed thecase with most real imaging systems.”11

In an ideal world, sample values would be stored in floating point, there would be lots ofprecision, and it wouldn't really matter much. But in reality, we're always trying to store images
in as few bits as we can.

If we decide to use samples that are linearly proportional to intensity, and do the gamma
correction in the frame buffer LUT, it turns out that we need to use at least 12-16 bits for each ofred, green, and blue to have enough precision in intensity. With any less than that, we will
sometimes see “contour bands” or “Mach bands” in the darker areas of the image, where two
adjacent sample values are still far enough apart in intensity for the difference to be visible.

However, through an interesting coincidence, the human eye's subjective perception ofbrightness is related to the physical stimulation of light intensity in a manner that is very much
like the power function used for gamma correction. If we apply gamma correction to measured(or calculated) light intensity before quantizing to an integer for storage in a frame buffer, we canget away with using many fewer bits to store the image. In fact, 8 bits per color is almost always
sufficient to avoid contouring artifacts. This is because, since gamma correction is so closely
related to human perception, we are assigning our 256 available sample codes to intensity values
in a manner that approximates how visible those intensity changes are to the eye. Compared to alinear-sample image, we allocate fewer sample values to brighter parts of the tonal range andmore sample values to the darker portions of the tonal range.

Thus, for the same apparent image quality, images using gamma-encoded sample values need
only about two-thirds as many bits of storage as images using linear samples.

If we consider a pipeline that involves capturing (or calculating) an image, storing it in an image
file, reading the file, and displaying the image on some sort of display screen, there are at least 5

11

Copyright © 1994-2004 W3C® (MIT, ERCIM, Keio)© 2015 Open Geospatial Consortium

450

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
places in the pipeline that could have nonlinear transfer functions. Let's give each a specificname for their characteristic gamma12:(1)

Camera_gamma ( γ c ):The characteristic of the image sensor.

(2)

Encoding_gamma ( γ e ): The gamma of any transformation performed by thesoftware writing the image file.

(3)

Decoding_gamma ( γ d ): The gamma of any transformation performed by any
software reading the image file.

(4)

LUT_gamma ( γ lut ):The gamma of the frame buffer LUT, if present.

(5)

CRT_gamma ( γ crt ):The gamma of the device, i.e. the nonlinear signalto-light-intensity or intensity-to-signal characteristics. For CRT-based devices, this is generally
2.5.

In addition, let's add a few other names:(1)

File_gamma ( γ f ):The gamma of the image in the file, relative to theoriginal scene, i.e. γ f = γ cγ e

(2)

12

DS_gamma ( γ DS ):The gamma of the “display system” downstream of
the frame buffer. In this context, the term display
system encompasses everything after the frame
buffer, that is γ DS = γ lutγ CRT

These definitions have been kindly provided by the World Wide Web Consortium and are included in the
PNG file format specification available at http://www.w3.org/pub/WWW/TR/REC-png-multi.html.

© 2015 Open Geospatial Consortium

451

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

Viewing_gamma ( γ v ):The overall gamma that we want to obtain to
produce pleasing images generally 1.0 to 1.25.

When the file_gamma is not 1.0, we know that some form of gamma correction has been doneon the sample values in the file, and we call them “gamma corrected” samples. However, since
there can be so many different values of gamma in the image display chain, and some of them
are not known at the time the image is written, the samples are not really being “corrected” for a
specific display condition. We are really using a power function in the process of encoding an
intensity range into a small integer field, and so it is more correct to say “gamma encoded”
samples instead of “gamma corrected” samples. The CDB specification does not rely on suchgamma encoding in order to achieve smaller integer number representations. Instead, the CDB
specification relies on standard compression algorithms to achieve an efficient representation ofcolor imagery.13

When displaying an image file on the simulator, the image-decoding software is responsible formaking the overall gamma of the system equal to the desired viewing_gamma, by selecting thedecoding_gamma appropriately. If the viewing condition is different from the specification, thenthe decoding process must compensate. This can be done by modifying the gamma values inequation G-1 below by the appropriate factor. If one does modify the gamma values in equation
G-1 below, extreme care must be taken to avoid quantization errors when working with 24 bit
images. The display_gamma should be measured (and known) for the display rendering theimage (either at the DB generation workstation or the simulator). The correct viewing_gamma
depends on lighting conditions, and that will generally have to come from the user. In dimly lit
office environments, the generally preferred value for viewing gamma is in the vicinity of
1.12514. In many digital video systems, camera_gamma is about 0.5. CRT_gamma is typically
2.2, while encoding_gamma, decoding_gamma, and LUT_gamma are all 1.0. As a result,viewing_gamma ends up being about 1.125. Coincidently, this happens to be the optimal
viewing gamma for an ambient luminance level of 64 lux or 5 ft-lbt.

γ cγ d γ DS = γ v(eq. G-1)

13

The JPEG-2000 standard is based on the sRGB default color space per the IEC 61966-2-1 Standard whichcalls for a gamma 2.2 under the specified viewing conditions

14

Historically, viewing gammas of 1.5 have been used for viewing projected slides in a dark room andviewing gammas of 1.25 have been used for viewing monitors in a very dim room. This very dim room value of
1.25 has been used extensively in television systems and assumes a ambient luminance level of approximately 15
lux (or 1.4 ft-lb). The current proposal assumes an encoding ambient luminance level of 64 lux (or 5. ft-lb) which
is more representative of a dim room in viewing computer generated imagery or a FAA level-D approved flight
simulator visual system. Such a system assumes a viewing gamma of 1.125 and is thus consistent with the ITU-R
BT.709 standard.

© 2015 Open Geospatial Consortium

452

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

γ cγ d γ lutγ crt = γ v
0.511 × 1.0 × 1.0 × 2.2 = 1.125 = γ v

In a complex system such as a flight simulator, the system architect must beaware of the gamma at every stage of the system, starting from the source of theimagery (e.g. camera or satellite) right through to the simulator’s display device.
His objective is to ensure that product of all gammas match the viewing gamma of
the simulator.

Given the above assumptions, and our objective of ensuring that the product of all gammas in theviewing chain equals the viewing gamma, the modeler will end up (subjectively) adjusting
images to an equivalent file gamma of 1.25.

The bottom portion of the illustration show the path taken by the CDB imagery as it is ingested
first by the real-time publisher, then by the IG, the IG color look-up tables and finally through tothe visual display system. In this example, we will assume the following:
1. The imagery file in the CDB is unmodified (i.e. those produced by the Adobe
Photoshop at the DBGF). Note that as a result of viewing gamma of
γ v = 1.25 , the file gamma ended up at γ f = 1.25 at the DBGF. As a result,
the CDB also has a file gamma of γ f = 1.25
2. The IG performs all of its internal operations in a linear color space (i.e. theIG_gamma is γ IG = 1.00 )3. The simulator visual system produces an average scene brightness ofapproximately 6 ft-lamberts: under these viewing conditions, the viewing
gamma is γ v = 1.125 .
4. The measured gamma of the visual display system is γ crt = 2.025
5. The content of the IG’s color look-up tables is adjusted to compensate for the
gamma of the visual display system, i.e. it is loaded with γ lut = 1

2.025

Given the above assumptions, and our objective of ensuring that the product of all gammas in the
chain equals the viewing gamma of 1.125, the required visual run-time publisher gamma mustaccount for the difference in viewing gamma at the DBGF and at the simulator. As a result, thepublisher gamma must be (1.125/1.25).

© 2015 Open Geospatial Consortium

453

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
G.2
Harmonization of Gamma at DBGF with Gamma of Simulator Visual System
Both the modelers and the visual system architects should be keenly aware of the handling of
gamma at the Database Generation Facility and at the simulator. Figure G-1: Typical Handlingof Gamma at DBGF and Simulator, illustrates the typical handling of gamma in both of thesecases.

The top portion of the illustration shows the path taken by source data as a modeler is viewing itat this workstation via the application software. In this example, we will assume the following:
1. The DBGF imagery application is Adobe Photoshop. The default color space
profile used by Adobe Photoshop (i.e. the *.icm file) is the sRGB Color Space
Profile which is defined by the sRGB standard to be a gamma of 2.2, therefore
the Photoshop uses a γ lut = 1 / 2.2
2. The DBGF workstation is running Windows (therefore the O/S does not
gammatize the imagery before sending it to the display, γ d = 1.25 )3. The measure gamma of the DBGF workstation monitor is γ CRT = 2.2
4. The DBGF workstation is located in a dimly lit room, so the viewing gamma
is in effect γ v = 1.25

© 2015 Open Geospatial Consortium

454

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

Figure G-1: Typical Handling of Gamma at DBGF and Simulator

G.3
Handling of Color
The default CDB specification color space follows the same convention as the Windows sRGB
Color Space Profile. sRGB is the default color space in Windows, based on the IEC 61966-2-1
Standard. A sRGB compliant device does not have to provide a profile or other support for color
management to work well.

Nonetheless, whether calibrated or not to the IEC Standard, all variants of RGB are typicallyclose enough that undemanding viewers can get by with simply displaying the data without color
correction. By storing calibrated RGB, the CDB standard retains compatibility with existing
database tools and software programs that expect RGB data, yet provides enough information forconversion to XYZ in applications that need precise colors. Thus, the CDB specification gets thebest of both worlds.
Full compliance to the CDB specification requires adherence to the color space described in thissection; however, in virtually all cases, direct use of un-calibrated RGB is sufficient. The
builders of Synthetic Environment Databases and the users of Visual Systems should be aware of© 2015 Open Geospatial Consortium

455

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
these color space conventions; significant deviation from the underlying IEC assumptions may
yield significant color differences.

The CDB specification encoded RGB color tri-stimulus values assume the following:(1)

Display luminance level: 80 cd/m2(2)

Display white point x = 0.3127, y = 0.3291 (D65)(3)

Display model Offset (R, G and B): 0.055(4)

Display Gun/Phosphor Gamma (R, G, and B): 2.2

Table G-1: CIE Chromaticity for CDB Reference Primaries & CIE Standard
Illuminant
Red

Green

Blue

D65 (white)X

0.64000.30000.15000.3127Y

0.33000.60000.06000.3291Z

0.03000.10000.79000.3583

According to PNG (Portable Network Graphics) Specification Version 1.0, W3C
Recommendation 01-October-1996 Appendix, Color Tutorial,(http://www.w3.org/TR/PNG-GammaAppendix):“The color of an object depends not only on the precise spectrum of light emitted or reflectedfrom it, but also on the observer, their species, what else they can see at the same time, evenwhat they have recently looked at. Furthermore, two very different spectra can produce exactly
the same color sensation. Color is not an objective property of real-world objects; it is asubjective, biological sensation. However, by making some simplifying assumptions (such as:
we are talking about human vision) it is possible to produce a mathematical model of color andthereby obtain good color accuracy.

© 2015 Open Geospatial Consortium

456

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
G.3.1
Device-dependent Color
Display the same RGB data on three different monitors, side by side, and you will get a
noticeably different color balance on each display. This is because each monitor emits a slightly
different shade and intensity of red, green, and blue light. RGB is an example of a devicedependent color model; the color you get depends on the device. This also means that a
particular color represented as say RGB 87, 146, 116 on one monitor might have to be specified
as RGB 98, 123, 104 on another to produce the same color.
G.3.2
Device-independent color
A full physical description of a color would require specifying the exact spectral power
distribution of the light source. Fortunately, the human eye and brain are not so sensitive as torequire exact reproduction of a spectrum. Mathematical, device-independent color models exist
that describe fairly well how a particular color will be seen by humans. The most importantdevice-independent color model, to which all others can be related, was developed by theInternational Commission on Illumination in 1931 (CIE-1931, in French) and is called “CIEXYZ” or simply “XYZ”.

In XYZ, X is the sum of a weighted power distribution over the whole visible spectrum. So are
Y and Z, each with different weights. Thus any arbitrary spectral power distribution iscondensed down to just three floating-point numbers. The weights were derived from color
matching experiments done on human subjects in the 1920s. CIE XYZ has been an International
Standard since 1931, and it has a number of useful properties:(1)

Two colors with the same XYZ values will look the same to humans(2)

Two colors with different XYZ values will not look the same

(3)

The Y value represents all the brightness information (luminance)(4)

The XYZ color of any object can be objectively measured

Color models based on XYZ have been used for many years by people who need accurate
control of color i.e., lighting engineers for film and TV, paint and dyestuffs manufacturers, andso on. They are thus proven in industrial use. Accurate, device-independent color started tospread from high-end, specialized areas into the mainstream during the late 1980s and early
1990s, and CDB takes notice of that trend.

© 2015 Open Geospatial Consortium

457

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
G.4
Calibrated, Device-Dependent Color
Traditionally, image file formats have used uncalibrated, device-dependent color. If the precise
details of the original display device are known, it becomes possible to convert the devicedependent colors of a particular image to device-independent ones. Making simplifying
assumptions, such as working with CRTs (which are much easier than printers), all we need toknow are the XYZ values of each primary color and the CRT exponent.

So why does not the CDB specification store images in XYZ instead of RGB? Well, tworeasons. First, storing images in XYZ would require more bits of precision, which would makethe files bigger. Second, all programs would have to convert the image data before viewing it.
But more importantly, whether calibrated or not, all variants of RGB are close enough that
undemanding viewers can get by with simply displaying the data without color correction. By
storing calibrated RGB, the CDB specification retains compatibility with existing database tools
and software programs that expect RGB data, yet provides enough information for conversion to
XYZ in applications that need precise colors. Thus, we get the best of both worlds.
G.5
What are chromaticity and luminance?
Chromaticity is an objective measurement of the color of an object, leaving aside the brightness
information. Chromaticity uses two parameters x and y, which are readily calculated from XYZ:

x = X / (X + Y + Z)
y = Y / (X + Y + Z)

(eq. G-3)

XYZ colors having the same chromaticity values will appear to have the same hue but can varyin absolute brightness. Notice that x,y are dimensionless ratios, so they have the same values nomatter what units we've used for X,Y,Z.

The Y value of an XYZ color is directly proportional to its absolute brightness and is called theluminance of the color. We can describe a color either by XYZ coordinates or by chromaticity
x,y plus luminance Y. The XYZ form has the advantage that it is linearly related to RGB
intensities.
G.6
How are computer monitor colors described?
The “white point” of a display device is the chromaticity x,y of the monitor's nominal white, thatis, the color produced when R = G = B = maximum.

© 2015 Open Geospatial Consortium

458

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
It's customary to specify CRT monitor colors by giving the chromaticities of the individual
phosphors R, G, and B, plus the white point. The white point allows one to infer the relative
brightness of the three phosphors, which isn't determined by their chromaticities alone.

NOTE:

The absolute brightness of the monitor is not specified. For computer
graphics work, we generally don't care very much about absolutebrightness levels. Instead of dealing with absolute XYZ values (in which
X,Y,Z are expressed in physical units of radiated power, such as candelas
per square meter), it is convenient to work in “relative XYZ” units, where
the monitor's nominal white is taken to have a luminance (Y) of 1.0.
Given this assumption, it's simple to compute XYZ coordinates for themonitor's white, red, green, and blue from their chromaticity values.

G.7
How do I convert from source_RGB to XYZMake a few simplifying assumptions first, like the monitor really is jet black with no input andthe guns don't interfere with one another. Then, given that you know theCIE XYZ values for each of red, green, and blue for a particular monitor, you put them into amatrix M:⎡ Xr
M = ⎢⎢ Yr⎢⎣ Zr

Xg
Yg
Zg

Xb⎤
Yb ⎥⎥Zb ⎥⎦(eq. G-4)

RGB intensity samples normalized to the range zero to one can be converted to XYZ by matrix
multiplication.

NOTE:

If you the RGB samples are gamma-encoded, the gamma encoding must
be un-done.

⎡ X ⎤⎡ R ⎤⎢ Y ⎥ = M ⎢G ⎥
⎢ ⎥
⎢ ⎥
⎢⎣ Z ⎥⎦⎢⎣ B ⎥⎦

© 2015 Open Geospatial Consortium(eq. G-5)

459

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

In other words, X = Xr*R + Xg*G + Xb*B, and similarly for Y and Z. You can go the otherway too:⎡ R ⎤⎡ X ⎤ ⎡ 3.2410 − 1.5374 − 0.4986⎤ ⎡ X ⎤⎢G ⎥ = M −1 ⎢ Y ⎥ = ⎢− 0.9692 1.8760
0.0416 ⎥ ⎢ Y ⎥⎢ ⎥⎢ ⎥ ⎢⎥ ⎢ ⎥⎣⎢ B ⎦⎥⎣⎢ Z ⎦⎥ ⎣⎢ 0.0556 − 0.2040 1.0570 ⎦⎥ ⎣⎢ Z ⎦⎥

Where

M-1=

(eq. G-6)

The inverse of the matrix M used to go from XYZ-1931 color
space to the CDB specification RGB color space.

In the RGB encoding process, negative sRGB tri-stimulus values, and sRGB tri-stimulus values
greater than 1,00 are not retained. When encoding software cannot support this extended range,
the luminance dynamic range and color gamut of RGB is limited to the tri-stimulus values
between 0,0 and 1,0 by simple clipping.

According to PNG (Portable Network Graphics) Specification Version 1.0, W3C
Recommendation 01-October-1996 Appendix, Color Tutorial,(http://www.w3.org/TR/PNG-GammaAppendix):“The gamut of a device is the subset of visible colors that the device can display.
(Note that this has nothing to do with gamma.) The gamut of an RGB device canbe visualized as a polyhedron in XYZ space; the vertices correspond to thedevice's black, blue, red, green, magenta, cyan, yellow, and white.

Different devices have different gamut (e.g. database generation workstation,
simulator display systems). In other words one device may be able to display
certain colors (usually highly saturated ones) that another device cannot. The
gamut of a particular RGB device can be determined from its R, G, and B
chromaticities and white point.

© 2015 Open Geospatial Consortium

460

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Converting image data from one device to another generally results in gamut
mismatches colors that cannot be represented exactly on the destination device.
The process of making the colors fit, which can range from a simple clip toelaborate nonlinear scaling transformations, is termed gamut mapping. The aim is
to produce a reasonable visual representation of the original image.

© 2015 Open Geospatial Consortium

461

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

© 2015 Open Geospatial Consortium

462

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

Appendix H
H. Navaids Attribution
This section provides a list and description of the instance-level attribution fields held in Navigation Dataset Instance
Attribute files. The attribute name is limited to a maximum of 10 characters.
The Logical data type in column 2 of the following tables refers to the dBASE III Logical data type. A true value isdefined as one of the letters T, t, Y, and y; while the false value is defined as F, f, N, and n.

© 2015 Open Geospatial Consortium

463

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

AirportAttribute Name
StoraNumbe

Data TypeUint64Range-

Logical1-Absolute Height above surface level Flag. Always true.

String50 chars-

Alternate name other than the official name that can be used
occasionally.

AsCoStNumb

Uint64--

Associated Comms record storage number

BeacoAvail

LogicalBoolean-Indicates if a rotating beacon is present.

City

String50 chars-

Airport city name.

CivMilTyp

CivilMilitaryType

0-6-

Airport usage type (civil, military, etc.)

ClearStatu

ClearanceStatus

0-3-

Clearance status.

CountryCountryEntry

0-336

-

DayliTim

Float32

+/-24

Hrs

Difference to Zulu time based on the daylight saving time.

DayTimFram

String100 chars-

Timeframe when daylight saving time is observed by a country.

FlipPage

String75 chars-

Related pages for that airport in the companion FLIP.

FuelType

Stringmemo-

Fuel type available.

LogicalBoolean-Indication of the presence of a hydrographic element near the
airport.

String

6 chars-

Airport IATA designator.

AHGT
AlterNam

HydElePres
IataCode

Unit Key Description- 2101 Storage number.

2116 Country where the airport is located.

© 2015 Open Geospatial Consortium

464

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

Range

IcaoCode

Attribute Name

String

4 chars-2103 Airport ICAO area code.

Ident

String

6 chars-2102 Airport ICAO ident.

IfrCapab

LogicalBoolean-Indicates if the airport has published IFR approaches.

IslanGrou

String50 chars-

Airport associated with islands or group of islands.

Jasu

String100 chars-

Type of Jet Aircraft Starting Units (JASU) available.

LonRunLeng

Uint32-

Ft

Length of the longest runway of the airport.

LonRunSurf

PavementType

0-3-

Surface type of the longest runway.

MagneticTrueIndication

0-6-

Indicates if the details and procedures are given relative toMagnetic or True North.

MagneVaria

Float32+/-180Deg

MgrsPosit

String20 chars-

MGRS position given using the UTM or the UPS grid.

Name

String100 chars-

Official name.

NavIcaCod

String

4 chars-

Recommended navaid ICAO code.

NavaiIden

String

6 chars-

Recommended navaid ident.

Notam

NotamSystem

0-4-

Notam service.

OilType

String75 chars-

Type of oil available.

OperaAgenc

String

255 chars-Primary operating agency.

OperaHour

OperatingHours

0-4-

Operating hours of the airport.

MagTruIndi

Unit Key Description

Magnetic variation.

© 2015 Open Geospatial Consortium

465

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

Data Type

Range

GeoCoordinate

x,y,z

-

Position (latitude, longitude, altitude) of the NavObject.

RemarkStringmemo-

Essential remarks for terminal procedures.

ServiRemar

StringMemo-

Service remarks for airport.

SpeedLimit

Uint32-

Kts

Speed limit in knots.

SpeLimAlti

Sint32-Ft

Altitude below where speed limits may be imposedStateName

StateEntry

0-51

-

State or province where the airport is located.

SupFluTyp

String50 chars-

Type of available fluids/system/oxygen/nitrogen.

TerraImpac

LogicalBoolean-Indicates a terrain impact on the airport.

Timezone

Float32

+/-24

Hrs

Difference to Zulu time.

Sint32-Ft

Upper altitude limit for which the vertical position of an A/C iscontrolled by reference to altitudes (MSL).

Sint32-Ft

Lowest flight level available to use above the transition altitude.

Point1

TransAltit
TransLeve

Unit Key Description© 2015 Open Geospatial Consortium

466

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

AirRefueling
Attribute Name
StoraNumbe

Data typeUint64

Range Unit Key Description
2101 Storage number.

AHGT

Logical1-

AiReOpIden

String20 chars-

AltitDescr

RefuelingAltitudeDescription

0-4-

Indicates how Altitude 1 and 2 should be used (Refuel1)

AltitDesc1

RefuelingAltitudeDescription

0-4-

Indicates how Altitude 1 and 2 should be used (Refuel2)

AltitDesc2

RefuelingAltitudeDescription

0-4-

Indicates how Altitude 1 and 2 should be used (Refuel3)

ApRaBeCoSe

Uint32--APN 69/134/135 radar beacon code setting

ApRaBeCoS1

Uint32--APX 78 radar beacon code setting

BackuFrequ

Uint64-Hz

Backup UHF frequency

ComTelNumb

String100-

Commercial telephone number(s) of the scheduling unit

CountryCountryEntry

0-336

-

2116 Country where the refueling track or anchor is locatedDirection

RefuelingDirection

0-8-2122 Predominant direction of the refueling track or anchor at
the point of entry

DsnTelNumb

String100-

Defense switched network telephone number

IcaoCode

String

4-

ICAO code at point of entry

PrimaFrequ

Uint64-

Hz

Primary UHF frequency

Absolute Height above surface level Flag. Always true.
2102 Air refueling operation identifier© 2015 Open Geospatial Consortium

467

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

Uint32--Air-to-Air Y-band tacan channel used during refueling
operations

GeoCoordinate

x,y,z

-

Reference Position (latitude, longitude, altitude)

RefueAltit

Sint32-Ft

Altitude 1 to be used with altitude description 1

RefueAlti1

Sint32-Ft

Altitude 2 to be used with altitude description 1

RefueAlti2

Sint32-Ft

Altitude 1 to be used with altitude description 2

RefueAlti3

Sint32-Ft

Altitude 2 to be used with altitude description 2

RefueAlti4

Sint32-Ft

Altitude 1 to be used with altitude description 3

RefueAlti5

Sint32-Ft

Altitude 2 to be used with altitude description 3

RemarkStringmemo-

Remarks are limited to essential information

SchedUni

String130-

General information on scheduling unit (name, area, etc.)

TankeChann

Uint32--Air-to-Air Y-band tacan channel used during refueling
operations

RefuelingOperationType

0-3-

Type of refueling operation

Point

Type

© 2015 Open Geospatial Consortium

468

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

AirRefuelingControl
Attribute Name
StoraNumbe

Data typeUint64

Range-

Unit Key Description
2101 Storage number.

AHGT

Logical1-

AiReOpIden

String20 chars-AiReStNumb

Uint64--

Associated air refueling record storage number

AiTrCoCent

String50 chars-

ATC controlling airspace where refueling track/anchor
is located

AiTrCoCeRe

Stringmemo-

Remarks pertaining to the controlling agency,
frequency, frequency direction, or general information

AtcCenMult

Uint32--2115 Differentiates between different entries for the sameATC center

CountryCountryEntry

0-336

-

Country where the air traffic control center is locatedDirection

RefuelingDirection

0-8-2122 Predominant direction of the refueling track or anchor
at the point of entry

Frequency1

Uint64-

Hz

Center frequency 1

Frequency2

Uint64-

Hz

Center frequency 2

Frequency3

Uint64-

Hz

Center frequency 3

Frequency4

Uint64-

Hz

Center frequency 4Frequency5

Uint64-

Hz

Center frequency 5

Absolute Height above surface level Flag. Always true.
2108 Air refueling operation identifier© 2015 Open Geospatial Consortium

469

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

FrequencyDirectionRestriction

0-3-

Direction in which the specified frequency applies

FreDirRes1

FrequencyDirectionRestriction

0-3-

Direction in which the specified frequency applies

FreDirRes2

FrequencyDirectionRestriction

0-3-

Direction in which the specified frequency applies

FreDirRes3

FrequencyDirectionRestriction

0-3-

Direction in which the specified frequency applies

FreDirRes4

FrequencyDirectionRestriction

0-3-

Direction in which the specified frequency applies

IcaoCode

String

4 chars-

ICAO code

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

RefuelingPointType

0-7-

Type of refueling point

Point1
RefPoiTyp© 2015 Open Geospatial Consortium

470

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

AirRefuelingFootnote
Attribute Name
StoraNumbe

Data typeUint64Range-

Logical1-

AiReOpIden

String20 chars-AiReStNumb

Uint64--

Associated air refueling record storage number

CountryCountryEntry

0-336

-

Country where the refueling operation is locatedDirection

RefuelingDirection

0-8-

Predominant direction of the refueling track or anchor
at the point of entry

Footnote

Stringmemo-Footnote

IcaoCode

String

4 chars-

ICAO code

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

AHGT

Point1

Unit Key Description- 2101 Storage number.
Absolute Height above surface level Flag. Alwaystrue.
2108 Air refueling operation identifier© 2015 Open Geospatial Consortium

471

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

AirRefuelingPoint
Attribute Name
StoraNumbe

Data typeUint64

Range
-

Unit
-

AHGT

Logical1-

AiReOpIden

String20 chars-AiReStNumb

Uint64--

Associated air refueling record storage number

Bearing

Uint320-359

Deg

Bearing TO navaid (brg FROM navaid if DME)

CoWiNaFla

LogicalBoolean-Indicates if point is collocated with a navaidCountryCountryEntry

0-336

-

Country where the refueling point is locatedDirection

RefuelingDirection

0-8-

Predominant direction of the refueling track or anchor
at the point of entry

Distance

Uint32-

Nm

Distance to navaid

IcaoCode

String

4 chars-

ICAO code

Ident

String

6 chars-

NavaiCount

CountryEntry

0-336

-

Navaid country

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32--

Navaid key code

NavaidType

NavaidType

0-15

-

Navaid type

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of refueling point

Point1

Key
2101

Description
Storage number.
Absolute Height above surface level Flag. Always true.

2108

2102

Air refueling operation identifier

Refueling point identifier© 2015 Open Geospatial Consortium

472

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

Uint32--

RefuelingPointType

0-7

-

2115

Refueling point sequence number
Type of refueling point© 2015 Open Geospatial Consortium

473

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

AirRefuelingSegment
Attribute Name
StoraNumbe

Data typeUint64

Range
-

AHGT

Logical1-

AiReOpIden

String20 chars-AiReStNumb

Uint64--

Associated air refueling record storage number

GeoCoordinate

x,y,z

-

Arc origin position (longitude, latitude, altitude)

ArcSegDeri

ArcSegmentDerivation

0-3-

Indicates how the arc segment is defined

Bearing1

Float32+/-180Deg

Bearing 1 from center coordinates or navaid

Bearing2

Float32+/-180Deg

Bearing 2 from center coordinates or navaidCountryCountryEntry

0-336

-

Country where the refueling segment is locatedDirection

RefuelingDirection

0-8-

Predominant direction of the refueling track or anchor at
the point of entry

IcaoCode

String

4 chars-

ICAO code

NavaiCount

CountryEntry

0-336

-

Navaid country

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32-

Navaid key code

NavaidType

NavaidType

0-15

-

Navaid type

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of refueling point

Point2

Point1

Unit Key- 2101 Storage number.

Description

Absolute Height above surface level Flag. Always true.
2108 Air refueling operation identifier© 2015 Open Geospatial Consortium

474

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

Float32-

Nm

Radius 1

Radius2

Float32-

Nm

Radius 2

Point3

GeoCoordinate

x,y,z

-

Segment end position (longitude, latitude, altitude)

Uint32--2115 Defines relative position of airspace segment

BoundaryShape

0-8-Type of airspace segment being plotted

SegmeNumbe
Shape© 2015 Open Geospatial Consortium

475

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

Airspace Boundary
Attribute Name
StoraNumbe

Data TypeUint64Range-

Logical1-Absolute Height above surface level Flag. Always true.

AirwayLevel

0-3-

Airspace structure in which boundary is effective (high/low)Class

String2 chars-

Airspace boundary class

ClaExcFla

LogicalBoolean-Flag indicating exceptions to the airspace class

ClaExcRema

Stringmemo-

Provides the details of the exception in the airspace

ComCalSig

String40 chars-

ContrAutho

String60 chars-CountryCountryEntry

0-336

-

Frequency

Uint64-Hz

Frequency for communicating with identified facility

Frequenc1

Uint64-Hz

Frequency 2 used for communicating with identifed facility

IcaoCode

String

4 chars-

ICAO code of the airspace boundary

Ident

String

6 chars-

LowEffAlti

Sint32-

Ft

Lower vertical limit of the given airspace

LoEfAlRefe

AltitudeReference

0-4-

Lower effective altitude reference

LowRvsAlti

Sint32-

Ft

Lower vertical limit of the given RVSM airspace

AHGT
AirwaLeve

Unit Key- 2101 Storage number.

Description

2111 Call sign of the communications facilities
Office responsible for air traffic within airspace
2116 Country where the boundary is located2102 ICAO ident of airspace boundary© 2015 Open Geospatial Consortium

476

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

String50 chars-

Official name of the airspace boundary

Point1

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

Float32-

Nm

Required performance accuracy necessary for operation
within airspace

AirspaceBoundaryType

0-14

-

Airspace boundary type

UppEffAlti

Sint32-Ft

Upper vertical limit of the given airspace

UpEfAlRefe

AltitudeReference

0-4-Upper effective altitude reference

UppRvsAlti

Sint32-Ft

Upper vertical limit of the given RVSM airspace

ReqNavPerf
Type© 2015 Open Geospatial Consortium

477

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

AirwayRestriction
Attribute Name
StoraNumbe

Data TypeUint64

Range-

Unit Key- 2101 Storage number.

Description

BloAltTo

LogicalBoolean-Consider restriction altitude 1 to 2 as a restricted range

BloAltTo1

LogicalBoolean-Consider restriction altitude 2 to 3 as a restricted range

BloAltTo2

LogicalBoolean-Consider restriction altitude 3 to 4 as a restricted range

BloAltTo3

LogicalBoolean-Consider restriction altitude 4 to 5 as a restricted range

BloAltTo4

LogicalBoolean-Consider restriction altitude 5 to 6 as a restricted range

BloAltTo5

LogicalBoolean-Consider restriction altitude 6 to 7 as a restricted range

BlockAltit

LogicalBoolean-Consider restriction altitude 7 as a restricted altitude

CountryCountryEntry

0-336

-

CruisTabl

CruiseTable

0-4-

Cruise table indicator

EndDateString12 chars-

End date

EnFiIcCod

String

4 chars-

ICAO code of end fix point

EndFixIden

String

6 chars-

End fix point identifier

ExcluIndic

ExclusionIndicator

0-4-

Altitudes to be excluded

OpeEndDay

DayOfWeek

0-7-Time of operation end day

OpeEndDay1

DayOfWeek

0-7-Time of operation end day

2116 Country where the start fix point is located© 2015 Open Geospatial Consortium

478

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

Data TypeRange

OpeEndDay2

DayOfWeek

0-7

Unit Key-Time of operation end day

Description

OpeEndDay3

DayOfWeek

0-7-Time of operation end day

OpeStaDay

DayOfWeek

0-7-Time of operation start day

OpeStaDay1

DayOfWeek

0-7-Time of operation start day

OpeStaDay2

DayOfWeek

0-7-Time of operation start day

OpeStaDay3

DayOfWeek

0-7-Time of operation start day

OpeEndTime

String20 chars-Time of operation end time

OpeEndTim1

String20 chars-Time of operation end time

OpeEndTim2

String20 chars-Time of operation end time

OpeEndTim3

String20 chars-Time of operation end time

OpeStaTime

String20 chars-Time of operation start time

OpeStaTim1

String20 chars-Time of operation start time

OpeStaTim2

String20 chars-Time of operation start time

OpeStaTim3

String20 chars-Time of operation start time

RestrAltit

Sint32-

Ft

Restriction altitude

RestrAlti1

Sint32-

Ft

Restriction altitude

RestrAlti2

Sint32-

Ft

Restriction altitude

RestrAlti3

Sint32-

Ft

Restriction altitude© 2015 Open Geospatial Consortium

479

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

Range

RestrAlti4

Attribute Name

Sint32-

Unit Key
Ft

Restriction altitude

Description

RestrAlti5

Sint32-

Ft

Restriction altitude

RestrAlti6

Sint32-

Ft

Restriction altitude

RestrIden

Uint32

6-

Restriction identifier

RestrNot

Stringmemo-

Restriction note

RestrTyp

RestrictionType

0-4-

Restriction type

RouteIdent

String

6 chars-2102 Route identifier

StartDate

String12 chars-

Start date

StFiIcCod

String

4 chars-

ICAO code of start fix point

StaFixIden

String

6 chars-

Start fix point identifier

TimeCode

TimeCode

0-4-Time code

TimeIndica

TimeIndicator

0-3-Time indicator© 2015 Open Geospatial Consortium

480

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

Approach

Attribute Name
StoraNumbe

Data TypeUint64

Range-

Unit Key- 2101 Storage number.

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirStoNumb

Uint64--

Airport storage number

Altitude1

Sint32-

Ft

First altitude limit

AltitTyp

AltitudeType

0-4-

Altitude 1 type

Altitude2

Sint32-

Ft

Second altitude limit

AltitTyp1

AltitudeType

0-4-

Altitude 2 type

AltitDescr

AltitudeDescription

0-13

-

Altitude description

ArcRadius

Float32-Nm

Arc radius

CenterFix

String10 chars-

Point which defines the center of the arc flight path

CeFiIcCod

String

4 chars-

ICAO code of the center fix

CountryCountryEntry

0-336

-

2116 Country associated with the terminal procedure

CourseFloat32+/-180Deg

Outbound course from waypoint in fix ident

FixDetails

FixDetails

0-9-

Fix details

FixFunctio

FixFunction

0-7-

Fix function

FixIcaCod

String

4 chars-

ICAO code of the fix point© 2015 Open Geospatial Consortium

Description

481

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

FixIdent

Attribute Name

String10 chars-

Fix identifier

FlyOveTyp

FlyOverType0-4-

Fly over type

MagCouIndi

MagneticTrueIndication

0-6-

Indicates if the course provided is magnetic course

NavaiCount

CountryEntry

0-336

-

Country where recommended navaid 1 is located

Point2

GeoCoordinate

x,y,z

-

Navaid 1 DME position (longitude, latitude, altitude)

NavKeyCod

Uint32--Distinguish between navaid of same type with same ident insame country

NavMagVari

Float32+/-180Deg

Recommended navaid 1 magnetic variation

GeoCoordinate

x,y,z

-

Navaid 1 position (longitude, latitude, altitude)

NavaiTyp

SegmentNavaidType

0-13

-

Recommended navaid 1 type

NavaiCoun1

CountryEntry

0-336

-

Country where recommended navaid 2 is located

Point4

GeoCoordinate

x,y,z

-

Navaid 2 DME position (longitude, latitude, altitude)

NavKeyCod1

Uint32--Distinguish between navaid of same type with same ident insame country

NavMagVar1

Float32+/-180Deg

Recommended navaid 2 magnetic variation

GeoCoordinate

x,y,z

-

Navaid 2 position (longitude, latitude, altitude)

NavaiTyp1

SegmentNavaidType

0-13

-

Recommended navaid 2 type

PathTermin

PathTermination

0-23

-

Path and Termination

ReNaIcCod

String

4 chars-

ICAO code of the recommended navaid 1

Point3

Point5

Unit Key

Description© 2015 Open Geospatial Consortium

482

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

Range

RecNavIden

Attribute Name

String10 chars

Unit Key-

Recommended navaid identifier 1

Description

RecNavIde1

String10 chars-

Recommended navaid identifier 2

ReqNavPerf

Float32-

Nm

Required navigation performance

RouteDista

Float32-

Nm

Distance in nautical miles from waypoint in fix ident

RouteType

RouteType

0-4-

Termination Procedure Type

SpeAirCate

AircraftCategory

0-4-

Aircraft category that speed limit 1 applies to

SpeedAltit

Sint32-Ft

Altitude where speed limit 1 applies

SpeedLimit

Uint32-

Kts

Speed limit 1

SpeAirCat1

AircraftCategory

0-4-

Aircraft category that speed limit 2 applies to

SpeedAlti1

Sint32-Ft

Altitude where speed limit 2 applies

SpeedLimi1

Uint32-

Kts

Speed limit 2

SuTeDaStNu

Uint64--Storage number of associated Supplemental Terminal Data
recordThrCroHeig

Uint32-Ft

Threshold crossing heightTransAltit

Sint32-

Ft

Transition altitude

TurnDirect

TurnDirection

0-3-

Turn direction

TurDirVali

LogicalBoolean-Turn direction valid

WaypoCount

CountryEntry

0-336

-

Waypoint country© 2015 Open Geospatial Consortium

483

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

Range

WaypoDescr

Attribute Name

WaypointDescription

0-15

-

Waypoint description

WaypoDista

Float32-

Nm

Nautical miles between fix point and recommended navaid 1(RHO)

WaypoDist1

Float32-

Nm

Nautical miles between fix point and recommended navaid 2

WayMagBear

Float32+/-180Deg

Magnetic bearing between fix point and recommended navaid 1(THETA)

WayMagBea1

Float32+/-180Deg

Magnetic bearing between fix point and recommended navaid 2

WayMagVari

Float32+/-180Deg

Waypoint magnetic variation

GeoCoordinate

x,y,z

-

Waypoint position (longitude, latitude, altitude)

AirIcaCod

String

4 chars-

ICAO code of the associated airport

AirpoIden

String

6 chars-

AppRouTypApproachRouteType

0-39

-

Approach route type

GpsFmsIndi

GpsFmsIndicator

0-6-Authorized system used for procedure

Ident

String

6 chars-

MultiCod

String2 chars-

Multiple records having same center fix

MultiIndic

String10 chars-Multiple records having same transition fix

RouteQuali

RouteQualifier1

0-9-

Approach route qualifier 1

RouteQual1

RouteQualifier2

0-6-

Approach route qualifier 2

SequeNumbe

Uint32--

Sequence number

Point1

Unit Key

Description

2102 Identifier of the associated airport

2108 SID/STAR/Approach identifier© 2015 Open Geospatial Consortium

484

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

Range

TransIden

Attribute Name

String10 chars

Unit Key-

VertiAngl

Float32+/-180Deg

Description
Transition identifier
Descent angle for the procedure© 2015 Open Geospatial Consortium

485

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

Arresting Gear

Attribute
Name
StoraNumbe

Data Type

Range

Unit

Key

Description

Uint64--2101

Storage number.

AHGT

Logical1-

AirIcaIden

String

6 chars-

2108

ICAO identifier of the associated airport

AirpoIden

String10 chars-

2102

DAFIF identifier of the associated airport

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of airport

Uint64--Storage number of the associated airport

CountryEntry

0-336

-

2116

Country in which the airport is located

DisFroRefe

Uint32

-

Ft

2114

Distance from the reference given in location reference

LocatRefer

LocationReference

0-3

-

2122

Reference for location of arresting gear

RunwaIden

String

6 chars-

2111

Runway identifier

Type

String80 chars-

2107

Arresting gear type

Point1
AirStoNumb
Country

Absolute Height above surface level Flag. Always true.

© 2015 Open Geospatial Consortium

486

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

Comms
Attribute Name
StoraNumbe

Data TypeUint64

Range
-

Unit
-

Key
2101 Storage number.

Description

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

24HouAvail

LogicalBoolean-

24 hour availability of comms frequency flag

AirIcaCod

String

4 chars-

ICAO code of the associated airport

AirpoIden

String

6 chars-

AirStoNumb

Uint64--Storage number of the associated airport

AltitDescr

AltitudeDescription

0-13

-

Altitude description

AntenPatte

String30 chars-

Antenna Pattern Description

AreaCode

String12 chars-

Area code for telephone numbers

CallSign

String50 chars-Name of facility being called

CellNetwor

String30 chars-

Cellular network information

CommsAltit

Sint32-

Ft

Communications altitude limit 1

CommsAlti1

Sint32-

Ft

Communications altitude limit 2

CommsDetai

CommsDetails

0-7-

Communications details

CommsDista

Uint32-

Nm

Communications distanceCommsEncry

CommsEncryption

0-1-

Communications encryption status/mode

2102 Identifier of the associated airport© 2015 Open Geospatial Consortium

487

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

Range

Unit

ComFliTypAttribute Name

CommsFlightType

0-4-

CommsType

CommsType0-58-2107 Communications typeCountryCountryEntry

0-336

-

2116 Country where the communications information isapplicable

DistaDescr

DistanceDescription

0-2-

Comms distance description

Encrypted

LogicalBoolean-

Encrypted

FirUirIden

String

6 chars-

2108 FIR/UIR identifier

FirUirIndi

FirUirType

0-3-

FIR/UIR indicator

Frequency

Uint64-Hz2104 Communications frequency

FrequTypFrequencyType

0-7-

Communications frequency type

GuardTrans

GuardTransmit

0-3-Communications transmit/receive flag

MagneVaria

Float32+/-180Deg

Magnetic variation

Modulation

Modulation

0-2-

Signal modulation

MonitFrequMonitoredFrequency

0-6-

Monitored emergency frequencies

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) ofcommunications antenna

RadarCapab

LogicalBoolean-Radar capability flag

ReceiSensi

Float64-

Watt

Receiver sensitivity

RemarkStringmemo-

Point1Key

Description
FIR/UIR address to supplement identifier

Remarks associated with Comms station© 2015 Open Geospatial Consortium

488

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

Range

Unit

ReAiStNumb

Attribute Name

Uint64--

Key

Storage number of associated remote airport facility

Description

ReFaIcCod

String

4 chars-

ICAO code of associated remote facility

RemFacIden

String

6 chars-

Identifier of associated remote facility

RemFacTyp

FacilityRecordType

0-4-

Associated remote facility type

RemoteName

String50 chars-

2120 Name of associated remote facility

ReNaStNumb

Uint64--Storage number of associated remote navaid

RetraAvail

LogicalBoolean-Retransmission available

RetraFrequ

Uint64-Hz

Retransmission frequency

SectorString100 chars-

Area in which frequency is effective

SeAiStNumb

Uint64--Storage number of sector airport facility

SecEndBear

Uint320-359

Deg

SeFaIcCod

String

4 chars-

ICAO code of sector facility

SecFacIden

String

6 chars-

Identifier of sector facility

SecFacTyp

FacilityRecordType

0-4-

Sector facility type

SeNaStNumb

Uint64--Storage number of sector navaid

SecStaBear

Uint320-359

Deg

ServiIndic

ServiceIndicator

0-10

-

Communications service indicator

SignaEmiss

SignalEmission

0-7-

Signal emission

Sector end bearing

Sector start bearing© 2015 Open Geospatial Consortium

489

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

H.12

Data Type

Range

Unit

SpeOpeHour

String100 chars-

Key

Hours of operation different from airport/heliport

Description

TelepNumbe

String20 chars-

Telephone number

TransPowe

Float64-

Watt

Transmission power

VoiceMessa

String30 chars-

Voice message

Controlled Airspace
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AiBoStNumb

Uint64--

Associated AirspaceBoundary record storage number

AirspCente

String

6 chars-

AirspClass

String2 chars-

AirspTypAirspaceType

0-18

-

2107 Controlled airspace type

AirTypChar

String2 chars-2122 Controlled airspace type character read directly from data file

ArcBearing

Float32+/-180 Deg

ArcDistanc

Float32-

Nm

2102 Ident for airspace 'center'
Airspace classification (one character)

Arc bearing
Arc distance© 2015 Open Geospatial Consortium

490

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

Data Type

Range Unit Key

Description

Float32-Nm

Arc distance (radius of arc from center point)

GeoCoordinate

x,y,z

-

Arc origin position (longitude, latitude, altitude)

ArcSegDeri

ArcSegmentDerivation

0-3-

Indicates how the arc segment is defined

Bearing1

Float32+/-180 Deg

True bearing from arc origin or navaid

Bearing2

Float32+/-180 Deg

True bearing from arc origin or navaid

BoundEn

LogicalBoolean-End of boundary description - return to origin point

BoundShap

BoundaryShape

0-8-

Boundary shape typeCountryCountryEntry

0-336

-

Country1

CountryEntry

0-336

-

Country through which the boundary passes

Country2

CountryEntry

0-336

-

Country through which the boundary passes

Country3

CountryEntry

0-336

-

Country through which the boundary passes

Country4

CountryEntry

0-336

-

Country through which the boundary passes

Country5

CountryEntry

0-336

-

Country through which the boundary passes

IcaoCode

String

4 chars-

ICAO code for the airspace

AirwayLevel

0-3-

Type of airway (high, low, or either)

LowerLimit

Sint32-

Ft

Lower limit

LoLiAlRefe

AltitudeReference

0-4-

Altitude reference

MultiCod

String2 chars-

Point3

Level

2116 Country where airspace is located2118 Differentiate between airspaces with same designator© 2015 Open Geospatial Consortium

491

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

Data Type

Name

H.13

Range Unit Key

Description

String50 chars-

Controlled airspace nameNavaiCount

CountryEntry

0-336

-

Country in which navaid is located

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32--Distinguish between same type navaid with same ident andcountry

NavaidType

NavaidType

0-15

-

Navaid type

Notam

LogicalBoolean-

Active times by NOTAM

Point2

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude)

Point1

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

ReqNavPerf

Float32-

Nm

Required navigation performance

SequeNumbe

Uint32--

Sequence number

TimeCode

PrimaryTimeCode

0-4-

Time codes for primary records

UpperLimit

Sint32-Ft

Upper limit

UpLiAlRefe

AltitudeReference

0-4-

Reference for upper limit altitude

Range
-

Unit Key Description
2101 Storage number.

Enroute Airway
Attribute Name
StoraNumbe

Data TypeUint64© 2015 Open Geospatial Consortium

492

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

Data Type
LogicalRange
1Unit Key Description
Absolute Height above surface level Flag. Always true.

AirwaLeve

AirwayLevel

0-3-

Airway level

AirwaRestr

LogicalBoolean-

Airway restriction exists

AtcComFla

LogicalBoolean-

ATC compulsory waypoint flag

BoundCod

BoundaryCode

0-10

-

Boundary code

Country

String95 chars-

List of countries through which the ATS route segment passes

CrLeNoStFl

LogicalBoolean-

IFR cruising levels are not in agreement with appropriate
diagrams (FLIP)

CruisTabl

CruiseTable

0-4-

Cruise table indicator

Direction

Direction

0-2-

Predominant direction of ATS route

DirecRestr

DirectionRestriction

0-3-

Direction restriction

EnAiRoTyp

EnrouteAirwayRouteType

0-7-

Enroute airway route type

FixCountry

CountryEntry

0-336

-

FixDetails

FixDetails

0-9-

Fix details

FixFunctio

FixFunction

0-7-

Fix function

FixIcaCod

String

4 chars-

ICAO code of fix point

FixIdent

String

6 chars-

Fix identifier

FixNavTypNavaidType

0-15

-

Fix type

FixRecTyp

FixRecordType0-8-

Fix point record type2116 Country where the fix point is located© 2015 Open Geospatial Consortium

493

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

Data TypeUint64Range-

FixTurRadi

Float32-

Nm

Fix turn radius 1

FixTurRad1

Float32-

Nm

Fix turn radius 2

FlyOveTyp

FlyOverType0-4-

Fly over type

FrequClas

FrequencyClass

0-2-

Frequency class of ATS route (UHF/VHF or LF/MF)

IcaoCode

String

4 chars-

ICAO CodeInbouCours

Float32+/-180Deg

InbCouRefe

MagneticTrueIndication

0-6-

Inbound course reference

MaximAltit

Sint32-Ft

Maximum altitude for segment

MaxFliAlti

Sint32-Ft

Maximum altitude for airway

MinimAltit

Sint32-Ft

Altitude limit in direction flight coded for segment

MinimAlti1

Sint32-Ft

Segment altitude limit for opposite of coded direction of flight

MinFliAlti

Sint32-Ft

Minimum altitude limit for airway

OutboCours

Float32+/-180Deg

Outbound course from waypoint in fix ident

OutCouRefe

MagneticTrueIndication

0-6-

Outbound course reference

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of waypoint

ReNaIcCod

String

4 chars-

ICAO code of recommended navaid

RecNavIden

String6-

Recommended navaid identifier

Point1

Unit Key Description
Fix point storage number

Inbound course to waypoint in fix ident© 2015 Open Geospatial Consortium

494

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Attribute Name
RemarkData Type
StringRange
memo

Unit Key Description
Essential information related to ATS route

ReqNavPerf

Float32-

Nm

Required navigation performance

RouteDista

Float32-

Nm

Distance in nautical miles from waypoint in fix ident

RouteIdent

String

8 chars-

RouSegTyp

AtsRouteSegmentType0-2-

ATS route segment type

RouteStatu

RouteStatus

0-5-

ATS route status

RvsmFlag

LogicalBoolean-

Reduced vertical separation minima

SequeNumbe

Uint32--

Sequence number

StateName

StateEntry

0-51

-

State through which ATS route passes

TransRadiu

Float32--

Transition radius

WaypoDescr

WaypointDescription

0-15

-

Waypoint description

WaypoDista

Float32-

Nm

Nautical miles between fix point and recommended navaid

WayMagBear

Float32+/-180Deg

Magnetic bearing between fix point and recommended navaid

2102 Route identifier© 2015 Open Geospatial Consortium

495

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

FirUirAttribute Name

Data Type

Description

Range Unit Key

StoraNumbe

Uint64--

AHGT

Logical1-

AdjFirIden

String

6 chars-

2108 Adjacent FIR ident

AdjUirIden

String

6 chars-2120 Adjacent UIR ident

AiBoStNumb

Uint64--

Associated airspace boundary record storage number

AltitudeUnit

0-3-

Unit used in specific FIR/UIR to fulfill requirement of ICAO flight plan

AltitUni

Absolute Height above surface level Flag. Always true.

ArcBearing

Float32

ArcDistanc

Float32-Nm

Arc distance

ArcDistan1

Float32-Nm

Arc distance (radius of arc from center point)

GeoCoordinate

x,y,z

-

Arc origin position (longitude, latitude, altitude)

ArcSegDeri

ArcSegmentDerivation

0-3-

Indicates how the arc segment is defined

Bearing1

Float32+/-180 Deg

True bearing from arc origin or navaid

Bearing2

Float32+/-180 Deg

True bearing from arc origin or navaid

BoundEn

LogicalBoolean-End of boundary description - return to origin point

BoundShap

BoundaryShape

0-8-

Boundary shape typeCountry1

CountryEntry

0-336

-

Country through which the boundary passes

Point2+/-180 Deg

2101 Storage number.

Arc bearing© 2015 Open Geospatial Consortium

496

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

Attribute Name

Data Type

Range Unit KeyCountry2

CountryEntry

0-336

-

Country through which the boundary passes

Country3

CountryEntry

0-336

-

Country through which the boundary passes

Country4

CountryEntry

0-336

-

Country through which the boundary passes

Country5

CountryEntry

0-336

-

Country through which the boundary passes

CruisTabl

CruiseTable

0-4-

Cruise table applicable

EntRepRequ

LogicalBoolean-

Entry report required for FIR/UIRFirUppLimi

Sint32Ft

FIR Upper Limit

FlightType

CommsFlightType

0-4-

IcaoCode

String

4 chars-

Ident

String

6 chars-2102 FIR/UIR Ident

NameString50 chars-

Fir/Uir nameNavaiCount

CountryEntry

0-336

-

Country in which navaid is located

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32--Distinguish between same type navaid with same ident and country

NavaidType

NavaidType

0-15

-

Navaid type

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude)

Uint32--

Sequence number

SpeedUnit

0-3-

Unit used in specific FIR/UIR to fulfill requirement of ICAO flight plan

Point1
SequeNumbe
SpeedUnit

2122 Type of airway (high, low, or either)
FIR/UIR ICAO code

© 2015 Open Geospatial Consortium

497

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

Attribute Name

Data Type

Range Unit Key

Type

FirUirType

0-3-

UirLowLimi

Sint32-Ft

UIR Lower limit

UirUppLimi

Sint32-Ft

Upper limit

2107 FIR/UIR type© 2015 Open Geospatial Consortium

498

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

Gate
Attribute Name
StoraNumbe

Data TypeUint64

Range
-

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirlineString50 chars-Airline assigned to gate

AirIcaCod

String

4 chars-

ICAO code of the associated airport

AirpoIden

String

6 chars-

AirStoNumb

Uint64--

CountryCountryEntry

0-336

-

2116 Country where the gate is located

Ident

String

6 chars-

2108 Gate identifier

Name

String50 chars-

Orientatio

Float32+/-180Deg

GeoCoordinate

x,y,z

-

Point1

Unit Key- 2101 Storage number.

Description

2102 Identifier of the associated airport
Storage number of the associated airport

Name commonly applied to the gate
Orientation of gate (bearing)
Position (longitude, latitude, altitude) of gate

© 2015 Open Geospatial Consortium

499

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

GLS
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-

AirpoIden

String

6 chars-

AirStoNumb

Uint64--Storage number of the associated airport

ApproSlop

Float32+/-180Deg

Glideslope angle of the GLS approach

Bearing

Float32+/-180Deg

Localizer bearing of GLS approach

Category

LandingAidCategory

0-9-Category/Class of the GLS

ChannelString10 chars-

Channel decoded to identify frequency of differential GLS
ground station and approach info sent by diff. GLS groundstationCountryCountryEntry

0-336

-

2116 Country where the GLS is located

IcaoCode

String

4 chars-2103 ICAO code

Ident

String

6 chars-

2108 GLS reference path identifier

LocatIden

String10 chars-

MagneVaria

Float32+/-180Deg

GeoCoordinate

x,y,z

-

Station position (longitude, latitude, altitude)

String

6 chars-

Ident of the associated runway

Point1
RunwaIden

Absolute Height above surface level Flag. Always true.
2102 Ident of the associated airport

Airport or heliport ICAO location identifier code wheretransmitter is installed
Magnetic variation© 2015 Open Geospatial Consortium

500

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

Uint64--Storage number of the associated runway

SerVolRadi

Uint32-

Nm

Radius of service volume around transmitter

StatiTyp

GlsStationType

0-2-

Type of differential ground station (eg: LAAS/GLS or SCAT-1)

TdmaSlot

String30 chars-Time division multiple access (TDMA) slot in which groundstation transmits related approach© 2015 Open Geospatial Consortium

501

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

HelipadAttribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AircrTypString10 chars-

Aircraft type known to have used helipad in last 5 years.

Point1

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the helipad approach end.

Bearing

Float32+/-180Deg

CountryCountryEntry

0-336

-

Point2

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the displaced threshold(latitude, longitude, elevation).

HelipClose

LogicalBoolean-Indicates if the helipad is closed or unusable.

HelIcaCod

String

4 chars-2103 Associated Heliport ICAO code.

HelipIden

String

6 chars-

2108 Associated Heliport identifier.

HelStoNumb

Uint64

-

-

Ident

String

6 chars-2102 Helipad identifier.

LengthUint32-Ft

Helipad length.

LightSyste

LightingSystem

0-64

-

Lighting system 1.

LightSyst1

LightingSystem

0-64

-

Lighting system 2.

LightSyst2

LightingSystem

0-64

-

Lighting system 3.

Magnetic bearing.
2116 Helipad country.

Associated Heliport storage number.

© 2015 Open Geospatial Consortium

502

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

PadShape

0-2-

Shape of helipad (circular or rectangular).

SequeNumbe

Uint32

-

-

Slope

Float32-%

Helipad gradient

Point3

GeoCoordinate

x,y,z

-

Position (longitude, latitude, elevation) of the helipad stop end.

StopwLengt

Uint32-

Ft

Length of the area beyond the takeoff helipad.

StoSurTyp

RunwaySurfaceType

0-21

-

Stopway surface type.

SurfaTyp

RunwaySurfaceType

0-21

-

Helipad surface type.

TakeoDista

Uint32-

Ft

Takeoff distance available.

TrueBearin

Float32+/-180Deg

Helipad true bearing.

TruNorRefe

LogicalBoolean-True North reference flag.

Width

Uint32

10

Ft

Helipad width.

2115 Sequence number to differentiate helipads at same heliport.

© 2015 Open Geospatial Consortium

503

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

Heliport

Attribute Name

Data Type

Description

Range Unit Key

StoraNumbe

Uint64--2101 Storage number.

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AlterNam

String50 chars-

Alternate name other than the official name that can be used
occasionally.

AsCoStNumb

Uint64--

Associated Comms record storage number

BeacoAvail

LogicalBoolean-Indicates if a rotating beacon is present.

City

String50 chars-

Heliport city name.

CivMilTyp

CivilMilitaryType

0-6-

Heliport usage type (civil, military, etc.).

ClearStatu

ClearanceStatus

0-3-

Clearance status.

CountryCountryEntry

0-336

-

DayliTim

Float32

+/-24

Hrs

Difference to Zulu time based on the daylight saving time.

DayTimFram

String

100
chars

-

Timeframe when daylight saving time is observed by a country.

FlipPage

String75 chars-

Related pages for that heliport in the companion FLIP.

FuelType

Stringmemo-

Fuel type available.

HydElePres

LogicalBoolean-Indication of the presence of an hydrographic element near the
heliport.

2116 Country where the heliport is located.

© 2015 Open Geospatial Consortium

504

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

Data Type

Description

Range Unit Key

IataCode

String

6 chars-

2106 Heliport IATA designator.

IcaoCode

String

4 chars-2103 Heliport ICAO area code.

Ident

String

6 chars-2102 Heliport ICAO ident.

IfrCapabil

LogicalBoolean-Indicates if the heliport has published IFR approaches.

IslanGrou

String50 chars-

Heliport associated with islands or group of islands.

Jasu

String

100
chars

-

Type of Jet Aircraft Starting Units (JASU) available.

MagneVaria

Float32+/-180 Deg

MagTruIndi

MagneticTrueIndication

0-6-

Indicates if the details and procedures are given relative toMagnetic or True North.

MgrsPositi

String20 chars-

MGRS position given using the UTM or the UPS grid.

Name

String

100
chars

-

Official name.

NavIcaCod

String

4 chars-

Recommended navaid ICAO code.

NavaiIden

String

6 chars-

Recommended navaid ident.

Notam

NotamSystem

0-4-

Notam service.

OilType

String75 chars-

Type of oil available.

OperaHour

OperatingHours

0-4-

Operating hours of the heliport.

PadDimensi

Uint32-Ft

Pad dimension.

Magnetic variation.

© 2015 Open Geospatial Consortium

505

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

Data Type

Description

Range Unit Key

PadDimens1

Uint32-Ft

Pad dimension.

PadIdent

String

6 chars-

2108 Helipad identifier.

PadShape

PadShape

0-2-

Pad shape.

Point1

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the NavObject.

RemarkStringmemo-

Essential remarks for terminal procedures.

ServiRemar

Stringmemo-Service remarks for airport.

SpeedLimit

Uint32-

Kts

Speed limit in knots.

SpeLimAlti

Sint32-Ft

Altitude below where speed limits may be imposedStateName

StateEntry

0-51

-

State or province where the heliport is located.

SupFluTyp

String50 chars-

Type of available fluids/system/oxygen/nitrogen.

TerraImpac

LogicalBoolean-Indicates a terrain impact on the heliport.

Timezone

Float32

+/-24

Hrs

Difference to Zulu time.

TransAltit

Sint32-Ft

Upper altitude limit for which the vertical position of an A/C iscontrolled by reference to altitudes (MSL).

TransLeve

Sint32-Ft

Lowest flight level available to use above the transition altitude.

© 2015 Open Geospatial Consortium

506

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

HoldingPattern
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirIcaCod

String

4 chars-

ICAO code of the associated airport

AirpoIden

String

6 chars-

Identifier of the associated airport

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of airport

AirStoNumb

Uint64--Storage number of the associated airport

ArcRadius

Float32-

Nm

Turning radius, inbound to outbound leg, for RNP HoldingCountryCountryEntry0-336- 2116 Country where the holding pattern applies

DupliIden

String

6 chars- 2108 Duplicate identifier

FixCountry

CountryEntry

0-336

-

Country where the fix point is located

FixIcaCod

String

4 chars-

Fix ICAO Code

FixIdent

String

6 chars- 2102 Fix identifier

FixRecTyp

FixRecordType

0-8- 2107 Record type of fix point

FixStoNumb

Uint64--

HoldiCours

Float32

HoPaTuDire

PathTurnDirection

Point1+/-180 Deg
0-2-

Fix point storage number
Inbound holding course
Holding pattern turn direction© 2015 Open Geospatial Consortium

507

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

Uint32-

Kts

Holding pattern maximum speed in knots

LegLength

Float32-

Nm

Leg length in nautical miles

LegTimeFloat32-

Min

Leg time in minutes

MagneCours

MagneticTrueIndication

0-6-

Indicates if magnetic course

MaximAltit

Sint32-Ft

Maximum altitude

MinimAltit

Sint32-Ft

Minimum altitude

Name

String50 chars-Name commonly applied to the holding pattern

NavaiCount

CountryEntry

0-336

-

Country of navaid collocated with waypoint

NavaiIden

String

6 chars-

Identifier of navaid collocated with waypoint

NavKeyCod

Uint32--Key code of navaid collocated with waypoint

NavaidType

NavaidType

0-15

-

Type of navaid collocated with waypoint

ReqNavPerf

Float32-

Nm

Required navigation performance

TrackDescr

TrackDescription

0-3-

Defines track geometry for single terminal segment record

Type

HoldingPatternType

0-7-

Type of holding pattern© 2015 Open Geospatial Consortium

508

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

Ils
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.
-

Description

AHGT

Logical1Absolute Height above surface level Flag. Always true.

AirIcaCod

String

4 chars- 2103 ICAO code of the associated airport.

AirpoIden

String

6 chars- 2102 Ident of the associated airport.

AirStoNumb

Uint64--Storage number of the associated airport.

AppRouIden

String

6 chars-

Ident of the associated approach route 1.

ApRoStNumb

Uint64--Storage number of the associated approach route 1.

AppRouIde1

String

6 chars-

Ident of the associated approach route 2.

ApRoStNum1

Uint64--Storage number of the associated approach route 2.

AppRouIde2

String

6 chars-

Ident of the associated approach route 3.

ApRoStNum2

Uint64--Storage number of the associated approach route 3.

AppRouIde3

String

6 chars-

Ident of the associated approach route 4.

ApRoStNum3

Uint64--Storage number of the associated approach route 4.

AppRouIde4

String

6 chars-

Ident of the associated approach route 5.

ApRoStNum4

Uint64--Storage number of the associated approach route 5.

BacCouAvai

IlsBackCourse

0-3-

Back course availability information.

© 2015 Open Geospatial Consortium

509

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

Data Type

Range Unit Key

Float32

BeariRefer

MagneticTrueIndication

0-6-

Bearing reference.

Category

LandingAidCategory

0-9-Category/class of the ILS.

CountryCountryEntry0-336- 2116 Country where the ILS is located.

Declinatio

Float32

DecliRefer

MagneticTrueIndication

0-6

FalGliFla

LogicalBoolean -False glidepath flag

FalLocFla

LogicalBoolean -False localizer flag

GlideAngl

Float32+/-180 Deg

Glideslope angle.

GlideBeamw

Float32+/-180 Deg

Glideslope beamwidth.

GlideFrequ

Uint64Hz

GliMagVari

Float32+/-180 Deg

ILS glideslope magnetic variation.

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the glideslope emitter.

GliXOffse

Sint32-Ft

Glideslope X offset.

GliYOffse

Sint32-Ft

Glideslope Y offset.

Ident

String

6 chars-

Localizer ICAO ident.

LocalBeamw

Float32+/-180 Deg

LocalFrequ

Uint64

Point3+/-180 Deg

Description

Bearing+/-180 Deg--

Localizer magnetic bearing.

Station declination.
Declination angle reference.

ILS glideslope frequency.

Localizer beamwidth.

Hz 2104 ILS localizer frequency.

© 2015 Open Geospatial Consortium

510

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

Data Type

Range Unit Key

Description+/-180 Deg

ILS localizer magnetic variation.

GeoCoordinate

x,y,z

-

Localizer position (longitude, latitude, altitude).

LocXOffse

Sint32-Ft

Localizer X offset.

LocYOffse

Sint32-Ft

Localizer Y offset.

Name

String50 chars -NavStoNumb

Uint64--Storage number of the associated navaid.

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

RunwaIden

String

6 chars- 2111 Ident of the associated runway.

RunStoNumb

Uint64--Storage number of the associated runway.

SynchTyp

SynchronisationType

0-2-

Synchronization type.

ThrCroHeig

Uint32-Ft

Height above the landing threshold on a normal glidepath.

TrueBearin

Float32

Point2

Point1

Float32+/-180 Deg

Official name of the localizer.

Localizer true bearing.

© 2015 Open Geospatial Consortium

511

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

MarkerAttribute Name
StoraNumbe

Data TypeUint64

Range
-

Unit
-

Key
2101 Storage number.

Description

AHGT

Logical1-

AirpoIden

String

6 chars-

AirStoNumb

Uint64--Storage number of the associated airport/heliport

AssocNavai

AssociatedNavaid

0-2-

Associated navaid information

ChannelString

6 chars-

Navaid channel.

CountryCountryEntry

0-336

-

Frequency

Uint64HighLow

MarkerPower

IcaoCode

Absolute Height above surface level Flag. Always true.
2108 Ident of the associated airport/heliport

2116 Country where the marker is locatedHz

Frequency

0-2-Marker power

String

4 chars-2103 Marker ICAO area code

Ident

String

6 chars-2102 Marker ident

IlsBearing

Float32+/-180Deg

Bearing of the ILS localizer

IlsBeaRefe

MagneticTrueIndication

0-6-

Reference for the ILS bearing

LocalIden

String

6 chars-

Associated localizer ident

LocStoNumb

Uint64--

Associated localizer storage number

Location

Float32-

Nm

Location from the approach end of the runway© 2015 Open Geospatial Consortium

512

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

LogicalBoolean-

Locator collocation flag

LocatIden

String

6 chars-

Associated locator ident

LocStoNum1

Uint64--

Associated locator storage number

MagneVaria

Float32+/-180Deg

Magnetic variation

MinAxiBear

Float32+/-180Deg

True bearing of the marker minor axis

MorseCodeString3 chars-

Corresponding letters of the Morse code

Name

String50 chars-Marker official nameNavaiCount

CountryEntry

0-336

-

Navaid country.

NavaiFrequ

Uint64-Hz

Frequency

NavKeyCod

Uint32--

Navaid key code.

NavaidType

NavaidType

0-15

-

Navaid type.

GeoCoordinate

x,y,z

-

Marker position (longitude, latitude, altitude)

RunwaIden

String

6 chars-

RunStoNumb

Uint64--MarkerType

0-10

-

Point1Type2111 Ident of the associated runway
Storage number of the associated runway
2107 Marker type© 2015 Open Geospatial Consortium

513

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

MilitaryTrainingRoute
Attribute Name
StoraNumbe

Data TypeUint64

Range
-

AHGT

Logical1-

CountryCountryEntry

0-336

-

EffecTime

String100 chars-

Hours, days and/or dates that military training route is in effect

IcaoCode

String

4 chars-

ICAO code of air traffic controlling authority where route originates

Ident

String10 chars-

OriMilUni

String100 chars-

Military unit designated as the originating activity

Point1

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

Memo

-

Remarks are limited to terrain following ops, special operatingproc., flight service stations (100nm radius) & SR remarks

String100 chars-

Military unit responsible for scheduling training route flights

MilitaryRouteType

0-3-

Type of military training route

RemarkSchMilUni
Type

StringUnit Key
2101 Storage number.

Description

Absolute Height above surface level Flag. Always true.
2116 Country where the military training route originates

2102 Designation of the military training route© 2015 Open Geospatial Consortium

514

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

MilitaryTrainingRouteAirspace
Attribute
Name
StoraNumbe

Data Type

Range Unit Key

Description

Uint64-- 2101 Storage number.

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

ActPoiIden

String4
chars-

Ident of the action point within the military training route

MiTrRoIden

String10chars- 2102 Military training route identifier

MiTrRoStNu

Uint64--

Associated military training route storage number

MTROSNumbe

Uint64--

Associated military training route overlay storage number

NeAcPoIden

String4
chars-

Ident of the next action point within the military training route

GeoCoordinate x,y,z-

Reference Position (longitude, latitude, altitude)-

Designation for the section of the special use airspace

Point1
SectorString10chars

SegmeNumbe

Uint32-- 2115 Defines relative position of segment in military training route airspace

SequeNumbe

Uint32--SpUsAiIden

String

18
chars

-

Special use airspace or military operations area identifier

SpUsAiStNu

Uint64--

Associated special use airspace storage number

2120

Defines order of special use airspace (SUAS) or military operations
area (MOA) identifiers© 2015 Open Geospatial Consortium

515

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

© 2015 Open Geospatial Consortium

516

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

MilitaryTrainingRouteDescription

Attribute Name
StoraNumbe

Data TypeUint64

Range
-

Unit
-

Key
2101 Storage number.

Description

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

ActPoiIden

String

4 chars-

2108 Ident of the action point within the military training route

AddRouInfo

String100 chars-

Bearing

Float32+/-180Deg

CoWiNaFla

LogicalBoolean-Point collocated with navaid flag

CountryCountryEntry

0-336

-

Country where the point is locatedCrossAltit

Sint32-

Ft

Crossing altitude 1

CroAltRefe

AltitudeReference

0-4-

Crossing altitude 1 reference

CrossAlti1

Sint32-

Ft

Crossing altitude 2

CroAltRef1

AltitudeReference

0-4-

Crossing altitude 2 reference

CroAltDesc

RouteAltitudeDescription

0-5-

Indicates how the crossing altitude(s) should be applied

Distance

Float32-

Nm

Range from non-DME navaid or slant range from DME

EnrouAltit

Sint32-

Ft

Enroute altitude 1

EnrAltRefe

AltitudeReference

0-4-

Enroute altitude 1 reference

EnrouAlti1

Sint32-

Ft

Enroute altitude 2

Info vital to execution of military training route at a specificpoint to the next point
Bearing from DME or bearing to non-DME navaid© 2015 Open Geospatial Consortium

517

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

H.25

EnrAltRef1

AltitudeReference

0-4-

Enroute altitude 2 reference

EnrAltDesc

RouteAltitudeDescription

0-5-

Indicates how the enroute altitude(s) should be applied

IcaoCode

String

4 chars-

ICAO code

MiTrRoIden

String10 chars-

MiTrRoStNu

Uint64--

Associated military training route storage number

NavaiCount

CountryEntry

0-336

-

Navaid country

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32--

Navaid key code

NavaidType

NavaidType

0-15

-

Navaid type

NeAcPoIden

String

4 chars-

Ident of next action point within a military training route

PointFunct

PointFunction

0-6-

Function of the point

Point1

GeoCoordinate

x,y,z

-

Position of point (longitude, latitude, altitude)

RouWidLef

Float32-

Nm

Route width to left of centerline to the next point

RouWidRigh

Float32-

Nm

Route width to right of centerline to the next point

TurnDirect

PathTurnDirection

0-2-

Specific direction in which a turn is to be made

TurnRadius

Float32-

Nm

Turn radius around a point2102 Military training route identifier

MilitaryTrainingRouteOverlay© 2015 Open Geospatial Consortium

518

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

Range

StoraNumbe

Attribute Name

Uint64--

AHGT

Logical1-

AcPoBiSeAn

Float32+/-180Deg

ActPoiFunc

PointFunction

0-6-

Function of the action point

ActPoiIden

String

4 chars-

Ident of the action point within the military training route

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the action point

AcPoRoWiLe

Float32-

Nm

Route width to left of action point

AcPoRoWiRi

Float32-

Nm

Route width to right of action point

AcPoTuDire

PathTurnDirection

0-2-

Specific direction in which a turn is to be madeAcPoTuRadi

Float32-

Nm

Turn radius around action point

MiTrRoIden

String10 chars-

2102 Military training route identifier

MiTrRoStNu

Uint64--

NAPBSAngl

Float32+/-180Deg

NeAcPoFunc

PointFunction

0-6-

Function of the next action point

NeAcPoIden

String

4 chars-

Ident of the next action point within the military training route

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the next action point

Float32-

Nm

Route width to left of the next action point

Point1

Point2NAPRWLef

Unit Key

Description

2101 Storage number.
Absolute Height above surface level Flag. Always true.
Bi-section path angle for the next point based on next segment path(acute angle to that path)

Associated military training route storage number
Bi-section path angle for the next point based on next segment path(acute angle to that path)© 2015 Open Geospatial Consortium

519

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

Float32-

Nm

Route width to right of the next action point

NeAcPoTuDi

PathTurnDirection

0-2-

Specific direction in which a turn is to be made

NeAcPoTuRa

Float32-

Nm

Turn radius around the next action point

SegmeNumbe

Uint32--2115 Defines relative position of segment in military training route overlay© 2015 Open Geospatial Consortium

520

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

Mls
Attribute Name
StoraNumbe

Data TypeUint64

Range
-

AHGT

Logical1-

AirIcaCod

String

4 chars-2103 Icao code of the associated airport

AirpoIden

String

6 chars-2102 Ident of the associated airport

AirStoNumb

Uint64--

AzimuBeari

Float32+/-180Deg

Magnetic bearing of the MLS azimuth

AziLefAngl

Float32+/-180Deg

Azimuth proportional left angle

AziLefCove

Sint32+/-180Deg

Azimuth left coverage

GeoCoordinate

x,y,z

-

AziRigAngl

Float32+/-180Deg

Azimuth proportional right angle

AziRigCove

Sint32+/-180Deg

Azimuth right coverage

AziTruBear

Float32+/-180Deg

Azimuth true bearing in degrees

AziXOffse

Float32-

Ft

Azimuth X offset

AziYOffse

Float32-

Ft

Azimuth Y offset

BacAziBear

Float32+/-180Deg

Magnetic bearing of the MLS back azimuth

BaAzLeAngl

Float32+/-180Deg

Back azimuth proportional left angle

Point1

Unit Key- 2101 Storage number.

Description

Absolute Height above surface level Flag. Always true.

Storage number of the associated airport

Position (longitude, latitude, altitude) of the MLS azimuth
transmitter© 2015 Open Geospatial Consortium

521

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

Data Type

Range

Unit Key

Sint32+/-180Deg

GeoCoordinate

x,y,z

-

BaAzRiAngl

Float32+/-180Deg

Back azimuth proportional right angle

BaAzRiCove

Sint32+/-180Deg

Back azimuth right coverage

BaAzTrBear

Float32+/-180Deg

Back azimuth true bearing in degrees

BaAzXOffse

Float32-

Ft

Back azimuth X offset

BaAzYOffse

Float32-

Ft

Back azimuth Y offset

Category

LandingAidCategory

0-9-Category/class of the MLS

ChannelString

6 chars-

Collocatio

MlsCollocation

0-3-

MLS collocation information

CountryCountryEntry

0-336

-

2116 Country where the MLS is located

Point3

GeoCoordinate

x,y,z

-

MLS Datum point position (longitude, latitude, altitude)

DaPoXOffse

Float32-

Ft

Datum point X offset

DaPoYOffse

Float32-

Ft

Datum point Y offset

EleAngSpa

Float32+/-180Deg

Elevation angle span

EleMinAngl

Float32+/-180Deg

Elevation minimum angle

EleNomAngl

Float32+/-180Deg

Elevation nominal angle

BaAzLeCove
Point2

Description
Back azimuth left coverage
Position (longitude, latitude, altitude) of the MLS backazimuth transmitter

2110 Assigned channel© 2015 Open Geospatial Consortium

522

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

Data Type

Range

GeoCoordinate

x,y,z

-

Elevation position (longitude, latitude, altitude)

EleXOffse

Float32-

Ft

Elevation X offset

EleYOffse

Float32-

Ft

Elevation Y offset

Frequency

Uint64-

Hz 2104 Frequency

HigRatAppr

LogicalBoolean-

MLS high rate approach available

Ident

String

6 chars-

MLS ICAO ident

MagneVaria

Float32+/-180Deg

Magnetic variation

Name

String50 chars-

Official name of the MLS

RunwaIden

String

6 chars-2111 Ident of the associated runway

RunStoNumb

Uint64--Storage number of the associated runway

SynchTyp

SynchronizationType

0-2-

Synchronization Type

ThrCroHeig

Uint32-Ft

Height above the landing threshold on a normal glidepath

Point4

Unit Key

Description© 2015 Open Geospatial Consortium

523

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

Msa
Attribute Name
StoraNumbe

Data TypeUint64

Range
-

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirIcaCod

String

4 chars-

Airport/Heliport ICAO CodeAirpoIden

String

6 chars-

AirStoNumb

Uint64--

Airport/Heliport Storage Number

CountryCountryEntry

0-336

-

2116 Country where the MSA applies

IcaoCode

String

4 chars-

MSA ICAO Code

MagTruIndi

MagneticTrueIndication

0-6-

Magnetic/True Indication

MsaCenter

String

6 chars-

MsCeFiStNu

Uint64--

MsaCenTyp

FixRecordType

0-8-2107 MSA Center TypeMultiCod

String2 chars-2118 Multiple Code

NavKeyCod

Uint32

2 chars-

Navaid key code if MSA center is a navaid

NavaidType

NavaidType

0-15

-

Navaid type if MSA center is a navaid

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the MSA center
fix

String50 chars-

2111 Identifier of the terminal procedure associated with MSA

Point1
RouteIdent

Unit Key- 2101 Storage number.

Description

2108 Airport/Heliport Ident

2102 MSA Center
MSA Center Fix Storage Number© 2015 Open Geospatial Consortium

524

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

Data Type

Range

RouteType

RouteType

0-4

Unit Key-Type of terminal procedure associated with MSA

Description

SectoAltit

Uint32-Ft

Sector Altitude

SecEndBear

Uint320-359

Deg

Sector End Bearing

SecEndRadi

Uint32-

Nm

Sector Radius

SecStaBear

Uint320-359

Deg

Sector Start Bearing

SecStaRadi

Uint32-

Nm

Sector Start Radius

SectoAlti1

Uint32Ft

Sector Altitude

SecEndBea1

Uint320-359

Deg

Sector End Bearing

SectoRadiu

Uint32-

Nm

Sector Radius

SecStaBea1

Uint320-359

Deg

Sector Start Bearing

SectoAlti2

Uint32-Ft

Sector Altitude

SecEndBea2

Uint320-359

Deg

Sector End Bearing

SectoRadi1

Uint32-

Nm

Sector Radius

SecStaBea2

Uint320-359

Deg

Sector Start Bearing

SectoAlti3

Uint32-Ft

Sector Altitude

SecEndBea3

Uint320-359

Deg

Sector End Bearing

SectoRadi2

Uint32-

Nm

Sector Radius

SecStaBea3

Uint320-359

Deg

Sector Start Bearing© 2015 Open Geospatial Consortium

525

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

Range

SectoAlti4

Attribute Name

Uint32-

Unit Key
Ft

Sector Altitude

Description

SecEndBea4

Uint320-359

Deg

Sector End Bearing

SectoRadi3

Uint32-

Nm

Sector Radius

SecStaBea4

Uint320-359

Deg

Sector Start Bearing

SectoAlti5

Uint32-Ft

Sector Altitude

SecEndBea5

Uint320-359

Deg

Sector End Bearing

SectoRadi4

Uint32-

Nm

Sector Radius

SecStaBea5

Uint320-359

Deg

Sector Start Bearing

SectoAlti6

Uint32-Ft

Sector Altitude

SecEndBea6

Uint320-359

Deg

Sector End Bearing

SectoRadi5

Uint32-

Nm

Sector Radius

SecStaBea6

Uint320-359

Deg

Sector Start Bearing© 2015 Open Geospatial Consortium

526

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

NavaidAttribute Name
StoraNumbe

Data TypeUint64

Range-

Unit Key- 2101 Storage number.

Description

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirIcaCod

String

4 chars-

ICAO code of the associated airport/heliport

AirpoIden

String

6 chars-

AirStoNumb

Uint64--Storage number of the associated airport/heliport

AsCoStNumb

Uint64--

Associated Comms record storage number

AssMarTyp

AssociatedMarkerType

0-4-

Associated marker type

BfoOperati

LogicalBoolean-

BFO operation flag

BiasedIls

LogicalBoolean-Biased ILS flag

ChannelString

6 chars-2110 Assigned channel

Collocatio

NavaidCollocation

0-8-

Navaid collocation information

CompoTypComponentType

0-10

-

Component type (e.g.: DME, locator, etc.)

CountryCountryEntry

0-336

-

Declinatio

Float32+/-180Deg

DecliRefer

MagneticTrueIndication

0-6-

Magnetic, True, or other (grid direction)

DmeIdent

String

6 chars-

DME identifier

2108 Ident of the associated airport/heliport

2116 Country where the navaid is locatedStation declination© 2015 Open Geospatial Consortium

527

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

Data Type

Range

Float32

Unit Key

DescriptionNm

DME offset

Point2

GeoCoordinate

x,y,z

-

DME position (longitude, latitude, altitude)

EmissTyp

EmissionType

0-3-

Emission type (A0, A1 or A2)

Frequency

Uint64-

Hz 2104 Navaid frequency

FreProAlti

Uint32-Ft

Frequency protection altitude

FreProDist

Uint32-

Nm

Frequency protection distance

IcaoCode

String

4 chars-2103 Navaid ICAO area code

Ident

String

6 chars-2102 Navaid ICAO Ident

KeyCodeUint32--Distinguish between same type navaid with same ident and2118 country

LocalBeari

Float32+/-180Deg

LocBeaRefe

MagneticTrueIndication

0-6-

LocalWidt

Float32+/-180Deg

Localizer width

MagneVaria

Float32+/-180Deg

Magnetic variation

Modulation

SignalModulation

0-2-

Modulation (400Hz or 1020Hz)

Name

String45 chars-

Navaid official name

NexNavDist

Uint32-

Nm

Distance to the next navaid

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the NavObject

Point1

Localizer bearing
Magnetic, True, or other (grid direction)© 2015 Open Geospatial Consortium

528

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

Range

Power

Attribute Name

Uint32-

Watt

PreciDm

LogicalBoolean-Precision vs non-precision DME

RadClaCod

RadioClassCode

0-7-

Navaid radio class code

Uint32-Nm

Navaid power capacity

RangeRelia

RangeReliability

0-10

-

Navaid range reliability

RepetRat

Uint32-

1/min

NDB repetition rate [number of occurrences per minute]

RunwaDista

Float32-

Nm

Distance to associated runway

RunwaIden

String

6 chars-

Associated runway identifier

StateStateEntry

0-51

-

State or province name where the navaid is locatedStatusNavaidStatus

0-3-

Navaid status

SynchTyp

SynchronisationType

0-2-

Navaid synchronization type

ThrCroHeig

Uint32-Ft

Threshold crossing height

NavaidType

0-15

-

2107 Navaid type

VhfNavaid

LogicalBoolean-2122 Flag indicating if navaid is a VHF navaid.

VoIdFiPat

String30 chars-

Voice identifier file name and path

VoiIdePres

LogicalBoolean-

Voice identifier present flag

VoiOnFrequ

LogicalBoolean-

Voice on frequency presence flag

VoOnFrFil

String30 chars-

Voice on frequency file link

Range

Type

Unit Key

Description
Navaid power capacity© 2015 Open Geospatial Consortium

529

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

Range

WeathBroad

Attribute Name

WeatherBroadcast

0-2

Unit Key-

Weather broadcast information

Description

WeaBroFil

String30 chars-

Weather broadcast file link

© 2015 Open Geospatial Consortium

530

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

Off Route Terrain Clearance Altitude
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

AHGT

Logical1

AlterIden

String

8 chars

Altitude

Uint32

-

Ft

Ident

String

8 chars-

Point2

GeoCoordinate

Point1

GeoCoordinate

Point3

GeoCoordinate

Point4

GeoCoordinate

x,y,z
x,y,z
x,y,z
x,y,z

-

Description

Absolute Height above surface level Flag. Always true.
2108 Alternate OffRouteTerrainClearanceAlt identifier
Altitude: 1000ft clearance in non-mountainous & 2000ft inmountainous areas of US and 3000ft clearance for NIMA products.
2102 OffRouteTerrainClearanceAlt identifier-

North east corner (longitude, latitude, altitude) of the cell in which
altitude applies-

North west corner (longitude, latitude, altitude) of the cell in which
altitude applies-

South east corner (longitude, latitude, altitude) of the cell in which
altitude applies-

South west corner (longitude, latitude, altitude) of the cell in which
altitude applies© 2015 Open Geospatial Consortium

531

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

ParachuteJumpArea

Attribute Name
StoraNumbe

Data TypeUint64

Range
-

Unit
-

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AltitRefer

AltitudeReference

0-4-

Altitude reference (eg: AMSL, AGL, etc.)

CountryCountryEntry

0-336

-

EffecAltit

Sint32-Ft

Altitude for which the area is effective

EffecTim

String50 chars-

Indicates hours, dates, or condition of operation

IcaoCode

String

4 chars-

ICAO region code

Ident

String

8 chars-

Name

String50 chars-

Official name assigned to the jump area

OperaHour

String20 chars-

Actual hours of operation

OperaTim

String95 chars-

Operating times of the area

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

StateEntry

0-51

-

State or province where the jump area is located

Point1
StateName

Key
2101

2116

2102

Description
Storage number.

Country where the parachute jump area is located

DAFIF parachute jump area identifier© 2015 Open Geospatial Consortium

532

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

ParachuteJumpAreaBoundary

Attribute Name
StoraNumbe
AHGT

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

Logical1-Absolute Height above surface level Flag. Always true.

ArcSegDeri

ArcSegmentDerivation

0-3-

Indicates how the arc segment is defined

Bearing1

Float32+/-180Deg

Bearing from navigational aid to designated area

Bearing2

Float32+/-180Deg

Bearing from navigational aid to designated area

BoundShap

BoundaryShape

0-8-Type of area point being plotted by positions, radii, etc.

Point2

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of circle or arc center

CountryCountryEntry

0-336

-

Distance1

Float32-

Nm

Distance from navigational aid to the designated area

Distance2

Float32-

Nm

Distance from navigational aid to the designated area

IcaoCode

String

4 chars-

ICAO code

Ident

String

8-2102 DAFIF parachute jump area identifier

NavaiCount

CountryEntry

0-336

-

Country where the navaid is located

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32--

Navaid key code

GeoCoordinate

x,y,z

-

Navaid position (longitude, latitude, altitude)

Point32116 Country in which boundary segment is located© 2015 Open Geospatial Consortium

533

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

Uint64--

Associated navaid storage number

NavaidType

NavaidType

0-15

-

Navaid type

PaJuArStNu

Uint64--Storage number of associated ParachuteJumpArea record

Radius1

Float32-

Nm

Radius of arc or circle from the center position

Radius2

Float32-

Nm

Radius of arc or circle from the center position

Point1

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

Point4

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the segment end
position

Point5

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the segment start
position

Uint32--

ParachuteJumpAreaType

0-7-

SequeNumbe
Type

2115 Sequence number
Parachute jump area boundary type© 2015 Open Geospatial Consortium

534

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

PathPoint

Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-

AirpoIden

String6chars-

AirStoNumb

Uint64--

Associated airport/heliport storage number

AppPerDesi

ApproachPerformance

0-0-

Indicates the category type of the approach (APD)

AppRouIden

String6
chars-

Identifier of the approach route to be flown

AppSegTypApproachSegmentType

0-1-

Type of the final approach segment (operations type)CountryEntry

0-336

-

FlPaAlElHe

Sint32-Ft

Surveyed height in reference to WGS-84 ellipsoid

FlPaAlOrHe

Sint32-Ft

Surveyed height in reference to Mean Sea Level (MSL)

GeoCoordinate

x,y,z

-

Flight path alignment point (FPAP) position (longitude, latitude,
altitude)Country

Point2Absolute Height above surface level Flag. Always true.
2102 Associated airport/heliport identifier

2116 Country in which the airport/heliport is locatedGlideAngl

Float32+/-180 Deg

Intended descent angle for final approach flight path

IcaoCode

String4
chars-

ICAO code for the airport/heliport

LaThElHeig

Sint32-Ft

Surveyed height in reference to WGS-84 ellipsoid© 2015 Open Geospatial Consortium

535

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

Sint32-Ft

Surveyed height in reference to Mean Sea Level (MSL)

GeoCoordinate

x,y,z

-

Landing threshold point (LTP) position (longitude, latitude, altitude)

LengtOffse

Uint32-

Ft

Distance from stop end of runway (SER) to the FPAPRePaDaSele

PathDataSelector

0-0-

Reference path data selector enables automatic tuning of aprocedure by Ground Based Augmentation Systems (GBAS) avionics

RefPatIden

String6
chars-

Ident to confirm selection of correct approach procedure

RouteIndic

String

25
chars

-

Differentiates between multiple final approach segments to the same
runway or helipad (single alpha character)

RunwaIden

String6chars-

Associated runway/helipad identifier

ServiProvi

ServiceProvider

0-0-

Associates approach procedure to a particular Satellite BasedApproach System (SBAS) service provider

ThrCouWidt

Float32-

Ft

Width of lateral course at Landing Threshold Point

ThrCroHeig

Uint32

6

Ft

Height above landing threshold on a normal glidepath

Point1© 2015 Open Geospatial Consortium

536

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

PreferredRoute

Attribute Name
StoraNumbe

Data TypeUint64Range-

Logical1-Absolute Height above surface level Flag. Always true.

AircrGrou

AircraftGroup

0-21

-

Types of aircrafts permitted to use the route

AirwaLeve

AirwayLevel

0-3-

Airway level (high, low, or both)

AlRoAiGrou

AircraftGroup

0-21

-

Types of aircrafts permitted to use the alternate route

AltitDescr

AltitudeDescription

0-13

-

Description of how segment altitude limits should be applied

DirecRestr

DirectionRestriction

0-3-

Direction restriction (forward, backward, either)

EffecTime

String50 chars-

Period during which preferred route is effective

EffecTime1String50 chars-

Period during which preferred route is effective

EffecTime2String50 chars-

Period during which preferred route is effective

FixCountry

CountryEntry

0-336

-

FixIcaCod

String

4 chars-

ICAO code of fix point

FixIdent

String30 chars-

Fix identifier (may be name if ident not available)

FiNaKeCod

Uint32--Key code of fix point for navaid fix

FixPoiTypFixPointType

0-19

-

Fix point type for navaid and ATS fixes

FiPoReTyp

FixPointRecordType

0-13

-

Fix record type

AHGT

Unit Key- 2101 Storage number.

Description

2116 Country where the fix point is located© 2015 Open Geospatial Consortium

537

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

Range

FixStoNumb

Attribute Name

Uint64

-

-

Ident

String

8 chars-

InFiIcCod

String

4 chars-

ICAO code of the initial fix point

IniFixIden

String

6 chars-

Identifier of departure airport or initial fix of the route

IniFixNam

String50 chars-Name of the initial fix point

InFiReTyp

FixRecordType

0-8-

Initial fix record typeInFiStNumb

Uint64--Storage number of the associated initial fix point

MaxRouAlti

Sint32-Ft

Maximum altitude limit for route

MaSpLiFla

LogicalBoolean-Speed limit represents maximum speed allowed (FALSE - min speed)

MinRouAlti

Sint32-Ft

Minimum altitude limit for route

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of fix point

RefRouIden

String

6 chars-

Reference route identifier (route to be flown)

RnaReqFla

LogicalBoolean-

RNAV equipment required flag

RouteUseRouteUse

0-2-

Route use (point-to-point or area-to-area)

RoutiTyp

RoutingType

0-7-

Type of reference route

SegAltLimi

Sint32-Ft

Segment altitude limit 1

SegAltLim1

Sint32-Ft

Segment altitude limit 2

SequeNumbe

Uint32--

Sequence number

Point1

Unit Key

Description
Fix storage number

2102 Route identifier© 2015 Open Geospatial Consortium

538

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

Range

SpeedLimit

Attribute Name

Uint32-

Unit Key
Kts

Speed limit for the route

Description

TeFiIcCod

String

4 chars-

ICAO code of the terminal fix point

TerFixIden

String

6 chars-

Identifier of arrival airport or terminal fix of the route

TerFixNam

String50 chars-Name of the terminal fix point

TeFiReTyp

FixRecordType

0-8-

Terminal fix record typeTeFiStNumb

Uint64--Storage number of the associated terminal fix point

TimeCode

PrimaryTimeCode

0-4-

Describes continuity of time of applicability

Type

PreferredRouteType0-9-

Preferred route type© 2015 Open Geospatial Consortium

539

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

Preset Site

Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-

AirTruBear

Float32

0-360

Deg

AirpoIden

String

6 chars-

AirStoNumb

Uint64

-

-

Ident

String32 chars-

Point1

GeoCoordinate

x,y,z

-

Preset site position (longitude, latitude, altitude)

Runwalden

String

6 chars-

Ident of the associated runway

RunStoNumb

Uint64--Storage number of the associated runway

SegmeNumbe

Uint32--The segment number of the preset site, if it belongs to a segment group

PresetSiteType

0-8-

Type of preset site

Type

Absolute Height above surface level Flag. Always true.
True bearing of aircraft at the preset site2108 Identifier of the associated airport
Storage number of the associated airport
2102 PresetSite identifier© 2015 Open Geospatial Consortium

540

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

RestrictiveAirspace

Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-

AirspDesig

String

6 chars-2102 Restrictive airspace designation

AirResTyp

AirspaceRestrictionType

0-9-

Restrictive airspace type

ArcBearing

Float32+/-180Deg

Arc bearing

ArcDistanc

Float32-Nm

Arc distance

ArcDistan1

Float32-Nm

Arc distance (radius of arc from center point)

GeoCoordinate

x,y,z

-

Arc origin position (longitude, latitude, altitude)

ArcSegDeri

ArcSegmentDerivation

0-3-

Indicates how the arc segment is defined

Bearing1

Float32+/-180Deg

True bearing from arc origin or navaid

Bearing2

Float32+/-180Deg

True bearing from arc origin or navaid

BoundEn

LogicalBoolean-End of boundary description - return to origin point

BoundShap

BoundaryShape

0-8-

Boundary shape typeCountryCountryEntry

0-336

-

2116 Country where airspace is located

IcaoCode

String

4 chars-

ICAO code for the airspace

AirwayLevel

0-3-

Type of airway (high, low, or either)

Point3

Level

Absolute Height above surface level Flag. Always true.

© 2015 Open Geospatial Consortium

541

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

Sint32-

Ft

Lower limit

LoLiAlRefe

AltitudeReference

0-4-

Altitude reference

MultiCod

String2 chars-

Differentiate between airspaces with same designator

Name

String50 chars-

Restrictive airspace nameNavaiCount

CountryEntry

0-336

-

Country in which navaid is located

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32--Distinguish between same type navaid with same ident and country

NavaidType

NavaidType

0-15

-

Navaid type

Notam

LogicalBoolean-

Active times by NOTAM

Point2

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude)

Point1

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

SectorString100 chars-

SequeNumbe

Uint32--

Sequence number

SpUsAiStNu

Uint64--

Associated SpecialUseAirspace storage number

TimeCode

PrimaryTimeCode

0-4-

Time codes for primary records

UpperLimit

Sint32-Ft

Upper limit

UpLiAlRefe

AltitudeReference

0-4-

Reference for upper limit altitude

H.36

2117 Designation for the section of the airspace

Runway© 2015 Open Geospatial Consortium

542

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

Data Type

Range Unit Key

Description

Uint64--

Logical1-

AirIcaCod

String

4 chars-2103 Associated Airport ICAO code.

AirpoIden

String

6 chars-

2108 Associated Airport identifier.

AirStoNumb

Uint64--

Associated Airport storage number.

Point1

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the runway
approach end.

Bearing

Float32+/-180Deg

CeLiLiFla

LogicalBoolean-Indicates presence of lights on center line.

ClosedFlag

LogicalBoolean-Indicates if the runway is closed or unusable.

CountryCountryEntry

0-336

-

Descriptio

Stringmemo-

Runway description.

DisThrDist

Uint32-

Ft

Distance between the beginning of the runway andthe displaced threshold.

Point2

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of the displaced
threshold (latitude, longitude, elevation).

Ident

String

6 chars-

LanAidCate

LandingAidCategory

0-9-Category of the primary landing aid (ILS, MLS, GLS).

LanAidIden

String

6 chars-

Primary landing aid (ILS, MLS or GLS) identifier.

AHGT2101 Storage number.
Absolute Height above surface level Flag. Always
true.

Magnetic bearing.

2116 Runway country.

2102 Runway identifier.

© 2015 Open Geospatial Consortium

543

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

Data Type

Range Unit Key

Description

LandiDista

Uint32-Ft

Landing distance available.

LengthUint32-

Ft

Runway length.

LightSyste

LightingSystem

0-64

-

Lighting system 1.

LightSyst1

LightingSystem

0-64

-

Lighting system 2.

LightSyst2

LightingSystem

0-64

-

Lighting system 3.

LightSyst3

LightingSystem

0-64

-

Lighting system 4.

LightSyst4

LightingSystem

0-64

-

Lighting system 5.

LightSyst5

LightingSystem

0-64

-

Lighting system 6.

LightSyst6

LightingSystem

0-64

-

Lighting system 7.

LightSyst7

LightingSystem

0-64

-

Lighting system 8.

MaxTirPres

MaximumTirePressure

0-4

Psi

Maximum tire pressure authorized.

PavemClass

Uint32--

Pavement classification number.

PavEvaMeth

PavementEvaluationMethod

0-2-

Pavement evaluation method.

PavSubCate

PavementSubgradeCategory

0-4-

Pavement subgrade category.

PavemTyp

PavementType

0-3-

Type of pavement.

SeLaAiCate

LandingAidCategory

0-9-Category of the second landing aid (ILS, MLS, GLS).

SeLaAiIden

String

6 chars-

Second landing aid (ILS, MLS or GLS) identifier.

Slope

Float32-%

Runway gradient.

© 2015 Open Geospatial Consortium

544

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

Data Type

Range Unit Key

Description

GeoCoordinate

x,y,z

-

Position (longitude, latitude, elevation) of the runway
stop end.

StopwLengt

Uint32-

Ft

Length of the area beyond the takeoff runway.

StoSurTyp

RunwaySurfaceType

0-21

-

Stopway surface type.

SurfaTyp

RunwaySurfaceType

0-21

-

Runway surface type.

TakeoDista

Uint32-

Ft

Takeoff distance available.

ThrCroHeig

Uint32-Ft

Height above the landing threshold on a normal
glidepath.

TouZonElev

Float32-

Ft

Highest elevation in the first 3000 ft of landing
surface.

TrueBearin

Float32+/-180Deg

Runway true bearing.

TruNorRefe

LogicalBoolean-True North reference flag.

Width

Uint32-

Ft

Runway width.

© 2015 Open Geospatial Consortium

545

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

Sid
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirStoNumb

Uint64--

Airport storage number

Altitude1

Sint32-

Ft

First altitude limit

AltitTyp

AltitudeType

0-4-

Altitude 1 type

Altitude2

Sint32-

Ft

Second altitude limit

AltitTyp1

AltitudeType

0-4-

Altitude 2 type

AltitDescr

AltitudeDescription

0-13

-

Altitude description

ArcRadius

Float32-Nm

Arc radius

CenterFix

String10 chars-

Point which defines the center of the arc flight path

CeFiIcCod

String

4 chars-

ICAO code of the center fix

CountryCountryEntry0-336- 2116 Country associated with the terminal procedure

CourseFloat32

FixDetails

FixDetails

0-9-

Fix details

FixFunctio

FixFunction

0-7-

Fix function

FixIcaCod

String

4 chars-

ICAO code of the fix point+/-180 Deg

Outbound course from waypoint in fix ident© 2015 Open Geospatial Consortium

546

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

Data Type
StringRange Unit Key
10 chars Fix identifier

Description

FlyOveTyp

FlyOverType0-4-

Fly over type

MagCouIndi

MagneticTrueIndication

0-6-

Indicates if the course provided is magnetic course

NavaiCount

CountryEntry

0-336

-

Country where recommended navaid 1 is located

Point2

GeoCoordinate

x,y,z

-

Navaid 1 DME position (longitude, latitude, altitude)

NavKeyCod

Uint32--Distinguish between navaid of same type with same ident insame country

NavMagVari

Float32+/-180 Deg

Recommended navaid 1 magnetic variation

GeoCoordinate

x,y,z

-

Navaid 1 position (longitude, latitude, altitude)

NavaiTyp

SegmentNavaidType

0-13

-

Recommended navaid 1 type

NavaiCoun1

CountryEntry

0-336

-

Country where recommended navaid 2 is located

Point4

GeoCoordinate

x,y,z

-

Navaid 2 DME position (longitude, latitude, altitude)

NavKeyCod1

Uint32--Distinguish between navaid of same type with same ident insame country

NavMagVar1

Float32

Point3+/-180 Deg

Recommended navaid 2 magnetic variation

GeoCoordinate

x,y,z

-

Navaid 2 position (longitude, latitude, altitude)

NavaiTyp1

SegmentNavaidType

0-13

-

Recommended navaid 2 type

PathTermin

PathTermination

0-23

-

Path and Termination

ReNaIcCod

String

4 chars-

ICAO code of the recommended navaid 1

Point5© 2015 Open Geospatial Consortium

547

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

Data Type
StringRange Unit Key
Description
10 chars Recommended navaid identifier 1

RecNavIde1

String10 chars-

Recommended navaid identifier 2

ReqNavPerf

Float32-

Nm

Required navigation performance

RouteDista

Float32-

Nm

Distance in nautical miles from waypoint in fix ident

RouteType

RouteType

0-4-

Termination Procedure Type

SpeAirCate

AircraftCategory

0-4-

Aircraft category that speed limit 1 applies to

SpeedAltit

Sint32-Ft

Altitude where speed limit 1 applies

SpeedLimit

Uint32-

Kts

Speed limit 1

SpeAirCat1

AircraftCategory

0-4-

Aircraft category that speed limit 2 applies to

SpeedAlti1

Sint32-Ft

Altitude where speed limit 2 applies

SpeedLimi1

Uint32-

Kts

Speed limit 2

SuTeDaStNu

Uint64--Storage number of associated Supplemental Terminal Data
recordThrCroHeig

Uint32-Ft

Threshold crossing heightTransAltit

Sint32-

Ft

Transition altitude

TurnDirect

TurnDirection

0-3-

Turn direction

TurDirVali

LogicalBoolean-Turn direction valid

WaypoCount

CountryEntry

0-336

-

Waypoint country

WaypoDescr

WaypointDescription

0-15

-

Waypoint description© 2015 Open Geospatial Consortium

548

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

Range Unit Key
Description
Nm
Nautical miles between fix point and recommended navaid 1(RHO)

WaypoDista

Float32

WaypoDist1

Float32-

WayMagBear

Float32+/-180

WayMagBea1
WayMagVari

Nm

Nautical miles between fix point and recommended navaid 2

Deg

Magnetic bearing between fix point and recommended navaid 1(THETA)

Float32+/-180 Deg

Magnetic bearing between fix point and recommended navaid 2

Float32+/-180 Deg

Waypoint magnetic variation

GeoCoordinate

x,y,z

-

Waypoint position (longitude, latitude, altitude)

AirIcaCod

String

4 chars-

ICAO code of the associated airport

AirpoIden

String

6 chars- 2102 Identifier of the associated airport

Ident

String

8 chars- 2108 SID/STAR/Approach identifier

SequeNumbe

Uint32-

SidRouTyp

SidRouteType

TransIden

StringPoint1

H.38

Data Type0-12
60 chars-Sequence number-

SID route type-Transition identifier

Special Use Airspace
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key--

Description

2101 Storage number.

© 2015 Open Geospatial Consortium

549

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

Logical1-Absolute Height above surface level Flag. Always true.

AirwaLeve

AirwayLevel

0-3-

Airspace structure in which boundary is effective (high/low)

ComCalSig

String50 chars-

ContrAgenc

String60 chars-

Office responsible for air traffic within airspace

Country1

CountryEntry

0-336

-

2116 Country in which the special use airspace is locatedCountry2

CountryEntry

0-336

-

Country in which the special use airspace is locatedCountry3

CountryEntry

0-336

-

Country in which the special use airspace is locatedCountry4

CountryEntry

0-336

-

Country in which the special use airspace is locatedEffecDat

String12 chars-

Effective date of the special use airspace

EffecTim

String50 chars-

Times at which given airspace iWs to be in effectFrequency1

Uint64-Hz

Frequency for communicating with identified facility

Frequency2

Uint64-Hz

Frequency 2 used for communicating with identifed facility

IcaoCode

String

4 chars-

ICAO code of the special use airspace

Ident

String

6 chars-

LowEffAlti

Sint32-

Ft

Lower vertical limit of the given airspace

LoEfAlRefe

AltitudeReference

0-4-

Lower effective altitude reference

Name

String50 chars-

Official name of the special use airspace

Point1

GeoCoordinate

x,y,z

-

Reference Position (longitude, latitude, altitude)

RemarkStringmemo-

Essential information related to the given special use airspace

2111 Call sign of the communications facilities

2102 ICAO ident of special use airspace© 2015 Open Geospatial Consortium

550

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
SectorString2 chars-2117 Designation for the section of the special use airspace

Type

AirspaceRestrictionType

0-9-

Special use airspace type

UppEffAlti

Sint32-Ft

Upper vertical limit of the given airspace

UpEfAlRefe

AltitudeReference

0-4-Upper effective altitude reference

WeathCondi

WeatherCondition

0-7-

Meteorological conditions in which the airspace can be used

© 2015 Open Geospatial Consortium

551

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

Star
Attribute Name
StoraNumbe

Data TypeUint64

Range Unit Key- 2101 Storage number.

Description

Logical1-Absolute Height above surface level Flag. Always
true.

AirStoNumb

Uint64--

Airport storage number

Altitude1

Sint32-

Ft

First altitude limit

AltitTyp

AltitudeType

0-4-

Altitude 1 type

Altitude2

Sint32-

Ft

Second altitude limit

AltitTyp1

AltitudeType

0-4-

Altitude 2 type

AltitDescr

AltitudeDescription

0-13

-

Altitude description

ArcRadius

Float32-Nm

Arc radius

CenterFix

String10 chars-

Point which defines the center of the arc flight path

CeFiIcCod

String

4 chars-

ICAO code of the center fix

CountryCountryEntry

0-336

-

2116 Country associated with the terminal procedure

CourseFloat32+/-180Deg

Outbound course from waypoint in fix ident

FixDetails

FixDetails

0-9-

Fix details

FixFunctio

FixFunction

0-7-

Fix function

FixIcaCod

String

4 chars-

ICAO code of the fix point

AHGT© 2015 Open Geospatial Consortium

552

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

Data Type

Range Unit Key

Description

FixIdent

String10 chars-

Fix identifier

FlyOveTyp

FlyOverType0-4-

Fly over type

MagCouIndi

MagneticTrueIndication

0-6-

Indicates if the course provided is magnetic course

NavaiCount

CountryEntry

0-336

-

Country where recommended navaid 1 is located

Point2

GeoCoordinate

x,y,z

-

Navaid 1 DME position (longitude, latitude, altitude)

NavKeyCod

Uint32--Distinguish between navaid of same type with same
ident in same country

NavMagVari

Float32+/-180Deg

GeoCoordinate

x,y,z

-

NavaiTyp

SegmentNavaidType

0-13

-

Recommended navaid 1 type

NavaiCoun1

CountryEntry

0-336

-

Country where recommended navaid 2 is located

Point4

GeoCoordinate

x,y,z

-

Navaid 2 DME position (longitude, latitude, altitude)

NavKeyCod1

Uint32--Distinguish between navaid of same type with same
ident in same country

NavMagVar1

Float32+/-180Deg

Recommended navaid 2 magnetic variation

GeoCoordinate

x,y,z

-

Navaid 2 position (longitude, latitude, altitude)

NavaiTyp1

SegmentNavaidType

0-13

-

Recommended navaid 2 type

PathTermin

PathTermination

0-23

-

Path and Termination

ReNaIcCod

String

4 chars-

ICAO code of the recommended navaid 1

Point3

Point5

Recommended navaid 1 magnetic variationA

Navaid 1 position (longitude, latitude, altitude)© 2015 Open Geospatial Consortium

553

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

Data Type

Range Unit Key

Description

RecNavIden

String10 chars-

Recommended navaid identifier 1

RecNavIde1

String10 chars-

Recommended navaid identifier 2

ReqNavPerf

Float32-

Nm

Required navigation performance

RouteDista

Float32-

Nm

Distance in nautical miles from waypoint in fix ident

RouteType

RouteType

0-4-

Termination Procedure Type

SpeAirCate

AircraftCategory

0-4-

Aircraft category that speed limit 1 applies to

WWSpeedAltit

Sint32-Ft

Altitude where speed limit 1 applies

SpeedLimit

Uint32-

Kts

Speed limit 1

SpeAirCat1

AircraftCategory

0-4-

Aircraft category that speed limit 2 applies to

SpeedAlti1

Sint32-Ft

Altitude where speed limit 2 applies

SpeedLimi1

Uint32-

Kts

Speed limit 2

SuTeDaStNu

Uint64--Storage number of associated Supplemental Terminal
Data record

ThrCroHeig

Uint32-Ft

Threshold crossing heightTransAltit

Sint32-

Ft

Transition altitude

TurnDirect

TurnDirection

0-3-

Turn direction

TurDirVali

LogicalBoolean-Turn direction valid

WaypoCount

CountryEntry

0-336

-

Waypoint country© 2015 Open Geospatial Consortium

554

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

Data Type

Range Unit Key

Description

WaypoDescr

WaypointDescription

0-15

-

Waypoint description

WaypoDista

Float32-

Nm

Nautical miles between fix point and recommended
navaid 1 (RHO)

WaypoDist1

Float32-

Nm

Nautical miles between fix point and recommended
navaid 2

WayMagBear

Float32+/-180Deg

Magnetic bearing between fix point and recommended
navaid 1 (THETA)

WayMagBea1

Float32+/-180Deg

Magnetic bearing between fix point and recommended
navaid 2

WayMagVari

Float32+/-180Deg

Waypoint magnetic variation

GeoCoordinate

x,y,z

-

Waypoint position (longitude, latitude, altitude)

AirIcaCod

String

4 chars-

ICAO code of the associated airport

AirpoIden

String

6 chars-2102 Identifier of the associated airport

Ident

String

8 chars-

2108 SID/STAR/Approach identifier

SequeNumbe

Uint32--

Sequence number

StaRouTyp

StarRouteType

0-12

-

STAR route typeTransIden

String

6 chars-

Transition identifier

VertiAngl

Float32+/-180Deg

Point1

Descent angle for the procedure© 2015 Open Geospatial Consortium

555

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

Supplemental Terminal Data

Attribute Name

Data Type

Range Unit Key

Description

StoraNumbe

Uint64--

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AgencRespo

String

8 chars-

Military or federal agency primarily responsible for terminal procedure

AirpoIden

String

6 chars-

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of airport

AirStoNumb

Uint64--

Airport/Heliport storage number

AltMinTyp

AlternateMinimumType

0-2-

Alternate minimum not standard or not authorizedCountryCountryEntry

0-336

-

2116 Country associated with supplemental terminal procedure data

EmeSafAlti

Uint32-Ft

Safe altitude providing obstacle clearance [above MSL]

IcaoCode

String

4 chars-

Terminal procedure ICAO code

Ident

String

40
chars

-

OperaAgenc

String

255
chars

-

Host country agency with authority for the terminal procedure

RemarkStringmemo-

Essential information applying to the entire procedure

RouQuaTyp

RouteQualifierType

0-2-

Supplements route type - applies to GPS & RNAV type procedures

RouteType

RouteType

0-4-

Terminal procedure route type

Point12101 Storage number.

2108 Airport/Heliport identifierW

2102 Terminal procedure identifier© 2015 Open Geospatial Consortium

556

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

TakeoffMinimumType

TransAltit

Uint32

TransLeve

Uint32

0-1--

Takeoff minimum not standard and/or departure procedure are
published

Ft

Altitude below which vertical position controlled by reference to altitudes[above MSL]

Ft

Lowest flight level above transition altitude [above MSL]

© 2015 Open Geospatial Consortium

557

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

Terminal Procedure Climb

Attribute Name

Data Type

Range

Unit

StoraNumbe

Uint64--

AHGT

Logical1-

AirpoIden

String

6 chars-

AirStoNumb

Uint64--

Airport/Heliport storage number

ClimbAltit

Uint32-Ft

Altitude to which climb rate applies [above MSL]

ClimbFootn

String90 chars-Footnote associated with climb information

CliRatTyp

ClimbRateType

0-4-

Minimum rate, or ATC climb rate if higher than min. climb rate

CountryCountryEntry

0-336

-

DesceRat

Uint32-

Ft/m

IcaoCode

String

4 chars-

Ident

String40 chars-

MinCliRat

Uint32-

Kts

Minimum climb rate based on 60 knots

OccurNumbe

Uint32--

Number of occurrences for a given runway

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of airport

RouteType

RouteType

0-4-

Terminal procedure route typeRunwaIden

String

6 chars-

Runway at which the climb rate information applies

Point1Key

Description

2101 Storage number.
Absolute Height above surface level Flag. Always true.
2108 Airport/Heliport identifier

2116 Country associated with terminal procedure climb data
Minimum or ATC climb rate/descent [vertical velocity ft/min]Terminal procedure ICAO code
2102 Terminal procedure identifier© 2015 Open Geospatial Consortium

558

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

© 2015 Open Geospatial Consortium

559

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

Terminal Procedure Feeder Route
Attribute Name

Data Type

Range

Unit Key

StoraNumbe

Uint64--

AHGT

Logical1-

AirpoIden

String

6 chars-

AirStoNumb

Uint64--

Airport storage number

AltitudeSint32-Ft

Referenced altitude associated with feeder route segment

CountryCountryEntry

0-336

-

2116 Country associated with terminal procedure feeder route

CourseFloat32+/-180Deg

IcaoCode

String

4 chars-

Ident

String10 chars-

MagCouIndi

MagneticTrueIndication

0-6-

Indicates if course is given in degrees magnetic, true or otherRouteDista

Float32-

Nm

Distance between waypoint 1 and waypoint 2

RouteType

RouteType

0-4-

Terminal procedure route type

SequeNumbe

Uint32--2115 Feeder route sequence number

TerProIden

String40 chars-

2126 Terminal procedure identifier

WaypoCount

CountryEntry

0-336

-

Waypoint 1 country

WaypoIden

String

6 chars-

Waypoint 1 identifier

Description

2101 Storage number.
Absolute Height above surface level Flag. Always true.
2108 Airport identifier

Course from waypoint 1 to waypoint 2 in route segment
Feeder route ICAO code
2102 Feeder route identifier© 2015 Open Geospatial Consortium

560

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

GeoCoordinate

x,y,z

-

Waypoint 1 position (longitude, latitude, altitude)

WaypoCoun1

CountryEntry

0-336

-

Waypoint 2 country

WaypoIden1

String

6 chars-

Waypoint 2 identifier

GeoCoordinate

x,y,z

-

Waypoint 2 position (longitude, latitude, altitude)

Point2© 2015 Open Geospatial Consortium

561

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

Terminal Procedure Minima
Attribute Name

Unit Key

Description

Data Type

Range

StoraNumbe

Uint64--

AHGT

Logical1-

AirpoIden

String

6 chars-

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of airport

AirStoNumb

Uint64--

Airport/Heliport storage number

ApproTypString30 chars-

CaADeHeigh

Uint32

CaAHeAbTou

Uint32

CaAPrVisib

Float32

CaARuVisib

Float32

CaAWeCeili

Float32

CaBDeHeigh

Uint32

CaBHeAbTou

Uint32

CaBPrVisib

Float32

Point12101 Storage number.
Absolute Height above surface level Flag. Always true.
2108 Airport/Heliport identifier

2107 Type of approach on which minimum data is based

Ft

Height above highest elevation in the touchdown zone - for astraight in or glideslope approach [above MSL]-

Ft

Height above highest elevation in the touchdown zone-m

Designated visibility for the approachm

Determined by atmospheric conditions or instrumentally derived
value for runway visual rangem

Height equal to or greater than decision height or minimum
descent altitude above airport or heliport elevation

Ft

Height above highest elevation in the touchdown zone - for astraight in or glideslope approach [above MSL]-

Ft

Height above highest elevation in the touchdown zone-m

Designated visibility for the approach--© 2015 Open Geospatial Consortium

562

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

Data Type

CaBRuVisib

Float32

CaBWeCeili

Float32

CaCDeHeigh

Uint32

CaCHeAbTou

Uint32

CaCPrVisib

Float32

CaCRuVisib

Float32

CaCWeCeili

Float32

CaDDeHeigh

Uint32

CaDHeAbTou

Uint32

CaDPrVisib

Float32

CaDRuVisib

Float32

CaDWeCeili

Float32

CaEDeHeigh

Uint32

Range

Unit Key

Descriptionm

Determined by atmospheric conditions or instrumentally derived
value for runway visual rangem

Height equal to or greater than decision height or minimum
descent altitude above airport or heliport elevation

Ft

Height above highest elevation in the touchdown zone - for astraight in or glideslope approach [above MSL]-

Ft

Height above highest elevation in the touchdown zone-m

Designated visibility for the approachm

Determined by atmospheric conditions or instrumentally derived
value for runway visual rangem

Height equal to or greater than decision height or minimum
descent altitude above airport or heliport elevation

Ft

Height above highest elevation in the touchdown zone - for astraight in or glideslope approach [above MSL]-

Ft

Height above highest elevation in the touchdown zone-m

Designated visibility for the approachm

Determined by atmospheric conditions or instrumentally derived
value for runway visual rangem

Height equal to or greater than decision height or minimum
descent altitude above airport or heliport elevation

Ft

Height above highest elevation in the touchdown zone - for astraight in or glideslope approach [above MSL]

-

-

-

© 2015 Open Geospatial Consortium

563

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

Unit Key

Description

Data TypeRange

CaEHeAbTou

Uint32-Ft

Height above highest elevation in the touchdown zone

CaEPrVisib

Float32-m

Designated visibility for the approach

CaERuVisib

Float32m

Determined by atmospheric conditions or instrumentally derived
value for runway visual range

CaEWeCeili

Float32m

Height equal to or greater than decision height or minimum
descent altitude above airport or heliport elevation-

CountryCountryEntry

0-336

-

IcaoCode

String

4 chars-

Ident

String40 chars-

2102 Terminal procedure identifier

RouteType

0-4-

Terminal procedure route type-

Remarks give conditions affecting published approach
minimums

RouteType
RemarkStringmemo

2116 Country associated with terminal procedure minima data
Terminal procedure ICAO code

© 2015 Open Geospatial Consortium

564

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

VfrRoute
Attribute Name

Data Type

Range

StoraNumbe

Uint64--

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirIcaCod

String

4 chars-

ICAO code of the associated airport/heliport

AirpoIden

String

6 chars-

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of airport

Uint64--Storage number of the associated airport/heliportCountryCountryEntry

0-336

-

RemarkStringmemo-

RouteIdent

String

6 chars-2102 Route identifier

RouteName

String40 chars-Route name

Point1
AirStoNumb

Unit Key

Description

2101 Storage number.

2111 Identifier of the associated airport/heliport

2116 Country where the airport/heliport is locatedEssential information pertaining to part or to all route
procedures at the airport/heliport© 2015 Open Geospatial Consortium

565

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

VfrRouteSegment

Attribute Name

Data Type

Range Unit Key

Description

StoraNumbe

Uint64--

AHGT

Logical1-

AirIcaCod

String

4 chars-2103 ICAO code of the associated airport/heliport

AirpoIden

String

6 chars-2111 Identifier of the associated airport/heliport

AirStoNumb

Uint64--Storage number of the associated airport/heliport

Altitude

Uint32Ft

Reference altitude [above sea level]

CountryCountryEntry

0-336

-

2116 Country where the airport/heliport is locatedCourseFloat32+/-180Deg

Inbound course to the point/checkpoint

MagneticTrueIndication

0-6-

Course reference (magnetic/true)

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) 0.5nm, at 90 degree angle
to heading, to left of checkpoint

MgrsPositi

String20 chars-

MGRS position given using the UTM or the UPS grid

PathType

PathType

0-6-

Defines how the route is used (eg: arrival, departure, etc.)

PointName

String25 chars-

Official name of point/checkpoint

PointDescr

String40 chars-

Landmark, graphical description of point/checkpoint

PoiRepTyp

PointReportingType

0-2-

Indicates if point is compulsory for graphic presentation of theroute

CoursRefer
Point22101 Storage number.
Absolute Height above surface level Flag. Always true.

© 2015 Open Geospatial Consortium

566

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

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) of point/checkpoint

Point3

GeoCoordinate

x,y,z

-

Position (longitude, latitude, altitude) 0.5nm, at 90 degree angle
to heading, to right of checkpoint

RouteIdent

String

6 chars-2102 Route identifier

RouteName

String40 chars-Route name

SegAltDesc

SegmentAltitudeDescription

0-5-

Defines how the given altitude applies to the segment

SegmeNam

String25 chars-

Official segment name

SegmeNumbe

Uint32--

SegTurDire

PathTurnDirection

0-2-

Direction in which course turns are to be madeSegmeTyp

SegmentType

0-3-

Indicates if segment is a starting, next, or ending segment

SOEAAFla

LogicalBoolean-Flag indicating whether or not the segment starts or ends at an
airport/heliport

VfRoStNumb

Uint64--Storage number of the associated VFR route record

2115 Defines relative position of segment in total VFR route segment© 2015 Open Geospatial Consortium

567

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

Waypoint

Attribute Name

Data Type

Range

StoraNumbe

Uint64--

AHGT

Logical1-Absolute Height above surface level Flag. Always true.

AirIcaCod

String

4 chars-

ICAO code of the associated airport.

AirpoIden

String

6 chars-

Ident of the associated airport.

AirStoNumb

Uint64--Storage number of the associated airport.

Bearing

Float32+/-180Deg

BeariRefer

MagneticTrueIndication

0-6-

Bearing reference (magnetic, true, or 'grid')

ColloNavai

LogicalBoolean-Waypoint collocated with a navaid flag

CountryCountryEntry

0-336

-

2116 Country where the waypoint is locatedDistance

Float32-

Nm

Distance from navaid to waypoint

DynMagVari

Float32+/-180Deg

Dynamic magnetic variation

FixType

FixType

0-16-

IcaoCode

String

4 chars-2103 ICAO code of waypoint

Ident

String

6 chars-2102 Waypoint Identifier

Name

String50 chars-

Waypoint name/description

NameFormatType

0-16

-

Format of waypoint name field

NameFormat

Unit Key

Description

2101 Storage number.

Bearing from navaid to waypointFix Type© 2015 Open Geospatial Consortium

568

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

CountryEntry

0-336

-

Country where navaid is located

NavaiIden

String

6 chars-

Navaid identifier

NavKeyCod

Uint32--Distinguish between same type navaid with same ident and country

NavaidType

NavaidType

0-15

-

Navaid type

GeoCoordinate

x,y,z

-

Waypoint Position (longitude, latitude, altitude)

RnavWaypoi

LogicalBoolean-Waypoint is a RNAV waypoint

RouteType

RouteType

0-4-

Route type

RunIcaCod

String

6 chars-

Runway ICAO code

RunwaIden

String

6 chars-

Runway identifier

RvsmIndica

RvsmIndicator

0-5-

Waypoint RVSM indicatorStateName

StateEntry

0-51

-

State or province where waypoint is locatedType

WaypointType

0-15

-

Waypoint type

Usage

WaypointUsageType0-9-

Waypoint usage type

FixRecordType

0-8-2122 Waypoint record type

Point1

WayRecTyp© 2015 Open Geospatial Consortium

569

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

Appendix I
I. Navaids Attribution Enumeration Values
This section describes the attributes specific to each NAV category whose values are
enumerated in accordance to this appendix.

© 2015 Open Geospatial Consortium

571

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

Enumerator Description

BoxRegionType

ValuesRemained Region0

Added Region

1

Removed Region

2

All aircrafts

0

Jets only1

Turbo props only

2

Other

3

Not Defined4

All Aircraft0

All Aircraft, Cruise speed 250 kts or less1

Non-Jet and Turbo Prop

2

Multi-Engine Props Only3

Jets & Turbo Props/Spec., Cruise Spd 190kts or greater

4

Helicopter Only

5

Jet Power

6

Turbo-Prop/Special, Cruise Speed 190 kts or greater

7

Non-Jet, Non-Turbo Prop

8

Non-Jet, Cruise Speed 190 kts or greater

9

Non-Jet, Cruise Speed 189 kts or less10

Aircraft as defined in a Continuation Record Note

11

Single Engine

12

AircraftCategory

AircraftGroup© 2015 Open Geospatial Consortium

572

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

Enumerator Description
Twin Engine

Values13

Non Turbo Jets

14

Non Jets

15

Props

16

Turbo Props

17

Turbo Jets

18

Water Turbo Jets

19

Water Turbo Props20

Not defined

21

Advisory Area (ADA or UDA)

0

Air Defense Identification Zone (ADIZ)

1

Air Route Traffic Control Center (ARTCC)

2

Area Control Center (ACC)

3

Buffer Zone (BZ)

4

Control Area or Special Rules Area

5

Ctrl/Special Rules/Military Traffic Zone

6

Flight Information Region (FIR)

7

Ocean Control Area (OCA)

8

Radar Area

9

Terminal Control Area (TCA or MTCA)

10Upper Flight Information Region (UIR)11

Mode C Defined Areas

12

Other

13

AirspaceBoundaryType© 2015 Open Geospatial Consortium

573

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

Enumerator Description
Not Defined

Values14

AirspaceRestrictionType
Alert

0

Caution1

Danger2

Military Operations Area

3

Prohibited

4

Restricted5

Temporary Reserved Airspace

6

Training

7

Warning

8

Not Defined

9Class C Airspace (was ARSA within the USA)

0

Control Area - ICAO Designation (CTA)

1

Terminal Control Area - ICAO Desig (TMA or TCA)

2

Radar Zone or Radar Area (was TRSA in the USA)

3

Class B Airspace (was TCA within the USA)

4

Class D Airspace in USA/Control Zone for ICAO (CTR)

5

Advisory Area (ADA or UDA)

6

Air Defense Identification Zone (ADIZ)

7

Air Route Traffic Control Center (ARTCC)

8

Area Control Center (ACC)

9

Buffer Zone (BZ)

10

AirspaceType© 2015 Open Geospatial Consortium

574

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

Enumerator Description
Control Area (CTA/UTA)/Special Rules Area (SRA - UK)

Values11

Ctrl/Special Rules/Military Traffic Zone

12

Ocean Control Area (OCA)

13

Radar Area

14

Terminal Control Area (TCA or MTCA)

15

Mode C Defined Areas

16

Other

17

Not Defined18

All Altitudes

0High Level Airway

1

Low Level Airway

2

Not Defined3

Alternate Minimum Not Standard

0

Alternate Minimum Not Authorized1

Not Defined2

At or above Alt1

0

At or below Alt1

1

At Alt1

2

Between two altitudes

3

At or above Alt2

4

At Alt1 & Glideslope altitude Alt2

5

AirwayLevel

AlternateMinimumType

AltitudeDescription© 2015 Open Geospatial Consortium

575

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

Enumerator Description
At or above Alt1 & Glideslope Alt Alt2

Values6

At Alt1 & Glideslope Intercept Alt2

7

At or above Alt1 & GS Intercept Alt2

8

At or above Alt1 & Vertical Angle Alt2

9

As assigned

10

Recommended altitude

11

Glideslope intercept altitude in Alt2

12

Not Defined

13

Above Mean Sea Level

0

Above Ground Level

1

By Notam2

Altitude not limited3

Not Defined

4

Feet above sea level0

Radar altimeter

1

Missed approach point

2

Transition level

3

Not Defined4

Flight Level

0

Meters1

Feet

2

AltitudeReference

AltitudeType

AltitudeUnit© 2015 Open Geospatial Consortium

576

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

Enumerator Description
Not Defined

Values3

Not defined0

Approach Transition0

Localizer/Backcourse Approach

1

Flight Management System Approach2

Instrument Guidance System (IGS) Approach3

Instrument Landing System (ILS) Approach

4

Ground Based Augmentation Sys/GLS Approach

5

Satellite Based Augmentation Sys Approach

6

Localizer Only (LOC) Approach

7

Microwave Landing System (MLS) Approach

8

Non Directional Beacon (NDB) Approach

9

Global Positioning System (GPS) Approach

10

Area Navigation (RNAV) Approach11

Tacan Approach

12

Simplified Directional Facility Approach

13

VOR Approach

14

Microwave Landing System Type A Approach

15

Localizer Directional Aid (LDA) Approach16

Microwave Landing System Type B & C Approach

17

Missed Approach18

ApproachPerformance

ApproachRouteType© 2015 Open Geospatial Consortium

577

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

Enumerator Description
ILS Back Course Approach

Values19

ILS Cat II Approach

20

VORDME/VORTAC Approach21

VOR Circling Approach

22

NDB Circling Approach

23

RNAV (GPS) Non-Precision Approach

24

ILS Cat III Approach

25

LAAS-GPS/GLS (PAPP record required)

26

WAAS-GPS (PAPP record required)

27

RNAV (GPS) Overlay Approach28

PAR Approach

29

NDB/DME Approach30

VOR (Based on VORDME or VORTAC) Approach

31

MLS Cat II Approach32

ADF Approach33

SDF Approach

34

MLS Cat III Approach

35

RNAV (GPS) Precision Approach (Other)36

ILS Localizer only Circling Approach

37

ILS Back Course Circling Approach

38

Not Defined

39

Distance and Bearing

0

End Coordinates

1

ArcSegmentDerivation© 2015 Open Geospatial Consortium

578

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

Enumerator Description
Derived by Plotted Coordinates

Values2

Not Defined

3

Straight-In Approach0

Not Defined1

Inner Marker Beacon0

Middle Marker Beacon

1

Outer Marker Beacon

2

Back Marker Beacon

3

Not Defined

4

Locator0

Non-Locator Navaid

1

Not Defined2

End of Continuous ATS route procedure0

Uncharted A-Route intersection

1

Not Defined

2

USA

0

Canada and Alaska

1

Pacific

2

Latin America

3

ApproachSegmentType

AssociatedMarkerType

AssociatedNavaid

AtsRouteSegmentType

BoundaryCode© 2015 Open Geospatial Consortium

579

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

Enumerator Description
South America

Values4South Pacific5Europe6

Eastern Europe

7

Middle East-South Asia

8

Africa9

Not Defined10

Arc by edge

0

Circle1Great Circle

2

Rhumb Line

3Counter Clockwise ARC

4Clockwise ARC

5

Point (without radius or bearing)

6

Generalized7

Not Defined

8

CIVIL

0

MILITARY

1

CIVIL/MILITARY

2

CIVIL - MINOR OR NO FACILITIES3MILITARY - MINOR OR NO FACILITIES4PRIVATE

5

BoundaryShape

CivilMilitaryType© 2015 Open Geospatial Consortium

580

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

Enumerator Description
Not Defined

Values6

ClearanceStatus
Airport of Entry

0

Landing Rights Airport

1

Airport of Entry/Landing Rights Airport

2

Not Defined3

Minimum Climb Rate

0

ATC Climb Rate

1

Not Defined2

Air/Ground0

VHF Direction Finding Service

1

Remote Communications Air to Ground2

Language other than English

3

Military Use Frequency

4

Pilot Controlled Light

5

Remote Communications Outlet

6

Not Defined

7

Off

0

Not Defined1

IFR Flight0

ClimbRateType

CommsDetails

CommsEncryption

CommsFlightType© 2015 Open Geospatial Consortium

581

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

Enumerator Description
VFR Flight

Values1

Oceanic FIR/UIR

2Other FIR/UIR

3

Not Defined

4

Area Control Center0

Airlift Command Post

1

Approach Control2

Arrival Control

3

Automatic Terminal Info Service

4

Automatic Weather Observing Service

5

Clearance Delivery

6

Clearance, Pre-Taxi

7

Control Area (Terminal)

8

Control9Departure Control

10Director (Approach Control Radar)

11

Enroute Flight Advisory Service

12

Emergency

13

Flight Service Station

14

Ground Comm Outlet

15

Ground Control

16

Gate Control

17

Helicopter Frequency

18

CommsType© 2015 Open Geospatial Consortium

582

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

Enumerator Description
Information

Values19

Multicom20

Operations

21

Radio

22

Radar

23

Remote Flight Service Station

24

Ramp/Taxi Control

25

Airport Radar Service Area

26

Terminal Control Area (TCA)

27

Terminal Control Area (TMA)

28

Terminal

29

Terminal Radar Service Area

30

Transcriber Weather Broadcast

31

Tower, Air Traffic Control

32

Upper Area Control

33

Unicom34

Volmet35

Ground Control Approach

36

Parameters (French Radio)

37

Common Traffic Advisory Frequency

38

Air/Ground39

Approach/Departure Control

40

Air Route Traffic Control Center

41

Ground Control/Clearance Delivery42© 2015 Open Geospatial Consortium

583

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

Enumerator Description
Command Post

Values43

Pilot to Dispatcher

44

Pilot to Metro Service

45

Airport Advisory Service

46

Air Route Traffic Control

47

Preflight

48

Single Frequency Approach

49

Miscellaneous

50

Centralized Approach Control

51

Aerodrome Flight Info Service

52

Remote Communications Outlet

53

Automated Surface Observation System

54

Flight Communications Center

55

Flight Operations Center

56

Airport Weather Information Broadcast

57

Not Defined58

Locator

0

Dme

1

Localizer

2

Glide Slope3

Back Course Marker

4

Inner Marker

5

Middle Marker

6

ComponentType© 2015 Open Geospatial Consortium

584

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

Enumerator Description
Outer Marker

Values7

MLS Localizer

8

MLS DME9

Not Defined10© 2015 Open Geospatial Consortium

585

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

Enumerator Description

CountryEntry

Value

Unidentified

0

Afghanistan

1

Africa - Central

2

Africa - East

3

Africa - South

4

Africa - West5

Alaska6

Albania

7

Algeria

8

American Samoa

9American Samoa/Samoa

10

Andorra11

Andorra/Spain

12

Angola13

Anguilla Island

14

Antarctica

15

Antigua and Barbuda

16

Argentina

17

Argentina/Antarctica

18

Armenia

19

Armenia/Azerbaijan/Georgia/Russian Federation

20

Armenia/Azerbaijan/Kazakhstan/Turkmenistan/Uzbekistan

21

Aruba

22

© 2015 Open Geospatial Consortium

586

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

Enumerator Description
Ashmore and Cartier Island

Value
23

Asia - Far East

24

Asia - Middle East

25

Asia - South

26

Australia

27

Australia associated islands

28

Austria29

Austria/Liechtenstein30

Azerbaijan

31

Azerbaijan/Kazakhstan/Russian Federation

32

Bahamas33

Bahrain

34

Bahrain/Iraq-Saudi Arabia Neutral Zone

35

Baker Island

36

Bangladesh

37

Barbados38

Bassas39

Belarus40

Belarus/Russian Federation

41

Belgium

42

Belize

43

Benin

44

Bermuda45

Bhutan46© 2015 Open Geospatial Consortium

587

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

Enumerator Description
Bolivia

Value
47

Bosnia and Herzegovina

48

Botswana49

Bouvet Island

50

Brazil51

British Indian Ocean Territory

52

British Virgin Islands

53

Brunei Darussalam

54

Bulgaria

55

Burkina Faso

56

Burma (Myanmar)

57

Burundi58

Cambodia59

Cameroon60

Canada61

Canada - Uplands CFB

62

Canada - Weather Centres

63

Cape Verde64

Cayman Islands

65

Central African Republic

66

Central America/Mexico/West Caribbean

67

Chad

68

Chile

69

Chile/Antarctica

70© 2015 Open Geospatial Consortium

588

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

Enumerator Description
China

Value
71

Christmas Island

72

Clipperton Island

73

Cocos (Keeling) Island

74

Colombia

75

Comoros

76

Congo

77

Continental China

78

Cook Islands

79

Coral Sea Islands

80

Costa Rica

81

Croatia

82

Cuba

83

Cyprus84

Czech Republic

85

Democratic People's Republic of Korea

86

Democratic Republic of the Congo87

Denmark

88

Denmark and associated islands

89

Djibouti

90

Dominica

91

Dominican Republic

92

East Caribbean

93

East Timor

94© 2015 Open Geospatial Consortium

589

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

Enumerator Description
Ecuador

Value
95

Egypt

96

El Salvador

97

Equatorial Guinea

98

Eritrea99

Estonia100

Ethiopia

101

Europa Island

102

Europe - North

103

Europe - South

104

Europe - West105

Ex-URSS region

106

Falklands Islands

107

Faroe Islands

108

Federal Republic of Yugoslavia

109

Fiji

110

Fiji and surrounding islands

111

Finland112

France113

France and associated islands

114

French Antilles

115

French Guyana

116

French Polynesia

117

French Polynesia/Pitcairn Island118© 2015 Open Geospatial Consortium

590

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

Enumerator Description
French Southern and Antarctic Islands

Value
119

Gabon

120

Gambia121

Gaza Strip

122

Georgia

123

Germany

124

Ghana

125

Gibraltar

126

Glorioso Islands

127

Greece128

Greenland

129

Grenada130

Guadeloupe

131

Guam

132

Guatemala133

Guernsey

134

Guinea135

Guinea-Bissau

136

Guyana

137

Haiti

138

Hawaii139

Honduras

140

Hong Kong

141

Hong Kong/Paracel Islands142© 2015 Open Geospatial Consortium

591

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

Enumerator Description
Howland Island

Value
143

Hungary

144

Iceland

145

Iles Wallis et Futuna

146

India

147

Indonesia

148

Indonesia/East Timor

149

Iran

150

Iraq

151

Iraq/Iraq-Saudi Arabia Neutral Zone

152

Iraq-Saudi Arabia Neutral Zone

153

Ireland154

Isle of Man

155

Israel

156

Israel/Gaza Strip

157

Italy

158

Italy and enclaved territories

159

Ivory Coast

160

Jamaica

161

Jamaica and surrounding islands

162

Jan Mayen

163

Japan

164

Jarvis Island

165

Jersey166© 2015 Open Geospatial Consortium

592

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

Enumerator Description
Johnston Atoll

Value
167

Jordan168

Jordan/The West Bank

169

Juan de Nova Island

170

Kazakhstan

171

Kazakhstan/Kyrgyzstan/Uzbekistan

172

Kazakhstan/Tajikistan/Turkmenistan/Uzbekistan

173

Kenya

174

Kingman Reef

175

Kiribati

176

Kiribati and Line Island

177

Kiribati/Jarvis Island

178

Kiribati/Tuvalu

179

Kuwait180

Kyrgyzstan

181

Laos People's Democratic Republic

182

Latvia183

Lebanon184

Lesotho185

Liberia

186

Libyan Arab Jamahiriya

187

Liechtenstein

188

Lithuania

189

Luxembourg

190© 2015 Open Geospatial Consortium

593

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

Enumerator Description
Macao

Value
191

Madagascar

192

Madagascar and surrounding islands

193

Malawi

194

Malaysia

195

Malaysia/Brunei Darussalam

196

Maldives

197

Mali

198

Malte

199

Mariana Islands

200Mariana Islands (including Guam)

201

Marshall Islands

202

Martinique203

Mauritania

204

Mauritius

205

Mayotte206

Mexico207

Mexico and surrounding islands

208

Micronesia

209

Micronesia/Palau

210

Midway Islands

211

Monaco212

Mongolia

213

Montserrat

214© 2015 Open Geospatial Consortium

594

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

Enumerator Description
MoroccoValue
215

Morocco/Western Sahara

216

Mozambique

217

Mozambique and surrounding islands

218

Namibia

219

Nauru

220

Navassa Island

221

Nepal

222

Netherlands

223

Netherlands Antilles

224

Netherlands Antilles/Aruba

225

New Caledonia

226

New Zealand

227

New Zealand/Antarctica

228

Nicaragua

229

Niger

230

Nigeria

231

Niue Island

232

Norfolk Island

233

Norway234

Norway and associated territories

235

Oceania - East

236

Oceania - North-East

237

Oceania - West238

© 2015 Open Geospatial Consortium

595

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

Enumerator Description
Oman

Value
239

Pacific

240

Pakistan

241

Palau

242

Panama243

Papua New Guinea

244

Paracel Islands

245

Paraguay

246

Peru

247

Philippines

248

Philippines/Spratly Islands

249

Pitcairn Island

250

Poland251

Portugal

252

Puerto Rico

253

Puerto Rico and surrounding Caribbean islands

254

Qatar

255

Republic of Korea

256

Republic of Moldova

257

Reunion258

Romania259

Russian Federation

260

Rwanda261

Saint Lucia

262© 2015 Open Geospatial Consortium

596

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

Enumerator Description
Saint Vincent and the Grenadines

Value
263

San Marino

264

Sao Tome and Principe

265

Saudi Arabia

266

Senegal267

Seychelles

268

Sierra Leone

269

Singapore

270

Slovakia

271

Slovenia

272

Solomon Islands

273

Somalia274

South Africa

275

South Africa and surrounding islands

276South America

277

Spain

278

Spain - Canary Islands

279

Spratly Islands

280

Sri Lanka

281

St. Kitts and Nevis

282

St.Helena and Ascension Island

283

St.Pierre and Miquelon

284

Sudan

285

Suriname286© 2015 Open Geospatial Consortium

597

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

Enumerator Description
Svalbard

Value
287

Swaziland288

Sweden289

Switzerland

290

Syrian Arab Republic

291

Taiwan292

Tajikistan

293

Thailand294

The former Yugoslav Republic of Macedonia

295

The West Bank

296

Togo

297

Tokelau

298

Tonga

299

Trinidad and Tobago

300

Tromelin Island

301

Tunisia

302

Turk and Caicos Islands

303

Turkey304

Turkmenistan

305

Tuvalu306

Uganda307

Ukraine308

Ukraine/Russian Federation

309

United Arab Emirates

310© 2015 Open Geospatial Consortium

598

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

Enumerator Description
United Kingdom

Value
311

United Kingdom and associated islands

312

United Republic of Tanzania

313

United States

314

United States (Central North-East)

315

United States (Central North-West)

316

United States (Central South)

317

United States (North-East)

318

United States (North-West)

319

United States (South-East)

320

United States (South-West)

321

Uruguay322

US territories - North Pacific Ocean

323

Uzbekistan

324

Vanuatu

325

Vatican City

326

Venezuela

327

Viet Nam

328

Virgin Islands

329

Virgin Islands/British Virgin Islands

330

Wake Island

331

Western Sahara

332

Western Samoa

333

Yemen

334

© 2015 Open Geospatial Consortium

599

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

Enumerator Description
ZambiaValue
335

Zimbabwe336© 2015 Open Geospatial Consortium

600

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

Enumerator Description

CruiseTable

Value

ICAO Standard Cruise Table0

Exception to ICAO Standard Cruise Table

1

Modified Cruise Table

2

Exception to Modified Cruise Table

3

Not Defined

4

ARINC 424

0

DAFIF

1

Error Data Lost

0

Data Transfer Completed

1

Data Transfer In Progress

2

Monday0

Tuesday1

Wednesday

2

Thursday3

Friday4Saturday5

Sunday6

Not Defined

7

East

0

DataSource

DataTransferStatus

DayOfWeek

Direction© 2015 Open Geospatial Consortium

601

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

Enumerator Description
West

Value
1

Not defined2

Forward Direction Route Coded0

Backward Direction Route Coded

1

No Direction Restriction2

Not Defined3

Out to Specified Distance0

Beyond Specified Distance1

Not Defined2

A0 - Unmodulated Carrier0

A1 - Carrier Keyed1

A2 - Tone Keyed Modulation2

Not Defined3

Airline Airway (Tailored Data)0

Control1

Direct Route2

Helicopter Airway

3

Officially Designated Airway

4

RNAV Airway

5

Undesignated ATS Route6

DirectionRestriction

DistanceDescription

EmissionType

EnrouteAirwayRouteType© 2015 Open Geospatial Consortium

602

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

Enumerator Description
Not Defined

Value
7

All Altitudes in Both Directions Restricted

0

All Altitudes in Backward Direction Restricted

1

All Altitudes in Forward Direction Restricted2

Not an all altitudes restriction3

Not Defined4

Airport0

VHF Navaid

1

NDB Navaid

2

Terminal NDB

3

Not Defined

4

FIR

0

UIR

1

Combined FIR/UIR

2

Not Defined3

Initial Approach Fix

0

Intermediate Approach Fix

1

Initial Approach Fix with Holding

2

Initial Approach Fix with Final Approach Crse Fix

3

Final End Point Fix

4

ExclusionIndicator

FacilityRecordType

FirUirType

FixDetails© 2015 Open Geospatial Consortium

603

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

Enumerator Description
Published/Database Final Approach Fix

Value
5

Holding Fix

6

Final Approach Course Fix

7

Published Missed Approach Point Fix

8

Not Defined9

Unnamed Stepdown Fix After Final Approach Fix

0

Unnamed Stepdown Fix Before Final Approach Fix

1

ATC Compulsory Waypoint

2

Oceanic Gateway Waypoint

3

First Leg of Missed Approach Procedure

4

Path Point Fix

5

Named Stepdown Fix

6

Not Defined

7

Airport0

VHF Navaid

1

NDB Navaid

2

Terminal NDB

3

Enroute Waypoint

4

Airport Waypoint

5

Heliport Waypoint

6

Runway7

SID

8

FixFunction

FixRecordType© 2015 Open Geospatial Consortium

604

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

Enumerator Description
STAR

Value
9

Navaid (VHF or NDB)

10

Waypoint (Terminal or Enroute)11

ATS Route12

Not Defined13

VOR (navaid)

0

VORTAC (navaid)

1

TACAN (navaid)

2

VORDME (navaid)

3

NDB (navaid)

4

NDBDME (navaid)

5

DME (navaid)

6

Atlantic (ATS Route)

7

Bahama (ATS Route)

8

Corridor (ATS Route)

9

Advisory (ADR) (ATS Route)

10

Direct, Control Area Routes (ATS Route)

11

Military (ATS Route)12

North American (NAR) (ATS Route)

13

Oceanic (ATS Route)

14

RNAV (ATS Route)15

Substitute, Canadian Control Area Tracks (ATS Route)

16

TACAN (ATS Route)

17

FixPointType© 2015 Open Geospatial Consortium

605

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

Enumerator Description
Airway (ATS Route)

Value
18

Not Defined19

Airport0

VHF Navaid

1

NDB Navaid

2

Terminal NDB

3

Enroute Waypoint

4

Airport Waypoint

5

Heliport Waypoint

6

Runway7

Not Defined8

Final Approach Fix

0

Initial and Final Approach Fix

1

Final Approach Course Fix

2

Intermediate Approach Fix

3

Off-Route Intersection

4

Initial Approach Fix

5

Final Approach Course Fix at Initial Approach Fix

6

Final Approach Course Fix at Interm. Approach Fix

7Missed Approach Fix

8Initial Approach Fix and Missed Approach Fix

9Oceanic Entry/Exit Waypoint

10

FixRecordType

FixType© 2015 Open Geospatial Consortium

606

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

Enumerator Description
Unnamed Stepdown Fix

Value
11

Named Stepdown Fix

12

FIR/UIR or Controlled Airspace Intersection

13

Lat/Long Intersection, Full Degree of Latitude

14

Lat/Long Intersection, Half Degree of Latitude

15

Not Defined

16

Flyover -End SID/STAR Rte, APCH Transition/Final
Approach0

End of Terminal Procedure Route Type1

Uncharted Airway Intersection

2

Fly-Over Waypoint (overfly)

3

Not Defined

4

UHF/VHF

0

LF/MF

1

Not defined2

East direction only

0West direction only

1

Both East and West2

Not defined

3

Aerodrome Traffic Frequency

0Common Traffic Advisory Frequency

1

FlyOverType

FrequencyClass

FrequencyDirectionRestriction

FrequencyType© 2015 Open Geospatial Consortium

607

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

Enumerator Description
Mandatory Frequency

Value
2

Secondary Frequency

3

Air/Ground4

Discrete Frequency

5

Air/Air6

Not Defined

7

LAAS/GLS0SCAT-1

1

Not defined

2

No GPS or FMS Overlay Authorized0

GPS Overlay, Navaids Operating & Monitored

1

GPS Overlay, Navaids Installed/Not Monitored

2

GPS Overlay, Title includes GPS

3

FMS Overlay Authorized

4

FMS and GPS Overlay Authorized5

Not Defined

6

Receive Voice Communications

0

Transmit Voice Communications

1

Receive and Transmit Voice Comms2

Not Defined

3

GlsStationType

GpsFmsIndicator

GuardTransmit

HoldingPatternType© 2015 Open Geospatial Consortium

608

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

Enumerator Description
High Altitude

Value
0

Low Altitude

1

SID

2

STAR

3

Approach4Missed Approach

5

All Altitude

6

Not Defined

7

Usable0

Unusable

1

Restricted2

Not Defined

3

ILS Localizer Without Glideslope

0

CAT I

1

CAT II

2

CAT III

3IGS

4LDA With Glideslope

5

LDA Without Glideslope

6

SDF With Glideslope

7

SDF Without Glideslope

8

Not Defined9

IlsBackCourse

LandingAidCategory© 2015 Open Geospatial Consortium

609

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

Enumerator Description

ValuesLightingSystem
Unidentified

0

PCL - Pilot Controlled Lighting

1

SF - Sequenced Flashing Lights

2

TDZL - Touchdown Zone Lighting

3

CL - Centerline Lighting System

4

HIRL - High Intensity Runway Lights

5

MIRL - Medium Intensity Runway Lighting System

6

LIRL - Low Intensity Runway Lighting System

7

RAIL - Runway Alignment Lights

8

REIL - Runway End Identifier Lights

9

A - ALSF-2

10

A1 - ALSF-1

11

A2 - SALS or SALSF

12

A3 - SSALR

13

A4 - MALS and MALSF or SSALS and SSALF

14

A5 - MALSR

15

AF - Overrun Centerline

16

AI - Centerline and Bar

17

B - US Configuration (b)18

BE - Hong Kong Curve

19

BF - Center row

20

BG - Left Center Row

21

BN - Former NATO Standard ©

22© 2015 Open Geospatial Consortium

610

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

Enumerator Description

ValuesBO - Center Row

23

BP - NATO standard

24

BQ - Center and Double Row

25

BR - Portable Approach26

BS - Center Row

27

G - Helicopter Approach Lighting System (HALS)

28

J2 - CALVERT II (BRITISH)

29

E - Two Parallel row

30

F - Left Row (High Intensity)

31

I - Air Force Overrun

32

J - CALVERT I (BRITISH)

33

M - Single Row Centerline

34

N - Narrow Multi-cross35

O - Centerline High Intensity

36

Q - Alternate Centerline and Bar

37

S - Cross38

T - Center Row

39

U - Singapore Centerline

40

X - Centerline 2 Crossbars

41

ODALS - Omni-directional Approach Lighting System

42

V(VASI) - Visual Approach Slope Indicator

43

V1 (T-VASI) - T-Visual Approach Slope Indicator

44

V2 (PVASI) - Pulsating Visual Approach Slope Indicator45

V3 (JUMBO) - VASI with a TCH to accommodate longbodied or jumbo aircraft46© 2015 Open Geospatial Consortium

611

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

Enumerator Description

ValuesV4 - Tri-color Arrival Approach (TRICOLOR)

47

V5 (APAP) - Alignment of Elements System

48

RETIL - Rapid Exit Taxiway Indicator Lighting

49

PAPI - Precision Approach Path Indicator50

OLS - Optical landing System

51

WAVEOFF

52

PORTABLE

53

FLOODS

54

LIGHTS

55

LCVASI - Low Cost Visual Approach Slope Indicator

56

Lighting Provisional3

57

Lighting Provisional4

58

Lighting Provisional5

59

Lighting Provisional6

60

Lighting Provisional7

61

Lighting Provisional8

62

Lighting Provisional9

63Lighting Provisional1064© 2015 Open Geospatial Consortium

612

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

Enumerator Description

ValuesLocationReference
Prior to threshold/approach end (near end)0

On the runway

1

On the overrun (far end)2

Not defined3

Magnetic

0

True

1

Mixed Magnetic and True

2

Other than Magnetic or True

3

Not Defined

4

Low

0

High

1

Not Defined2

Elliptical

0

Bone

1

Not Defined2

Inner Marker Beacon0

Middle Marker Beacon

1

Outer Marker Beacon

2

Back Marker Beacon

3

MagneticTrueIndication

MarkerPower

MarkerShape

MarkerType© 2015 Open Geospatial Consortium

613

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

Enumerator Description

ValuesBone Marker Beacon

4

Fan Marker Beacon

5

Low Power Fan Marker Beacon

6

Z Marker Beacon

7

Not Defined10High - No Limit0

Medium - Limited to 217 psi

1

Low - Limited to 145 psi

2Very Low - Limited to 73 psi

3

Not Defined4

Instrument Route0

Visual Route1

Slow Route2

Not Defined

3

DME Collocated With MLS Azimuth

0

DME Collocated With MLS Elevation

1

DME Non Collocated With MLS

2

Not Defined3

Amplitude Modulated Frequency

0Frequency Modulated Frequency

1

MaximumTirePressure

MilitaryRouteType

MlsCollocation

Modulation© 2015 Open Geospatial Consortium

614

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

Enumerator Description

ValuesNot Defined2

VHF Emergency Frequency 121.5

0

UHF Emergency Frequency 243.0

1

VHF/UHF Emergency Frequencies2

VHF 121.5 and VHF/UHF Emergency Freq

3

UHF 243.0 and VHF/UHF Emergency Freq

4

VHF 121.5 and UHF 243.0 Emergency Freq

5

Not Defined

6

Abeam Fix0

Bearing and Distance Fix

1

Airport Name as Fix

2

FIR Fix

3

Phonetic Letter Name Fix

4

Airport Ident as Fix

5

Latitude/Longitude Fix

6

Multiple Word Name Fix

7

Navaid Ident as Fix

8

Published Five-Letter Name Fix

9Published Less Than 5-Letter Fix

10

Published More Than 5-Letter Fix

11

Airport/Runway Related Fix

12

UIR Fix

13

MonitoredFrequency

NameFormatType© 2015 Open Geospatial Consortium

615

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

Enumerator Description

Values

Official 5-letter Localizer Name

14

Unofficial 5-letter Localizer

15

Not Defined16

Collocated Navaid0

Non Collocated Navaid

1

DME Collocated With ILS Localizer

2

DME Collocated With ILS Glide Slope

3

DME Non Collocated With ILS

4DME Collocated With MLS Azimuth

5

DME Collocated With MLS Elevation

6

DME Non Collocated With MLS

7

Not Defined8

Terminal0

Low Altitude

1

High Altitude

2

200 Watts or More

3

50 to 1999 Watts

4

25 to Less Than 50 Watts

5

Less Than 25 Watts

6

Not Defined

7

In-Service0

NavaidCollocation

NavaidRangePower

NavaidStatus© 2015 Open Geospatial Consortium

616

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

Enumerator Description

ValuesOut of Service

1

On Test2

Not Defined

3

VOR

0

DME

1

VOR/DME2

TACAN - Channels 17-59 and 70-126

3

Military TACAN - Channels 1-16 and 60-69

4

VORTAC

5

ILS/DME

6

ILS/TACAN

7

MLS/Narrow Spectrum DME

8

MLS/Precision DME

9

NDB

10

NDB-DME

11

SABH

12

Marine Beacon

13

VOR Test Station

14

Not Defined

15

FAA/DOD Full Coverage0

FAA/DOD Partial Coverage

1

US Army Flight Operations Detachment

2NavaidType

NotamSystem© 2015 Open Geospatial Consortium

617

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

Enumerator Description

ValuesGerman Federal Armed Forces

3

Not Defined

4

Station is alive / Reset status to alive0

Station is killed / Set status to killed

1

Leave station status as it is2

Airport0

AirspaceBoundary

1

AirwayRestriction

2

Approach

3

Comms

4

ControlledAirspace

5

EnrouteAirway

6

FirUir

7

Gate

8

Gls

9

Helipad10

Heliport

11

HoldingPattern

12

Ils

13

Marker

14

Mls

15

Msa

16

ObjectStatus

ObjectType© 2015 Open Geospatial Consortium

618

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

Enumerator Description

ValuesNavaid17

OffRouteTerrainClearanceAlt

18

PresetSite

19

RestrictiveAirspace

20

Runway

21

Sid

22

SpecialUseAirspace

23

Star

24

SupplementalTerminalData

25

TerminalProcedureClimb

26

TerminalProcedureFeederRoute27

TerminalProcedureMinima

28

VfrRoute

29

Waypoint

30

Object has not been updated

0

Object has been deleted from database

1

Object has changed

2

Object has been added to database

3

Object status has changed

4

24 Hours0

Sunrise to Sunset

1

No Hours Listed

2

ObjectUpdateType

OperatingHours© 2015 Open Geospatial Consortium

619

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

Enumerator Description

ValuesRefer to Remarks

3

Unknown Hours

4

Rectangular0

Circular1

Not Defined2

Bearing/Distance to a point

0

A point

1

Bearing/Distance to an area

2

Geographic area (defined by coords)

3

Area defined by 2 brgs & 2 distances

4

Multiple areas defined by brg/distance5

Unspecified, Call Tower

6

Not Defined7

Not defined0

Initial Fix (IF)0

Track to a Fix (TF)

1

Course to a Fix (CF)2

Direct to a Fix (DF)3

Fix to an Altitude (FA)4

Track from a Fix from a Distance (FC)5

PadShape

ParachuteJumpAreaType

PathDataSelector

PathTermination© 2015 Open Geospatial Consortium

620

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

Enumerator Description

ValuesTrack from a Fix to DME Distance (FD)6

From a Fix to Manual Termination (FM)7

Course to an Altitude (CA)8

Course to a DME Distance (CD)9

Course to an Intercept (CI)10

Course to a Radial Termination (CR)11

Constant Radius Arc (RF)12

Arc to a Fix (AF)13

Heading to Altitude Termination (VA)

14

Heading to DME Distance Termin. (VD)

15

Heading to an Intercept (VI)16

Heading to a Manual Termination (VM)

17

Heading to a Radial Termination (VR)18

Procedure Turn (PI)19

Crse Reversal Altitude Termination (HA)

20

Crse Reversal Single Circuit Term. (HF)

21

Course Reversal Manual Termination (HM)22

Not Defined

23

Left

0

Right

1

Not Defined2

Arrival Route0

PathTurnDirection

PathType© 2015 Open Geospatial Consortium

621

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

Enumerator Description

ValuesDeparture Route1

Holding Pattern

2

Part of a Terminal Traffic Pattern

3

VFR Transition

4

Other

5

Not Defined

6

Technical

0

By Experience Using Pavement1

Not Defined

2

High

0

Medium1

Low

2

Ultra-Low

3

Not Defined

4

Rigid

0

Flexible

1

Water

2

Not Defined3

Compulsory Reporting Point0

Non-Compulsory Reporting Point

1

PavementEvaluationMethod

PavementSubgradeCategory

PavementType

PointReportingType© 2015 Open Geospatial Consortium

622

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

Enumerator Description

ValuesNot Defined2

Alternate Entry Point0

Alternate Exit Point

1

Alternate Entry/Exit Point

2

Entry Point (Starting Point)

3

Turning Point

4

Exit Point (Ending Point)5

Not Defined

6

N-Ameri Rtes for N-Atlantic Traffic - Common

0Preferential Routes

1

Pacific Oceanic Transition Routes (PACOTS)

2

TACAN Routes (Australia)

3

N-Ameri Rtes for N-Atlantic Trffic -Noncommon

4Preferred/Preferential Overflight Routes

5

Preferred Routes

6

Traffic Orientation System Routes (TOS)

7

Tower Enroute Control Routes (TEC)8

Not Defined

9

Gate

0

CAL Site

1

Hold

2

PointFunction

PreferredRouteType

PresetSiteType© 2015 Open Geospatial Consortium

623

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

Enumerator Description

ValuesTakeoff

3

Opposite End

4

Not Defined

5

Ramp

6

Parking Spot

7

Taxi

8

Active Continuously Including Holidays

0

Active Continuously Excluding Holidays

1

Active Non-Continuously, see Cont. Rec

2

Active Times Announced by NOTAM

3

Not Defined

4

Non-Directional Beacon, 50-2000 Watts

0Interference-Free 40NM up to 18000 feet

1

Interference-Free 25NM up to 12000 feet2

Non-Directional Beacon, 50 Watts or less3

Non-Directional Beacon, 2000 Watts & up

4

Interference-Free Service Varies

5

Compass Locator, 25 Watts or less, 15NM

6

Not Defined7

Terminal Within 25 nm

0

Low Altitude - Within 40 nm

1

PrimaryTimeCode

RadioClassCode

RangeReliability© 2015 Open Geospatial Consortium

624

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

Enumerator Description

ValuesHigh Altitude - Within 130 nm

2

Extended High Altitude - Beyond 130 nm

3

Out of Service

4

High Level

5

Low Level

6High and Low Level

7

RNAV

8

Terminal

9

Not Defined10

At or above Altitude 10

At or below Altitude 1

1

Between Altitude 1 and 2

2

At Altitude 1

3

Not defined

4

North

0

South

1

East

2

West

3

Northeast

4

Northwest

5

Southeast

6

Southwest

7

RefuelingAltitudeDescription

RefuelingDirection© 2015 Open Geospatial Consortium

625

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

Enumerator Description

ValuesNot defined

8

Anchor

0

Track

1

Anchor or Track2

Not defined3

Air refueling initial point0

Air refueling control point

1

Navigation check point

2

Exit point

3

Entry point (anchors only)

4

Anchor point (anchors only)

5

Anchor pattern (anchors only)

6

Not defined

7

Altitude Exclusion0

Cruising Table Replacement

1

Seasonal Restriction

2

Note Restriction3

Not Defined

4

Ok

0

Fail

1

RefuelingOperationType

RefuelingPointType

RestrictionType

ReturnCode© 2015 Open Geospatial Consortium

626

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

Enumerator Description

ValuesNot Found2

Request Pending

3

Request In Progress

4

Request Completed

5Unappropriate Container Type Ident

6

Container Ownership Unappropriate

7

Status unavailable

8

User cancelled operation

9

File name not specified

10

Database Name not found11

Client already registered

12

Client is not registered

13

Client is unauthorized

14

Request is not registered

15

Request is unauthorized

16

Duplicate Item

17

No Associated Runway

18

Kill command doesn't match Navaid component

19

Unique Id doesn't match NavObject component

20

NavObject already exists in the database21

Local area has not been defined22Service unavailable in current LOF DLL

23

Gaussian's Coefficient are unavailable

24

Gaussian's Coefficients model are out of date25

© 2015 Open Geospatial Consortium

627

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

Enumerator Description

Values

Theoretical Result. Computed with a magnetic model(WMM or IGRS)

26

Accessing wrong magnetic model

27

DataType mismatch

28

Another client is already registered as editor

29

Edition mode is not active

30

Edition mode activated31

Edition mode deactivated32

The supported Interface is not implemented

33

The requested service is not supported on server

34

Null

250

No key is defined251

Null Object

252

Insertion Fail

253

Removal Fail254

File Opened

255

File Closed

256

File Not Found

257

Parsing In Progress

258

Database Empty

259

Container Owner Unappropriate

260

No Object Found

261

Key wrongly assigned

262

Restriction Not Satisfied

263

Copy Failed264© 2015 Open Geospatial Consortium

628

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

Enumerator Description

ValuesSelected Nav Type does not exists

265

The kill station command has been sent

266

At or above Altitude 10

At or below Altitude 1

1

Between Altitude 1 and 2

2

At Altitude 1

3

As Assigned

4

Not defined5

DME required0

RNAV/E if applicable

1

RNAV/F if applicable2

GPS required3

GPS required, DME/DME to RNP Not Authorized4

DME not required5

GPS or DME/DME to RNP required

6

DME/DME required

7

VOR/DME RNAV

8

Not Defined9

Primary Missed Approach

0

Secondary Missed Approach

1

Engine Out Missed Approach2

RouteAltitudeDescription

RouteQualifier1

RouteQualifier2© 2015 Open Geospatial Consortium

629

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

Enumerator Description

ValuesProcedure with Circle-to-Land Minimums

3

Procedure with Straight-In Minimums

4

Procedure Designed for Helicopter to Runway

5

Not Defined

6

RNAV, GPS required, DME/DME to RNP Not Auth.

0

RNAV, GPS or DME/DME to RNP authorized1

Not Defined

2

Open

0

Closed1

Restricted

2

Alternate

3

Seasonal, Conditional4

Not defined

5

SID

0

STAR

1

Approach2

Multiple3

Not Defined

4

Point-to-Point0

Area-to-Area

1

RouteQualifierType

RouteStatus

RouteType

RouteUse© 2015 Open Geospatial Consortium

630

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

Enumerator Description

ValuesNot Defined2

Designated Airway

0

Direct to Fix

1

Initial Fix

2Route via Fix

3

Route via Fix not permitted

4Standard Instrument Departure

5Standard Terminal Arrival & Profile Descent6

Not Defined7

Asphalt, Asphaltic Concrete, Tar, Macadam

0

Brick - Laid or Mortared

1

Concrete

2

Composite - 50 percent or more of runway is permanent

3Part concrete, asphalt, or bitumen-bound macadam

4Permanent - Surface type unknown

5

Bituminous, tar or asphalt mixed in place, oiled

6

Clay

7

Composite - less than 50 percent of runway is permanent

8

Coral

9

Graded or rolled earth, grass on graded earth

10

Grass or earth not graded or rolled

11

Gravel12

RoutingType

RunwaySurfaceType© 2015 Open Geospatial Consortium

631

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

Enumerator Description

ValuesIce

13

Laterite

14

Macadam - crushed rock water bound15

Membrane - plastic or other fiber material

16

Mix in place using non-bituminous binders (eg: portland)

17

Pieced steel planking

18

Sand

19

Snow

20

Not Defined21

Entry/Exit

0

Entry Only

1

Exit Only

2

RVSM Transition Waypoint

3

RVSM on Airway or Stand Alone4

Not Defined5

At or above altitude specified

0

At or below altitude specified

1

As assigned

2

At altitude specified

3

Recommended altitude

4

Not Defined5

RvsmIndicator

SegmentAltitudeDescription

SegmentNavaidType© 2015 Open Geospatial Consortium

632

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

Enumerator Description

Values

VOR

0

VOR-TAC

1

TACAN

2

VOR-DME

3NDB

4NDB-DME

5DME

6ILS Locator

7

ILS DME

8ILS Localizer

9

Waypoint

10

MLS

11

MLS-DME12

Not Defined

13

Starting Segment

0

Next Segment

1

Ending Segment

2

Not Defined

3

Off

0

Initializing

1

Online2Partially Operational

3

SegmentType

ServerState© 2015 Open Geospatial Consortium

633

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

Enumerator Description

ValuesNot Operational

4

Not Responding

5

Not Available

6

Parsing in Progress

7

Airport Advisory Service

0

Community Aerodrome Radio Station

1

Departure Service (not Control Unit)

2

Flight Information Service

3

Initial Contact

4

Arrival Service (not Control Unit)

5

Pre-Departure Clearance (Data Link)

6

Aerodrome Flight Information Service

7

Terminal Area Control (not Control Unit)

8

Aeronautical Enroute Information Service

9

Not Defined10

Not Defined0Engine Out SID

0

SID Runway Transition

1

SID or SID Common Route2

SID Enroute Transition

3

RNAV SID Runway Transition

4

ServiceIndicator

ServiceProvider

SidRouteType© 2015 Open Geospatial Consortium

634

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

Enumerator Description

ValuesRNAV SID or RNAV SID Common Route5

RNAV SID Enroute Transition

6

FMS SID Runway Transition

7

FMS SID or SID Common Route8

FMS SID Enroute Transition

9

Vector SID Runway Transition

10

Vector SID Enroute Transition

11

Not Defined12

Double Sideband (A3)0Single Sideband, Reduced Carrier (A3A)

1

Two Independent Sidebands (A3B)

2

Single Sideband, Full Carrier (A3H)

3Single Sideband, Suppressed Carrier (A3J)

4

Lower (single) Sideband, Carrier Unknown

5

Upper (single) Sideband, Carrier Unknown6

Not Defined

7

400 Hz01020 Hz1

Not Defined2

TAS in Knots0

TAS in Mach

1

SignalEmission

SignalModulation

SpeedUnit© 2015 Open Geospatial Consortium

635

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

Enumerator Description

ValuesTAS in Kilometers/Hour2

Not Defined3STAR Enroute Transition

0STAR or STAR Common Route1

STAR Runway Transition

2

RNAV STAR Enroute Transition

3

RNAV STAR or RNAV STAR Common Route4

RNAV STAR Runway Transition

5

Profile Descent Enroute Transition

6

Profile Descent or Prof. Desc. Common Route7

Profile Descent Runway Transition

8

FMS STAR Enroute Transition

9

FMS STAR or STAR Common Route10

FMS STAR Runway Transition

11

Not Defined

12

StarRouteType© 2015 Open Geospatial Consortium

636

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

Enumerator Description

Value

StateEntry
Unidentified

0

Alabama1

Alaska2

Arizona3

Arkansas4

California

5

Colorado

6

Connecticut

7

Delaware8

District of Columbia

9

Florida10

Georgia

11

Hawaii

12

Idaho

13

Illinois

14

Indiana

15

Iowa

16

Kansas17

Kentucky

18

Louisiana

19

Maine

20

Maryland21

Massachusetts

22© 2015 Open Geospatial Consortium

637

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

Enumerator Description

Value

Michigan

23

Minnesota

24

Mississippi

25

Missouri

26

Montana27

Nebraska

28

Nevada29

New Hampshire

30

New Jersey

31

New Mexico

32

New York

33

North Carolina

34

North Dakota

35

Ohio

36

Oklahoma

37

Oregon38

Pennsylvania

39

Rhode Island

40

South Carolina

41South Dakota

42

Tennessee

43

Texas

44

Utah

45

Vermont

46© 2015 Open Geospatial Consortium

638

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

Enumerator Description

Value

Virginia

47

Washington

48

West Virginia

49

Wisconsin

50

Wyoming51© 2015 Open Geospatial Consortium

639

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

Enumerator Description

ValuesSynchronisationType
Synchronous0

Asynchronous1

Not Defined2

Takeoff Not Standard

0

Not Defined1

Active Continuously Including Holidays

0

Active Continuously Excluding Holidays

1

Active for Time of Operation Excluding Holidays

2

Active for Time of Operation Including Holidays

3

Not Defined4Time Codes are Local Time

0Time Codes adjusted for Daylight Savings Time1

Times shown in Universal Coordinated Time2

Not Defined3

Automatically at the fix after one full circuit

0

Automatically at a fix after reaching an altitude

1

Manually2

Not Defined3

TakeoffMinimumType

TimeCode

TimeIndicator

TrackDescription

TurnDirection© 2015 Open Geospatial Consortium

640

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

Enumerator Description

Values

Left

0

Right

1

Left or Right2

Not Defined3

Airport as Waypoint

0

Essential Waypoint

1

Off Airway Waypoint

2

Runway/Helipad as Waypoint

3

Heliport as Waypoint

4

NDB Navaid as Waypoint

5

Phantom Waypoint

6

Non-Essential Waypoint

7

Transition Essential Waypoint

8

VHF Navaid as Waypoint

9

Airport or Heliport as Waypoint

10

VOR, VORDME, VORTAC as Waypoint

11

Tacan as Waypoint

12

NDB, NDBDME as Waypoint

13

ILS as Waypoint

14

Not Defined15

Arc Center Fix Waypoint

0

Combined Named Intersection and RNAV Waypoint

1

WaypointDescription

WaypointType© 2015 Open Geospatial Consortium

641

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

Enumerator Description

ValuesUnnamed Charted Intersection

2

Middle Marker as Waypoint

3

NDB Navaid as Waypoint

4

Terminal NDB Navaid as Waypoint

5

Outer Marker as Waypoint

6

Named Intersection

7

Uncharted Airway Intersection

8

VFR Waypoint

9

RNAV Waypoint

10

Unnamed Charted Off Route Fix

11

Named NDB

12Off Route NDB

13Named Off Route Fix

14

Not Defined15

High and Low Altitude

0High Altitude

1

Low Altitude

2

Terminal Use Only

3

RNAV

4

Runway or Displaced Threshold

5

Pitch and Catch (RNAV)

6

Off Route Intersection in FAA Airspace

7

ATCAA and SUAS Waypoints in FAA High Alt

8

WaypointUsageType© 2015 Open Geospatial Consortium

642

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

Enumerator Description

ValuesNot Defined

9

Automatic Transcribed Weather Broadcast

0

Scheduled Weather Broadcast

1

Not Defined2

Visual Flight Rules

0

Instrument Flight Rules

1

Visual Meteorological Rules

2

Instrument Meteorological Rules

3

Notice to Airmen

4Visual and Instrument Flight Rules

5

Visual and Instrument Meteorological Rules

6

Not Defined

7

User

0

Editor

1

Admin

2

Number of duplicate %s

6

IDENT %s has %s duplicates

7

Container output

0

Dual container output

1

WeatherBroadcast

WeatherCondition

GroupPermission

LoggerMessage

OutputTypeEnum© 2015 Open Geospatial Consortium

643

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

Enumerator Description

ValuesStatus output

2

Container and status output

3

Parser status output

4

String array output

5

Value output

6© 2015 Open Geospatial Consortium

644

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

Appendix J
J. XML Schema Definitions
The CDB specification makes an extensive use of XML to describe several parts of thespecification. XML is used to describe CDB metadata, to store global datasets, to add attributes
to OpenFlight models, to describe base and composite materials, etc.

This appendix lists all the schemas used by the Specification. A schema is required to formallydefine the format of an XML file and to validate its content.

Note: As of version 3.2 of the Specification, XML schemas are no longer provided intext form in appendix J. Instead, the actual XSD files are delivered with the CDB
Specification Distribution Package.

The following XML Schemas can be found in the \CDB\Metadata\Schema subdirectory of the
CDB Specification Distribution Package:
1. Base_Material_Table.xsd
2. Composite_Material_Table.xsd
3. Configuration.xsd
4. Defaults.xsd
5. Feature_Data_Dictionary.xsd
6. Lights.xsd
7. Lights_Tuning.xsd
8. Model_Components.xsd
9. Model_Metadata.xsd
10.
OpenFlight_Model_Extensions.xsd
11.
Vector_Attributes.xsd
12.
Version.xsd

J.1
The CDB Namespace
The CDB Specification makes use of several XML namespaces to isolate the definitions of its
schemas. The name of these namespaces is built around a base URL whose name is“http://www.CDB-Spec.org/”15.
J.2
Schema Conventions
The target namespace of all CDB schemas follow this pattern:
15

As of December 2013, this URL does not correspond to an active Web site. An XML namespace does not need tobe the address of a Web site, although it is practical to do so because it ensures its uniqueness.

© 2015 Open Geospatial Consortium

645

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014"http://www.CDB-Spec.org/Schema/[Name]/[Version]"

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

To illustrate how a target namespace is composed, here is the target namespace of the schema
found in Version.xsd (item 12 in the list above):"http://www.CDB-Spec.org/Schema/Version/3.2"© 2015 Open Geospatial Consortium

646

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

Appendix K
K. CDB Coordinate Systems
K.1
Spatial Reference Frames (SRF) and Coordinate Systems
The handling of spatial data requires a good deal of rigor to accurately describe the position ofpoints in space. Furthermore, it requires the ability to define directions and distances.
Generally, this is accomplished through the use of coordinate systems.
It is often convenient to represent position in several different spatial reference frames. Eachspatial reference frame provides a particular way of defining positions within its domain. Thislevel of abstraction also permits spatial reference frames to be decomposed into a series of, oreven a hierarchy of reference, each relative to another reference frames. This mechanism
permits objects to be independently defined (positioned, oriented, and scaled) with respect to a
local spatial reference frame and then be later incorporated into other reference frames. The
reference frames can be abstract mathematical constructs or they can be bound to real world
objects (e.g., a flap located defined in a flap reference frame which in turn is bound to an aircraft
wing reference frame).
The CDB specification defines the conceptual model and the methodologies that allow thedescription, and transformation or conversion, of geometric properties within a set of spatialreference frames supported by the Specification. The CDB Spatial Reference Model (SRM)
supports an unambiguous specification of the positions, directions, and distances associated withspatial information. It also defines algorithms for precise transformation of positions, directions
and distances among different spatial reference frames.
K.2
CDB Approach
One of the primary objectives of the CDB specification is to provide the means to represent theentire earth. Secondly, it must handle spatial data with a good deal of rigor to accurately
describe the position of points in space, and must do so at the level of fidelity commensuratewith the precision that is now possible in modern simulators.
The size, content, fidelity and precision of synthetic environments now warrant a different
approach, an approach that entirely avoids the “problem with projections” and otherapproximations used in the past. To this end, the CDB specification mandates the use ofgeographic coordinates to represent the shape of terrain surfaces and the position of all culturalfeatures. Since no projections are involved, full geometric coherence is assured withoutcompromise and all four key spatial properties can be achieved simultaneously:

(1)
(2)
(3)
(4)

Preservation of distancePreservation of direction
Preservation of area
Preservation of shape© 2015 Open Geospatial Consortium

647

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
K.3
CDB SRF Specifications, and Algorithmic Development
The CDB specification is based on a surface geodetic coordinate system, i.e., points on the earth
surface are specified in geographic lat/long/elevation coordinates.
The CDB embeds modeled point features (e.g., the representation of 3-D objects, moving and/or
static) within a General Cartesian Coordinate System. Its use is generally constrained to objects
that are small in comparison to the earth. As shown below, a modeled point feature can bereferenced anywhere on the earth by providing the model’s orientation (the AO1 attribute
specified in Chapter 5) and the model’s origin using a set of geographic lat/long/elevation
coordinates. Note that the model’s z-axis implicitly points upward with respect to the earth
surface.

Figure K-1: Cartesian Model positioned to WGS-84 Coordinates

The earth shape is described by the WGS-84 reference ellipsoid. The Specification also defines
three related set of Spatial Frames (and associated coordinate systems) for use in conjunction
with the surface geodetic coordinate system; they are:

(1)
(2)
(3)

Earth-centered Cartesian (Geocentric)
Generic Cartesian
Local Vertical (LVCS)© 2015 Open Geospatial Consortium

648

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
K.3.1 Geographical Coordinate System (Geodetic)
The geographical coordinate system (also called the geodetic coordinate system), where thecoordinates are longitude, latitude and altitude above mean sea level, is the most commonly used
coordinate system today. Geographical latitude and longitude are the angles of the normal
on the reference ellipsoid along the point to the equator and zero meridian. The angles arenormally given as degrees, minutes and seconds. Altitude above mean sea level is the distanceabove and normal to the geoid in meters. The WGS 84 ellipsoid represents the actual geoid
within an accuracy of 100 meters. The prime meridian and the equator are the reference planes
used to define latitude and longitude.
In other terms, the geographic latitude – there are many other defined latitudes – of a point is theangle between the equatorial plane and a line normal to the reference ellipsoid’s surface. The
geographic longitude of a point is the angle between a reference plane, Greenwich, and a planepassing through the point, both planes being perpendicular to the equatorial plane. The
geographic height at a point is the distance from the reference ellipsoid to the point in a direction
normal to the reference ellipsoid.

Table K-1: Geographic Coordinate System (Geodetic)
Field

Specification

Properties

Orthogonal.
a: major semi-axis length

CS parameters andconstraints

b: minor semi-axis length
Constraints: a > b: (oblate ellipsoid)

Coordinate components: longitude in radians, and: geodetic latitude in radians.

Domain of thegenerating function or
mapping equations−π < φ < π22−π < λ ≤ π

Domain of the inverseof the generating
function or mapping
equationsx 2 y 2 z2++
= 1 and z ≠ ± b.
a2 a2 b2

© 2015 Open Geospatial Consortium

649

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

Specification

Notes(1) The CS surface is the oblate ellipsoid (or sphere)
surface excluding the pole points.
(2) The geodetic 3D CS induces this CS on the 3rd
coordinate surface at any point for which h = 0.
(3) If a = b, the geodetic latitude coincides with thespherical latitude .
(4) For WGS-84 a= 6,378,137 m and b = 6,356,752 m.
The inverse flattening ratio f-1 is 298.257223563.

K.3.2 Earth-Centered SRF (aka Rectangular Geocentric SRF)
The earth-centered spatial reference frame defines a three-dimensional Euclidian space withrespect to the geometric center of the reference ellipsoid, the center of the earth. The reference
datum of the Earth-centered SRF is based on the WGS-84 ellipsoid reference model. In this
SRF, the z-axis is pointing at the North Pole, the x-axis is pointing at the intersection of theequator and the Greenwich meridian, the prime meridian, and the y-axis is pointing at theintersection of the equator and 90o east longitude. The associated coordinate system is called theWorld Coordinate System (WCS); its units are meters. The WCS is used to specify the 3D
position of objects with respect to the earth-centered SRF. This coordinate system is used as anintermediate system to convert geodetic coordinates to LVCS and vice versa.
K.3.3 General Cartesian SRF
The Cartesian spatial reference frame defines a three-dimensional Euclidian space with respect toan arbitrary origin. The reference datum specifying the origin and the orientation of the SRF is
arbitrary, i.e. the reference datum can be specified within a geocentric SRF, a LVCS SRF or any
other SRF. The SRF is right-handed and orthonormal. In this SRF system, the z-axis is pointing
up and both the x-axis and y-axis lie in the horizontal plane. The associated coordinate system iscalled the General Cartesian Coordinate System; coordinates are specified in meters. This
coordinate system is used for the representation of 3-D objects, moving and/or static. Its use isgenerally constrained to objects that are small in comparison to the earth16.
K.3.4 Local Vertical SRF
The Local Vertical SRF (LVCS) spatial reference frame defines a three-dimensional Euclidian
space. It is a SRF similar to the Geocentric SRF except that the origin of the SRF is translated
and rotated to a point on the surface of the WGS-84 ellipsoid. At that point, the x-y plane istangent to the surface of the earth and the z-axis is normal to the ellipsoid. The associatedcoordinate system is called the local vertical coordinate system; the coordinates are specified inmeters. In this coordinate system, the z-axis is pointing up, the y-axis is pointing north and the

16 To ensure that the object preserves its shape, size, orientation, and relative geometry.

© 2015 Open Geospatial Consortium

650

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
x-axis is pointing east. Its use is generally constrained to a surface that is small in comparison to
the earth17.
K.4
Geodetic to Geocentric Transformation
Information providers and information consumers must transform geodetic information togeocentric information according to the following:(1)

If < , , h> represents the geodetic coordinates to be transformed, where is
the latitude, is the longitude, and h is the WGS84 height above mean-sealevel; and(2)

If <x, y, z> represents the geocentric coordinates; then using the WGS84
ellipsoid equatorial radius, a, of 6,378,137.0m and the WGS84 ellipsoid polarradius, b, of 6,356,752.314245m, the flattening f, the eccentricity e and theradius of curvature as a function of latitude N( ) are given by equation eq. A1:
f = (a − b) ae2 = 2 f − f 2(eq. A-1)

N (ϕ ) = a 1 − e 2 sin 2 ϕ

From these equations, we define the transformation of each geodetic coordinate as:

x = (N (ϕ ) + h) cosϕ cos λy = (N (ϕ ) + h) cosϕ sin λ((eq. A-2))

z = N (ϕ )(1 − e 2 ) + h sin ϕ

17 To ensure that the object preserves its shape, size, orientation, and direction© 2015 Open Geospatial Consortium

651

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
K.5
Geocentric to Geodetic Transformation
Geocentric coordinates cannot be transformed to the geodetic coordinate system directly.
Instead, a successive approximation approach is used to compute the new coordinates. The
following describes the algorithm to convert geocentric coordinates <x, y, z> to geodetic
coordinates < , , h>, where is the latitude, is the longitude, and h is the WGS84 height
above mean-sea-level. First, using the WGS84 ellipsoid equatorial radius, a = 6,378,137.0 m
and the WGS84 ellipsoid polar radius, b = 6,356,752.314245 m, the flattening f and theeccentricity e of the ellipsoid are given by equation A-3:

f = (a − b) a2

e = 2f − f

We first compute the longitude2(eq. A-3)

with equation A-4:

⎛ y ⎞λ = tan −1 ⎜ ⎟⎝ x ⎠(eq. A-4)

We then compute a first approximation of the latitude assuming a spherical earth model withequation A-5:

⎛
⎞
z
⎟
ϕ = tan −1 ⎜⎜ x 2 + y 2 ⎟⎝⎠(eq. A-5)

Then, we iteratively compute the radius of curvature as a function of latitude N( ) and, as aresult we iteratively converge to a new, more accurate latitude ’ with equation A-6:

N (ϕ ) = a 1 − e 2 sin 2 ϕ© 2015 Open Geospatial Consortium(eq. A-6)

652

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014⎛ z + N (ϕ ) e 2 sin ϕ ⎞⎟
ϕ ' = tan −1 ⎜
2
2
⎜
⎟
x +y
⎝
⎠

For each iteration, is replaced with ’, until the difference between the two values is less thana preset allowable error. The resulting latitude error will be less than . Finally, we compute theheight above mean-sea-level h with equation A-7h=x2 + y2− N (ϕ )cos ϕ(eq. A-7)

K.6
Geodetic to LVCS Coordinate Transformation
The transformation of a geodetic coordinate into an LVCS coordinate is decomposed into twoparts:(1)

Apply a coordinate transformation to each coordinate of an object from thegeodetic coordinate system to the rectangular geocentric coordinate system.

(2)

Then apply a second transformation to go from the geocentric coordinate
system to LVCS.

The first transformation, from geodetic to rectangular geocentric is described in section K.4. The
transformation is applied to the origin of the object. The result of this transformation is theorigin x0 of the object in the geocentric coordinate system. Then for each coordinate x of theobject, we apply the geodetic to geocentric transformation to coordinate x and we then computethe translation vector t between x and x0 in the geocentric coordinate system with equation A-8

t = x − x0

© 2015 Open Geospatial Consortium(eq. A-8)

653

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The second transformation, from geocentric to LVCS is presented here as an algorithm totransform all coordinates of an object from the geodetic coordinate system to LVCS. The
transformation from geodetic to LVCS first requires the assembly of a 3x3 rotation matrix M
with equation A-9:

cos λ00 ⎤⎡ − sin λ0⎢
M = ⎢ − sin ϕ0 cos λ0 − sin ϕ0 sin λ0 cos ϕ0 ⎥⎥⎢⎣ cos ϕ0 cos λ0
cos ϕ0 sin λ0 sin ϕ0 ⎥⎦

Where: 0 and(eq. A-9)

0 = the latitude and longitude of the origin of the object.

Finally, the rotation matrix M is applied to the translation vector t to obtain each coordinate xL in
the local vertical coordinate system with equation A-10:

xL = Mt(eq. A-10)

K.7
Angular Displacements to Linear Displacement
For WGS84, which is an elliptical representation of the earth, the transformation from angulardisplacements to equivalent linear displacements in a tangential plane is slightly different thanthat for a spherical earth.

For WGS84 we get…

δX = ρ t cos(lat )δlon
δY = ρ mδlat… as opposed to for a spherical earth© 2015 Open Geospatial Consortium

654

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

δX = ρ cos(lat )δlon
δY = ρδlatwhere…
δX , δY

are the linear displacements along the x and y axes.

ρ m , ρt

are the meridional and transverse radiuses of curvature.

ρis the radius of the spherical earth.

δlat , δlon

are small displacements at location lat/lon

we have…

ρm =
ρt =

(

a 1 − e2)3

[1 − e sin (lat )]
2

2

2

a

1 − e 2 sin 2 (lat )

b2
a2
a −b
⇒ b = a (1 − f )f =ae2 = 1 −where…
e2

is the square of the eccentricity

a,b

are the semi-major an the minor axes of the earthfis the flattening

K.8
3D Model Coordinate System
This section describes the transformations required to go to-and-from the DIS/HLA and the CDB
moving model coordinate systems.

© 2015 Open Geospatial Consortium

655

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

The CDB 3D model coordinate system conventions were presented earlier in Chapter 6.

Figure K-2: CDB 3D Model Coordinate System

The DIS coordinate system is used on a HLA network and is represented on the following figure.

Figure K-3: DIS Entity18 Coordinate System

The two coordinate systems differ in the axis conventions (Z is up in the CDB while Z is down
in DIS). Furthermore, the position of the origin also differs; DIS requires that the origin of its
18

DIS refers to a 3D model as an entity.

© 2015 Open Geospatial Consortium

656

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
coordinate system be located at the center of the entity’s bounding box excluding its articulated
and attached parts19. The CDB specification uses a different convention.

The transformation from the CDB coordinate system to the DIS coordinate system involves one
translation followed by two rotations. The translation represents the offset to the DIS origin as
defined in chapter 6. Assume that P0 represents the coordinate of the DIS origin.

P0 = ( x0 , y0 , z0 )(eq. A-11)

The two rotations are relatively simple. First, rotate 180° about the X-axis. This rotation will
position the Z-axis in its correct position. Equation A-12 represents this rotation.

⎧1 0 0 ⎫⎪⎪
M x = ⎨0 − 1 0 ⎬⎪0 0 − 1⎪⎩⎭(eq. A-12)

Second, rotate -90° about this new Z-axis. This last rotation completes the transformation and isrepresented by equation A-13.

⎧0 − 1 0⎫⎪⎪
M z = ⎨1 0 0⎬⎪0 0 1⎪⎩⎭(eq. A-13)

Now, if we combine equations A-11, A-12 and A-13, we can transform a point P expressed in
the CDB coordinate system into point P’ in the DIS coordinate system. Equation A-14 presents
the complete transformation.

19

This definition can be found on page 3 of IEEE Std 1278.1-1995. Note that the CDB provides the means to store the DIS
origin within the coordinate system space of the model.

© 2015 Open Geospatial Consortium

657

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

P ' = M z M x ( P − P0 )(eq. A-14)

The combined matrix gives equation A-15 and the resulting individual terms are presented in A16.

⎧0 1 0 ⎫⎪⎪
M zx = ⎨1 0 0 ⎬⎪0 0 − 1⎪⎩⎭(eq. A-15)

x ' = y − y0
y ' = x − x0(eq. A-16)

z ' = z0 − z

If a single transformation matrix M is preferred then Matrix Mzx and point P0 are combined toobtain the set of equations A-17.

P ' = MP
where...
⎧0⎪1⎪
M = ⎨
⎪0⎪⎩0− y 0 ⎫− x0 ⎪⎪⎬
0 − 1 z0 ⎪
0 0
1 ⎪⎭

1000(eq. A-17)

and ...
⎧ x ⎫⎪ y ⎪⎪ ⎪
P = ⎨ ⎬⎪ z ⎪⎪⎩ 1 ⎪⎭

© 2015 Open Geospatial Consortium

658

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
To convert from the DIS coordinate system back to the CDB coordinate system, the inverse
transformation is applied. Knowing that unscaled rotation matrices (the upper 3 x 3 portion ofM) have the property that their inverse is their transpose, we obtain the set of equations A-18.

P = M −1 P 'where...
⎧0⎪1⎪
M −1 = ⎨
⎪0
⎪⎩0

x0 ⎫
0 0 y 0 ⎪⎪⎬
0 − 1 z0 ⎪
0 0 1 ⎪⎭1

0

© 2015 Open Geospatial Consortium(eq. A-18)

659

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

Appendix L
L. CDB Base Materials
The complete list of CDB Base Materials is part of the metadata provided with the CDB
Specification Distribution Package and can be found in the following file:\CDB\Metadata\Materials.xml

Note: As of CDB Specification 3.2, the list of CDB Base Materials is no longer presented here to
avoid the risk of miscorrelation between the appendix and the metadata. The list is now
exclusively found in the Metadata folder.

© 2015 Open Geospatial Consortium

661

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

Appendix M
M. CDB Directory Naming and Structure
In previous versions of the Specification, Appendix M was used to present the complete list ofnames allowed to construct the directories of the CDB. As of version 3.2, the appendix has been
replaced by a combination of folder hierarchy and metadata files delivered with the CDB
Specification Distribution Package.

The /CDB folder hierarchy provides a complete list of directory and file name patterns of the
CDB; it summarizes the structure of the CDB presented in chapter 3. The following files arenecessary to expand the patterns:/CDB/Metadata/Feature_Data_Dictionary.xml

directory names associated with FACC codes.

provides

the

list

of

/CDB/Metadata/Moving_Model_Codes.xml provides the list of names for

DIS Entity Kinds, Domains, and Categories.

/CDB/Metadata/DIS_Country_Codes.xml contains the list of DIS Country

Names.
Together, these files provide all the information required to build the names of all
directories permitted by the Specification.

© 2015 Open Geospatial Consortium

662

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

Appendix N
N. CDB Feature Data Dictionary
The CDB Feature Data Dictionary (FDD) is provided with the CDB Specification in the formof an XML file. An XML Stylesheet is provided to format and display the dictionary inside astandard Web browser. Furthurmore, the XML Schema defining the format of the FDD canalso be found in the Schema subdirectory of the CDB Specification Distribution Package.
See /CDB/Metadata/Feature_Data_Dictionary.xml for the complete list of FACC codes
supported by the Specification.

Note: As of CDB Specification 3.2, the CDB FDD is no longer presented here to avoid the riskof miscorrelation between the appendix and the metadata. The FDD is now exclusively foundin the Metadata folder.

© 2015 Open Geospatial Consortium.

663

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

Appendix O
O. List of Texture Component Selectors
The following table provides the list of codes to use to build CDB model texture filenames.

Texture Kind
CS1 (Sxxx)
002 – Month003 – Season

004 – Uniform
Paint Scheme

Texture Index
CS2 (Txxx)

Description

001

January002

February

003

March

004

April

005

May

006

June

007

July

008

August009

September

010

October

011

November

012

December001

Spring002

Summer003

Autumn004

Winter

001

Grey

002

White

003

Green

004

Black

005

Beige

© 2015 Open Geospatial Consortium.

665

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

005 – Camouflage
Paint Scheme

006 – Airline Paint
SchemeTexture Index
CS2 (Txxx)

Description

006

Blue

007

Red

008

Yellow

009

Brown

010

Pink

011

Purple012

Burgundy

013

Orange014

Light Blue

015

Khaki

016

Dark Grey

017

Amber

018

Gold

019

Silver020

Copper001

Desert002

Winter003

Forest004

Generic

005

Urban

001

AAH Aloha Airlines Inc.

002

AAL American Airlines Inc.

003

AAR Asiana Airlines Inc.

004

AAW Afriqiyah Airways

005

ABR Air Contractors (UK) Limited© 2015 Open Geospatial Consortium.

666

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

006

ACA Air Canada

007

ACI Air Caledonie International008

ADR Adria Airways - The Airline of Slovenia

009

AEA Air Europa Lineas Aereas, S.A.

010

AEE Aegean Airlines S.A.

011

AEW Aerosvit Airlines

012

AFG Ariana Afghan Airlines

013

AFL Aeroflot Russian Airlines

014

AFR Air France

015

AGN Air Gabon

016

AHY Azerbaijan Hava Yollary017

AIC Air-India Limited

018

AIZ Arkia - Israeli Airlines Ltd

019

AJM Air Jamaica

020

ALK SriLankan Airlines Limited

021

AMC Air Malta p.l.c.

022

AML Air Malawi Limited

023

AMU Air Macau Company Limited

024

AMX Aeromexico

025

ANA All Nippon Airways Co. Ltd.

026

ANG Air Niugini Pty Limited

027

ANS Air Nostrum L.A.M.S.A.

028

ANZ Air New Zealand Limited

029

ARG Aerolineas Argentinas

030

ASA Alaska Airlines Inc.

© 2015 Open Geospatial Consortium.

667

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

031

ATC Air Tanzania Company Ltd.

032

AUA Austrian Airlines, Osterreichische033

AUI Ukraine International Airlines

034

AUT Cielos del Sur S.A.

035

AVA Aerovias del Continente Americano – Avianca

036

AVN Air Vanuatu (Operations) Limited

037

AWE America West Airlines Inc.

038

AZA Alitalia - Linee Aeree Italiane

039

AZW Air Zimbabwe (Pvt) Ltd.

040

BAG dba Luftfahrtgesellschaft mbH

041

BAW British Airways p.l.c.

042

BBC Biman Bangladesh Airlines

043

BCS European Air Transport

044

BCY Cityjet

045

BEE Jersey European Airways Limited

046

BER Air Berlin GmbH & Co. Luftverkehrs KG

047

BKP Bangkok Airways Co. Ltd.

048

BLF Blue1 Oy049

BLV Bellview Airlines Ltd.

050

BMA British Midland Airways Ltd.

051

BOT Air Botswana Corporation

052

BPA Blue Panorama Airlines S.p.A.

053

BRA SAS Braathens AS

054

BRU Belavia

055

BRZ Samara Airlines© 2015 Open Geospatial Consortium.

668

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

056

BWA BWIA West Indies Airways Limited

057

CAL China Airlines

058

CAW Comair Ltd.

059

CCA Air China Limited

060

CDG Shandong Airlines

061

CES China Eastern Airlines

062

CHH Hainan Airlines Company Limited

063

CLH Lufthansa CityLine GmbH064

CLX Cargolux Airlines International S.A.

065

CMI Continental Micronesia, Inc.

066

CMP Compania Panamena de Aviacion, S.A.

067

CNW China Northwest Airlines

068

COA Continental Airlines, Inc.

069

CPA Cathay Pacific Airways Ltd.

070

CPN Caspian Airlines Service Company Ltd.

071

CRL CORSAIR

072

CSA Czech Airlines a.s., CSA

073

CSN China Southern Airlines

074

CTN Croatia Airlines

075

CUB Cubana de Aviacion S.A.

076

CXA Xiamen Airlines

077

CYH China Yunnan Airlines

078

CYP Cyprus Airways Limited

079

DAH Air Algerie

080

DAL Delta Air Lines Inc.

© 2015 Open Geospatial Consortium.

669

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

081

DAN Maersk Air A.S.

082

DAT Delta Air Transport N.V.

083

DHK DHL Air Limited

084

DHX DHL International E.C.

085

DLH Deutsche Lufthansa AG

086

DNM Denim Air

087

DTA TAAG - Linhas Aereas de Angola

088

EIN Aer Lingus Limited

089

ELG ALPI Eagles S.p.A.

090

ELL Estonian Air

091

ELY El Al Israel Airlines Ltd.

092

ETD Etihad Airways

093

ETH Ethiopian Airlines Enterprise094

EVA EVA Airways Corporation

095

EWG Eurowings AG

096

FCN Falcon Air AB

097

FDX FedEx

098

FIN Finnair Oyj

099

FJI Air Pacific Ltd.

100

GBL GB Airways Ltd.

101

GEC Lufthansa Cargo AG

102

GFA Gulf Air Company G.S.C.

103

GHA Ghana Airways Corp.

104

GIA Garuda Indonesia

105

HCY Helios Airways© 2015 Open Geospatial Consortium.

670

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

106

HDA Hong Kong Dragon Airlines Limited

107

HEJ Hellas Jet S.A.

108

HHN Hahn Air Lines109

HLF Hapag Lloyd Fluggesellschaft

110

HZL Hazelton Airlines dba Regional Express

111

IAC Indian Airlines112

IAW Iraqi Airways

113

IBB Binter Canarias

114

IBE Iberia - Lineas Aereas de Espana115

ICE Icelandair

116

ICL C.A.L. Cargo Airlines Ltd.

117

IRA Iran Air

118

IRC Iran Aseman Airlines

119

IRM Mahan Airlines120

ISR Israir Airlines and Tourism Ltd.

121

ISS Meridiana S.p.A.

122

IYE Yemenia - Yemen Airways

123

JAI Jet Airways (India) Limited

124

JAL Japan Airlines International Co., Ltd.

125

JAT Jat Airways

126

JAZ JALways Co. Ltd.

127JKK Spanair S.A.

128

KAC Kuwait Airways

129

KAL Korean Air Lines Co. Ltd.

130

KHA Kitty Hawk Aircargo, Inc.

© 2015 Open Geospatial Consortium.

671

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

131

KLM KLM Royal Dutch Airlines132

KOR Air Koryo

133

KQA Kenya Airways

134

KRP Carpatair S.A.

135

LAA Libyan Arab Airlines

136

LAM LAM - Linhas Aereas de Mocambique137

LAN Lan Airlines S.A.

138

LAP TAM - Transportes Aereos del139

LBC Albanian Airlines MAK S.H.P.K.

140

LBH Laker Airways (Bahamas) Limited

141

LCO Lan Chile Cargo S.A.

142

LDA Lauda Air Luftfahrt AG

143

LDI Lauda Air S.p.A.

144

LGL Luxair

145

LIL Lithuanian Airlines146

LLB Lloyd Aereo Boliviano S.A. (LAB)

147

LOT LOT - Polish Airlines

148

LPE Lan Peru S.A.

149

LRC Lineas Aereas Costarricenses S.A.

150

LTU LTU International Airways

151

LXR Air Luxor, S.A.

152

MAH Malev Hungarian Airlines Limited

153

MAK Macedonian Airlines

154

MAS Malaysia Airline System Berhad

155

MAU Air Mauritius© 2015 Open Geospatial Consortium.

672

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

156

MAZ Zambian Airways

157

MDG Air Madagascar

158

MEA Middle East Airlines AirLiban

159

MGL MIAT - Mongolian Airlines

160

MGX Montenegro Airlines

161

MLD Air Moldova

162

MPX Aeromexpress S.A. de C.V.

163

MRS Air Marshall Islands, Inc.

164

MSR Egyptair

165

MXA Compania Mexicana de Aviacion

166

NBK Albarka Air Services Ltd.

167

NCA Nippon Cargo Airlines168

NMB Air Namibia

169

NTW Nationwide Airlines (Pty) Ltd.

170

NWA Northwest Airlines, Inc.

171

OAL Olympic Airlines172

OAS Oman Aviation Services Co. (SAOG)173

PAL Philippine Airlines, Inc.

174

PAO Polynesian Limited

175

PGA Portugalia - Companhia Portuguesa de176

PIA Pakistan International Airlines177

PLK Pulkovo Aviation Enterprise178

PNW Palestinian Airlines

179

PUA Pluna Lineas Aereas Uruguayas S.A.

180

QFA Qantas Airways Ltd.

© 2015 Open Geospatial Consortium.

673

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

181

QTR Qatar Airways(Q.C.S.C)

182

RAM Royal Air Maroc183

RBA Royal Brunei Airlines Sdn. Bhd.

184

REU Air Austral185

RJA Royal Jordanian186

ROT TAROM - Transporturile Aeriene Romane

187

RSN Royal Swazi National Airways Corp.

188

RWD Rwandair Express

189

SAA South African Airways

190

SAS Scandinavian Airlines System (SAS)191

SAT SATA - Air Acores

192

SBI Siberia Airlines

193

SER Aero California

194

SEY Air Seychelles Limited

195

SFR Safair (Proprietary) Ltd.

196

SIA Singapore Airlines Limited

197

SKX Skyways AB

198

SLA Sierra National Airlines

199

SLK SilkAir (S) Pte. Ltd.

200

SLM Surinam Airways Ltd.

201

SNG Air Senegal International

202

SOL Solomon Airlines

203

SQC Singapore Airlines Cargo Pte. Ltd.

204

SUD Sudan Airways Co. Ltd.

205

SVA Saudi Arabian Airlines© 2015 Open Geospatial Consortium.

674

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

206

SWD Southern Winds S.A.

207

SWR SWISS International Air Lines Ltd

208

SYR Syrian Arab Airlines

209

TAI Taca International Airlines, S.A.

210

TAM TAM Linhas Aereas S.A.

211

TAP TAP - Air Portugal

212

TAR Tunisair

213

TAY TNT Airways S.A.

214

THA Thai Airways International Public

215

THT Air Tahiti Nui

216

THY Turkish Airlines Inc.

217

TMA Trans-Mediterranean Airways

218

TNA TransAsia Airways Corporation

219

TSO Transaero Airlines

220

TUA Turkmenistan Airlines221

UAE Emirates

222

UAL United Airlines, Inc.

223

UPS UPS224

USA US Airways, Inc.

225

UYC Cameroon Airlines

226

VAP Phuket Airlines Co., Ltd.

227

VDA Volga-Dnepr Airline Joint Stock228

VIR Virgin Atlantic Airways Limited

229

VLE Volare Airlines S.p.A.

230

VLK Vladivostok Air JSC© 2015 Open Geospatial Consortium.

675

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

231

VRG Varig S.A.

232

VSP Viacao Aerea Sao Paulo, S.A. (VASP)233

VTA Air Tahiti

234

WIF Wideroe's Flyveselskap A.S.

235

WNT Cargojet Airways Ltd.

236

CRX Crossair

237

WJA WestJet Airlines Ltd.

238

JAS Japan Air System

239

NWW North West Airlines

240

MEP Midwest Express Airlines

241

TWA Trans World Airlines

242

SAB Sabena243

TUI Tuninter

244

SRT Trans Asian Airlines

245

JBU JetBlue Airways

246

TSC Air Transat

247

SWG Sunwing Airlines

248

FFM Firefly

249

BVT Berjaya Air

250

VLG Vueling Airlines251

SKY Skymark Airlines

252

JST Jetstar Airways

253

ABX ABX Air254

CQH Spring Airlines

255

POE Porter Airlines© 2015 Open Geospatial Consortium.

676

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)

Description

256

EAQ Eastern Australia

257

EZY EasyJet

258

NLY Niki259

VOZ Virgin Australia

260

KNA Kunming Airlines

261

CSC Sichuan Airlines

262

VRD Virgin America

263

DKH Juneyao Airlines264

KEN Kenmore Air265

XAK Air Kenya

266

NZM Mount Cook Airline

267

FDA Fuji Dream Airlines

268

TAE TAME (Línea Aérea del Ecuador)

269

CFE BA CityFlyer

270

JZA Jazz Aviation

271

CSH Shanghai Airlines

272

BEE Flybe

273

TYR Tyrolean Airways

274

SWA Southwest Airlines275

XME Australian Air Express

276

BEL Brussels Airlines

277

GCR Tianjin Airlines278

VOI Volaris279

ARA Arik Air

280

LNI Lion Air© 2015 Open Geospatial Consortium.

677

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Texture Kind
CS1 (Sxxx)

009 – Quarter

054 – Contaminant

055 – Skid Mark

Texture Index
CS2 (Txxx)

Description

281

RYR Ryanair

282
283
284
285
286

SHU Aurora
NIG Aero Contractors
SCW Malmö Aviation
NAX Norwegian Air Shuttle
RAR Air Rarotonga

001

First quarter of the year

002

Second quarter of the year003

Third quarter of the year

004

Fourth quarter of the year

001

Wet Surface002

Snowy Surface003

Icy Surface

004

Slushy Surface

005

Patchy Wet Surface

006

Patchy Snowy Surface

007

Patchy Icy Surface

008

Patchy Sandy Surface

009

Patchy Dirty Surface

010

Volcanic Ash

011

Patchy Volcanic Ash001

Tire Mark

Examples:A geospecific City Hall especially decorated for the Halloween during themonth (S002) of October (T010) could have a texture named
Geocell_D301_S002_T010_LOD_UREF_RREF_City-Hall.rgb.
The texture of a geotypical house used during the first (T001) quarter (S009)
of the year could be named D501_S009_T001_Wxx_House.rgb.

© 2015 Open Geospatial Consortium.

678

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Similarly, the uniform (S004) grey (T001) texture used with a Cobra
helicopter could be named D601_S004_T001_Wxx_Cobra.rgb.
A 1024 by 1024 (W10) texture representing an M1A2 tank desert (T001)
camouflage(S005)
couldbestored
in
a
file
named
D601_S005_T001_W10_M1A2.rgb.
An Airbus 380 model 800 operated by the Emirates (T221) Airlines (S006)
could be stored in a file named D601_S006_T221_Wxx_A380-800.rgb.
Notes:
Texture Kind 002 and 009 are complete; the number of months and quarters
will not change.
Texture Kind 004 will expand as new colors are added. Color names aredefined here: http://en.wiktionary.org/wiki/Appendix:Colors.
Texture Kind 005, the Camouflage Paint Scheme, follows a similar numbering
scheme as the HLA’s RPR-FOM Version 2 Draft 17. The list will expand as
new camouflages are needed or new values added to the RPR-FOM.
Texture Kind 006 will expand as ICAO assigns new airline acronyms.
Texture Kind 054 and 055 will expand as new contaminants and skid marks
are deemed necessary.

© 2015 Open Geospatial Consortium.

679

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

Appendix P
P. SGI Image File Format
This document has been annotated to reflect the conventions established by the CDB
Specification. Collectively, these conventions are referred to as SGI/CDB. The conventions
define how SGI Image files are interpreted by a CDB-compliant SGI Image reader; the statedconventions supersede or replace related aspects of this annotated specification. Unless statedotherwise, CDB-compliant SGI Image readers will ignore any data that fails to conform to thestated conventions.

© 2015 Open Geospatial Consortium

681

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

For Version 1.00 of this spec see:
http://paulbourke.net/dataformats/sgirgb/sgiversion.html

Draft version 0.97
The SGI Image File Format
Paul Haeberli
paul@sgi.com
Silicon Graphics Computer Systems

This is the definitive document describing the SGI image file format.

This

is a low level spec that describes the actual byte level format of SGI image
files.

On SGI machines the preferred way of reading and writing SGI image

files is to use the image library -limage.

This library provides a setof functions that make it easy to read and write SGI images.

If you areon an SGI workstation you can get info on -limage by doing:% man 4 rgb
A note on byte order of values in the SGI image files
In the following description a notation like bits[7..0] is used to denote© 2015 Open Geospatial Consortium

682

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014a range of bits in a binary value.

Bit 0 is the lowest order bit in

the value.
All short values are represented by 2 bytes.

The first byte stores thehigh order 8 bits of the value: bits[15..8].

The second byte storesthe low order 8 bits of the value: bits[7..0].
So, this function will read a short value from the file:unsigned short getshort(inf)FILE *inf;{
unsigned char buf[2];fread(buf,2,1,inf);
return (buf[0]<<8)+(buf[1]<<0);}
All long values are represented by 4 bytes.

The first byte stores thehigh order 8 bits of the value: bits[31..24].

The second byte stores

bits[23..16].

The third byte stores bits[15..8]. The forth byte storesthe low order 8 bits of the value: bits[7..0].
So, this function will read a long value from the file:static long getlong(inf)FILE *inf;{
unsigned char buf[4];fread(buf,4,1,inf);
return (buf[0]<<24)+(buf[1]<<16)+(buf[2]<<8)+(buf[3]<<0);}

The general structure of an SGI image file is as shown below:© 2015 Open Geospatial Consortium

683

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The header indicates whether the image is run length encoded (RLE).
If the image is not run length encoded, this is the structure:
The Header
The Image Data
If the image is run length encoded, this is the structure:
The Header
The Offset Tables
The Image Data

The Header
The header consists of the following:Size| Type| Name| Description

2 bytes | short| MAGIC| IRIS image file magic number

1 byte| char| STORAGE| Storage format

1 byte| char| BPC| Number of bytes per pixel channel

2 bytes | ushort | DIMENSION | Number of dimensions
2 bytes | ushort | XSIZE| X size in pixels

2 bytes | ushort | YSIZE| Y size in pixels

2 bytes | ushort | ZSIZE| Number of channels

4 bytes | long

| PIXMIN| Minimum pixel value

4 bytes | long

| PIXMAX| Maximum pixel value

4 bytes | char

| DUMMY| Ignored

80 bytes | char

| IMAGENAME | Image name

4 bytes | long

| COLORMAP| Colormap ID| DUMMY| Ignored

404 bytes | char

Here is a description of each field in the image file header:© 2015 Open Geospatial Consortium

684

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
MAGIC - This is the decimal value 474 saved as a short. This
identifies the file as an SGI image file.
STORAGE - specifies whether the image is stored using run
length encoding (RLE) or not (VERBATIM).
of this byte will be 1.

If RLE is used, the value

Otherwise the value of this byte will be 0.

The only allowed values for this field are 0 or 1.
BPC - describes the precision that is used to store eachchannel of an image.
component.

This is the number of bytes per pixel

The majority of SGI image files use 1 byte per

pixel component, giving 256 levels.
2 bytes per component.

Some SGI image files use

The only allowed values for this field

are 1 or 2.
DIMENSION - described the number of dimensions in the data stored
in the image file.

The only allowed values are 1, 2, or 3.

If

this value is 1, the image file consists of only 1 channel andonly 1 scanline (row).

The length of this scanline is given by thevalue of XSIZE below.

If this value is 2, the file consists of asingle channel with a number of scanlines. The width and heightof the image are given by the values of XSIZE and YSIZE below.
If this value is 3, the file consists of a number of channels.
The width and height of the image are given by the values of
XSIZE and YSIZE below.

The number of channels is given by thevalue of ZSIZE below.
XSIZE - The width of the image in pixels
YSIZE - The height of the image in pixels
ZSIZE - The number of channels in the image.

B/W (greyscale) images

are stored as 2 dimensional images with a ZSIZE of 1.

RGB color

images are stored as 3 dimensional images with a ZSIZE of 3.

An RGB

image with an ALPHA channel is stored as a 3 dimensional image witha ZSIZE of 4.

There are no inherent limitations in the SGI image

file format that would preclude the creation of image files with more

© 2015 Open Geospatial Consortium

685

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
than 4 channels.
PIXMIN - The minimum pixel value in the image.

The value of

0 may be used if no pixel has a value that is smaller than 0.
PIXMAX - The maximum pixel value in the image.

The value of

255 may be used if no pixel has a value that is greater than 255.
This is the value that is considered to be full brightness in
the image.
DUMMY - This 4 bytes of data should be set to 0.
IMAGENAME - An null terminated ascii string of up to 79 characters
terminated by a null may be included here.

This is not commonly

used.
COLORMAP - This controls how the pixel values in the file should beinterpreted.
0:

It can have one of these four values:

NORMAL - The data in the channels represent B/W values
for images with 1 channel, RGB values for images with 3
channels, and RGBA values for images with 4 channels.
Almost all the SGI image files are of this type.

1:

DITHERED - The image will have only 1 channel of data.
For each pixel, RGB data is packed into one 8 bit value.
3 bits are used for red and green, while blue uses 2 bits.
Red data is found in bits[2..0], green data in bits[5..3],and blue data in bits[7..6].

2:

This format is obsolete.

SCREEN - The image will have only 1 channel of data.
This format was used to store color-indexed pixels.
To convert the pixel values into RGB values a colormap
must be used.

The appropriate color map varies fromimage to image.
3:

This format is obsolete.

COLORMAP - The image is used to store a color map from© 2015 Open Geospatial Consortium

686

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
an SGI machine.

In this case the image is not displayablein the conventional sense.
DUMMY - This 404 bytes of data should be set to 0. This makes theheader exactly 512 bytes.

The Image Data (if not RLE)
If the image is stored verbatim (without RLE), then image data directly
follows the 512 byte header.
channel is written first.

The data for each scanline of the first

If the image has more than 1 channel, all

the data for the first channel is written, followed by the remaining
channels.

If the BPC value is 1, then each scanline is written as XSIZE

bytes.

If the BPC value is 2, then each scanline is written as XSIZE

shorts.

These shorts are stored in the byte order described above.

The Offset Tables (if RLE)
If the image is stored using run length encoding, offset tables
follow the header that describe what the file offsets are to the
RLE for each scanline.

This information only applies if the value

for STORAGE above is 1.
Size| Type| Name| Descriptiontablen longs | long

| STARTTAB| Start table

tablen longs | long

| LENGTHTAB | Length table

One entry in each table is needed for each scanline of RLE data.

The

total number of scanlines in the image (tablen) is determined by the
product of the YSIZE and ZSIZE.

There are two tables of longs thatare written. Each consists of tablen longs of data.

The first

table has the file offsets to the RLE data for each scanline in theimage.

In a file with more than 1 channel (ZSIZE > 1) this table firsthas all the offsets for the scanlines in the first channel, followed© 2015 Open Geospatial Consortium

687

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
be offsets for the scanlines in the second channel, etc.

The second

table has the RLE data length for each scanline in the image.

In afile with more than 1 channel (ZSIZE > 1) this table first has all the
RLE data lengths for the scanlines in the first channel, followed
be RLE data lengths for the scanlines in the second channel, etc.
To find the the file offset, and the number of bytes in the RLE data
for a particular scanline, these two arrays may be read in and indexed asfollows:
To read in the tables:
unsigned long *starttab, *lengthtab;
tablen = YSIZE*ZSIZE*sizeof(long);
starttab = (unsigned long *)mymalloc(tablen);lengthtab = (unsigned long *)mymalloc(tablen);fseek(inf,512,SEEK_SET);
readlongtab(inf,starttab);readlongtab(ing,lengthtab);

To find the file offset and RLE data length for a scanline:
rowno is an integer in the range 0 to YSIZE-1
channo is an integer in the range 0 to ZSIZE-1
rleoffset = starttab[rowno+channo*YSIZE]
rlelength = lengthtab[rowno+channo*YSIZE]
It is possible for two identical rows (scanlines) to share compresseddata.

A completely white image could be written as a single compressed

row and having all table entries point to that row.

Another little hackthat should work is if you are writing out a RGB RLE file, and aparticular scanline is achromatic (greyscale), you could just make ther, g and b rows point to the same data!!

© 2015 Open Geospatial Consortium

688

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
The Image Data (if RLE)
This information only applies if the value for STORAGE above is 1.

If

the image is stored using run length encoding, the image data follows
the offset tables above.

The RLE data is not in any particular order.

The offset tables above are used to locate the rle data for any scanline.
The RLE data must be read in from the file and expanded into pixel
data in the following manner:
If BPC is 1, then there is one byte per pixel.

In this case theRLE data should be read into an array of chars.

To expanddata, the low order seven bits of the first byte: bits[6..0]
are used to form a count.

If the high order bit of the first

byte is 1: bit[7], then the count is used to specify how many
bytes to copy from the RLE data buffer to the destination.
Otherwise, if the high order bit of the first byte is 0: bit[7],then the count is used to specify how many times to repeat thevalue of the following byte, in the destination.
continues until a count of 0 is found.

This processThis should decompress

exactly XSIZE pixels.
Here is example code to decompress a scanline:
expandrow(optr,iptr,z)unsigned char *optr, *iptr;
int z;{
unsigned char pixel, count;optr += z;
while(1) {pixel = *iptr++;if ( !(count = (pixel & 0x7f)) )return;if(pixel & 0x80) {while(count--) {© 2015 Open Geospatial Consortium

689

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
*optr = *iptr++;
optr+=4;}} else {pixel = *iptr++;while(count--) {*optr = pixel;
optr+=4;}}}}
If BPC is 2, there is one short (2 bytes) per pixel.

In thiscase the RLE data should be read into an array of shorts.

To

expand data, the low order seven bits of the first short: bits[6..0]
are used to form a count.

If bit[7] of the first short is 1, thenthe count is used to specify how many shorts to copy from the RLE
data buffer to the destination.

Otherwise, if bit[7] of the firstshort is 0, then the count is used to specify how many times torepeat the value of the following short, in the destination.
process proceeds until a count of 0 is found.
exactly XSIZE pixels.

This

This should decompress

Note that the byte order of short data in

the input file should be used, as described above.

Implementation notes
Implementation of both RLE and VERBATIM format for images with
BPC of 1 is required since the great majority of SGI images are inthis format.

Support for images with a 2 BPC is encouraged.

If the ZSIZE of an image is 1, it is assumed to represent B/Wvalues.

If the ZSIZE is 3, it is assumed to represent RGB data,and if ZSIZE is 4, it is assumed to contain RGB data with alpha.
The origin for all SGI images is the lower left hand corner.

© 2015 Open Geospatial Consortium

The

690

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
first scanline (row 0) is always the bottom row of the image.
Naming Conventions
On SGI systems, SGI image files end with the extension .bw ifthey are B/W images, they end in .rgb if they contain RGB image
data, and end in .rgba if they are RGB images with alpha channel.
Sometimes the .sgi extension is used as well.
An example
This program will write out a valid B/W SGI image file:#include “stdio.h”#define IXSIZE(23)#define IYSIZE(15)

putbyte(outf,val)
FILE *outf;
unsigned char val;{
unsigned char buf[1];buf[0] = val;
fwrite(buf,1,1,outf);}
putshort(outf,val)
FILE *outf;
unsigned short val;{
unsigned char buf[2];buf[0] = (val>>8);
buf[1] = (val>>0);© 2015 Open Geospatial Consortium

691

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
fwrite(buf,2,1,outf);}
static int putlong(outf,val)
FILE *outf;
unsigned long val;{
unsigned char buf[4];buf[0] = (val>>24);
buf[1] = (val>>16);
buf[2] = (val>>8);
buf[3] = (val>>0);
return fwrite(buf,4,1,outf);}
main(){FILE *of;char iname[80];unsigned char outbuf[IXSIZE];
int i, x, y;of = fopen(“example.rgb”,”w”);
if(!of) {fprintf(stderr,”sgiimage: can't open output file\n”);exit(1);}putshort(of,474);/* MAGIC*/

putbyte(of,0);/* STORAGE is VERBATIM*/

putbyte(of,1);/* BPC is 1*/

putshort(of,2);/* DIMENSION is 2*/

putshort(of,IXSIZE);/* XSIZE*/

putshort(of,IYSIZE);/* YSIZE*/

putshort(of,1);/* ZSIZE*/

putlong(of,0);/* PIXMIN is 0*/

putlong(of,255);/* PIXMAX is 255*/© 2015 Open Geospatial Consortium

692

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
for(i=0; i<4; i++)/* DUMMY 4 bytes*/

fwrite(iname,80,1,of);/* IMAGENAME*/

putlong(of,0);/* COLORMAP is 0*/

for(i=0; i<404; i++)/* DUMMY 404 bytes*/

putbyte(of,0);
strcpy(iname,”No Name”);

putbyte(of,0);for(y=0; y<IYSIZE; y++) {for(x=0; x<IXSIZE; x++)outbuf[x] = (255*x)/(IXSIZE-1);
fwrite(outbuf,IXSIZE,1,of);}fclose(of);}© 2015 Open Geospatial Consortium

693

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

Appendix Q
Q. Table of Dataset Codes
The table below summarizes the CDB dataset codes along with their names and theirapplicability to the three active versions of the CDB Specification.

DatasetName

Specification
Code

3.0

3.2

Elevation

001

√

√

MinMaxElevation

002

√

√

MaxCulture

003

√

√

Imagery004√√

RMTexture

005

√

√

RMDescriptor

006

√

√

Reserved

007

Reserved

008

Reserved

020

GSFeature

100

√

√

GTFeature

101

√

√

GeoPolitical

102

√

√

VectorMaterial

200

√

√

RoadNetwork

201

√

√

RailRoadNetwork

202

√

√

PowerLineNetwork

203

√

√

HydrographyNetwork

204

√

√

© 2015 Open Geospatial Consortium

695

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

Name

Code

3.0

3.2

GSModelGeometry

300

√

√

GSModelTexture

301

√

√

GSModelSignature

302

√

√

GSModelDescriptor

303

√

√

GSModelMaterial

304√

GSModelInteriorGeometry305√

GSModelInteriorTexture

306√

GSModelInteriorDescriptor

307√

GSModelInteriorMaterial

308√

GSModelCMT

309√

T2DModelGeometry

310√

NavData

400√√

Navigation

401

√

√

GTModelGeometry

500

√

√

510
GTModelTexture

501

√
√

511
GTModelSignature

502

√
√

512
GTModelDescriptor

503

GTModelMaterial504© 2015 Open Geospatial Consortium

√
√

√
√

696

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

Specification
Code

3.0

3.2

GTModelCMT

505√

GTModelInteriorGeometry

506√

GTModelInteriorTexture

507√

GTModelInteriorDescriptor

508√

GTModelInteriorMaterial

509√

GTModelInteriorCMT

513√

MModelGeometry

600

√

√

MModelTexture

601

√

√

MModelSignature

602

√

606

√

MModelDescriptor

603

√

√

MModelMaterial

604√

MModelCMT

605√

Metadata

700√

ClientSpecific

701√

Reserved for CDB Extensions

9xx

Dataset Code is not used√

Dataset Code is in use
Dataset Code is deprecated© 2015 Open Geospatial Consortium

697

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
Dataset Code is reserved© 2015 Open Geospatial Consortium

698

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

Appendix R
R. Derived Datasets within the CDB
As seen throughout this document, the CDB Specification provides all the means andmechanisms to populate all the simulation datasets without involving data duplication by using
Industry Standards. However, there are situations where a specific dataset information typeneeds to be derived from another existing one in order to specialize further the information intoanother dataset type or form.
This consideration becomes a grey area where the off-line tools’ capability and the run-time
simulation clients’ performance levels enforces this data derivation.
It is such a case with the Mip-Map data, Min-Max Elevation datat, Tile Presence data, RCS data,
and Raster Material data for example.

SourceDatasetData Manipulation
Description

Resulting Dataset(s)Elevation
DatasetIn order to produce the various Level Of Details Elevation LODs
within the Elevation Dataset, it is often necessary toover-sample or sub-sample a primary set of data
values. Since those values within the LOD hierarchy
may come from a single data source, the LODs can beseen as derived information which can betteraccommodate the client needs based on theirperformance level.

Elevation
DatasetFor clients that need to compute line of sights (LOS) Min-Max Elevation
between simulation entities spread across a vast terrainarea, it is imperative to have a fast way of knowing theminimum and maximum elevations within a tile
without loading the entire elevation data grid. The
min/max elevation dataset can be used to ensure a fast
pre-determination of entities occultation state with theterrain. The min/max data is stored in the form of aquad-tree pyramid and is based on the area covered at
the given depth level of the quad-tree. For example,
for the maximum dataset the top will contain the
maximum for the whole of the geocell, the next
pyramid level contains maximum data for each thequarter geocells and so on. Similarly for the minimum
the top represents the minimum for the whole of the© 2015 Open Geospatial Consortium.

699

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

Resulting Dataset(s)geocell going down as for maximums. Currently the
pyramid size is fixed and goes down to level 9 which
covers areas that are approximately 256x256 meterssquare; note that the depth level can be modified to afiner or coarser level but level 9 is suggested as areasonable compromise of performance vs. storage. A
tool will pre-determine the minimum and maximum
elevations within a geocell’s elevations and generate
the quad-trees described previously; note that the tool
will use all of the elevation data that is present in theelevation dataset to determine the maximums or
minimums in a given area. The tool will provide MinMax values to client devices through the Min-Max
Elevation datasets in the CDB.
VectorDatasets(Point, Linealand Areal
Features)

The Max Culture Height data is produced for clients Max Culture Heightthat need to compute line of sights (LOS) between
simulation entities spread across a vast terrain areathat take into account the maximum cultural featureheights. The dataset helps rapidly assess anintersection status of line-of-sight with culturalfeatures. This dataset is derived from the Vector
Datasets of the CDB for corresponding tiles. The
storage is done via a quad-tree similar to that of themin/max elevation the top of the pyramid represents
the height of the highest cultural feature in the dataset
going down to a suggested depth level of 9.

3D Model(GT, GS, MM)
Datasets

The polar diagram data (covering all aspect angles) of RCS (Radar Cross
the RCS dataset for Geotypical, Geospecific or Section)
Moving Models cannot readily be computed at runtime due to the complex mathematical computing
algorithms and resources required to determine theElectro-Magnetic Energy absorption levels by themodel’s materials, the corner reflections, the multipath reflections, EM parameters (frequency,
polarization) effects, and so on. Therefore, off-line
COTS tools are used to analyze the 3D model
geometry and its materials in order to produce the
RCS dataset specifically for different frequencies andpolarizations.

© 2015 Open Geospatial Consortium.

700

Open Geospatial Consortium – Common DataBase Specification
Version 1.0
Industry Version 3.2 published 19 March 2014
SourceDatasetVectorDatasets(Point, Linealand Areal
Features)

Data Manipulation
Description

Resulting Dataset(s)Since the material attribution is normally done in the Raster Material
vector data, a rasterization operation among all
features is required to come up with a raster grid of
attributed materials.

© 2015 Open Geospatial Consortium.

701

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

Appendix S
S. Default Read and Write values to be used by Simulator Client-Devices
As seen throughout this document, the CDB Specification provides guidelines withrespect to default values in cases where no data could be read from the CDB for
requested datasets. Those default parameters are captured in a Metadata file within
the CDB. The Table below summarizes all the Default Parameters Names and thesuggested initial values to be used by client-devices. In cases where the default
parameter would be missing altogether from \CDB\Metadata\Defaults.xml, ClientDevices shall use the “Default Value” found in the fourth column. A “Read” default
refers to the value being assumed while reading the CDB data. A “Write” default
refers to the value being written to the file when content-generation tools have partial
source data.
Parameter Name

DatasetType

Default ValueR/
W

Default_Elevation-1

001_Elevation

float

0m

R

Default_Elevation-[2-99]

001_Elevation

float

0m

R

Default_Primary_Elevation_Control

001_Elevation

integer

INSIDE (1)R

Default_Subordinate_Elevation_Control

001_Elevation

integer

NO_ELEVATION (0)R

Default_Bathymetry

001_Elevation

float

0m

R

Default_Tide

001_Elevation

float

2.5 m

R

Default_MinElevation_CaseI

002_MinMaxElevation

float

Default_Elevation-1

R

Default_MaxElevation_CaseI

002_MinMaxElevation

float

Default_Elevation-1

R

Default_MinElevation_CaseII

002_MinMaxElevation

float-400 mR

Default_MaxElevation_CaseII

002_MinMaxElevation

float

8846 mR

Default_MinElevation_CaseIII

002_MinMaxElevation

float

8846 mW

Default_MaxElevation_CaseIII

002_MinMaxElevation

float-400 mW

Default_MaxCulture_CaseI

003_MaxCulture

float

600 m

R

Default_MaxCulture_CaseII

003_MaxCulture

float

0m

R

Default_VSTI_Y_Mono

004_Imagery

float

0.5

R

© 2015 Open Geospatial Consortium

703

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

Parameter Name

DatasetType

Default ValueR/
W

Default_VSTI_Y_Red

004_Imagery

float

0.5

R

Default_VSTI_Y_Green

004_Imagery

float

0.5

R

Default_VSTI_Y_Blue

004_Imagery

float

0.5

R

Default_VSTLM_Mono

004_Imagery

float

0.0

R

Default_VSTLM_Red

004_Imagery

float

0.0

R

Default_VSTLM_Green

004_Imagery

float

0.0

R

Default_VSTLM_Blue

004_Imagery

float

0.0

R

Default_Imagery_Gamma

004_Imagery

float

1.0

R

Default_RoadNetwork_LTN

201_RoadNetwork

integer

2

R

Default_RailRoadNetwork_LTN

202_RailRoadNetwork

integer

1

R

Default_GSModelTexture_Gamma

301_GSModelTexture

float

1.0

R

Default_GSModelInteriorTexture_Gamma

306_GSModelInteriorTexture

float

1.0

R

Default_GTModelTexture_Gamma

511_GTModelTexture

float

1.0

R

Default_GTModelInteriorTexture_Gamma507_GTModelInteriorTextur
e

float

1.0

R

Default_MModelTexture_Gamma

601_MModelTexture

float

1.0

R

Default_Base_Material

string

BM_LAND-MOOR

R

Default_Material_Layer

integer

0

R

Default_AO1

float

0.0

R

Default_SCAL[x,y,z]

float

1.0

R

Default_TRF

integer4

R© 2015 Open Geospatial Consortium

704

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

Appendix T
T. JEPG 2000 File Format Syntax
The following pages are an extract from the JPEG 2000 Standard Annex I which
describes the JP2 File Format Syntax.

© 2015 Open Geospatial Consortium

705

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

© 2015 Open Geospatial Consortium

706

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

© 2015 Open Geospatial Consortium

707

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

© 2015 Open Geospatial Consortium

708

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

© 2015 Open Geospatial Consortium

709

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

© 2015 Open Geospatial Consortium

710

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

© 2015 Open Geospatial Consortium

711

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

© 2015 Open Geospatial Consortium

712

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

© 2015 Open Geospatial Consortium

713

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

© 2015 Open Geospatial Consortium

714

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

© 2015 Open Geospatial Consortium

715

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

© 2015 Open Geospatial Consortium

716

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

© 2015 Open Geospatial Consortium

717

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

© 2015 Open Geospatial Consortium

718

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

© 2015 Open Geospatial Consortium

719

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

© 2015 Open Geospatial Consortium

720

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

© 2015 Open Geospatial Consortium

721

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

© 2015 Open Geospatial Consortium

722

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

© 2015 Open Geospatial Consortium

723

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

© 2015 Open Geospatial Consortium

724

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

© 2015 Open Geospatial Consortium

725

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

© 2015 Open Geospatial Consortium

726

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

© 2015 Open Geospatial Consortium

727

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

© 2015 Open Geospatial Consortium

728

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

© 2015 Open Geospatial Consortium

729

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

Appendix U
U. ZIP File Format Specification
The archive zip format used in CDB Spec 3.0 is based on
APPNOTE.TXT - .ZIP File Format Specification
URL: http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.1.TXT
Version: 6.3.1
Revised: April 11, 2007
Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved.
The use of certain technological aspects disclosed in thecurrentAPPNOTE is available pursuant to the below section
entitled "Incorporating PKWARE Proprietary Technology into Your
Product".

CDB zip compliant reader is required to support as a minimum the following features
defined in APPNOTE.TXT:
Local file header (Note: Extra field can be inserted but not required to be read)
File data
Data descriptor:
Central directory structure (Note: Digital signature is supported but will not beread)
End of central directory record: (Note: ZIP file comments are supported but
will not be read)
The compression methods supported:
No compression
Deflate (Enhanced Deflate is not required to be supported)
The following features are not required to be supported thus are optional and left tothe implementation
Archive decryption header:Archive extra data record.
Zip64 end of central directory record
Zip64 end of central directory locator
Splitting and Spanning ZIP files
Encryptions of any type
Note that anything not listed in this section is by default assumed not to be supported.

© 2015 Open Geospatial Consortium

731

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

© 2015 Open Geospatial Consortium732