The SEDRIS Data Representation Model
APPENDIX A - Classes
Model
|
|---|
Class Name: Model
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, a geometric
representation, or both. 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> 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
- The lowest level of detail of a tank's turret.
- A 1 degree by 1 degree tile of terrain containing thousands of
instances to other <Models>.
- An aircraft carrier that has both a geometric representation
and a feature representation.
- A data provider has an overall model (call it "car")
made up of several components: top, two sides, four tires, back, front,
underneath. When put into this data provider's <
Model Library>, each of these components (as well as the overall
"car" placeholder) is represented as an instance of
<Model>. The data provider's organization has a place
in its database where "car" is instanced, so that at an IG the
"car" appears. This is represented in the resulting SEDRIS
transmittal by a <
Geometry Model Instance> of "car" appearing in the scope of
an <Environment Root>. No other
<Models> in this data provider's mapping to SEDRIS can
reference the "car" <Model>.
In this case, the "car" will have
model_reference_type set to
SE_MDL_REF_TYP_ROOT, since "car" can be instanced outside the
scope of the <Model Library>, and in fact has a
<Geometry Model Instance> under an
<Environment Root>.
On the other hand, the "top" <Model>,
representing the top of the car, cannot be instanced outside the
<Model Library> in the data provider's scheme
of things, but only as part of more complex <Models>;
consequently, the "top" <Model> has
model_reference_type
SE_MDL_REF_TYP_COMPONENT.
- 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", which has
model_reference_type =
SE_MDL_REF_TYP_ROOT. Since the <Model>
"plane" could be used elsewhere in the transmittal, its
instance under "ship" has
model_reference_type =
SE_MDL_REF_TYP_ROOT_AND_COMPONENT.
FAQs
- 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.
- As a consumer, if I am given a transmittal containing a
<Model Library>, I keep track of which
<Models> are instanced by some
<Environment Root>.
Does this information correlate at all with the
dynamic_model_processing
information of each <Model>?
- Not necessarily.
As <Model Libraries> are passed around
projects and re-used for purposes other than that for which they were
built, many <Models> in any given
<Model Library> may not be instanced in a
given <Environment Root> that references
that <Model Library>. For instance, a
<Model Library> may contain a
<Model> of a free-standing brick wall that by chance
is not instanced by any <Environment Root>,
but this does not make the brick wall dynamic.
On the other hand, consider a <Model> representing
a biplane, in which the propellers are able to rotate. An
<Environment Root> representing
the Smithsonian Air and Space Museum might contain an instance of this
<Model> representing one of the exhibits.
- 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 SE_TRUE?
- Although the consumer can determine additional processing for any
data read from SEDRIS, 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>
for <LSR Transformation> instances that
have <Control Links> attached to them?
- Yes. The information is provided to allow consumers to detect
at the 'top' level of the <Model> whether it has
moving parts anywhere within its scope, rather than forcing them to
(potentially) search the entire <Model> to derive this
information.
- Why can <Model> have at most 2
<Hierarchy Summary Item> components?
- A <Model> 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> may have one
summary for <Geometry>, one summary for
<Features>, or a summary of each.
- Can <Model> have both
<Hierarchy Summary Item> 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.
Notes
Fields Notes
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.
Set to SE_TRUE only if this <Model> 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 it can only be set at the level where "model_reference_type"
is not SE_MDL_REF_TYP_COMPONENT.
Only takes effect if the srf_parameters are LSR.
This flag allows a producer to say "This LSR Model is in metres" vs.
"This LSR Model is unitless (it has no units)".
Sometimes we want LSR models in metres, 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).
Set to SE_TRUE only if this model contains <Control Links> attached to
<Transformations>, which allow or limit motion.
Prev: Mesh Face Table.
Next: Model Instance Template Index.
Up:Index.
|
Last updated: October 1, 2002
|
Copyright © 2002 SEDRIS™
|
|