Open Geospatial Consortium

Submission Date: 2018-03-20

Approval Date:      2018-08-27

Publication Date:      2018-12-19

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

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

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

Version: 1.1

Category: OGC® Implementation

Editor:       Sara Saeedi

Volume 11: OGC CDB Core Standard Conceptual Model

Copyright notice

Copyright © 2018 Open Geospatial Consortium

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

Warning

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

Document type:        OGC® Standard

Document subtype:   

Document stage:    Approved

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

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

i. Abstract

This Open Geospatial Consortium (OGC) standard defines the conceptual model for the OGC CDB Standard. The objective of this document is to provide an abstract core conceptual model for a CDB data store (repository). The model is represented using UML (unified modeling language). The conceptual model is comprised of concepts, schema, classes and categories as well as their relationships, which are used to understand, and/or represent an OGC CDB data store. This enables a comparison and description of the CDB data store structure on a more detailed level. This document was created by reverse-engineering the UML diagrams and documentation from the original CDB submission [1] as a basis for supporting OGC interoperability. One of the important roles of this conceptual model is to provide a UML model that is consistent with the other OGC standards and to identify functional gaps between the current CDB data store and the OGC standards baseline. This document references sections of Volume 1: OGC CDB Core Standard: Model and Physical Database Structure [OGC 15-113r5].

Note
The simulation community uses the term “synthetic environment data” to mean all the digital data stored in some database or structured data store that is required for use by simulation clients. From the geospatial community perspective, these data are essentially the same as GIS data but with, in some cases, special attributes, such as radar reflectivity.

ii. Keywords

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

ogcdoc, OGC document, UML, conceptual model, raster, tiles, vector, CDB, Common Data Base, simulation, visualization, synthetic environment.

iii. Preface

The industry-maintained CDB model and data store structure has been discussed and demonstrated at OGC Technical Committee meetings since September 2013. This document, the first UML conceptual model for OGC CDB standard, is one of the 12 documents that comprise the OGC CDB modular standard. The UML conceptual model establishes a single set of consistent concepts that could be also implemented using other encoding mechanisms. The CDB standard is originally based on the OGC CDB Best Practice documents, which were submitted to the OGC by CAE Inc. on behalf of the CDB implementation community and user group. CDB is currently widely implemented in the defence and aviation simulation communities. The intent is that this initial OGC version of the CDB standard be backwards compatible with existing implementations but that terminology and concepts be aligned as appropriate with the OGC technical baseline. Future work is planned to align the standard with other OGC standards and to provide Best Practices focused on how to use CDB with the existing OGC standards baseline, such as OGC GeoPackage, CityGML, Web Map Service (WMS), Web Feature Service (WFS), and Web Coverage Service (WCS).

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

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

Organization name(s)

  • CAE Inc.

  • Carl Reed, OGC Individual Member

  • Envitia, Ltd

  • Glen Johnson, OGC Individual Member

  • KaDSci, LLC

  • Laval University

  • Open Site Plan

  • University of Calgary

  • UK Met Office

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

v. Submitters

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

Name

Affiliation

Sara Saeedi

University of Calgary

Steve Liang

University of Calgary

Carl Reed

Carl Reed & Associates

David Graham

CAE Inc.

vi. Future Work

The CDB community anticipates that additional standardization will be required to prescribe content appropriate to targeted simulation applications. In its current form, the CDB standard does not mandate synthetic environmental richness, quality and resolution. In Version 1.1, additional informative clauses were incorporated that provide guidance on how to include and encode global (data store wide) and local (data set specific) geospatial metadata. The OGC CDB Standards Working Group (SWG) members understand there is a requirement for eventual alignment of the CDB standard with the OGC/ISO standards baseline. In Version 1 of the CDB standard, effort was invested to begin aligning terminology and concepts, specifically in the coordinate reference system discussions and requirements. The current version of the CDB standard is fully backwards compatible with version 1.0 of the CDB standard as defined and implemented by the current CDB implementer and user community. The requirements for a CDB data store are focused on the ability to store, manage, and access extremely large volumes of geographic content. In this version of the standard, initial harmonization with the OGC and ISO standards baseline has begun. For example, where appropriate, the CDB simulation community terms and definitions have been replaced with OGC/ISO terms and definitions. Further, the standards documents have been reorganized and structured to be consistent with the OGC Modular Specification Policy. However, the CDB SWG and community recognize the need to further harmonize and align this standard with the OGC baseline and other IT best practices. There has already been considerable discussion in this regard. Based on such discussions and comments received during the public comment period, the following future work tasks are envisioned:

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

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

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

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

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

vii. CDB Document Guide

This document contains a number of annexes related to the OGC CDB Core standard.

For the purposes of being able to cross reference this OGC Best Practice with the previous versions of the CDB standard, the following annex “crosswalk” is provided.

OGC CDB Best Practice and CDB 3.2

OGC CDB Standard Version 1.0

Formerly Annex A10 in Volume 2

Annex B Rationale: Sensor Simulation - Achieving Device-Independence

Main Body: Rationale for using JPEG

Annex C Reasons for Using JPEG

Formerly Annex B in Volume 2

Annex D: TIFF Implementation Requirements

Formerly Annex D in Volume 2

Annex E: ShapeFile dBASE III Guidance

Formerly Annex A.11 in Volume 2

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

Formerly Annex A.12

Annex G Rationale: Importance of Level of Detail

Formerly Annex A.17 Volume 2

Annex H: JPEG Informative annex

Formerly Annex U, Volume 2

Annex I ZIP File Informative annex

Formerly Annex E, Volume 2

Annex J: Light Hierarchy

Formerly Annex M, Volume 2

Annex M: CDB Directory Naming and Structure

Formerly Annex O, Volume 2

Annex O: List of Texture Component Selectors

Formerly Annex Q, Volume 2

Annex Q: Table of Dataset Codes

Formerly Annex R, Volume 2

Annex R: Derived Datasets within the CDB

Formerly Annex S, Volume 2

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

For ease of editing and review, the standard has been separated into 12 Volumes and a schema repository.

  • Volume 0: OGC CDB Companion Primer for the CDB standard. (Best Practice)

  • Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure. The main body (core) of the CDB standard (Normative).

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

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

  • Volume 4: OGC CDB Use of Shapefiles for Vector Data Storage (Best Practice).

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

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

  • Volume 7: OGC CDB Data Model Guidance (Best Practice).

  • Volume 8: OGC CDB Spatial Reference System Guidance (Best Practice).

  • Volume 9: OGC CDB Schema Package: provides the normative schemas for key features types required in the synthetic modelling environment. Essentially, these schemas are designed to enable semantic interoperability within the simulation context. (Normative)

  • Volume 10: OGC CDB Implementation Guidance (Best Practice).

  • Volume 11: OGC CDB Core Standard Conceptual Model (Normative)

  • Volume 12: OGC CDB Navaids Attribution and Navaids Attribution Enumeration Values (Best Practice)

viii. Terms, Definitions, and Abbreviations

Please refer to Volume 3: Terms and Definitions for terms used in this document (http://www.opengeospatial.org/standards/cdb). Abbreviations used in this CDB Volume are:

BMT Base Material Table

CMT Composite Material Table

DEM Digital Elevation Model

DIGEST Digital Geographic Exchange Standard

DGIWG Defence Geospatial Information Working Group

FDD Feature Data Dictionary

LOD Level of Detail

SEDRIS Synthetic Environment Data Representation and Interchange Specification

UHRB Ultra-High Resolution Building (data)

1. Overview of the OGC CDB Conceptual Model

Conceptual modelling is a structural methodology for describing how the components of a CDB data store may be implemented based on the modular specification design of the OGC CDB Core Standard. The following table defines the general CDB data store requirement and an overview of key elements implemented in a compliant CDB data store.

Requirement Class 1

Req. ID

http://opengis.net/spec/CDB/1.0/core/OveralConceptualModel

Dependency

All of the requirements of the OGC CDB core document

Req. Text

A minimum compliant CDB shall contain the version metadata. When any dataset is provided in a CDB, it shall comply with the corresponding mandatory requirements of the OGC CDB Core Standard (Volume 1 http://www.opengeospatial.org/standards/cdb).

This section presents the conceptual model for an OGC CDB compliant data store. This model can used as the basis for the CDB standard in other application domains, along with its requirements, extension, file-based structure, data formats, access, and the discovery of services.

image
Figure 1. Package diagram of OGC CDB data store conceptual model

The CDB data store structure is designed to provide efficient access to any location enabled content accessible in the data store. The main properties of the CDB data store UML diagram are documented below.

Name

Definition

Data type & Value

Multiplicity

Tile

Geographically divides the world into geodetic tiles (bounded by latitudes and longitudes), each containing at least a dataset

Dataset type.

One or more (mandatory)

LOD Hierarchy

Each dataset layer has a LOD hierarchy.

Hierarchy of raster, vector and models.

One (mandatory)

Dataset

Defines the basic storage unit used in a CDB data store.

Layers of data

One (mandatory)

Models

Includes 3D representations of cultural features and moving models such as buildings, pylons and posts, aircraft and other moving platforms. 3D models have various model components

Model data formats supported in CDB standard.

Zero or more (optional)

Imagery

There are various imagery types in a CDB data store such as representation of geo-referenced terrain, elevation, and texture.

Image data formats supported in the CDB standard such as GeoTIFF, JPEG 2000, etc.

Zero or more (optional)

Vector Features

This includes all the vector feature datasets in a CDB which are defined based on the Feature Data Dictionary.

Vectors data formats supported by the CDB such as shapefile and etc.

Zero or more (optional)

Elevation

Depicted by a grid of elevation data elements at regular geographic intervals, which include DEM, MinMaxElevation and MaxCulture [2].

Grid of terrain altimetry data

Zero or more (optional)

Metadata

CDB XML files that include the default hierarchies, naming, and values to be used by client devices.

XML association

one or more (mandatory)

As it can be seen in Figure 2, the CDB standard relies on three important concepts to organize geospatial data: Tiles, Layers (or datasets) and Levels of Detail (LOD) which are described here.

  • Tiles: Tiles organize the data into zones defined by location with respect to a WGS84 reference system [3]. The CDB storage structure allows efficient searching, retrieval and storage of any information contained within a CDB data store. The storage structure portion of the standard geographically divides the world into geodetic tiles (bound by latitudes and longitudes), each containing a specific set of features (such as terrain altimetry, vectors) and models (such as 3D and Radar Cross Sections models), which are in turn represented by their respective datasets. The datasets define the basic storage unit used in a CDB data store. The geographic granularity is at the tile level while in each tile, the information granularity is at the dataset level defined by layers.

  • Layers: Layers organize different types of data in a tile. The CDB standard data store model is also logically organized as distinct layers of information. The layers are independent from each other (i.e., changes in one layer do not impose changes in other layers).

  • Levels-of-Detail (LODs): LODs organize the data in each layer of each tile by its detail. The availability of LOD representations is critical to real-time performance. Most simulation client-devices can readily take advantage of an LOD structure because, in many cases, less detail/information is necessary at increasing distances from the viewpoint of a simulation rendering. The CDB standard requires that each geographic area be represented in an LOD hierarchy in accordance with the availability of source data.

Picture11.png
Figure 2. CDB data organization structure

2. CDB General Data Organization

The CDB is composed of several datasets that share a common structure. The following sections present the general organization and structure of all CDB datasets. The CDB standard does not define or enforce an operating system or file system. Nonetheless, the implementation of a CDB storage sub-system must conform to absolute minimum file system requirements called for by the standard. A CDB data store uses existing common file formats for storing data in various formats such as TIFF/GeoTIFF (raster data), JPEG 2000 (imagery data), OpenFlight (3D models), ShapeFiles (vector data and radar cross sections), RGB (textures), XML (Metadata) and ZIP (file collection). The current version of CDB uses a consolidation of data dictionaries from DIGEST, DGIWG, SEDRIS and UHRB (See Volume 3: CDB Terms and Definitions). In addition, it is possible to extend the CDB Feature Data Dictionary (FDD) by using the extension capabilities and adding a new FDD XML schema file to access additional feature data codes. The UML diagram in Figure 3 describes how the data is categorized in tiles, layers and LODs. This is the basis for the CDB geospatial data categorization.