The SEDRIS Data Representation Model
APPENDIX A - Classes
Reference Surface
|
|---|
Class Name: Reference Surface
Subclasses
This DRM class is concrete and has no subclasses.
Definition
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.
In addition, a <Reference Surface>
specifies how the surface is to be used in the resolution process.
A hierarchy instance requires a
<Reference Surface> if
- there are <Location 2D> instances
below the hierarchy,
- the <Location 2D> instances are in
the scope of a 3D spatial reference frame, and
- the data provider wants the locations to lie on a
surface other than the last default surface (The initial
default is the spatial reference frame's vertical offset model).
A <Geometry Hierarchy>'s and
<Reference Surface>'s field values
define a surface for the resolution process as follows; there
are several cases.
The <Geometry Hierarchy> is a
<Property Grid Hook Point> that
aggregates at least one <Property Grid>
with these qualifications:
its <Classification Data>
matches the <Reference Surface>'s
classification field,
it has 2 spatial axes corresponding to the horizontal coordinates
of the SRF, and
it has a
<Table Property Description> for height, elevation, or bathymetry.
If the <Property Grid> meets the above
criteria, then it defines a resolution surface.
The <Geometry Hierarchy> is a
<Union Of Primitive Geometry> that
aggregates <Surface Geometry> with
<Classification Data> matching
the <Reference Surface>'s
classification field.
In this case, all such <Surface Geometry>
instances combine to form the resolution surface. (Note that the
multiplicity_rule
field deals with surface complexity).
The <Geometry Hierarchy> is a
Distance, Index, Map Scale, or Spatial Resolution
<LOD Related Geometry> that aggregates (directly or
indirectly) <Geometry Hierarchy>
cases 1 and/or 2 above under an LOD branch selected by the
<Reference Surface>
lod_rule field.
The <Geometry Hierarchy> aggregates
some combination of cases 1, 2, or 3.
In general, the set of all
<Surface Geometry> and
<Property Grid> instances under the
<Geometry Hierarchy> is culled by
matching the <Reference Surface>
classification field
(and <Property Grid> qualifications) and matching
LOD branches to the lod_rule
field. The remaining geometry is the
resolution surface used for ray intersections.
Primary Page in DRM Diagram:
Secondary Pages in DRM Diagram:
Example
Consider an <Environment Root> instance
ER, having both a
<Union Of Geometry Hierarchy>
component UGH and a
<Union Of Features> component UF.
The <Union Of Geometry Hierarchy>
instance contains a
<Union Of Primitive Geometry>
instance UPG_1 with a
<Classification Data> component
specifying
ECC_TERRAIN_ELEVATION, and
contains <Polygon> instances, which inherit the
<Classification Data>. That is,
UPG_1 is a polygonal representation of terrain, forming part of the
larger environmental representation ER.
UF, the feature representation of ER, has a
<Reference Surface> component,
which associates to the
<Union of Primitive Geometry>
and has these field values:
Consequently,
<Location 2D> instances found in the
<Union Of Features>
aggregation tree of UF use the terrain polygons of UPG_1 to resolve
elevation.
Continuing example 1, the
<Union Of Geometry Hierarchy> UGH under ER contains another
<Union Of Primitive Geometry>
instance UPG_2
containing <Polygon> instances classified as
ECC_INLAND_WATER_ELEVATION.
UF, in turn, aggregates a
<Union Of Features>
instance UF_2, which is classified as
ECC_ENGINEERING_BRIDGE and contains
<Linear Feature> instances using
<Location 2D> instances.
UF_2 also contains a
<Reference Surface> instance with
<Classification Data> tagged as
ECC_INLAND_WATER_ELEVATION, and
associated to UPG_2.
Consequently, the
<Location 2D> instances
of the ECC_ENGINEERING_BRIDGE UF_2 will
have elevation values derived for them by being evaluated against UPG_2.
Consider a <Reference Surface>
instance R for which the geometry is a
<Spatial Index Related Geometry>
instance S. Each branch of S is a polygonal representation, part of which
represents terrain surface, part roads, and part forest canopy.
R associates to S, and its
classification field
is 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> L
representing a road, which mostly stays on the road geometry but
sometimes strays off. L is placed in a
<Union Of Features>
aggregating a different
<Reference Surface> instance R2 with
associates to the same
<Spatial Index Related Geometry> but has
classification =
ECC_ROAD, but which like R associates to S.
The resolution process for R2 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 the resolution
process (as per case 3) applies, and the resolution process falls back on
the previous override, which was the terrain surface.
Consider a terrain representation organized in 3 minute regions,
which are grouped into 1 degree cells that are collected under one
<Union Of Geometry Hierarchy>
instance. In the same transmittal,
<Feature Representation> and non-terrain
<Geometry Representation>
instances 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 offset model.
FAQs
- 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 offset model 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_3D_Parameters
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 offset model, 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 2D Location>
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 2D Location> 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 2D Location> 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 3D Location 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 ORM.
Case 2 - The two SRFs have different ORMs.
In case 1 (Same ORM), the ray determined by the
<Location 2D> is invariant, so the
horizontal coordinates are converted in the usual way.
In case 2 (Different ORMs), 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 elevations are resolved in
the first SRF, and the <Location 3D> is then
converted, the location will match the transmittal point, but it may
no longer lie on the triangle's surface.
On the other hand, if the <Location 2D> is
converted and then elevations are resolved 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.
Constraints
Associated to (one-way)
Composed of (two-way)
Component of (two-way)
Inherited Field Elements
This class has no inherited field elements.
Notes
Associated to Notes
This specifies the <Geometry Hierarchy> containing the
<Surface Geometry> and / or <Property Grid> instances to be used
as the resolution surface.
Composed of Notes
A <Reference Surface> instance has <Property Value> components
only when the classification of the <Reference Surface> requires
elaboration by <Property Value> instances.
Fields Notes
Within the resolution surface, use only geometry matching
the (possibly elaborated) classification specified by the
classification field.
The multiplicity_rule field specifies a rule to select a single
point from multiple intersections of a ray with a resolution surface.
The lod_rule field specifies a rule to select one LOD branch.
Prev: Reference Origin.
Next: Reference Vector.
Up:Index.
|
Last updated: July 16, 2004
|
Copyright © 2004 SEDRIS™
|
|