Definition

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>.

Rationale

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 Vector> and <World 3x3> instances to automatically inherit a <Location> component as required for some coordinate transformations and conversions.

Example

1. A large <Polygon> with a <Reference Vector> component might use the "centre" of the <Polygon> for the <Reference Vector>'s <Location> component.

2. A <Line> with a <Reference Vector> component might use the <Location> of one of its <Vertex> components for the <Reference Vector>'s <Location> component.

3. An <Infinite Light> is shining down on the local area. The "down" direction <Reference Vector> component shall have a localizing <Location> component, since parallel translations of a "down" vector will not point down over most places on the Earth's (curved) surface.

4. A <Positional Light> has both a <Location> component and a <Lobe Data> component. The <Lobe Data>, in turn, has 2 <Reference Vector> components. These two <Reference Vector> instances inherit the <Positional Light> instance's <Location> component by this rule.

FAQs

How does choice of <Location> component affect <Reference Vector> instances in <Model> instances that have been specified in LSR spatial reference frames?

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 in the context of an <Environment Root> instance or another <Model> instance, the SRF of which has a curvilinear coordinate system such as Geodetic, the effect may be noticeable with a large <Model> instance.

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.

How does the data consumer use this form of inheritance?

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.