|
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 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.
The lowest level of detail of a tank's turret may be represented by a <Model> instance.
A one degree by one degree tile of terrain containing thousands of instances to other <Model> instances may be represented by a <Model> instance.
An aircraft carrier that has both a geometric representation and a feature representation may be represented by a <Model> instance.
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.
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.
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.
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.
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.
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.
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.
Yes.
| 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 |
The name field specifies a meaningful short name.
The srf_context_info field specifies the SRF within which the <Model> instance is defined.
The model_reference_type field specifies how the <Model> instance may be referenced within a transmittal.
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.
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.
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.
|