Open Geospatial Consortium

Submission Date: 2020-01-21

Approval Date:      2020-08-24

Publication Date:      2021-02-26

External identifier of this OGC® document: http://www.opengis.net/doc/BP/CDB-core-annexes/1.2

Internal reference number of this OGC® document:        16-005r4

Version: 1.2

Category: OGC® Best Practice

Editor:      Carl Reed

OGC CDB Core Model and Physical Structure Annexes (Best Practice)

Copyright notice

Copyright © 2021 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.ogc.org/legal/

Warning

This document defines an OGC Best Practice 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 membership on this particular technology topic.

Document type:        OGC® Best Practice

Document subtype:   

Document stage:    Approved

Document language:  English

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 PATENTS THAT 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 PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET 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 OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM 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 as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

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 (ATS). 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, annexes

iii. 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 be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Organization name(s)

  • 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 Office

The OGC CDB standard is based on and derived from an industry developed and maintained specification, which has been approved and published as OGC Document 15-003: OGC Common Data Base Volume 1 Main Body. An extensive listing of contributors to the legacy industry-led CDB specification is at Chapter 11, pp 475-476 in that 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

Affiliation

Carl Reed

Carl Reed & Associates

David Graham

CAE Inc.

1. 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 the previous 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

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 Detail

Formerly Annex A.17 Volume 2

Annex H: JPEG Informative annex

Was Annex U, Volume 2

Annex I ZIP File Informative annex

Formerly Annex E, Volume 2

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 a schema 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 CDB standard (Normative).

  • Volume 2: OGC CDB Core Model and Physical Structure Annexes (Best Practice).

  • Volume 3: OGC CDB Terms and Definitions (Normative).

  • Volume 4: OGC CDB Rules for Encoding CDB Vector Data using Shapefiles (Best Practice).

  • Volume 5: OGC CDB Radar Cross Section (RCS) Models (Best Practice).

  • Volume 6: OGC CDB Rules for Encoding CDB Models using OpenFlight (Best Practice).

  • 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: http://schemas.opengis.net/cdb/ provides the normative schemas for key features types required in the synthetic modeling environment. Essentially, these schemas 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).

  • Volume 13: OGC CDB Rules for Encoding CDB Vector Data using GeoPackage (Normative, Optional Extension).

  • Volume 14: OGC CDB Guidance on Conversion of CDB Shapefiles into CDB GeoPackages (Best Practice).

  • Volume 15: OGC CDB Optional Multi-Spectral Imagery Extension (Normative).

2. Conformance

This section is not applicable to this document.

3. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International 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 and Definitions (normative) of Best Practice.

4. Conventions

This section 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.

4.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 by partial URIs which are relative to this base.

Annex A: Conformance Class Abstract Test Suite (Normative)

Not applicable for this document.

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 the data required by all sensor devices, not just Image Generators producing the Out the Window (OTW) scenes. The purpose of this integration, among other things, is to achieve 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 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 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 a complete 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 the electromagnetic 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 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 a material. 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:

  1. the sensor types to be supported;

  2. the vendors’ sensor simulation implementations to be supported; and

  3. 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 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 the sensor type) 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 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 as well as their own sets of material properties.

The materials.xsd and materials.xml schema in the CDB schema package enumerates the base materials supported by this standard.

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 for its storage intensive raster imagery datasets. This not only provides a substantial reduction in storage, but also reduces the data transmission bandwidths associated with simulator’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 any other 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 reconstructed without banding artifacts.

  4. High dynamic range: Compress and decompress images with various dynamic ranges (e.g., 1-bit to 16-bit) for each color component.

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

There are other characteristics of the JPEG 2000 that are worth mentioning but are not directly beneficial to the CDB Standard. Those are:

  1. Progressive image reconstruction: Allow images to be reconstructed with increasing 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 the image.

  3. Seamless quality and resolution scalability: Without having to download the entire file

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

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 primary considerations.

  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 in degrees or arc-sec) along the longitudinal axis are increased at specific latitudes; 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 DTED LEVEL 2.

Table A-3. INTERVALS FOR DTED LEVEL 2

DTED Zone Latitude Range (Degrees) Latitude Interval (Arc seconds) Longitude Interval (Arc seconds)

I

0 – 50 N-S

1

1

II

50 – 70 N-S

1

2

III

70 – 75 N-S

1

3

IV

75 – 80 N-S

1

4

V

80 – 90 N-S

1

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 is the 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 of latitude.

  5. The geodetic dimension of an x-axis unit in arc-second is constant within a zone, but is re-defined at pre-selected latitudes to achieve a greater level of spatial sampling uniformity in all tiles; this overcomes the narrowing effect of increased 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 the 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 arrays; each array represents the same content but at successively finer levels of resolution.

  8. The number of units along the slice’s x-axis will vary depending on which zone the latitude of the slice belongs. At this point we introduce the concept 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, which goes from –50 to 50 degrees latitude, a CDB Geocell is 1 × 1 degree, in zone 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 a reasonable 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.

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

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

12

1

–89 ≤ lat < –80

1 X 6

6

2

–80 ≤ lat < –75

1 X 4

4

3

–75 ≤ lat < –70

1 X 3

3

4

–70 ≤ lat < –50

1 X 2

2

5

–50 ≤ lat < +50

1 X 1

1

6

+50 ≤ lat < +70

1 x 2

2

7

+70 ≤ lat < +75

1 x 3

3

8

+75 ≤ lat < +80

1 x 4

4

9

+80 ≤ lat < +89

1 x 6

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 switching from 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.

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 many clients 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 of finer 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 the inherent performance advantage that can be achieved with an LOD structure. Consider a simulator client-device, 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, and without 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 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 for ranges 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 compute the 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 LOD process; these guidelines are provided with each of the raster-organized dataset (or list-organized datasets in future releases of the CDB standard).

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

untitled2

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

untitled3

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 in supporting 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

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

Lossless and lossy compression:

Lossless compression ratios approx. 1.7:1.

Seamless quality / resolution scalability:

Without having to download the entire file.

Progressive image reconstruction:

Allows images to be reconstructed with increasing pixel accuracy and resolution.

Large images sizes - up to (232 - 1).

Perceptual color space internal coding.

Single decompression architecture.

Region of interest coding:

Permits certain ROI’s in the image to be coded and transmitted with better quality and less distortion than the rest of the image.

Error resilience during transfers.

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 the currentAPPNOTE
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 be read)

  • 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 the 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.

Annex M: CDB Directory Naming and Structure

Formerly Appendix M, Volume 2 of the OGC CDB Best Practice

With CDB version 3.2 (prior to the submission into the OGC), Appendix M was used to present the complete list of names allowed to construct the directories of the CDB. As of version 3.2 (as submitted into the OGC standards process), the appendix has been replaced by a combination of folder hierarchy and metadata files and controlled vocabularies delivered 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; and

  • /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.

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) Texture Index CS2 (Txxx) Description

002 – Month

001

January

002

February

003

March

004

April

005

May

006

June

007

July

008

August

009

September

010

October

011

November

012

December

003 – Season

001

Spring

002

Summer

003

Autumn

004

Winter

004 – Uniform Paint Scheme

001

Grey

002

White

003

Green

004

Black

005

Beige

006

Blue

007

Red

008

Yellow

009

Brown

010

Pink

011

Purple

012

Burgundy

013

Orange

014

Light Blue

015

Khaki

016

Dark Grey

017

Amber

018

Gold

019

Silver

020

Copper

005 – Camouflage Paint Scheme

001

Desert

002

Winter

003

Forest

004

Generic

005

Urban

006 – Airline Paint Scheme

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

006

ACA Air Canada

007

ACI Air Caledonie International

008

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 Yollary

017

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.

031

ATC Air Tanzania Company Ltd.

032

AUA Austrian Airlines, Osterreichische

033

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 Oy

049

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

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 GmbH

064

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.

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 Enterprise

094

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

106

HDA Hong Kong Dragon Airlines Limited

107

HEJ Hellas Jet S.A.

108

HHN Hahn Air Lines

109

HLF Hapag Lloyd Fluggesellschaft

110

HZL Hazelton Airlines dba Regional Express

111

IAC Indian Airlines

112

IAW Iraqi Airways

113

IBB Binter Canarias

114

IBE Iberia - Lineas Aereas de Espana

115

ICE Icelandair

116

ICL C.A.L. Cargo Airlines Ltd.

117

IRA Iran Air

118

IRC Iran Aseman Airlines

119

IRM Mahan Airlines

120

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.

127

JKK Spanair S.A.

128

KAC Kuwait Airways

129

KAL Korean Air Lines Co. Ltd.

130

KHA Kitty Hawk Aircargo, Inc.

131

KLM KLM Royal Dutch Airlines

132

KOR Air Koryo

133

KQA Kenya Airways

134

KRP Carpatair S.A.

135

LAA Libyan Arab Airlines

136

LAM LAM - Linhas Aereas de Mocambique

137

LAN Lan Airlines S.A.

138

LAP TAM - Transportes Aereos del

139

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 Airlines

146

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

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 Airlines

168

NMB Air Namibia

169

NTW Nationwide Airlines (Pty) Ltd.

170

NWA Northwest Airlines, Inc.

171

OAL Olympic Airlines

172

OAS Oman Aviation Services Co. (SAOG)

173

PAL Philippine Airlines, Inc.

174

PAO Polynesian Limited

175

PGA Portugalia - Companhia Portuguesa de

176

PIA Pakistan International Airlines

177

PLK Pulkovo Aviation Enterprise

178

PNW Palestinian Airlines

179

PUA Pluna Lineas Aereas Uruguayas S.A.

180

QFA Qantas Airways Ltd.

181

QTR Qatar Airways(Q.C.S.C)

182

RAM Royal Air Maroc

183

RBA Royal Brunei Airlines Sdn. Bhd.

184

REU Air Austral

185

RJA Royal Jordanian

186

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

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 Airlines

221

UAE Emirates

222

UAL United Airlines, Inc.

223

UPS UPS

224

USA US Airways, Inc.

225

UYC Cameroon Airlines

226

VAP Phuket Airlines Co., Ltd.

227

VDA Volga-Dnepr Airline Joint Stock

228

VIR Virgin Atlantic Airways Limited

229

VLE Volare Airlines S.p.A.

230

VLK Vladivostok Air JSC

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 Sabena

243

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 Airlines

251

SKY Skymark Airlines

252

JST Jetstar Airways

253

ABX ABX Air

254

CQH Spring Airlines

255

POE Porter Airlines

256

EAQ Eastern Australia

257

EZY EasyJet

258

NLY Niki

259

VOZ Virgin Australia

260

KNA Kunming Airlines

261

CSC Sichuan Airlines

262

VRD Virgin America

263

DKH Juneyao Airlines

264

KEN Kenmore Air

265

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 Airlines

275

XME Australian Air Express

276

BEL Brussels Airlines

277

GCR Tianjin Airlines

278

VOI Volaris

279

ARA Arik Air

280

LNI Lion Air

281

RYR Ryanair

282

SHU Aurora

283

NIG Aero Contractors

284

SCW Malmö Aviation

285

NAX Norwegian Air Shuttle

286

RAR Air Rarotonga

287

CJR Caverton Helicopters

288

KZR Air Astana

289

ROU Air Canada Rouge

290

DWT Darwin Airline

291

UTA UTair Aviation

292

AZN Amaszonas

293

FDB Flydubai

294

UZB Uzbekistan Airways

295

PGT Pegasus Airlines

296

ABY Air Arabia

297

AXB Air India Express

009 – Quarter

001

First quarter of the year

002

Second quarter of the year

003

Third quarter of the year

004

Fourth quarter of the year

054 – Contaminant

001

Wet Surface

002

Snowy Surface

003

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 Ash

055 – Skid Mark

001

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.

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

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 their applicability to the community 3.0 specification and the OGC standard, which is based on CDB version 3.2.

Dataset Specification

Name

Code

3.0

OGC

Elevation

001

√

√

MinMaxElevation

002

√

√

MaxCulture

003

√

√

Imagery

004

√

√

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

√

√

GSModelGeometry

300

√

√

GSModelTexture

301

√

√

GSModelSignature

302

√

√

GSModelDescriptor

303

√

√

GSModelMaterial

304

√

GSModelInteriorGeometry

305

√

GSModelInteriorTexture

306

√

GSModelInteriorDescriptor

307

√

GSModelInteriorMaterial

308

√

GSModelCMT

309

√

T2DModelGeometry

310

√

GSModelInteriorCMT

311

√

T2DModelCMT

312

√

T3DModelGeometry

320

√

T3DModelTexture

321

√

T3DModelMaterial

322

√

T3DModelInteriorGeometry

323

√

T3DModelInteriorTexture

324

√

T3DModelInteriorMaterial

325

√

NavData

400

√

√

Navigation

401

√

√

GTModelGeometry

500

√

√

510

√

GTModelTexture

501

√

511

√

GTModelSignature

502

√

512

√

GTModelDescriptor

503

√

√

GTModelMaterial

504

√

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

Dataset Code is reserved

Annex R: Derived Datasets within the CDB

By using Industry Standards throughout this document, the CDB Standard defines the means and mechanisms to populate all the simulation datasets without involving data duplication. 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 run-time simulation clients’ performance levels enforces this data derivation.

It is such a case with the Mip-Map data, Min-Max Elevation data, Tile Presence data, RCS data, and Raster Material data for example.

Source Dataset Data Manipulation Description Resulting Dataset(s)

Elevation Dataset

In order to produce the various Level Of Details within the Elevation Dataset, it is often necessary to over-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 be seen as derived information which can better accommodate the client needs based on their performance level.

Elevation LODs

Elevation Dataset

For clients that need to compute line of sights (LOS) between simulation entities spread across a 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 pre-determination of entities occultation state with the terrain. The min/max data is stored in the form of a quad-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 the quarter geocells and so on. Similarly for the minimum the top represents the minimum for the whole of the 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 level can be modified to a finer or coarser level but level 9 is suggested as a reasonable 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 the elevation dataset to determine the maximums or minimums in a given area. The tool will provide Min-Max values to client devices through the Min-Max Elevation datasets in the CDB.

Min-Max Elevation

Vector Datasets (Point, Lineal and Areal Features)

The Max Culture Height data is produced for clients 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 a suggested depth level of 9.

Max Culture Height

3D Model (GT, GS, MM) Datasets

The polar diagram data (covering all aspect angles) of the RCS dataset for Geotypical, Geospecific or Moving Models cannot readily be computed at run-time due to the complex mathematical computing algorithms and resources required to determine the Electro-Magnetic Energy absorption levels by the model’s materials, the corner reflections, the multi-path 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 and polarizations.

RCS (Radar Cross Section)

Vector Datasets (Point, Lineal and Areal Features)

Since the material attribution is normally done in the vector data, a rasterization operation among all features is required to come up with a raster grid of attributed materials.

Raster Material

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

As seen throughout this document, the CDB standard provides guidelines with respect 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 the suggested initial values to be 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 the file when content-generation tools have partial source data.

Parameter Name Dataset Type Default Value R/W

Default_Elevation-1

001_Elevation

float

0 m

R

Default_Elevation-[2-99]

001_Elevation

float

0 m

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

0 m

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 m

R

Default_MaxElevation_CaseII

002_MinMaxElevation

float

8846 m

R

Default_MinElevation_CaseIII

002_MinMaxElevation

float

8846 m

W

Default_MaxElevation_CaseIII

002_MinMaxElevation

float

-400 m

W

Default_MaxCulture_CaseI

003_MaxCulture

float

600 m

R

Default_MaxCulture_CaseII

003_MaxCulture

float

0 m

R

Default_VSTI_Y_Mono

004_Imagery

float

0.5

R

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_Gamma

507_GTModelInteriorTexture

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

integer

4

R

Annex Y: Revision History

Date Release Editor Primary clauses modified Description

2017-02-23

1.0

C. Reed

All

2018-08-28

1.1

C. Reed

All

2019-12-16

1.2

C. Reed

Various

Changes for version 1.2