|
The SEDRIS Data Representation Model
APPENDIX A - Classes Image Anchor |
|---|
An instance of this DRM class specifies where the given <Image> is located in the specified spatial reference frame.
<Image Anchor> is used in 2 ways:
In this case, the <Image> is not tied to a particular <Feature> or <Geometry>, and the <Image Anchor>'s <Location> components merely specify the positions of the corners of the <Image> in the specified spatial reference frame.
Please note that if 2 geo-referenced <Image> instances are to be placed exactly next to each other by means of <Image Anchor> components, the <Location> components of those <Image Anchor> instances would be exactly the same along the common edge.
In this case, the <Image Anchor> defines how the associated <Image> is to be applied to the object having the <Image Mapping Function> instance as a component, and the spatial reference frame parameters of the <Image Anchor> shall match those of the context in which the <Image Mapping Function> is being applied.
<Image Anchor> instances are used to support spherical and cylindrical image projections for <Image Mapping Function> instances. By specifying anchor points that are not in the same plane, non-orthogonal projection becomes possible.
Note that when an image mapping is applied to many <Polygon> instances using a single <Image Mapping Function>, a "continuous" image should result when displayed.
A producer has a geo-specific "global" texture that has been derived from overhead photography and rectified. It might, for example, be used to "drape" over a terrain surface. This would typically be represented as an <Image> (in an <Image Library>) with an <Image Anchor> component.
If a producer has a geo-referenced <Image> data that is to be explicitly applied to one or more terrain <Polygons>, the mapping of the image data to the <Polygons> would be defined by an <Image Mapping Function> (component of the <Polygon>) that has an <Image Anchor> and an association to the appropriate <Image>.
No. An <Image> instance is not required to specify an <Image Anchor>, and in fact, an <Image> utilizes its optional relationship with <Image Anchor> only when the texture is geo-specific.
Consequently, since spatial reference frame parameters are defined for an <Image> instance only if an <Image Anchor> is present as a component of that <Image>, only geo-specific textures require assignment of spatial reference frame parameters.
Although all geo-specific textures in an <Image Library> may have the same parameters, this is not a requirement for data providers, nor can it be relied upon by consumers. Consequently, each geo-specific <Image> may specify an independent spatial reference frame.
Furthermore, many data providers generate <Image> instances that are not geo-specific and thus do not require spatial reference frame parameters. Adding spatial reference frame parameters as a field of <Image Library> would require all data providers to specify spatial reference frames for all <Image Library> instances, even those to which spatial reference frame parameters were not applicable.
A geo-specific <Image> is not required to specify the same spatial reference frame parameters as that of any of the <Environment Root> instances that may be present in its native transmittal. It is perfectly possible for a transmittal to contain multiple <Environment Root> instances, each with its own spatial reference frame, or to have an <Image Library> and no <Environment Root> instances whatsoever.
<Image Anchor> instances only provide for a simple method of <Image> warping. It is assumed that for more complex forms of warping (i.e., "rubber sheeting", ortho-rectification) the <Image> will be warped by the data provider and transmitted in the final state.
| SRM_SRF_Parameters | srf_parameters; |
|---|
The three <Location> components of an <Image Anchor> instance
are interpreted as the locations of corners of the given <Image>
instance, *NOT* those of the centre of the texels in the corners
of the <Image>.
When an <Image Anchor> is interpreted as a component of an
<Image>, or as a component of an <Image Mapping Function>
specifying a planar projection, the <Location> components
of the <Image Anchor> are interpreted as follows.
(1) The first <Location> component specifies the location
to which the lower left corner of the <Image> is mapped.
(2) The second <Location> component specifies the location
to which the upper left corner of the <Image> is mapped.
(3) The third <Location> component specifies the location
to which the upper right corner of the <Image> is mapped.
When an <Image Anchor> is interpreted as a component of an
<Image Mapping Function> that specifies a non-planar projection,
the <Location> components of the <Image Anchor> are interpreted
as follows.
(1) For a cylindrical projection, the first <Location> specifies
the centre of the cylinder. The second specifies a point
at the centre of the top of the cylinder, thus indicating
direction. The third <Location> specifies the alignment
of the cylinder by specifying a point on the surface of
the cylinder.
(2) For a spherical projection, the first <Location> specifies
the centre of the sphere. The second specifies the point at
the "north pole" of the sphere, thus indicating direction.
The third <Location> specifies a point on the "equator"
of the sphere.
|