Volume 7: OGC CDB Data Model Guidance (Best Practice)

The front (and back) of a powerline pylon is aligned with the general direction of the attached wires as illustrated below.

Figure A‑2: Pylon Orientation

The above snapshot is similar to the one found in Figure 6–10 of CDB Best Practice - Volume 6: OGC CDB Rules for Encoding Data using OpenFlight.

The OpenFlight graph of the above pylon exposes the 3 cross-arms, each with 2 insulators where wires are attached. Here are the names of the components that are used to model this power pylon:

These 3 names are used to create CDB Zones as explained in section 6.5 of the CDB Best Practice: Volume 6 OGC CDB Rules for Encoding Data using OpenFlight. Here is the first level of the resulting graph.

The rounded rectangle named Object is an OpenFlight object node containing the geometry of the concrete base and lattice steel structure of the pylon, but excluding the geometry of the cross-arms. Arm[1] is the lowest cross-arm; Arm[2] is the middle one; Arm[3] is the top one. Each arm is then made of a steel structure and 2 insulators.

Again, Object represents the steel structure of the cross-arm without the insulators. When looking at one of the cross-arm of the power pylon from the back, Insulator[1] is to the left while Insulator[2] is to the right. Finally, each insulator has an attach point to indicate where to connect an eventual wire.

The node Object contains the geometry of the insulator.

As explained in section 6.8 of the CDB Best Practice Volume 6: OGC CDB Rules for Encoding Data using OpenFlight, the resulting list of paths is as follow:

Note the presence of a total of 6 attach points (1 attach point per insulator × 2 insulators per cross-arm × 3 cross-arms per pylon = 6 attach points per pylon). Even though all attach points have the same name, there is a unique path to reach each one. For this reason, there is no ambiguity identifying and locating each point.

When creating the attach point of the insulator, pay attention to its orientation. Since the cable attaches underneath the insulator, the Z-axis of the local coordinate system (LCS) must be pointing down. To achieve a proper positioning of the attach point, the modeler usually inserts two transformations in the node, one translation and one rotation. The translation positions the point underneath the insulator while the rotation changes the orientation of the Z-axis. Make sure to leave the Y-axis in the direction of the wire as in the figure below.

Figure A‑3: Attach Point Orientation

In this figure, the position and orientation of the attach point is identified by the blue-red-green axis system beneath the insulator. The Y-axis is in red and points in the same direction as the model’s Y-axis, which is toward the front of the model. The Z-axis is in green and points down indicating that wires attach under the insulator.

The table below is the collection of class and instance-level attributes from tables 5-46 and 5-47 of Volume 1: OGC CDB standard ^[2].

Table A‑1: Powerline Attributes

The occurrence of some of the optional attributes depends on the occurrence of other optional attributes. In particular, when MODL is present, other attributes become required while others remain optional. The table below provides the relation between MODL and other attributes.

Table A‑2: MODL-related Attributes

As a result of the above tables, a CDB-compliant Powerline Network dataset requires 11 mandatory attributes (listed in the first column of Table A‑1). Optionally, when a 3D model representing a pylon is provided, 4 additional attributes are required (MODL obviously, plus BSR, HGT, and MODT) and 5 others remain optional (AO1, BBH, BBL, BBW, and SCALn).

The HGT attribute represents a special case because table 5-47 in Volume 1 suggests that the attribute is optional while, in fact, it should always be present. If you carefully read its description in paragraph 5.3.1.2.3.17, you realize that HGT is required in both the line and figure point features of the Powerline Network.

For line features, HGT represents the average height above ground of the powerline when no MODL is specified, as suggested by the discussion about HGT in section 5.3.1.17 of the Volume 1: Core. In the figure point features, HGT represents the height above ground of the pylon, whether or not a MODL is provided. In either file, when MODL is supplied, HGT represents the height of the 3D model above the ground.

You should read guideline (6.3 – old Annex A.3) for a complete discussion about HGT

If the orientation of the pylon is specified by AO1, then use the value as-is. If the orientation is not specified, the client device must compute its value using the orientation of the segments of the line that are adjacent to the pylon. In the case of the first and last segments, the orientation of the segment is also the orientation of the pylon. For the other segments, the orientation of the pylon is the average of the orientation of the two adjacent segments.

When no MODL is provided at all – meaning no MODL for the line and none for the figure points – and because there is no attribute specifying the number of wires along the transmission line, the client device must assume a generic powerline with two wires separated by a width of WGP meters connecting generic posts (simple pylons) of HGT meters high.

When a common MODL is specified for the whole line and no figure points are provided, it is possible to determine the number of wires by counting the number of attach points in the 3D model. Refer to guideline 6.1.2 (old A.1.2) for details on how to detect attach points.

If specific MODLs are defined through figure points, the number of attach points in each 3D model of the collection of all MODLs referenced by the powerline network must be identical. For instance, if the line refers to a generic pylon supporting 4 wires, then all specific pylons referenced as figure points must also support 4 wires. Furthermore, the general configuration of all pylons must be identical. If the general pylon supports 6 wires configured as a matrix of 2 wires horizontally by 3 wires vertically, then all specific pylons must also share the same configuration.

If the client device has a single generic pylon along the line, then there is no problem connecting wires and attach points. That is when multiple pylons are used along the same line that problems arise. The client has to match attach points from one type of pylon to attach points on another pylon that may be of a different type. The algorithm to determine how to connect pylons of different types is left to the client device. A future version of CDB Standard will provide a robust and deterministic approach on how to connect the wires.

Typically, a model is positioned relative to the ground without any offset. As a result, AHGT is false, and Zr is set to zero. Hence…

\(HGT = BBH\)

In the case of airport and environmental light points, no model of a light fixture is provided (the MODL attribute is not allowed). Hence…

\(BSR = 0\ \rightarrow BBH = 0\)

Currently, the light point datasets do not allow the HGT attribute, the client application may have to compute its value using the equation given previously…

\(HGT = BBH + Zr\)

where BBH is null.

\(HGT = Zr\)

And if the light point is positioned at an absolute height (AHGT is true), then…

\(HGT = Za - Gh\)

Refrain from using AHGT. There are several advantages to leave this flag set to false. First, it facilitates the creation of CDB datasets that are independent of each other. When the Z coordinate (altitude) of a feature is relative to the ground, the elevation dataset can be updated without the need to re-compute and update all features that have an absolute altitude.

Second, when a feature has an absolute altitude, it is possible that it will end up being displayed below the ground by a given client. How is this possible? Isn’t it an error in the data store itself? No, this is not an error. It is perfectly possible to create content that is valid and – still – produce an incorrect result at the client level. Consider a feature that is positioned with an absolute height in a valley between two mountains of a high resolution terrain profile. At coarse LOD of terrain elevation, the valley and the mountains may (and will) be flattened producing a terrain skin that may no longer pass underneath the feature. Now imagine a client that uses that coarse LOD of elevation to create a terrain skin and then draw the feature at its absolute altitude, which happen to be underneath the terrain skin. The feature will not be visible or will be partially occluded by the terrain.

These reasons explain why the use of the AHGT flag should be avoided whenever possible.

Limit the use of AHGT to data whose source is inherently absolute. Such source data include geodetic marks or survey marks that provide a known position in terms of latitude, longitude, and altitude. Good examples of such markers are boundary markers between countries.h

The ModelInteriorGeometry dataset is a subordinate dataset of the ‘regular’ ModelGeometry dataset. It depends directly on it. This is best illustrated by an example.

In the above table, the Shell column represents what is called the ‘regular’ ModelGeometry dataset. In this example, the model appears at LOD 2, a better version exists at LOD 6, an even better at LOD 8, and finally, the most detailed shell is at LOD 10. The Interior column shows 3 different LODs of interiors. There cannot be more Interior LODs than Shell LODs. Also, once an interior is provided (here at LOD 6), it must be provided for all subsequent (finer) LODs of the shell (LOD 8 and 10). Which means… interior at LOD 8 and 10 must exist.

It is expected that a client will first request the shell of the model, then discover that the model has an interior because of the presence of a CDB Zone whose name is Interior (see 6.18.2 Volume 6: OGC CDB Rules for Encoding Data using OpenFlight, Pseudo-Interior), and then decide if the pseudo interior is sufficient for the application or if the real interior is necessary.

Client applications that are interested in 3D models will typically perform the following sequence of actions:

Interior datasets exists for both geospecific and geotypical models. Hence, all features can be represented by a 3D model and all 3D models can have a separately modeled interior. Note the symmetry between the file names of shell and interior datasets. For geospecific models encoded as OpenFlight, the names of geometry files are…

For geotypical models encoded as OpenFlight, the file names become…

Note that in both cases, the only difference between the name of the shell and the name of the corresponding interior is the dataset code; and in both cases, a value of 5 is added to the ‘regular’ ModelGeometry dataset code.

To help understand how CDB Model Interior maps to UHRB concepts, three (3) diagrams are provided below. The first two diagrams illustrate the UHRB Object Model ^[4] while the third diagram presents the corresponding CDB Object Model.

The first diagram is the UHRB Class Diagram presented in Figure A‑4 below. The class diagram presents twelve classes of which eight are concrete classes that can be used to represent tangible objects. The UHRB_EDM_COMPLEX_FEATURE class implements an extension mechanism that is not required in the context of the CDB Specification. The remaining seven UHRB classes will be mapped to CDB zones.

Figure A‑4: UHRB Class Diagram

The second diagram is the UHRB Association Diagram of Figure A‑5; it shows all permissible associations between the UHRB classes.

Figure A‑5: UHRB Association Diagram

The third diagram, in Figure A‑6 below, presents the Object Model proposed by CDB Model Interior objects. The UML diagram is both the class and association diagram of CDB zones listed in table 6-27 of section 6.18.5 of CDB 3.1.

Figure A‑6: CDB Model Interior Object Model

This section describes the required client-device behavior for PointZ and MultiPointZ features used as terrain elevation constraint points (AHGT is true) into a uniformly sampled terrain elevation dataset.

The application of a constraint point P is very much like drawing an anti-aliased rectangle centered on P into the uniform terrain elevation grid. The rectangle shape is defined by feature attributes BBL, BBH and AO1. Consider a terrain grid element A in the immediate vicinity of a constraint point P. After applying the constraint P to terrain grid element A, the new elevation E_A is:

\(E_{A}\ = \ E_{P}*\text{Ain}_{\text{PA}} + \ E_{A}*\ \text{Aout}_{\text{PA}} \)

where…

E_A is elevation of grid element A

E_P is elevation of constraint point P

Ain_PA is the percentage overlap of constraint point P onto grid element A

\(\text{Aout}_{\text{PA}}\) = \(\left( 1\ - \ \text{Ain}_{\text{PA}} \right)\)

Figure A‑7: Application of Constraint Point - Uniformly-Sampled Terrain

This section describes the required client-device behavior for PolyLineZ features used as terrain elevation constraint linear feature (AHGT is true) into a uniformly sampled terrain elevation dataset.

First, the PolyLineZ feature is broken into a series of constraint lines. The application of each constraint line L is very much like drawing an anti-aliased line centered on L into the uniform terrain elevation grid. The width of the line is defined by feature attribute WGP. Consider a terrain grid element A in the immediate vicinity of a constraint line L, defined by vertices V1 and V2. After applying the constraint line L to terrain grid element A, the new elevation E_A is:

\(E_{\text{A}}\) = \(E_{\text{LA}} * Ain_{\text{LA}} + E_{\text{A}} * Aout_{\text{LA}} \)

where…

E_A is elevation of grid element A

E_LA is interpolated elevation of constraint line L at grid element A

Ain_LA is the percentage overlap of constraint line L onto grid element A

\(\text{Aout}_{\text{LA}}\) = \(\left( 1\ - \ \text{Ain}_{\text{LA}} \right)\)

Figure A‑8: Application of Constraint Line - Uniformly-Sampled Terrain

This section describes the required client-device behavior of PolygonZ and MultiPatch features used as terrain elevation constraint points (AHGT is true) into a uniformly sampled terrain elevation dataset.

Each vector PolygonZ feature consists of a number of rings (or parts). Each ring is a closed (the first vertex is same as the last vertex), non-self-intersecting loop. A PolygonZ feature may contain multiple outer rings. A sequence of rings can describe a convex or concave feature outline. In the CDB standard, rings can only be made up of triangles.

Each vector MultiPatch feature consists of a number of rings (or parts). Each ring is a closed (the first vertex is same as the last vertex), non-self-intersecting loop. A sequence of rings can describe a convex or concave feature outline. While the vector MultiPatch feature permits multiple inner rings (aka parts), this capability is dis-allowed in CDB. Furthermore, rings can only be made up of triangles.

The rendering of the vector feature is handled as a series of constraint triangles applied in the order in which they appear within the vector PolygonZ record. The application of each constraint triangle T is very much like drawing an anti-aliased triangle into the uniform terrain elevation grid. Consider a terrain grid element A in the immediate vicinity of a constraint triangle T, defined by vertices V1, V2 and V3. After applying the constraint triangle T to terrain grid element A, the new elevation E_A is:

\(E_{A}\ = \ E_{\text{TA}}*\text{Ain}_{\text{TA}} + \ E_{A}*\ \text{Aout}_{\text{TA}}\ \)

where…

E_A is elevation of grid element A

E_TA is interpolated elevation of constraint triangle T at grid element A

Ain_TA is the percentage overlap of constraint line T onto grid element A

\(\text{Aout}_{\text{PA}}\) = \(\left( 1\ - \ \text{Ain}_{\text{TA}} \right)\)

Figure A-9: Constraint Polygons

This section describes the required client-device behavior for PointZ and MultiPointZ features used as terrain elevation constraint points (AHGT is true) into a non-uniformly sampled terrain elevation dataset.

The application of a constraint point P is applied as follows.

Figure A‑10: Application of Constraint Point – Non-uniform Grid

This section describes the required client-device behavior for PolyLineZ features used as terrain elevation constraint line (AHGT is true) into a non-uniformly sampled terrain elevation dataset.

First, the PolyLineZ feature consisting of n vertices is broken-down into (n-1) line segments defined by successive pairs of vertices.

The application of a constraint line segment L is applied as follows.

Figure A‑11: Application of Constraint Line – Non-uniform Grid

This section describes the required client-device behavior of PolygonZ and MultiPatch features used as terrain elevation constraint points (AHGT is true) into a non-uniformly sampled terrain elevation dataset.

Each vector PolygonZ feature consists of a number of rings (or parts). Each ring is a closed (the first vertex is same as the last vertex), non-self-intersecting loop. A PolygonZ feature may contain multiple outer rings. A sequence of rings can describe a convex or concave feature outline. In the CDB standard, rings can only be made up of triangles.

Each vector MultiPatch feature consists of a number of rings (or parts). Each ring is a closed (the first vertex is same as the last vertex), non-self-intersecting loop. A sequence of rings can describe a convex or concave feature outline. While the vector MultiPatch feature permits multiple inner rings (aka parts), this capability is dis-allowed in CDB. Furthermore, rings can only be made up of triangles.

The application of a constraint triangle T is applied as follows.

Figure A‑12: Application of Constraint Polygon – Non-uniform Grid

In FalconView, a top-level directory contains files that are metadata containing information about the various datasets and files in the directories.

The FalconView directory structure is as follows:

Falconviewmaps

+---covdata Coverage data

| cgnc.cov Global Navigation charts

| cjga.cov Joint Operation Graphics Air

| cjnc.cov Jet Navigation Chart

| conc.cov Operational Navigation Chart

| ctpc.cov Tactical Pilotage Chart

| mm100.cov 1:100,000 maps

| mm250.cov 1:250,000 maps

| sigfile.sig

| trs_8km.cov Township Range Section

|

+---rpf Raster Product Format

| +---cgnc Global Navigation Map

| | +---1 Zone

| | | 00023023.GN1 File Name

MIL-STD-2411 divides the world into 18 zones, nine in the northern hemisphere and nine in the southern hemisphere. The first eight zones in both hemispheres are divided into frames, which in turn are divided into sub-frames. Frames are made of pixels with 1536 x 1536 pixels in a frame; there are 36, 6x6 sub-frames per frame. Between each zone, there is an overlap of one frame; this implies that the size of zones will vary slightly depending on the resolution that is used. Table A‑5 Zones Range No Overlap gives the approximate range of each zones; 1 – 9 in the north, A - J in the south. The two extreme zones, which cover the north and south poles, use a different scheme and are not discussed here.

Table A‑5: Zones Range No Overlap

Along lines of constant longitude, the pixel constant used to determine the size of frames is a function of the resolution but is independent of the zone. Along lines of constant latitude the constant is a function of both resolution and zone and is based on the mid latitude of the zone. Table A‑6 Example Resolution east-west pixel constants that is extracted from MIL-C-89041 enumerates the factors for three resolutions.

Table A‑6: Example Resolution east-west pixel constants

The north-south or latitudinal pixel constant is the number of pixels from the equator to the pole (90°). The east-west pixel constant is the number of pixels longitudinally from the 180° west longitude meridian going 360° in an easterly direction along the zone midpoint.

To illustrate, we will use as an example a resolution of 10 meters. To calculate the exact latitudinal zone extent for a given resolution, first calculate the number of pixels in a degree of latitude for the resolution

The number of frames needed to reach the nominal zone boundary is the number of pixels per degree of latitude multiplied by the nominal zone boundary (in degrees), divided by 1536, the number of pixels rows in a frame, and rounded up to the nearest integer. For example in the first zone the number of frames is

The extent of the zone is then

In order to find the extent of the next zone we use the following method, which applies to all zones from 2 to 8 or B to H.

Since there is an overlap of one frame the start point of the zone 2 will be the number of frames required to reach the next zone which nominally is at 48 is: and the extent is

The number of longitudinal frames and subframes is computed by determining the number of subframes to reach around the earth along a parallel at the zone midpoint. The east-west pixel constant is divided by 256 pixels to determine the number of subframes. The results are divided by 6 and rounded up to obtain the number of frame columns.

For example, longitudinally in the first zone we get subframes and frames. Table A‑7 Frame/Subframe Sizes for Source Image GSD of 10 Meters, shows the complete set for a resolution of 10 meters.

Table A‑7: Frame/Subframe Sizes for Source Image GSD of 10 Meters

MIL-C-89041 states that “the origin for counting nonpolar frame rows and columns is the southernmost latitude of the zone and 180° west longitude, with columns counted in an easterly direction from that origin, as opposed to frames and subframes where “the origin for the subframe and pixel numbering within frames and subframes shall be from the upper left corner”.

For a given latitude and longitude the row and column for the frame where that geographic position is situated can be computed. The determination of the zone is derived from the latitude except at the border of zones where an overlap exists and the zone must be picked.

The row is given by where is the bottom southern-most latitude of the zone at resolution r and is the number of pixels per degrees of latitude at resolution r. Similarly, the column corresponding to the longitude is given by where is the number of pixel per longitudinal degrees in zone z at resolution r, ranges from –180 to 180.

As an example, for latitude of 36 degrees and longitude of –88 degrees we would get for a resolution of 10 meters

MIL-C-89041 for Controlled Image Base (CIB) states that:

“The naming convention for all resolutions of images registered in MIL-STD-2411-1, where it is intended for producers to provide contiguous [frame file] coverage, shall conform to MIL-STD-2411. In addition, the CIB [frame file] names are further restricted to conform to the form “ffffffvp.ccz.” The “ffffff” portion of the name shall be a radix 34 value that encodes the unique cumulative frame number within a zone in base 34, with the right-most digit being the least significant position. The radix 34 value incorporates the numbers 0 through 9 and letters A through Z exclusive of the letters “I” and “O” as they are easily confused with the numbers “1” and “0”. For example, the “ffffff” portion of the names would start with “000000,” proceed through “000009,” “00000Z,” “000010,” and so forth until “ZZZZZZ.” This allows 1,544,804,416 unique [frame file] names; a contiguous grid of frame names down to a resolution of 0.2 meters (approximately 8 inches) can be defined. The “v” portion of the name shall be a radix 34 value that encodes the successive version number. The “p” portion of the name shall be a radix 34 value that designates the producer code ID, as defined in MIL-STD-2411-1. The “cc” and “z” portions of the name extension shall encode the data series code and the zone, respectively, as defined in MIL-STD-2411-1. The CIB producers are responsible to ensure that [frame files] for all image resolutions, zones, and revisions, have unique names.”

In our case:

…

In the example of a lat of 36 and lon –88 with a resolution of 10 meters we get:

ffffff = 503+29x1970=57633 or 001FV3₍₃₄₎

… where 1970 is number columns in zone 2 as given in Table A‑7 Frame/Subframe Sizes for Source Image GSD of 10 Meters, and in RADIX 34 we get ffffff = 001FV3 ; for a global navigation chart dataset a version level 0, a manufacturer code of 3 and zone 2 the file name would be equal to “001FV303.GN2.”

Note that nothing in the file name defines the resolution for the data; this information is part of the [coverage section] in the file itself (see section 3.12.3 in MIL-C-89041). Also note that the file name is unique only to the zone at a given resolution.

On the other hand a similar file for imagery (VSTI, Visible Spectrum Terrain Imagery) in the CDB convention for an LOD of 04 which has a resolution of approximately 8 meters; at position lat 36 and lon –88 we would get for the file name:

\CDB\Tiles\N36\W088\004_Imagery\L04\U0\
N36W088_D004_S001_T001_L04_U0_R0.jp2

Note that the file name itself is unique worldwide and that from it we can derive the directory path to which it belongs.

The T2DModels are stored in the OpenFlight format. The CDB conventions described herein are designed to facilitate the integration of such models onto the terrain tile, hence the name “Tiled 2D Models”. Each 2DModel can have one or more modeled representation (called a 2DModel-LOD) that represents the feature to a certain level of fidelity. 2DModel-LODs are re-grouped into T2DModel Tile-LODs; this re-grouping approach is designed to reduce the overheads associated with the access of 2DModel-LODs. Furthermore, T2DModel-LODs can be accessed without a prior reference to a corresponding feature in the GSFeature dataset.

The integration of T2DModels to the underlying terrain skin is performed by the client-devices at runtime. Historically, this integration has always been performed by the tools and was “baked-in” into the SE terrain skin during the offline data store generation process. Many client-specific considerations went into the mechanisms required to support this integration and as a result, the resulting synthetic environments were very client-specific and did not scale easily to higher resolutions.

In line with CDB principles, the T2DModel Dataset defers this integration and imposes it on the consumers (not the producers) of synthetic environments. As a result, client-devices can independently access, manage and control each dataset, i.e., the Primary Elevation, the VSTI Imagery, the T2DModel, etc. This layered approach to synthetic environment production and consumption provides a much greater level of abstraction between the SE data model and the data models internal to each client-device. It is understood, that the deferral of the integration process imposes added functionality and computational requirements on the part of the CDB client-devices.

While it would be possible, in theory, to use the T2DModel Dataset for the modeling of the terrain skin, this use-case is specifically forbidden because the T2DModel Dataset does not provide a guarantee of full tile coverage. As a result, the Primary Elevation Dataset is always required regardless of whether a corresponding Tile-LOD of the T2DModel is present or not. Furthermore, since CDB forbids the duplication of information, the terrain skin cannot be duplicated by the T2DModel Dataset.

Client-devices must always access the Primary Elevation prior to any other raster datasets. Once a Tile-LOD of the Primary Elevation is loaded, a client-device can then access the T2DModel Dataset at an “appropriate” LOD ^[6]. Following this, the client-device must integrate the models found within the T2DModel Tile-LOD with the terrain found in the Primary Elevation dataset.

The following diagram represents a typical usage of a linear model in a CDB data store for a typical radar client-device.

The radar application first extracts the line features from the CDB data stores and constructs an object. The constructed object contains the necessary information for the radar to compute the equivalent radar image using the radar cross-section (RCS) of the line features with material attributes and directivity, etc.

Figure A‑31: Example of Line Features, illustrates three line features stored in the tile in in a vector data set. The junction nodes of each line feature represents the start and end junctions of the line feature. In this example, there is only one chain per line feature.

Figure A‑31: Example of Line Features

The radar uses the position of the lineal coordinates to construct a line representation of the radar image. It extracts the line feature information from the chains to construct an internal local representation. The necessary information needed by radar is…

Figure A‑32: Radar Beam Simulation

The radar then uses a beam simulation to process the above information and construct an image representing the content of each small beam sections. The intersection of the beam pie slice is compared with the line feature’s position and converted into an image whose intensity is based on the computed RCS of the line features. As mentioned above, the RCS value (which is modeled internally in the radar simulation) takes into account the properties (which are derived from the attributes) of each line feature.

Figure A‑33: Network Dataset Used to Describe a Navigable Network, illustrates how line features can be used to describe a navigable network; the example could represent a network of roads. First, the application reads a vector line file describing the chains, then the vector point file describing the junction nodes. For each junction nodes the application makes up a list of attached chains ending up with a network as illustrated in Figure A‑33: Network Dataset Used to Describe a Navigable Network, where there are six chains (labeled in this example as CSLID1 to CSLID6) that are joined through intersection nodes (labeled in this example as CSZID1 to CSZID6). The small black dots represent points forming the segments of a chain; they are essentially used to describe the deviation from a straight line between nodes.

In Figure A‑33: Network Dataset Used to Describe a Navigable Network, the green line shows an example of what a shortest path algorithm could determine if asked to find the shortest route between CSZID1 and CSZID5 based on the lengths of the chains. First, the algorithm would move to CSZID2 via the chain CSLID1; when at CSZID2 it has two alternatives, either take CSLID4 or use CSLID3 and CSLID6. In our example it would have determined that the latter alternative is the shortest path; the entity would then follow the path given by the green line going through all the segments in the chains.

Figure A‑33: Network Dataset Used to Describe a Navigable Network

The following diagram represents a typical usage of a point feature as modeled in the CDB data store for a typical radar client-device. The radar client-device extracts the point feature from the data store using the format described in the Standard and constructs an object. The constructed object will contain the necessary information for the radar to compute the equivalent radar image using the radar cross-section (RCS) of the object over the terrain; the RCS is derived from the point features characteristics.

In Figure A‑34: Objects Represented on a Terrain Tile, a series of different objects are represented on a terrain tile. The objects are modeled as single point of zero dimensions in radar. The radar will position the different points according to their geographic position and altitude. The height data corresponds to a height of the feature with respect to the terrain.

Figure A‑34: Objects Represented on a Terrain Tile

The necessary information needed by radar is typically…

The radar then uses a beam simulation to process the above information and construct an image representing the content of each small beam sections. The intersection of the beam pie slice is compared with the point’s position and converted into an image whose intensity is based on the computed RCS of the points. As mentioned above, this RCS takes into account the attributes of each point feature.

If the size of the object referred to by the point feature is much larger than a specific threshold, the simulation could in addition use the MODL field of that point feature to extract a more precise geometrical 3D model from the CDB to increase the simulation fidelity.

The following diagram represents a typical usage of a polygon feature as modeled in the CDB for a radar client-device.

Currently, in a manner similar to the line example, the Radar extracts this polygon from the data store using the ShapeFile (*.shp) file ^[10] and constructs a tile in its memory. The constructed tile will contain the necessary information for the radar to compute the equivalent radar image using the radar cross-section (RCS) of the represented surface polygon over the terrain intersecting the Radar beam.

In Figure A‑37: Four Polygon Features Stored in the Tile, four polygon features are stored in the tile with their surface material and feature classification attributes. Each of the features points to an array of segments.

Figure A‑37: Four Polygon Features Stored in the Tile

The radar simulation uses the segment coordinates to construct a polygonal representation on the radar image. It extracts the polygon feature attribute information from the segments and constructs its tile data in memory. The necessary information needed by the radar simulation is typically…

The following image shows how a typical radar beam would intersect the different parts of polygon features that are part of the terrain represented previously.

Figure A‑38: Radar Beam Simulation, shows the radar using a beam simulation to extract the above information and construct an image representing the content of each small beam sections (aka bins). The intersection of the beam pie slice is performed against the polygon feature polygons. Then the material of the polygon falling in the beam bin is converted into image intensity, which is relative to the computed RCS of that polygon’s material. As mentioned above, this RCS takes into account the attributes of the segment of each polygon feature.

Figure A‑38: Radar Beam Simulation

The finest Tile-LOD for lineal and areal vector datasets can be determined and generated using the following steps, starting with the full resolution dataset for a CDB Tile at the coarsest Tile-LOD:

It is recommended to stop when the vertex limit is satisfied so as to limit the number of even finer Tile-LODs that would otherwise be necessary to simply satisfy the spatial significance criterion alone.

This section describes how to produce coarser Tile-LODs of lineal networks from finer Tile-LODs, taking into account each vector’s priority, as defined in Section 5.7.1.6.4, Network Vector Priority.

In the case that all features have been removed in step d, create empty Tile-LODs at this and every coarser Tile-LOD to indicate the presence of content at finer LODs of this dataset.

Creating coarser Tile-LODs of non-network lineals from finer Tile-LODs is a process similar to the one for networked lineals, but without the junction ID and topology preserving steps.

In the case that all features have been removed in step c, create empty Tile-LODs at this and every coarser Tile-LOD to indicate the presence of content at finer LODs of this dataset.

This section describes how to produce coarser Tile-LODs of areal vector data from finer Tile-LODs. For network areal data, there is a single Junction ID for the entire feature. Therefore, the network only requires the presence of the feature, rather than a specific vertex, to maintain topological completeness. As such, network and non-network areals can be treated similarly, where the important characteristics are whether a feature is present in a particular Tile-LOD, and how precisely its shape has been preserved.

This process is similar to the one for lineal vectors.