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.