OGC Testbed-13: CDB Engineering Report

This Engineering Report addresses the following requirements:

The work and experiments completed in the OGC Testbed 13 CDB sub-thread are described in this CDB ER document. This ER was reported to the CDB SWG on several occasions and the current key findings of the CDB sub-thread are summarized here:

This ER is mainly of interest to the CDB SWG and the CDB implementation community. In particular, any Change Request Proposals created as a result of the work will be discussed in the SWG. The work documented in this ER is important for CDB SWG as it applies to the CDB 1.0 standard, expands its feature codes/attribution schema using NAS profile, and accesses the CDB data store using OGC web services. Due to the strong link to 3D information streaming and NGA’s NSG application schema, the work is also expected to be of interest to other OGC Domain Working Groups (DWG) such as the 3D Information Management (3DIM) DWG, Defense & Intelligence DWG, Distributed Simulation and Gaming DWG, OGC Web Services and profiling.

All questions regarding this document should be directed to the editor or the contributors:

The following future work items are envisioned:

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.

The following figure (Figure 1) describes the CDB workflow executed in Testbed 13.

This document contains the following chapters:

The sample data set used in the CDB sub-thread is the NYC dataset created by FlightSafety International Inc. solely for use by the National Geospatial-Intelligence Agency (NGA) in support of OGC’s Testbed 13 effort. The CDB is physically arranged on disk into the following top level folders:

The Coordinate Reference System (CRS) of this datastore is WGS 84 (World Geodetic System, 1984). The New York data set contains two CDB Geocells: N40-W74 and N40-W75. The demonstration data store has thirteen tiled data layers: Elevation, MinMaxElevation, MaxCulture, Imagery, GeoSpecificFeatures, GeoTypicalFeatures, VectorMaterial, RoadNetwork, RailRoadNetwork, GeoSpecificModelGeometry, GeoSpecificModelTexture, GeoSpecificModelDescriptorbuildings and Hydro. The CDB sub-thread experiments make use of the Elevation, Imagery, Geotypical, and Geospecific model data layers. Each data layer has its own LoDs (level of Details). A CDB-compliant datastore currently uses ShapeFiles for the representation and attribution of vector feature datasets. Aligned with the capabilities of the ShapeFile format, vector features consist of points, lines and polygon features. The raster data layers such as Elevation and Imagery are in GeoTIFF format. The format of the 3D models, the buildings and trees with geometry & textures, is OpenFlight. OpenFlight is a format widely supported in the modeling and simulation community for dynamic and static 3D models. The texture of those models can be described as .rgb format.

In the NYC CDB data version.xml file, it has been denoted that the dataset is compatible with the CDB 3.2 specification. On the other hand, in the Specification_Version.xml file of the NYC CDB datastore, it was mentioned that the CDB Database Version is 3.0 and released in September 2008. After evaluating most of the datasets inside the CDB it was concluded that this sample data store in Testbed 13 was generated based on CDB 3.0 specifications.

Regardless, there are some enhancements in the OGC CDB 1.0 compared CDB 3.2 specification such as updating the terms and definition to be consistent with the ISO 19xxx (Geomatics) series of standards, specifically ISO 19111 Spatial referencing by Coordinates and ISO 19017 Spatial Schema which is published as the OGC CDB 1.0 Standard, Volume 3: OGC CDB Terms and Definitions. Also, the metadata files and folder updated (e.g., corrections to the Feature Data Dictionary, the addition of a Priority field to the Feature Data Dictionary, additional Base Materials for building interiors, changes to the CDB Attributes, the addition of new airliners and countries codes). Handling of Topological Networks, Model LoDs and significant size and some of the datasets had minor changes as well. The list of these updates can be found in the OGC CDB Wiki page [6]. From the CDB 3.0 to the CDB 3.2 specification, updates are more significant and fully described in the OGC CDB Best Practices documents ([7] and [8]).

The underlying use case for the work documented in this report is that:

This section discusses the CDB-related Technology Integrated Experiments (TIEs) conducted in Testbed 13.

Conceptual modelling is a structural methodology for describing how the components of a CDB data store will be implemented based on the modular specification design pattern. The OGC CDB conceptual model presents the important components of the core standard (Figure 2). This model, along with its requirements, extension, file-based structure, data formats, access, and the discovery of services, can be used as the basis for the OGC CDB standard in a variety of application domains. 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. The following figure (Figure 2) describes the CDB original conceptual model and consists of all the UML files related to the CDB’s structure. The CDB conceptual model could be implemented in Oracle, PostGIS or almost any other database software.

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

The OGC CDB Standard relies on three important means to organize the synthetic environmental data: a) Tiles which organize the data into zones defined by its location with respect to a WGS84 reference system; b) Layers (or datasets) which organize different types of data in a tile; and c) Levels of Detail (LoD) which organize the data in each layer of each tile by its detail. The UML diagram in Figure 3 describes how the data is categorized into tiles, layers and LoDs. This is the basis for the CDB geospatial data categorization. A CDB database can use existing common file formats for storing data such as: TIFF/GeoTIFF (raster data), JPEG 2000 (imagery data), OpenFlight (3D models), Shape (vector data and radar cross sections), RGB (textures), XML (Metadata) and ZIP (file collection).

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

This section describes how the 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 file name alone is sufficient to infer the path of the file. This is an important 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 own directory. However, some datasets share a common structure. The top-level directory of the CDB datastore comprises of the following structures:

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

The OGC CDB 1.0 standard comes with a set of pre-defined feature types, which are listed in a Feature Data Dictionary (FDD), in the form of an XML file and specified as part of the standard. The list of feature types is defined in a Feature_Data_Dictionary.xml [1] file which is located at /CDB/Metadata/Feature_Data_Dictionary.xml. The CDB feature dictionary currently does not support a capability to express relationships between features.

The OGC CDB 1.0 standard uses a convenient categorization of features (based on FACC code 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 standard defines an additional attribute called feature sub-code (FSC). 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 by feature type. The feature code structure and its data model are presented in Figure 4.

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 5). These Feature Codes were supported by the DGIWG FDD and the ISO/IEC 18025 data dictionaries.