Navigation Library Dataset Best Practices | OGC

140 © 2015 Open Geospatial Consortium 141 © 2015 Open Geospatial Consortium Chapter 4 4 CDB File Formats The CDB Specification internal formats are based on the formats used by industry-standard toolsets. As a result, the Specification eliminates the time-consuming off-line database assembly and database publishing process usually imposed by each of the clients. Refer to Section 1.6.4.2, Database Generation Flow for a more comprehensive discussion of this topic. Furthermore, the translation step into CDB format is typically trivial since the CDB Specification is based on industry-standard native tool formats. The CDB Specification permits any CDB to run “as-is”, without any offline assembly aka compilation, translation, conversion, on any CDB-compliant simulator client-device platform. This allows the simulator user community AND the database creation community to freely exchange CDBs across simulators and database generation facilities either through the exchange of physical media or entire storage subsystems or via network. As a result, a CDB can be run and exchanged without change on any CDB-compliant simulator client-devices or any database generation workstations, regardless of the computer platforms, simulator system software. The storage structure of the CDB Specification allows for efficient searching, retrieval and storage of any information contained within the database. The storage structure portion of the Specification is defined in Chapter 3. This chapter concerns itself with the formats used by the CDB. The formats used by the CDB Specification are: 1. TIFF .tif: used for the representation of all datasets whose inherent structure reflects that of a two-dimensional regular grid in a Cartesian coordinate system. The primary use of TIFF within a CDB is for the representation of terrain elevation and raster imagery. To qualify as a CDB-compliant TIFF reader, the reader must satisfy the requirements described in Appendix B of this Specification. It is to be noted that the LZW compression algorithm within the TIFF format is supported and encouraged by the CDB Specification when the data type of the content of the file is of integral type. As a consequence, it is strongly recommended to compress TIFF files containing integer values but to avoid compression if the file contains floating-point values. 2. GeoTIFF .tif: used for the representation of all datasets whose inherent structure reflects that of a two-dimensional regular grid of a Geographic coordinate system. The primary use of GeoTIFF within a CDB is for the representation of terrain elevation note: the use GeoTIFF is preferred over TIFF in the case of terrain elevation. CDB-compliant GeoTIFF readers do not concerns themselves with any of the GeoTIFF specific tags because the CDB Specification provides all of the conventions to geo-reference each geographic dataset. However, it is 142 © 2015 Open Geospatial Consortium strongly recommended that database generation tools be fully compliant to GeoTIFF; this provision eliminates the need for the tools to be aware of the CDB conventions governing the content of each geo-referenced dataset. 3. SGI Format .rgb: used for the representation of 3D model textures. The file format allows for the representation of an image with 1, 2, 3, or 4 channels. A single channel image represents a grey-shaded texture; a two- channel image represents a grey-shaded texture with an alpha component providing the transparency; a three-channel image represents a color RGB texture; finally, a four-channel image is a color RGB texture with an alpha channel providing the transparency. CDB-compliant RGB readers must be fully compliant with the SGI Image File Format Specification. Its use is limited to 3D models. 4. JPEG 2000 .jp2: used for the representation of an image encoded in accordance to the JPEG 2000 standard. CDB-compliant JPEG 2000 readers must be fully compliant with the JPEG 2000 standard while reading such still image file types. JPEG 2000 encoded images can be used for the representation of geo-referenced terrain imagery with some degree of compression levels and is only applicable in the case of terrain raster imagery. 5. OpenFlight .flt: used for the representation of 3-dimensional geometric representation of all models statically positioned cultural models, moving models. To qualify as a CDB-compliant OpenFlight reader, the reader must satisfy the requirements described in Appendix C of this Specification. 6. Shape .shp, .shx, .dbf, .dbt: used for the representation and attribution of the vector feature datasets in a CDB. To qualify as a CDB- compliant Shape reader, the reader must satisfy the requirements described in Appendix D of this Specification. 7. Extensible Mark-up Language .xml: used to store metadata that describes CDB versioning, describes CDB Composite and Base material structure, defines CDB light type naming conventions and hierarchy, and defines CDB model component hierarchy. 8. Cross-platform and interoperable file storage and transfer format .zip: used to archive and store geospecific 3D model datasets. Appendices B, C, D of this Specification define the required compliancy of CDB readers for the TIFF, OpenFlight and Shape formats. Appendix T describes the JPEG 2000 file format and the last section of Appendix D describes the dBASE III+ file format used by the Shapefile standard. For all other formats used by this Specification, CDB readers must be fully compliant. 143 © 2015 Open Geospatial Consortium Table 4-1: CDB File Format Compatibility File Format Versions Supported by CDB CDB Client-device Behavior for Prior Versions .tif 6.0 Ignores data .rgb 1.0 Ignores data .jp2 1.0 Ignores data .flt 16.0 Ignores data .shp, .shx ERSI White Paper, July 98 Ignores data .dbf, .dbt dBASE III+ and above Ignores data .xml 1.0 Ignores data .zip 6.3.1 Ignores data 145 © 2015 Open Geospatial Consortium Chapter 5 5 CDB Datasets This chapter provides the description of the content of CDB datasets, except OpenFlight and RCS models that are covered in the following chapters. Chapter 5 also provides the Component Selectors necessary to complete the file names associated with all CDB datasets.

5.1 Metadata Datasets

Metadata datasets contain information, global to the CDB that define its structure, naming hierarchies, default values, allowable values, and status. All metadata files are formatted using eXtended Markup Language XML files and their XML schemas can be found in the \CDB\Metadata\Schema\ folder delivered with the Specification. The table below lists all metadata files that are allowed and defined by the Specification. Note that a dataset code and component selectors are assigned to each metadata file eventhough these codes do not participate in the construction of their file names. Dataset codes are assigned to metadata datasets for consistency with all other CDB Datasets. Table 5-1: Component Selectors for Metadata Datasets CS1 CS2 File Name Dataset 700, Metadata 001 - Lights.xml 002 - Model_Components.xml 003 - Materials.xml 004 - Defaults.xml 005 - Specification_Version.xml Deprecated 006 - Version.xml 007 - CDB_Attributes.xml 008 - Geomatics_Attributes.xml 009 - Vendor_Attributes.xml 010 - Configuration.xml Dataset 701, Client-Specific Metadata - - Lights_xxx.xml For client-specific metadata, the Specification only reserves one dataset code but no component selector. The mechanism is kept for backward compatibility with previous version of the Specification. However, its use is strongly discouraged because it defeats the very intent of the CDB, which is to promote correlation between client devices by having a single source of data. 146 © 2015 Open Geospatial Consortium

5.1.1 Light Name Hierarchy Metadata

The light name hierarchy for the CDB is described in detail within the table found in Appendix E of this Specification. For run-time access of this data, clients must be able to retrieve such information. To this end, the Lights Hierarchy Definition metadata is stored in an XML file in the metadata CDB directory as described in Section 3.1.1, Metadata Directories. The name of the file is “Lights.xml”. The XML file provides a description of the entire naming hierarchy, including the hierarchical relationship of the levels with respect to each other and the position of each light type within this hierarchy. In addition to the name of each light type, the “Lights.xml” file contains a unique code with each light type. In the case of light features Airport Features - Lights and Environmental Lights tiled datasets, the light type code provides a storage-efficient means to attribute each light, since only the code is used to attribute light features. Database tools are required to map the light type name string provided by the modeler into a light type code. In the case of light features that are part of OpenFlight models, the light type name string provided by the modeler is used “as-is” within the model to attribute each of the light features. Client-devices are required to internally build and initialize a table of light properties and characteristics for their respective use. This table could be indexed at runtime using the light type code. The table can be built at CDB load time and should match the device’s inherent capabilities and level-of-fidelity; this flexibility can be achieved because the “Lights.xml” file communicates the lights naming hierarchy to the client-devices. The client-devices are required by the CDB specification to ensure that properties and characteristics of lower-tier names in the light point hierarchy inherit the properties and characteristics of the higher-tier names in the light name hierarchy. This feature allows modelers to add new light names to the light name hierarchy and be assured that the new light names will immediately inherit all of the properties and characteristics of the parent names even if the simulator vendor does not update any of the client-devices. The light type code can range from 0 to 9,999. The light type codes are used by the Airport Features - Lights and Environmental Lights tiled datasets of the CDB. It is up to the CDB creation tools to ensure that the light type code does in fact correspond to the light type name assigned by the modeler. Below is a small sample of the CDB light name hierarchy in XML format. 147 © 2015 Open Geospatial Consortium Lights Light type=Light code=0 Description All Purpose Generic light Description Light type=Platform code=1 Description Platform light Description Light type=Air code=2 Description Aircraft light Description Light type=Aircraft_Helos code=3 Description Light for Aircraft and Helicopters Description Light type=Anti-collision code=4 Description Anti collision light – normally red flashing Description Light type=Bottom_Light code=5 Description Anti-collision found on bottom of the fuselage Description Light type=NVG_Bottom_Light code=6 Description Anti-collision found on bottom of fuselage in NVG mode Description Light Light Light ... other light definitions of type Platform-Air-Aircraft_Helos Light ... other light definitions of type Platform-Air Light ... other light definitions of type Platform Light Light Lights Note that light code numbering need not be consecutive. Light codes have a one-to-one association with light types; consequently, the light codes are unique among all light types.

5.1.1.1 Client Specific Lights Definition Metadata

Client-devices use the light type code as an index to look-up the client-specific properties and characteristics of each light type. This approach is client-device independent because the device-specific client’s rendering parameters are local to its implementation. As a result, modelers need not bother setting or even understanding the many parameters specific to each light type and to each client-device type. The CDB specification also offers a complementary approach to modifying the appearance of lights. This approach provides basic control over light intensity, color, lobe width and aspect, frequency and duty cycle to client devices. The approach also permits a modeler to add new light types to the CDB light hierarchy. Example: