Overview of the OGC CDB Standard for 3D Synthetic Environment Modeling and Simulation

Abstract

Recent advances in sensor and platform technologies, such as satellite systems, unmanned aerial vehicles (UAV), manned aerial platforms, and ground-based sensor networks have resulted in massive volumes of data being produced and collected about the earth. Processing, managing, and analyzing these data is one of the main challenges in 3D synthetic representation used in modeling and simulation (M&S) of the natural environment. M&S devices, such as flight simulators, traditionally require a variety of different databases to provide a synthetic representation of the world. M&S often requires integration of data from a variety of sources stored in different formats. Thus, for simulation of a complex synthetic environment, such as a 3D terrain model, tackling interoperability among its components (geospatial data, natural and man-made objects, dynamic and static models) is a critical challenge. Conventional approaches used local proprietary data models and formats. These approaches often lacked interoperability and created silos of content within the simulation community. Therefore, open geospatial standards are increasingly perceived as a means to promote interoperability and reusability for 3D M&S. In this paper, the Open Geospatial Consortium (OGC) CDB Standard is introduced. “CDB” originally referred to Common DataBase, which is currently considered as a name with no abbreviation in the OGC community. The OGC CDB is an international standard for structuring, modeling, and storing geospatial information required in high-performance modeling and simulation applications. CDB defines the core conceptual models, use cases, requirements, and specifications for employing geospatial data in 3D M&S. The main features of the OGC CDB Standard are described as the run-time performance, full plug-and-play interoperable geospatial data store, usefulness in 3D and dynamic simulation environment, ability to integrate proprietary and open-source data formats. Furthermore, compatibility with the OGC standards baseline reduces the complexity of discovering, transforming, and streaming geospatial data into the synthetic environment and makes them more widely acceptable to major geospatial data/software producers. This paper includes an overview of OGC CDB version 1.0, which defines a conceptual model and file structure for the storage, access, and modification of a multi-resolution 3D synthetic environment data store. Finally, this paper presents a perspective of future versions of the OGC CDB and what the steps are for humanizing the OGC CDB standard with the other OGC/ISO standards baseline.

1. Introduction

Synthetic environment (SE) is a representation of the natural environment with a high level of realism at a specific geographical location. In the SE, the models and simulations of some given real-world environments exist and interact [1]. SE allows the modeling and simulation of the environmental elements and processes, as well as its visualization. Although terrain data is the most commonly used data in virtual reality [2], the SE consists of terrain data as well as oceans, atmosphere, and space [3,4]. Therefore, a 3D synthetic environment may include terrain data, terrain elements (both natural and manmade structures), 3D dynamic (moving) models of vehicles, people and animals, ocean surface, ocean bottom and natural/man-made features on the ocean floor. Additionally, the SE includes the specific attributes of the environment features (e.g., soil, trees, and vegetation), dynamic changes (such as seasonal variation in weather or light) as well as their relationships (such as spatial and non-spatial associations and connections). Although SE was traditionally applied in military applications, such as mission rehearsal, its use is rapidly spreading into research and commercial applications, due to the advancement of IT (Information Technology) and data collection technologies. In the past decade, SE has become much more popular and beneficial in many diverse disciplines such as video gaming, 3D city planning, car safety research, real-time traffic simulation, surgical training, manufacturing, education, and flight simulation and training for commercial aircrafts [5].

SE provides a realistic representation of a natural environment for modeling and simulation (M&S). M&S has recently become an important domain of knowledge that is being pursued by many experts from different fields due to the role plays in understanding complex and dynamic systems [6,7]. M&S can be used in virtual reality (simulations with human-in-the-loop controllers), live (using real-world sensors), and constructive simulation (simulations within which entity dynamics are computer controlled). In M&S application scenarios, various synthetic representations need to be created. Accordingly, effective M&S requires a comprehensive pre-configured SE datastore that can be shared, reused, and repurposed. Such a database is used to produce a unified synthetic representation of the world based on the geospatial information with redundancies and inconsistencies. Traditionally, the M&S simulators require their own proprietary application-specific SE geospatial databases which may contain the same geospatial data, but encoded in different formats and described in a range of semantics. In this case, heterogeneous simulators with the same “worldview” require data translation, replication, and synchronization. The process of data translation usually introduces errors and inconsistencies that are costly to identify and compensate. Therefore, an open, platform-independent, interoperable, OGC-compatible, a standard is needed to efficiently support multiple geospatial M&S datastore [3,4,8,9].

As a standards organization, the Open Geospatial Consortium (OGC) addresses issues of interoperability focused on the sharing and use of geospatial data and services, a fundamental requirement in Geographic Information System (GIS) technology and remote sensing software platforms. The OGC has emerged as the leading organization for geospatial interoperability and cooperates closely with major governmental and industrial organizations as well as other international standards organizations. An essential part of the geospatial data users is the M&S community, which adopts OGC standards in different applications such as aviation, emergency response, defense, and military. Several efforts have been made in developing a robust infrastructure to store, search, discover, and retrieve massive geospatial data in M&S using OGC-approved formats and services [10,11,12,13]. The demonstration of an M&S environment using open standards proves that (1) using open standards reduces development time and (2) standards-based software solutions achieve an initial operating capability faster. The OGC Common DataBase (CDB) Standard Working Group (SWG) focuses on bridging the gap between the geospatial standards community and the M&S community to facilitate interoperability of the geospatial content beyond the traditional GIS community. OGC has developed and proposed a suite of standards and best practices (OGC CDB 1.0 Standard) for a database repository which is useful for run-time 3D synthetic environment generation [14,15]. The OGC CDB datastore may include terrain data, terrain features (both natural and manmade structures), 3D dynamic (moving) models of vehicles, people and animals, ocean surface, ocean bottom and natural/man-made features on the ocean floor. The OGC CDB Standard allows the creation of a dynamic synthetic datastore that can be used in live, virtual, and constructive simulation environments. The name “CDB” originally referred to Common DataBase, which is considered as a name with no abbreviation in the OGC community. The reason for this decision was that the name “Common Database” is a general and misleading term in OGC community, and the scope of the name is more inclusive than the CDB datastore which is primarily utilized in M&S application.

2. Background of the OGC CDB Standard

The basic concept of using a common database is to develop a 3D dynamic SE that can be used for different simulator clients. On the other hand, there is no need to create replicated application-oriented databases for various simulators. Such a database needs to support M&S NATO interoperability standards (e.g., Distributed Interactive Simulation (DIS) and High-Level Architecture (HLA)), natural environment standards (e.g., Synthetic Environment Data Representation and Interchange Specification (SEDRIS)), and many others for reusability of data and simulations and cost saving [16]. A good summary of these M&S standards can be found in Handbook AMSP-01 [17]. Additionally, most of the data layers in an SE datastore is geospatial raster and vector data; therefore, a successful SE datastore standard has to be compatible with geospatial International Organization for Standardization (ISO) and OGC data and services standards for reusability and transformation of geospatial data.

The OGC CDB is an interoperable datastore standard that supports the creation of standardized and rapidly updatable SE. The starting point for this standard was the existing Common DataBase (CDB) Version 3.2 specification, Volumes 1 and 2, currently maintained as a de-facto industry best practice [18]. The CDB specification was initially authored by CAE Inc. on November 2005 under a contract administered by the US Army Program Executive Office for Simulation Training and Instrumentation (PEO STRI) to meet requirements set by US Special Operations Command (USSOCOM) for interoperable, high-performance mission rehearsal and simulation federations. CAE along with other companies (e.g., Flight Safety Inc., New York, NY, USA, Presagis Inc., Montréal, QC, Canada, etc.) have delivered hundreds of simulation channels based on CDB to customers in the US, Canada, UK, Germany, Turkey, Israel, Singapore, Australia, Brunei and other countries. To improve the efficiency of M&S analysis, facilitate data and services’ interaction and communications, and reduce operational cost and complexity, OGC adopted CDB model and datastore structure. CDB has been discussed and demonstrated at OGC Technical Committee meetings since September 2013. The industry specification has been approved by the OGC Technical Committee and Planning Committee, and released under OGC Copyright as OGC Best Practices documents 15-003 and 15-004. The final output of the OGC CDB SWG is the first version of the OGC CDB standard which approved by the OGC membership in October 2016 as a new standard for SE modeling and simulation. The OGC CDB 1.0 includes 12 documents that comprise the OGC CDB modular standard.

The OGC CDB 1.0 is an open standard to describe the SE database specification which is well established within the modeling and simulation industry. Unlike other specifications that only deal with visual simulation, the OGC CDB standard deals with all the data representational types needed in high-end virtual, live and constructive simulation applications. The OGC CDB defines all aspects of data representation and organization, storage structure, rapid discovery, transformation, and streaming of geospatial data to support simulation. A database that conforms to the OGC CDB 1.0 standard contains datasets organized in layers and tiles that represent the features of a 3D SE for distributed simulation applications. These features include 2D and 3D raster and vector data describing natural and man-made features such as planet earth, terrain relief, terrain imagery, ocean surface, ocean bottom, bridges, building, indoor features, people, vehicles, texture, and attributes. Existing simulation client-devices can readily use an OGC CDB datastore through a publishing process performed in real-time. The data structures used in CDB is a file-based data structure which is different from those used in relational databases. This file-based structure facilitates the work required to adapt existing M&S tools to read/write/modify the CDB to develop runtime publishers. It also supports big data processing and analytics which is based on the use of file systems to take advantage of the locality of data. Direct file access can be extremely fast, efficient, as well as providing you all the file access capabilities with full integrity control and security. This is especially true when loading the entire flat file into memory. In the modern computation world, storage is not a problem; however, granularity and LODs (level of details) can be helpful for the performance. Also, the CDB has a well-defined structure and associated naming rules. Structure and regulations allow for anyone to implement the structure and verify the datastore using the OGC testing software and website [19] to be assured that its interoperability is maintained. The OGC CDB design is extensive as all the details have been mentioned in the standard. However, it is not complicated for implementation. Many of the data layers and specification codes can be ignored for different application domains.

2.1. Objectives and Scope

The long-term goal of the OGC CDB Standard is to harmonize the specifications for dynamic M&S which are useful in runtime SE generation and terrain database repositories. This goal can be achieved by proposing an international open geospatial standard to express geospatial entities, attributes, and their relationships. This standard can be efficiently implemented by the existing or future simulation software development communities and will be widely used by the simulation end-user services. The primary scope of this standard is to propose a terrain database model and specification which is efficient for the M&S application. The scope of the OGC CDB standard includes a combination of a conceptual model, requirements, an encoding specification, and implementation guide which is useful for implementers of CDB to support all of its requirements.

By using OGC compatible standards, most of the producers and users of geospatial technologies in M&S may adopt standards that appear at first to compromise business processes; however, many reasons are encouraging the development of the OGC CDB standards as listed below:

• Standardization: The OGC and M&S community need to work collaboratively to ensure proper life-cycle management of the OGC CDB standards, including such issues as backward compatibility and usability.
• Modularity and Extensibility: Logically, partitioning the OGC CDB standard(s) will be useful in future manageability and extensibility. A high-end simulation system using OGC’s CDB-derived standard(s) will dynamically update the terrain and instantly serve it to any OGC-compliant client. This flexibility and scalability could also support the requirement for a modular structure that can be delivered to simulators.
• Adaptation: The OGC CDB standard is aligned with the OGC international best practices and standards, thereby, enabling greater interoperability of different CDB implementations, data formats and platforms is necessary by incorporating their requirements, scenarios and use cases.
• Run-time performance: Meeting the performance requirements of run-time SE generation for M&S is essential for the OGC CDB standard. This standard improves the online performance by using one unique data repository which allows to process and modify online sensors, data formats, and platforms in real-time and in the different level of details.
• Interoperability: Geospatial interoperability is the ability for various systems to interact with each other at different levels of geospatial information structures, semantics, systems, and services. Interoperability between heterogeneous data sources is essential to advancing data access and collaborations in the OGC CDB datastore which contains geospatial data, sensor data, decision support services, and analytical functions into the SE.
• Reusability: One of the promises of the OGC CDB standards is the possibility of reusing geographic data and software procedures. Reusability of data can be viewed as a way to lower the costs of data acquisition and enrich the basis for performing the geographic analysis. The M&S end-user community increasingly requires re-usable “plug and play” SE database.

2.2. Challenges

The critical challenge in developing the OGC CDB standard is meeting the requirement of both high-performance runtime synthetic environment generation and a comprehensive repository for different features of the terrain database for the M&S application. To address this challenge, the OGC CDB SWG multidisciplinary team carried out a study aimed at (i) Review and survey relevant standard documents in order to identify best approaches; (ii) Design the baseline of the project using the existing CDB specifications and resources; (iii) Identify the common architectural components shared between the CDB specifications and the OGC standards and aligned different technical components and vocabularies between them; (iv) Design and propose a conceptual model and architecture for the new standards; and (v) Provide an in-depth analysis and verification of the guideline for the further specifications harmonization. The work which is in progress by the OGC CDB SWG will provide innovative information, conceptual models, open standards, and methodologies that can help both industry and government agencies to efficiently manage various types of geospatial data in dynamic and online simulations systems.

2.3. CDB Use Cases

The CDB open standard enables various application scenarios for visualization, planning, education, training, modeling, and simulation. A list of various projects using a CDB datastore implementation can be found in [20]. As an example, city planners can access terrain data for the design, planning, and evaluation of various development scenarios during the early stages of the project. One use case of this application is urban simulation model that was used in the redevelopment planning of downtown Sunnyvale, California [21]. This real-time simulation environment enables urban planners, city officials and citizens to visualize and evaluate new developments before they are approved for construction. The City of Sunnyvale's 3D model is approximately eight city blocks and consists of various urban features such as buildings, streets, shopping center, train station, mall, parking, bus shelters, landscaping, and pedestrian walkways. This 3D model is a fully interactive simulation for public consensus development. For creating a CDB compliant datastore in this project, various layers of information have been utilized such as digital parcel maps, aerial photographs, site plans and photographs from the city (Figure 1a). Besides, a digital camera was used to capture texture images, such as building facades. Also, some virtual elements have been added to the model, such as an animated fountain, an outdoor car and virtual people producing an attractive urban scene. Within the urban simulation model, users can choose from three different navigation methods including a fly mode, a walk mode and a fixed path mode for unattended viewing. During the virtual walk-through of the site, users can make design changes to the downtown plans-in essence. After modifying the datastore, the simulator clients which share a CDB are notified about the changes and updates. This provides a 3D SE that is persistent and entirely correlated across all simulation federates.

Another example which applied OGC CDB data structure is a terrain data repository to facilitate the design, planning, preparing, conducting and assessment of events that provide collective Joint Training (JT) for combatant commanders and services [22]. To support the JT applications, the CDB terrain database consists of the earth’s surface at a 1:250K scale (Figure 1b). This global repository is accessible to any user with a valid operational need and access. Map layer information may include geographical features, population demographics, political and economic features, infrastructures, operational limitations (e.g., rules of engagement (ROE), no-fly zones), environmental conditions, toxic material locations, International Governmental Organizations or Non-Governmental Organizations, and knowledge of capabilities or intent of forces [23]. In another scenario, terrain trafficability could be handled by a new SE simulation that dynamically calculates soil moisture content as a function of localized rain precipitation and soil types/composition. A second simulation would then derive the resulting soil physics and determine vehicle wheel slippage across the varying terrain conditions. The modification/notification approach is well-suited for a broad gamut of SE simulations; however, some simulations are very data intensive and would require excessive broadcasting bandwidths to other federates. In such cases, these dynamic simulations would have to be replicated in the other client-devices of the federation. Other examples of this include the varying effects of weather [6] (local winds, temperature, humidity, particulates, etc.) and oceans (currents, temperature, etc.).

Another example is a cloud-based Terrain Generation Service detailed in the primer (OGC CDB 1.0 Volume 0) [24] which is an excellent reference for a recently deployed constructive and virtual simulation using OGC standards [25]. An OGC CDB compliant datastore contains geospatial data that represents the synthetic 3D natural environment, man-made features, dynamic (moving) objects, the ocean surface, and floor. The objective of this paper is to present an overview of the OGC CDB 1.0 Standard, which is an interoperable and high-performance open geospatial standard for dynamic SE representations.

3. OGC CDB Conceptual Model

The OGC CDB conceptual model presents the essential components of the core standard (Figure 2). This model can be used as the basis for the OGC CDB standard in a variety of application domains, along with its requirements, extension, file-based structure, data formats, access, and the discovery of services. 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 datastore. One of the critical roles of the conceptual model is to identify conceptual gaps and problems of interoperability between CDB and other OGC standards. The CDB conceptual model is described using UML (Unified Modeling Language) package diagrams and could be implemented in Oracle, PostGIS or most any database software. The CDB core document defines how to implement the conceptual model using a UNIX or similar file system [14].

The CDB datastore structure provides efficient access to its contents. The main properties of the CDB datastore UML diagram are listed in

Table 1. The main properties of Unified Modeling Language (UML) Package diagram of the Open Geospatial Consortium (OGC) CDB datastore.

Name	Definition	Data Type & Value	Multiplicity
Tile	Geographically divides the world into geodetic tiles (bound by latitudes and longitudes), each containing at least a dataset.	Dataset type.	One or more (mandatory)
LOD Hierarchy	Each dataset layer has a hierarchy of data layers describing different level of details.	Hierarchy of raster, vector and 3D models.	One (mandatory)
Dataset	It defines the basic storage unit used in a CDB datastore.	Layers of data	One (mandatory)
3D Models	It includes 3D representations of static or moving features such as buildings, pylons and posts, aircraft and other moving platforms. 3D models have various model components	Model data formats supported in the CDB standard (e.g., OpenFlight 1)	Zero or more (optional)
Imagery	There are various imageries in a CDB datastore such as representation of geo-referenced terrain, elevation, and texture.	Image data formats supported in the CDB standard (e.g., GeoTIFF, JPEG, etc.)	Zero or more (optional)
Vector Features	This includes all the vector feature datasets in a CDB which are defined based on the feature codes.	Vectors data formats supported by the CDB (e.g., shapefile, etc.)	Zero or more (optional)
Elevation	It is depicted by a grid of elevation data elements at regular geographic intervals, or Triangulated irregular network	Grid of terrain altimetry data	Zero or more (optional)
Metadata	A number of CDB XML files that include the default hierarchies, naming, values to be used by client devices.	XML association	One or more (mandatory)

¹ OpenFlight is a format supported widely in modeling and simulation community for dynamic and static 3D model. Also the texture of those models can be described as rgb format.

.

The CDB storage structure allows efficient searching, retrieval, and storage of any information contained within a CDB datastore. As shown in Figure 3, the storage structure portion of the CDB datastore relies on three essential concepts to organize geospatial data: Tiles, Layers (or datasets) and LOD which are described here:

• Tiles: Tiles organize the data into zones defined by location with respect to a WGS84 reference system [24]. The CDB Standard geographically divides the world into geodetic tiles (bound by latitudes and longitudes), each containing a specific set of data layers. The geographic granularity is at the tile level while in each tile, the information granularity is at the dataset level defined by layers.
• Layers: The CDB Standard datastore model is also logically organized as distinct layers of information. Layers organize different types of data in a tile. Each layer has a different set of data such as satellite image, elevation, vector features and models (such as 3D and Radar Cross Sections models), which are represented by their respective datasets. The layers are independent from each other (i.e., changes in one layer do not impose changes in other layers).
• Levels-of-Detail: 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 is represented in an LOD hierarchy in accordance with the availability of source data.

A CDB-compliant datastore can be implemented using open-source and proprietary data formats to handle modifications of an SE representation in real-time. As an example, CDB internal datastore can be represented based on the following commercial data formats endorsed by the simulation database industry, namely:

• GeoTIFF [26]: for the geo-referenced representation of terrain, altimetry, and terrain surface characteristics relevant to simulation.
• OpenFlight [27]: for the representation of 3D dynamic models and RGB format for the 3D model’s textures.
• Esri Shapefile [28]: for the instancing and attribution of the 2D/3D vector data and radar cross sections, line and polygon features.
• JPEG [29]: for any representation of terrain raster imagery comprising a well-defined and accepted compression method.
• XML [30]: for saving metadata, feature data dictionary, default values, configuration and version files.

CDB uses the WGS-84 earth model to provide geodetic interoperability for different applications and also avoid the coordinate transformation in the real-time application. The CDB standard also makes provision for the representation of moving models. The representation of moving models is comprehensive and goes well beyond other visualization standards because it makes arrangements for the standardized simulator naming conventions, material and feature attributes, radar/laser reflectivity, lighting systems, special effects, etc. The current version of CDB uses a consolidation of data dictionaries from DIGEST, DGIWG, SEDRIS, and UHRB. Also, it is possible to extend the CDB Feature Data Dictionary (FDD) by using the extension capabilities and adding the new feature codes into the FDD XML or add a new attribute into the Vector Attribute schema file to access additional feature codes/attributes.

3.1. CDB Datasets and Their Structure

The CDB is composed of several datasets that share a common structure. The following sections present the general organization and structure of the CDB datasets. The UML diagram in Figure 4 describes how the data layers is categorized in tiles, and LODs. This UML Diagram is the basis for the CDB geospatial data categorization.

This diagram is the general data organization for the CDB. The main properties of the CDB general data organization UML diagram are listed in

Table 2. The main properties of the UML diagram of the OGC CDB general data organization.

Name	Definition	Data Type	Multiplicity
Raster Dataset	Data elements are organized into a regular grid evenly positioned. Raster Datasets always have a fixed number of elements corresponding to their LOD spec.	Raster data formats supported in CDB Core Standard for elevation, imageries, texture and grid data.	Zero or more (optional)
Vector Dataset	The point, line, and area features are organized into several Vector Datasets and into LODs. For each LOD, the maximum number of points allowed per Tile-LOD and the resulting average Feature Density is defined.	Vector data, RMDescriptor, GSFeature, GTFeature, GeoPolitical, VectorMateria, RoadNetwork, RailRoadNetwork, PowerLineNetwork, HydrographyNetwork	Zero or more (optional)
Model Dataset	It includes 3D GTModel, GSModel, MModel & 2D Model or cultural feature such as air platforms, buildings and pylons and posts. 3D models have various model components.	OpenFlight models, GSModelGeometry, GSModelTexture, GSModelSignature, GSModelDescriptor, GSModelMaterial, GSModelInteriorGeometry, GSModelInteriorTexture, GSModelInteriorDescriptor, GSModelInteriorMaterial, GSModelCMT, T2DModelGeometry	Zero or more (optional)
Navigation	Navigation library is composed of a single dataset.	NavData	Zero or more (optional)

.

3.2. CDB File Folder Structure

This section of the paper describes how a current version of a CDB conformant datastore uses the computer’s native file system to store data in files and directories. An important feature of the CDB Standard is that all CDB file names are unique and that the filename alone is sufficient to infer the path of the file. This name indexing method is an essential performance factor for the simulator client to find the path of a specific feature or dataset by its name. The CDB datastore is composed of several datasets that usually reside in their directory; however, some datasets share a common structure. The top-level directory of the CDB datastore follows the following structures:

• \CDB\: This is the root directory and does not need to be “\CDB\” and can be any valid path name on any disk device.
• \CDB\Metadata\: This directory contains the XML metadata files which are global to the CDB.
• \CDB\GTModel\: This is the entry directory that includes the Geotypical Models Datasets.
• \CDB\MModel\: This is the entry directory that consists of the Moving Models Datasets.
• \CDB\Tiles\: This is the entry directory that contains all tiles within the CDB instance.
• \CDB\Navigation\: This is the entry directory that includes the global Navigation datasets.

Most of the CDB datasets are organized in a tile structure and stored under \CDB\Tiles\ directory. The tile structure facilitates access to the information in real-time by any runtime client-devices. However, for some datasets such as Moving Models or Geotypical Models that require minimal storage, there is no significant advantage to be added into such a tile structure. Such datasets are referred to as global datasets; they consist of data elements that are global to the earth.

3.3. CDB Feature Codes

OGC CDB 1.0 standard comes with a set of pre-defined feature types (which is listed in FDD), in the form of an XML file. The list of feature types is in “/CDB/Metadata/Feature_Data_Dictionary.xml”. The OGC CDB 1.0 uses a convenient categorization of features (based on FACC code [31] which is now called as “CDB feature code”). The first character in a 5-character CDB feature code (e.g., “CCnnn”) represents a category of features, the second represents a subcategory of the current category, and the last three characters represent a specific feature type in the subcategory. To provide an even better classification of features, the CDB defines an additional attribute called feature sub-code (FSC) to the feature codes. By extending the feature code hierarchy structure in this manner, it is possible to define a broader set of feature types. The sub-code value and its meaning depend on the feature code and varies for different feature types. The feature code structure and its data model are presented in Figure 5.

The current CDB FDD is a consolidation of the DIGEST, DGIWG, SEDRIS, and UHRB dictionaries. These standards are commonly used for the attribution of source vector data in a broad range of simulation applications (Figure 6). These Feature Codes were supported by the DGIWG FDD and the ISO/IEC 18025 data dictionaries.

The feature codes (such as AL015) is an indexing mechanism for CDB to access and navigates to the Geotypical (GTModels) 3D models more efficiently. Geotypical Datasets (directory, geometry, and description) are likely to be referenced multiple times and are stored under a feature code based hierarchy. Here is an example:

• \CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Features\015_Building\D500_S001_T001_AL015_050_Church-Gothic.flt.

The indexing approach greatly simplifies the management of the model library since every model has a pre-established location in the library. Also, they are used in CDB for naming the files in the CDB folders. In GeoSpecific models, feature codes are used for the file naming in the following data layers: 300_GSModelGeometry, and 305_GSModelInteriorGeometry datasets. The file name is as follows:

• Geocell_DSC_CS1_CS2_LOD_UREF_RREF_FACC_FSC_MODL.ext.

Broader feature codes can be defined by other OGC standards or a prototype which tests some new features. For example, since the previous versions of CDB, 635 new feature codes have been added to its feature data dictionary. The new Feature Codes use the same coding approach as used in the previous CDB versions, namely a 5-digit FACC supplemented by a 3-digit FSC to be compatible with the other versions of CDB. When a new feature is added to the FDD.xml, it is good to denote the recommended dataset property. While the wording is recommended, there is a runtime determinism element to this recommendation. If a client wants to find a particular set of features, they can look for all the features in a dataset. Otherwise, they would need to load every dataset and search, which defeats a major purpose of CDB.

3.4. CDB Attribution Schema

A set of attributes characterizes each vector feature. Attribution schemas are the method of handling these different types of attributes. The OGC CDB 1.0 standard provides three attribution schemas to represent the attributes of a feature:

• Instance-level attribution schema
• Class-level attribution schema
• Extended-level attribution schema

Each of the schemas offers different trade-offs in the manner attribution data is accessed and stored. Each of these schemas is motivated mainly by the storage size considerations and flexibility of the attributes which are assigned to individual feature or a group of features. For example, a CDB can use Esri Shapefiles to represent vector data and attributes. As per Esri Shapefile Technical Description, the set of attributes of vector features are stored in dBase III+ files. Attributes are either mandatory, optional, not permitted or not used (Figure 7).

In addition to instance and class level attributes, one can use the “Extended-level” attributes. There are two XML files to define CDB extended attributes: Geomatics (for geospatial attributes whose governed by standard organizations), and Vendor (for attributes whose are governed by one or more vendors) Attributes. The intent behind those XML Attribute files is to provide the data necessary to interpret feature attributes. The following example illustrates how to define an extended attribute (Figure 8).

3.5. CDB Versioning

A CDB Version is a collection of CDB and user-defined datasets. A CDB Version contains data belonging to a single version of a CDB conformant database. Versioning mechanism describes how to create, delete, or edit a CDB dataset. One CDB Version may refer to another one, which is the basis for the CDB File Replacement Mechanism. The concept of a CDB Version is illustrated using the following UML diagram (Figure 9).

The diagram shows that a CDB Version contains CDB datasets. Besides, the diagram states which CDB Version Number has been used to build the CDB content; finally, the CDB Version has a reference to another CDB Version. This reference allows the creation of a chain of CDB Versions. By chaining two CDB Versions together, the user can replace files in a previous CDB Version with new ones in a newer CDB Version datastore. The diagram in Figure 9 shows that a CDB Extension inherits all the attributes of a CDB Version and adds its own attributes, a name and a version number (of the extension). The client application checks the name attribute to recognize and process the known CDB Extensions and skip the unrecognized CDB Extensions.

4. Alignment Perspective of the OGC CDB with Other OGC Standards Baseline

Alignment of CDB specifications with different OGC standards baseline reduces the complexity of discovering, transforming, and streaming geospatial data. It also shows how open standards enable the direct flow of real-world maps, earth images, sensor data, ocean data, and weather data into M&S applications. The OGC CDB datastores can be queried and accessed over the web using existing OGC standards such as Web Map Service (WMS) or Web Feature Service (WFS) to permit visualization of the content outside of the traditional simulator hardware environment [32]. The file-based architecture of CDB makes it compatible with restful web services. The following figure (Figure 10) shows OGC CDB Web Coverage Service (WCS) prototype which offers multi-dimensional coverage data access by a client request. This experiment is based on a freely available CDB sample dataset included in [18].

Although a CDB compliant datastore is accessible using OGC web services, alignment refers to the degree of match between CDB content and the other OGC standard baselines. Given the wide extent of OGC standards, it is challenging to achieve a desirable degree of match. This fact points to the need to study the degree of alignment both at the vocabulary level and at the component level. In the current version of the CDB standard, initial harmonization with the OGC and ISO standards baseline is established. For example, the CDB simulation and modeling community terms and definitions have been replaced with OGC/ISO terms and definitions. Further, the standard documents have been reorganized and structured to be consistent with the OGC Modular Specification Policy. However, there is an urgent need to further harmonize and align this standard with the OGC baseline and other IT best practices. This paper presents a perspective of future versions of the OGC CDB and what the steps are for humanizing the OGC CDB standard with the other OGC/ISO standards baseline. While the goal of first CDB standard is to maintain compatibility with existing simulators, the next versions need to be harmonized with the latest versions of OGC/ISO standards baseline and efficiently deliver to the next generation of simulators.

4.1. Vocabularies and Feature Code Alignment

CDB has been used in the M&S community for many years without full consideration of M&S requirements in the general geospatial community. One result is that there are different vocabularies used in CDB and the OGC. These dictionaries need to be aligned. For example, a cross-reference table can be used to map the terminologies between two domains and how they relate to each other, what their definitions are and how they differ. The cross-reference table includes matchings (predicting the similarity of terms) and mappings (typically expressing logical equivalence or inclusion among the terms) [14]. In this document, an effort was invested to begin aligning terminology and concepts, specifically in the coordinate reference system discussions and requirements. Another attempt is currently in progress in OGC Testbed 13 [32] to evolve beyond the current use of CDB feature codes and attributes. In this work, we have been trying to explain the alignment of CDB feature data dictionary the advanced design of feature data dictionaries such as the NAS (National System for Geospatial-Intelligence (NSG) Application Schema) feature and Attribute encoding. The current CDB feature codes have been used for indexing of 3D models in the CDB file hierarchy. Therefore, instead of aligning the two model, a NAS schema profile was generated for CDB and a set of cross-reference tables used to find the mapping between the two feature code models.

4.2. Component Alignment

Alignment and harmonization of the CDB standard with the OGC standards baseline at the component level promote interoperability among the CDB, other OGC standards and a wide variety of different applications. Different technical components between OGC and CDB will be aligned whether the alignments are one-to-one, or can involve more complex mappings. Comparative analysis of two domains also provides a list of recommendations/issues for the future versions of the OGC CDB to expand the CDB in a possible OGC based standard. This extension mechanism includes building, specifying, and releasing a new standard(s) for CDB and an extension API (Application Program Interface) to convert CDB specifications into OGC standard(s). Future versions of the OGC CDB standard will enhance the core CDB specification and enable improvements to the application(s) that implement to the CDB standard. AS part of the revision process, an enhanced information model architecture will be designed and proposed for CDB. The overall perspective of the future version of the OGC CDB standard will be split into a core module and extensions. The core module comprises the basic concept, and each extension module covers a specific thematic field such as for flight simulation applications. According to dependency relationships among modules, each module may also import the related CDB modules. Figure 11 shows an example UML diagram of the modular architecture of the future OGC CDB conceptual model in the case of flight simulation application.

The perspective of the future OGC CDB core module is presented in Figure 12. The goal of this conceptual model is to provide a core model, which can be aligned with other OGC standards baseline. For example, the OGC web or data services can be encoded to specify a fully configured service set which can be exchanged (with a consistent interpretation) among clients. There are no limitations on certain types of processes or data. Also, City GML and Geopackage can be integrated into CDB as a new data source. Another topic which can be considered in CDB is to provide support for converting WGS 84 into other Discrete Global Grid Systems (DGGSs) or coordinate reference frames. The critical issue which needs a careful attention for the future version of CDB is that all the extension and conversion mechanism have to run in real-time. Therefore, a detailed performance test is required to investigate the run-time synthetic environment generation capability of each additional modules.

5. Conclusions and Future Work

This paper presents key information on the OGC CDB 1.0 standard in response to the requirements of the M&S community for an interoperable datastore solution with geographically accurate data for generating a 3D synthetic environment. This dataset enhances runtime performance and provides simulation realism for client-devices to retrieve relevant information simultaneously. Such a datastore can only be created through the effective employment of standardization, training, exercises, learned lessons, demonstrations, tests, and trials. This paper provides the basis for M&S community to assess and evaluate the OGC CDB 1.0 standard and to apply it for their SE datastore. The application of the open CDB standard to future simulator architectures will significantly reduce development, update and configuration management time while improving runtime performance, interoperability, and integration between geospatial data sources. Compatibility of the OGC CDB standard with the OGC standards baseline makes them widely acceptable to major geospatial data/software vendors and stakeholders. Furthermore, OGC-compatibility reduces the complexity of discovering, transforming, and streaming geospatial data from the Internet into the simulation environment. This OGC CDB geospatial datastore facilitate incorporation of the standardized OGC services through uniform access methods. It also shows how open standards enable the direct flow of real-world maps, earth images, sensor data, ocean data, and weather data into M&S applications.

The OGC CDB SWG anticipates that additional standardization will be required to target other simulation applications. The following future work items are envisioned:

• Describe explicitly how the CDB model may or may not align with the OGC DGGS standard.
• Provide best practice details on how to use WMS, WFS, and WCS to access the existing CDB datastores. This work is under development in the OGC Testbed 13 [32] to better understand the implications of these experiments; other OGC services such as SOS (Sensor Observation Service) should be considered as well for future development of the CDB.
• Extend the supported encodings and formats for a CDB database to include the use of the OGC GeoPackage, GML, 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 understand the implications of these decisions better.
• Further, align CDB terminology to be entirely consistent with the OGC/ISO terminology.
• Consider replacement(s) for the feature data dictionary with the application schemas (e.g., NAS [32]) which described the features and attributes in the different domain of application with their associations and relationships.

Making these enhancements will allow for the use and implementation of a CDB structured datastore for application areas other than military M&S.