The SEDRIS Data Representation Model
APPENDIX A - Classes
Model

Class Name: Model

Superclass - <SEDRIS Abstract Base>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

An instance of this DRM class specifies a representation of some environmental entity as a feature representation and/or a geometry representation. This representation is usually a generic representation that can be referenced many times in a transmittal to create many instances of representations of similar environmental entities.

The special case of the null model is the case in which both the feature and the geometric representation of the <Model> instance are empty; that is, they contain no primitives. This is instanced in cases where some state or condition of a representation exists but has no primitives, such as a representation of an environmental entity that has been completely destroyed or that is out of viewing range.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

Example

  1. The lowest level of detail of a tank's turret may be represented by a <Model> instance.

  2. A one degree by one degree tile of terrain containing thousands of instances to other <Model> instances may be represented by a <Model> instance.

  3. An aircraft carrier that has both a geometric representation and a feature representation may be represented by a <Model> instance.

  4. A data provider has an overall model (call it "automobile") made up of several components: top, two sides, four tires, back, front, underneath. When put into this data provider's <Model Library> instance, each of these components (as well as the overall "automobile" placeholder) is represented as a <Model> instance. The data provider's organization has a place in its database where "automobile" is instantiated that is represented in the resulting transmittal by a <Geometry Model Instance> instance of "automobile" appearing in the component tree of an <Environment Root> instance. No other <Model> instances in this data provider's mapping to the DRM can reference the "automobile" <Model> instance.

    In this case, the "automobile" has model_reference_type set to SE_MODREFTYP_ROOT, since "automobile" can be instanced outside the scope of the <Model Library> instance and has <Geometry Model Instance> instance in the component tree of an <Environment Root> instance.

    On the other hand, the "top" <Model> instance, representing the top of the automobile, cannot be instantated outside the <Model Library> instance in the data provider's scheme of things, but only as part of more complex <Model> instances; consequently, the "top" <Model> instance has model_reference_type SE_MODREFTYP_COMPONENT.

  5. A producer has a <Model> instance "plane" that has several components (such as two wings, a tail, and a fuselage). However, the producer has a <Model> instance "ship" that instances "plane" to specify a ship with planes on its deck. The transmittal instantiates "ship", which has model_reference_type = SE_MODREFTYP_ROOT. Since the <Model> instance "plane" could be used elsewhere in the transmittal, its instance under "ship" has model_reference_type = SE_MODREFTYP_ROOT_AND_COMPONENT.

FAQs

Why would a consumer need a dynamic_model_processing flag? When data is retrieved from a transmittal, won't the dynamic <Model> instances also be processed?

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

Given a transmittal containing a <Model Library> instance, consider a consumer who keeps track of which <Model> instances are instanced by some <Environment Root> instance. Does this information correlate at all with the dynamic_model_processing information of each <Model> instance?

Not necessarily.

As <Model Library> instances are passed around projects and re-used for purposes other than that for which they were built, many <Model> instances in any given <Model Library> instance may not be referenced in a given <Environment Root> instance that references that <Model Library> instance. For example, a <Model Library> instance may contain a <Model> component representing a free-standing brick wall that by chance is not instanced by any <Environment Root> instance, but this does not make the brick wall dynamic.

On the other hand, consider a <Model> instance B representing a biplane, in which the propellers are able to rotate. An <Environment Root> instance representing the Smithsonian Air and Space Museum might contain a reference to B representing one of the exhibits.

Can't any <Model> instance 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 SE_TRUE?

Although the consumer can determine additional processing for any data read from a transmittal, these flags are to be set by the data provider. If a <Model> instance is dynamic or has moving parts, then the data provider is required to provide this information.

Relating to the has_moving_parts flag, can't this information be derived by searching the entire <Model> instance for <LSR Transformation> instances that have <Control Link> instances attached to them?

Yes. The information is provided to allow consumers to detect at the "top" level of the <Model> instance whether it has moving parts anywhere within its scope, rather than forcing them to (potentially) search the entire <Model> instance to derive this information.

Why can a <Model> instance have at most two <Hierarchy Summary Item> components?

A <Model> instance is not required to have a hierarchy summary at all, but if a data provider wants to provide a summary of hierarchy, then a <Model> instance may have one summary for <Geometry Representation>, one summary for <Feature Representation>, or a summary of each.

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

Yes.

Constraints

Composed of (two-way)

Composed of (two-way metadata)

Component of (two-way)

Inherited Field Elements

This class has no inherited field elements.

Field Elements

SE_String name; 2
SE_SRF_Context_Info srf_context_info; 3
SE_Model_Reference_Type model_reference_type; 4
SE_Boolean dynamic_model_processing; 5
SE_Boolean has_units; 6
SE_Boolean has_moving_parts; 7

Notes

Composed of Notes


Identification

If provided, the <Identification> component may be used to provide a more detailed description than that specified by the name field.

Fields Notes

name

The name field specifies a meaningful short name.

srf_context_info

The srf_context_info field specifies the SRF within which the <Model> instance is defined.

model_reference_type

The model_reference_type field specifies how the <Model> instance may be referenced within a transmittal.

dynamic_model_processing

The value of the dynamic_model_processing field is SE_TRUE only if the <Model> instance is used by the data provider to represent something that moves throughout the environment, such as a vehicle. This flag is used to identify information at the top level of model data, so that it can be set at the level where model_reference_type is not SE_MODREFTYP_COMPONENT.

has_units

The has_units field only takes effect if the srf_context_info value specifies an LSR SRF. The has_units field allows a data provider to say "This LSR Model is in metres" vs. "This LSR Model is unitless (it has no units)". In the former case, when an LSR model is specified in metres, it can be used to represent real-world things, such as a tank, a ship, or a tree. Such a <Model> instance may be scaled when it is instantiated. (<Model> instances representing trees are often scaled, but those representing ships and tanks are not.) In the latter case when an LSR model has no units, the <Model> instance cannot be instantiated into another SRF.

has_moving_parts

The value of the has_moving_parts field is SE_TRUE only if the <Model> instance contains at least one <Control Link> instance attached to an <LSR Transformation Step> instance that allows motion.


Prev: Mesh Face Table. Next: Model Instance Template Index. Up:Index.

Last updated: July 26, 2006 Copyright © 2006 SEDRIS