12 Copyright © 2017 Open Geospatial Consortium
5.2 Schemas
The following XML Schemas can be found in the OGC CDB Standard schema repository: 1. Base_Material_Table.xsd
2. Composite_Material_Table.xsd 3. Configuration.xsd
4. Defaults.xsd 5. Feature_Data_Dictionary.xsd
6. Lights.xsd 7. Lights_Tuning.xsd
8. Model_Components.xsd 9. Model_Metadata.xsd
10. OpenFlight_Model_Extensions.xsd 11. Vector_Attributes.xsd
12. Version.xsd
6. CDB OpenFlight Models
This volume of the CDB standard defines a set of conventions for representing 2D and 3D models based on version 16.0 of the OpenFlight Scene Description Database Specification as
annotated in Appendix C of this document.
The conventions presented here address the needs of several types of simulation clients including OTW, FLIR, NVG, CGF, radar, and laser, acoustic, magnetic, visual and thermal sensors.
Requirements Class - Metadata
req coremetadata
Target type Operations
Dependency OpenFlight Specification
Dependency File Management system
Requirement 1 reqcoreopenflightcrs
6.1 OpenFlight File Header
The OpenFlight Header Record contains descriptive metadata about the manner vertices are encoded, and how these vertices are applied to an earth model and a projection type. On the other
hand, the CDB standard itself mandates a prescribed set of conventions in this regard.
13 Copyright © 2017 Open Geospatial Consortium
Requirement 1
Req 1
http:www.opengis.netspecCDB1.0openflightheader-crs
As a result; the following OpenFlight Header records SHALL be set as follows: •
Projection Type:
o Flat Earth, value 0: This is the type of projection used by most CDB Models, GTModel, GSModel, and MModel.
o Geodetic, value 5: This is the type of projection used by T2DModels. •
Earth Ellipsoid Model:
o WGS-84, value 0: This is the Earth model to use with T2DModels. The field is ignored with other CDB Models.
6.2 OpenFlight Model Tree Structure
The internal structure of OpenFlight models is a tree structure that consists of nodes having child nodes as well as sibling nodes
3
. This type of tree structure is called a directed acyclic graph, or DAG. The general tree structure of a Model resembles that of Figure 6- 1: General OpenFlight
Tree Structure .
3
In Appendix C, the section called Database Hierarchy explains in details how OpenFlight organizes its graph.
14 Copyright © 2017 Open Geospatial Consortium
Figure 6- 1: General OpenFlight Tree Structure
The CDB standard uses Group Nodes to arrange Models in a hierarchical manner. This way of organizing models helps identify components of interest.
The CDB standard refers to a number of OpenFlight nodes to store meaningful data for simulation client-devices. For a complete list of nodes supported by the CDB standard, see
Appendix C. The nodes listed here are the ones referred to by one or more CDB conventions.
An example of an ancillary record is the OpenFlight comment record. A comment record may appear once, anywhere after a node’s primary record. The CDB standard relies on comment
records to extend the definition of OpenFlight nodes. Instead of using the Extension Record to create new primary and ancillary records, the CDB standard uses comments to store the extra
attributes required by the specialization of existing OpenFlight nodes
4
. Comment records were chosen over OpenFlight extensions in order to minimize any changes to the Creator tool or the
need to develop a plug-in to Creator. Using this approach, anybody can create CDB-compliant models using a plain version of Creator. Nevertheless, the development of Creator CDB plug-ins
would improve modeler’s efficiency. Such plug-ins could, for instance, offer a menu-based GUI
4
CDB-compliant readers must ignore all OpenFlight extension records.
Group node 1
LOD node 1
LOD node 2
Header node
DOF node 1
Object node 1
DOF node 2
Object node 3
Object node 4
Object node 2
Switch node
Light Point
15 Copyright © 2017 Open Geospatial Consortium
to allow modelers to enter and edit CDB comments, while ensuring that syntax and conventions are fully adhered to.
The text contained in the comment record is formatted using the XML notation.
Requirements Class – tree structure
req coretree-structure
Target type Operations
Dependency OpenFlight Specification
Dependency CDB File Management system
Requirement 2 reqcoreopenflightmodel-global-zone
Requirement 3 reqopenflight2dmodel
Requirement 4 reqopenflight2dmodel-rules
Requirement 5 reqopenflight2dmodels
Requirement 6 reqopenflightxref
6.2.1 CDB Model Tree Structure
Based on Figure 6- 1: General OpenFlight Tree Structure above, the internal structure of CDB Models resemble this one:
16 Copyright © 2017 Open Geospatial Consortium
Global Zone
Other nodes
db
...
Figure 6- 2: Internal Structure of CDB Models
Requirement 2
Req 2 reqmodel-global-zone
All CDB Models SHALL have a global zone as their root node. This node identifies the model. Global zones are defined in section 6.5.2 below.
6.2.2 T2DModel Tree Structure
A T2DModel being a collection of 2DModels, each individual 2DModel occupies its own subtree of the graph. The general structure of a T2DModel is as follow:
17 Copyright © 2017 Open Geospatial Consortium
LOD
Optional
Global Zone
...
Zone
2DModel n
Object
Face
Conformal ...
Zone
2DModel 1
Mesh
n
Mesh
1
Group
Layer 1 ...
Group
Layer 0
db
Group
Layer n
Figure 6- 3: Internal Structure of T2DModels
Requirement 3
Req 3 reqopenflight2dmodel
18 Copyright © 2017 Open Geospatial Consortium
Each 2DModel SHALL be implemented as a Model Zone section 6.5 with its own subgraph. 2DModels are disjoint and non-overlapping. .
A 2DModel is comprised of multiple layers; the layer number is expressed by the group’s relative priority section 6.3.4. Each layer has an optional LOD node followed by a fixed
hierarchy of regular OpenFlight Object, Face, and Mesh nodes.
6.2.2.1 Restrictions
T2DModels being an alternate representation of the terrain and its imagery and materials, a number of restrictions are necessary to ensure client devices can consume the dataset efficiently.
Requirement 4
Req 4 reqopenflight2dmodel-rules
A 2DModel SHALL have at least two layers, layer 0 and layer 1. Layer 0 SHALL always empty because it represents the terrain on top of which subsequent
layers are applied. Each layer SHALL be composed of exactly one OpenFlight Object node.
1. All Face and Mesh nodes share exactly the same set of graphic attributes color, textures, material, and other flags. Stated differently, the Face and
Mesh nodes provide the shape of the layer while the Object node controls its appearance.
2. Subfaces are not permitted because coplanar geometry is implemented through layers.
6.2.2.2 Node Attributes Requirement 5
Req 5 reqopenflight2dmodels
For T2DModels, node attributes section 6.12 SHALL be permitted only at the zone
19 Copyright © 2017 Open Geospatial Consortium
levels; that is, at the global zone or at the individual 2DModel zones. Node attributes are not permitted at the Group, LOD, Object, Face, and Mesh node levels.
6.2.3 The Use of Node Names
Although the CDB standard defines naming conventions for objects stored in an OpenFlight file, the standard does not constrain the OpenFlight node names themselves. Instead, the CDB
standard defines names that are assigned via XML tags stored in the comment record.
The following question arises, “Why not establish a set of CDB conventions around node names?” The answer lies primarily around constraints imposed by tools used to editcreate
OpenFlight files. Tools such as Creator require unique node names throughout the OpenFlight file. The OpenFlight format specification itself does not state that node names must be unique;
however, a tool such as Creator prevents the modeler from entering the same node name twice.
To circumvent this limitation, the CDB standard provides naming conventions through XML tags inserted in the comment record following a node’s primary record. This way of doing
things leaves modelers with the needed freedom in naming nodes. The CDB standard defines how to organize a model; all extra object attributes that do not fit in the current OpenFlight
records are stored in the comment record, including object names.
Here is an example of XML tags stored in the comment record for a Group Node.
Table 6-1: Sample XML Tag Used in a Comment Record
CDB:Zone name = zone name
All XML tags defined by the CDB standard belong to a single XML namespace that is appropriately named CDB
5
.
6.2.4 Model Master File
A Model Master file is an OpenFlight file that contains only external references to other OpenFlight files. The purpose of the master file is to ensure a Model is seen as a single “object”
even though its constituents are stored in separate files. The use of a model master file provides a convenient means for modelers to reference all of the constituent files that make up the model.
There is no other purpose associated to the master file.
The concept of a Model Master file is used in a single case, to regroup all representations all LODs of a geotypical model into a single OpenFlight file. However, the concept applies to all
5
The syntax to specify a XML namespace is
ns:element
where
ns
is the namespace and
element
is the XML element name or simply tag.
20 Copyright © 2017 Open Geospatial Consortium
types of CDB Models. The concept can also be used to regroup a model’s shell with its interior. For this reason, expect new usage of the Model master file in future version of the Standard.
The master file is useful in two circumstances: when modelers create or edit Models, and when client devices want to discover at once all constituents of Models.
For modelers, it is useful if not required to edit a model using a single source file to present a coherent view of the model as a whole. For this reason, a master file with a set of LOD-XRef
nodes is perfect to assemble and present a unified view of the model to edit.
Figure 6- 4: Typical Structure of Model Master File presents the general structure of a master file.
Group
LOD
coarsest
db
XRef LOD
finest
XRef
...
Figure 6- 4: Typical Structure of Model Master File
The value found in the Significant Size field of the above LOD nodes matches the values found in Error Reference source not found.. The next section provides details on XRef nodes
themselves.
6.2.5 Referencing Other OpenFlight Files Requirement 6
21 Copyright © 2017 Open Geospatial Consortium
Req 6 reqopenflightxref
An OpenFlight external reference XRef node is used to refer to another OpenFlight file. The reference is made by specifying the filename and its path absolute or relative. The
CDB Standard requires that all references SHALL be made using a relative path.
The XRef node and its External Reference record supports a number of options: Override flags, View-As-Bounding-Box flag, and Target Node Name. The CDB standard supports none of
these options.
Here are two cases to illustrate the use of XRef nodes.
6.2.5.1 Models Straddling Multiple Files
In the case of GTModels, GSModels, and MModels, the OpenFlight geometry can straddle multiple files. It could be seen in a moving model e.g., a helicopter whose pilot could be stored
in a separate file. In that case, the file containing the pilot resides in the same directory as the file containing the helicopter itself. The helicopter would be stored in file 1:
\CDB\MModel\600_MModelGeometry\1_Platform\2_Air \225_United_States\21_Utility_Helo\1_2_225_21_x_x_x\
D600_S001_ T001
_1_2_225_21_x_x_x.flt
The pilot would be stored in file 2:
\CDB\MModel\600_MModelGeometry\1_Platform\2_Air \225_United_States\21_Utility_Helo\1_2_225_21_x_x_x\
D600_S001_ T002
_1_2_225_21_x_x_x.flt
The XRef node in file 1 would contain the following string:
.\D600_S001_ T002
_1_2_225_21_x_x_x.flt
where
1_2_225_21_x_x_x
is the complete DIS code of the helicopter.
6.2.5.2 Models with Multiple Model-LODs
This is the case of the master file of a geotypical model. The master file known as the GTModelGeometry Entry File refers to all levels of details of the geometry files that reside in
different sub-directories. Assuming a geotypical model representing a gothic church, the master file itself would reside in a directory such as this one:
\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature \015_Building\
D500_S001_T001_AL015_050_Church-Gothic.flt
The targets of the XRef nodes would all reside in directories such as these:
22 Copyright © 2017 Open Geospatial Consortium
\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature \015_Building\Lnn\
D510_S001_T001_Lnn_AL015_050_Church-Gothic.flt
The resulting strings to use in the XRef nodes in the master file would resemble this:
.\Lnn\D510_S001_T001_Lnn_AL015_050_Church-Gothic.flt
where Lnn corresponds to the LOD the XRef file resides in.
6.3 Modeling Conventions
Kategori