Class Name: Model

Superclass - SEDRIS Abstract Base

Definition

A collection of Polygons and surfaces defined in the same spatial reference frame that represent some "thing". A Model might have no Points, Polygons, or Patches, i.e. the "null model".

Primary Page in DRM Diagram:

• 2

Secondary Pages in DRM Diagram:

• 10
• 16

Example

1. The lowest level of detail of a tank's turret.
2. A 1 degree by 1 degree tile of terrain containing thousands of instances to other Models.
3. A theme VITD data
4. An Aircraft carrier that has both a geometric representation and a feature representation.
5. A producer has an overall Model (call it "car") made up of several components: top, two sides, four tires, back, front, underneath. When put into the SEDRIS Model Library, each of these components (as well as the overall "car" placeholder) is considered a SEDRIS Model. The producers have a place in their database where "car" is instanced, so that at an IG the "car" appears. In this case, the Model field of "car" will have model_reference_type set to SE_ROOT_MODEL. Under Environment Root is the Geometry Model Instance for "car", the other components' Geometry Model Instances are instanced by "car". The database can only instance "car", it cannot instance the "top" of the car.
6. A producer has a Model "plane" that has several components (two wings, tail, fuselage, etc). However, the producer has a Model "ship" that instances "plane" to identify a ship with planes on its deck. The transmittal will instance "ship", and the Model field of "ship" will have model_reference_type set to SE_ROOT_MODEL. Since the Model "plane" could be used elsewhere in the transmittal, its instance under "ship" will have model_reference_type set to SE_BOTH_ROOT_AND_COMPONENT.

   In this way (5 & 6), consumers will be confident that at the point that model_reference_type is SE_ROOT_MODEL or SE_BOTH_ROOT_AND_COMPONENT, they have encountered an instantiable Model, and could do something like create a geometry source file or structures referencing "car", with the Geometry Model Instances under "car" as its components.

FAQs

I reuse the "tire" component on many types of car Models within a transmittal, but I also have it instanced by the transmittal in the case where I have a tire sitting by itself outside a gas station. Could I have the "tire" Model just once in the SEDRIS Model Library, with the "model_reference_type" set to SE_ROOT_MODEL? After all, it is sometimes seen as a "component", and sometimes as an instanced Model.

No. You should use SE_BOTH_ROOT_AND_COMPONENT. The producer must also realize that Models having model_reference_type set to SE_ROOT_MODEL or SE_BOTH_ROOT_AND_COMPONENT will have a unique name, in order to identify for easier consumption.

Won't this create extra levels of indirection if I have something like a plane Model, and the same Model is instanced from another Model, like a ship?

By identifying a plane Model as SE_BOTH_ROOT_AND_COMPONENT, then reuse is allowed, and no extra levels occur. Something like a "ship" Model can reference the "plane" as a component, and the "plane" and "ship" can both be instanced by Environment Root.

Why do I need a dynamic_model_processing flag? When I retrieve data from a SEDRIS transmittal, won't the dynamic Models also be processed?

That depends entirely on how the data processing code was written. If the code starts at Environment Root and processes everything that the components of Environment Root eventually refer to, then dynamic Models will not be processed unless the dynamic Model(s) have a connection to the database (unless at least one reference is made to the dynamic Model(s) from somewhere within Environment Root). In some Interchange systems, the way around this has been to "connect" the dynamic Model(s) to something like the SW corner of the database. However, this requires "adding" information, which is not the purpose of SEDRIS.

Won't I be able to tell which Models are moving by seeing which Models have been processed in the Model Library? Anything that hasn't been processed (since it is not referenced by Environment Root) must be dynamic?

Not necessarily. As Model Libraries have been passed around projects, many unused Models may exist. It would not be safe to assume that unreferenced Models must be dynamic.

Relating to the " has_moving_parts" flag, can't I find out this information by searching the entire Model for Transformations that have Control Links attached to them? Isn't that the method for determining if a Model has parts that can move?

That is correct. However, consumers of this data have expressed an interest in knowing at the top (model_reference_type set to SE_ROOT_MODEL or SE_BOTH_ROOT_AND_COMPONENT) level of the Model if the Model is going to have moving parts somewhere inside of it, instead of having to search through the Model to find out this information.

Can't any Model really be dynamic in the database? All I have to do is put it through my special processing, and it moves. Couldn't all the flags for dynamic_model_processing therefore be set to true?

Although the consumer can determine additional processing for any data read from SEDRIS, these flags are to be set by the vendor, and each vendor knows at the point of filling SEDRIS structures how they used a specific Model. If that Model was dynamic or had moving parts, then the vendor is required to set the flag appropriately.

Why can Model only have 0-2 Hierarchy Summary Item components?

An Model does not have to have a hierarchy summary (i.e. 0). If the data producer wants to provide a summary of hierarchy information, then a Model can have one summary for Geometry (i.e. 1), one summary for Features (i.e. 1), or a summary of each (i.e. 2).

Can Model have both Hierarchy Summary Item and Primitive Summary Item components (as opposed to either/or)?

Yes.

Constraints

• Hierarchy Summary Item For Environment Root and Models
• Locations Under Model
• LSR Model and Reference Surfaces
• Model Spatial Reference Frame
• No Attribute Conflicts
• Non Empty Model
• Unique Root Model Name
• Valid ID Field

Composed of (one-way)

• optionally, a Classification Data
• optionally, an Overload Priority Index
• optionally, some Property Values
• optionally, a Spatial Domain

Composed of (two-way)

• optionally, a Feature Model
• optionally, a Geometry Model
• a bounded set of Hierarchy Summary Items[0..2] (notes)
• optionally, an Interface Template
• optionally, some Primitive Summary Items

Composed of (one-way metadata)

• optionally, an Access
• optionally, some Browse Graphics
• optionally, a Citation
• optionally, some Cross References
• optionally, a Data Quality
• optionally, a Description
• optionally, a Keywords
• optionally, a Point of Contact
• optionally, a Time Constraints Data

Component of (two-way)

• one Model Library

Field Elements

Notes

Composed of Notes

Hierarchy_Summary_Item

 No hierarchy summary, <Geometry Hierarchy> summary,
 <Feature Hierarchy> summary, or both

Fields Notes

ID

 ID required to be unique from all other Model object IDs.

name

 A meaningful short name.  A full description will be in
 the <Description> component. This name is unique in a transmittal
 depending on the model_reference_type enumeration.

dynamic_model_processing

 Set to true only if this model is used by the vendor as a model that
 moves throughout the database (e.g. car, plane, tank, ship).
 This flag is used to identify information at the top level of model
 data, so it can only be set at the level where "model_reference_type"
 is not SE_COMPONENT_MODEL.

has_units

 Only takes effect if the srf_params are LSR.

 This flag allows a producer to say "This LSR Model is in meters" vs.
 "This LSR Model is unitless (it has no units)".

 Sometimes we want LSR models in meters, when we are modeling real-world
 things, e.g. tanks, ships, trees. Sometimes those models are scaled when
 instanced (trees are commonly scaled, but ships and tanks aren't.)

 Sometimes we want an LSR model to be purely unitless (e.g. a logo
 model).

has_moving_parts

 Set to true only if this model contains Control Links attached to
 Transformations, which allow or limit motion (e.g. vanes on a windmill).