Abstract Class Name: Primitive Geometry

Superclass - Geometry

Subclasses

• Finite Element Mesh
• Linear Geometry
• Point Geometry
• Surface Geometry
• Volume Geometry

Definition

An abstract class that specifies the basic data to describe a Geometry.

Primary Page in DRM Diagram:

• 5

Secondary Pages in DRM Diagram:

• 3
• 4
• 18

Example

In processing subfaces, traversal and drawing order of the objects is depth first.

Structure:

 p1
 |--------|
 p2       p3
 |----|   |----|----|
 p4   p5  p6   p7   p8

Becomes:

FAQs

How do I retrieve the Polygons in the right order?

In order to consume, set up a component iterator for Primitive Geometry on the first Union of Primitive Geometry with search depth of 0 and traversal method to SE_DEPTH_FIRST. This will return the Polygons in their rendering order.

What happens with Union of Primitive Geometries under Continuous Level of Detail Related Geometries?

As a business rule, Union of Primitive Geometries under Continuous Level of Detail_Related Geometries are not allowed to have other Union of Primitive Geometry objects. Terrain Polygons usually do not have subfaces. If there is a terrain Polygon with another coplanar Polygon, then the Rendering Priority Level object is used to determine the correct drawing order. This is usually a layering issue where soil is usually drawn first, then vegetation, then water, etc...

What happens if a Rendering Priority Level is encountered under a subfaced Polygon?

Rendering Priority Level should be handled normally. If one is encountered, then the siblings for that Polygon should be examined and those siblings with a lower rendering priority should be processed before those with a higher rendering priority.

What should the reason_for_ordering be for the Union of Primitive Geometries?

The reason_for_ordering could still be valid for any of the enums currently in Union of Primitive Geometry. The actual drawing order is explicitly defined using a depth-first search for the Primitive Geometries.

When a Primitive Geometry contains a Union of Primitive Geometry for nesting reasons, what are the restrictions on the nested Primitive Geometries?

As a business rule, when a Primitive Geometry contains a Union of Primitive Geometry, for nesting reasons, the resulting geometry must be coplanar. Only Polygon, Ellipse, Line, Arc, and Point Primitive Geometries can have nesting, except for Elliptic Cylinder with Finite Element Mesh (see below).

The possible combinations at any level of nesting are:

• Polygon can nest:
  Polygon, Ellipse, Line, Arc, Point, and Finite Element Mesh
  
• Ellipse can nest:
  Polygon, Ellipse, Line, Arc, Point, and Finite Element Mesh
  
• Line can nest Line, Arc, and Point
  
• Arc can nest Line, Arc, and Point
  
• Point can nest Point
  
• can nest:
  Finite Element Mesh as interior 3-D mesh
  
• Finite Element Mesh cannot nest.

Constraints

• No Attribute Conflicts
• Non Crossing Aggregations
• Non Cyclic Aggregations
• Precedence of Attribute Set Index
• Color Mapping Restrictions
• Image Mapping Functions and Texture Coordinates
• Nested Primitive Geometry
• Non Nestable Continuous LOD

Composed of (one-way)(inherited)

• optionally, some {ordered} Attribute Set Indices
• optionally, a Classification Data
• optionally, some Property Tables
• optionally, some Property Table References
• optionally, some Property Values

Composed of (one-way)

• optionally, some Tack Points
• optionally, some {ordered} Colors
• optionally, a Light Rendering Properties
• optionally, a Rendering Properties
• optionally, some {ordered} Image Mapping Functions
• optionally, a Rendering Priority Level

Composed of (two-way)

• optionally, a Union of Primitive Geometry

Composed of (one-way metadata)(inherited)

• optionally, a Time Constraints Data

Component of (two-way)

• one or more Union of Primitive Geometries