Open Geospatial Consortium
Submission Date: 2016-04-04
Approval Date: 2016-09-23
Publication Date: 2017-02-23
External identifier for OGC® document: http://www.opengis.net/doc/BP/CDB-core-annexes/1.0
Internal reference number of this OGC® document:

16-005r2

Version: 1.0
Category: OGC® Best Practice
Editor: Carl Reed

Volume 2: OGC CDB Core: Model and Physical
Structure: Informative Annexes
Copyright notice
Copyright © 2017 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 related to an OGC
standard. 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 membershipon this particular technology topic.
Document type:
Document subtype:
Document stage:
Document language:

OGC® Best PracticeVolume 2
Approved
English1

Copyright © 2016 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.

2

Copyright © 2016 Open Geospatial Consortium

Contents
1.

Scope ........................................................................................................................... 52.

Conformance ............................................................................................................... 7

3.

References ................................................................................................................... 7

4.

Terms and Definitions ................................................................................................. 7

5.

Conventions ................................................................................................................. 7
5.1

Identifiers ............................................................................................................. 86.

Annex A: Conformance Class Abstract Test Suite (Normative) ................................. 97.

Annex B Rationale: Sensor Simulation - Achieving Device-Independence ............. 10

8.

Annex C: Reasons for Using Jpeg ............................................................................. 12

9.

Annex F Rationale: Partitioning the Earth into Tiles ................................................ 14

10.

Annex G Rationale: Importance of Level of Detail ............................................... 18

11.

Annex H Informative: JPEG .................................................................................. 20

12.

Annex I Informative: ZipFile Format Notes .......................................................... 22

13.

Annex J: Light Names and Hierarchy .................................................................... 24

14.

Annex M: CDB Directory Naming and Structure ................................................. 36

15.

Annex O: List of Texture Component Selectors.................................................... 37

16.

Annex Q: Table of Dataset Codes ......................................................................... 45

17.

Annex R: Derived Datasets within the CDB ......................................................... 48

18.

Annex S: Default Read and Write values for Simulator Client-Devices ............... 51

3

Copyright © 2016 Open Geospatial Consortiumi.

Abstract
This document provides the Annexes for the CDB Core: Model and Physical Structure
standard. The only exception is Annex A, Abstract Test Suite. The CDB ATS Annex is in
Volume 1: Core document.

ii.

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

Preface
Attention is drawn to the possibility that some of the elements of this document may be
the subject of patent rights. The Open Geospatial Consortium shall not be held
responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of
any relevant patent claims or other intellectual property rights of which they may beaware that might be infringed by any implementation of the standard set forth in thisdocument, and to provide supporting documentation.

iv.

Submitting organizations
The following organizations submitted this Document to the Open Geospatial
Consortium (OGC):CAE Inc.
Carl Reed, OGC Individual Member
Envitia, Ltd
Glen Johnson, OGC Individual Member
KaDSci, LLC
Laval University
Open Site Plan
University of Calgary
UK Met Office4

Copyright © 2016 Open Geospatial Consortium

The OGC CDB standard is based on and derived from an industry developed andmaintained specification, which has been approved and published as OGC Document 15003: OGC Common DataBase Volume 1 Main Body. An extensive listing ofcontributors to the legacy industry-led CDB specification is at Chapter 11, pp 475-476 inthat OGC Best Practices Document(https://portal.opengeospatial.org/files/?artifact_id=61935) .

v.

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

Name

1.

Affiliation

Carl Reed

Carl Reed & Associates

David Graham

CAE Inc.

Scope

This document contains a number of annexes related to the OGC CDB Core standard.
For the purposes of being able to cross reference this OGC Best Practice with theprevious versions of the CDB standard, the following annex “crosswalk” is provided.

OGC Best Practice and CDB 3.2

OGC CDB Standard Version 1.0

Formerly Annex A10 in Volume 2

Annex B Rationale: Sensor Simulation Achieving Device-Independence

Main Body: Rationale for using JPEG Annex C Reasons for Using JPEG
Formerly Annex B in Volume 2

Annex D: TIFF Implementation Requirements
5

Copyright © 2016 Open Geospatial ConsortiumFormerly Annex D in Volume 2

Annex E: ShapeFile dBASE III Guidance

Formerly Annex A.11 in Volume 2

Annex F: Annex F Rationale: Partitioning the
Earth into Tiles

Formerly Annex A.12

Annex G Rationale: Importance of Level of
DetailFormerly Annex A.17 Volume 2
Was Annex U, Volume 2
Formerly Annex E, Volume 2

Annex H: JPEG Informative annex
Annex I ZIP File Informative annex
Annex J: Light Hierarchy

Formerly Annex M, Volume 2

Annex M: CDB Directory Naming and Structure

Formerly Annex O, Volume 2

Annex O: List of Texture Component Selectors

Formerly Annex Q, Volume 2

Annex Q: Table of Dataset Codes

Formerly Annex R, Volume 2

Annex R: Derived Datasets within the CDB

Formerly Annex S, Volume 2

Annex S: Default Read and Write values to be
used by Simulator Client-Devices

For ease of editing and review, the standard has been separated into 12 Volumes and aschema repository.
● Volume 0: OGC CDB Companion Primer for the CDB standard. (Best Practice)● Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure.
The main body (core) of the CBD standard (Normative).
• Volume 2: OGC CDB Core Model and Physical Structure Annexes (BestPractice).
● Volume 3: OGC CDB Terms and Definitions (Normative).
● Volume 4: OGC CDB Use of Shapefiles for Vector Data Storage (Best Practice).
● Volume 5: OGC CDB Radar Cross Section (RCS) Models (Best Practice).
● Volume 6: OGC CDB Rules for Encoding Data using OpenFlight (Best Practice).
6

Copyright © 2016 Open Geospatial Consortium

● Volume 7: OGC CDB Data Model Guidance (Best Practice).
● Volume 8: OGC CDB Spatial Reference System Guidance (Best Practice).
● Volume 9: OGC CDB Schema Package: provides the normative schemas for key
features types required in the synthetic modelling environment. Essentially, theseschemas are designed to enable semantic interoperability within the simulation
context. (Normative)● Volume 10: OGC CDB Implementation Guidance (Best Practice).
● Volume 11: OGC CDB Core Standard Conceptual Model (Normative)● Volume 12: OGC CDB Navaids Attribution and Navaids Attribution
Enumeration Values (Best Practice)2.

ConformanceThis section is not applicable to this document.

3.

References

The following normative documents contain provisions that, through reference in thistext, constitute provisions of this document. For dated references, subsequent
amendments to, or revisions of, any of these publications do not apply. For undated
references, the latest edition of the normative document referred to applies.

4.

Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which isbased on the ISO/IEC Directives, Part 2, Rules for the structure and drafting ofInternational Standards. In particular, the word “shall” (not “must”) is the verb form used
to indicate a requirement to be strictly followed to conform to this Best Practice.
Other Terms and Definitions may be found in Volume 3: OGC CDB Terms andDefinitions (normative) of Best Practice.

5.

Conventions

This sections provides details and examples for any conventions used in the document.
Examples of conventions are symbols, abbreviations, use of XML schema, or special
notes regarding how to read the document.
7

Copyright © 2016 Open Geospatial Consortium

5.1
Identifiers
The normative provisions in this Best Practice are denoted by the URI
http://www.opengis.net/spec/CDB/1.0/annexes
All requirements and conformance tests that appear in this document are denoted bypartial URIs which are relative to this base.

8

Copyright © 2016 Open Geospatial Consortium

6.

Annex A: Conformance Class Abstract Test Suite (Normative)

Not applicable for this document.

9

Copyright © 2016 Open Geospatial Consortium

7.

Annex B Rationale: Sensor Simulation - Achieving Device-

Independence
Formerly Annex A10 in Volume 2
One of the primary objectives of the CDB Standard is to provide and integrate all of thedata required by all sensor devices, not just Image Generators producing the Out theWindow (OTW) scenes. The purpose of this integration, among other things, is toachieve and maintain a high level of correlation among the many client-devices(subsystems) within a simulator.
Furthermore, this integration 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 tosimulate 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
to now, the current state of the art approaches to the simulation of sensors has typically
been quite proprietary to the client-device implementation of the various vendors. There
have been no universally 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 databases whose
content was designed to match the functionality, fidelity, structure and format
requirements of the SEM. The level of realism possible by the SEM depended heavily
on the quality, quantity and completeness of the data 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 fromthe CDB; however, the key is to segregate all device-dependent data and all SEMdependent data from the modeling data that represents the synthetic environment. In
order to accommodate the most different kind of sensors possible, a common
denominator must be chosen. In the CDB standard, this common denominator is called amaterial. This is the subject of this annex.
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:
10

Copyright © 2016 Open Geospatial Consortium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 aresult, the CDB Standard limits its jurisdiction over the material properties.
Instead, the CDB standard defines and publicly defines a list of materials that can be used
in a CDB. It is the responsibility of each vendor to define the properties (that satisfies thesensor type) for these CDB materials. As a result, vendors are totally free to selectmaterial properties that satisfy the fidelity, functionality and precision requirements of the
SEM for the sensor type of 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 aswell as their own sets of material properties.
The materials.xsd and materials.xml schema in the CDB schema package enumerates thebase materials supported by this standard.

11

Copyright © 2016 Open Geospatial Consortium

8.

Annex C: Reasons for Using Jpeg

(Formerly from body of Best Practice Volume 1)
The CDB Standard prescribes the use of an industry standard compression algorithm forits storage intensive raster imagery datasets. This not only provides a substantial
reduction in storage, but also reduces the data transmission bandwidths associated withsimulator’s access to the synthetic environment database at runtime. As a result of its
storage efficiency, the CDB Standard relies on relatively few data formats for storing its
datasets. There is no benefit (other than storage efficiency) to be gained in supporting anyother specialized data formats whose underlying objective is only for storage efficiency.
The CDB Standard embodies the JPEG 2000 industry standard format for raster imagery
because it has comparable storage efficiency to all of these image formats without
sacrificing any generality. JPEG 2000 has been chosen by the CDB Standard as a format
for the storage of OTW raster imagery because of the following characteristics:
1.
High compression efficiency: Compression better than 0.25 bits per pixels.
Virtually indiscernible loss in image quality for 10:1 – 20:1 compression.
2.

Lossless and lossy compression: Lossless compression ratios approx. 1.7:1

3.
Perceptual color space internal coding: Allow dark images to be reconstructedwithout banding artifacts.
4.
High dynamic range: Compress and decompress images with various dynamic
ranges (e.g., 1-bit to 16-bit) for each color component.
5.

Large images sizes: Up to (2^32 - 1)

There are other characteristics of the JPEG 2000 that are worth mentioning but are notdirectly beneficial to the CDB Specification. Those are:1.
Progressive image reconstruction: Allow images to be reconstructed withincreasing pixel accuracy and resolution.
2.
Region of interest coding: Permits certain Region of Interest (ROI’s) in the image
to be coded and transmitted with better quality and less distortion than the rest of theimage.

12

Copyright © 2016 Open Geospatial Consortium

3.
Seamless quality and resolution scalability: Without having to download theentire file4.

Error resilience during transfers.

JPEG 2000 will be solely targeted at Raster Imagery data only. The reason is simply
because of its highly efficient compression scheme that fits well with the goal of reducing
the huge datasets associated with Imagery. Other raster-based datasets defined in the
CDB will solely be using the TIFF format due to their more manageable size.

13

Copyright © 2016 Open Geospatial Consortium

9.

Annex F Rationale: Partitioning the Earth into Tiles

Formerly Appendix A11 in Volume 2 of the CDB Best Practice.
This section provides rationale for partitioning the world into tiles.
The design of the CDB standard 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
lat-long coordinates into CDB coordinates and vice versa is highly
desirable for real-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
the need 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 geo-cell, which always has a height and width of one degree.
In order to maintain a density of data that does not increase inordinately
when moving towards the poles, the grid post intervals (measured indegrees or arc-sec) along the longitudinal axis are increased at specificlatitudes; for instance, at DTED level 2, the latitude interval is always one
second of arc but the longitude interval 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 DTEDLEVEL 2.

14

Copyright © 2016 Open Geospatial ConsortiumTable A-3. INTERVALS FOR DTED LEVEL 2
DTED
Zone

Latitude Range(Degrees)

Latitude Interval(Arc seconds)

Longitude Interval(Arc seconds)

I
II
III
IV
V

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

1
1
1
1
1

1
2
3
4
6

Before going into the detailed design of the CDB tile representation, it is worth stating
the guiding 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 isthe same 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 oflatitude.

(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 of increased latitudes on longitudinal distances. The definition ofzones in the CDB is the same as those in DTED (with the exception of thepoles).

(6)

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

(7)

The number of units along the slice’s y-axis is constrained to a 2n-multiple
in all slices.
Many simulator client devices impose constraints related to the run-time
use of binary pyramidal structures (such as mip-maps, quadtrees, etc.). A
binary pyramidal structure is simply a collection of two-dimensional
15

Copyright © 2016 Open Geospatial Consortiumarrays; each array represents the same content but at successively finerlevels of resolution.
(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 theconcept of a CDB Geocell, which differs slightly from a DTED Geocell.
A DTED cell is 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. Size of CDB Geocell per zone shows the dimensions of a
CDB Geocell per zones of latitude. For instance, in latitude zone 5, whichgoes from –50 to 50 degrees latitude, a CDB Geocell is 1 × 1 degree, inzone 4 and 6 which goes from latitude 50 to 70 degrees the cell size is 1 ×
2 degrees. The main reason to introduce this concept is to maintain areasonable eccentricity between the sides by trying to keep them as close
to a square as possible. Two criteria are used to define the size of a CDB
Geocell:(a)

A CDB Geocell must contain a whole number of DTED Geocells;
in other words a CDB Geocell must start and end on a whole
degree along the longitudinal axis. This is done so as to facilitate
mapping from CDB Geocells to DTED Geocells.

(b)

The length of the CDB Geocell must be a whole factor of 180, in
other words 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
Zone

Latitude Range(Degrees)

CDBGeocell size
(deg Lat × deg Lon))

Number of DTED
Geocells

0–90 ≤ lat < –89

1 X 1212

1–89 ≤ lat < –80

1X6

6

2

–80 ≤ lat < –75

1X4

4

3

–75 ≤ lat < –70

1X3

3

4

–70 ≤ lat < –50

1X2

2

5

–50 ≤ lat < +50

1X1

1

6

+50 ≤ lat < +70

1x2

2

7

+70 ≤ lat < +75

1x3

3

8

+75 ≤ lat < +80

1x4

4

16

Copyright © 2016 Open Geospatial Consortium9+80 ≤ lat < +89

1x6

6

10

+89 ≤ lat < +90

1 x 12

12

The variable CDB Geocell size in the CDB standard has the following benefits:
1. Reduces the simulator client processing overheads associated with the switchingfrom one zone to another. (Due to the small number of zones across the earth.)
2. Reduces the variation of longitudinal dimensions (in meters) to a maximum of
50%.
3. Improves storage efficiency.

17

Copyright © 2016 Open Geospatial Consortium

10.

Annex G Rationale: Importance of Level of Detail

Formerly Appendix A-12 of Volume 2 of the OGC CDB Best Practice.
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 manyclients naturally require less detail with increasing distance away from the simulated own
ship 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 an alternate coarser representation if they cannot
cope with the paging bandwidths, memory footprint or computational requirements offiner LODs. This provides a solid basis on which client-devices can build paging
managers, load management and memory management algorithms.
The following example illustrates the important performance considerations and theinherent performance advantage that can be achieved with an LOD structure. Consider asimulator client-device, with a capability to display terrain imagery out to 128 km; theimagery is 1m at its finest available resolution and the simulated ownship is flying at 100
m/s. Under these conditions, and without the benefit of an LOD organization (asillustrated in Figure A-15: Paging of Terrain Imagery without an LOD Structure), theclient-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 the client-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 1m imagery for ranges less than 1/2 km, 2m for ranges less than 1km, 4m forranges less than 2km, and so on. With the benefit of an LOD structure, the client-device
would require access to the imagery 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
client-devices that have a requirement to dynamically filter the data to control aliasing.
In effect, part of the client-device filtering process is relegated to an off-line process.
The CDB standard does not enforce, nor does it specify the type of filter used to computethe data element values of raster-organized or list-organized datasets. Yet, it is clear that
inadequate off-line filter may affect the rendering quality of the affected client-devices.
As a result, the CDB standard provides guidelines to govern the quality of the off-line
18

Copyright © 2016 Open Geospatial Consortium

LOD process; these guidelines are provided with each of the raster-organized dataset (orlist-organized datasets in future releases of the CDB standard).

Figure A-14: Paging of Terrain Imagery with an LOD Structure

19

Copyright © 2016 Open Geospatial ConsortiumFigure A-15: Paging of Terrain Imagery without an LOD Structure11.

Annex H Informative: JPEG

Formerly Appendix A.17 in Volume 2 of the OGC CDB Best Practice
The CDB standard 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 and transmission bandwidths. JPEG-2000 achieves these goals and many others,
refer to Table A-8 JPEG 2000 Features.
Table A-8 JPEG 2000 Features

20

Copyright © 2016 Open Geospatial Consortium

High compression efficiency:
High dynamic range:
Compression better than 0.25 bits per pixels,
Compress images with various
20% compression efficiency improvement over dynamic ranges (e.g. 1-16 bit) for each
JPEG.
color component.
Lossless and lossy compression:
Seamless quality / resolution
scalability:
Lossless compression ratios approx. 1.7:1.
Without having to download the entire
file.
Progressive image reconstruction:
Large images sizes - up to (232 - 1).
Allows images to be reconstructed withincreasing 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
and transmitted with better quality and lessdistortion than the rest of the image.

21

Copyright © 2016 Open Geospatial Consortium

12.

Annex I Informative: ZipFile Format Notes

Formerly Annex U in Volume 2 of the OGC CDB Best Practice
The archive zip format used in the CDB standard 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 to theimplementation
•
•
•
•
•

Archive decryption header:Archive extra data record.
Zip64 end of central directory record
Zip64 end of central directory locator
Splitting and Spanning ZIP files
22

Copyright © 2016 Open Geospatial Consortium•

Encryptions of any type

Note that anything not listed in this section is by default assumed not to be supported.

23

Copyright © 2016 Open Geospatial Consortium

13.

Annex J: Light Names and Hierarchy

24

Copyright © 2016 Open Geospatial Consortium

25

Copyright © 2016 Open Geospatial Consortium

26

Copyright © 2016 Open Geospatial Consortium

27

Copyright © 2016 Open Geospatial Consortium

28

Copyright © 2016 Open Geospatial Consortium

29

Copyright © 2016 Open Geospatial Consortium

30

Copyright © 2016 Open Geospatial Consortium

31

Copyright © 2016 Open Geospatial Consortium

32

Copyright © 2016 Open Geospatial Consortium

33

Copyright © 2016 Open Geospatial Consortium

34

Copyright © 2016 Open Geospatial Consortium

35

Copyright © 2016 Open Geospatial Consortium

14.

Annex M: CDB Directory Naming and Structure

Formerly Appendix M, Volume 2 of the OGC CDB Best PracticeIn previous versions of the CDB specification, Appendix M was used to present thecomplete list of names 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 filesdelivered with the CDB 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, Volume 1: Core.
The following files are necessary to expand the patterns:•••/CDB/Metadata/Feature_Data_Dictionary.xml provides the list of directory names
associated with feature codes.
/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 CDB standard.

36

Copyright © 2016 Open Geospatial Consortium

15.

Annex O: List of Texture Component Selectors

Formerly Appendix O, Volume 2 of the OGC CDB Best Practice
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)
001
002
003
004
005
006
007
008
009
010
011
012
001
002
003
004
001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019

Description
January
February
March
April
May
June
July
AugustSeptember
OctoberNovember
DecemberSpringSummerAutumnWinter
Grey
White
Green
Black
Beige
Blue
Red
Yellow
Brown
Pink
PurpleBurgundy
OrangeLight Blue
Khaki
Dark Grey
Amber
Gold
Silver37

Copyright © 2016 Open Geospatial ConsortiumTexture Kind
CS1 (Sxxx)
005 – Camouflage
Paint Scheme

006 – Airline Paint
SchemeTexture Index
CS2 (Txxx)
020
001
002
003
004
005
001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041

Description
CopperDesertWinterForestGeneric
Urban
AAH Aloha Airlines Inc.
AAL American Airlines Inc.
AAR Asiana Airlines Inc.
AAW Afriqiyah Airways
ABR Air Contractors (UK) Limited
ACA Air Canada
ACI Air Caledonie International
ADR Adria Airways - The Airline of Slovenia
AEA Air Europa Lineas Aereas, S.A.
AEE Aegean Airlines S.A.
AEW Aerosvit Airlines
AFG Ariana Afghan Airlines
AFL Aeroflot Russian Airlines
AFR Air France
AGN Air Gabon
AHY Azerbaijan Hava Yollary
AIC Air-India Limited
AIZ Arkia - Israeli Airlines Ltd
AJM Air Jamaica
ALK SriLankan Airlines Limited
AMC Air Malta p.l.c.
AML Air Malawi Limited
AMU Air Macau Company Limited
AMX Aeromexico
ANA All Nippon Airways Co. Ltd.
ANG Air Niugini Pty Limited
ANS Air Nostrum L.A.M.S.A.
ANZ Air New Zealand Limited
ARG Aerolineas Argentinas
ASA Alaska Airlines Inc.
ATC Air Tanzania Company Ltd.
AUA Austrian Airlines, Osterreichische
AUI Ukraine International Airlines
AUT Cielos del Sur S.A.
AVA Aerovias del Continente Americano – Avianca
AVN Air Vanuatu (Operations) Limited
AWE America West Airlines Inc.
AZA Alitalia - Linee Aeree Italiane
AZW Air Zimbabwe (Pvt) Ltd.
BAG dba Luftfahrtgesellschaft mbH
BAW British Airways p.l.c.

38

Copyright © 2016 Open Geospatial ConsortiumTexture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088

Description
BBC Biman Bangladesh AirlinesBCS European Air Transport
BCY Cityjet
BEE Jersey European Airways Limited
BER Air Berlin GmbH & Co. Luftverkehrs KG
BKP Bangkok Airways Co. Ltd.
BLF Blue1 Oy
BLV Bellview Airlines Ltd.
BMA British Midland Airways Ltd.
BOT Air Botswana Corporation
BPA Blue Panorama Airlines S.p.A.
BRA SAS Braathens AS
BRU Belavia
BRZ Samara Airlines
BWA BWIA West Indies Airways Limited
CAL China Airlines
CAW Comair Ltd.
CCA Air China Limited
CDG Shandong Airlines
CES China Eastern Airlines
CHH Hainan Airlines Company Limited
CLH Lufthansa CityLine GmbH
CLX Cargolux Airlines International S.A.
CMI Continental Micronesia, Inc.
CMP Compania Panamena de Aviacion, S.A.
CNW China Northwest Airlines
COA Continental Airlines, Inc.
CPA Cathay Pacific Airways Ltd.
CPN Caspian Airlines Service Company Ltd.
CRL CORSAIRCSA Czech Airlines a.s., CSA
CSN China Southern Airlines
CTN Croatia Airlines
CUB Cubana de Aviacion S.A.
CXA Xiamen Airlines
CYH China Yunnan Airlines
CYP Cyprus Airways Limited
DAH Air Algerie
DAL Delta Air Lines Inc.
DAN Maersk Air A.S.
DAT Delta Air Transport N.V.
DHK DHL Air Limited
DHX DHL International E.C.
DLH Deutsche Lufthansa AG
DNM Denim Air
DTA TAAG - Linhas Aereas de Angola
EIN Aer Lingus Limited

39

Copyright © 2016 Open Geospatial ConsortiumTexture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)
089
090
091
092
093
094
095
096
097
098
099
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135

Description
ELG ALPI Eagles S.p.A.
ELL Estonian Air
ELY El Al Israel Airlines Ltd.
ETD Etihad Airways
ETH Ethiopian Airlines Enterprise
EVA EVA Airways Corporation
EWG Eurowings AG
FCN Falcon Air AB
FDX FedEx
FIN Finnair Oyj
FJI Air Pacific Ltd.
GBL GB Airways Ltd.
GEC Lufthansa Cargo AG
GFA Gulf Air Company G.S.C.
GHA Ghana Airways Corp.
GIA Garuda Indonesia
HCY Helios Airways
HDA Hong Kong Dragon Airlines Limited
HEJ Hellas Jet S.A.
HHN Hahn Air Lines
HLF Hapag Lloyd Fluggesellschaft
HZL Hazelton Airlines dba Regional Express
IAC Indian Airlines
IAW Iraqi Airways
IBB Binter Canarias
IBE Iberia - Lineas Aereas de Espana
ICE Icelandair
ICL C.A.L. Cargo Airlines Ltd.
IRA Iran Air
IRC Iran Aseman Airlines
IRM Mahan Airlines
ISR Israir Airlines and Tourism Ltd.
ISS Meridiana S.p.A.
IYE Yemenia - Yemen Airways
JAI Jet Airways (India) Limited
JAL Japan Airlines International Co., Ltd.
JAT Jat Airways
JAZ JALways Co. Ltd.
JKK Spanair S.A.
KAC Kuwait Airways
KAL Korean Air Lines Co. Ltd.
KHA Kitty Hawk Aircargo, Inc.
KLM KLM Royal Dutch Airlines
KOR Air Koryo
KQA Kenya Airways
KRP Carpatair S.A.
LAA Libyan Arab Airlines

40

Copyright © 2016 Open Geospatial ConsortiumTexture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182

Description
LAM LAM - Linhas Aereas de Mocambique
LAN Lan Airlines S.A.
LAP TAM - Transportes Aereos del
LBC Albanian Airlines MAK S.H.P.K.
LBH Laker Airways (Bahamas) Limited
LCO Lan Chile Cargo S.A.
LDA Lauda Air Luftfahrt AG
LDI Lauda Air S.p.A.
LGL Luxair
LIL Lithuanian Airlines
LLB Lloyd Aereo Boliviano S.A. (LAB)
LOT LOT - Polish Airlines
LPE Lan Peru S.A.
LRC Lineas Aereas Costarricenses S.A.
LTU LTU International Airways
LXR Air Luxor, S.A.
MAH Malev Hungarian Airlines Limited
MAK Macedonian Airlines
MAS Malaysia Airline System Berhad
MAU Air Mauritius
MAZ Zambian Airways
MDG Air Madagascar
MEA Middle East Airlines AirLiban
MGL MIAT - Mongolian Airlines
MGX Montenegro Airlines
MLD Air Moldova
MPX Aeromexpress S.A. de C.V.
MRS Air Marshall Islands, Inc.
MSR Egyptair
MXA Compania Mexicana de AviacionNBK Albarka Air Services Ltd.
NCA Nippon Cargo Airlines
NMB Air Namibia
NTW Nationwide Airlines (Pty) Ltd.
NWA Northwest Airlines, Inc.
OAL Olympic Airlines
OAS Oman Aviation Services Co. (SAOG)
PAL Philippine Airlines, Inc.
PAO Polynesian Limited
PGA Portugalia - Companhia Portuguesa de
PIA Pakistan International Airlines
PLK Pulkovo Aviation EnterprisePNW Palestinian Airlines
PUA Pluna Lineas Aereas Uruguayas S.A.
QFA Qantas Airways Ltd.
QTR Qatar Airways(Q.C.S.C)
RAM Royal Air Maroc

41

Copyright © 2016 Open Geospatial ConsortiumTexture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229

Description
RBA Royal Brunei Airlines Sdn. Bhd.
REU Air Austral
RJA Royal Jordanian
ROT TAROM - Transporturile Aeriene Romane
RSN Royal Swazi National Airways Corp.
RWD Rwandair Express
SAA South African Airways
SAS Scandinavian Airlines System (SAS)SAT SATA - Air Acores
SBI Siberia Airlines
SER Aero California
SEY Air Seychelles Limited
SFR Safair (Proprietary) Ltd.
SIA Singapore Airlines Limited
SKX Skyways AB
SLA Sierra National Airlines
SLK SilkAir (S) Pte. Ltd.
SLM Surinam Airways Ltd.
SNG Air Senegal International
SOL Solomon Airlines
SQC Singapore Airlines Cargo Pte. Ltd.
SUD Sudan Airways Co. Ltd.
SVA Saudi Arabian Airlines
SWD Southern Winds S.A.
SWR SWISS International Air Lines Ltd
SYR Syrian Arab Airlines
TAI Taca International Airlines, S.A.
TAM TAM Linhas Aereas S.A.
TAP TAP - Air Portugal
TAR Tunisair
TAY TNT Airways S.A.
THA Thai Airways International Public
THT Air Tahiti Nui
THY Turkish Airlines Inc.
TMA Trans-Mediterranean Airways
TNA TransAsia Airways Corporation
TSO Transaero Airlines
TUA Turkmenistan Airlines
UAE Emirates
UAL United Airlines, Inc.
UPS UPSUSA US Airways, Inc.
UYC Cameroon Airlines
VAP Phuket Airlines Co., Ltd.
VDA Volga-Dnepr Airline Joint Stock
VIR Virgin Atlantic Airways Limited
VLE Volare Airlines S.p.A.

42

Copyright © 2016 Open Geospatial ConsortiumTexture Kind
CS1 (Sxxx)

Texture Index
CS2 (Txxx)
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276

Description
VLK Vladivostok Air JSC
VRG Varig S.A.
VSP Viacao Aerea Sao Paulo, S.A. (VASP)VTA Air Tahiti
WIF Wideroe's Flyveselskap A.S.
WNT Cargojet Airways Ltd.
CRX Crossair
WJA WestJet Airlines Ltd.
JAS Japan Air System
NWW North West Airlines
MEP Midwest Express Airlines
TWA Trans World Airlines
SAB Sabena
TUI Tuninter
SRT Trans Asian AirlinesJBU JetBlue Airways
TSC Air Transat
SWG Sunwing Airlines
FFM Firefly
BVT Berjaya Air
VLG Vueling Airlines
SKY Skymark Airlines
JST Jetstar Airways
ABX ABX Air
CQH Spring Airlines
POE Porter Airlines
EAQ Eastern Australia
EZY EasyJet
NLY Niki
VOZ Virgin Australia
KNA Kunming Airlines
CSC Sichuan Airlines
VRD Virgin America
DKH Juneyao Airlines
KEN Kenmore Air
XAK Air Kenya
NZM Mount Cook Airline
FDA Fuji Dream Airlines
TAE TAME (Línea Aérea del Ecuador)
CFE BA CityFlyer
JZA Jazz Aviation
CSH Shanghai Airlines
BEE Flybe
TYR Tyrolean Airways
SWA Southwest Airlines
XME Australian Air Express
BEL Brussels Airlines

43

Copyright © 2016 Open Geospatial ConsortiumTexture Kind
CS1 (Sxxx)

009 – Quarter

054 – Contaminant

055 – Skid Mark

Texture Index
CS2 (Txxx)
277
278
279
280
281
282
283
284
285
286
001
002
003
004
001
002
003
004
005
006
007
008
009
010
011
001

Description
GCR Tianjin Airlines
VOI Volaris
ARA Arik Air
LNI Lion Air
RYR Ryanair
SHU Aurora
NIG Aero Contractors
SCW Malmö Aviation
NAX Norwegian Air Shuttle
RAR Air Rarotonga
First quarter of the year
Second quarter of the year
Third quarter of the year
Fourth quarter of the year
Wet Surface
Snowy Surface
Icy Surface
Slushy Surface
Patchy Wet Surface
Patchy Snowy Surface
Patchy Icy Surface
Patchy Sandy Surface
Patchy Dirty Surface
Volcanic Ash
Patchy Volcanic Ash
Tire Mark

Examples:•A geospecific City Hall especially decorated for the Halloween during
the month (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.

•

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) could be stored in a file named
D601_S005_T001_W10_M1A2.rgb.
44

Copyright © 2016 Open Geospatial Consortium•

An Airbus 380 model 800 operated by the Emirates (T221) Airlines(S006) could be stored in a file named D601_S006_T221_Wxx_A380800.rgb.

•

Texture Kind 002 and 009 are complete; the number of months andquarters will not change.

•

Texture Kind 004 will expand as new colors are added. Color names
are defined 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.

Notes:

16.

Annex Q: Table of Dataset Codes

Formerly Appendix Q in Volume 2 of the OGC CDB Best Practice.
The table below summarizes the CDB dataset codes along with their names and theirapplicability to the three active versions of the CDB standard.
DatasetName

Specification
Code 3.0
3.2
001
√
√
002
√
√
003
√
√
004
√
√
005
√
√
006
√
√
007
008
020
100
√
√
101
√
√

Elevation
MinMaxElevation
MaxCulture
Imagery
RMTexture
RMDescriptor
Reserved
Reserved
Reserved
GSFeature
GTFeature45

Copyright © 2016 Open Geospatial ConsortiumDataset
Name
GeoPolitical
VectorMaterial
RoadNetwork
RailRoadNetwork
PowerLineNetwork
HydrographyNetwork
GSModelGeometry
GSModelTexture
GSModelSignature
GSModelDescriptor
GSModelMaterial
GSModelInteriorGeometry
GSModelInteriorTexture
GSModelInteriorDescriptor
GSModelInteriorMaterial
GSModelCMT
T2DModelGeometry
NavData
Navigation
GTModelGeometry
GTModelTexture
GTModelSignature
GTModelDescriptor
GTModelMaterial
GTModelCMT
GTModelInteriorGeometry
GTModelInteriorTexture
GTModelInteriorDescriptor
GTModelInteriorMaterial
GTModelInteriorCMT
MModelGeometry
MModelTexture
MModelSignature
MModelDescriptor
MModelMaterial46

Copyright © 2016 Open Geospatial Consortium

Specification
Code 3.0
3.2
102
√
√
200
√
√
201
√
√
202
√
√
203
√
√
204
√
√
300
√
√
301
√
√
302
√
√
303
√
√
304
√
305
√
306
√
307
√
308
√
309
√
310
√
400
√
√
401
√
√
500
√
√
510
√
501
√
511
√
502
√
512
√
503
√
√
504
√
505
√
506
√
507
√
508
√
509
√
513
√
600
√
√
601
√
√
602
√
606
√
603
√
√
604
√

DatasetSpecification
Name
Code 3.0
3.2
MModelCMT
605√
Metadata
700√
ClientSpecific
701√
Reserved for CDB Extensions 9xx

Dataset Code is not used√

Dataset Code is in use
Dataset Code is deprecatedDataset Code is reserved

47

Copyright © 2016 Open Geospatial Consortium

17.

Annex 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 byusing Industry Standards. However, there are situations where a specific dataset
information type needs to be derived from another existing one in order to specialize
further the information into another dataset type or form.
This consideration becomes a grey area where the off-line tools’ capability and the runtime 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.

SourceDatasetElevation
DatasetElevation
DatasetData Manipulation
ResultingDescription
Dataset(s)In order to produce the various Level Of Details Elevation LODs
within the Elevation Dataset, it is often necessary
to over-sample or sub-sample a primary set ofdata values. Since those values within the LOD
hierarchy may come from a single data source,
the LODs can be seen as derived information
which can better accommodate the client needs
based on their performance level.
For clients that need to compute line of sights Min-Max Elevation(LOS) between simulation entities spread acrossa vast terrain area, it is imperative to have a fast
way of knowing the minimum 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 predetermination of entities occultation state withthe terrain. The min/max data is stored in theform of a quad-tree pyramid and is based on thearea covered at the given depth level of the quadtree. 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 the quarter geocells andso on. Similarly for the minimum the top
represents the minimum for the whole of the48

Copyright © 2016 Open Geospatial ConsortiumSource
DatasetVectorDatasets(Point, Linealand Areal
Features)

3D Model(GT, GS,
MM) Datasets

Data Manipulation
ResultingDescription
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 meters square; note that the depth levelcan be modified to a finer or coarser level but
level 9 is suggested as a reasonable compromiseof performance vs. storage. A tool will predetermine the minimum and maximum
elevations within a geocell’s elevations andgenerate the quad-trees described previously;note that the tool will use all of the elevation datathat is present in the elevation dataset todetermine the maximums or minimums in agiven area. The tool will provide Min-Max
values to client devices through the Min-Max
Elevation datasets in the CDB.
The Max Culture Height data is produced for Max Culture Heightclients that need to compute line of sights (LOS)
between simulation entities spread across a vast
terrain area that take into account the maximum
cultural feature heights. The dataset helps rapidly
assess an intersection status of line-of-sight with
cultural features. 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 the min/max elevation the top of the
pyramid represents the height of the highest
cultural feature in the dataset going down to asuggested depth level of 9.
The polar diagram data (covering all aspect RCS (Radar Cross
angles) of the RCS dataset for Geotypical, Section)
Geospecific or Moving Models cannot readily be
computed at run-time due to the complex
mathematicalcomputingalgorithms
andresources required to determine the ElectroMagnetic Energy absorption levels by themodel’s materials, the corner reflections, themulti-pathreflections,EMparameters(frequency, polarization) effects, and so on.
Therefore, off-line COTS tools are used to49

Copyright © 2016 Open Geospatial ConsortiumSource
DatasetVectorDatasets(Point, Linealand Areal
Features)

Data Manipulation
ResultingDescription
Dataset(s)analyze the 3D model geometry and its materials
in order to produce the RCS dataset specificallyfor different frequencies and polarizations.
Since the material attribution is normally done in Raster Material
the vector data, a rasterization operation among
all features is required to come up with a raster
grid of attributed materials.

50

Copyright © 2016 Open Geospatial Consortium

18.

Annex S: Default Read and Write values for Simulator Client-

Devices
As seen throughout this document, the CDB standard provides guidelines with respect todefault 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 the suggested initial values tobe used by client-devices. In cases where the default parameter would be missing
altogether from \CDB\Metadata\Defaults.xml, Client-Devices 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 thefile when content-generation tools have partial source data.
Parameter Name

DatasetType

Default ValueR/
W

Default_Elevation-1
Default_Elevation-[2-99]

001_Elevation
001_Elevation

0m
0m

R
R

Default_Primary_Elevation_Control

001_Elevation

float
float
integer
intege
r
float
float
float
float
float
float
float
float
float
float
float
float
float
float
float
float

INSIDE (1)R

Default_Subordinate_Elevation_Control
Default_Bathymetry
Default_Tide
Default_MinElevation_CaseI
Default_MaxElevation_CaseI
Default_MinElevation_CaseII
Default_MaxElevation_CaseII
Default_MinElevation_CaseIII
Default_MaxElevation_CaseIII
Default_MaxCulture_CaseI
Default_MaxCulture_CaseII
Default_VSTI_Y_Mono
Default_VSTI_Y_Red
Default_VSTI_Y_Green
Default_VSTI_Y_Blue
Default_VSTLM_Mono
Default_VSTLM_Red

001_Elevation
001_Elevation
001_Elevation
002_MinMaxElevation
002_MinMaxElevation
002_MinMaxElevation
002_MinMaxElevation
002_MinMaxElevation
002_MinMaxElevation
003_MaxCulture
003_MaxCulture
004_Imagery
004_Imagery
004_Imagery
004_Imagery
004_Imagery
004_Imagery

51

Copyright © 2016 Open Geospatial Consortium

NO_ELEVATION
(0)
0m
2.5 m
Default_Elevation-1
Default_Elevation-1-400 m8846 m8846 m-400 m
600 m
0m
0.5
0.5
0.5
0.5
0.0
0.0

R
R
R
R
R
R
R
W
W
R
R
R
R
R
R
R
R

Parameter Name

DatasetType

Default ValueR/
W

Default_VSTLM_Green
Default_VSTLM_Blue
Default_Imagery_Gamma

004_Imagery
004_Imagery
004_Imagery

0.0
0.0
1.0

R
R
R

Default_RoadNetwork_LTN

201_RoadNetwork

2

R

Default_RailRoadNetwork_LTN

202_RailRoadNetwork

1

R

Default_GSModelTexture_Gamma
Default_GSModelInteriorTexture_Ga
mma
Default_GTModelTexture_Gamma
Default_GTModelInteriorTexture_Ga
mma
Default_MModelTexture_Gamma
Default_Base_Material

301_GSModelTexture
306_GSModelInteriorText
ure
511_GTModelTexture
507_GTModelInteriorText
ure
601_MModelTexture

float
float
float
integer
intege
r
float

1.0

R

float

1.0

R

float

1.0

R

float

1.0

R

float
stringintege
r
float
float
integer

1.0
BM_LAND-MOOR

R
R

0

R

0.0
1.0

R
R

4

R

Default_Material_Layer
Default_AO1
Default_SCAL[x,y,z]Default_TRF

52

Copyright © 2016 Open Geospatial Consortium