44
© 2016 Open Geospatial Consortium
The name of a light SHALL be composed as follows. Starting from the top-most level of the hierarchy, concatenate each of the names encountered with the backslash
15
“\” character. Go down through hierarchy until the desired level of specificity is
encountered.
Here are a few examples: ● \Light\Platform: A light suitable for use on all platforms
● \Light\Platform\Air\Aircraft_Helos\Formation_Light: A formation light for use on aircraft and helicopter platforms
● \Light\Platform\Land\Headlight\High_Beam_Light: A high-beam head-light for use on land vehicles
● \Light\Cultural\Line-based\Highway: A light suitable to depict highway lighting ● \Light\Cultural\Line-based\Highway\Incandescent_Light: A light used to depict
incandescent highway lighting
2.3.1 Adding Names to the CDB Light Name Hierarchy
The hierarchy permits modelers to reference light types that are not defined by the current version of the CDB standard. This can be achieved by adhering to the following requirements
and procedure.
Requirements Class Light Name Hierarchy 18-21 req
corelight-name-hierarchy
Target type Data instance
Dependency XML
Dependency Light Name
Dependency XML Schema – Part 2
Requirement 18 req
cor elight-name-hierarchytype name
The modeler or the simulator vendor SHALL create a new light type name with its corresponding light code.
Requirement 19 req
cor elight-name-hierarchytype-name-definition
15
The CDB standard uses the backslash character as a separator for light names. In no time should the reader assume that the Specification is favoring the Windows operating system which is also using the backslash as a
separator when building directory paths. Again, the backslash is simply a separator for names.
45
© 2016 Open Geospatial Consortium
The modeler or the simulator vendor SHALL provide a definition for the light type name.
Requirement 20 req
cor elight-name-hierarchyinsert
The modeler or the simulator vendor SHALL insert the new light type into the light name hierarch
Requirement 21 req
cor elight-name-hierarchyedit
The modeler or the simulator vendor SHALL edit the Lights.xml metadata file to reflect the change to the Light Name Hierarchy
The modeler or simulator vendor may optionally provide values for Description, Intensity, Color, Frequency, Duty_Cycle… in the Lights_xxx.xml files. If the new entry has no values for
Description, Intensity, etc, the new light type will immediately inherit all of the properties and characteristics of CDB-native light types higher up in the light hierarchy. If the new entry
requires one or more of the fields stated in Section 2.3.2, Light Type Modeler Tuning, it will be assigned those characteristics.
Note that the level of rendering fidelity is a function of customer requirements andor the vendor’s capabilities.
The user may also elect to propose his new light name for inclusion into subsequent versions of the CDB standard.
Since the light type codes are global to a CDB structured data store, it is strongly recommended that none of the existing light type codes be modified when adding a new light type. Failure to do
this would require a complete recompilation of the data store in order to map light point type name to their newly assigned light point type codes. For this reason, it is recommended that the
CDB tools create new light type codes so that light relationships within the data store remain coherent.
2.4 Model Component Naming
