Open Geospatial Consortium

Submission Date: 2023-05-22

Approval Date:      2023-xx-xx

Publication Date:      2023-xx-xx

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

Internal reference number of this OGC® document:        23-034

Version: 2.0

Category: OGC® Implementation Standard (Draft)

Editor:      Carl Reed, PhD

OGC CDB Version 2: Core Standard (Draft)

Copyright notice

Copyright © 2023 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.ogc.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:    Draft

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

CDB Version 2.0 is a major revision to the CDB standard. The CDB Version 2.0: Core Standard specifies requirements (rules) defining a standardized model and structure for a single, versionable, virtual representation of the earth. The full CDB standard is comprised of a fundamaental core, Parts (extensions to the core), and profiles. The core consists of requirements and conformance classes that must be complied with in any extension, profile, and implementation. Core requirements can be profiled (restricted). An overarching design principle is that a CDB data store is focused on the ability to store, manage, and access extremely large volumes of geographic content and related assets such as model definitions in as determinstic manner as possible.

A CDB compliant structured data store provides a geospatial content and model repository that is plug-and-play interoperable between applications within a domain and potentially between domains. In the CDB context, a domain represents an information community, such as gaming, tactical analysis, or simulation, that has a common set of requirements for data content including access.

Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various client-devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime tasks. In this case, a CDB data store is plug-and-play interoperable between CDB-compliant clients. The hope is that implementations of CDB 2.0 will significantly reduce runtime-source level and algorithmic correlation errors, while reducing development, update and configuration management timelines.

The CDB Version 2.0 and earlier standards defines an open, deterministic structure and rules for the storage, access and modification of a synthetic environment data store. 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 distributed network connected by local and wide area networks or in the cloud and augmented by super-realistic special effects and accurate behavioral models.

The CDB synthetic environment is a representation of the natural environment including 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.

ii. Keywords

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

ogcdoc, OGC document, CDB, simulation, synthetic environment, virtual

iii. Preface

This major revision to the OGC CDB Standard is the result of numerous OGC interoperability experiments, "sprints", SWG discussions, and general input and feedback from the OGC Membership, the CDB User base, and the broader Simulation Community. Further, there is a requirement for alignment of the CDB standard with the OGC/ISO standards baseline. In CDB Version 1.0, effort was invested to begin aligning terminology and concepts with the OGC standards baseline, specifically in the coordinate reference system discussions and requirements. For version 1.1, the primary effort was focused on resolving several Change Requests and adding guidance on incorporating metadata into a CDB data store. Version 1.2 provided requirements and best practices for using the OGC GeoPackage Standard to specify containers for CDB content. This major revision completes that trend.

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

  • Need more

Organization name(s)

v. Contributors and Endorsing Members

Name

Affiliation

Role

Carl Reed

Carl Reed & Associates

Editor

David Graham

Eaglecapsystems

SWG Chair and Editor

Kevin Bentley

Cognitics

Contributor

Hermann Bressard

Presagis

Contributor

Brian Ford

FlightSafety

Contributor

Ryan Franz

FlightSafety

Contributor

Jérôme Jacovella-St-Louis

Ecere

Contributor

Michala Hill

Cognitics

Contributor

Greg Peele

Geometric Progress

Contributor

Please submit your comments using the following email address: requests@list.opengeospatial.org. The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the official template for the message body. Please direct comments to the editors named above.

vi. Future work

The CDB community understands that additional standardization work is required to define and document additional Parts, extensions, profiles, and content appropriate to targeted applications, new use cases, and application in new domains.

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.

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

1. Using OGC standards with a CDB structured data store

The U.S. Department of Defense (DoD) developed the Joint Training Data Services (JTDS) to support rapid scenario generation for the U.S. DoD M&S training community [1]. The recently developed (2014) and deployed JTDS Common Terrain Generation Service (C-TGS) is a cloud-based service for the war fighter. C-TGS provides a robust capability to search, discover and retrieve Modeling and Simulation (M&S) terrain data. JTDS based the C-TGS standard data structure on OGC-approved formats served by OGC Web Services. The goal for the Terrain Generation Service (TGS): Eliminate the current paradigm where every simulation uses a different proprietary format. Current data efforts are fraught with simulation issues and errors, and data mining, correlation and processing to support multiple simulation formats is manpower intensive.

The TGS Solution: Have a repository and user interface that provides access to a single source of data through a persistent web service AND set and enforce a standard data structure based on industry standard Open Geospatial Consortium (OGC) approved formats, to normalize terrain data across Force Development simulations.

image

The above figure, DoD C-TGS Architecture (Chambers and Sherman, 2014), represents the implementation architecture for C-TGS. Implementation software represents a mix of commercial/proprietary and open source. At the heart of the C-TGS are two data stores: A CDB structured data store and a 3D model data store. All applications at the Visualization and Dissemination level interface the data stores via OGC service interfaces.

Connecting OGC Web Services to an open, simulation-optimized terrain data store, such as a CDB structured data store, results in high-end performance for serving and rendering geospatial content, the ability to dynamically modify terrain and support for all levels of simulation. a high-end simulation system using CDB can dynamically update the terrain (such as a bomb crater) and have that dynamically updated terrain instantly served by the Geospatial Discovery Service to any OGC compliant system, such as Esri® ArcMap, QGIS, or a mobile web page. The underlying architecture and framework of the C-TGS provide a mechanism to move high-end simulation to the point where data sharing, crowd-sourcing, and dynamic terrain are in-sync with GIS tools and simulation system edits of the terrain repository.

Clause 1: CDB 2.X Key Concepts and High Level Architecture

2. Background

This section details the general architecture for CDB 2.0 and beyond. The CDB 2.0 architecture is the result of:

  • Discussions and lessons learned from prototyping activities in the SOFWERX Geospatial Series Tech Sprint II - OGC CDB 2.0 (aka CDB-X in the Sprint Engineering report). This activity was performed in support of Special Operations Forces (SOF) Future Concepts. The joint SOFWERX/OGC CDB X Conceptual Model with Prototyping Examples and Recommendations Discussion Paper details the work and recommendations developed during the sprint.

  • Ongoing discussions and decisions made in the OGC CDB Standards Working Group (SWG).

  • Lessons learned and documented in the OGC CDB Vector Data in GeoPackage Interoperability Experiment. This OGC Engineering Report (ER) documents the results of the CDB Vector Data in GeoPackage Interoperability Experiment (IE). The participants in this IE tested transforming CDB Shapefile vector data into one or more GeoPackage(s) and storing the result in a CDB data store. GeoPackage Version 1.2 and CDB Version 1.1 and related Best Practices were the standards baseline used for this experiment.

  • Work performed and documented in the OGC Testbed-13 CDB Engineering Report. This Engineering Report describes the conceptual model of an OGC CDB 1.0 datastore as a UML (Unified Modeling Language) diagram to show different datasets (the 3D models, vector features and coverages) structure. The ER also describes how to process and use a NAS-based Profile as a CDB feature/attribute data model or a GML-SF0 application schema. Finally the ER discusses how to access, navigate and visualize a CDB dataset using OGC web services (such as WFS and WCS).

3. Key Architecture Concepts

The following key architecture concepts are critical to understanding how to read the CDB 2.X Standard, understanding the CDB architecture and how to define implementable application profiles.

3.1. Analysis Ready Data (ARD)

Data that have been processed to a minimum set of requirements and organized into a form that allows immediate use with a minimum of additional user effort for further interoperability both through time and with other datasets. (source: CEOS http://ceos.org/document_management/Meetings/Plenary/30/Documents/5.5_CEOS-CARD4L-Description_v.22.docx). ARD is an abstract concept that can only be implemented in the context of a common domain of application. The CDB 1.x standard specifies how to structure, attribute, and curate geospatial (2d and 3d) data to make that data ready for the simulation domain of application.

Other characteristics of ARD include:

  • There is an effort made by the producer to reduce the need for pre-processing by integrating the necessary correction(s) in the product production chain. These corrections are based on the rules (requirements) for generating ARD.

  • Data are made available in easy-to-use formats. These are commonly known and well documented formats that are supported in multiple software products.

  • The product is well documented (metadata) at the product level as well as other levels (such as a layer).

In terms of the architecture, ARD fits well with the requirements specified in an application profile. An application profile of the CDB Core yprovides requirements for data content and structure for a given domain, such as simulation or tactical.

3.2. authoritative data

Officially recognized data that can be certified and is provided by an authoritative source.

(SOURCE: Authority and Authoritative Sources: Clarification of Terms and Concepts for Cadastral Data. FGDC/NIST 2008)

3.3. authoritative data source

An information technology (IT) term used by system designers to identify a system process that assures the veracity of data sources. These IT processes should be followed by all geospatial data providers. The data may be original or it may come from one or more external sources all of which are validated for quality and accuracy.

(SOURCE: Authority and Authoritative Sources: Clarification of Terms and Concepts for Cadastral Data. FGDC/NIST 2008)

3.4. CDB Core

The CDB Core consists of core requirements and corresponding conformance classes that any extension, application profile, or implementation of the CDB Standard shall be conformant with. For example, any implementation of an Application Profile (aka Profile) shall inherit and be dependent on the conformance classes as defined and implemented in the Core.

3.5. Conformance

OGC Standards specify requirements and requirements classes (See below). Conformance means that an implementation of an OGC standard, such as CDB-X, properly implements one or more requirements/requirement classes. Conformance can be tested.

3.6. Conformance Class

In this standard, the set of requirements tested by the conformance tests within a conformance class is a requirements class and its dependencies. Each optional requirement will be in a separate requirements class with other requirements that are part of the same option. Each requirements class corresponds to a separate conformance class.

3.7. Conformance Test

Test, abstract or real, of one or more requirements contained within a standard, or set of standard. Tests determine whether the requirement or set of related requirements was properly implemented. Below is an example of an Abstract Conformance test that could be physically implemented in a conformance test suite.

conformance class example

3.8. Core Requirement Class

Unique requirements class that must be satisfied by any conformant standardization targets associated to the standard. A core requirements class is one which is a dependency of all others. as a form of reference model for establishing core vocabularies and schemas for the entire specification. The core may contain the definition and schema of commonly used terms and data structures for use in other structures throughout the specification.

For example, a Coordinate Reference System core requirement class specifies requirements that shall be implemented in any instance, profile, and/or extension of the CDB-X standard. This means that any profile or profile with extensions of the CDB-X standard shall implement the core CRS requirements class.

3.9. Data Store

A data store is a repository for persistently storing and managing collections of data which include not just repositories such as databases, but also simpler store types such as simple files, metadata, models, etc.

3.10. Extension

Requirements class which has a direct dependency on another requirements class.

Note
 Here extension is defined on requirements class so that their implementation may be software extensions in a manner analogous to the extension relation between the requirements classes. A common mechanism to extend the functionality of a specification is to define extensions, which may be either local or encompass other standards. Specifications should use extensions where feasible, but should never hinder them.

3.11. Foundation Data

Authoritative data and models that have been curated and stored in a CDB repository. Foundation data uses known and agreed to controlled vocabularies for attribution, has been curated based on the requirements as stated in the CDB standard or some other authoritative source, and supported by required metadata.

For example, as per the current CDB standard (and industry best practice), a road network (RoadNetwork dataset in CDB 1.2) could be considered as foundation data. In CDB 1.2, there are a set of requirements associated with how the roads data are structured and attributed and stored in a CDB repository. The specification of any foundation data layer (such as RoadNetwork) at the logical model level can be 100% independent from the storage environment, end user use case(s) and so on while at the same time also having the requirements based on industry knowledge and use case requirements.

Any CDB 2.X foundation data requirements do not mention the actual storage structure, enabling software, storage formats, tiling structure, and so forth.

3.12. Profile

Specification or standard consisting of a set of references to one or more base standards and/or other profiles, and the identification of any chosen conformance test classes, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. [ISO/IEC TR 10000-1] In the usage of this standard, a profile will be a set of or extensions to requirements classes or conformance classes (either preexisting or locally defined) of the base standards.

In the CDB 2.0 Standard and later, the requirements and any related extensions are based on the use cases and interoperability requirements of a specific domain or information community. In the diagram below, some example Profiles are shown as labeled CDB-X Tactical, CDB-X Gaming, and CDB-X Simulation. All of these and any other defined profiles shall implement and be consistent with conformance classes as defined in the Core standard.

3.13. Requirement

Expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted [ISO Directives Part 2]

Note
 Each requirement is a normative criterion for a single type of standardization target. In this standard, requirements will be associated to conformance tests that can be used to prove compliance to the underlying criteria by the standardization target. Requirementsuse normative language and in particular are commands and use the imperative shall or similar imperative constructs. Statements in standards which are not requirements and need to be either conditional or future tense normally use will and should not be confused with requirements that use shall imperatively.

An example Requirement as used in this standard is:

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.

3.14. Requirements class

Aggregate of all requirement in a module that must all be satisfied to satisfy a conformance test class

An example Requirements Class as used in this standard is:

Requirements Class - Tile

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

Target type

Operations

Dependency

WGS-84 2d definition

Requirement 11

/req/core/tile-extent

Requirement 12

/req/core/tile-metadata

Requirement 13

/req/core/tile-size

3.15. standardization target

entity to which some requirements of a standard apply. (The Specification Model — A Standard for Modular specifications)

For the CDB Standard, the standardization target for the core would be any extension, application profile and implementation of a CDB data store conformant with the core. So, for example, the standardization target for an extension would be the core conformance class. Specifically, every requirements class in a standard shall have a standardization target type which is a subtype of that of the core and shall have the core as a direct dependency.

Note
 The standardization target is the entity which may receive a certificate of conformance for a requirements class.

4. Description of the High Level Architecture

The following figure presents a high level CDB X conceptual model. CDB X Architecture

4.1. Three tiered architecture

The CDB-X architecture is comprised of three primary tiers:

  • Tier 1 - Technology and Implementation Agnostic. This tier contains the components of the model that are technology, language, platform, vendor, and implementation agnostic. This tier is also heavily vested in existing a number of OGC, ISO, W3C, and IETF standards.

  • Tier 2 - Implementable and Use case/technology specific. This tier documents the components of the architecture that can be implemented.

  • Tier 3 - Implementation Specific details based on content (resource) type. This tier is comprised of model components that describe in detail the requirements and properties for utilizing specific content/resources in a CDB data store.

4.1.1. Tier 1

4.1.1.1. Foundation Conceptual Models and Abstract Foundation Standards (Sub-tier 1.1)

Tier 1 is comprised of four levels of abstraction. At the base level (Sub-tier 1.1) is a foundation consisting of a number of OGC Abstract Specifications, ISO TC 211 91xxx series International Standards, and standards from other Standards Development Organization such as the W3C and the IETF.

The OGC Abstract Specification and ISO 19xxx Standards provide the conceptual foundation for OGC standards development activities. They also provide a conceptual (abstract) foundation for many other geospatial standards development activities in the IETF, W3C, OASIS, and a large number of government organizations. Open interfaces and protocols can be designed, built, and referenced against the Abstract Specification, thus enabling interoperability between different platforms, applications, and different spatial processing systems. The Abstract Specification provides a reference model for the development of standards that can be implemented, such as CDB-X.

The following OGC and ISO Abstract Standards provide key components of the foundation for the CDB-X conceptual architecture, logical models, and subsequent detailed implementation requirements and conformance classes.

  1. Topic 2: Referencing by coordinates (aka ISO/DIS 19111:2018): This document defines the conceptual schema for the description of referencing by coordinates. It describes the minimum data required to define coordinate reference systems. All Coordinate and Coordinate Reference System requirements and terms and definitions specified in CDB-X are based on this OGC Abstract Specification.

  2. Topic 1: "Features and geometry – Part 1: Feature models" describes how geographic information in datasets and databases using a "feature model" are structured, created, stored, queried and manipulated.Topic 1 (an earlier version) is the basis for the OGC Simple Features Standard. Simple features is an OGC implementation standard that is the basis for many other standards, such as GeoJSON and the GeoPackage vector storage model.

  3. Topic 6: Topic 6 - Schema for coverage geometry and functions (aka ISO 19123) defines a conceptual schema for the spatial characteristics of coverages. Coverages support mapping from a spatial, temporal or spatiotemporal domain to feature attribute values where feature attribute types are common to all geographic positions within the domain. A coverage domain consists of a collection of direct positions in a coordinate space that may be defined in terms of up to three spatial dimensions as well as a temporal dimension.

  4. Topic 22: OGC Abstract Specification Topic 22 - Core Tiling Conceptual and Logical Models for 2D Euclidean Space Describes 1.) a conceptual model for tiling space in any dimension and 2) A logical model for 2D tiled structures and by extension tiling. The logical model is based on the conceptual model.

4.1.1.2. Tier 1 Logical Model (Sub-tier 1.2)

The CDB Logical Model describes the core elements and required implementation rules for the CDB Standard. Terms and definitions, semantics, concepts and other elements of the CDB logical model are primarily based on the conceptual models defined in the abstract standards described in Sub-tier 1.1.

For example, the OGC Topic 2: Referencing by coordinates Standard provides an extensive vocabulary for terms and definitions used in referencing. These terms and definitions are included by reference as normative in the CDB Standard. Topic 2 also defines:

  1. Two classes of conformance for relating coordinates to coordinate metadata; and

  2. Twenty six classes of conformance for the definition of a coordinate reference system (CRS) or of a coordinate operation.

These conformance classes provide the basis for all Coordinate Reference System (CRS) requirements and conformance clauses specified in the CDB standard. These classes along with the requirements specified in the WKT for CRS Standard are the basis for all CRS requirements specified in every OGC Standard that specifies the use of a CRS.

More on this is the Sub-tier 1.4 discussion.

4.1.1.3. Tier 1 CDB Metadata, Controlled Vocabularies, and Metadata Files (Sub-tier 1.3)

A critical aspect of developing, curating, maintaining, and using a CDB data store in a well known, interoperable manner is the definition and use of metadata. In CDB, the term metadata is often used in a much broader context than just "data about data". Metadata in a CDB data store is comprised by "traditional" metadata such as the author of a dataset, controlled vocabularies such as country names and codes, and enumerations such as months of the year.

In the CDB standard, a single metadata standard is not specified as mandatory for encoding of metadata. The CDB-X standard allows for a number of metadata standards to be used. However, the CDB-X standard does specifiy that all data sets shall have a minimum set of metadata.

The three main types of metadata utilized in a CDB data store are now defined.

4.1.2. Metadata

Metadata is data that provides information about other data. 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 (National Information Standards Organization (NISO)).

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

4.1.2.1. Tier 1 Implementation Standards (Sub-tier 1.4)

In this Tier 1 sub-tier of the architecture:

  1. Elements of existing OGC Implementation Standards, such as the Two Dimensional Tile Matrix Set Standard are specified as components of the CDB-X Core Standard. In other words, such as with the case of tiling, the rules specified in the Core are applicable to all use cases, extensions, information domains, or profiles of the Core.

  2. Specific guidance and requirements are specified for characteristics such as attribution that are not currently specified in an existing Implementation Standard. These characteristics are independent of use cases, domains, or profiles. In other words, the attribution rules specified in the Core are applicable to all use cases and information communities.

An important note is that even though specific standards are specified in this sub-tier, the architecture remains agnostic as to data formats, operating platforms, encodings, physical models, and so forth.

4.1.3. Tier 2 - Implementable requirements and conformance classes

In Tier 2 of the architecture, specific implementable requirements are specifed as part of the CDB Core. An example of implementable requirements are those that specifically describe the CDB Tiling structure. The Tiling structure in the CDB 1.x series of standards is well defined and widely implemented in the CDB community. However, the CDB tiling structure is not specifically tied to or consistent with international standards. Further, a number of issues have been documented over the years of CDB use. At the same time as recommended in the SOFWERX CDB Sprint, the CDB-X tiling scheme must enable a "relatively" easy migration path from the CDB 1.1/1.2 tiling/LoD structure into the CDB-X structure.

4.1.3.1. Tier Two Tiling Example

Continuing with the Tiling example, a number of design criteria were identified in the SOFWERX CDB Sprint:

  • Use metadata for whole datasets that describe basic information about the tile scheme as well as how data layers are regrouped (LOD grouping and data layer grouping).

  • Provide for fewer top level tiles than in OGC CDB 1.x.

  • Store imagery in a container according to the tiling scheme specified.

  • Store coverage data in the container according to the tiling scheme specified in CDB-X. Suggested coverage types based on current CDB standard and user specified requirements: (Ellipsoidal body surface): Elevation models, visual and non-visual (multi-spectral) imagery, terrain light maps (emissive at night), and raster materials (for non-visual sensors). Should be extensible to support other types.

  • Coordinate Reference System is WGS 84 with epoch encoding (same as current CDB Standard except for epoch).

  • Need to keep the various encodings that CDB 1.x already has:

    • Elevation compression encodings (use of scaled integers vs floating point for smaller data sizes).

    • Elevation grids that are adjustable (better terrain fidelity at lower LODs/zoom levels)

    • Raster Material encodings using multiple coverage layers.

    • Use Imagery Compression (Imagery is typically the largest layer in CDB by disk storage).

More specifically, an example of a requirement based on the above design requirements and experience in the CDB Sprint might be:

Requirement 8

req/CDB/2.0/core/variablematrixwidth/model

Dependency

WGS-84 2d definition

Dependency

Two Dimensional Tile Matrix Set

Req

When a tiled resource or dataset has variable width tiles, the resource or dataset shall define the variable matrix width in a tile matrix set 2D using a variablematrixwidth data structure. This will result in the following UML model shown in Figure <TBD> and model description in Table Example.

The complete set of tiling requirements would be captured and documented in a tiling requirements class. There would also then be an associated conformance class documented in the Abstract Test Suite (Annex A of any OGC Standard). The Tiling Conformance class would be specified as a Core conformance class which means that any CDB conformant implementation shall implement either the Tiling Conformance Class as defined or a profile of that Conformance Class.

4.1.4. Tier 3

In this Tier, requirements related to specific categories of data content are specified. Many of the data content requirements specified in the current CDB 1.x Standards could be moved directly to CDB-X. Another characteristic of Tier 3 requirements is that they may or may not be in the core. This is because there is currently no requirement that a CDB data store implement any of the data content types detailed in the CDB 1.x Standard. An example is the current Volume 6: OGC CDB Rules for Encoding Data using OpenFlight

That said, there are also data content requirements that are specified in the Core. These are requirements for such elements as file naming. An example is provided below.

Another characteristic of the CDB-X Tier 3 is the role of metadata. Unlike the current CDB 1.X Standard, there is no mandatory requirement for metadata at the data content storage level. In CDB-X, metadata is only recommended. In CDB-X, a minimal set of metadata is mandatory for any dataset in a CDB data store.

4.1.4.1. Tier 3 Content Requirement Example

The following requirement is extracted from the current CDB 1.2 Standard (Volume 1). This requirement may or may not eixist in the CDB-X Core. However, requirements such as this (and related conformance classes) will be specified in the CORE.

Requirement 107 Vector Type

http://www.opengis.net/spec/cdb/2.0/vector-type-rule

All instances of the feature SHALL be of the same vector data type. The CDB standard requires a maximum of one vector data type for point features, a maximum of one type for lineal features and a maximum of one type for polygon features for each tile (for a maximum of 3 feature vector files per tile).
Note
 The above is an example only!!

5. CDB Application Profiles

Note
 The use of the term "Profile" here should probably be changed as this usage is not consistent with the OGC/ISO definition. This should be a discussion topic. I would suggest a better term is Application Profile or Domain Profile.

The SOFWERX/SOCOM CDB Sprint participants identified four application areas: CDB-Tactical, CDB-Simulation, CDB-Gaming and CDB-Analytics. These 4 application areas, as stated in the CDB-X Engineering Report, shall correlate to the data defined in CDB-Foundation. CDB-Foundation is the CDB-X Core as defined in this document.

The CDB-X Core and Content requirements do not specify what conformance classes (or profiles) and/or what extensions are required to meet the use cases and needs for a specific application domain or information community. An application domain is the segment of reality for which a standard(s) and related software system is developed. The definition of an application domain is the starting point for the actual-state analysis and the creation of a domain model. The domain model is a conceptual model of the domain that incorporates both behavior and data. In ontology engineering, a domain model is a formal representation of a knowledge domain with concepts, roles, datatypes, individuals, and rules, typically grounded in description logic.

In the CDB-X context, this means that each application area (aka Profile in the Sprint Engineering Report):

  1. Clearly specifies which Core requirements (and conformance classes) or profiles thereof are mandatory for that Application Profile.

  2. Clearly states which data content requirements (and conformance classes) or profiles thereof are mandatory for that Application Profile.

  3. Clearly defines and documents any required extensions necessary to meet the requirements of a particular application domain.

Note
 This note clarifies how specifying a core enhances interoperability. First all application profiles shall implement the Core or profiles of the Core. The Core specifies core requirements/conformance classes that shall be implemented in ALL application profiles. An Application Profile may restrict a given requirements and related conformance class. For example, the CDB standard may specify a requirement that OGC WKT for CRS shall be used to specify any CRS information. A profile could restrict that requirement by stating that only WGS 84 2D as specified in EPSG code 4326 shall be used. (Of course the SWG may decide that only WGS 84 shall be used in any CDB data store!). Also remember that the Core not only specifies implementation requirements such as for Tiling, the Core also specifies requirements - as done the current CDB standard - for both characteristics of data types as well as for specific data themes. An example of a specific data theme is Navigation. An example of requirements for the characteristics of a general data type are the requirements and conformance classes for Tiled Elevation Data as specified in the current CDB 1.x standard. As such, for example, any Application Profile that implements elevation data shall do so based on the specified requirements. The net result is interoperability regardless of the Application Profile used.

6. Conformance

This CDB Core standard defines an Abstract Test Suite in Annex A.

The standardization target type for all Core requirements modules and requirements is a CDB Datastore.

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.

The CDB Core is comprised of a set of requirements modules. Each requirements module specifies requirements and recommendations that an implementation of a CDB Application Profile may have to implement. There is a corresponding conformance class for each requirements module.

The CDB Core does not mandate a specific encoding or format for representing any content.

7. References

Normative References

Note
 Also please see the Bibliography in this CDB volume for a complete list of all normative and informative references.

8. Terms and Definitions

The following are terms and definitions used in the CDB standard.

Note
 These terms and definitions are an almost exact copy of those used in the CDB 1.x series of standards. To find additional key terms and concepts, please visit CDB 2.X Key Concepts and High Level Architecture

Term

Description

A

Aliasing

Spatial and/or temporal image defects or artifacts in a raster image. They are due to interaction between the discrete sampling of the raster format and the spatial and temporal frequencies inherent in the computed image of edges, surfaces and point features. Manifestation of spatial aliasing includes edge stair-stepping and crawling, scintillation of narrow surfaces, break-up of long, narrow surfaces and positional or angular motion of scene edges in discrete steps. Temporal aliasing includes double image and loss of dynamic image integrity due to the human eye’s ability to dynamically track individual fields at certain angular rates of motion.

Ambient Illumination

See Illumination, Ambient.

Anti-aliasing

Active image processing techniques that reduce the perception of the aliasing phenomena.

AO1

Angle of Orientation with greater than 1 degree resolution. The angular distance measured from true north (0 deg) clockwise to the major (Y) axis of the feature.

Areal Feature

See Feature, Areal and Polygon

Articulated Part

A child part of a model (usually a moving model) that is allowed some degree of motion with respect to the parent body of the model. Examples of articulated parts include tank turrets, refueling drogues, and helicopter rotor blades.

Arithmetic Logic Unit

An arithmetic logic unit (ALU) is a digital circuit used to perform arithmetic and logic operations. It represents the fundamental building block of the central processing unit (CPU) of a computer. Modern CPUs contain very powerful and complex

B

Background Area

See Area, Background.

Base Material

See Material, Base.

Base Material Table

(BMT)

A data structure that contains a description of the Base Materials available to the CDB. There is only one BMT per CDB. Each entry in the BMT corresponds to a Base Material; the entry associates a name to the Base Material.

C

CDB device

A device that can directly input synthetic environment data that conforms to the format, structure and conventions of this standard. A device need not input and process all of the CDB datasets and attributes to be CDB-compliant.

CDB simulator

A simulator whose client-devices can input synthetic environment data that conforms to the format, structure and conventions of the CDB standard. Any subsystem or client-device that does not natively conform to this standard requires that CDB data be formatted and structured to the device’s native format and structure through the use of a runtime publisher. A simulator need not input and process all of the CDB datasets and attributes to be CDB-compliant.

CDB Translator

An off-line software process that translates an environmental database from its toolset-native format(s) into one of the CDB specified formats.

NOTE: The CDB data formats are based on industry standard tool formats; as a result a translation to the formats prescribed by this standard may not be required.

CDB Server

Gateway platform to CDB mass storage and applicable infrastructure. CDB compliant servers access, filter and distribute CDB data in response to requests from the Database Generation Facility (DBGF) and the client-devices (or their runtime publishers).

CDB Geocell (tile)

Region of the earth, aligned to lines of latitude and longitude in accordance with Section 2.1 CDB Core (Volume 1). The size of a CDB Geocell per Zone is also specified in the Core CDB Standard section 2.1. Also known as DGGS Cell.

Channel

A field of view segment within a visual system’s total viewing field for which a corresponding unique scene segment is calculated and presented.

Client application

A software application that requires a complete or partial synthetic representation of the world. CDB applications may require a CDB runtime publisher to convert the CDB compliant database into a form it can directly input. Used interchangeably with “Client-device” in this standard.

Client-device

Simulation subsystems (Image Generators (IGs), Radar, Weather Server, Computer Generated Forces (CGF) Terrain Server, etc.) that require a complete or partial synthetic representation of the world. A CDB client-device may require a CDB runtime publisher to convert the CDB data into a form it can ingest.

Coordinate

One of a sequence of n-numbers designating the position of a point (see point) in n-dimensional space.

NOTE In a coordinate reference system, the numbers shall be qualified by units. [adapted from ISO 19111]

Coordinate Conversion

coordinate operation in which both coordinate reference systems are based on the same datum

Coordinate Reference System

Coordinate system that is related to an object by a datum

NOTE For geodetic and vertical datums, the object will be the Earth. [ISO 19111:2007]

Coordinate System

Set of mathematical rules for specifying how coordinates are to be assigned to points (ISO 19111).

Composite Material

See Material, Composite.

Composite Material Table

A data structure that contains a description of the Composite Materials available in a CDB tile or on a model. Each entry in the CMT corresponds to a Composite Material.

Coordinate System, Geographic

A geographic coordinate system (GCS) uses a three-dimensional spherical surface to define locations on the earth. A GCS is often incorrectly called a datum, but a datum is only one part of a GCS. A GCS includes an angular unit of measure, a prime meridian, and a datum (based on a spheroid).A common choice of coordinates is latitude, longitude and elevation (or altitude). For the CDB, the reference data is based on the WGS-84 ellipsoid, i.e., geographical latitude j and longitude l are the angles of the normal on the WGS-84 reference ellipsoid along the point to the equator and zero meridian. The angles are given as degrees, minutes and seconds. Altitude is the distance above and normal to the ellipsoid in meters. The WGS-84 ellipsoidal earth models provides for accurate calculations over long distances on the earth’s surface.

Correlation, Algorithmic

The degree of informational consistency between the outputs of two or more devices with equivalent Arithmetic Logic Units, each submitted to the same input data. (e.g., consider two devices meshing terrain from a regular grid of elevation points, one using a regular mesh of right-handed triangles using the elevation points as vertices, and the other with a DeLauney triangulated mesh derived from the grid of elevation points).

Correlation, Numerical

The degree of informational consistency between the outputs of two or more devices, each submitted to the same input data, (e.g., two devices computing the sine of an angle, one with a series of 10 terms, and another with an interpolation of a look-up table with 100 entries, or one device using 32-bit signed integers for its internal computations and the other using single-precision floats). The CDB Standard addresses Runtime Source Database numerical accuracy correlation errors because a single representation is used for each data set.

Correlation, Parametric

The degree of informational consistency between the outputs of two or more devices, each submitted to the same input data but to different control parameters (e.g., consider two devices generating regular meshes of right-handed triangles based on a regular grids of elevation points organized by Level-of-Detail (LOD), one using an LOD meshing tolerance parameter of 1m and the other 2m).

Correlation, Raw Source DB

The degree of informational consistency between two or more sets of raw data[2] (i.e., inputs to a modeling station) representing aspects of the same environment (for instance, the correlation errors arising from Digital Terrain Elevation Data (DTED) elevation data that does not perfectly match the satellite raster imagery due to oblique view distortions induced by the satellite). Correlation errors are intrinsic to the process of gathering data because there is no means to gather all of the required data from a single device, at a single instant in time. Instead, datasets (e.g., elevation, raster imagery, geometry) are each gathered from various devices of various types, at different times, etc. As a result, this process inherently introduces (raw source) correlation errors.

Correlation, Runtime DB

The degree of informational consistency between two or more runtime databases representing the same synthetic environment. The CDB standard eliminates database correlation errors since only one database is used to represent the same synthetic environment. A runtime database is a device-loadable database format that can be processed by a target device. The CDB Standard defines a format that can be entered in runtime by client-devices that conform to the CDB standard. By definition, the CDB Standard addresses all runtime database-level correlation errors.

Correlation, Source DB

The degree of informational consistency between the internal datasets of a source database produced by a DB generation toolset. To a large extent, the effort expended by a modeler at their DB workstation consists in eliminating (or at least reducing) correlation errors arising from miss-correlated raw source data.

Culture

See Feature, Cultural.

Culture, 2D

Short for 2D Cultural Feature. The 2D representation of a man-made or natural object (such as a road, a runway, a forest canopy), conformed to the terrain.

Culture, 3D

Short for 3D Cultural Feature. The 3D representation of erect man-made or natural object (such as buildings, trees, towers) positioned on top of and usually conformed to the terrain.

D

Data Dictionary

A data dictionary is a collection of descriptions of the data objects or items in a data model for the benefit of programmers and others who need to refer to them. See http://searchsoa.techtarget.com/definition/data-dictionary

Data Duplication

Data logically representing the same information, copied one or more times within a complex data structure. The CDB Standard eliminates all duplication of data, i.e., the data appears once and only once within the CDB structure.

Data Normalization

Data normalization is the process of reducing data to its canonical form. For instance, Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency.

Data Redundancy

Information in the form of data that can readily be derived (within the limits of technological/cost reasonability) and re-formatted, or re-derived from other data.

Dataset

A collection of data, published or curated by a single agent, and available for access or download in one or more representations.
SOURCE: DCAT
NOTE: In modelling and simulation, an organized group of related environmental data that cannot be broken down into a smaller set used to describe a synthetic environment element of the world.

Database Fidelity

Reflects the amount and type of synthetic environmental data needed by client-devices to simulate real-world environmental data with greater fidelity. Consider for instance a simulator client-device capable of supporting a single-surface earth skin representation versus one capable of representing a multi-surface earth skin that represent tunnels, bathymetric data, location-dependent tide heights, etc.

Database Assembly

In many database tools, the generation of the terrain plays a pivotal role in the database assembly process because all of the cultural features are conformed and constrained to the terrain representation and structure. Most client-devices in existence today have interdependent terrain geometry, raster imagery and culture; as a result of this, most tools in use today resolve these inter-dependencies during this critical and computationally expensive database assembly step.

Database Generation Facility (DBGF)

A geographically co-located group of workstation(s), computer platforms, input devices (digitizing tablets, etc.), output devices (stereo viewers, etc.), modeling software, visualization software, CDB Server, CDB off-line publishing software and any other associated software and hardware used for the development/modification of the CDB. The DBGF is used for the purpose of CDB creation and CDB updates. Each workstation is equipped with one or more specialized tools. The tool suite provides the means to generate and manipulate the synthetic environment.

Database Generation Timeline

Elapsed time from availability of Environmental DB requirements (geographic extent, fidelity, resolution, etc.) to availability of a compliant runtime Environmental DB, ready for use on all client-devices of a simulator.

Database Publishing

A process (either off-line[3] or on-line) where all of differences between the tool-native representation and the client-device internal representation of the synthetic environment database are resolved. During this step, the publisher transforms the assembled database so that it satisfies the client-device’s:

  • internal formats

  • internal data structure and organization

  • internal naming conventions

  • internal precision and number representation

  • data fidelity requirements (typically parameters that match the client-device algorithms)

  • performance limitations

  • level-of-detail representation and conventions

3. When applied as an off-line process, the term “compilation” is often used instead.

Database Publishing, Offline

The process of performing the steps listed above in Database Publishing, and then storing the result in a distinct SE database for each client-device. (Note that the stored databases are different for each client-device type and each vendor type). In many cases, the published databases are proprietary.

Database Publishing, Online

The process of performing the steps listed above in Database Publishing, on-the-fly, based on paging requests of a client-device. Since the publishing is performed on-demand, it exists only momentarily in memory; it is not stored on disk.

Database Resolution

Informational density (for instance, the number of elevation values per km2, pixels per km2, polygons per km2) of a modeled dataset.

Data Precision

Corresponds to the numerical precision (i.e., number of bits allocated) used to represent a unit.

Data store

A repository for persistently storing and managing collections of data which include not just repositories such as databases, but also simpler store types such as simple files, emails, images, models, etc.

Datum

Parameter or set of parameters that define the position of the origin, the scale, and the orientation of a coordinate system.

Deformation

Refers to the change in size, shape or other metric property of a body. If all the particles that comprise the body move without producing a change in the size or shape of the body, this is called rigid body motion. However, if the size or shape of the body changes, this is called deformation.

Depth

Height below the reference surface will have a negative value, which would embrace both gravity-related heights and ellipsoidal heights.

DGIWG

Defense Geographic Information Working Group

DGGS

Discrete Global Grid System: spatial reference system that uses a hierarchical tessellation of cells to partition and address the globe. “cell” aka “tile” or ”geocell”

Directional Illumination

See Illumination, Directional.

Displacement

The change in the position (or location) of a point in a frame of reference as a function of time. For a body, displacement refers to the sum of rigid body rotation and strain.

DIS

Distributed Interactive Simulations [IEEE Std 1278TM]

E

Elevation

Synonym for “height”

Environmental Data Coding Specification

An Environmental Data Coding Specification provides a mechanism to specify the environmental "things" that a particular data model is intended to represent. That is, a feature such as building could be represented alternatively as a Man-made Point Feature, a Radar RCS polar diagram or as an OpenFlight model, or some combination of these. The representation of these is chosen by the data modeler and is orthogonal to the semantic of the "thing" that is represented (and its location). The provision of such a "thing" results in a shared understanding of "what the thing is and what it potentially means" to all participating applications.

Environmental Data Representation Model

A data representation model (EDRM) is a description used to provide identification of all environmental data elements within a system, including their attributes and the logical relationships between data elements.

Environmental DB, Runtime

A device-loadable database format that can be processed by a target device. The CDB Standard defines a format that can be entered in runtime by simulator client-devices that conform to the CDB Standard.

Eyepoint

A single point (monocular) location of the observer’s eye relative to a scene representation. Usually a point within the cockpit of the simulated aircraft or vehicle.

Eyepoint, Pilot

The normal eyepoint position when the pilot’s seat is adjusted properly for flying the aircraft. Defined by the aircraft manufacturer for each pilot seating position. The eyepoint(s) for which the display design is normally optimized and typically used for display testing purposes.

F

FDD

Feature Data Dictionary

Feature

Abstraction of real world phenomena

NOTE A feature may occur as a type or an instance. Feature type or feature instance is used when only one is meant. [adapted from ISO 19101]

Feature, Areal (aka polygon)

A representation of closed area-oriented features conformed relative to the terrain such as forested areas, fields. The information includes areal feature type identification, location, orientation, 2D geometry, connectivity, attribution and other surface characteristics relevant to simulation.

Feature, Cultural

Human made (constructed) point, lineal and areal features.

Feature, Lineal (previously Feature, Linear)

A geographic feature that can be represented by a line or set of lines. For example, rivers, roads within a pizza delivery area, and electric and telecommunication networks are all lineal features. The information includes lineal feature type identification, location, orientation, geometry, connectivity, attribution and other surface characteristics relevant to simulation. See also LineString

Feature, Point

See Point below. Specifically, in CDB, the representation of a single location in space or on the earth’s surface. A Point Feature consists of a single <latitude, longitude> coordinate with or without an elevation and related properties such as feature type and orientation.

Flat Earth

Jargon used in simulation community to signify the projection of the earth ellipsoid onto a flat surface. The flat Earth approximation retains terrain relief but eliminates the effects of Earth surface curvature. If you stay in the vicinity of a given fixed point, it may be a good enough approximation to consider the earth as "flat", and use a North, East, Down rectangular coordinate system with origin at the fixed point.

FOM

Federation Object Model

FOV, Field of View

The horizontal and vertical subtended angles from a designated eyepoint to the boundaries of a visual system channel (channel FOV) or all channels (system FOV).

G

Geocell

Short form for geographic cell. Synonymous with a single tile in the CDB tiled structure. A 1o of latitude by 1 o of longitude area on the surface of the earth. At the equator, this corresponds to an area of approximately of 111,319m × 111,319m. (See also CDB Geocell).

Geodetic Datum

datum describing the relationship of a two- or three-dimensional coordinate system to the Earth (ISO 19111)

Geographic Extent

An earth surface area that has been modeled.

Geographic Projection

coordinate conversion from an ellipsoidal coordinate system to a plane

Geometric Primitive

Geometric object representing a single, connected, homogeneous element of space. [ISO 19107]

Geospecific Model

A model is said to be geospecific if it is instanced once and only once within a CDB. Geospecific models usually correspond to unique (in either shape, size, texture, materials or attribution), man-made, real-world 3D cultural features.

Geotypical Model

A model is said to be geotypical if it instanced multiple times within a CDB data store. Geotypical models correspond to representative (in shape, size, texture, materials and attribution) models of real-world manmade or natural 3D cultural features.

Grid

This is a grid network composed of two or more sets of curves in which the members of each set intersect the members of the other sets in an algorithmic way NOTE The curves partition a space into grid cells.. [ISO 19123:2007]

Grid point

Point located at the intersection of two or more curves in a grid

H

Height

Distance of a point from a chosen reference surface measured upward along a line perpendicular to that surface. [ISO 19111] Note 1 to entry: A height below the reference surface will have a negative value, which would embrace both gravity-related heights and ellipsoidal heights.

HLS

High Level Architecture [IEEE Std 1516TM]

I

Illumination

One or more sources of illumination for the objects in the scene, such as daylight, twilight, landing lights.

Illumination, ambient

The non-directional component of illumination for the scene. Daylight, twilight and moonlight have ambient components over the entire scene. Landing lights typically provide ambient-type illumination over a limited area of the scene.

Illumination,

Directional

Scene illumination provided by an illumination source at a particular position or direction in the environmental database spatial frame. The effect on object luminance depends on the angle between the illumination source and object surface normal.

Imagery

A likeness or presentation of any natural or manmade feature or related object of activity and the positional data acquired at the same time the likeness or representation was acquired. (NSG Geospatial Core Metadata Profile)

J

K

L

Latency

The time interval from a request to a prescribed response from the targeted device.

Level-of-Detail (LOD)

Representations of the same thing that differ only in the amount of fidelity. An LOD is said to be coarse if it contains little detail or fine if it contains considerable detail.

Light Point

A database element used to model a point source of light (e.g., a taxiway lights, street lights, collision lights).

Light String

A group of lights, usually a series of light points sharing common spacing characteristics and are of a common type.

Lineal (Linear) Feature

See Feature, Lineal.

LineString

Curve composed of straight-line segments (ISO 19107)

Local Vertical Spatial Frame

See Spatial Frame, Local Vertical.

M

Material

Shorthand for either Base Material or Composite Material.

Material, Base

Symbolic representation of a basic material in the CDB. Basic materials are inputs to production or manufacturing processes. They are often raw, that is unprocessed, but are sometimes processed before being used in more advanced production processes. Basic materials represent the substances out of which a thing is or can be made. Examples are materials such as steel, aluminum, copper, sand, soil, stone, glass, concrete, wood, water, rubber. Base materials are chosen for their relevance to simulation.

Material, Composite

A symbolic representation that corresponds to a composite material that is made up of a primary substrate and one or more secondary substrates. Each substrate is composed of one or more base materials entries. The substrates can each be assigned a thickness.

Metadata

Data about data. Metadata describes how and when and by whom a particular set of data was collected. This is often referred to as “provenance”. Metadata may also define how the data is formatted.

Metadata element

Discrete unit of metadata. (NSG Geospatial Core Metadata Profile)

Mission Functions

A set of low-level simulator query functions performed on the synthetic environment, including such functions as Height Above Terrain (HAT), Height Above Culture (HAC), Collision Detection (CD), Line-Of-Sight (LOS), Laser Range Finder (LRF), etc.

*Model *

A term which stands for the 2D or 3D representation of features (exclusive of the terrain and/or bathymetry itself) within the synthetic environment database. Models can be statically positioned on the terrain (i.e., a cultural feature), or they are freely moving (i.e., a moving model). Models are often a 3D representation of a man-made or a natural object positioned and conformed relative to the terrain. The information includes its geometry, articulations, raster imagery (texture, normal map, light map, etc.), lighting systems, and other characteristics relevant to simulation.

Model, 2D

Refers to the modeled representations of 2D features; i.e., lineal or areal features that have no significant height with respect to the underlying terrain; 2D Models generally conform to the terrain profile.

Model, 3D

Refers to the modeled representation of 3D features that can be readily distinguished from the underlying terrain. In the case where they are unique, they are referred to as GSModels. In the case where they are instanced, they are referred to as GTModels. 3DModels capable of movement are called MModels. In the case where MModels are positioned by the modeler, they are called statically-positioned MModels.

*Model, Cultural *

A model that is statically positioned on the terrain or bathymetry skin. Cultural models are often a 3D representation of a man-made or a natural object positioned and conformed relative to the terrain. The information includes its geometry, articulations, raster imagery (texture, normal map, light map, etc.), lighting systems, and other characteristics relevant to simulation.

Model, GS

The geospecific representation of a cultural feature that is unique within the CDB.

Model, GT

The geotypical representation of a cultural feature that can be reused several times throughout the CDB.

*Model, Moving *

A model that is not fixed at one location in the synthetic environment database. The simulation host can update the position and orientation of a moving model at every simulation iteration cycle. A moving model is a 3D representation of manmade and natural objects free to move.

Model-LOD

Refers to a specific level of detail of the modeled representation of a feature; a general term encompassing both 2D and 3D Model-LOD

Model-LOD, 2D

Refers to a specific level of detail of a 2D model.

Model-LOD, 3D

Refers to a specific level of detail of a 3D model.

Modeler

The person who creates and assembles a synthetic environment database.

Multipatch

A multipatch can be viewed as a container for a collection of geometries that represent 3D surfaces.

N

Navigational Data

Is a representation of ARINC-424 and DAFIF data in the form of NAVAIDs (VHF, ILS/MLS, NDB, Markers), Communications Stations, Airport/Heliport (including SIDs, STARs, Terminal Procedure/Approaches, Gates), Runway/Helipad, Waypoints, Routes, Holding Patterns, Airways and Airspace.

Normal Vector

A vector of unit length perpendicular to a surface.

Numerical Correlation

See Correlation, Numerical.

O

Ownship

The vehicle (aircraft, ship, tank, etc.) being simulated.

OTW

Out the Window

P

Parametric Correlation

See Correlation, Parametric.

Pilot Eyepoint

See Eyepoint, Pilot.

Point

topological 0-dimensional geometric primitive, representing a position (ISO 19107)

PointM

A 2d Point consisting of a pair of double-precision coordinates in the order X, Y, plus a measure M.

PointZ

0-dimensional geometric primitive, representing a position (ISO 19107) with a Z value.

Point Feature

See Feature, Point.

Polygon

Planar surface defined by 1 exterior boundary and 0 or more interior boundaries. (ISO 19107)

PolygonM

A 2d Polygon consisting of a number of rings. A ring is a closed, non-self-intersecting loop. Note that intersections are calculated in XY space, not in XYM space. A PolygonM may contain multiple outer rings. The rings of a PolygonM are referred to as its parts.

PolygonZ

A Polygon in which each vertex (coordinate) has an associated Z value.

Polyline

A polyline is a connected sequence of line segments created as a single object. You can create straight line segments, arc segments, or a combination of the two.

PolylineM

A 2d polyline consisting of one or more parts.

PolylineZ

A Polyline in which each vertex (coordinate) has an associated Z value.

Q

R

Raster

In general, usually rectangular pattern of parallel scanning lines forming or corresponding to the display on a cathode ray tube. In the GIS community and in its simplest form, a raster consists of a matrix of cells (or pixels) organized into rows and columns (or a grid) where each cell contains a value representing information

Raw Source

A term generally used to describe the data imported into the database generation workstation for the purpose of off-line assembling and building the synthetic environment. The level of pre-processing applied to the source may vary considerably (from raw data directly from sensors such as unprocessed satellite raster imagery or photos to data directly usable by simulator client-devices). Source data need not be in digital form (e.g., photos).

Raw Source DB Correlation

See Correlation, Raw Source DB.

Regular grid

Grid whose grid lines have a constant distance along each grid axis

Runtime Publisher

A real-time software process (either shared or dedicated to a computer platform) that a simulation application client-device uses to transform or translate CDB data into a format that can be directly input by the client-device it serves.

Runtime DB Correlation

See Correlation, Runtime DB.

S

Sensor Environmental Model (SEM)

A simulation of the synthetic environment over a portion of the electromagnetic spectrum that is relevant to a client-device. A SEM is usually based on mathematical model of the environment for the portion of the electromagnetic spectrum of interest.

Sensor Simulation Model (SSM)

A simulation of a real-world sensor over a portion of the electromagnetic spectrum that is relevant to the sensor being simulated. A SSM is usually based on mathematical model of the real-world sensor for the portion of the electromagnetic spectrum of interest.

Simulator CDB Repository

The simulator CDB repository consists of a mass storage system (typically a storage array) and its associated network infrastructure. It is connected to the UMC (primarily for update purposes) and the CDB Servers (for simulator client-device runtime access).

Source DB Correlation

See Correlation, Source DB.

Synthetic Environment Generation

Synthesis of multiple source inputs to generate the required integrated environmental representation

T

Target Area of Interest

The geographical area where high value targets can be acquired and engaged by friendly forces

Terrain

A representation of earth surface shape/elevation, raster imagery, surface attribution and other earth surface characteristics relevant to simulation. Also includes bodies of water such as oceans, lakes.

Terrain Profile

See Terrain.

Terrain Skin

See Terrain.

U

UHRB

Ultra-High Resolution Building

V

Vector data

Data that represents geographic data through the use of constructive geometric primitives such as points, lines, and polygons.

Viewpoint

The viewpoint is the position from which the synthetic environment database is being observed.

W

X

Y

Z

0-9

2D Feature

See Culture, 2D.

2D Model

See Model, 2D

2D Model-LOD

See Model-LOD, 2D

3D Feature

See Culture, 3D.

3D Model

See Model, 3D

3D Model-LOD

See Model-LOD, 3D

9. Conventions

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

9.1. Standards Document Terms

Many of the terms used in the CDB Standard, such as requirement and requirements class, are used to ensure that any OGC Standards document is specified as clearly and unambiguously as possible. For example, a requirement is an "expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted". The standards terms are defined in the OGC Specification Model — A Standard for Modular specifications [OGC-08-131r3]

As many readers of this standard may not be familiar with the OGC Modular Specification, some key terms and definitions from that policy standard used in the CDB Standard are provided here.

conformance test: set of conformance tests that must be applied to be considered conformant. Typically each stated requirements class will have a related confomrance class.

core requirements class: one of more unique requirements classes that must be satisfied by any conformant standardization targets associated to the specification. The CDB Core Standard specifies a related suite of core requirements classes group into requirements modules.

direct dependency (of a requirements class): another requirements class (the dependency) whose requirements are defined to also be requirements of this requirements class. An example in the CDB Core is that the Geometry Requirements Module has a dependency on the OGC Simple Features Standard which iteself has a dpendency on the ISO/OGC 19107, Geographic information ⎯ Spatial schema.

extension (of a requirements class): requirements class which has a direct dependency on another requirements class that may or may not be part of the core. In the CDB standard, an extension is defined on requirements class so that their implementation may be software extensions in a manner analogous to the extension relation between the requirements classes.

profile: In the usage of this standard, a profile will be a set of requirements classes or conformance classes (either preexisting or locally defined) of the base standards. This is typically referred to as a restircted subset.

recommendation: expression in the content of a document conveying that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.

requirement: expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted.

requirements class: aggregate of all requirement modules that must all be satisfied to satisfy a conformance test class.

requirements module: aggregate of requirements and recommendations of a specification against a single standardization target type.

standardization target: entity to which some requirements of a standard apply. In CDB, the standardization target is a CDB Compliant Data Store.

9.2. Identifiers

The normative provisions in this standard are denoted by the URI namespace

http://www.opengis.net/spec/cdb/2.0/core

All requirements that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

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

http://www.opengis.net/spec/cdb/2.0/

An example might be:

req/core/crs

All conformance tests that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

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

http://www.opengis.net/spec/cdb/2.0/core/

9.3. Use of HTTPS

For simplicity, this document in general only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS and simply is a shorthand notation for "HTTP or HTTPS." In fact, most servers are expected to use HTTPS, not HTTP.

9.4. HTTP URIs

This document does not restrict the lexical space of URIs used in the API beyond the requirements of the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded. See Clause 2 of RFC 3986 for details.

9.5. CDB XML Schema Definitions

Historically, the CDB standard made extensive use of XML. XML was used to:

  • Describe CDB metadata,

  • Encode controlled vocabularies and enumerations,

  • Encode global metadata,

  • Add attributes,

  • Add information to 3d models, such as an OpenFlight model,

  • To describe base and composite materials,

  • And other key information.

In the CDB 2.0 Core modules, specific encoding technologies such as XML or JSON are not specified. The Core requirements are agnostic to any particular encoding. This is because metadata, vocabularies, enumerations, and so forth could be encoded in any number of technologies including database tables. As such, CDB application profiles restrict and define which encoding technology is used.

Regardless of the encoding technology, CDB 2.0 (and later) still provides a number of controlled vocabularies and enumerations. These were integral to the success of earlier CDB versions and are provided in version 2.x as optional but recommended. In CDB 1.2 and earlier, these files were located in the \CDB\Metadata\Schema subdirectory of a CDB datastore.

In CDB 2.x, these vocabularies may be referenced by URI, stored in a database table, or stored in some file in a file system (including the Cloud). The traditional XML metadata and controlled vocabulary schema and files are provided as part of the CDB 2.x Standard. They are identical to those provided in CDB 1.3.

The schemas provided with the CDB Standard that can be used as is, replaced, or extended are:

Vocabulary/Schema Name

O/C/M

Description

BaseMaterialTable.xsd

C

Defines the format of the CDB Base Material Table

Materials.xml

C

The CDB Base Material Table. This file contains the base material names for a CDB datastore.

CompositeMaterialTable.xsd

C

Defines the format of a CDB Composite Material Table (CMT) - a collection of substrates each made of base materials.

Configuration.xsd

O

Defines the configuration of one logical CDB

Configuration.xml

O

An example is provided with the CDB standard of what could be in this file.

Datasets.xsd

M

XML Schema to define and validate the content of Datasets.xml

Datasets.xml

M

Dataset type enumeration

Defaults.xsd

O

XML Schema to define and validate the content of Defaults.xml

Defaults.xml

O

Defaults values for key attributes or data layers in a CDB datastore.

DIS_Country_codes.xsd

C

Schema to define and validate the content of the country code controlled vocabulary

DIS_Country_codes.xml

C

ISO COuntry Codes as used in CDB version 1.2

FeatureDataDictionary.xsd

M

Defines the format of the CDB Feature Data Dictionary.

FeatureDataDictionary.xml

M

DIGEST Feature Data Dictionary

Globalgeometadata.<ext>

O

Global geospatial metadata

Lights .xsd

C

Schema to define and validate the content of the CDB Light Names Hierarchy

Lights.xml

C

Lights Hierarchy as defined and use in CDB version 1.3.

LightsTuning.xsd

O

Schema to define and validate the content of a CDB Light Tuning enumeration.

LightsTuning.xml

O

Example of the type of parameters that can be specified for light tuning visualization and modelling.

Globalgeometadata.<ext>

O

Global geospatial metadata

Model_Components.xsd

C

Schema to define and validate CDB Model Components.

Model_Components.xml

C

Sample list of Model Components provided with CDB 1.3

Moving_Model_Codes.xsd

C

Schema to define and validate the content of the moving model code enumeration.

Moving_Model_Codes.xml

C

Moving model codes as provided in CDB 1.3

Model_Metadata.xsd

O

Schema defines the metadata associated with 3D models.

Vector_Attributes.xsd

O

Schema to define and validate CDB, Geomatics, and Vendor Vector Attributes as defined in Clause 10 of CDB Volume 1

Version.xsd

M

All CDB Versions are identified by a file called Version.xml. This schema defines the format of this file.
Note
 These files/schema have a download location of - Need download location once we know.
Note
 Type: CV = Controlled Vocabulary, M = Metadata, E = Enumeration
Note
 M/O: [M = Mandatory, O = Optional, C = Conditional] Conditional inidcates that if a specific optional requirements module, such as Lights, is specified in an application profile than that specific controlled vocabulary or enumeration SHALL be used (although mofied and.or extended as required)
Note
 <ext> could be xml for XML, jsn for JSON, and other extensions based on the encoding technology used for the geospatial metadata

Each of these files is described in more detail later in either a specific core requirements module, such as for Lights, or in a specific application profile.

How these schemas are provided and accessed in a physical implementation of a CDB datastore is specified in the requirements clauses of a CDB Application Profile. However, the CDB 2.x Standard specify requirements and recommendations for naming, accessing, and processing these schemas.

Note
 For more work: 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. 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.”

9.5.1. The CDB Namespace

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

9.5.2. Accessing the CDB global metadata files, controlled vocabularies, and enumerations.

The following is in reference to how global metadata, vocabularies, and enumerations are provided as part of the CDB Standard on the OGC website. These schemas can be used as the source to populate the global metadata folder in a CDB datastore.

The target namespace of all CDB schemas for vocabularies and enumerations follow this pattern:

"http://opengis.net/cdb/Version/Name

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

To illustrate how a target namespace/URI is composed, here is the target namespace for the Lights vocabulary provided as XML schema:

"http://opengis.net/cdb/2.0/Lights.xml"

9.6. CDB Metadata, Controlled Vocabulary, and Metadata Files

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

In addition to "traditional metadata" for describing geospatial and other resources, CDB implementations make extensive use of one or more additional controlled vocabularies and enumerations. In CDB 1.1 and earlier, all of these datasets were referred to as metadata. From CDB version 1.2 and later, a distinction is made between metadata about a resource, such as a description, and controlled vocabularies/enumerations.

9.6.1. What is a 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, 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.

9.6.2. What is an Enumeration?

In computer programming, an enumerated type (also called an enumeration) is a data type consisting of a set of named values called elements, members, or enumerators of the type. The enumerator names are usually identifiers that behave as constants in the language. Similarly, 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.

9.7. CDB Directory File Naming and Structure

A CDB datastore directory and folder structure is defined by a combination of rules. The base information for defining the folder hierarchy and file naming rules for any CDB application profile are contained in the metadata, controlled vocabulary, and enumerations initially provided with the CDB standard. Please note that these files can be extended to meet any specific domain or community specific requirements.

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 can provide all the information required to build the names of all directories specified and required for a given application profile.

The following file extensions are used:

File Format Minimal Version Number Extension

TIFF

6.0

*.tif

SGI Image

1.0

*.rgb

JPEG 2000

1.0

*.jp2

OpenFlight

16.0

*.flt

Shapefile

Esri White Paper, July 98

*.shp, *.shx

dBASE

III+

*.dbf, *.dbt

XML

1.0 and later

*.xml, *.xsd

ZIP

6.3.1 and later

*.zip

GeoPackage

1.1 and later

*.gpkg

Previous version of the above table had a column labeled: CDB Client-device Behavior for Prior Versions". All rows had the label Ignores data. The column has been removed but the value is still valid.

10. Scope and Introduction - Informative

10.1. Scope

The CDB 2.0 Core Standard defines the mandatory and optional requirements, recommendations, and conformance classes that must be profiled or profiled and extended in any CDB 2.0 and later compliant application profile or implementation. In the CDB 2.0 Standard, requirements and recommendations are organized as aggregates in requirements modules. Some requirements modules, such as Topology, are optional. However if an application profile mandates the use of the Topology requirements module and related conformance classes, then that application profile shall be conformant with the Core Topology Requirements Module.

Note
 The CDB 2.0 Core is abstract and cannot be directly implemented. Therefore, application profiles need to be specified that restrict or restrict and extend requirements that can actually be implemented in an operational environment. For example, the CRS Requirements Module does not specify what CRS should be used for a given CDB datastore. An application profile would clearly state which CRS, such as EPSG 4326, is to be used for a CDB datastore instance. More details are provided below.

10.2. Introduction - High level CDB 2.0 Architecture

The following figure portrays, at a high level, the CDB 2.0 architecture.

Note
 This diagram is abstract and does not incorporate all aspects and requirements classes defined in the CDB 2.0 Core.

CDB 2.0 Architecture

The OGC CDB 2.0 Standard is comprised of a fundamental core and multiple Parts, each Part being a separate standard. This part, the "Core," specifies the core capabilities and is restricted to being able to define a CDB datastore where geometries and coverages represented in a given CRS represented can be structured, referenced, and stored. Additional capabilities that address more advanced requirements will be specified in additional Parts. Examples include support for Materials, Lights, and textures.

Note
 The Core as specified cannot be directly implemented. The specification of profiles and profiles with extensions are required to provide a requirements framework that can be implemented. That said, the fundamaental core does provide and specify two tiling extensions that can be implemented.

10.2.1. What is a datastore?

The following is from Technopedia.

A datastore is a repository for storing, managing and distributing datasets typically at an enterprise level. Datastore is a broad term that incorporates all types of data that is produced, stored and used by an organization. The term references data that is at rest and used by one or more data-driven applications, services, or individuals.

A datastore may include data from end user database applications, files or documents, or the random data property of an organization or an information system. Data may be structured, unstructured, or in another electronic format.

Depending on the organization, a datastore may be classified as an application-specific datastore, operational datastore or centralized datastore. Moreover, a datastore may be designed and implemented by using purpose-built software or through typical database applications.

10.2.2. Foundation Standards

The CDB 2.0 Standard is grounded in a number of OGC Abstract Specifications, ISO TC 211 91xxx series International Standards, and standards from other Standards Development Organization such as the W3C and the IETF. The OGC Abstract Specification and ISO 19xxx Standards provide the conceptual foundation for many OGC standards development activities. They also provide a conceptual (abstract) foundation for many other geospatial standards development activities in the IETF, W3C, OASIS, and a large number of government organizations. Open interfaces and protocols can be designed, built, and referenced against the Abstract Specification, thus enabling interoperability between different platforms, applications, and different spatial processing systems. The Abstract Specification provides a reference model for the development of standards that can be implemented.

10.2.3. CDB 2 Fundamaental Core

The CDB Fundamental Core consists of core requirements modules and corresponding conformance classes that any extension, application profile, or implementation of the CDB Standard shall be conformant with. For example, any implementation of an Application Profile (aka Profile) shall inherit and be dependent on the conformance classes as defined and implemented in the Core. In the above diagram, a number of requirements modules are mandatory. Any application profile (including extensions) shall conform with the requirements stated in those modules. The yellow highlighted core modules are optional. However, if an optional core module is specified in an application profile (including extensions) then that profile shall conform with the requirements stated in those modules.

The CDB Fundamaental Core is comprised of a set of abstract requirements modules and related conformance modules. These requirements modules are defined by an aggregate of requirements and recommendations that are abstract in the sense that they cannot be directly implemented. Instead, they need to be profiled or profiled with extensions in order to be implemented. However, any profile, profile with extensions, or implementation of any given requirements class shall be conformant with that core requirements class.

Another key design concept of the Core is that each specified requirements module - as defined by one or more requirements classes - has no dependencies on any other core requirements module. For example the CRS Core Requirements Module has no dependencies on Geometry and visa-versa. The only exception is the metadata core module. More on that below.

Note
 There are very few interdependencies between the core modules. The only exceptions are related to metadata and coordinate reference systems.

10.2.4. Application Profiles

The CDB 2.0 core is not implementable. While the core consists of requirements classes and related conformance classes, profiles that restrict any given requirement or requirements module are necessary to create a set of requirements and conformance classes that can be implemented. In CDB 2.0, these are called application profiles.

For example, CDB 2.0 Core specifes a Coordinate Reference System (CRS) Requirements Module. This requirements Module does not mandate which CRS is to be used for a given implementation instance or profile. Instead, that restriction would be specified in a profile or profile with extensions. The CRS requirements module also specifies requirements such as that the ISO/OGC Well Known Text for CRS (WKT for CRS) shall be used to encode the CRS metadata for storage in a CDB datastore.

10.3. Metadata and the CDB Core

The majority of the requirements modules specified in the CDB Core are metadata centric. For example the requirements modules for tiling, feature attribution, or coordinate reference systems are focused on metadata related to the actual tiling structure or the CRS of a given CDB datastore. There are also requirements modules specifically focused on is considered more traditional metadata such as metadata for a given resource (dataset). The core also contains requirements modules related to specific controlled vocabularies such as Lights and Navigation Aids. Again, however, in a broad sense a controlled vocabulary is also metadata.

The determinism design principle is one reason for the focus on metadata in the CDB Core. Metadata elements defined in an application profile of the Core, such as for tiling, feature attribution, and the CRS, provide a well known and documented determinstic structure for both service and client access.

Note: The CDB Core does not address specific metadata required for a given resource or dataset type. For example, the Core does not provide requirements or guidance on all imagery metadata other than a few key metadata elements required for discovery.

10.4. Overview of the CDB Storage Structure

The CDB specified storage structure supports 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 tiling structure specifies how to geographically divide 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 individual 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 use of LOD representations is critical for high performance. Most client-devices can readily take advantage of an LOD structure because, in many cases, less detail/information is necessary at increasing distances from the user perspective. As a result, many client-devices can reduce (by 100-fold or more) the required bandwidth to access 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 CDB Standard does not define or enforce an operating system or file system.

11. Clause 7: CDB 2.0 Core Requirements Classes

This clause specifies the requirements classes that comprise the abstract core of the CDB-2.0 Standard. The core requirements classes are unique requirements classes that must be satisfied by any conformant standardization targets associated with the CDB 2.0 and later Standard. Standardization targets may be extensions to this Standard, application profiles based on the core, and implementations of the Standard.

Some of the requirements classes are mandatory for any application profile and implementation. Other requirements classes are optional but any application profile or implementation using the optional requirements classes must be conformant with those classes.

Requirements Class M/O Description

Attributes

O

Requirements for encoding and storing attributes in a CDB datastore.

Coverages

O

Requirements for specifying coverages in a CDB datastore.

Coordinate Reference System

M

Requirements for the coordinate reference system of a CDB datastore.

File naming

M

Requirements for naming assets in a CDB datastore.

Geometry

O

Requirements for specifying geometry in a CDB datastore.

Links

M

Specifies requirements for how links are structured.

Media Types

O

Specifies enumerations of CDB 2.0 Media Types.

Metadata

M

Specifies requirements classes and requirements for global and resource metadata used in a CDB datastore.

Tiling (Abstract)

O

Specifies requirements classes and requirements for tiling a CDB datastore at the abstract level.

Tiling Extension: CDBGlobal Grid

O

Requirements module for implementing the CDBGlobalGrid tiling extension.

Tiling Extension: GNOSISGlobal Grid

O

Requirements module for implementing the GNOSISGlobalGrid tiling extension.

Topology

O

Specifes requirements for topology primitives used in a CDB datastore.

Versioning

O

Specifes requirements for versioning used in a CDB datastore implementation.

11.1. Additional Parts - Future Work

The OGC CDB 2.0 Standard consists of a fundamental core of mandatory and optional requirements classes and a number of additional Parts. These additional Parts define the requirments classes for such features as Materials and Textures. These Parts have been identified as future work. Many are in draft form but work wil not be completed until the fundamental core is approved as an official OGC Standard.

3D Models O Requirements for specifying 3D Models in a CDB datastore.

Light Naming

O

Requirements for the structure of a lights controlled vocabulary and how new Light types and related metadata can be added to the Lights controlled vocabulary.

Materials

O

Specifies core requirements for physical materials.

Textures

O

Specifies the requirements for textures in a CDB datasstore.

Annex A: Revision History

Date Release Editor Primary clauses modified Description

2021-08-11

2.0

C. Reed

all

Initial version

2021-12-15

2.0

C. Reed

CRS

Initial full draft for SWG approval

2022-02-10

2.0

C. Reed

Tiling

Abstract and Extension - initial full drafts for SWG review

Annex B: Bibliography

This table lists the documentation referenced throughout this document.

Ref

Title

Description

1

ARINC Standard 424-16

Navigation System Data Base, Aeronautical Radio Inc., August 30, 2002.

2

ASTARS-04 CDB

Systems Requirements

3

Digital Geographic Information Exchange Standard (DIGEST), Standard V2.1

The document can be obtained at the following address:

http://www.digest.org/

4

Enumeration and Bit Encoded Values for use with Protocols for Distributed Interactive Simulation Applications.

This is document SISO-REF-010. It accompanies IEEE Std 1278.1-1995 and can be obtained from the Simulation Interoperability Standards Organization at http://www.sisostds.org/

5

Extensible Markup Language (XML) 1.0 (Third Edition)

Bray, Tim, et al.

http://www.w3.org/TR/2004/REC-xml-20040204/

W3C Recommendation, February 04, 2004.

6

Guide - PD6777, BSI’s _Guide to the practical implementation of JPEG 2000 _

The document can be found at:

http://www.jpeg.org/

Other useful sites include:

http://en.wikipedia.org/wiki/SRGB_color_space

The document is targeted at managers; application software developers and end-users who want to know more about JPEG 2000.

7

IEEE Standard for Distributed Interactive Simulation - Application Protocols

IEEE Std 1278.1-1995

8

JPEG 2000: Image Compression Fundamentals, Standards and Practice

Kluwer International Series in Engineering and Computer Science, Secs 642, by David S. Taubman and Michael W. Marcellin

9

MIL-STD-2411 Raster Product Format Specification

The Raster Product Format (RPF) is a standard data structure for geospatial databases composed of rectangular arrays of pixel values (e.g., in digitized maps or images) in compressed or uncompressed form. RPF defines a common format for the interchange of raster-formatted digital geospatial data among DoD Components.

Department of Defense Information Technology Standards Registry Baseline Release 04-2.0.

http://earth-info.nga.mil/publications/specs/printed/2411/2411_RPF.pdf

10

MIL-C-89041 Controlled Image Base Specification

Controlled Image Base (CIB). This Specification provides requirements for the preparation and use of the RPF CIB data. CIB is a dataset of orthophotos, made from rectified grayscale aerial images.

http://www.fas.org/irp/program/core/mil-c-89041-cib.htm

11

OpenFlight Scene Description Database Standard, Version 16.0, Revision A, November 2004, Presagis Inc

The original document has been annotated by CAE to create the CDB-annotated OpenFlight Standard.

12

Product Standard for the Digital Aeronautical Flight Information File (DAFIF), Eight Edition, Doc. # PS/1FD/086

National Imagery and Mapping Agency (NIMA), April 2003.

13

SEDRIS™ - Synthetic Environment Data Representation Interchange Specification

The Source for Synthetic environment Representation and Interchange.

http://www.sedris.org

14

Shapefile Technical Description - an ESRI White Paper—July 1998

The original document has been annotated by CAE Inc to create the CDB-annotated Shapefile Technical Description.

15

The SGI Image File Format, Version 1.00, Paul Haeberli, Silicon Graphics Computer Systems

This specification can be found at:

http://paulbourke.net/dataformats/sgirgb/sgiversion.html

16

TIFF rev 6.0 Adobe Developers Association, Adobe Systems Incorporated, 1585 Charleston Road and P.O. Box 7900Mountain View, CA 94039-7900

A copy of this original standard can be found at:

http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

and at:

ftp://ftp.adobe.com/pub/adobe/ DeveloperSupport/TechNotes/PDFfiles

The original document has been annotated by CAE Inc to create the CDB-annotated TIFF Standard.

17

XML Schema Part 0: Primer Second Edition

Fallside, David, Priscilla Walmsley.

http://www.w3.org/TR/xmlschema-0/

W3C Recommendation, October 28, 2004.

18

XML Schema Part 1: Structures Second Edition

Thompson, Henry S., et al.

http://www.w3.org/TR/xmlschema-1/

W3C Recommendation, October 28, 2004.

19

XML Schema Part 2: Datatypes Second Edition

Biron, Paul V., Ashok Malhotra.

http://www.w3.org/TR/xmlschema-2/

W3C Recommendation, October 28, 2004.

20

ICAO Airline Designator

List of ICAO Airline Codes,

http://en.wikipedia.org/wiki/Airline_codes

21

Radar Signatures and Relations to Radar Cross-Section. Mr. P E R Galloway, Roke Manor Research Ltd, Romsey, Hampshire, United Kingdom.

This document can be obtained at the following Internet address:

http://aircraftdesign.nuaa.edu.cn/lo/Ref/General%20Topics/radar_signatures_and_relations_to_rcs.pdf

22

AN/APA to AN/APD - Equipment Listing.

This document can be obtained at the following Internet address:

http://www.designation-systems.net/usmilav/jetds/an-apa2apd.html#_APA

23

Radar Polarimetry - Fundamentals of Remote Sensing.

National Resources Canada.

This document can be obtained at the following Internet address:

https://www.nrcan.gc.ca/earth-sciences/geomatics/satellite-imagery-air-photos/satellite-imagery-products/educational-resources/9275

24

RCS in Radar Range Calculations for Maritime Targets, by Ingo Harre. Bremen,

Germany. (V2.0-20040206).

This document can be obtained at the following Internet address:

http://www.mar-it.de/Radar/RCS/RCS_xx.pdf

25

Decibels relative to a square meter – dBsm. By Zhao Shengyun.

This document can be obtained at the following Internet address:

http://radarproblems.com/chapters/ch06.dir/ch06pr.dir/c06p11.dir/c06p11.htm

26

MIL-C-89041

Controlled Image Base (CIB)

27

MIL-STD-2411

Defense Mapping Agency, Military Standard, Raster Product Format (RPF)

28

MIL-STD-2411-1

Defense Mapping Agency, Registered Data Values for Raster Product Format

29

MIL-STD-2411-2

Defense Mapping Agency, Incorporation of Raster Product Format (RPF) Data in National Imagery Transmission Format (NITF).

30

IEEE Std 1516-2000

IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)

31

RPR-FOM Version 2 Draft 17

Real-time Platform Reference (RPR) Federation Object Model (FOM)

This RPR-FOM maps the DIS standard to the HLA standard.

The document can be obtained from the Simulation Interoperability Standards Organization at the following address:

http://www.sisostds.org/

32

MIL-PRF-89039 Amendment 2

Performance Specification Vector Smart Map (VMAP Level 0), 28 September 1999

http://en.wikipedia.org/wiki/Vector_Map http://earth-info.nga.mil/publications/specs/printed/VMAP0/vmap0.html

33

MIL-PRF-89033 Amendment 1

Performance Specification Vector Smart Map (VMAP Level 1), 27 May 1998

34

MIL-PRF-89035A

Urban Vector Map (UVMap), 1st August, 2002

35

OneSAF Ultra High Resolution Building (UHRB) Object Model

OneSAF UHRB Object Model (Version 2.2, Document Revision E, March 7th, 2008, Contract #: N61339-00-D-0710, Task Order: 28.) *http://www.onesaf.net/community/systemdocuments/v.3.0/MaintenanceManual/erc/UHRB_2_Object_Model.pdf *

36

OneSAF Ultra High Resolution Building (UHRB) On-Disk Format

OneSAF UHRB On-Disk Format Model (Version 2.2, Document Revision E, March 7th, 2008, Contract #: N61339-00-D-0710, Task Order: 28.) *http://www.onesaf.net/community/systemdocuments/v.3.0/MaintenanceManual/erc/UHRB_2_On_Disk_Format.pdf *

37

U.S. Department of Transportation - Federal Aviation Administration – Advisory Circular 150/5340-1J

Standards for Airport Markings, AC- 150/5340-1J, dated 4/29/2005

38

Federal Aviation Administration – Aeronautical Information Manual

Official Guide to Basic Flight Information and ATC Procedures, dated 14th February, 2008
1. This section is based on presentations and a paper on the JTDS C-TGS activity. Specifically, “Cloud Terrain Generation and Visualization Using Open Geospatial Standards, Chambers and Freeman, 2014. From proceedings of the Interservice/Industry Training, Simulation, and Education Conference.
2. In this context, raw source denotes any input to the modeling workstation that is used to assemble the synthetic environment; consequently, the data may have undergone some level of post-processing (such as image color-balancing, image ortho-rectification, etc.) or may be in a specific source interchange format (such as SIF, SEDRIS, etc.)