Open Geospatial Consortium

Submission Date: 2018-03-04

Approval Date:      2018-08-27

Publication Date:      2018-12-19

External identifier of this OGC® document: http://www.opengis.net/doc/IS/CDB-core/1.1

Additional Formats (informative): F+G2fvLtTjLSr4cADESA7XbHd8gco4fq2dAz0VXYYJMi2DSAeKJh+S1n4d8GPmwVvHdyvi8MNmyvuUrCagAAAABJRU5ErkJggg==

Internal reference number of this OGC® document:        15-113r5

Version: 1.1

Category: OGC® Implementation Standard

Editor:      Carl Reed, PhD

Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure

Copyright notice

Copyright © 2017, 2018 Open Geospatial Consortium

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

Warning

This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:        OGC® Standard

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.

Table of Contents

i. Abstract

The CDB standard defines a standardized model and structure for a single, versionable, virtual representation of the earth. A CDB structured data store provides for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various simulator client-devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime simulation tasks. In this case, a CDB is plug-and-play interoperable between CDB-compliant simulators. A CDB can be readily used by existing simulation client-devices (legacy Image Generators, Radar simulator, Computer Generated Forces, etc.) through a data publishing process that is performed on-demand in real-time.

The application of CDB to future simulation architectures will significantly reduce runtime-source level and algorithmic correlation errors, while reducing development, update and configuration management timelines. With the addition of the High Level Architecture - -Federation Object Model (HLA/FOM)[1] and DIS protocols, the application of the CDB standard provides a Common Environment to which inter-connected simulators share a common view of the simulated environment.

The CDB standard defines an open format for the storage, access and modification of a synthetic environment database. A synthetic environment is a computer simulation that represents activities at a high level of realism, from simulation of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by super-realistic special effects and accurate behavioral models. SE allows visualization of and immersion into the environment being simulated[2].

This standard defines the organization and storage structure of a worldwide synthetic representation of the earth as well as the conventions necessary to support all of the subsystems of a full-mission simulator. The standard makes use of several commercial and simulation data formats endorsed by leaders of the database tools industry. A series of associated OGC Best Practice documents define rules and guidelines for data representation of real world features.

The CDB synthetic environment is a representation of the natural environment including external features such as man-made structures and systems. A CDB data store can include terrain relief, terrain imagery, three-dimensional (3D) models of natural and man-made cultural features, 3D models of dynamic vehicles, the ocean surface, and the ocean bottom, including features (both natural and man-made) on the ocean floor. In addition, the data store can include the specific attributes of the synthetic environment data as well as their relationships.

The associated CDB Standard Best Practice documents provide a description of a data schema for Synthetic Environmental information (i.e. it merely describes data) for use in simulation. The CDB Standard provides a rigorous definition of the semantic meaning for each dataset, each attribute and establishes the structure/organization of that data as a schema comprised of a folder hierarchy and files with internal (industry-standard) formats.

A CDB conformant data store contains datasets organized in layers, tiles and levels-of-detail. Together, these datasets represent the features of a synthetic environment for the purposes of distributed simulation applications. The organization of the synthetic environmental data in a CDB compliant data store is specifically tailored for real-time applications.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, CDB, Common Data Base, simulation, synthetic environment, virtual

iii. Preface

The industry-maintained CDB model and data store structure has been discussed and demonstrated at OGC Technical Committee meetings beginning in September 2013.

At the suggestion of several attendees at the first OGC CDB ad-hoc meeting in September 2014, the existing CDB standard was slightly reformatted and approved as an OGC Best Practice in May 2015.

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):

  • 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

Organization name(s)

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.

vi. Future work

The CDB community anticipates that additional standardization work will be required to prescribe content appropriate to targeted simulation applications, new use cases, and application in new domains. In its current form, the CDB standard does not mandate synthetic environmental richness, quality and resolution.

Further, the OGC CDB Standards Working Group (SWG) members understand there is a requirement for eventual alignment of the CDB standard with the OGC/ISO standards baseline. In Version 1 of the CDB standard, effort was invested to begin aligning terminology and concepts, specifically in the coordinate reference system discussions and requirements.

This version of the CDB standard is backwards compatible with version 1.0 of the OGC CDB standard with one exception.

The requirements for a CDB data store are focused on the ability to store, manage, and access extremely large volumes of geographic content and related model definitions. In this version of the standard, initial harmonization with the OGC and ISO standards baseline has begun. For example, where appropriate, the CDB simulation community terms and definitions have been replaced with OGC/ISO terms and definitions. Further, the standards documents have been reorganized and structured to be consistent with the OGC Modular Specification Policy. However, the CDB SWG and community recognize the need to further harmonize and align this standard with the OGC/ISO baseline and other IT best practices. There has already been considerable discussion in this regard.

Based on such discussions and comments received during the public comment period, the following future work tasks are envisioned:

  1. Describe explicitly how the CDB model may or may not align with the OGC DGGS standard;

  2. Provide best practice details on how to use WMS, WFS, and WCS to access existing CDB data stores. This work may require Interoperability Experiments to better understand the implications of these decisions;

  3. Extend the supported encodings and formats for a CDB structured data store to include the use of the OGC GeoPackage, CityGML, and InDoorGML standards as well as other broadly used community encoding standards, such as GeoTIFF. This work may require performing OGC Interoperability Experiments to better understand the implications of these decisions.

  4. Further align CDB terminology to be fully consistent with OGC/ISO terminology.

Making these enhancements will allow the use and implementation of a CDB structured data store for application areas other than aviation simulators.

vii. A note on using a CDB Data Store with OGC Standards

Please refer to Volume 0: CDB Primer, Clause 5 for an operational example of using OGC standards to query, access, and modify content in a CDB data store.

1. Introduction

The CDB standard defines a data model and the representation, organization, storage structure and conventions necessary to support all of the subsystems of a simulation workflow. The standard makes use of existing commercial and simulation data formats [3].

The CDB conceptual model is a representation of the natural environment including external features such as man-made structures and systems. The model encompasses planimetry, terrain relief, terrain imagery, three-dimensional (3D) models of natural and man-made cultural features, 3D models of vehicles, the ocean surface, and the ocean bottom, including features (both natural and man-made) on the ocean floor. In addition, the model includes the attributes of the synthetic environment data as well as their relationships.

A data store that conforms to the CDB standard (i.e., a CDB) contains datasets organized in layers, tiles and levels-of-detail. Together, these datasets represent the features and models of a synthetic environment for the purposes of distributed simulation applications. The organization of the geospatial data in a CDB data store is specifically tailored for real-time applications.

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 Best Practice use of Shapefiles for Vector Data Storage (Best Practice).

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

  • Volume 6: OGC CDB Rules for Encoding Data 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: provides the normative schemas for key features types required in the synthetic modelling 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)

Once this version is approved as an OGC standard, the CDB SWG shall consider how this standard will evolve to align with the OGC/ISO standards baseline. Discussion and suggestions have already started, specifically in relation to the OGC GeoPackage, DGGS, KML, and CityGML standards.

1.1. Conformance

This standard defines an Abstract Test Suite in Annex A.

Requirements for one standardization target type are considered.

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site[4].

1.2. References

Please see Annex B in Volume 0: Primer for the OGC CDB Standard: Model and Physical Data Store Structure for a complete list of all normative and informative references.

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

Terms and Definitions specific to this standard or defined by existing ISO 19000 series standards are provided in Volume 3: OGC CDB Terms and Definitions <need URL at publication>.

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

1.4.1. Identifiers

The normative provisions in this standard are denoted by the URI

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

For the sake of brevity, the use of “req” in a requirement URI denotes:

An example might be:

req/core/platform

1.4.2. CDB XML Schema Definitions

Note
The content in this clause was originally in CDB Volume 2, Annex J.

The CDB standard makes an extensive use of XML to describe several parts of the standard. XML is used to describe CDB metadata, controlled vocabularies, to store global datasets, to add attributes and information to 3d models, such as an OpenFlight model, to describe base and composite materials, and so forth.

The following XML Schemas can be found in the \CDB\Metadata\Schema subdirectory of the CDB Standard Distribution Package:

  • BaseMaterialTable.xsd

  • CompositeMaterialTable.xsd

  • Configuration.xsd

  • Defaults.xsd

  • FeatureDataDictionary.xsd

  • Lights.xsd

  • LightsTuning.xsd

  • ModelComponents.xsd

  • ModelMetadata.xsd

  • OpenFlightModelExtensions.xsd

  • VectorAttributes.xsd

  • Version.xsd

Clause 1.4.3 and 1.4.4 provides more information on these files.

1.4.2.1. The CDB Namespace

The CDB standard makes use of several XML namespaces to isolate the definitions of its schemas. The name of these namespaces is built around a base URL.

1.4.2.2. Schema Conventions

The target namespace of all CDB schemas follow this pattern:

"http://schemas.opengis.net/cdb/[Name]/[Version]"

Where the Name is identical to the filename portion of the file containing the schema and Version is the version number of the schema.

To illustrate how a target namespace is composed, here is the target namespace of the schema found in Version.xsd (item 12 in the list above):

"http://schemas.opengis.net/cdb/Version/1.1"

IMPORTANT NOTE: For brevity, the literal “CDB” in a schema path should be expanded to:

Name/1.1

in any implementation.

1.4.3. CDB Metadata, Controlled Vocabulary, and Metadata Files

There are a number of CDB XML files that are stored and referenced from the CDB metadata folder. First, some terms are defined

1.4.3.1. Metadata

Metadata is "https://en.wikipedia.org/wiki/Data[data] [information] that provides information about other data”[5]. In the geospatial community and the rapidly emerging spatial web community, metadata is critical to operations such as discovery and determining whether a resource is “fit for purpose”. Three distinct types of metadata exist: descriptive metadata, structural metadata, and administrative metadata [6].

  • Descriptive metadata describes a resource for purposes such as discovery and identification. It can include elements such as title, abstract, author, and keywords.

  • Structural metadata is metadata about containers of metadata and indicates how compound objects are put together, for example, how pages are ordered to form chapters.

  • Administrative metadata provides information to help manage a resource, such as when and how it was created, file type and other technical information, and who can access it. <end Wikipedia>

The geospatial community has a long and extensive history in defining and using metadata for geospatial resources. Without metadata, discovery of required resources and determination of whether a resource is “Fit for Purpose” becomes difficult if not impossible. The geospatial community makes use of all three types of metadata, although the first and third are more critical. The CDB use of metadata focuses on use cases 1 and 3.

  1. Controlled Vocabulary

    Controlled vocabularies provide a way to organize knowledge for subsequent retrieval and use. They are used in subject indexing schemes, subject headings, thesauri,[1][2] taxonomies and other forms of knowledge organization systems. Controlled vocabulary schemes mandate the use of predefined, authorized terms that have been preselected by the designers of the schemes, in contrast to natural language vocabularies, which have no such restriction. The use of controlled vocabularies in standards such as CDB can significantly increase interoperability and consistent understanding of the semantics. Controlled vocabularies typically are managed through formal processes and official governance.

  2. Enumerations

    In computer programming, an enumerated type (also called enumeration) is a data type consisting of a set of named values called elements, members, enumeral, or enumerators of the type. The enumerator names are usually identifiers that behave as constants in the language.Similarily, in a database enumerated (enum) types are data types that comprise a static, ordered set of values. They are equivalent to the enum types supported in a number of programming languages. An example of an enum type might be the days of the week, or a set of status values for a piece of data.

1.4.3.2. CDB metadata, controlled vocabularies, and enumerations summary table

The following is a list of these files. While the general term being used is “metadata” in terms of the file system structure, a number of these files are either controlled vocabularies or attribute files. Please read Clauses 1.4.4, 1.5, and 3.1.1 Metadata Directory for more detailed information on the files maintained in that folder. The following table identifies the files stored in the metadata folder and whether they are metadata or controlled vocabularies.

Name Location Type[7] Extension M/O[8]

CDBAttributes

\CDB\Metadata\ CDB-Attributes

CV

.xml

O

Configuration

\CDB\Metadata\Configuration

M

.xml

O

Datasets

\CDB\Metadata\Datasets

CV

.xml

O

Lights

\CDB\Metadata\Lights

CV

.xml

O

LightsFLIR

\CDB\Metadata\LightsFLIR

CV

.xml

C

Defaults

\CDB\Metadata\Defaults

E

.xml

O

Materials

\CDB\Metadata\Materials

CV

.xml

O

Modelcomponents

\CDB\Metadata\Modelcomponents

CV

.xml

O

Movingmodelcodes

\CDB\Metadata\MovingModelcodes

E

.xml

O

Version

\CDB\Metadata\Version

M

.xml

M

FeatureDataDixtionary

\CDB\Metadata

CV

.xml

O

DISCountryCodes

\CDB\Metadata\DIScountrycodes

E

.xml

O

Globalgeometadata

\CDB\Metadata\Globalgeo

M

.<ext>[9]

O

Localgeometadata

Determined by directory path rules

M

.<ext>

O

Each of these files is described in detail later in this document.

In CDB version 1.1 and later, additional metadata requirements and elements are specified. These are traditional metadata including geospatial metadata. Specifically, the reader should reference clauses 3.1.1, 3.1.2, and 5.1 (special focus on 5.1.6). Also, make special note of the guidance in clause “3.2.3.2 How to handle the metadata directory.”

1.4.4. CDB Directory File Naming and Structure

The CDB directory and folder structure is defined by a combination of folder hierarchy and metadata files delivered with the CDB Standard Distribution Package.

The /CDB folder hierarchy provides a complete list of directory and filename patterns of the CDB; it summarizes the structure of the CDB presented in chapter 3 of this document. The following files contain enumerations and controlled vocabularies that are necessary to expand the patterns:

  • /CDB/Metadata/FeatureDataDictionary.xml provides the list of directory names associated with feature codes.

  • /CDB/Metadata/MovingModelCodes.xml provides the list of names for DIS Entity Kinds, Domains, and Categories.

  • /CDB/Metadata/DISCountryCodes.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 standard.

In CDB Version 1.1, explicit file name extensions in Requirements were replaced with a generic <ext> to designate that one or more file types are allowed to satisfy that requirement. Notes are also provided to indicate what filename extension (type) was required as specified in CDB Version 1.0. In CBD Version 1.1, the following file extensions are used:

File Format

Versions Currently Supported by CDB

CDB Client-device Behavior for Prior Versions

*.tif

6.0

Ignores data

*.rgb

1.0

Ignores data

*.jp2

1.0

Ignores data

*.flt

16.0

Ignores data

*.shp, *.shx

Esri White Paper, July 98

Ignores data

*.dbf, *.dbt

dBASE III+ and above

Ignores data

*.xml

1.0

Ignores data

*.zip

6.3.1

Ignores data

1.5. CDB Feature Data Dictionary

The CDB Feature Data Dictionary (FDD) is provided with the CDB standard in the form of an XML file. An XML Stylesheet is provided to format and display the dictionary inside a standard Web browser. Furthermore, the XML Schema defining the format of the FDD can also be found in the Schema subdirectory of the CDB Schema Distribution Package.

See /CDB/Metadata/Feature_Data_Dictionary.xml for the complete list of the supported codes [10].

Please see section 3.3.8.1 for more detailed information on the use of feature codes and extensions to that codelist in the CDB standard.

1.6. Introduction

1.6.1. Purpose

This standard provides a full description of a data model (aka schema) for the synthetic representation of the world. The representation of the synthetic environment in the CDB model as expressed in a physical data store is intended for use by authoring tools and by various simulator client-devices that are able to simultaneously retrieve, in real-time, relevant information to perform their respective runtime simulation tasks. With the addition of the DIS protocol, the application of the CDB standard provides a Common Environment to which inter-connected simulators share a common view of the simulated environment.

1.6.2. Document Structure

This document is structured as follows.

Section 1.6 defines general CDB data store and implementation requirements

Sections 2.1, 2.2, 2.3, and 2.4 provide an overview if key elements of the CDB data store structure.

Section 2.5: CDB concepts and semantics. Describes the naming and handling of materials that make up the synthetic environment

Section 3.0: Focuses on aspects of the data model that relate to the structure of the data store repository on the storage subsystem. The organization of the CDB data into tiles, levels-of-detail and datasets is embodied through a set of conventions that prescribe the CDB directory hierarchy and file naming conventions.

Section 4: CDB File Formats provides a description of all the formats prescribed by the CDB Specification.

Section 5: CDB Datasets provides a detailed description of all CDB datasets.

The current CDB standard relies on established industry formats:

  • The TIFF format. TIFF encoding rules are defined in Volume 10: OGC CDB Implementation Guidance;

  • The Best Practice use of the OpenFlight [11] format (Volume 6: OGC CDB Rules for Encoding Data using OpenFlight);

  • The RGB format. Included in the Gamma Tutorial Section, Volume 10: OGC CDB Implementation Guidance

  • The Best Practice use of the Shapefile format in a CDB data store. The Shapefile table content encoding rules are in Volume 4. Volume 4: OGC CDB Best Practice use of Shapefiles for Vector Data Storage;

  • JPEG 2000 file format (Volume 2: OGC CDB Core Model and Physical Structure Annexes, Annex H).

Each of these documents has been annotated to reflect the conventions established by the CDB standard. The Best Practice conventions currently define how TIFF, OpenFlight, RGB, Shapefile and JPEG 2000 formatted files are to be interpreted by CDB-compliant simulator readers. Additional encoding formats and conventions will be defined for future versions of the CDB standard.

Annexes J and F of Volume 2 provide the CDB light type naming hierarchy and the CDB model component hierarchies respectively while \CDB\Metadata\Materials.xml provides the material list for the CDB standard.

Other Annexes in Volume 2 further describe additional aspects of the CDB standard:

  • Providing the CDB Directory Naming and Structure (Annex M),

  • List of Texture Component Selectors (Annex O see footnote 32 [12]),

  • SGI Image File Format (http://paulbourke.net/dataformats/sgirgb/sgiversion.html),

  • Table of Dataset Codes (Annex Q [13])

  • How some datasets are derived from others (Annex R see footnote 32).

1.6.3. What is the CDB Standard: An Overview

The CDB standard defines a conceptual model that models the organization, and storage structure of a data store to support real time simulation applications. A data store that conforms to the CDB standard contains datasets organized in layers and tiles that represent the features of the earth for the purposes of distributed simulation applications. A CDB data store can be readily used by existing simulation client-devices (legacy IGs, Radars, CGF, etc.) through a publishing process performed in real-time. The CDB conceptual model would allow an implementation if a CDB compliant data store in a relational database. However, the data structures used in CDB structured data stores are somewhat different than those used in relational databases because 1.) of the use of standardized data formats adopted by the simulation community and 2.) the CDB storage structure is optimized for near real time simulation applications. The approach defined in this CDB Core standard facilitates the work required to adapt existing authoring tools to read/write/modify data into the CDB and the task to develop runtime publishers (RTP) designed to operate on these data structures.

The CDB standard is fundamentally about:

  • A representation of the earth and man-made environment for use in real time simulations; and

  • A turnkey, as-is representation of the Synthetic Environment (SE) for use in real-time distributed simulation applications.

Currently, the majority of a CDB conformant internal data storage representation is based on five well known and supported data formats endorsed by leaders of the simulation database tools industry. The CDB Best Practices associated with the Core standard are currently recommended for implementation of a CDB data store:

  • For the representation of terrain altimetry, terrain surface characteristics relevant to simulation: TIFF/GeoTIFF

  • For the representation of 3D culture and moving models: OpenFlight

  • For the textures associated with 3D culture and moving models RGB

  • For the instancing and attribution of statically positioned point, lineal and polygon 2D/3D culture features.

  • For a representation of terrain raster imagery comprising a well-defined and accepted compression method that allows both lossy and lossless schemes: JPEG 2000.

Please note that the OGC CDB Standards Working Group is considering developing best practice guidance for using other industry standard formats and encodings, such as OGC CityGML, OGC InDoorGML, and OGC GeoPackage.

Note
Due to the real time requirement, the CDB standard limits the number of units of measure for each physical quantity. For instance, all coordinates are represented in latitude longitude and all distances are in meters.
Note
In the future, the CDB standard will evolve to enable the use of other international and de-facto geospatial encoding structures.

The CDB specified storage structure allows efficient searching, retrieval and storage of any information contained within a CDB structured data store. Storage structure aspects include descriptions of each information field used within CDB conformant files, including data types and data type descriptions.

The CDB standard relies on three important concepts to organize the geospatial data.

  • Tiles: The CDB defined storage structure allows efficient searching, retrieval and storage of any information contained within the CDB. The storage structure portion of this standard geographically divides the world into geodetic tiles (each tile bounded by latitude and longitude), each tile containing a specific set of features (such as terrain altimetry, vectors) and models (such as 3d models and radar cross section models), which are in turn represented by the datasets. The datasets define the basic storage unit used in a CDB data store. The geographic granularity is at the tile level while the information granularity is at the dataset level. As a result, the CDB storage structure permits flexible and efficient updates due to the different levels of granularity with which the information can be stored or retrieved

  • Layers: The CDB model is also logically organized as distinct layers of information. The layers are notionally independent from each other (i.e., changes in one layer do not impose changes in other layers).

  • Levels-of-Detail (LODs): The availability of LOD representations is critical to real-time performance. Most simulation client-devices can readily take advantage of an LOD structure because, in many cases, less detail/information is necessary at increasing distances from the simulated own-ship. As a result, many client-devices can reduce (by 100-fold or more) the required bandwidth to access environmental data in real-time. The availability of levels-of-detail permits client-devices to deal with data stores having big-data levels of content. The CDB storage model supports a LOD hierarchy consisting of up to 34 LODs. The CDB standard requires that each geographic area be reduced into a LOD hierarchy in accordance to the availability of source data.

The standard does not define or enforce an operating system or file system.

1.6.4. What the CDB Standard is Not

The representation and sharing of geospatial data plays a key role in the interoperation of systems and applications that use such data. In the mid to late 90’s some specifications/standards were conceived to provide a means of sharing synthetic environment data, in source form, for a wide variety of applications. They provided a standardized means to share native databases, thereby avoiding direct and (often inefficient) conversion of the data to/from (often proprietary) native database format.

The CDB standard defines a model for data representation and attribution of terrain, objects and entities within the CDB data store. However, the standard does not define requirements for the movement, change in shape, physical properties and/or behavior of such objects and entities. These capabilities fall under the domain of simulation software or application.

The CDB standard does not define requirements for the representations of celestial bodies, such as the Sun, Moon, stars, and planets. Rather, this standard assumes that the modeled representation of celestial bodies is internally held within the appropriate simulator client-devices.

The CDB standard does not specify a mandatory “coverage completeness requirement” imposed by. This permits the generation of a CDB structured data store even when there is limited data availability.

Given the requirement that the CDB standard be platform independent, the standard does not provide the implementation details of specific off-line data store compilers or runtime publishers attached to specific client-devices [14]. Furthermore, since there is no standardization of the SE representation internal to client-devices (they vary by type [15], by vendors), it is unlikely that such information would completely satisfy the interests of all developers. More importantly, the structure and format of data ingested by each client-device is typically proprietary. Finally, this standard does not describe the effort required to develop CDB off-line compilers and/or CDB runtime publishers.

1.7. General CDB Data Store and Implementation requirements

This section details the requirements for a CDB conformant or structured data store.

Requirement 1

http://www.opengis.net/spec/CDB/1.0/core/model

A CDB implementation SHALL include all elements of the CDB Core Data Model as defined in Annex A.

1.7.1. Platform Requirements

Requirements Class - Platform requirements.

/req/core/platform

Target type

Operations

Dependency

Operating System

Dependency

Hardware

Dependency

File Management system

Requirement 5

/req/core/literal-case

1.7.1.1. File System

Moved to section 5.1 Volume 10: Implementation Guidance

1.7.1.2. Operating System

Moved to section 5.2 Volume 10: Implementation Guidance

1.7.1.3. Transport Protocols

The CDB standard is transport protocol-independent. The standard does not mandate the use of specific transport protocols. Furthermore, this standard does not explicitly rely on or specify any transport protocols.

1.7.1.4. System Hardware Independence

This section was moved to section 5.3 Volume 10, Implementation Guidance

1.7.1.5. Literal Case

Requirement 5

http://www.opengis.net/spec/CDB/1.0/core/literal-case

Implementations SHALL support the literal case rules as specified in this standard. CDB file naming conventions are case sensitive. Further, regardless of case, any name such as “house” SHALL have the same semantic meaning.

CDB structured data stores may be implemented on any modern operating systems whether they are Windows-like or Unix-like.

Throughout this standard, the reader will notice that filenames and directory paths are specified using a mix of upper and lower cases. This choice is made to improve and ease the readability of those names.

However, it is important to note that no two names are to differ only by their case. After all, a name is used to designate a single object or concept whether that name is spelled in lowercase or uppercase or even using mixed case. For instance, the terms house, House, and HOUSE (and even HoUsE) all convey the same idea of a residence where people live. And this stays true for all combination of cases.

1.7.2. General Data Representation Requirements

The following is the Requirements Class for general data representation requirements.

Requirements Class - General Data Representation. (6-10)

/req/core/data-representation

Target type

Operations

Dependency

WGS-84 definition

Dependency

Compression Algorithms

Dependency

Units of measure

Requirement 6

/req/core/raster-imagery-compression

Requirement 7

/req/core/uom

Requirement 8

/req/core/crs

Requirement 9

/req/core/crs-client

Requirement 10

/req/core/coordinates

1.7.2.1. Compression of Storage Intensive Imagery Datasets

Requirement 6

http://www.opengis.net/spec/CDB/1.0/core/raster-imagery-compression

JPEG 2000 SHALL be used for storing and compressing Raster Imagery such as the imagery used for Out The Window (OTW) applications. See Annex C Volume 2 for reasons for this requirement.

1.7.2.2. Compression of other imagery datasets

In general, all TIFF/GeoTIFF files benefit from LZW compression. For this reason, and as a general practice, the compression of all TIFF-based raster datasets is recommended. The one exception is when every cell in the raster dataset is a unique floating point number. In this case, the compressed file may be larger than the original.

1.7.2.3. Units of Measure

Requirement 7

http://www.opengis.net/spec/CDB/1.0/core/uom

All units of measure in a CDB conformant data store SHALL be in meters.

1.7.3. Coordinate Reference Systems

Requirement 8

http://www.opengis.net/spec/CDB/1.0/core/crs

Geographic locations in CDB SHALL be expressed using WGS-84 (World Geodetic System 1984), equivalent to EPSG (European Petroleum Survey Group) code 4326 (2 dimensions) and EPSG code 4979 (3 dimensions).

If a geographic location also has an altitude, the altitude SHALL be expressed relative to the WGS-84 reference ellipsoid.

Please see the Volume 8: OGC CDB Spatial Reference System Guidance.

Requirement 9

http://www.opengis.net/spec/CDB/1.0/core/crs-client

Each implementation of the simulator client-devices accessing the CDB geospatial data SHALL at a minimum support the WGS-84 geodetic coordinate system as specified in Req 8. Other reference systems may be used in the client application.

1.7.4. Geographic Coordinates

Requirement 10

http://www.opengis.net/spec/CDB/1.0/core/coordinates

Coordinates SHALL be described using the decimal degree format without the “°”symbol. The values of latitude and longitude SHALL be bounded by ±90° and ±180° respectively. Positive latitudes are north of the equator, negative latitudes are south of the equator. Positive longitudes are east of the Prime Meridian; negative longitudes are west of the Prime Meridian. Latitude and longitude are expressed in that sequence, namely latitude before longitude.

2. CDB Concepts

This chapter presents basic CDB data store model concepts. These concepts are either reused by other concepts or used repeatedly throughout the Standard.

The CDB core data model may be viewed as an instance of a Discrete Global Grid System as defined in OGC 15-104. Please note, however, that the CDB data model and structure predates the OGC DGGS activity by over a decade and as such should not be deemed compliant with the OGC DGGS standard.

A DGGS is a spatial reference system that uses a hierarchical tessellation of cells to partition and address the globe. DGGS are characterized by the properties of their cell structure, geo-encoding, quantization strategy and associated mathematical functions.

The following sections detail the CDB tiling storage model.

Requirements Class - Tiles/Geocells and LoD relationships (11-16 and 41)

/req/core/cdb-structure-tiles-lod

Target type

Operations

Dependency

WGS-84 2d definition

Requirement 11

/req/core/geocell-extent

Requirement 12

/req/core/geocell-length

Requirement 13

/req/core/tile-sizes

Requirement 14

/req/core/lod-area-coverage

Requirement 15

/req/core/hierarchy

Requirement 16

/req/core/tile-lod-replacement

Requirement 41

/req/core/lod-organization-resolution (section 3.3.6)

2.1. Characteristics of the CDB tiling storage model

For performance, a CDB data store is tiled. Both raster and vector-based data sets are tiled. The CDB tiling approach has the following characteristics.

  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-seconds of y-axis units within an earth slice is exactly the same, regardless of latitude.

  5. The geodetic dimension of an x-axis unit in arc-seconds 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 [16].

  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 multiple of 2n in all slices.

  8. The number of units along the slice’s x-axis will vary depending on which zone the latitude of the slice belongs. For instance, in latitude zone 5, which goes from –50° to 50° of latitude, a CDB Geocell is 1° × 1°, in zone 4 and 6 which goes from latitude 50° to 70° the cell size is 1° × 2°. The main reason to introduce this concept is to maintain a reasonable eccentricity between the sides by trying to keep them as close to a square as possible. Variable CDB Geocell size reduces the simulator client-device processing overheads associated with the switching from one zone to another (due to small number of zones across the earth), reduces the variation of longitudinal dimensions (in meters) to a maximum of 50% and improves storage efficiency. Two requirements as defined below are used to define the size of a CDB Geocell

Geocell extent

Requirement 11

http://www.opengis.net/spec/CDB/1.0/core/geocell-extent

A CDB Geocell SHALL start and end on a whole degree along the longitudinal axis.

Geocell length

Requirement 12

http://www.opengis.net/spec/CDB/1.0/core/geocell-length

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

2.1.1. Details of the Tiling System in the CDB core model

The CDB storage model represents the earth as a fixed number of slices divided equally along a latitude axis as illustrated in Figure 2-1: CDB Earth Slice Representation.

image

Figure 2-1. CDB Earth Slice Representation

The earth surface coordinate system conventions used for each slice consists of a regular two-dimensional grid where the x-axis is always pointing east, aligned to WGS-84 lines of latitude and where the y-axis is always pointing north, aligned with WGS-84 lines of longitude. The earth surface origin, reference point (lat:0, long:0) on the CDB earth representation, is defined by the intersection of the WGS-84 equator and the WGS-84 international 0° meridian [17]. The x=0 and y=0 reference is at (lat:0, long:0) x is positive going East and negative going West; y is positive North of the equator and negative South.

Every x and y unit corresponds to a fixed increment of longitude and latitude in arc-seconds. The x-axis and y-axis fixed increment units are hereafter referred to as XUnit and YUnit. Since the y-axis of the slices is aligned with WGS-84 lines of longitude, y-axis coordinate units are uniformly distributed between the equator and the poles in both geodetic system terms (arc-second) and in Cartesian system terms (meters). This property naturally leads to defining the same number of YUnit per slice. This however is not the case with the x-axis. As illustrated in Figure 2-2: Variation of Longitudinal Dimensions versus Latitude, the Cartesian space distance between such x-axis values diminishes as we move towards the poles. In order to maintain size constancy, the CDB standard provides a piecewise solution similar to that used by NGA DTED data. The world is divided into eleven zones. All CDB Geocells within a slice are one degree of latitude high (the height of a slice) and of varying width in longitude depending on the zone to which they belong.