Open Geospatial Consortium

Submission Date: 2020-01-21

Approval Date:      2020-08-24

Publication Date:      2021-02-26

External identifier of this OGC® document: http://www.opengis.net/doc/BP/CDB-model-guidance/1.2

Internal reference number of this OGC® document:        16-010r5

Version: 1.2

Category: OGC® Best Practice

Editor:      Carl Reed

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

Copyright notice

Copyright © 2021 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.ogc.org/legal/

Warning

This document defines an OGC Best Practice on a particular technology or approach related to an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC Standard. It is subject to change without notice. However, this document is an official position of the OGC membership on this particular technology topic.

Document type:        OGC® Best Practice

Document subtype:   

Document stage:    Approved

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

Table of Contents

i. Abstract

This CDB Volume provides Guidelines, Clarifications, Rationales, Primers, and additional information for the definition and use of various models that can be stored in a CDB compliant data store.

Please note that the term “lineal” has been replaced with the term “line” or “linear” throughout this document

Please note that the term “areal” has been replaced with the term “polygon” throughout this document.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, cdb, models, guidance, simulation

iii. Preface

This document contains material from Annex A in the original CDB 3.2 specification submission to the OGC. These sections provide guidance for model builders to build and maintain model content in a CDB data store.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

  • CAE Inc.

  • Carl Reed, OGC Individual Member

  • Envitia, Ltd

  • Glen Johnson, OGC Individual Member

  • KaDSci, LLC

  • Laval University

  • Open Site Plan

  • University of Calgary

  • UK Met Office

The OGC CDB standard is based on and derived from an industry developed and maintained specification, which has been approved and published as OGC Document 15-003: OGC Common Data Base Volume 1 Main Body. An extensive listing of contributors to the legacy industry-led CDB specification is at Chapter 11, pp 475-476 in that OGC Best Practices Document (https://portal.opengeospatial.org/files/?artifact_id=61935 )

v. Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name

Affiliation

Carl Reed

Carl Reed & Associates

David Graham

CAE Inc.

1. Scope

The CDB Standard defines a standardized model and structure for a single, versionable, simulation-rich, virtual representation of the earth. A CDB structured data store provides for a synthetic environment repository that is plug-and-play interoperable between data store authoring workstations. Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various simulator client-devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime simulation tasks. In this case, a CDB data store is plug-and-play interoperable between CDB-compliant simulators. A CDB data store can be readily used by existing simulation client-devices (legacy Image Generators, Radar simulator, Computer Generated Forces, etc.) through a data publishing process that is performed on-demand in real-time.

Please note that this document was Annex A, Volume Part 2 in the pre-OGC 3.2 version.

2. Conformance

This is an informative document. There are no normative clauses

3. References

For ease of editing and review, the standard has been separated into 16 Volumes, one being a schema repository.

  • Volume 0: OGC CDB Companion Primer for the CDB standard (Best Practice).

  • Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure. The main body (core) of the CDB standard (Normative).

  • Volume 2: OGC CDB Core Model and Physical Structure Annexes (Best Practice).

  • Volume 3: OGC CDB Terms and Definitions (Normative).

  • Volume 4: OGC CDB Rules for Encoding CDB Vector Data using Shapefiles (Best Practice).

  • Volume 5: OGC CDB Radar Cross Section (RCS) Models (Best Practice).

  • Volume 6: OGC CDB Rules for Encoding CDB Models using OpenFlight (Best Practice).

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

  • Volume 8: OGC CDB Spatial Reference System Guidance (Best Practice).

  • Volume 9: OGC CDB Schema Package: http://schemas.opengis.net/cdb/ provides the normative schemas for key features types required in the synthetic modeling environment. Essentially, these schemas are designed to enable semantic interoperability within the simulation context (Normative).

  • Volume 10: OGC CDB Implementation Guidance (Best Practice).

  • Volume 11: OGC CDB Core Standard Conceptual Model (Normative).

  • Volume 12: OGC CDB Navaids Attribution and Navaids Attribution Enumeration Values (Best Practice).

  • Volume 13: OGC CDB Rules for Encoding CDB Vector Data using GeoPackage (Normative, Optional Extension).

  • Volume 14: OGC CDB Guidance on Conversion of CDB Shapefiles into CDB GeoPackages (Best Practice).

  • Volume 15: OGC CDB Optional Multi-Spectral Imagery Extension (Normative).

4. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms and definitions apply:

5. Conventions

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

6. Data Model Guidance

Please note that whenever there is reference to Volume 1: Core, the full reference is Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure.

6.1. Guideline: Creating a 3D Model for a Powerline Pylon

Formerly Annex A.1 Volume 2 of the CDB Best Practice

The goal of this guidance is to model a typical high voltage electrical pylon resembling the one in the following figure. This guidance is based originally on CDB version 3.1 prior to submission to the OGC, but is applicable to version 3.0 as well [1].

Electrical Pylon.jpeg

Figure A‑1: Typical Electrical Pylon

6.1.1. Pylon Model Orientation

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

Pylon.JPG

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.

6.1.2. OpenFlight Graph

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:

  • Pylon (global zone)

  • Arm (horizontal cross-arm at the top of the structure)

  • Insulator (ceramic insulator string attached at the end of each arm)

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:

  • \Pylon

  • \Pylon\Arm[1]

  • \Pylon\Arm[1]\Insulator[1]

  • \Pylon\Arm[1]\Insulator[1]\Attach_Point

  • \Pylon\Arm[1]\Insulator[2]

  • \Pylon\Arm[1]\Insulator[2]\Attach_Point

  • \Pylon\Arm[2]

  • \Pylon\Arm[2]\Insulator[1]

  • \Pylon\Arm[2]\Insulator[1]\Attach_Point

  • \Pylon\Arm[2]\Insulator[2]

  • \Pylon\Arm[2]\Insulator[2]\Attach_Point

  • \Pylon\Arm[3]

  • \Pylon\Arm[3]\Insulator[1]

  • \Pylon\Arm[3]\Insulator[1]\Attach_Point

  • \Pylon\Arm[3]\Insulator[2]

  • \Pylon\Arm[3]\Insulator[2]\Attach_Point

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.

6.1.3. Attach Point Orientation

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.

AT040.jpg

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.

6.2. Guideline: Generating Wires between Pylons of a Powerline

Formerly Annex A.2 in the CDB Best Practice, Volume 2.

This guideline is intended for both modelers and developers responsible for the creation of:

  • CDB content such as 3D models representing pylons

  • Tools used to generate the Powerline Network datasets

  • Client-devices that use the Powerline Network datasets to generate pylons and wires along the transmission line.

6.2.1. Powerline Network Attributes

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

Required
Attributes
Optional
Attributes

CMIX

AHGT

CNAM

AO1

DIR

BBH

EJID

BBL

FACC

BBW

FSC

BSR

JID

HGT

LENL

MODL

RTAI

MODT

SJID

SCALn

WGP

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

Required Optional

BSR

AO1

HGT

BBH, BBL, BBW

MODT

SCALn

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).

6.2.2. Generation of HGT

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

6.2.3. Pylon Orientation

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.

6.2.4. Number of Wires

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.

6.2.5. How to Connect Wires to Attach Points

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.

6.3. Guideline: How to Interpret the AHGT, HGT, BSR, BBH, and Z Attributes

Formerly Annex A.3 in the OGC CDB Best Practice, Volume 2.

The goal of this guideline is to promote a correct use of five CDB attributes: AHGT, HGT, BSR, BBH, and Z. The article is aimed to both developers and users of content creation tools as well as developers of client applications.

A picture being worth a thousand words, the following diagram should help understand the relations between the AHGT, HGT, BSR, BBH, and Z attributes.

Here is a reminder of what these attributes are. The complete definitions can be found in Section 5.3.1.3, CDB Attributes in the CDB Standard Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure.

  • AHGT (Absolute Height) is a flag to interpret correctly the value of the Z coordinate of a feature. When false, the value of Z is relative to the ground (Zr); when true, Z is the absolute altitude (Za).

  • AHGT is not related with HGT even though their names are similar.

  • HGT (Height Above Surface Level) is the distance from the top of the model to the ground.

  • BBH (Bounding Box Height) is the distance from the top of the model to its XY plane.

  • BSR (Bounding Sphere Radius) encompasses the portion of the model that is above its XY plane.

  • Z is the altitude of a feature, either absolute or relative to the ground.

In the diagram above, a model (MODL) is positioned above the ground. This is indicated by the fact that the model’s XY plane does not lie directly on the ground. The distance above the ground is represented by Zr. The diagram clearly shows the relation between HGT, BBH, and Zr.

\[HGT = BBH + Zr\]

When the value of Zr is not readily available from the instance of the feature itself (because AHGT is true), it can be computed using the ground height (Gh).

\[Zr = Za - Gh\]

The BBH attribute is optional and defaults to twice the value of BSR, which is mandatory for a MODL model.

\[default\ BBH = 2 \times BSR\]

\[default\ BBH \geq real\ BBH\]

6.3.1. Typical Use-case

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\]

6.3.2. Light Points

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\]

6.3.3. Recommendation

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.

6.3.4. When should AHGT be used?

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

6.4. Guideline: How to Model a Wind Turbine

Formerly Annex A.4 in the OGC CDB Best Practice, Volume 2.

This text proposes a way to create a 3D model representing an articulated wind turbine. The articulations of interest are the yaw control to orient the turbine in the direction of the wind, the roll control to allow rotation of the rotor, and, optionally, the pitch control to change the orientation of the blades, if needed.

image

Beside is a typical Horizontal Axis Wind Turbine. The components of interest are the following:

  • Turbine

  • Rotor

  • Blade

Looking at appendix F – CDB Model Components – we note that Turbine is not listed and, consequently, will be proposed as an extension to future version of the CDB standard.

The CDB metadata folder provides the proper code for a Wind Turbine, AD010-005 [3]. The code indicates the presence of a man-made point feature.

A = Culture

D = Power Generator

010 = Power Plant

005 = Wind

The hierarchy graph of the OpenFlight model could look like the one on the right. If individual control of the pitch of each blade is required, the Blades object (the lower right node) could be replaced with three (3) sub-trees each containing a Blade zone, a DOF node, and an object node.

With the proposed layout, a client device will detect the presence of a wind turbine through its feature attribute code (aka feature code), and recognize and control two articulations, the Turbine Yaw angle, and Rotor Roll angle.

A last note: to comply with the prescribed orientation of the CDB coordinate system as defined in section 6.3 Volume 6: OGC CDB Rules for Encoding Data using OpenFlight, the rotor must represent the front of the wind turbine (and not its right side).

6.5. Guideline: Handling of Model Interiors

Formerly Annex A.5 in the OGC CDB Best Practice, Volume 2.

CDB introduces the concept of the interior of a 3D model. The concept is developed in section 6.18, Model Interior, of the CDB Best Practice Volume 6: OGC CDB Rules for Encoding Data using OpenFlight. The following text serves as a complement to the standard to understand how the concept has been developed and how model interior is intended to be used.

6.5.1. Relationship between Model Shell and Model Interior

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

LOD ModelGeometry
(Shell)
ModelInteriorGeometry
(Interior)

-

-

0

-

-

1

-

-

2

Coarsest Shell

-

3

-

-

4

-

-

5

-

-

6

Medium Shell

Medium Interior

7

-

-

8

Fine Shell

Fine Interior

9

-

-

10

Finest Shell

Finest Interior

11

-

-

12

-

-

13

-

-

14

-

-

15

-

-

-

-

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.

6.5.2. Detecting Presence of a Model Interior

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.

6.5.3. Access of a Model Interior

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

  1. Load the GS Features of a tile

  2. Load the GS and GT Models referenced by the GS Features

  3. For each model, traverse its graph and detect the presence of an optional Interior (Zone name = Interior)

  4. Decide to load the corresponding Interior (or not)

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…

  • GeoCell_D300_S001_T001_Lxx_Ux_Rx_FeatureCode_FSC_MODL.flt

  • GeoCell_D305_S001_T001_Lxx_Ux_Rx_FeatureCode_FSC_MODL.flt

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

  • D510_S001_T001_Lxx_FeatureCode_FSC_MODL.flt

  • D515_S001_T001_Lxx_FeatureCode_FSC_MODL.flt

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.

6.5.4. UHRB vs CDB Object Models

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.