|
The SEDRIS Data Representation Model
APPENDIX A - Classes Model |
|---|
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.
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 <Model> instances.
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.
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 <Model> instances will not 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 SW corner of the database. However, this requires "adding" information, which is not the purpose of SEDRIS.
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 instance, a <Model Library> may contain a <Model> instance representing 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.
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.
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.
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 Representation>, one summary for <Feature Representations>, or a summary of each.
Yes.
If provided, the <Description> component may be used to provide a more detailed description than that specified by the name field.
The name field specifies a meaningful short name.
The srf_info field specifies the SRF within which the given <Model> instance is defined.
The model_reference_type field specifies how the given <Model> instance may be referenced within a transmittal.
The value of the dynamic_model_processing field is SE_TRUE only if the given <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_MDL_REF_TYP_COMPONENT.
The has_units field only takes effect if the srf_info are LSR; has_units 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. Sometimes such a <Model> is scaled when it is instanced. (<Model>s representing trees are often scaled, but those representing ships and tanks aren't.) In the latter case, when an LSR model has no units, the <Model> cannot be instanced into another SRF. One example of something that might be represented in this manner is a "logo model".
The value of the has_moving_parts field is SE_TRUE only if the given <Model> contains at least one <Control Link> attached to an <LSR Transformation Step> instance that allows motion.
|