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 SRF.
<Image Anchor> is used in 2 ways:
In this case, the <Image> is not tied to a particular <Feature Representation> or <Geometry Representation>, and the <Image Anchor>'s <Location> components merely specify the positions of the corners of the <Image> in the specified SRF.
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 SRF 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 <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>.
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 SRF 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 SRF 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 SRF.
Furthermore, many data providers generate <Image> instances that are not geo-specific and thus do not require spatial reference frame parameters. Adding SRF parameters as a field of <Image Library> would require all data providers to specify SRFs for all <Image Library> instances, even those to which SRF parameters were not applicable.
A geo-specific <Image> is not required to specify the same SRF 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 SRF, 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.
SE_SRF_Info | srf_info; | (notes) |
---|
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.
The srf_info field specifies the SRF within which the given <Image Anchor> instance is defined.
|