The SEDRIS Data Representation Model
APPENDIX A - Classes
Image Anchor

Class Name: Image Anchor

Superclass - <SEDRIS Abstract Base>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

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:

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

This class appears on only one page of the DRM class diagram.

Example

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

  2. If a producer has a geo-referenced <Image> data that is to be explicitly applied to one or more terrain <Polygon> instances, the mapping of the image data to the <Polygon> instances would be defined by an <Image Mapping Function> (component of each <Polygon>) that has an <Image Anchor> and an association to the appropriate <Image>.

FAQs

Is it necessary to define spatial reference frame parameters for every <Image> in an <Image Library>?

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.

In a given <Image Library>, are all geo-specific <Image> instances required to specify the same spatial reference frame parameters? If so, why not store those parameters within the <Image Library> rather than in <Image Anchor> components for individual <Image> instances?

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.

Can the spatial reference frame parameters defined for a geo-specific <Image> differ from those specified for its native transmittal's <Environment Root>, and if so, why?

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.

How can a data provider transmit an <Image> and its associated warping?

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

Constraints

Composed of (two-way)

Component of (two-way)

Inherited Field Elements

This class has no inherited field elements.

Field Elements

SRM_SRF_Parameters srf_parameters;

Notes

Composed of Notes


Location

 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.
 - The first <Location> component specifies the location
   to which the lower left corner of the <Image> is mapped.
 - The second <Location> component specifies the location
   to which the upper left corner of the <Image> is mapped.
 - 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.
 - 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.

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

Prev: Image. Next: Image Library. Up:Index.

Last updated: May 15, 2003 Copyright © 2003 SEDRIS™