|
The SEDRIS Data Representation Model
APPENDIX B - Constraints Required Reference Vector Location |
|---|
Given any object that has a <Location> component, that <Location> (or the first <Location> in an ordered list of <Location> components) becomes the (default) <Location> in the context for the aggregation tree stemming from that object.
A <Reference Vector> is required to have a <Location> component whenever the <Reference Vector> is a component of a <Polygon>, <Line>, <Infinite Light>, <Moving Light Behaviour>, or <Union Of Geometry>.
The SEDRIS API requires an appropriate <Location> to convert a <Reference Vector> to or from non-vector spatial reference frames, such as Geodetic. For most <Reference Vector> aggregators, the <Location> is supplied by the context inheritance mechanism. For the remaining classes covered by this rule, inheritance cannot be relied on to supply an appropriate <Location> component. Inheritance allows <Reference Vectors> and <World 3x3> to automatically inherit a <Location> component as required for some coordinate transformations and conversions.
In the case of <Model> instances that use LSR, the choice has no effect at all. The LSR origin (0, 0, 0), for example, could always be used. However, if the <Model> is instanced into an <Environment Root> or another model, the SRF of which has a curvilinear coordinate system such as Geodetic, the effect may be noticeable with a large <Model>. For example, if two <Reference Vector> instances in the <Model> are both pointing "up" and use the same <Location>, when the <Model> is instanced they will remain parallel but may no longer be pointing up. If, on the other hand, they each have a different <Location>, they each will point up at the corresponding instance <Location>, but they will no longer be parallel due to the curvature of the Earth.
The data consumer does not use it directly. It is sometimes used by the Read (Extraction) API implementation when the consumer requests data extraction in another spatial reference frame.
|