An instance of this DRM class specifies, for the hierarchy instance(s)
of which it is a component, a surface which is to be used to
resolve the elevation of <Location 2D>
instances in the
component tree rooted at each hierarchy instance.
An <Environment Root> has both a
<Union Of Geometry Hierarchy> and a
<Union Of Features> component.
The <Union Of Geometry Hierarchy>
contains a
<Union Of Primitive Geometry>
with a <Classification Data> (specifying
ECC_TERRAIN_ELEVATION). This
<Union Of Primitive Geometry>
contains <Polygon> instances, which inherit the
<Classification Data>. The
<Union Of Features> has a
<Reference Surface> component, which
associates to the
<Union of Primitive Geometry>
and has these field values:
<Location 2D> instances found in the
<Union of Features>
aggregation tree use the terrain polygons to resolve
elevation.
Continuing example 1, the
<Union Of Geometry Hierarchy> under the
<Environment Root> contains another
<Union Of Primitive Geometry>
with <Polygon> instances classified as
ECC_INLAND_WATER_ELEVATION. The
<Union Of Features> aggregates a
<Union Of Features>, which is classified as
ECC_ENGINEERING_BRIDGE and contains
<Linear Features> using
<Location 2D> instances. The
<Union Of Features> also contains a
<Reference Surface> with
<Classification Data> tagged as
ECC_INLAND_WATER_ELEVATION, and
associated to the
<Union Of Primitive Geometry>.
Consider a <Reference Surface> instance
for which the geometry is a
<Spatial Index Related Geometry>
the components of which are all
<Classification Related Geometry>. Each
<Classification Related Geometry> contains 3
<Union Of Primitive Geometry>
instances: one for terrain surface polygons, one for road
polygons (which may or may not be part of the road surface),
and one for forest canopy polygons.
<Reference Surface> would associate to
the
<Spatial Index Related Geometry>, and its
classification field
would be set to ECC_TERRAIN_ELEVATION. The
resolution process then
ignores the road and canopy polygons, but sees all the terrain
polygons regardless of which union they're in.
Consider a <Linear Feature> representing a road,
which mostly stays on the road geometry but sometimes strays off. This
<Linear Feature> is placed in a
sub-<Union Of Features> aggregating a
different <Reference Surface> instance, which
associates to the same
<Spatial Index Related Geometry> but has
classification =
ECC_ROAD. The resolution process for this
<Reference Surface> sees the road
<Polygon> instances and ignores the others. For
<Feature Node> instances that stray off the road,
the corresponding <Location 2D> instances' rays
will fail to intersect any road polygon, so case 3 (empty intersection set)
applies, and the resolution process falls back on the previous override,
which was the terrain surface.
Using a specific plane for elevation resolution, such as
a carrier deck, or a landing plate. Represent the
plane with one or more <Polygon> instances,
putting them under a
<Union Of Primitive Geometry>
and classifying them. Use that
<Union Of Primitive Geometry>
for the <Reference Surface> associated
<Geometry Hierarchy>, and use the same
classification for the
classification field.
Terrain is organized in 3 minute regions, which are grouped
into 1 degree cells, where the 1 degree cells are collected
under one
<Union Of Geometry Hierarchy>. In addition,
<Features> and non-terrain
<Geometry> are organized under a corresponding
spatial organization. Each 3 minute hierarchy has a
<Reference Surface> associated to the
corresponding 3 minute terrain. Each 1 degree hierarchy has a
<Reference Surface> associated to the
corresponding 1 degree terrain. Each of the highest level feature
and non-terrain geometry hierarchies has a
<Reference Surface> associated to the
terrain <Geometry Hierarchy>.
In this scheme, a <Location 2D> in a 3
minute region finds its resolution surface in the corresponding 3
minute terrain. If a <Location 2D>
"strays" outside its region (i.e.,
strict_organizing_principle=SE_FALSE), then the containing
1 degree terrain resolves the
<Location 2D>. If the location
ray fails to intersect the 1 degree surface, then the full
terrain
<Union Of Geometry Hierarchy> is used. If ray / surface
intersection still fails, the elevation is resolved by the
vertical datum.
- Why does a hierarchy need a
<Reference Surface>? What do you mean
by "elevations" for <Location 2D>
instances? They don't have elevation.
In a 3D spatial reference frame, <Location 2D>
instances are thought of as lying on a surface. Which surface is intended
seems to be subjective at best. A cartographer may prefer the
vertical datum as the
<Location 2D> surface, while others prefer the
"terrain surface". Terrain surface is also a subjective term,
and terrain surfaces have been mapped to the DRM in a variety of ways.
Even if one notion of surface for <Location 2D>
instances were mandated, it would not meet everyone's requirements.
The solution is to mandate a clearly defined surface (the initial
default) and provide a flexible mechanism to override the default
for all or for selected parts of the transmittal.
- How does a <Feature Hierarchy> or
<Geometry Hierarchy> use a
<Reference Surface> to resolve elevations
for aggregated <Location 2D> instances?
Consider a <Reference Surface> that is
associated to a <Geometry Hierarchy> that
contains a surface. A <Location 2D> corresponds to
the (unique) ray which is:
- normal to the surface of the SRF ellipsoid (*),
- intersects the ellipsoid at the same horizontal coordinates as the
<Location 2D>, and
- extends below the surface of the ellipsoid to a depth
equal to the minor radius of the ellipsoid.
(*) NOTE:
For augmented Projected SRFs, this is the projection ellipsoid. For LSR,
use the z=0 plane, where z is the coordinate axis specified by the
SRM_LSR_Parameters_3D
up_direction value.
The intersection of this ray with the resolution surface defines the
candidate set for the corresponding 3D location. One 3D location is
selected from the ray/surface intersection set according to the
following three cases.
If the set contains 1 and only 1 element, the spatial position
of that point resolves the <Location 2D>
instance.
If the set contains more than one element, the
<Reference Surface> field
multiplicity_rule
value is used to select exactly one element.
(For instance, if several overlapping
<Property Grids> with <Grid Overlap> components
are part of the <Reference Surface>, use
<Grid Overlap>'s rules to define the
<Reference Surface> in the overlap region
of two or more of the surface grids. If the intersection set still has
more than one point, use
multiplicity_rule.)
If the intersection is empty, then look for other
<Reference Surface>
instances higher up the aggregation tree and repeat this resolution
process with that surface instead. If there are no other
<Reference Surface>
instances higher up the aggregation tree, then use the
vertical datum, which is guaranteed to be a case 1 surface.
(See also example 5).
- What if there is no single
<Union Of Primitive Geometry> that defines the
<Reference Surface>?
There is no requirement that the aggregate be free of non-reference
surface geometry (See example 3). In this case, find the higher level
<Geometry Hierarchy> that aggregates
the desired
<Union Of Primitive Geometry> sub-hierarchies, and use that for the
<Reference Surface> association.
- What happens to <LSR Location 2D>
instances in an LSR <Model> when the
<Model> is instanced by a model instance object in a
non-LSR 3D spatial reference frame?
That depends on whether or not the scoping SRF supports
<Location 2D> instances.
If <Location 2D> instances are supported
in the scoping SRF, (for example, if the scoping SRF is 3D geodetic,
for which 2D geodetic exists), these
<LSR Location 2D> instances are converted
to <Location 2D>
instances in the instancing 3D SRF using a 3 step process.
- Otherwise, if the scoping SRF does not support
<Location 2D> instances, then
the <LSR Location 2D> is converted
to 3D by setting the tertiary axis value to zero.
(Note 1): LSR models are not permitted to contain
instances; see constraints.
(Note 2): Conformal behaviour may also be modeled with
<LSR Location 3D Control Link> instances.
- Can a <Geometry Model Instance>
be used for a <Reference Surface>
association?
Yes, if the <Model>'s spatial reference frame
matches the currently scoped 'world' spatial reference frame.
- How are <Location 2D> instances converted
consuming data in a different spatial reference frame?
There are two cases.
Case 1 - both SRFs have the same horizontal datum.
Case 2 - The two SRFs have different horizontal datums.
In case 1 (Same horizontal datum), the ray determined by the
<Location 2D> is invariant, so the
horizontal coordinates are converted in the usual way.
In case 2 (Different horizontal datums), the ray may change, so three
steps are needed:
- If a transmittal is consumed in an SRF other than its native
SRF, should elevations be resolved in the originating or the
consuming SRF?
It should not make a difference if the two SRFs are both
"real world" or
both Augmented Projected Coordinate Systems (APCS). In the case in which
one is "real" world and the other is APCS, there are
two ways to deal with the "conversion distortion" that
tends to bend flat surfaces.
Consider a <Location 2D> whose ray intersects
the resolution surface near the centre of exactly one triangular
<Polygon>. The intersection point determines the
elevation, and therefore a corresponding
<Location 3D>. If you resolve in the first SRF, and then convert the
<Location 3D>, the location will match the
transmittal point, but it may no longer lie on the triangle's surface.
On the other hand, if you convert the
<Location 2D> and then resolve in the second SRF,
the corresponding <Location 3D> will lie on the
triangle's surface, but may differ a little
in elevation from the originating point. Therefore if absolute location
is more important than conformality, resolve in the originating SRF.
If conformality is more important, resolve in the consuming SRF.