Class Name: Feature Volume

Superclass - <Feature Topology>

Subclasses

Definition

An instance of this DRM class is a three-dimensional <Feature Topology> instance used to represent the region of space that corresponds to parts of zero or more <Volumetric Feature> instances, bounded by two or more <Feature Face> instances.

Primary Page in DRM Diagram:

• 12

Secondary Pages in DRM Diagram:

• 8

Example

1. Consider a <Volumetric Feature> instance representing a building as depicted in Figure 6.17:

   

   Figure 17 — <DRM Feature Volume> example

   It has:

   1. an associated <Feature Volume> instance that defines its extent, shape, and topological relationships;
   2. a <Classification Data> component that classifies it as an ECC_BUILDING;
   3. <Property Value> components that describe its characteristics, such as material composition; and
   4. a <Label> component that identifies it as "The Empire State Building".

FAQs

When are <Feature Volume> instances required?

<Feature Volume> instances are required whenever there are <Volumetric Feature> instances, regardless of the feature topology level.

Are there any geometric constraints on <Feature Volume> instances?

Yes. <Feature Volume> instances must always have closed external boundaries, and their interiors must be fully connected. At feature topology level 5, the interiors of <Feature Volume> instances may not intersect or overlap one another, and <Feature Volume> instances may meet only along one or more common <Feature Face> instances.

Can <Feature Volume> instances exist at any feature topology level?

Yes. <Feature Volume> instances may exist at any feature topology level in order to define the extents of <Volumetric Feature> instances. At feature topology level 5, the collection of <Feature Volume> instances must exhaustively and exclusively partition the 3-dimensional topological space, such that exactly two <Feature Volume> instances shall be bounded by each <Feature Face> instance.

Looking at the relationships allowed for <Feature Topology> instances, we note that the <Feature Node> to <Feature Node> association, and the <Feature Edge> to <Feature Edge> association are "many to many", while the <Feature Face> to <Feature Face> association is "optional to optional". Why is there no corresponding association between <Feature Volume> instances?

These associations exist to support cross-tile topology. This refers to topological relationships that cross multiple branches below a <Spatial Index Related Features> instance, a <Spatial Index Related Feature Topology> instance, a <Perimeter Related Features> instance, or a <Perimeter Related Feature Topology> instance. <Feature Node> instances, <Feature Edge> instances, and, in 3D, <Feature Face> instances can be located on the boundary of a tile. When this happens, they have "counterparts" in each of the adjacent tiles that share the boundary. These associations allow <Feature Node> instances, <Feature Edge> instances, and <Feature Face> instances to identify their counterparts, if any.

In 2D,

• tile boundary <Feature Node> instances come in pairs, unless they're located at a corner where four tiles meet,
• tile boundary <Feature Edge> instances always come in pairs,
• <Feature Face> instances are always contained within a single tile.

In 3D,

• tile boundary <Feature Node> instances can come in
  • pairs, if they're located within a tile boundary <Feature Face> instance,
  • fours, if they lie on a tile boundary <Feature Edge> instance, or
  • eights, if they are at a tile boundary corner.
• tile boundary <Feature Edge> instances can come in
  • pairs, if they are contained in a tile boundary <Feature Face> instance, or
  • fours if they lie on a tile boundary <Feature Edge> instance.
• tile boundary <Feature Face> instances only come in pairs, so a <Feature Face> instance can have at most one counterpart.
• <Feature Volume> instances cannot be part of a tile boundary (though their bounding <Feature Face> instances can). Therefore, <Feature Volume> instances never have counterparts in adjacent tiles.

Constraints

• <<Publishable Object>>
• <<Property Constraints>>
• <<Constraints On Associates>>
• <<Contained Edge Constraints>>
• <<Contained Node Constraints>>
• <<Faces Bordering Volumes>>
• <<Volume Shell Face Consistency>>

Associated by (one-way)

• zero or more <Feature Face> instances¹

Associated with (two-way)

• zero or more <Feature Edge> instances²
• zero or more <Feature Node> instances³
• zero or more <Volumetric Feature> instances

Composed of (two-way) (inherited)

• zero or more <Property Value> instances

Composed of (two-way)

• zero or more {ordered} <Feature Volume Shell> instances⁴

Component of (two-way) (inherited)

• zero or more <Union Of Feature Topology> instances

Inherited Field Elements

Field Elements

Notes

Associated from Notes

Feature_Face

Associated with Notes

Feature_Edge

Feature_Node

Composed of Notes

Feature_Volume_Shell

Fields Notes

universal

The universal field specifies that the <Feature Volume> instance is the universal <Feature Volume> instance. Within a 3D tile that has feature topology level 5, the universal <Feature Volume> instance lies outside any other volumes. Since the external boundary of the universal <Feature Volume> instance is conceptually at infinity, a <Feature Volume> instance that has this field set to SE_TRUE has no external <Feature Volume Shell> instance.