ISO/IEC CD2 18023-1 — SEDRIS functional specification

4 Concepts

4.1 Introduction and Table of contents

4.1.1 Table of contents

Table 4.1 contains the table of contents for this clause.

4.1.2 Introduction

This clause describes the fundamental SEDRIS concepts and how they interact with each other to provide a cohesive data representation system. Provision is made for representing data to the level of detail necessary to support a variety of information technology (IT) applications that will use or depend on SEDRIS-based environmental data.

4.1.3 Conventions used

Throughout this standard, special conventions and notations are formatted to distinguish between and add emphasis to various computer-related or SEDRIS-specific terms. Table 4.2 states these conventions and notations.

Table 4.2 — Document conventions and notations

4.2 SEDRIS and environmental domains

4.2.1 Purpose

Accurate and unambiguous representation of environmental data is an important part of many information technology applications. SEDRIS permits environmental representations that can be described accurately, unambiguously, and precisely.

Authoritative representations of the environment are expected to be internally consistent and conform to physics-based principles. Furthermore, environmental representations shall contain an appropriate integration of terrain, ocean, atmosphere, and space domain data about a region of interest. SEDRIS technology supports the representation of the physical as well as the abstract aspects of each environmental domain. In addition, the actual reference objects being modelled or described can be either real (e.g., some region of the Earth) or some artificial object. This latter capability is important in applications that evaluate the characteristics and performance of artificial objects with respect to environmental effects and impacts, prior to production (e.g., testing and evaluating land, water, air, and space vehicles). To meet these application requirements, SEDRIS technology also supports the representation of 3D models, including various articulations required to convey general system design characteristics, as well as data representation in the environmental domains of:

1. terrain,
2. ocean,
3. atmosphere, and
4. space.

Environmental representation of the terrain domain includes data on the location and characteristics of a planetary surface, natural and permanent or semi-permanent artificial features, and related processes including seasonal and diurnal variation. Examples of these include, but are not limited to, the representation of soil and subsurface characteristics, surface elevations, vegetation, roads, signs, vehicles, and buildings with interiors and included objects. The terrain also includes inland waters, as well as the ocean bottom (e.g., bathymetry and sediment types).

Environmnetal representation of the ocean domain includes data on the location and characteristics of natural and artificial features and description of the dynamic processes of the liquid planetary surface and subsurface. Examples of these include, but are not limited to, the representation of wave heights, depth pressure, vessels, buoys and impediments to navigation, temperature, salinity gradients, and acoustic phenomena.

Environmental representation of the atmosphere domain includes data on the characteristics of the gaseous envelope surrounding a planetary object and location and characteristics of liquid or solid particles contained within an atmosphere. Examples of these include, but are not limited to, the representation of particulate and aerosol data on haze, dust, smoke, fog, clouds, atmospheric pressure, wind, precipitation, humidity, obscurants, contaminants, nuclear/biological/chemical effects, radiated energy, temperature, and illumination. For the Earth, the atmosphere domain is specified to include the zone extending from the planetary surface to the lower mesosphere as part of a general transition area to the space domain.

Environmental representation of the space domain includes data on the location and characteristics of regions beyond the specified upper boundary of a planetary atmosphere. Examples of these include, but are not limited to, the representation of stars and the interstellar medium, natural or artificial celestial objects, neutral and charged atomic and molecular particles and their optical properties, solar winds, space weather, and electromagnetic effects. For the Earth, the space domain generally lies beyond the upper stratosphere as part of a general transition area from the atmosphere domain.

The boundaries of the various environmental domains are not precisely defined. An application may combine several environmental domains as appropriate to fulfill requirements. The challenge in such combinations is to ensure that consistency and correlation are achieved in the resulting environmental representation. SEDRIS technology provides the common framework for meeting this challenge.

4.2.2 Representational capability

4.2.2.1 Overview

This part of ISO/IEC 18023 also provides the requisite facilities necessary to model data according to the requirements of environmental applications. The SEDRIS Data Representation Model (DRM) supports the creation and instantiation of data model constructs specific to the requirements of each application while ensuring that such data can also be reused by other applications as appropriate.

The DRM supports a wide variety of concepts including:

• geometry,
• features,
• topology,
• metadata,
• attributes,
• classifications,
• relationships, and
• data organization.

These concepts and others will be described later in this part of ISO/IEC 18023.

The DRM’s ability to support a variety of data models is also the direct result of its support for the polymorphic representation of environmental objects. This means the same environmental object can be represented through various means. For example, a road can be represented as a linear feature while at the same time captured as a series of polygonal facets. Similarly, a cloud can be represented as a 3D grid of moisture content, a volumetric feature object, or represented as a cloudy region within a weather map. Neither representation changes the nature of the object, but rather reflects a particular application’s view of that object. Since the DRM allows multiple representations of environmental objects, applications that hold differing views of environmental objects may be supported.

In addition, the DRM permits the relationships between the various representations to be explicitly expressed. It does this by recording the "association" of the various representations, generally indicating that one form is an alternate representation of the other. The DRM also ensures that the form and structural semantics of the data are fully expressed and can be correctly understood by users.

Environmental data can often be organized based on a variety of schemas including: time, spatial partition, resolution, classification or theme, among others. The data organization capabilities in the DRM allow for a potentially infinite combination of organizational schemas without restricting the user to a particular resolution or order.

The DRM is at the heart of SEDRIS technologies, and is based on object-oriented techniques, the characteristics of which are described using the Unified Modeling Language (UML). It consists of a large variety of object-oriented classes that allow the description of any environmental data, regardless of resolution, domain, or density.

The combination of these classes and their relationships provides a rich, powerful, and expressive schema that can be thought of as the grammar of a language for describing environmental data.

4.2.2.2 Multiple representation requirements

Depending on context, the data about the same object can require different representations. An expressive language is able to support this multi-representation requirement. The variation of context in data representation is often considered as a “view” of the object being represented.

For example, depending on the application, a building can be "viewed" as a collection of facets describing its physical shape. Alternatively, the building can be "viewed" by its purpose or function, by its position, by how it obscures line of sight, or by other aspects established by the application requirements.

Similarly, a bridge can be “viewed” through different contexts. If route planning and transportation of goods is the context, the location of the bridge and its traffic patterns are of interest. If shipping or boating is the context, its height above the surface of the water or whether the bridge deck can be raised would be of interest. Many other examples exist.

In each of these examples, the data about the environmental object and its characteristics is valid and sufficient for a given application from a particular view and context. SEDRIS supports the representation of such potentially diverse views, without requiring that applications be burdened by conforming to unneeded representations.

4.2.3 Interchange and interoperability

4.2.3.1 Overview

This part of 18023 provides an infrastructure for the representation of environmental data with a subsequent ability to support interchange of that environmental data. Two aspects of the interchange of environmental data are the creation of the data (i.e., production) and the use of the data (i.e., consumption).

A producer may create data for a variety of purposes including tailoring a database for use by a particular customer or application. Such purposes are supported through the use of a common object model (the SEDRIS DRM as specified in this part of ISO/IEC 18023), a common file format (the SEDRIS abstract transmittal format specified in ISO/IEC 18023-2), and specific encodings such as specified in ISO/IEC 18023-3. Both are accessed through the application program interface that is specified in 7 Application program interface (API)).

The unambiguous and efficient representation and interchange of data is a precondition to interoperability. Data interoperability occurs when the producing and consuming applications can both unambiguously understand the organization, the meaning, and the context of the environmental data. While interoperability is not always perfectly achieved in practice, ISO/IEC 18023 specifies the mechanisms that make environmental data interoperability possible.

4.2.3.2 Reuse of environmental data

SEDRIS supports the creation and reuse of environmental data by providing a common representational mechanism. The DRM, EDCS, and SRM together make it possible for various applications to represent their environmental data in ways peculiar to their own requirements. When augmented with the SEDRIS API and standard encodings, the DRM, EDCS, and SRM also enable the sharing and reuse of this environmental data by others.

As a common environmental data interchange mechanism, it is not necessary that SEDRIS capture the unique requirements of each and every application. Rather it is sufficient to provide a common means for the data to be represented, accessed, and consumed as needed by the application. Each application's requirements for such data may differ, and are often driven by the context of the application. The processing of the data to satisfy those requirements is therefore part of the consuming application’s responsibility (and to some extent outside the domain of the interchange mechanism). SEDRIS makes it possible for such processing to be feasible. This means allowing data to be viewed from different perspectives. It also means providing data access facilities such that interface to data can be tailored to a given view and context under application control.

4.2.3.3 Complementary modelling

Different producers specialize in different aspects of environmental data production. This part of ISO/IEC 18023 is designed to allow data models to be created using content from different producers. By enforcing a standard data representation model for creating this data, consumers are able to mix data from different producers according to their differing strengths. For example, in a virtual tourism application, the following content might be provided by different producers:

1. the spatial positioning data of a city,
2. the visualizations of buildings in the city, and
3. street sounds from that city.

In a training application, different producers might provide:

1. the terrain data upon which a training simulation might occur,
2. >the data of a vehicle that is the object of the training,
3. standard dynamic models of features to be encountered by that vehicle, and
4. roadways along which that vehicle might travel.

There are many applications where sharing of data from many producers would be appropriate. This part of ISO/IEC 18023 facilitates the amalgamation of this data within the infrastructure provided by its data representation model.

4.3 SEDRIS technology components

4.3.1 Overview

This part of ISO/IEC 18023 is fundamentally about two key objectives:

1. the clear and unambiguous representation of environmental data, and
2. the practical and efficient interchange of environmental data.

To achieve these objectives, this part of ISO/IEC 18023 relies on five core technology components. These are:

1. the SEDRIS Data Representation Model (DRM),
2. the Environmental Data Coding Specification (EDCS) (see 2.[I18025]),
3. the Spatial Reference Model (SRM) (see 2.[I18026]),
4. the SEDRIS abstract transmittal format (ATF) as defined in ISO/IEC 18023-2 (see 2.[I18023-2]) standardized concrete transmittal formats such as the SEDRIS transmittal format binary encoding (STF) as defined in ISO/IEC 18023-3 (see 2.[I18023-3]), and
5. the SEDRIS application program interface (API).

Three of the core technology components of SEDRIS (DRM, EDCS, and SRM) are used to achieve the first objective. The combination of these three core technology components provides the mechanism for describing and articulating environmental data. This capability makes SEDRIS analogous to a language designed for describing data about the environment. The DRM, the EDCS, and the SRM enable producers and consumers to capture and communicate meaning and semantics about environmental data.

The second objective builds upon the first, and provides the ability to interchange and share environmental data. The SEDRIS API and the standardized concrete encodings provide the practical means for the interchange of environmental data that can be described through the combined use of the DRM, the EDCS, and the SRM.

The EDCS and the SRM have been designed as independent technologies that can be utilized by other applications or in other data representation schemas. Therefore, this part of ISO/IEC 18023 depends on EDCS and SRM as companion standards. These are briefly described in 4.4 Related standards and their use.

4.3.2 Representation of environmental data

4.3.2.1 Role of DRM, EDCS, and SRM

Representation of an environmental object requires a data model that allows the expression of the object’s semantics, including its possible relationship to other objects of interest, the composition and characteristics of that object, and the spatial attributes of that object. The DRM provides the technology necessary to express the representation of an environmental object. This means the manner in which an environmental object can be organized within a desired and appropriate hierarchy, as well as how that object may relate to other environmental objects, can be specified through the DRM.

The DRM relies on the EDCS, however, for describing the semantics of what an object is and what characteristics it has. New environmental concepts can be added to the EDCS dictionaries without changing the DRM. The EDCS dictionary entries are used by the DRM to describe what an environmental data object is (classification), or what its specific characterstics are (attribution).

Similarly, the DRM relies on the SRM for specifying the spatial location of an environmental data object, its extent, or its components in a proper spatial reference frame. Spatial reference frames, coordinate systems, datums, and other spatial characteristics for the expression of location information can be added to the SRM without impacting the DRM. This allows the DRM objects to use the necessary spatial reference frame to express location information of environmental objects, but leaves the complexities of the derivation and expression of the underlying mathematical concepts to the SRM.

4.3.2.2 Expression of environmental data and data models with the DRM

Specific data objects within the DRM are designated to hold values for location, classification, and attribution. The DRM objects used for the expression of location data use the spatial reference frame concepts from the SRM. The DRM objects that deal with the classification and attribution of environmental objects use the EDCS entries to express object-level semantics.

The DRM objects for location, classification, and attribution can be aggregated by other DRM objects used to express environmental objects as data primitives or assign them to organizational containers. To express a given environmental object or concept in a specific and appropriate data model, a set of DRM objects are instanced to represent that object or concept. This allows the DRM to represent a variety of data models.

Data primitives include constructs for the representation of points, lines, surfaces, volumes, meshes, networks, and n-dimensional point-sampled data. Such primitives, along with their location data, classification, and attribution, can be organized in various hierarchies, including by type, spatial extent, time, spatial relationships, and use. A collection of related instances of environmental objects creates a unique set of environmental data for use by specific applications or users.

The DRM, in conjunction with the EDCS and the SRM, can also be used to specify environmental data requirements by data modelers for a specific system or application. In these cases, no particular instance of DRM-based data is created, but rather the DRM is used to express a specific data model.

Whether the DRM is used to express a particular data model or instance of specific data, DRM objects may have relationships with other DRM objects in three different manners:

1. they may contain other objects (aggregation relationship);
2. they may be contained by other objects (component relationship); or
3. they may be otherwise affiliated with other objects (association relationship).

When such a relationship exists, the DRM object will be related to other DRM objects that are its aggregates, components, or associates, respectively. The nature of the allowed relationships is generally described in 4.5 Data representation model (DRM) syntax and is specifically described for each DRM class in 6.3 DRM class specifications.

4.3.3 Interchange of environmental data

4.3.3.1 Transmittals

4.3.3.1.1 Description

A hierarchy of DRM class instances organized according to the principles described in this part of ISO/IEC 18023 is called a SEDRIS transmittal. A SEDRIS transmittal contains only DRM objects with the representation and relationships prescribed by the DRM. A transmittal provides a standard medium for the interchange of environmental data.

Within this context, there are SEDRIS users who produce environmental data and there are SEDRIS users who consume the environmental data. Consumers of SEDRIS data use SEDRIS transmittals as inputs into specific applications or processes. SEDRIS data producers generate transmittals as output of their applications or processes. There need not be a one-to-one relationship between data producers and consumers; i.e., a data producer may generate data for more than one consumer and a consumer may receive data from more than one data producer.

4.3.3.1.2 >Interchange

SEDRIS transmittals themselves are not an interchange mechanism. Instead, they provide the media-based form for the exchange of environmental data. As a result, there is a requirement for storing the information contained within a transmittal in a form that allows its transport between SEDRIS implementations. This requirement is satisfied through the SEDRIS Abstract Transmittal Format (ATF), as specified in ISO/IEC 18023-2. Other parts of ISO/IEC 18023 specify the encodings for the ATF that describe the actual form in which data is stored. While the forms provided by each encoding may differ, the information content is the same for the same SEDRIS transmittal. In particular, ISO/IEC 18023-3 specifies a binary encoding referred to as the SEDRIS Transmittal Format (STF). The provision of a standard API (see 4.3.3.1.2 Access) means that applications are decoupled from specific transmittal encodings. Therefore, applications do not need to be concerned about the transmittal encoding used, and instead can interact with any encoding in exactly the same manner, via the API.

4.3.3.1.3 Inter-Transmittal Referencing (ITR)

Inter-Transmittal Referencing (ITR) is the mechanism that allows relationships between objects contained in different SEDRIS transmittals. For example, an aggregate in one transmittal can have an ITR reference to a component object in a different transmittal. Relationships that use ITR still follow the DRM relationship rules. Those DRM objects that can create relationships through ITR are limited by the DRM constraint, 6.2.46 Publishable objects.

4.3.3.2 Application Program Interface (API)

The SEDRIS API allows access to, and manipulation of, SEDRIS transmittals. The API decouples the user’s application from the specific format of the transmittal. It also provides access functions that allow data extraction independent of the transmittal’s data organization or presentation. It does this by allowing the calling applications to set a specific extraction context through filters. Under these conditions only data that matches the filter criteria is returned to the calling application. The key API concepts and overall characteristics of the API are specified in 4.19 Application program interface (API), and the specific functions are described in 7 Application program interface (API).

4.4 Related standards and their use

4.4.1 Overview

This part of ISO/IEC 18023 depends on other International Standards for specifications that are also applicable outside of the SEDRIS milieu. The following describe the primary companion standards required by this part of ISO/IEC 18023.

4.4.2 EDCS

The concepts embodied by SEDRIS often require indicating information about the data in a SEDRIS transmittal. This information is provided in the form of classifications of the environmental objects and attributes specifying properties of such objects. ISO/IEC 18025 — Environmental data coding specification (EDCS) (see 2.[I18025]) specifies the allowed classifications and attributes and also provides a mechanism for specifying new classifications and attributes. Since attributes have data associated with them, ISO/IEC 18025 also specifies codes for indicating the units of measure in which numeric attribute values are specified and codes for selecting enumerated values. A standard API is provided for specifying EDCS codes and attributes as well as a functional API for converting values from one unit to another.

4.4.3 SRM

The spatial concepts used within SEDRIS are specified in ISO/IEC 18026 — Spatial reference model (SRM) (see 2.[I18026]). The SRM specifies the mechanisms and the structure of spatial reference frames (SRFs) as well as the formal definitions for specific SRFs, the coordinate systems used within them, and the reference objects to which they are attached. ISO/IEC 18026 also provides standard functionality for converting spatial positions from one spatial reference frame to another. Representation of spatial data as well as the means of converting between representations is provided by the SRM API also specified in ISO/IEC 18026 (see 2.[I18026]).

4.4.4 Metadata

Metadata concepts used in this part of ISO/IEC 18023 are built on the concepts specified in ISO 19115 — Geographic information — Metadata (see 2.[I19115]).

4.5 Data representation model (DRM) syntax

4.5.1 Overview

Through the use of the data representation model, users of SEDRIS can describe and articulate their environmental data clearly while simultaneously using the same representation model to understand data from other users unambiguously. The DRM is an object-oriented data representation model and provides a unified method for describing all data elements and their logical relationships needed to express environmental data in a seamless manner across all environmental domains.

4.5.2 Specification techniques

A data representation model defines the manner in which specific data models can be represented, independent of any specific data content. A data representation model can be thought of as a meta-“data model”. The SEDRIS DRM defines object classes and relationships that allow a wide variety of environmental entities or phenomena to be represented as abstract forms, tables and grids, images, and/or forms that more closely resemble the geometric shape and configuration of the entity.

Generally, a data model defines individual classes to represent specific types of real-world entities or phenomena. A data model is the specific set of data structures, and their relationships, that specify the unique instance of data about a concept or an object. A data model is usually directly tied to the entity or concept it models. Attributes specific to each entity's class are "built-in" to the class definitions. The semantics of what specific entity or phenomena a given class represents is captured by the name and the attributes of that class. Often, data models are realized as a specific and rigid format or schema.

In contrast, a data representation model defines a mechanism where a variety of data can be modelled and represented through a common set of classes. The semantics and attributes of the specific entity or phenomena that a particular class represents are factored out. These are modelled as separate components of a given common class.

The DRM contains classes that can represent physical locations, and “property” classes that describe various characteristics through the use of EDCS. Such fundamental constructs in the DRM, along with its primitive classes for the representation of environmental data, can be used to model and instance any set of environmental objects. Since the primitive classes used in the representation are independent of any specific environmental object, and since such classes can contain other classes that use the EDCS to specify the semantics and the attributes of an object, different environmental entities or phenomena can be represented with the same classes.

Separating the semantics of what something is from the “data primitives” that can represent the thing is a fundamental concept in SEDRIS. An equally important concept is the factoring out of the common syntax and structural semantics of data models that are used to describe “similar things”. Combining these two methods (along with other important concepts that will be discussed later) allows a single schema to represent a large variety of possible data models.

4.5.3 Modelling technique and notation

This part of ISO/IEC 18023 uses Unified Modelling Language (UML) as specified in ISO/IEC 19501-1 (see 2.[I19501-1]) to model the DRM classes. UML notation is used to describe class diagrams as well as object diagrams that describe example instances of the data conforming to the related class diagrams. This subclause describes the extensions and deviations to conventional UML use.

UML describes object classes by providing the name, a set of attributes, and a set of operations or behaviours that can be performed by objects of that class. It provides this information by a rectangular box having three segments as shown in Figure 4.1

Figure 4.1—UML object class

The DRM class diagrams, provided in the DRM class specifications of 6 DRM classes, omit the attributes and operations instead only providing the class name in order to highlight the class relationships. The UML attribute listings are also provided in 6 DRM classes, but are referred to as “field” elements. Hence, there is a mapping between UML attribute elements and DRM field elements. In instance diagrams, the field elements are provided in the second rectangular box, consistent with UML.

Abstract classes (i.e., those that cannot be instantiated) are distinguished from concrete classes (i.e., those that can be instantiated) by depicting the name of the class in italics and by shading the box for the class.

UML defines an association as a semantic relationship between two or more classes. All associations have a directionality assigned that is either one-way or two-way.  One way association means that only one class is aware of the association relationship. If there is a one way association of A and B, and A is aware of the association, it is said that A is associated to B and B is associated by A. In two way associations, both classes are aware of the relationship. Hence if A and B have a two way association, A is associated to B and A is associated by B, as well as B is associated to A and B is associated by A.  All of these relationships are conveyed by the statement “A is associated with B”.

UML specifies a set of association relationships termed aggregation and composition. Aggregation is specified as a whole to part relationship in which instances cannot have cyclic aggregation relationships. Composition is specified as a form of aggregation with strong ownership where the lifetime of the “owned” is dependent on the “owner”. The examples in Figure 4.2 provide the UML graphical representation for a one-way association, two-way association, aggregation and composition between classes A and B respectively. In one-way associations, an arrowhead is used to show object B is associated by object A. The solid line without arrow heads indicates a two-way association between two objects. For simplicity, the arrowheads at each end of a two-way association are not included in the diagrams, and instead simply a plain-line is used. Aggregation is represented with a open diamond attached to the aggregating class.  Composition is represented with a solid diamond attached to the “whole”. The composition relationship is not required and is not used in this part of ISO/IEC 18023.

In this part of ISO/IEC 18023, UML aggregation is used to denote the whole to part relationship between object classes. Within object pairs that have an aggregation relationship, aggregating objects are termed aggregates, whereas aggregated objects are termed components as defined in 4.3.2.2 Expression of environmental data and data models with the DRM.

Multiplicity, the number of components allowable in the aggregation, and optional relationships are denoted in UML by providing a lower limit and an upper limit in the form: <lower limit> .. <upper limit>. A one-to-one relationship between two classes would be expressed as “1 .. 1”, at each end of the relationship. In this part of ISO/IEC 18023, the same rule is applied with some minor modifications. The multiplicity of a relationship between a class A and a class B indicates, for a given instance of A, the number of instances of B that may participate in such a relationship with A. For component relationships, if B is a formal component of A, the multiplicity for A in the relationship indicates how many instances of A can share B. Relationships between classes specify the legal possibilities, while relationships between objects shall comply with those possibilities.

The UML generalization relationship, as denoted in, Figure 4.3 is used in this part of ISO/IEC 18023. Here, classes B and C are both a type of class A, and both inherit from class A.

If the multiplicity is exactly one as in Class A in Figure 4.4, the numbering can be removed. Class B is an optional relationship that follows the UML notation. Class C also follows UML notation by using the “*” character to denote “zero or more”. Class D states a minimum per the UML notation. Finally, Class E indicates that a specific ordering exists between object classes.

The last distinction made between the conventional UML notation and its use in this part of ISO/IEC 18023 concerns UML association classes. These classes are referred to as Link Classes in this part of ISO/IEC 18023 and are used within the context of aggregation and association relationships, a deviation from standard UML modeling.

4.5.4 DRM classes

4.5.4.1 Overview

There are hundreds of classes in the DRM. These classes can be grouped into a small number of categories based on whether they describe:

1. the physical shape or form of objects or concepts used for geometric rendering (referred to as the geometry classes);
2. the more abstract representation of the physical objects or the non-physical concepts (referred to as the feature classes);
3. topology, as it pertains to geometry topology or feature topology;
4. attributes of objects or concepts, including physical characteristics such as mass, temperature, and material composition;
5. data organization schemes; or
6. explicit relationships between classes.

The geometry classes include such primitives as points, vertices, lines, arcs, polygons, and volumes. They also include point sample data represented in n-dimensional uniform and non-uniform grids, including finite element meshes.

The feature classes include such primitives as point features, linear features, and areal features.

Both feature and geometry primitives have their own independent topology data classes for describing mathematical and physical connectivity.

Attributes include such items as location, colour, sound, classification, metadata, and extents.

Data organization classes include methods for organizing data by such concepts as time, distance, type or classification, spatial relationships, and state. Libraries can also be thought of as data organization schemes. Libraries allow for storage savings by reuse of shareable items through referencing an instance of an item in a library.

Explicit relationships describe association between various classes.

To isolate the evolution of the DRM from the API (thereby reducing impact on application software development investments), each class in the DRM is not treated as an independent class with its own method. Instead, all classes in the DRM inherit from a single “superclass”.

4.5.4.2 Abstract Classes

All classes in the DRM are either concrete or abstract; that is, either they can or cannot be instantiated as actual objects in a transmittal. Abstract classes cannot be instantiated, and therefore never correspond directly to physical objects or environmental data. Instead, they are used to abstract information that is common to their subclasses, such as relationships with other classes in the DRM or data fields. Abstract classes always have subclasses, which may themselves be abstract or concrete.

Concrete classes, on the other hand, can be instantiated directly, but never have subclasses. Superclasses, therefore, are always abstract.

An example of abstract vs. concrete classes is shown in Figure 4.5:

In Figure 4.5, A is an abstract class with two subclasses, B and C, where B is also an abstract class, but C is a concrete class. Instances of class C may appear in a transmittal, but A and B cannot be instantiated. Since C is a subclass of A, any instance of C is conceptually a member of A as well. Any instance of a concrete class descended from B is also conceptually a member not only of B, but also of A.

In discussing abstract classes and their characteristics, references will be made to instances of the concrete classes that are subclasses (or subclasses of subclasses) of the abstract class. When speaking of these instances, for brevity they may be referred to as “instances” of the abstract class.

4.5.4.3 Aggregation

An aggregation relationship between two classes A and B may be called a ‘has-a’ relationship, because an instance of A is considered to ‘have’ instances of B as components. In terms of relationships between classes, B is called a formal component of A, and A is called a formal aggregate of B. An instance of A is said to have instances of B as components, while an instance of B has one or more instances of A as aggregates. The multiplicity of the formal relationship specifies for an instance of A exactly how many instances of B it can have as components, and for an instance of B how many instances of A may aggregate it.

Both abstract and concrete classes may participate in relationships as either formal aggregates or formal components. If an abstract class A is a formal aggregate of some class C, all subclasses of A are also formal aggregates of C; the relationship is said to be inherited from A. Likewise, if an abstract class X is a formal component of some class Y, all subclasses of X may be substituted for X in the relationship when concrete subclasses are instanced as actual objects.

EXAMPLE Consider a case where an abstract class “member”, is specified to be a component of at least one “club”, and a concrete class, “senior member”, is a subclass of the class “member”.  In this case, an instance of “senior member” is required to be a component of at least one instance of “club”.

4.5.4.4 Associations

In the DRM, the "association" relation is used in the following cases:

1. Unless otherwise stated, "association" depicts the relation of the two objects embodying the alternate representations of an abstract object.
2. If "association" does not directly indicate alternate representation, it depicts topological relationships; in such cases, the DRM object may have an association to an appropriate topological object to indicate that its topology is represented by that object.
3. Within the topological classes themselves, associations are used to indicate several types of relationships that will be discussed in 4.5.12 Topology.

4.5.4.5 Sharing

When the relationship from a component DRM class to an aggregation DRM class has multiplicity greater than one, instances of the component DRM class may be shared by more than one instance of the aggregation DRM class. Consider a class called “polygon” representing a planar surface. A “polygon” instance shall have three or more “vertex” components, each of which may be shared by any number of “polygon” instances. An example using these classes is illustrated below in the instance diagram. Within this diagram there are two objects of class “polygon” labeled Polygon P1 and Polygon P2. There are also five objects of “vertex’ labeled Vertex V1, Vertex V2, Vertex V3, Vertex V4, and Vertex V5. The multiplicity from the “polygon” class to the “vertex” class is three or more, while the multiplicity from the “vertex” class to the “polygon” class is one or more. Thus, in Figure 4.6, the objects Vertex V2 and Vertex V3 are shared by objects Polygon P1 and Polygon P2.

4.5.4.6 Constraints

The syntactic specification of the structure of DRM classes, types, and relationships between classes does not in itself guarantee complete semantic validity in a given transmittal. A quad-tree organization, for example, may be syntactically correct in specifying four quadrants, but semantically invalid if, for example, they are all identified as corresponding to the same quadrant, or if the spatial extents of the quadrants do not partition some region into quadrants. A number of DRM classes require further specification of what is and is not semantically valid use in practice.

The SEDRIS Data Representation Model specifies a set of constraints that distinguish valid and invalid semantic usage in cases where syntactically valid cases may occur that are not semantically valid. These constraints are specified in 6.2 Constraints.

4.5.5 Representational paradigm

SEDRIS concepts, embodied in the DRM, are depicted using UML as specified in 4.5.3 Modelling technique and notation. UML diagrams are used in the DRM classes specified in 6 DRM Classes. All of the DRM, using several UML diagram pages, is specified in Annex A UML Diagrams.

Each DRM class contains the information shown in Table 4.3:

The full set of DRM class specifications may be found in 6.3 DRM class specifications.

4.6 DRM semantics

4.6.1 Overview

4.6.2 Spatial concepts

The science and mathematics for defining spatial reference frames, their valid parameters, their interrelaionship, and their operations is generally complex and detailed. As a result, the DRM does not define SRFs. Rather, it relies on the concepts specified in ISO/IEC 18026 (see 2.[I18026]) to represent location data. Similarly, the SEDRIS API relies on the SRM API to perform conversions and transformation operations on coordinate values.

Through specific classes designated for the representation of location data, the DRM provides the ability to express 2D and 3D coordinate values in any number of valid SRFs specified in the SRM. The DRM also permits the coexistence of different SRFs in a transmittal, as long as rules for environmental object relationships are followed.

SRFs can be applied to DRM classes that represent a region of the environment (<DRM Environment Root>), a standalone model of an object (<DRM Model>), which can be a complete world onto itself, and point-sampled grid of surfaces or volumes (<DRM Property Grid>) among others. The DRM supports the expression of coordinates in 2D and 3D SRFs through the specific set of DRM objects. The fields of these DRM objects can be set to specify valid SRF parameters such as datums, reference object models, offsets, and others.

In addition, the DRM supports the expression of orientation, scale, and translation of environmental objects, as well as permitting the nested instancing of environmental objects within each other.

These concepts along with the specific DRM objects that embody them are further discussed in 4.7 Spatial concepts.

4.6.3 Representing the semantics of environmental objects

The DRM separates what an environmental object, or concept, is from how it can be represented. DRM class instances are used to represent environmental objects. However, an environmental object is not fully classifiable from the DRM classes used to represent it. Instead, the DRM uses EDCS classification codes to identify the environmental object. Similarly, EDCS attribute codes are used to provide specific characteristics of the environmental object. This separation of representation and semantic classification allows DRM classes to be independent of any specific environmental objects or concepts. This part of ISO/IEC 18023 specifies specific DRM classes used to provide the EDCS codes for environmental object semantics as discussed in 4.8 Semantic attribution in the DRM.

4.6.4 Environmental concepts as data tables

A significant portion of environmental data is represented as data located within a grid. Such data represents ocean volume or columns, atmospheric volumes, layers, or columns, space data, surface elevation or surface characteristics data, image data, and point sampling of 3D solid objects. The DRM represents these through the use of <DRM Data Table> and <DRM Property Grid> objects.

A <DRM Data Table> is an n-dimensional array of cells, where each cell may contain one or more data elements. A <DRM Property Grid> is a special version of <DRM Data Table>, where at least one of the axes of the table is based on spatial locations.

The cells of a table may contain as many data elements as needed for the particular data representation needed. However, the “signature” of the table specifies the type of data elements in a given cell, and how those elements should be stored. Cells of a data table may be sparse or full depending on the nature of data being represented. EDCS attributes are used to specify the properties of the elements of each cell.

EDCS classification entries are used to specify the meaning of the entire table. Each axis of a table can be specified independently for its spacing and units. Unlike most other DRM objects, specific API access and manipulation calls exist for handling data tables.

The DRM objects involved in the representation of tabular data are further detailed in 4.9 Data tables.

4.6.5 Environmental concepts as geometry

Certain environmental objects should be represented in a manner as close to their physical appearance as possible. These include the representation of 2D and 3D lines, 2D and 3D solid or point-sampled surfaces, and solid or point-sampled volumes. Often these representations are used in realistic visualization applications. In general, when modeling of an environmental object requires an abstraction that closely resembles its physical appearance and is intended to preserve its geometrical shape, the DRM objects under a branch called geometry are used.

Primitive geometry objects include point, line, surface, and volume geometry. In addition, finite element mesh and property grid representations are also considered geometry objects.

The primitive geometry objects can be organized in a number of ways described in 4.6.10 Organizing principles under Key DRM concepts and in 4.5.13 Organizing principles for details. Collections of primitive objects when organized in this manner are called geometry hierarchy objects. Each <DRM Geometry Hierarchy> object can be associated with one or more other <DRM Geometry Hierarchy> objects, as well as with one or more <DRM Feature> objects. This allows a <DRM Feature> or a <DRM Geometry Hierarchy> object to be represented as an alternate representation of a given <DRM Geometry Hierarchy>. A complete treatment of geometry concepts is provided in 4.10 Geometry.

4.6.6 Environmental concepts as features

In cases where environmental objects are best represented as a higher abstraction of their physical form or when the environmental concept has no realizable physical form, the objects under the DRM branch called features can be used. Such environmental concepts include, but are not limited to, borders between countries, point locations representing an object as a single point, road centerlines, and outlines of buildings, lakes, or regions. Often these representations are used in analysis or 2D map applications. In general, when modeling of an environmental object requires a higher degree of abstraction of that object, the DRM objects under the feature branch are used.

Primitive feature objects include point features, linear features, and areal features. And unlike geometry objects, the representation of location of feature objects is directly through their topology primitives.

The primitive feature objects can be organized in a number of ways described in 4.6.10 Organizing principles under Key DRM concepts and in 4.5.13 Organizing principles for details. Each <DRM Feature>object can be associated with one or more other <DRM Geometry Hierarchy> objects, as well as with one or more <DRM Feature> objects. This allows a <DRM Feature> to be represented as an alternate representation of a <DRM Geometry Hierarchy> object or another <DRM Feature> object. A complete treatment of feature concepts is provided in 4.11 Features.

4.6.7 Distinction between features and geometry representations

The DRM provides the <DRM Feature> versus <DRM Geometry>distinction as a mechanism to provide a fundamental separation for environmental object representations. The distinction between the <DRM Feature> representations and <DRM Geometry>representations is that a <DRM Feature> representation removes all spatial information not required to support spatial connectivity; i.e., it only requires topology. The location data of a feature representation is stored within the topology DRM classes. A <DRM Geometry> representation stores location data within the actual representation of the environmental objects. The <DRM Geometry> representation can then be augmented with topological relationships. Conversely, a <DRM Feature> representation is inherently a topological description.  Furthermore, by making this distinction in the DRM, a specific branching point between two types of representations is provided in the form of a feature representation branch and a geometry representation branch at the second level of a Transmittal structure (i.e., at the <DRM Environment Root>).

A second distinction for feature representation versus geometry representation is data application or data usage. A <DRM Feature> representation is more suited to artificial reasoning applications such as route planning and minimizing route costs as in geographic travel systems. While both types of representation can be used by the same application, they are designed for different purposes. Thus, the <DRM Geometry> representation is better suited for immersive visualizations, while a <DRM Feature> representation is better suited for visualization of abstractions of an environment such as maps.

4.6.8 Representational polymorphism

The association links between <DRM Feature> and <DRM Geometry Hierarchy>, <DRM Feature> and <DRM Property Grid>, as well as the self association of <DRM Feature> to itself and <DRM Geometry Hierarchy> to itself provide a powerful mechanism for the alternate representation of the same environmental object. This polymorphic aspect of the DRM enables it to serve a variety of applications that tend to deal with the same environmental objects but differ in their context or view of that object.

4.6.9 Topology

Topology defines the interrelationships between environmental objects. The DRM supports five topology levels for both features and geometry as described in 4.12 Topology. In addition, the DRM provides mechanisms for capturing stacking information (over and under) without the need for three-dimensional topology. Such information is needed by applications that require knowledge of above and below relationships but whose use of topology information is more limited. Examples of such cases include multi-level road network systems and multi-level buildings.

Topology is inherent in the representation of environmental objects as features. The spatial location of feature-based data within the DRM can only be obtained through the use of the topology relationship. Topology of the feature-based environmental objects is often used by applications that require information about connectivity to determine navigation through an environment or adjacency of environmental objects.

Geometry objects may contain full topology about the connectivity of the defining surfaces and facets. However, such topology is not a required part of geometry object representation.

DRM objects used to support geometry and feature topology representations are described in 4.12 Topology.

4.6.10 Organizing principles

The DRM allows primitive data to be organized in several different ways including by:

1. time,
2. classification,
3. spatial extent or spatial partitioning,
4. level of detail,
5. alternate hierarchy, and
6. separating planes.

The DRM classes that provide organization hierarchies are found in both the geometry and feature branches. Each DRM aggregate object acts as a container , and can themselves contain other aggregate objects.

The feature and geometry branches each have their own independent aggregate objects, with ten aggregate objects for the feature branch and fourteen for the geometry branch. Since a <DRM Aggregate Feature> is a type of <DRM Feature Hierarchy> (which itself is a type of <DRM Feature>), and since a <DRM Aggregate Geometry> is a type of <DRM Geometry Hierarchy>, all association relationships that apply to polymorphic representation of <DRM Feature> and <DRM Geometry Hierarchy> also apply to all types of aggregate objects. Aggregate objects not only organize data as needed, they can also associate to other aggregate (and primitive) environmental data at any level of the instanced hierarchy.

A complete treatment of DRM objects used as organizing principles is provided in 4.13 Organizing principles.

4.6.11 Libraries

Libraries fill a special role by allowing a single copy of an object to be referenced or reused one or more times from within the <DRM Environment Root>. The following kinds of libraries are supported by the DRM:

1. 3D models,
2. images,
3. sounds,
4. map symbols,
5. data tables,
6. colour tables, and
7. property sets.

Libraries, as a construct for sharing data, are provided in 4.14.3 Libraries.

4.6.12 Models and model instancing

Models in a <DRM Model Library> can be placed in the environment and can be given local attributes that make them appear as if they are unique. This capability in the DRM allows data modelers and data producers to reuse the same <DRM Model> numerous times by providing a pointer (captured in <DRM Feature Model Instance> and <DRM Geometry Model Instance> classes) from the environment they are modeling to the specific <DRM Model> in the <DRM Model Library>.

A <DRM Model> can be composed of two branches, one called feature model, the other geometry model. This allows a <DRM Model> to act analogous to the <DRM Environment Root>, where a feature and geometry branch is provided. A <DRM Model> can instance other <DRM Model>s. This capability can be used to build very complex worlds and reuse them in a broader context. For example, a representation of a solar system may include a region of space within the <DRM Environment Root>, where each celestial object can be instanced by pointing to a <DRM Model> in the <DRM Model Library>. Each such model (celestial body) can in turn point to other <DRM Model>s in order to provide a richer and more complex planetary object.

Alternatively, a <DRM Model> can be a simple model of a single object (for example, a park bench, a door knob, a tree.) and can be reused within the environment. Each local use within the environment can provide variations to the base model by assigning an orientation or scale, as well as overriding attributes of the base model. Sharing, instancing, and applying transformation to a model is discussed in 4.14.2 Models.

4.6.13 Metadata

The DRM allows for inclusion of metadata that is intended for use by humans as well as metadata that is used for automated processing and parsing of transmittals. The metadata associated with such concepts as citation, data quality, and points of contact is based on the precepts specified in ISO 19115 (see 2.[I19115]).

Metadata can be associated with most DRM objects, including organization objects such as aggregates, primitive data, data tables, and libraries.

The metadata associated with the contents of a transmittal, such as transmittal summary, included structures, use of EDCS, DRM classes used, and a summary of primitives and hierarchies used, is also allowed in the DRM to allow automated machine-parsing of transmittals, if such metadata is present.

A detailed description of all metadata objects used in the DRM is provided in 4.17 Metadata.

4.6.14 Other concepts

In addition to the DRM concepts described here, there exist a number of other important DRM concepts. These concepts are generally a detailed specialization of topics discussed here indirectly, such as transmittal structure, discussed in 4.18 Transmittal structure, and constructs for sharing data discussed in 4.14 Constructs for sharing data. Others are unique to specific application domains, such as animation, control links, visualization parameters for lighting,, as discussed in 4.15 Constructs for presenting data and 4.16 Constructs for controlling dynamic data.

4.7 Spatial concepts

4.7.1 Overview

Primitives used for expressing location data, and the DRM objects that require location data are described below. To provide a basis for understanding spatial concepts of the DRM, the concepts of the SRM are related to concepts of the DRM.

4.7.2 SRFs

A spatial reference frame, or SRF, is a concept specified in ISO/IEC 18026 — Spatial Reference Model (SRM) (see 2.[I18026]). Briefly, in the SRM, and thus in the DRM, a coordinate is an ordered pair or ordered triple of real numbers designating the position of a point, and is specified in some coordinate system. A coordinate system is a set of rules by which a coordinate can spatially relate a location to a unique origin and associated axes. A spatial reference frame ties a coordinate system’s origin to some Object Reference Model. A coordinate is always specified in the context of some spatial reference frame to avoid ambiguity. A spatial reference frame in the DRM is specified by an instance of a DRM class that has an srf_parameters field, where the field specifies SRF parameters information as specified by the SRM.

Coordinates are specified in the DRM as instances of <DRM Location> (see 4.7.3 Location) or as coordinates within gridded data in the scope of a <DRM Property Grid> instance. In the DRM, a coordinate appears only within an object subtree (that is, a tree of aggregate/component relationships) rooted at an instance of some DRM class that specifies a spatial reference frame via an srf_parameters field. Further, the coordinate shall be specified so that it is specified within that spatial reference frame.

Classes that specify srf_parameters include:

1. <DRM Environment Root>
,
2. <DRM Property Grid>,
3. <DRM Model>,
4. <DRM Image Anchor>,
5. <DRM Reference Origin>, and
6. <DRM SRF Summary>.

Each such class specifies its spatial reference frame by means of an srf_parameters field, specified using the structured data type SRF_Parameters as specified in ISO/IEC 18026 — Spatial Reference Model (SRM) (see 2.[I18026]).

4.7.3 Location

<DRM Location> has two subclasses, both of which are abstract: <DRM Location 2D> and <DRM Location 3D>. These correspond to the SRM concepts of a Coordinate_2D and a Coordinate_3D. The subclasses of <DRM Location 2D>, in turn, correspond to the 2D SRFs specified by the SRM, and the subclasses of <DRM Location 3D> correspond to the 3D SRFs so specified.

An instance of a concrete subclass of <DRM Location 3D> shall appear only within the context of a compatible set of SRF parameters. For example, a <DRM SM Location 3D> shall appear only within the scope of an object that specifies SRF_Parameters specified for a three-dimensional solar magnetic (SM) spatial reference frame. A <DRM Location 3D> shall never appear in the scope of an object that specifies 2D parameters.

A <DRM Location 2D> shall appear only within the context of a compatible set of SRF parameters. In the case of 2D, a <DRM Location 2D> can be completely specified within the context of an object that requires 3D parameters. As long as the respective SRFs are compatible, a <DRM Location 2D> instance may appear in a 3D context. A reference surface defines the surface from which vertical values are computed for <DRM Location 2D> instances found in a transmittal. For example, a <DRM EC Location 2D> may appear within the context of an AEC spatial reference frame.

In the cases where this occurs, the <DRM Location 2D> is a conformal point; that is, it represents a location in 3D space where the location lies on the reference surface for that SRF. A reference surface is a surface specified to provide the vertical resolution of <DRM Location 2D> instances found in a transmittal. For example, consider a representation H of a house containing some representation W of an exterior wall. The data provider wishes the locations specifying the base of W to lie on the representation of the terrain surface wherever H is instanced, and chooses to use <DRM Location 2D> , will conform to terrain surface rather than specifying the exact vertical values for those locations. To conform the <DRM Location 2D> instances to a terrain surface, the <DRM Reference Surface> shall associate to a <DRM Geometry Hierarchy> that captures the terrain surface. A 2D coordinate is considered to lie on the object reference surface used to specify the spatial reference frame in which the 2D coordinate is specified. In the DRM, this may be further refined through the use of <DRM Reference Surface>.

4.7.4 Orientation

Orientation information is represented in the DRM by two mechanisms: <DRM Reference Vector> and <DRM World Transformation>. The former is covered below; the latter, in 4.7.5 Mapping from the model SRF to the environment SRF.

A <DRM Reference Vector> specifies an SRM Vector_3D, together with a vector_type field supplying the semantic meaning of the SRM Vector_3D. For a given <DRM Reference Vector> instance, the semantic meaning specified by the vector_type field may be further qualified by a <DRM Property Value> instance supplied as a component of the <DRM Reference Vector> (see 4.5.5 Semantic Attribution in the DRM for further information). The Vector_3D specified by a <DRM Reference Vector> instance shall always be a unit_vector.

A <DRM Reference Vector> instance always has a <DRM Location> component, which is either a component of the <DRM Reference Vector> instance, or is supplied by the context of the <DRM Reference Vector>, subject to the 6.2.50 Required Reference Vector Location constraint.

One important characteristic of a spatial reference frame is how vector operations behave in a space described by that spatial reference frame. In particular, a space in which  vectors are well-behaved is said to have a vector space structure. The space is closed under vector addition and scalar multiplication, meaning that any two vectors in the space that are mathematically combined using those operations will result in a vector that is also in the same space. If a space has a vector space structure, the mathematics of describing physical phenomena such as light or motion by means of vectors is straightforward.

The SRM, and consequently the DRM, supports several spatial reference frames that do not have a vector space structure. Without additional information, the unit_vector of a <DRM Reference Vector> would not be meaningful in such spatial reference frames since the standard dot product of two vectors is not the correct inner product for such non-vector spaces. Consequently, for each spatial reference frame supported by the SRM that lacks a vector space structure, a Local Tangent Plane vector space appropriate for each <DRM Reference Vector> instance is embedded in the spatial reference frame, and it is this Local Tangent Plane vector space that is used to specify unit_vector information.

The spatial reference frames supported by the SRM that lack vector space structure fall into two categories: those for which the Object Reference Model (ORM) is an oblate spheroid or a sphere, and those for which this is not the case.

For a spatial reference frame having an ORM that is an oblate spheroid or a sphere, the canonical LTP space at a point is specified as follows. Given a point location in the spatial reference frame under consideration, the canonical LTP space at the point is the Local Tangent Plane space tangent to the ORM at the surface location that shares the same ray from the centre of the ORM as the given point, where the Local Tangent Plane's spatial reference parameters x_offset = y_offset = azimuth = 0.0. In such a spatial reference frame, the unit_vector of a <DRM Reference Vector> instance is interpreted as a vector in the canonical LTP space specified at the position specified by the <DRM Location> component of the <DRM Reference Vector>.

For a spatial reference frame having an ORM that is not an oblate spheroid or a sphere, vectors are interpreted in the corresponding celestiocentric spatial reference frame.

4.7.5 Mapping from the model SRF to the environment SRF

Coordinate information shall always be specified in a compatible spatial reference frame. There are cases when it is desirable to specify a generic representation of some entity in a Local Space Rectangular (LSR) SRF and then reference the generic representation in another SRF.

An instance of <DRM World Transformation> is used to specify a transformation from a source context to a target context, where the source context is a <DRM Model>, always specified within an LSR SRF (either 2D or 3D) and the target context may be specified within any SRF.

4.7.6 Spatial extents

A <DRM Spatial Extent> instance specifies a bounding rectangle (if 2D) or a parallelepiped (if 3D) within which the DRM objects representing environmental data are contained. This includes rectangles with area zero and parallelepipeds with volume zero.

A <DRM Spatial Extent> instance has two ordered <DRM Location> components, specified in the SRF in which the <DRM Spatial Extent> has been specified. The ordering of these components is semantically significant because the first <DRM Location> specifies the minimum coordinate values of the spatial domain, while the second specifies the maximum coordinate values. Conceptually, these <DRM Location> instances can be considered as the “lower left” and “upper right” corners of a bounding box within which all coordinates in the corresponding tree of component relationships are located. Any data that extends beyond the boundaries of the spatial extent is considered invalid.

Note that in the case of an SRF such as Geodetic, the coordinate values of the second <DRM Location> may be either greater than or less than those of the first <DRM Location>, depending on the particular region for which spatial domain information is being specified.

4.7.7 Perimeters

An instance of <DRM Perimeter Data> specifies the perimeter of the region corresponding to the object of which it is a component. In the case of <DRM Aggregate Feature> or <DRM Aggregate Geometry>, the aggregate represents some aspect or aspects of the region in question. In the case of <DRM Sound Instance>, the meaning is more specialized (see 4.5.15.6 Sound for details). <DRM Perimeter Data> instances also occur as link objects in a perimeter-related organization (see 4.5.13.7 Perimeter for details of its usage). The semantics of how a <DRM Perimeter Data> specifies the perimeter of the given region are the same in all these use cases.

The N ordered <DRM Location> components of a <DRM Perimeter Data> instance specify the perimeter of the given region by specifying an implicit line segment between each pair of <DRM Location> components i, i+1 for i in the range 1, …, n-1, where the components are numbered starting at 1. There is a last implicit line segment connecting the n^th <DRM Location> with the first <DRM Location> component so that the <DRM Perimeter Data> specifies a connected boundary. <DRM Perimeter Data> is constrained (see 6.2.38 Non-selfoverlapping perimeter data locations for details) so that the boundary thus specified does not overlap with itself.

4.7.8 Volumes

The <DRM Volume> class is used to specify instances of volumes in space. Other classes that represent volumetric information include <DRM Volume Level Of Detail Data> and <DRM Volume Light Behaviour>. Location and shape data for these classes are specified as for <DRM Volume> which is described below.

A <DRM Volume> is centred at a <DRM Location 3D>, which is specified as a component of the <DRM Volume>. The shape of the volume is specified by a separate component, an instance of one of the concrete subclasses of <DRM Volume Extent>. This design permits a common volume shape to be specified once and reused at many different locations to specify different volumes.

<DRM Volume Extent> has three concrete subclasses: <DRM Cylindrical Volume Extent>, <DRM Parallelepiped Volume Extent>, and <DRM Spherical Volume Extent>. <DRM Cylindrical Volume Extent> specifies its major and minor axes as <DRM Reference Vector> components, while the axis lengths and cylinder height are specified by the fields of the <DRM Cylindrical Volume Extent> itself. <DRM Parallelepiped Volume Extent> specifies three ordered <DRM Reference Vector> components as the axes of the parallelepiped, the lengths of which are specified as field values within <DRM Parallelepiped Volume Extent>. Finally, <DRM Spherical Volume Extent> specifies the radius of the sphere in question.

The use of <DRM Reference Vector> instances permits these volume constructs to be subjected to coordinate conversion and transformation without distortion of the volume shapes.

4.8 Semantic attribution in the DRM

4.8.1 Use of EDCS attributes

4.8.1.1 Overview

The DRM uses EDCS Attribute Codes (EACs) to specify the semantic meaning of some related set of data values where the data type of that set is as defined in ISO/IEC 18025 — Environmental data coding specification (EDCS) (see 2.[I18025]).

An EAC may be specified in the following contexts in the DRM:

1. as the state_tag of a <DRM State Related Features> or <DRM State Related Geometry> instance (see 4.13.11 State),
2. as the axis_type of a <DRM Axis> instance (see 4.9.5 Axis),
3. as the meaning of a <DRM Variable> instance (see 4.16.2.2 The <DRM Literal> and <DRM Variable> classes), and
4. as the meaning of a <DRM Property> instance.

In the <DRM Property> case, the semantic meaning is specified by an Element_Type value, a data structure that is specified to contain an EDCS_Attribute_Code, an Index_Code, or a Variable_Code; EACs are the most common case. The Index_Code and Variable_Code data types support semantic meanings of attributes that are too specific to the DRM to obtain entry in the EDCS Attribute dictionary, but are conceptually the same as EDCS Attribute Codes in application, with the addition that they are constrained regarding the contexts in which they can be used that will convey semantically valid information. For example, the Index_Code value DATA_TABLE_COMPONENT is constrained by6.2.21 Index codes within tables to appear only within the context of a <DRM Data Table> with appropriate characteristics. Except for the special cases covered by Index_Code and Variable_Code, the information represented by Element_Type constructs consists of EACs.

4.8.1.2 <DRM Property>

4.8.1.2.1 Overview

For an instance of a concrete subclass of <DRM Property>, the EDCS classification is specified by an Element_Type value, and specifies the semantic meaning of the set of data values bound to that <DRM Property>. Any subclass of <DRM Property> may represent numeric data, so <DRM Property> has EDCS Unit and EDCS Scale fields with appropriate constraints (see 6.2.45 Property meaning constraints). The set of data values bound to a given instance of <DRM Property> depends upon the concrete subclass involved.

<DRM Property> has three concrete subclasses each of which serves a somewhat different purpose and provides different functionality: <DRM Property Value>, <DRM Table Property Description>, and <DRM Property Description>. The common characteristics abstracted by <DRM Property> are discussed above with the exception of its relationship with <DRM Property Characteristic>.

4.8.1.2.2 <DRM Property Characteristic>

A <DRM Property Characteristic> instance specifies details about the representation of a property, such as maximum value, minimum value, measurement error, and (in the case of multiple value sets) sentinel values.

A <DRM Property Characteristic> instance appears only as a component of some <DRM Property> instance (or instances). It specifies a value and a semantic meaning for that value, where the semantic meaning is represented by an EDCS Value Characteristic Code, such as TOLERANCE. See 6.2.44 Property_Characteristic constraints for semantic constraints ensuring that <DRM Property Characteristic> information is meaningful within the context of a <DRM Property>.

4.8.1.2.3 <DRM Property Value>

A <DRM Property Value> instance specifies a single data value, the meaning of which is specified by its meaning field. This data value is specified by its value field, which also specifies the data type of the value.

4.8.1.2.4 <DRM Table Property Description>

A <DRM Table Property Description> is always a component of a <DRM Data Table>, and specifies the semantic meaning of the corresponding set of elements within the cells of the <DRM Data Table>. The <DRM Table Property Description> also specifies the data type of the data, but the data itself is contained by the cells of the <DRM Data Table>. (See 4.5.6 Data tables for further details.)

4.8.1.2.5 <DRM Property Description>

Within the scope of a <DRM Aggregate Feature> or <DRM Aggregate Geometry>, many <DRM Property Value> instances may appear that specify values of the same property for different locations, but subject to a common set of constraints, such as a common measurement error, or (collectively) minimum or maximum value.

This information can be provided with the class <DRM Property Description>, which serves to provide context for all <DRM Property Value> instances within the scope of a <DRM Aggregate Feature> or <DRM Aggregate Geometry> of which the <DRM Property Description> is a component, such that the <DRM Property Value> meaning values match that of the <DRM Property Description>.

For example, consider a <DRM Property Description> specifying a meaning of WIND_SPEED and a <DRM Property Characteristic> specifying a TOLERANCE value. The information being provided is that <DRM Property Value> instances falling within the scope of that <DRM Property Description> and having the same meaning of WIND_SPEED also have the given TOLERANCE value.

In addition, <DRM Property Description> may have qualifying <DRM Property Value> components, which then apply to all <DRM Property Value> instances within that scope that have matching meaning field values. For example, in a <DRM Aggregate Geometry> containing many <DRM Polygon> instances that specify different EMISSIVITY values, the aggregate can contain a single <DRM Property Description> component specifying the EM_BAND.

4.8.2 Use of EDCS classifications

4.8.2.1 Overview

The DRM uses EDCS Classification Codes to specify the semantic meaning assigned to a collection of DRM objects within the environment; that is, to classify those DRM objects.

An EDCS Classification Code (ECC) may be specified in the following contexts in the DRM:

1. as the tag of a <DRM Classification Data> instance;
2. as the environmental_domain of a <DRM Environmental Domain Summary> instance;
3. as the classification of a <DRM Reference Surface>;

4. as the component_data_table_ecc of a <DRM Table Property Description>; and
5. as part of the texel data of a <DRM Image>, depending on the image_signature.

For <DRM Classification Data>, <DRM Environmental Domain Summary>, and <DRM Reference Surface>, the ECC specified is subject to qualification by <DRM Property Value> components, as discussed in 4.5.5.2.2 Qualification.

The details of the specific interpretation of an ECC depend on the context in which it appears. In the case of <DRM Classification Data>, the tag field specifies the semantic meaning of the object to which the <DRM Classification Data> is being applied, as specified in 6 DRM classes. This is the most common usage of ECCs, but there are classes that use ECCs for summary or identification purposes rather than to specify the semantic meaning of instances of the classes in which the ECCs are specified.

An <DRM Environmental Domain Summary> instance is used to specify a particular environmental domain that is being represented in the given transmittal. In a <DRM Reference Surface>, the classification field (subject to qualification) specifies that only resolution surface geometry matching the given classification is truly part of the resolution surface. The component_data_table_ecc of a <DRM Table Property Description> is used to identify a specific <DRM Data Table> being referenced, rather than classifying the <DRM Table Property Description> itself.

The final case is that of the texel data of a <DRM Image>, where the image_signature is EDCS_CLASSIFICATION_CODE. In this type of <DRM Image>, each texel is an ECC, so that the <DRM Image>, when mapped to a specific spatial region, can indicate the classification of various environmental entities in that region.

4.8.2.2 Qualification

A <DRM Classification Data> instance specifies the semantic meaning of the object to which the <DRM Classification Data> is being applied. This semantic meaning may be further qualified by the presence of <DRM Property Value> components of the <DRM Classification Data> instance that, if present, supply more specific information regarding the semantic meaning being specified. For example, a <DRM Classification Data> may specify that the object being classified is a BRIDGE, and may have a <DRM Property Value> component further specifying that the BRIDGE_DESIGN is SUSPENSION. A classification with related attributes is termed a qualified classification.

4.9 Data tables

4.9.1 Overview

The abstract <DRM Data Table> class specifies an n-dimensional array of data cells. The dimension n is determined by the number of ordered <DRM Axis> objects aggregated as components by a given <DRM Data Table>. Each <DRM Axis> component determines the number cell ranks in its coordinate dimension. Consequently, a <DRM Data Table> with two axes of size m and n will have m×n cells. A <DRM Data Table> also aggregates an ordered list of <DRM Table Property Description> components. This list constitutes the signature of the table. Each cell contains as many properties as there are <DRM Table Property Description> components in the signature. These <DRM Table Property Description> components describe each property: its meaning, the units of measure, and a value of data type Property_Data_Value. However, the dimensions and signature do not fully describe the intended meaning of the <DRM Data Table>. For that, a <DRM Classification Data> instance is provided as a component of each <DRM Data Table> instance.

4.9.2 Property grids

The <DRM Data Table> class specifies an array of data cells. In general, these cells have no meaningful location in space. If the cells do correspond to gridded locations in space, some of the axes shall be spatial. The <DRM Property Grid> class is used for <DRM Data Table> instances that include at least one spatial <DRM Axis>. Therefore, <DRM Property Grid> instances cna be used to represent point-sampled lines, surface, or volumes. As a result, a <DRM Property Grid> instance used with a <DRM Property Grid Hook Point> instance is considered a geometry representation.

The <DRM Property Grid> class requires that the following shall be specified:

1. the spatial reference frame that preserves the “griddedness” of the cells,
2. the orientation and location of one cell in space, and
3. which <DRM Axis> components are the spatial axes.

The coordinate data is specified by the intersections of the gridlines specified by its <DRM Axis> components, specifically those <DRM Axis> components that specify spatial information.

In an analog to a <DRM Geometry Model> instance, which is referenced at a spatial location using a <DRM Geometry Model Instance> that provides a <DRM Transformation>, the DRM provides the <DRM Property Grid Hook Point> class, a subclass of <DRM Geometry Hierarchy>, to tie a <DRM Property Grid> instance to a spatial location within the geometric context in which it is to be referenced. A <DRM Property Grid Hook Point> instance specifies the spatial location as a <DRM Location> component, while a <DRM Property Grid> instance specifies which of its cells corresponds to that location. A <DRM Property Grid> instance specifies its own SRF. This may or may not match the SRF in which the <DRM Property Grid> is instanced. The spatial_axes_count shall correspond to the <DRM Property Grid>'s own SRF, rather than that of whatever context instances the <DRM Property Grid>. The spatial_axes_count field specifies which of the ordered <DRM Axis> components of a given <DRM Property Grid> are spatial, in accordance with the 6.2.4 Axis Type Constraints constraint.

EXAMPLE If a <DRM Property Grid> specifies its srf_parameters as Augmented Mercator (AM), there can be no more than one “x” axis, “y” axis, or “z” axis.

The cell corresponding to the <DRM Location> of a <DRM Property Grid Hook Point> has indices on the three or fewer spatial axes specified by the location_index field. Note that location_index is not required to specify a point that actually lies within the boundaries of the grid. This allows several neighbouring <DRM Property Grid> instances to be offset from the same <DRM Property Grid Hook Point>, if desired.

4.9.3 Property tables

The <DRM Property Table> class is used to store tabular data that is not spatially aligned. A <DRM Property Table> may aggregate other <DRM Property Table> instances as ordered components, which are then referenced in the cells of the table by an index into the list of components. <DRM Property Grid> instances cannot be referenced in this way by a <DRM Property Table>, because the <DRM Property Table> provides no spatial location to tie the location_index of the <DRM Property Grid> to the instancing spatial reference frame.

4.9.4 Table property descriptions

4.9.4.1 Overview

Attributed data is used throughout the DRM. To fully specify a data value, its meaning and data type are required. If the data type is a numeric, a scaled unit of measure is also required. The data signature of a <DRM Data Table> cell needs this information for each data item.

<DRM Table Property Description> represents a signature item in a <DRM Data Table>. Since the values are stored in the cells of a <DRM Data Table> instance, <DRM Data Table> does not have a value field. On the other hand, all the cells corresponding to a given <DRM Table Property Description> have the same data type, so a given signature item is specified once in the fields of the <DRM Table Property Description>. Consequently, <DRM Table Property Description> has a value_type field, in addition to the fields inherited from <DRM Property>.

A <DRM Data Table> cell may reference other <DRM Data Table> instances, if they are components of the referencing <DRM Data Table> instance or if they reside in a <DRM Data Table Library>. An instance of <DRM Data Table> that is used as a component of another instance of <DRM Data Table> is termed a component data table. To reference another table in this manner, the meaning field of the applicable <DRM Table Property Description> in the referencing table is set to the appropriate Index_Code while each of the referencing table's cells for that signature item contains an index number. Consider a reference to the k^th ordered component <DRM Data Table>. The meaning of the <DRM Table Property Description> is { INDEX, { DATA_TABLE_COMPONENT } }, while the referencing cell contains the appropriate index value. Other Index_Code meanings are handled in a similar fashion.

If the DRM allowed only one signature item in any given <DRM Data Table> instance to reference a component or library table, the index value would simply be the index of the table within the specified list. An instance of <DRM Table Property Description> contains the field component_data_table_ecc that describes the meaning of the component data table and an optional ordered list of <DRM Property Value> components that further specify the characteristics of the component data table. These <DRM Property Value> components qualify the component_data_table_ecc when they are specified. Thus, the j^th component data table instance that matches the given ECC can be referenced.

4.9.4.2 Qualification

As a <DRM Table Property Description> represents a signature item in a <DRM Data Table>, the signature may be further qualified by the presence of <DRM Property Value> components of the <DRM Table Property Description> instance, which, if present, supply more specific information regarding the specific signature.

EXAMPLE A <DRM Table Property Description> instance may specify a signature item corresponding to the EDCS Attribute (EA) HIGH_CLOUD_TOP_LEVEL (see 2.[I18025]). This EA requires a reference to a vertical reference as given by the related EA ATM_VERTICAL_REFERENCE. By associating a <DRM Property Value> instance containing the enumerated value of the appropriate ATM_VERTICAL_REFERENCE, the HIGH_CLOUD_TOP_LEVEL is fully specified.

4.9.5 Axis

4.9.5.1 Overview

The <DRM Axis> class abstracts the common characteristics of its concrete subclasses. Each <DRM Axis> instance specifies:

1. the semantic meaning of its tick marks (the axis_type);
2. a scaled unit of measure (the axis_unit and axis_scale) for numeric axes; and
3. a count for the number of tick marks on the axis (the axis_value_count).

The <DRM Axis> class has four concrete subclasses:

1. <DRM Regular Axis>,
2. <DRM Irregular Axis>,
3. <DRM Enumeration Axis>, and
4. <DRM Interval Axis>.

For an instance of a concrete subclass of <DRM Axis>, the axis_type is specified by an Element_Type value, and specifies the semantic meaning of the tick marks for that axis. In the case of <DRM Regular Axis>, this applies to the first_value and spacing fields; in the other subclasses, it applies to an explicit array of axis values. The <DRM Axis> classes that represent numeric data have EDCS Unit and EDCS Scale fields so that the values’ meaning is unambiguous, and the values are constrained to be consistent with the axis_type (see 6.2.4 Axis type constraints for details).

Each of the four concrete subclasses is discussed in more detail below.

4.9.5.2 Regular Axes

The <DRM Regular Axis> class is used to specify numerical axes that have a constant spacing between the axis values, which are called tick marks. To specify these regularly spaced values, a <DRM Regular Axis> specifies the starting value (its first_value field), the type of spacing being used (spacing_type), and the spacing itself (spacing).

The notion of equal spacing applies to both arithmetic and geometric spacing. If ARITHMETIC is specified, the k^th tick mark value is:

tick(k) = first_value + (k × spacing)

while, if GEOMETRIC is specified, the k^th tick mark value is:

tick(k) = first_value × (spacing^k)

When a <DRM Regular Axis> is used to represent a continuous value, interpolation could be required. As a result, the preferred interpolation method is provided by the interpolation_type field entry of the <DRM Regular Axis> class. The interpolation methods are specified in 5.2.5.26 Interpolation_Type. If there is no preferred interpolation method, interpolation_type shall be NOT_SUPPLIED. Data not requiring interpolation shall set interpolation_type to DISALLOWED. Spatial axes are not permitted to disallow interpolation although a data provider may indicate that a preferred interpolation method is not supplied.

When a <DRM Regular Axis> instance represents a spatial axis as a component of a <DRM Property Grid>, the values of the axis are relative to the <DRM Location> components of the <DRM Property Grid Hook Point>. The <DRM Property Grid> aggregate of the <DRM Regular Axis> instance specifies which tick mark in the axis will correspond to the <DRM Location>  component of the <DRM Property Grid Hook Point>. This is done with the location_index field of the <DRM Property Grid>.

4.9.5.3 Irregular axes

The essential difference between <DRM Regular Axis> and <DRM Irregular Axis> is that the former uses regular spacing to specify its tick marks and the latter does not. The tick marks of a <DRM Irregular Axis> are specified explicitly in the axis_value_array field. The number of values in the axis_value_array field is specified by the axis_value_count field, which also indicates how many tick marks are represented along the axis. Further constraints on the contents of the axis_value_array can be found in 6.2.4 Axis type constraints.

The interpolation_type field specifes the interpolation method as described for regular axes.

If a <DRM Irregular Axis> instance is used as a spatial <DRM Axis> within a <DRM Property Grid>, the values within axis_value_array are all offsets from the location corresponding to the location_index of the grid. That is, if the axis is the i^th spatial axis of a grid, and v is the corresponding coordinate value of the location cell, the k^th tick coordinate value is:

v + axis_value_array[k]

where k ranges from zero to axis_value_count-1.

In particular, there is no offset at the location cell tick

>axis_value_array[location_index[i]] = 0.0

Because there are only axis_value_count-1 intervals determined by this array, there is no “last” interval. In particular, the non-existent last interval has neither middle nor upper point, so axis alignment for a <DRM Irregular Axis> is always LOWER.

4.9.5.4 Enumeration axis

A <DRM Enumeration Axis> instance is constrained to specify an axis_type corresponding to an EDCS Attribute Code (EAC) that is bound to a set of EECs, from which its tick marks are supplied as its axis_value_array.

4.9.5.5 Interval axis

<DRM Interval Axis> specifies an axis whereby the axis values corresponding to the tick marks are specified as ranges. The axis_interval_value_array will contain axis_value_count entries where all entries are provided as signed or unsigned integers or as floating point numbers.  The interval entries shall not overlap and shall be provided in ascending order within axis_interval_value_array.

4.10 Geometry

4.10.1 Overview

<DRM Geometry> is an abstract DRM class for which an ‘instance’ of the class (that is, an instance of one of the concrete classes descended from <DRM Geometry>) represents an entity in the environment, or an organized collection of such entities, in a manner intended to approximate the physical extent and characteristics of that entity so that it can be presented in terms of a given sensor domain in a realistic manner. Often, but not always, this is in terms of visual representation.

<DRM Geometry> includes, but is not limited to, the concepts of point geometry, linear geometry, planar geometry, surface geometry, and volume geometry. For example, <DRM Geometry> also includes the concept of <DRM Property Grid Hook Point> instances used to reference tables, wherein various properties of an entity have been systematically sampled.

4.10.2 Geometry hierarchy

4.10.2.1 Overview

A <DRM Geometry Hierarchy> is a hierarchically organized collection of <DRM Geometry> instances. <DRM Geometry Hierarchy> is abstract, and has three subclasses: <DRM Geometry Model Instance>, <DRM Aggregate Geometry>, and <DRM Property Grid Hook Point>.

<DRM Geometry Model Instance> provides a mechanism for referencing the <DRM Geometry Model> of a <DRM Model>. <DRM Geometry Model Instance> is covered in 4.14.2.2 Instancing.

<DRM Aggregate Geometry> and <DRM Property Grid Hook Point> are described below.

4.10.2.2 Aggregate geometry

A <DRM Aggregate Geometry> specifies a collection of <DRM Primitive Geometry> or <DRM Geometry Hierarchy> instances, organized according to some organizing principle specific to the particular subclass of <DRM Aggregate Geometry> being considered. Each of the concrete subclasses of <DRM Aggregate Geometry> is covered under the corresponding organizing principle.

4.10.2.3 Property grid hook points

A <DRM Property Grid Hook Point> instance specifies the connection between one or more <DRM Property Grid> instances’ spatial reference frames and that of the <DRM Property Grid Hook Point> itself, where the <DRM Property Grid> instances are components of the <DRM Property Grid Hook Point>.

Consider a <DRM Property Grid> instance G as shown in Figure 4.7. This instance specifies N spatial <DRM Axis> components, where N is the value of the spatial_axes_count field of G and is between 1 and 3 inclusive. G also has a location_index field specifying an intersection in grid space of the spatial <DRM Axis> data; that is, specifying a position in the SRF of G.

When G is referenced as a component of a <DRM Property Grid Hook Point> instance H, H specifies a <DRM Location> L in the SRF in which H is specified. The semantic relationship is that L corresponds to the position in G’s SRF specified by G’s location_index information.

4.10.3 Primitive geometry

4.10.3.1 Overview

The <DRM Primitive Geometry> class specifies the smallest data elements that can be used to represent environmental objects. The <DRM Primitive Geometry> class is an abstract class with five subclasses.  All instances of these subclasses are aggregated by an instance of the <DRM Union Of Primitive Geometry> class. The five subclasses of <DRM Primitive Geometry> specify geometry in the form of points, lines, surfaces, volumes, and finite element meshes.

While individual <DRM Primitive Geometry> instances may represent a single renderable object, multiple instances are typically needed (e.g., when property data is associated with a set of primitives rather than each primitive individually). In this case, the set of related <DRM Primitive Geometry> are aggregated in a <DRM Union Of Primitive Geometry>. This allows the property data to be associated with the <DRM Union Of Primitive Geometry> instance and apply to all <DRM Primitive Geometry> instances in the container.

4.10.3.2 Point

A <DRM Point> instance can specify a <DRM Location> with various geometric rendering characteristics or a <DRM Location> at which specific attributes apply. A <DRM Point> instance may be associated with an optional <DRM Light Rendering Properties> instance, in which case it is said to represent a light point. A <DRM Point> may be used to represent the appearance of any environmental entity that is so small from the viewpoint of an observer that it may be considered as a point.

4.10.3.3 Linear geometry

4.10.3.3.1 Overview

A <DRM Linear Geometry> instance specifies a linear geometric representation. Such an instance may be optionally associated with a <DRM Light Rendering Properties> instance.

The count field of a <DRM Linear Geometry> instance does not refer to the number of <DRM Vertex> or <DRM Location> instances specifying the geometry. Instead, count indicates how the <DRM Linear Geometry> is to be rendered. A count field value of zero for a given <DRM Linear Geometry> instance L indicates that L is to be rendered as solid, and the suppress_last field does not apply. If, however, count is greater than zero, the interpretation of count depends on whether L has a <DRM Light Rendering Properties> component. If a <DRM Light Rendering Properties> component is present, count is the number of evenly spaced light points to be rendered along L. Otherwise, count is the number of evenly spaced line segments to be rendered along L. In either of these two cases, suppress_last indicates whether the last light point/segment in the sequence is to be suppressed or rendered.

If desired, a <DRM Linear Geometry> instance may be provided with an association to a <DRM Geometry Edge> instance to indicate its geometric topology, but this is not required.

4.10.3.3.2 Lines

A <DRM Line> is an ordered list of two or more <DRM Vertex> instances specifying a sequence of connected line segments. As an example, consider a <DRM Line> instance representing the outline of a rectangular runway. The <DRM Line> instance aggregates five <DRM Vertex> instances with ordered pairs of <DRM Vertex> instances representing the end points of the four line segments representing the runway outline.

4.10.3.3.3 Arcs

A <DRM Arc> instance is circular arc with the center at the component <DRM Location> and with end points specified by the <DRM Vertex> components.  The arc segment is from the first <DRM Vertex> component until it intersects the radial line that passes through the second <DRM Vertex> component.

EXAMPLE  consider a <DRM Arc> instance L representing an arc of lights on one side of a helipad. In this particular example, L has two <DRM Vertex> components, a count value of 30, and suppress_last has value FALSE. The <DRM Vertex> instances specify the endpoints of the <DRM Arc> (i.e., the positions of the first and last light points). L has a <DRM Light Rendering Properties> component specified with <DRM Flashing Light Behaviour>, so L is rendered as 30 flashing light points, evenly spaced between L’s endpoints. The UML for this example is depicted in Figure 4.8.

Figure 4.8 — Example arc representation

4.10.3.4 Surface geometry

4.10.3.4.1 Overview

Surface geometry is a set of <DRM Primitive Geometry> classes that use geometrical representation constructs having area, but no thickness. DRM classes that represent surface geometry include <DRM Polygon> and <DRM Ellipse>.

4.10.3.4.2 Polygons

A <DRM Polygon> class instance specifies a bounded portion of a plane, specified by a set of three or more ordered <DRM Vertex>components. The order of the <DRM Vertex> components is counterclockwise when viewed from the direction identified by computing the cross product of the vector from the first vertex to the second and the vector from the second vertex to the third. The first <DRM Vertex> is not duplicated to also appear as the last <DRM Vertex> of the <DRM Polygon>. Thus, the last segment connecting the last <DRM Vertex> instance to the first <DRM Vertex> instance is only implicitly specified. A <DRM Polygon> instance provides for texture mapping through optional <DRM Image Mapping Function> components and colouring through optional <DRM Colour> instances. The field entry polygon_flags shall have all applicable bits sets for a <DRM Polygon> instance.

4.10.3.4.3 Ellipses

<DRM Ellipse> represents an ellipse by specifying the centre of the ellipse as a <DRM Location> component, the major and minor axis lengths as field values, and the directions of the major and minor axes as <DRM Reference Vector> components with the appropriate vector_type values, either MAJOR_AXIS or MINOR_AXIS. These vectors are constrained to be perpendicular to one another.

An instance of <DRM Ellipse> specifies an ellipse in a manner such that the representation can be subjected to a coordinate conversion or transformation without undue distortion of the ellipse’s shape and position, and so that the ellipse can be specified at any desired position and any desired orientation.

4.10.3.5 Volume geometry

4.10.3.5.1 Overview

<DRM Volume Geometry> abstracts common properties of classes used to specify geometric volumes. <DRM Volume Geometry> has one concrete subclass, <DRM Elliptic Cylinder>.

4.10.3.5.2 Elliptic Cylinders

An instance of <DRM Elliptic Cylinder> specifies a closed cylindrical volume having an elliptical cross-section, in a manner such that the representation can be subjected to a coordinate conversion or transformation without distortion of the cylinder’s shape and position, and so that the cylinder can be specified at any desired position and any desired orientation.

<DRM Elliptic Cylinder> specifies the shape of the elliptic cross-section in the same manner used by <DRM Ellipse> (see 4.10.3.4.3 Ellipses). The position of the elliptic cylinder is specified by a <DRM Location 3D> representing the centre of the bottom face. In addition to major_axis_length and minor_axis_length fields, <DRM Elliptic Cylinder> contains a height field.

4.10.3.5.3 Finite element meshes

A finite element mesh is a surface or volume tessellated by mesh faces in the form of polygons that has property data associated with the mesh face vertices, the mesh faces, and/or solid elements, if any. The data is homogeneous in the sense that if one vertex (or face or solid element) has a set of property types, all the vertices (or faces or solid elements) will have the same set of property types. Since the <DRM Finite Element Mesh> class can represent  surface or volume data, it is considered a geometry representation. Because of the homogeneity of the data and since such data is organized as tables, a <DRM Finite Element Mesh> instance uses a <DRM Mesh Face Table> instance, an instance of a special form of <DRM Data Table>, to efficiently represent a finite element mesh. Finite element meshes are often used as input data for computational environment models.

4.11 Features

4.11.1 Overview

<DRM Feature> is an abstract DRM class for which an “instance” of the class (that is, an instance of one of the concrete classes descended from <DRM Feature>) is used to represent an entity in the environment, or an organized collection of such entities, that specifies the properties of the entity in terms of its spatial connectivity.

A <DRM Feature> is either a <DRM Primitive Feature> or a <DRM Feature Hierarchy>. A <DRM Primitive Feature> directly represents some environmental entity, or some portion of an environmental entity, while a <DRM Feature Hierarchy> is an organized collection of such primitives.

4.11.2 Primitive features

4.11.2.1 Overview

<DRM Primitive Feature> has three concrete subclasses: <DRM Point Feature>, <DRM Linear Feature>, and <DRM Areal Feature>. Consequently, all three of these classes inherit the formal aggregation, component, and association relationships specified for <DRM Feature> as well as those for <DRM Primitive Feature>. A <DRM Feature> may have a <DRM Classification Data> instance as a component, denoting what the particular <DRM Feature> represents, as well as <DRM Property Value> instances to capture the desired characteristics of that <DRM Feature>.

4.11.2.2 Point features

An instance of <DRM Point Feature> is used to represent a single environmental object, such as a tree, house, vehicle, or table, in such a way that the spatial information associated with that representation has been abstracted to a single point location. (The examples given earlier in this clause, although not directly mentioned, used a <DRM Point Feature> to represent the tree and building.) The spatial information itself is provided by an associated <DRM Feature Node> (see 4.5.9 Topology).

4.11.2.3 Linear features

An instance of <DRM Linear Feature> is used to represent a single environmental object, such as a power line, contour line, or road centreline, in such a way that the spatial information associated with that representation has been abstracted to a linear structure. The spatial information itself is provided by an ordered sequence of one or more associated <DRM Feature Edge> instances (see 4.12 Topology).

Each such <DRM Feature Edge> instance is associated through a link object; specifically, an instance of <DRM Edge Direction> specifying the direction in which that <DRM Feature Edge> is to be interpreted to incorporate it into the sequence. For example, consider a <DRM Linear Feature> representation of a single road that is part of a larger system of roads, where the representation is divided into many segments. The topology of the <DRM Linear Feature> in this example is a sequence of many <DRM Feature Edge> instances, where the <DRM Edge Direction> instances specify the direction (from start to end or end to start) in which each <DRM Feature Edge> is to be interpreted so that the <DRM Linear Feature> expresses the entire sequence as a continuous entity.

Note that a <DRM Linear Feature> is not required to be continuous; that is, it is possible for two <DRM Feature Edge> instances to be specified in sequence for a <DRM Linear Feature> that do not share a common endpoint. This permits the representation of linear entities that are discontinuous, such as a road that is interrupted by some terrain obstacle, such as a lake or crater.

4.11.2.4 Areal features

An instance of <DRM Areal Feature> is used to represent either an environmental object or the “universe” within which all other <DRM Primitive Feature> instances are considered to be located.

In the first case, if an instance of <DRM Areal Feature> is used to represent an environmental object, it represents a single environmental object, such as a lake, orchard, parking lot, or wall, in such a way that the spatial information associated with that representation has been abstracted to a bounded region. The spatial information itself is provided by one or more associated <DRM Regular Feature Face> instances (see 4.12 Topology).

If an instance of <DRM Areal Feature> is used to represent the “universe” within which all other <DRM Primitive Feature> instances are being specified, the spatial information itself is provided using one associated <DRM Universal Feature Face> instance (see 4.12 Topology).

4.11.3 Feature hierarchy

A <DRM Feature Hierarchy> is a hierarchically organized collection of <DRM Feature> instances. <DRM Feature Hierarchy> is abstract, and has two subclasses: <DRM Feature Model Instance> and <DRM Aggregate Feature>.

<DRM Feature Model Instance> is described in 4.14.2.2 Instancing. It provides a mechanism for referencing the <DRM Feature Model> of a <DRM Model>.

A <DRM Aggregate Feature> specifies a collection of <DRM Primitive Feature> and/or <DRM Feature Hierarchy> instances, organized according to some organizing principle specific to the particular subclass of <DRM Aggregate Feature> being considered. Each of the concrete subclasses of <DRM Aggregate Feature> is covered under the corresponding organizing principle.

4.12 Topology

4.12.1 Overview

Topology, in the DRM, is used to refer to constructs that provide a mechanism for representing entities in terms of spatial connectivity, such that spatial information that is not relevant to connectivity is omitted from the abstraction.

There are two categories of topological representation in the DRM: feature topology and geometry topology. While there are broad structural similarities between the two, they represent different semantic information. Feature topology represents connectivity information for associated <DRM Feature> instances, and semantically represents connectivity information for the environmental data being represented.

EXAMPLE a feature representation of two roads, where any intersections between the two roads are identified in their representations.

Geometry topology represents connectivity information for associated <DRM Geometry> instances and semantically represents connectivity information specific to the geometric representation itself.

EXAMPLE two <DRM Polygon> instances in which a common boundary is specified topologically.

Feature topology consists of instances of the subclasses of <DRM Feature Topology>:

1. <DRM Feature Node>,
2. <DRM Feature Edge>, and
3. <DRM Feature Face>.

These instances are always organized by a <DRM Feature Topology Hierarchy> instance.

1. Geometry topology consists of instances of the subclasses of <DRM Geometry Topology>:
2. <DRM Geometry Node>,
3. <DRM Geometry Edge>, and
4. <DRM Geometry Face>.

These instances are always organized by a <DRM Geometry Topology Hierarchy> instance.

4.12.2 Feature topology

4.12.2.1 Nodes

A <DRM Feature Node> represents a position in space that is significant in terms of its connectivity. This position is significant either because it specifies the topology of a <DRM Point Feature>, or because it is used to specify an endpoint for one or more <DRM Feature Edge> instances, or both. A <DRM Feature Node> can be considered “zero-dimensional”, in the sense that it specifies position but does not specify the dimensions of the thing being represented.

For a <DRM Feature Node> instance N, the position in space represented by N is the <DRM Location> component of N. N indicates for that <DRM Location>:

1. all associated <DRM Point Feature> instances located at N;
2. all <DRM Feature Edge> instances that refer to N as an endpoint; and
3. the <DRM Feature Face> instances, if any, within which N is located, depending on the level of topological information being provided.

The concept of levels of topological information is discussed in 4.12.3 Geometry topology.

4.12.2.2 Edges

A <DRM Feature Edge> represents a sequence of line segments in space such that the sequence is significant in terms of its connectivity. This information is significant either because it specifies the topology of a <DRM Linear Feature>, or because it is used to specify part of a boundary of one or more <DRM Feature Face> instances, or both. A <DRM Feature Edge> can be considered “one-dimensional”, in the sense that it specifies “length” but does not specify “width” or “height” for the entity being represented. (Note that a <DRM Feature Edge> may be specified in any orientation in space.)

For a <DRM Feature Edge> E, the endpoints of E are specified by its ordered associated <DRM Feature Node> instances, where the first <DRM Feature Node> associate N1 is the starting node and the second, N2, is the ending node. This directionality is utilized when specifying sequences of <DRM Feature Edge> instances to specify higher level constructs. Such higher level constructs are described in 6.3.80 <DRM Feature Edge>. If E is not a straight line between N1 and N2, E will have an ordered collection of <DRM Location> components, so that a non-self overlapping but connected sequence of line segments is specified between N1 and N2. The only self-overlapping case that may occur is when N1 and N2 are the same <DRM Feature Node>.

The set of <DRM Linear Feature> instances associated with E (if any) can always be determined by examining the associations of E. Depending on the level of topological information being supplied, E may also specify the collection of <DRM Feature Face> instances bordered by E, as associates of E that are ordered counterclockwise when “looking along” E.

4.12.2.3 Faces

4.12.2.3.1 Overview

A <DRM Feature Face> represents a region in space, not necessarily planar, such that the region is significant in terms of its connectivity. A <DRM Feature Face> can be considered “two-dimensional” in the sense that it does not specify “thickness” but does specify a spatial extent.

<DRM Feature Face> has a Boolean field universal that indicates whether  the <DRM Feature Face> is characterized by having an infinite extent (universal has value TRUE) or a finite extent (universal has value FALSE). No transmittal shall have more than one instance of <DRM Feature Face> characterized by having an infinite extent. Such an instance is termed as the "universal" <DRM Feature Face> instance. All other <DRM Feature Face> instances are termed "regular" <DRM Feature Face> instances.

Boundaries of a <DRM Feature Face> are specified by using by a <DRM Feature Face Ring> instance as described in 4.12.2.3.2 <DRM Feature Face Ring>.

4.12.2.3.2 <DRM Feature Face Ring>

A <DRM Feature Face Ring> specifies a boundary as a sequence of one or more ordered <DRM Feature Edge> instances forming a closed (but not necessarily planar) shape. Each <DRM Feature Edge> instance is associated through a <DRM Edge Direction> instance, specifying whether the <DRM Feature Edge> is to be interpreted “forwards” (start to end) or "backwards" (end to start) in order for it to connect with its predecessor and successor in the sequence. The constraints specified in 6.2.14 Feature_Edge constraints ensure that the <DRM Feature Edge> instances of a <DRM Feature Face Ring> do not touch except at their endpoints. The semantic information supplied by a <DRM Feature Face Ring> depends on its relationship with the <DRM Feature Face> instance for which it forms a boundary. That relationship indicates the type of boundary being specified by the <DRM Feature Face Ring> instance in question.
 

For a “regular” <DRM Feature Face> instance, one <DRM Feature Face Ring> instance specifies the explicit outer boundary of that <DRM Feature Face>. This <DRM Feature Face Ring> component, termed an “external” <DRM Feature Face Ring> instance, is specified by the “regular” <DRM Feature Face> instance as the first of its <DRM Feature Face Ring> components to indicate its role.

The other type of boundary that can be specified by a <DRM Feature Face Ring> is an inner boundary for the given <DRM Feature Face> instance. It specifies a “hole”, a region that is not semantically part of the <DRM Feature Face> instance in question. A <DRM Feature Face Ring> instance specifying an inner boundary is termed an “internal” <DRM Feature Face Ring> instance, and may be part of an instance of either a regular or a universal <DRM Feature Face> instance. In the case of a universal <DRM Feature Face> instance, all <DRM Feature Face Ring> components are internal, as a universal <DRM Feature Face> has no outer boundary, while for a “regular” <DRM Feature Face> instance, all <DRM Feature Face Ring> components other than the first are internal.

4.12.2.3.3 Regular <DRM Feature Face>

A regular <DRM Feature Face> instance is characterized by having an explicit outer boundary in the form of an external <DRM Feature Face Ring>, and thus having a finite extent. A regular <DRM Feature Face> instance may also have inner boundaries, specified by internal <DRM Feature Face Ring> instances. The first <DRM Feature Face Ring> component of a regular <DRM Feature Face> instance specifies the outer boundary, while the remaining <DRM Feature Face Ring> components (if any) specify any inner boundaries.

EXAMPLE Consider a regular <DRM Feature Face> instance associated with a <DRM Areal Feature> instance that represents the exterior wall of some structure, as indicated by a <DRM Classification Data> instance for the <DRM Areal Feature> instance. If the exterior wall contains windows, one possible representation is to represent the boundary of each window by an internal <DRM Feature Face Ring>. Note that the representation may go on to use the edges for each such <DRM Feature Face Ring> to specify a separate external <DRM Feature Face Ring> instance, regular <DRM Feature Face> instance, and <DRM Areal Feature> instance for the corresponding window, if desired. The fact that the exterior boundary of one of the windows forms an inner boundary of the wall makes the connection between the window and the wall explicit.

Regular <DRM Feature Face> instances may appear at any level of topology.

4.12.2.3.4 Universal <DRM Feature Face>

Instances of <DRM Feature Face> for which the universal field is set to TRUE only occur for topology level THREE or higher. The concept of levels of topology is represented as field information within the hierarchical organization of topology primitives rather than as part of the primitives themselves, since the level of a topological organization characterizes the quality of that information in terms of completeness and lack of redundancy.

There are currently six levels of feature topology organization:

0. A level ZERO organization contains <DRM Feature Topology> objects, but at least two <DRM Feature Node> instances are specified for the same coordinates in space. <DRM Feature Node> instances are required to be present, but higher level topological constructs may or may not be present.

1. At level ONE, no two <DRM Feature Node> instances shall be specified for the same coordinates in space, but otherwise there are no constraints in addition to those for level ZERO. At least two <DRM Feature Edge> instances intersect or overlap at some position not indicated by a common <DRM Feature Node> instance.

2. At level TWO, in addition to the conditions specified at level ONE, no two <DRM Feature Edge> instances intersect or overlap except where they meet at a common <DRM Feature Node>.

3. At level THREE, in addition to the conditions specified at level TWO, the following conditions are met. Every <DRM Feature Face> shall have an association to each <DRM Feature Node> located within it, and likewise every <DRM Feature Node> shall have an association to each <DRM Feature Face> within which it is located. Most importantly, in the context of <DRM Feature Face>, at level THREE, the set of regular <DRM Feature Face> instances shall form a complete surface and shall be exclusive and exhaustive; that is, they may meet only at common <DRM Feature Edge> instances. Every <DRM Feature Edge> shall form part of the boundary of at least one <DRM Feature Face>, and every <DRM Feature Face> shall have an association with every <DRM Feature Edge> forming part of any of its boundaries.

4. At level FOUR, in addition to the conditions specified by level THREE, the following conditions are met. The <DRM Feature Topology> instances are specified by <DRM Location 3D> instances, and at least one <DRM Feature Edge> shall form part of the boundary of more than two <DRM Feature Face> instances.

A detailed specification of the levels of feature topology is contained in 5.2.5.15 Feature_Topology_Level.

Universal <DRM Feature Face> instances exist to support the requirements of level THREE topology. A universal <DRM Feature Face> shall be provided for every context in which level THREE  topology is specified. Since every <DRM Feature Edge> is required to bound two <DRM Feature Face> instances, the outer boundary of the entire topological surface formed by the regular <DRM Feature Face> instances requires the presence of a universal <DRM Feature Face>, representing the “universe” outside the topological surface.

Since a universal <DRM Feature Face> consequently has infinite extent, it has inner boundaries as represented by internal <DRM Feature Face Ring> components, but has no outer boundary.

4.12.3 Geometry topology

The structure of the subclasses of <DRM Geometry Topology> somewhat resembles that of their counterparts in <DRM Feature Topology>, but the connectivity information is specified in terms of the location information embedded in the geometry rather than as components of the topology.

A <DRM Geometry Node> is always associated with an instance of one of the following, where the <DRM Location> specified by the associate is the location of the <DRM Geometry Node>:

1. <DRM Point>,
2. <DRM Vertex>,
3. <DRM Property Grid Hook Point>,
4. <DRM Ellipse> where the node corresponds to the centre, and
5. <DRM Elliptic Cylinder> where the node corresponds to the centre of the bottom face.

A <DRM Geometry Edge> is either associated with some <DRM Linear Geometry> (in which case, its <DRM Geometry Node> endpoints are associated with <DRM Vertex> instances of the <DRM Linear Geometry>) or forms part of the <DRM Geometry Face Ring> of some <DRM Geometry Face>.

<DRM Geometry Face> is somewhat simpler than its counterpart in feature topology. A <DRM Geometry Face> instance F has only a single <DRM Geometry Face Ring>, representing its outer boundary. F is associated with some collection of <DRM Polygon> instances that form a connected surface, specifying the outer boundary of the surface in question (which may or may not be planar). The <DRM Geometry Edge> instances forming the outer boundary of F shall be specified by <DRM Vertex> instances forming the outer boundary of the polygonal representation being so abstracted.

4.13 Organizing principles

4.13.1 Overview

4.13.1.1 Types of organization

There are fourteen data organizing principles for the geometry data, and ten for the feature data. Each of these is an organizing container that holds one or more data items. Most of the containers (for both feature and geometry) can hold other containers.

Primitives can only be contained within (and through) one of the containers for each of feature and geometry. This means, in cases where only a single primitive is to be represented, that the primitive shall be contained within at least one container.

The following is a list of the various organizing principles:

1. alternate hierarchy,
2. animation,
3. classification,
4. level of detail,
5. oct_tree,
6. perimeter,
7. quad_tree,
8. separating plane,
9. spatial index,
10. state,
11. time,
12. union of geometry hierarchy
13. union of primitive geometry, and
14. union of features.

Of these, the following concepts organize by spatial relationship:

1. oct_tree division of a volume,
2. quad_tree division of a region,
3. perimeter division by irregularly shaped boundaries,
4. separating planes, and
5. spatial index division by regularly shaped boundaries.

Each of these organizing principles has at least one formal constraint specifying the semantic constraints that apply to the corresponding <DRM Aggregate Geometry> and <DRM Aggregate Feature> subclasses that embody these organizing principles.

Organizing principles that provide special purpose groupings include:

1. alternate hierarchy, where the contained data within each branch represents exactly the same information, except that it is organized for a specific use or application;
2. animation, where the contained data, which is always geometric, is organized by prescribed animation sequences;
3. level of detail (LOD), where contained data is organized by various characteristics such as scale, viewing distance or range, and spatial resolution;
4. continuous LOD (CLOD), where contained data is organized by an algorithm (generally used in computer graphics applications) that replaces specific facets with finer detailed facets, on a facet by facet basis;
5. union of geometry hierarchy, where the contained data is organized but the reason for organizing them into separate branches is not specified;
6. union of primitive geometry, where the contained data is a collection of <DRM Primitive Geometry> instances; and
7. union of features, where the contained data is a collection of <DRM Primitive Feature> instances and/or <DRM Feature Hierarchy> instances.

Other organizing principles include:

1. time, where the contained data is valid for specific time periods;
2. state, where data is organized according to the specific characteristics of objects that describe the state of the object, such as discrete changes in the physical shape or geometry of an object or collection of objects; and
3. classification, such as organizing all objects in a classroom by their types.

Each of these organizing principles is described more fully below.

4.13.1.2 Strict organizing principle

Each instance of <DRM Aggregate Geometry> and <DRM Aggregate Feature> either strictly complies with the constraints imposed by the organizing principle applicable to the specific subclass it is an instance of, or does not strictly comply. The organizing principle constraint for each specific organizing principle subclass specifies what constitutes strict compliance for that subclass. SEDRIS supports either strict or loose compliance to these constraints.

EXAMPLE In a spatial organization defined in terms of boundaries, strict compliance might require that a primitive assigned to a branch associated with a particular boundary be contained completely within that boundary, while non-strict compliance would require only that the primitive overlap the specified region rather than be contained within it.

The strict_organizing_principle field of data type Boolean specifies whether a specific instance of <DRM Aggregate Geometry> or <DRM Aggregate Feature> complies strictly with its organizing principle. A value of  TRUE specifies that the given instance meets the criteria for strict compliance for the corresponding subclass. A value of  FALSE specifies that the given instance does not meet the criteria for strict compliance.. The strict_organizing_principle field allows data consumers to make informed decisions about processing object representations, since it notifies data consumers about what simplifying assumptions can be made about the level of organizing principle compliance being observed.

4.13.1.3 Unique descendants

In any <DRM Aggregate Geometry> or <DRM Aggregate Feature> instance, the possibility exists that a primitive within the organization represented by that instance may appear in more than one branch of
the aggregation.

EXAMPLE A <DRM Polygon> instance falling on a cell boundary within a spatial index organization might be assigned to both cells by the data provider responsible for that <DRM Polygon>.

The unique_descendants field of data type Boolean specifies whether each primitive is unique or may be shared.  A value of TRUE indicates that each primitive in the aggregation only appears one time. A value of FALSE indicates that each primitive may be shared within the aggregation. This field allows a data consumer to optimize processing if the value is TRUE.

4.13.2 Alternate hierarchy

The alternate hierarchy organizing principles provides a DRM mechanism to represent the same set of environmental data using different representations. Organization by alternate hierarchy is supported by the DRM classes <DRM Alternate Hierarchy Related Geometry> for geometry data and <DRM Alternate Hierarchy Related Features> for feature data. The alternate_representation_reason field of the link class <DRM Hierarchy Data> instance specifies the reason for each branch in the hierarchy.

4.13.3 Animation

The animation organizing principle represents environmental data as a sequence of animation frames. A <DRM Animation Related Geometry> instance aggregates an ordered set of <DRM Geometry Hierarchy> instances that comprise the sequence of animation frames. The behaviour of the animation sequence is controlled by the ordered <DRM Animation Behaviour> components of a <DRM Animation Related Geometry> instance.

Each <DRM_Animation_Behaviour> specifies:

1. frame duration in seconds,
2. the number of times the animation sequence will repeat with a flag value of zero for continuous repetition,
3. the sequence mode to cycle through the frames, whether standard (beginning to end) or swing (beginning to end, end to beginning),
4. the index of the component representing the beginning frame of the <DRM_Animation_Related_Geometry>,
5. the index of the component representing the ending frame of the <DRM_Animation_Related_Geometry>, and
6. a flag to specify a random beginning frame that will ignore the beginning frame index and have the sequence cycle towards the ending frame.

4.13.4 Classification

The classification related organizing principle groups environmental data by EDCS classification code (ECC) using the DRM classes <DRM Classification Related Features> and <DRM Classification Related Geometry>. The class <DRM Classification Related Features> shall have at least one instance of <DRM Aggregate Feature> and the ECC stored in a link object of DRM class <DRM Classification Data>. Likewise, an instance of the class <DRM Classification Related Geometry> shall have at least one instance of <DRM Aggregate Geometry> as a component and the ECC stored in a link object of DRM class <DRM Classification Data>.

4.13.5 Level of detail

The LOD organizing principles provides a DRM mechanism to represent the same set of environmental data using alternate representations at different levels of detail. This is done with the classes <DRM Level Of Detail Related Geometry> and <DRM Level Of Detail Related Features>. These two DRM classes of aggregate objects, <DRM Aggregate Feature> and <DRM Aggregate Geometry>, contain the actual alternate representations at the different levels of detail. The level of detail information is provided in the link object that will be of one of the DRM subclasses of <DRM Base Level of Detail Data>.

The DRM classes available to be used as link objects to store the level of detail information are:

1. <DRM Distance Level Of Detail Data>,
2. <DRM Index Level Of Detail Data>,
3. <DRM Map Scale Level Of Detail Data>,
4. <DRM Spatial Resolution Level Of Detail Data>, and
5. <DRM Volume Level Of Detail Data>.

The <DRM Distance Level Of Detail Data> class specifies a level of detail described in terms of distance from the eyepoint to the centre of the object. This class specifies the following:

1. the minimum range in metres where the corresponding <DRM Feature Hierarchy> or <DRM Geometry Hierarchy> is valid,
2. the minimum fade band in metres where the corresponding <DRM Feature Hierarchy> or <DRM Geometry Hierarchy> can begin to be faded in,
3. the maximum range in metres where the corresponding <DRM Feature Hierarchy> or <DRM Geometry Hierarchy> is valid, and
4. the maximum fade band in metres where the corresponding <DRM Feature Hierarchy> or <DRM Geometry Hierarchy> begins to fade out.

The centre of the object to be used for evaluation is provided as a <DRM Location> component of the <DRM Distance Level Of Detail Data> link object.

The <DRM Index Level Of Detail Data> class specifies an index that indicates the relative level of detail of the associated data. Lower values indicate more detailed versions and higher values indicate less detailed versions.

The <DRM Map Scale Level Of Detail Data> class specifies the level of detail based on the map scale of the associated data. The map scale is provided as a float value.

The <DRM Spatial Resolution Level Of Detail Data> class specifies the level of detail based on spatial resolution providing both the spatial resolution and the unit of measurement for such resolution.

The <DRM Volume Level Of Detail Data> class specifies the level of detail representation based on a volume and whether the data is in or outside of the volume. The centre of the volume is specified by the <DRM Location 3D> component of the link object. The shape of the volume is specified by the <DRM Volume Extent> component of the link object. The information needed to orient and locate the volume is provided in the <DRM World Transformation> component. The class has a single Boolean field value that, if set, specifies that the data within the specified branch is valid inside of the volume. When the flag is not set, the value of the data is valid when outside of the specified volume.

4.13.6 Oct_tree

The oct_tree related organizing principle is represented in the DRM by the <DRM Octant Related Geometry> class for the organization of geometry, and the <DRM Octant Related Features> class for the organization of features. The two classes are constrained by the 6.2.38 Oct tree related organizing principle constraint to ensure that instances of these classes are semantically valid. In terms of their oct_tree behaviour, <DRM Octant Related Features> and <DRM Octant Related Geometry> have exactly the same organization, so “oct_tree related aggregation”, will be used herein to mean either an instance of <DRM Octant Related Geometry> or an instance of <DRM Octant Related Features>. The notion of an oct_tree is analogous to that of a quad_tree as discussed in 4.13.8 Quad_tree.

An oct_tree corresponds to the spatial data structure notion of a region oct_tree (see  [SAMET]) that divides a volume into eight equal-sized octants. However, an oct_tree in SEDRIS is not necessarily a classical region oct_tree, in that a SEDRIS data provider is not constrained to organize the entire hierarchy below an oct_tree as smaller and smaller oct_trees. A data provider may choose to do so, but it is not a requirement.

To begin specifying an oct_tree, the region being subdivided into octants shall be specified. A three-dimensional <DRM Spatial Extent> component is attached to each octant related aggregation, specifying the parallelepiped being divided into octants. Every octant related aggregation has between one and eight branches (<DRM Feature Hierarchy> instances in the case of <DRM Octant Related Features>, <DRM Geometry Hierarchy> instances in the case of <DRM Octant Related Geometry>) corresponding to the equal-sized octants into which the region is being partitioned. The <DRM Octant Data> link object for a given branch indicates, via the value of its octant field, which of the eight octants is represented.

Note that an oct_tree related organization is not required to specify a branch for each possible octant. Some data providers may have data that naturally lends itself to oct_tree organization, but which for some reason leaves one or more octants empty.

For consumption of a transmittal in a spatial reference frame other than that in which it was specified, 6.2.38 Oct tree related organizing principle specifies further constraints to ensure that each octant is clearly specified, even if coordinate conversion or transformation is applied to the data. This is necessary, because the notion of ‘size’ is not invariant under coordinate conversion and transformation. Consequently, each branch of an oct_tree related organization is required to specify an explicit three-dimensional <DRM Spatial Extent>, corresponding exactly to the bounding parallelepiped of the octant represented by that branch.

Since a <DRM Spatial Extent> component specifies a strict boundary, no position information in the scope of its aggregate may lie outside the bounding parallelepiped specified by the <DRM Spatial Extent>. Consequently, the strict_organizing_principle field value of an oct_tree related organization is always TRUE indicating that the oct_tree related organizing principle is strictly obeyed. In addition, since the octants partition the oct_tree’s region and do not overlap, no two branches may have primitives in common, so the unique_descendants field value of an oct_tree related aggregation is always TRUE. A user who does not wish to ensure that the primitives within his or her data always conform strictly to an oct_tree related organization can still organize the data spatially, using a spatial index related organization.

4.13.7 Perimeter

The perimeter related organizing principle provides for spatial organization of environmental data by providing a set of non-overlapping perimeters. This organizing principle is expressed in the DRM by <DRM Perimeter Related Geometry> and <DRM Perimeter Related Features>. Each of these classes may contain instances of <DRM Geometry Hierarchy> and <DRM Feature Hierarchy>, respectively, with link objects of <DRM Perimeter Data>. The perimeter data is stored as <DRM Location> objects of the link object. This class shall meet the constraint 6.2.38 Non-selfoverlapping Perimeter_Data locations.

4.13.8 Quad_tree

The quad_tree related organizing principle is represented in the DRM by the <DRM Quadrant Related Geometry> class for the organization of geometry, and the <DRM Quadrant Related Features> class for the organization of features. The two classes are constrained by the 6.2.47 Quad tree related organizing principle constraint to ensure that instances of these classes are semantically valid. In terms of their quad_tree behaviour, <DRM Quadrant Related Features> and <DRM Quadrant Related Geometry> have exactly the same organization, so “quad_tree related aggregation”, will be used herein to mean either an instance of <DRM Quadrant Related Geometry> or an instance of <DRM Quadrant Related Features>.

A quad_tree corresponds to the spatial data structure notion of a region quad_tree (see [SAMET]), that divides a region into four equal-sized quadrants. However, a quad_tree in SEDRIS is not necessarily a classical region quad_tree, in that a SEDRIS data provider is not constrained to organize the entire hierarchy below a quad_tree as smaller and smaller quad_trees. A data provider may choose to do so, but it is not a requirement.

To begin specifying a quad_tree, the region being subdivided into quadrants shall be specified. This is done by attaching a <DRM Spatial Extent> component to each quad_tree related aggregation, specifying the rectangular region being divided into quadrants. Every quad_tree related aggregation then has between one and four branches (<DRM Feature Hierarchy> instances in the case of <DRM Quadrant Related Features>, <DRM Geometry Hierarchy> instances in the case of <DRM Quadrant Related Geometry>) corresponding to the equal-sized quadrants into which the region is being partitioned. The <DRM Quadrant Data> link object for a given branch indicates, via the value of its quadrant field, which of the four quadrants is represented.

Note that a quad_tree related organization is not required to specify a branch for each possible quadrant. Some data providers may have data that naturally lends itself to quad_tree organization, but which for some reason leaves one or more quadrants empty. For example, a <DRM Quadrant Related Geometry> representing some area of terrain may include a lake within its boundaries, such that one or more of the quadrants has no non-bathymetric terrain. (Conversely, a <DRM Quadrant Related Geometry> organizing <DRM Property Grid> instances describing various properties of a region of sea water may omit a quadrant because it corresponds to an island.)

To assist the API in consuming a transmittal in a spatial reference frame other than that in which it was specified, 6.2.47 Quad tree related organizing principle specifies further constraints to ensure that each quadrant is clearly specified, even if coordinate conversion or transformation is applied to the data. This is necessary, because the notion of “size” is not invariant under coordinate conversion and transformation. Consequently, each branch of a quad_tree related organization is required to specify an explicit <DRM Spatial Extent>, corresponding exactly to the bounding box of the quadrant represented by that branch.

A <DRM Spatial Extent> component specifies a strict boundary, such that no position information in the scope of its aggregate may lie outside the bounding rectangle (if the <DRM Spatial Extent> is two-dimensional) or bounding parallelepiped (if the <DRM Spatial Extent> is three-dimensional) specified by the <DRM Spatial Extent>. Consequently, the strict_organizing_principle field value of a quad_tree related organization is always TRUE, indicating that the quad_tree related organizing principle is strictly obeyed. In addition, since the quadrants partition the quad_tree’s region and do not overlap, no two branches may have primitives in common, so the unique_descendants field value of a quad_tree related aggregation is always TRUE. A user who does not wish to ensure that the primitives within his or her data always conform strictly to a quad_tree related organization can still organize the data spatially, using a spatial index related organization.

4.13.9 Separating plane

The separating plane organizing principle provides for organizing environmental data based on whether the data is on the positive or negative side of a specified plane. Environmental data organized by a separating plane uses the DRM class <DRM_Separated_Plane_Relations> that aggregates instances of DRM class <DRM Aggregate Geometry> and a component of <DRM Separating Plane>. A link object of type <DRM Separating Plane Data> provides a Boolean field specifying if the environmental data objects is on the positive or negative side of the plane specified by the <DRM Separating Plane> instance. The separating plane is specified by the three ordered <DRM Location> components.  The positive side of the plane is specified to be the side with plane normal pointing towards it and the negative side with the plane normal pointing away from it.

4.13.10 Spatial index

The spatial index related organizing principle specifies an aggregation in which each component represents a different rectangular area, termed a tile, within a spatially indexed organization of objects within a SEDRIS transmittal. Each tile is uniquely identified with two indices contained in the <DRM Spatial Index Data> link object attached to each component.

The spatial index related organizing principle is represented in the DRM by the <DRM Spatial Index Related Geometry> class for the organization of geometry, the <DRM Spatial Index Related Features> class for the organization of features, the <DRM Spatial Index Related Geometry Topology> class for the organization of geometry topology, and the <DRM Spatial Index Related Feature Topology> class for the organization of feature topology. The four classes are constrained as specified in 6.2.52 Spatial_Index related organizing principle to ensure that instances of these classes are semantically valid. In terms of their spatial index behaviour, all four have exactly the same organization, so the term “spatial index related aggregation” will be used to refer to an instance of any of the four classes named above.

4.13.11 State

The state related organizing principle provides representation of the same environmental data with different state values. This is implemented with the DRM classes <DRM State Related Features> and <DRM State Related Geometry> that aggregate instances of DRM class <DRM Aggregate Feature> and <DRM Aggregate Geometry>, respectively, with link objects of <DRM State Data>. <DRM State Related Features> and <DRM State Related Geometry> instances provide both state_tag and active_state_value fields. The state_tag field is the EDCS Attribute Code (EAC) that is being used to differentiate the components of the state aggregation. The active_state_value field specifies the default value for the state information. The <DRM State Data> instance stores a value for the specific branch of the same fundamental type as specified by the active_state_value field.

In state-related aggregations, the state_tag field specifies the semantic meaning of the related <DRM State Data> field values, as well as that of the active state of the aggregation as a whole. Since EDCS attributes that are used as state tags are restricted to those EDCS attributes having percentage or enumerated values, unit and scale information need not be specified.

4.13.12 Time

The time organizing principle provides a representation of environmental data at different points in time. This is implemented with the DRM classes <DRM Time Related Features> and <DRM Time Related Geometry> that aggregate instances of <DRM Aggregate Feature> and <DRM Aggregate Geometry>, respectively, with link objects of <DRM Time Constraints Data>. The data can be organized based on the following types of time data:

• months
• seasons
• time intervals
• time of day
• time points

The type of time data being used is specified in the <DRM Time Related Features> or <DRM Time Related Geometry> class.

4.13.13Union

4.13.13.1 Union of geometry hierarchy

<DRM Union Of Geometry Hierarchy> exists to allow <DRM Geometry Hierarchy> instances to be grouped together where none of the more structured organizing principles is applicable.

For example, consider a <DRM Geometry Model> representing a building, in which the <DRM Geometry Hierarchy> consists of four <DRM Geometry Model Instance> instances of another <DRM Geometry Model> representing a wall. Each <DRM Geometry Model Instance> has an appropriate <DRM Transformation> component ensuring that it is instanced in with the correct position and orientation; no higher level organization is needed. Consequently, the <DRM Geometry Model> uses a <DRM Union Of Geometry Hierarchy> to aggregate the four <DRM Geometry Model Instance> objects.

The components of a <DRM Union Of Geometry Hierarchy> are not required to be homogeneous; for example, a <DRM Union Of Geometry Hierarchy> instance may contain both <DRM Property Grid Hook Point> instances and <DRM Union Of Primitive Geometry> instances as components. The components are required to be unique. That is, a given <DRM Geometry Hierarchy> instance cannot be attached twice as a component of the same <DRM Union Of Geometry Hierarchy> instance. This does not in itself guarantee that none of the <DRM Geometry Hierarchy> components have common primitives; therefore, the field value of unique_descendants is data-dependent.

The <DRM Geometry Hierarchy> components of a <DRM Union Of Geometry Hierarchy> are ordered; that is, retrieving the k^th <DRM Geometry Hierarchy> component of a given <DRM Union Of Geometry Hierarchy> will always result in the same object. The meaning of, or reason for, the ordering, if any, is specified via the ordering_reason field of the <DRM Union Of Geometry Hierarchy>  instance. For example, if the data provider chose to use the ordering of the <DRM Geometry Hierarchy> components to indicate rendering order rather than using explicit <DRM Rendering Priority Level> instances, ordering_reason would be FIXED_LISTED.

Since a <DRM Union Of Geometry Hierarchy> has no organizing principle other than that its descendants are unique and its ordering reason, its strict_organizing_principle field value is always TRUE. (If an ordering reason were not strictly followed, the ordering_reason field value would be NONE.)

4.13.13.2 Union of primitive geometry

A <DRM Union Of Primitive Geometry> instance groups an ordered list of <DRM Primitive Geometry> instances. All <DRM Geometry Hierarchy> branches eventually terminate by reaching a <DRM Geometry Model Instance>, a <DRM Property Grid Hook Point>, or a <DRM Union Of Primitive Geometry>, at which point the hierarchical organization transitions into another concept. In the case of <DRM Union Of Primitive Geometry>, a <DRM Union Of Primitive Geometry> exists to connect actual <DRM Primitive Geometry> instances to the rest of the organization of a transmittal; <DRM Primitive Geometry> instances cannot occur in any other context.

The components of a <DRM Union Of Primitive Geometry> are not required to be homogeneous; for example, a <DRM Union Of Primitive Geometry> instance may contain both <DRM Polygon> instances and <DRM Point> instances as components. The components are required to be unique. A given <DRM Primitive Geometry> instance cannot be attached twice as a component of the same <DRM Union Of Primitive Geometry> instance. Consequently, the unique_descendants field value of a <DRM Union Of Primitive Geometry> is always TRUE.

The <DRM Primitive Geometry> components of a <DRM Union Of Primitive Geometry> are ordered. Retrieving the k^th <DRM Primitive Geometry> component of a given <DRM Union Of Primitive Geometry> shall always result in the same object. The reason for the ordering, if any, is specified via the ordering_reason field of the <DRM Union Of Primitive Geometry> instance.

EXAMPLE If the data provider chose to use the ordering of the <DRM Primitive Geometry> components to indicate rendering order rather than using explicit <DRM Rendering Priority Level> instances, ordering_reason would be FIXED_LISTED.

Since a <DRM Union Of Primitive Geometry> has no organizing principle other than that its descendants are unique and its ordering reason, its strict_organizing_principle field value is always TRUE. If an ordering reason were not strictly followed, the ordering_reason field value would be NONE.

4.13.13.3 Union of features

A <DRM Union Of Features> instance is the analogue to both <DRM Union Of Geometry Hierarchy> and <DRM Union Of Primitive Geometry>; its components may be either <DRM Feature Hierarchy> instances and/or <DRM Primitive Feature> instances.

The components of a <DRM Union Of Features> are not required to be homogeneous.

EXAMPLE A <DRM Union Of Features> instance may contain both <DRM Quadrant Related Features> instances and <DRM Areal Feature> instances as components.

The components are required to be unique. That is, a given <DRM Feature> instance cannot be attached twice as a component of the same <DRM Union Of Features> instance. This does not in itself guarantee that none of the components have primitives in common when <DRM Aggregate Feature> components are present. Therefore, the field value of unique_descendants is data-dependent.

The <DRM Feature Hierarchy> components of a <DRM Union Of Features> are ordered. That is, retrieving the k^th <DRM Feature Hierarchy> component of a given <DRM Union Of Features> will always result in the same object. The meaning of, or reason for, the ordering, if any, is specified via the ordering_reason field of the <DRM Union Of Features> instance. For example, if the data provider chose to use the ordering of the <DRM Feature Hierarchy> components to indicate rendering order for any geometry to be derived from the features, ordering_reason would be FIXED_LISTED.

Since a <DRM Union Of Features> has no organizing principle other than that its descendants are unique, its union reason, and its ordering reason, its strict_organizing_principle field value is always TRUE. (If an ordering reason were not strictly followed, the ordering_reason field value would be NONE, and similarly for union_reason.)

4.14 Constructs for sharing data

4.14.1 Overview

4.14.2 Models

4.14.2.1 Overview

A model is specified as a representation of an entity or phenomenon in the environmental data. This could include such items as a tree, a forest, a park bench, a door knob, or a motor vehicle. Furthermore, models can be composed of other models.

EXAMPLE a model of a house could be composed of a set of window models, door models, and wall models

When a model can be a stand alone entity in the transmittal, it is referred to as a root model. If it cannot stand alone, it is referred to as a component model.

A model is embodied in the DRM through the class <DRM Model>.   This class allows a model to contain both a feature and geometry representation.  The feature representation is specified using instances of the <DRM_Feature_Model> class and the geometry representation is specified using instances of the <DRM_Geometry_Model> class.  Models can be constructed with a specific SRF and have field values to indicate:

1. if the model is a model that moves within the transmittal;
2. if the model is a root model and/or a component model;
3. if the model has moving parts; and
4. if the model either has units for the SRF or is unitless.

<DRM Model> within a <DRM Model Library> can contain feature and/or geometry data similar to the <DRM Environment Root>. This allows models to be worlds onto themselves. Since a <DRM Model> can be instanced within a <DRM Environment Root> or another <DRM Model>, complex worlds composed of environments containing many <DRM Model>s can be constructed. For example, one method for representing the solar system is to design and describe each of the planets at the desired detail and place them in the <DRM Model Library> as individual <DRM Model>s. Subsequently each of the planets may be instanced at the appropriate position within the environment (under a <DRM Environment Root>). Since a <DRM Model> can reference another <DRM Model>, each representation of the planets can contain very detailed data, such as trees and buildings.

4.14.2.2 Instancing

Models are stored in the transmittal under the <DRM_Model_Library> component of the <DRM_Transmittal_Root> instance. These models are instanced into other models or into the hierarchy under a <DRM Environment Root> instance in a transmittal. The DRM allows the instancing of the specific <DRM Geometry Model> or   <DRM Feature Model> components of the <DRM_Model> . To create an instance of the geometric representation of a model, a <DRM_Geometry_Model_Instance> is created that associates to the <DRM_Geometry_Model> to be instanced.  Likewise, in order to instance the feature representation of a model, a <DRM_Feature_Model_Instance> is created that associates to the <DRM_Feature_Model> to be instanced.

4.14.2.3 Transformations

When instancing models into local use within the environment, variations to the base model can be assigned through translation, rotation, and scaling, as well as overriding the attributes of the base model.  Overriding attributes of the base model is discussed in 4.16.2 Control links and expressions, while other changes to models are referred to as transformations in this part of ISO/IEC 18023.

There are two purposes for transforming models.  The first purpose is to instance into a new SRF and the second is to provide local attributes for models to appear to be unique.  The abstract DRM class <DRM_Transformation> provides the mechanism to provide both of these capabilities.  It provides the capability to transform into a new SRF and alter the model through the <DRM World Transformation> class. The DRM also provides for altering models instanced within other models through the <DRM_LSR_Transformation> subclass of <DRM_Transformation>.

The <DRM World Transformation> class specifies a <DRM_Location> and a 3×3 matrix, used to transform the model into the non-LSR SRF. The location specifies the SRF to be instanced into and the exact location the model origin should be instanced. The 3×3 matrix provides a nine element matrix containing scaling and rotation data where the direction of rotation is determined by the right-hand rule.

The <DRM_LSR_Transformation> class specifies the transformation to occur when instancing a model in a LSR SRF into another model in a LSR SRF.  This is done by either providing a 4×4 matrix through the class <DRM_Local_4x4> or through an ordered set of <DRM_LSR_Transformation>.

4.14.3 Libraries

4.14.3.1 Overview

A <DRM Library> serves as a repository for data that may occur many times within the scope of an <DRM Environment Root> or <DRM Model>. The data is stored once in the <DRM Library>, then instanced via references to the <DRM Library> rather than replicating the actual data every time the data is used.

The abstract class <DRM Library> has seven concrete subclasses:

1. <DRM Property Set Table Library>, where reusable sets of properties are stored;
2. <DRM Colour Table Library>, where reusable colour tables are stored;
3. <DRM Data Table Library>, where reusable data tables (n-dimensional arrays of data) are stored;
4. <DRM Image Library>, where reusable images and/or texture maps are stored;
5. <DRM Model Library>, where reusable models of physical environmental objects are stored;
6. <DRM Sound Library>, where reusable sound items are stored, and
7. <DRM Symbol Library>, where reusable map symbols are stored.

In any given transmittal, there can be at most one instance of each of the seven <DRM Library> subclasses.

4.14.3.2 <DRM Property Set Table Library>

The <DRM Property Set Table Library> class contains elements of class <DRM Property Set Table Groups>.  This class, in turn, contains <DRM Property Set_Table> objects that, in turn, contain <DRM Property Set> objects. The class <DRM Property Set> supports collecting a set of properties to be referenced as a group. See 4.14.4 Property sets for details.

To share the property sets, the DRM provides the class <DRM Property Set_Index>. Instances of this class have associations to the <DRM Property Set Table Group> instances in the <DRM Property Set Table Library> instance in the transmittal.  The index is provided for the <DRM Property Set> component of the primary <DRM Property Set_Table>. The <DRM Property Set> objects can also be shared by being directly aggregated by other DRM objects.

4.14.3.3 <DRM Colour Table Library>

The <DRM_Colour_Table Library> class contains elements of class <DRM Colour Table Group>.  This class contains <DRM_Colour_Table> objects that, in turn, contain <DRM_Primitive_Colour> objects. This mechanism allows for the grouping and reuse of <DRM_Primitive_Colour> throughout a transmittal.

In order to share the primitive colours, the DRM provides the class <DRM_Colour_Index>. Instances of this class have associations to the <DRM Colour Table Group> instances in the <DRM_Colour_Table Library> instance in the transmittal. The index is provided for the <DRM Primitive Colour> component of the primary <DRM_Colour_Table>. The <DRM Primitive Colour> instances can also be shared by being directly aggregated by other DRM objects.

4.14.3.4 <DRM Data Table Library>

The <DRM_Data_Table_Library> class is used to contain <DRM_Data_Table> instances that can be referenced or instanced by an object within the transmittal. This referencing can be done through aggregation by other DRM objects or through other data table mechanisms as described in 4.5.6 Data Tables.

4.14.3.5 <DRM Image Library>

The <DRM Image Library> class aggregates a complete list of the <DRM_Image> instances that can be referenced in a transmittal. The <DRM_Image> is referenced from within the transmittal with the class <DRM Image Mapping Function>.

4.14.3.6 <DRM Model Library>

The <DRM Model Library> class aggregates a complete list of the <DRM Model> objects that can be referenced in a transmittal. Model referencing is described in 4.5.11.1 Models.

4.14.3.7 <DRM Sound Library>

The <DRM Sound Library> class contains the complete list of the unique <DRM Sound> objects that can be referenced within a transmittal.  Sound referencing is accomplished through the use of a <DRM Sound Instance> object.

4.14.3.8 <DRM Symbol Library>

The <DRM Symbol Library> class contains the complete list of the unique <DRM Symbol> instances that can be referenced within a transmittal.  Symbols are referenced as components of <DRM Label> instances.

4.14.4 Property sets

An instance of the <DRM Property Set> class organizes a collection of properties (i.e., non-spatial information about a SEDRIS object representation). A property set may include metadata information and/or non-metadata information. Instances of any of the metadata classes may be included in a <DRM Property Set> instance.

Instances of the following non-metadata classes are allowed as components of an instance of <DRM Property Set>:

• <DRM_Classification Data>,
• <DRM_Colour>,
• <DRM Image Mapping Function>,
• <DRM Light Rendering Properties>,
• <DRM Presentation Domain>,
• <DRM Property Table>,
• <DRM Property Table Reference>,
• <DRM Property Value>,
• <DRM Rendering Priority Level>,
• <DRM Responsible Party>,
• <DRM Rendering Properties>, and
• <DRM Spatial Extent>.

A <DRM Property Set> instance may specify what kind of environmental object is being represented, details of how its representation should be rendered visually in specific presentation domains, and various values of its environmental state (whether organized as a single value, a table of values, or both). This provides an effective mechanism for specifying, for a given kind of environmental object, the characteristics of that kind of object, which can then be shared by different representations.

A <DRM Property Set> instance is stored in a transmittal as part of a <DRM Property Set Table> instance. A <DRM Property Set> instance is referenced by geometric and/or feature representations using instances of the <DRM Property Set Index> class; see 4.14.3.2 <DRM Property Set Table Library> for details.

4.14.5 Inheritance

4.14.5.1 Overview

DRM objects that specify properties can be attached to various levels of a <DRM Aggregate Feature> (or <DRM Aggregate Geometry>) instance hierarchy and “inherited” by the various features (or geometry) that are organized by that aggregate. That is, an instance of <DRM Aggregate Geometry> instances (or <DRM Aggregate Feature>) inherits a list of properties from its aggregate.

Property inheritance and context applies to the following DRM classes:

1. <DRM Primitive Feature> and its subclasses;
2. <DRM Primitive Geometry> and its subclasses;
3. <DRM Aggregate Feature> and its subclasses, each of which organizes one or more collections of <DRM Primitive Feature> instances;
4. <DRM Aggregate Geometry> and its subclasses, each of which organizes one or more collections of <DRM Primitive Geometry> instances; and
5. DRM objects that specify attributes of geometry or features.

For the purposes of discussion, the following terminology will be established. One object A is the ancestor of another object B when A aggregates B as a component, or when A is an aggregate of an ancestor of B. B, in turn, is said to be a descendant of A. If A is an aggregate of B, B is said to be a directly attached component of A, to distinguish this case from cases where A is an ancestor but not an aggregate of B.

EXAMPLE A <DRM Polygon> is an ancestor of its <DRM Vertex> components, and a <DRM Union Of Primitive Geometry> can be an ancestor of a <DRM Polygon>.

The purpose of attribute inheritance is to indicate that a collection of <DRM Primitive Feature> instances (or <DRM Primitive Geometry> instances) all have the same attribute as a component. This allows attaching the component to a “higher” object in the hierarchy, rather than attaching it to each individual primitive object. This “higher” object eventually aggregates the primitive objects, which inherit the component from this “higher” ancestor object. Thus, explicit sharing of individual object instances occurs efficiently among many aggregates.

Inheritance is transitive. That is, when a <DRM Geometry> or <DRM Feature> inherits a component, that component may be treated as if it were attached directly to the <DRM Geometry> or <DRM Feature> instance that inherited the component. All the inherited components of an <DRM Aggregate Geometry> are inherited in turn by any <DRM Primitive Geometry> and <DRM Property Grid Hook Point> instances aggregated by that <DRM Aggregate Geometry>, subject to the rules of inheritance. Similarly, all the inherited components of a <DRM Aggregate Feature> are inherited in turn by any <DRM Primitive Feature> instances aggregated by that <DRM Aggregate Feature>.

The <DRM Geometry Model Instance> and <DRM Feature Model Instance> classes do not participate in attribute inheritance. If the attribute objects within a <DRM Model> are to be determined on an instance-by-instance basis, <DRM Model> shall have an <DRM Interface Template> and an appropriate set of <DRM Control Link> and <DRM Variable> instances.

In addition to inheriting components, there are two cases in which link objects are inherited: the classification related and time related organizations. The same rules that apply to classification related aggregations also apply to time related aggregations. An aggregate, primitive, or <DRM Property Grid Hook Point> member of a classification related aggregation inherits a <DRM Classification Data> component identical to the information in the link object between the component and the classification related aggregation.

4.14.5.2 General inheritance rules

If a component is directly attached to an object to associate a property with that object and the object is a member of an aggregating hierarchy, that component will override any similar component attached at a higher level in the aggregating hierarchy.

4.14.5.3 Inheritable Components

4.14.5.3.1 Overview

The following classes are subject to simple replacement. A directly attached component always overrides an inherited component in the case of instances of these classes.

1. <DRM Access>,
2. <DRM Base Level Of Detail Data>,
3. <DRM_Colour>,
4. <DRM Data Quality>,
5. <DRM Light Rendering Properties>,
6. <DRM Perimeter Data>,
7. <DRM Presentation Domain>,
8. <DRM Rendering Priority Level>,
9. <DRM Rendering Properties>, and
10. <DRM Time Constraints Data>.

The following classes are subject to more complex rules of inheritance:

1. <DRM Classification Data>,
2. <DRM Property Set Index>, and
3. <DRM Image Mapping Function>.

4.14.5.3.2 <DRM Classification Data>

<DRM Classification Data> instances are not inherited in the general case, but only in the specific context of a <DRM Union Of Features> or <DRM Union Of Geometry> instance. The union is used to explicitly distinguish between the cases of a union representing a single environmental object versus the case of a union representing a collection of environmental objects, where in the latter case the <DRM Classification Data> is being shared by the components of the union for efficiency of representation.

In the case of a union representing a single environmental object, the union_reason field will value  CLASSIFIED_OBJECT. In this case, the <DRM Classification Data> instance is not inherited by the components of the union. In the case of a union representing a collection of environmental objects, the union_reason field will have some other value. In this case, the <DRM Classification Data> instance is inherited by the components of the union. If they in turn are union instances, further property inheritance behaviour is determined by their own union_reason field values. If the components of the union are not themselves unions, property inheritance stops at that level for the <DRM Classification Data> instance.

4.14.5.3.2 <DRM Property Set Index>

<DRM Property Set Index> is not inherited itself. Instead, the applicable attribute objects from the referenced <DRM Property Set> are treated as if they replaced the <DRM Property Set Index> for the purposes of inheritance. For each of those attribute objects, the individual, standard inheritance rules for their classes apply.

A <DRM Property Set> may contain some objects that are <DRM Feature> specific and some that are <DRM Geometry> specific. In this case, <DRM Feature> instances only  use the properties that are legal for the <DRM Feature> class, while <DRM Geometry> instances only use the properties that are legal for the <DRM Geometry> class.

The general rule of “lower” components overriding “higher” components still applies. As an extension of that rule, if there is a conflict between a directly attached component and an attribute from a referenced <DRM Property Set> that appears at the same level, the directly attached component overrides the component from the <DRM Property Set>.

4.14.5.3.3 <DRM Image Mapping Function>

At any level, a set of <DRM Image Mapping Function> objects can be attached; they are treated as a group. Each set completely replaces the previous set, even if the set contains only one <DRM Image Mapping Function>. In other words, any object with one or more direct <DRM Image Mapping Function> components will not inherit any <DRM Image Mapping Function> components from its ancestors, but instead will pass on its own direct <DRM Image Mapping Function> components to its components.

4.14.5.3.4 Locations for reference vectors

In general, <DRM Location> is not inherited; it is covered by a special rule specific to <DRM Reference Vector>.

A <DRM Reference Vector> is required to have a specified point of origin. In order for the unit_vector field of a <DRM Reference Vector> to be specified in an SRF, that SRF shall have a compatible vector space structure. Several of the SRFs supported by this part of ISO/IEC 18023 (e.g., geodetic) do not have vector space structure. When a <DRM Reference Vector> is specified in such an SRF, an LTP space is embedded in that non-vector SRF at the vector's point of origin, so that the vector is actually specified inside that LTP space.

If a <DRM Reference Vector> has a directly attached <DRM Location> component, that is its point of origin. However, in many contexts where <DRM Reference Vector> appears in the DRM, the vector can unambiguously inherit a <DRM Location> from the object that aggregates the <DRM Reference Vector> rather than specifying a separate <DRM Location>. The rule for this inheritance, expressed by the constraint 6.2.50 Required Reference Vector location is that, given any object A with a <DRM Location> component (or an ordered list of <DRM Location> components), that object's first <DRM Location> component becomes the default <DRM Location> in the context of the aggregation tree rooted at A.

In the cases of those classes specified by the 6.2.50 Required Reference Vector location constraint, in which multiple <DRM Location> components are present, and inheritance would be ambiguous, a directly attached <DRM Location> is required for the <DRM Reference Vector>.

4.14.5.3.5 < DRM Property Description>

A directly attached <DRM Property Description> component overrides an inherited instance if the “newer” <DRM Property Description> instance applies  to the same envrionmental attribute, as indicated by its meaning field value. Otherwise, both <DRM Property Description> instances apply and are inherited further down in the tree. Thus, two <DRM Property Description> instances conflict only if they apply to the same property.

If a <DRM Property Description> is a component of an object instance A and a <DRM Property Value> with matching meaning is in the component tree rooted at A, that <DRM Property Value> is considered to be qualified by the <DRM Property Value> and <DRM Property Characteristic> components of the matching <DRM Property Description>.

4.14.5.3.6 <DRM Property Table>

A directly attached <DRM Property Table> object overrides an inherited instance if the newer <DRM Property Table> has the same qualified classification. Otherwise, both <DRM Property Table> objects apply and are inherited further down in the tree. Thus, two <DRM Property Table> instances conflict only if they have the same qualified classification (see 4.8.2.2 Qualification).

4.14.5.3.7 <DRM Property Table Reference>

A directly attached <DRM Property Table Reference> instance overrides an inherited instance if both referenced <DRM Property Table> instances have the same qualified classification. Otherwise, both <DRM Property Table Reference> instances apply and are inherited further down in the tree. Thus, two <DRM Property Table Reference> instances conflict only if the referenced <DRM Property Table> instances conflict.

4.14.5.3.8 <DRM Property Value>

A directly attached <DRM Property Value> instance overrides an inherited instance if the newer <DRM Property Value> applies to the same environmental attribute, as indicated by its meaning field value. Otherwise, both <DRM Property Value> instances apply and are inherited further down in the tree. Thus, two <DRM Property Value> instances conflict only if they specify values for the same property.

4.14.5.4 Classes of properties that are not inherited

Property inheritance does not apply to all kinds of property classes. Those classes to which property inheritance does not apply are discussed below, including the reasons why property inheritance does not apply.

Instances of <DRM Citation> cannot be inherited. The <DRM Citation> at the top of any hierarchy specifies the bibliographic citation information for the collection as a whole. Referencing any part of the collection specifically requires its own <DRM Citation>.

Instances of <DRM Keywords> apply only to the object to which they are attached, because the keywords applicable at the level of a hierarchy at which a <DRM Keywords> instance is specified are built up from smaller subsets of keywords derived from lower levels of that hierarchy. Consequently, property inheritance does not apply to instances of <DRM Keywords>.

A <DRM Description> instance is specific to the DRM object that aggregates it, describing the hierarchy as a whole.

<DRM Spatial Extent> instances cannot be inherited due to the bottom-up nature of a <DRM Spatial Extent>.

EXAMPLE A <DRM Environment Root> may cover a <DRM Spatial Extent> of thousands of square kilometres, while one of its <DRM Polygon> instances covers only a square metre or two.

<DRM Responsible Party> instances are not inherited.

4.15 Constructs for presenting data

4.15.1 Overview

The DRM constructs described herein provide mechanisms for specifying the presentation properties of objects in the environment. These presentation properties are typically used by visual and audio systems to provide a graphical and aural representation of environmental objects.

4.15.2 Presentation of coplanar objects

When SEDRIS objects are to be visually rendered, the possibility exists that two or more such objects may potentially overlap, resulting in occlusion issues.

In many cases, if two such SEDRIS objects belong to different branches of an aggregate organization, the organizing principle will provide a means of resolving the conflict. Where an organizing principle is listed that applies to both <DRM Aggregate Feature> and <DRM Aggregate Geometry>, the resolution mechanism specified is understood to apply to both.

1. In the case of SEDRIS objects belonging to different branches of an alternate hierarchy related organization, the semantics of the organization make it clear that two different representations of the same environmental object are being considered, so that the data consumer would render such representations simultaneously at his or her own risk.
2. In the case of <DRM Animation Related Geometry>, different branches represent different frames of the animation, and thus should not be rendered simultaneously.
3. In the case of SEDRIS objects that belong to different branches of a level of detail related organization, such as an instance of <DRM Level Of Detail Related Geometry>, the data consumer's mechanism for handling level of detail is responsible for resolving such issues, and similarly for coarser and finer levels of detail in a <DRM Continuous Level Of Detail Related Geometry>.
4. In the case of <DRM State Related Geometry>, each branch represents a different state, and no two states should be active (i.e., rendered) simultaneously.
5. In the case of <DRM Time Related Geometry>, each branch represents a different time, and no two times should be active (i.e., or rendered) simultaneously.
6. In the case of SEDRIS objects belonging to different branches of spatial organizing principles, such as <DRM Spatial Index Related Geometry>, ideally data would be constructed strictly according to the organizing principle, so that no overlap could occur. However, this strictness is not required. In addition, other organizing principles exist that do not inherently exclude two branches of an organization from being active simultaneously with potentially overlapping data. Furthermore, an organization may potentially have overlapping data within the same branch.

Consequently, the following mechanisms are supplied to allow data providers to resolve potential ambiguities in the rendering of potentially overlapping data.

1. In the case of a <DRM Primitive Geometry> instance for which finer <DRM Primitive Geometry> is nested (e.g., a <DRM Polygon> with subfaces), a <DRM Primitive Geometry> may contain a <DRM Union Of Primitive Geometry> instance as a component to organize such subfaces. This indicates unambiguously that a nesting relationship exists, so that either the coarse or fine representation may be used.
2. In cases where overlap may exist but a nesting relationship is not indicated, <DRM Rendering Priority Level> is recommended. When <DRM Rendering Priority Level> instances are to be used, each <DRM Rendering Priority Level> is assigned to a priority group (indicated by its rendering_group field), and within each such group, rendering priority is assigned as indicated by the rendering_priority field. In case of potential overlap, lower-numbered priority groups are rendered before higher-numbered priority groups, and within a group, lower rendering_priority items are rendered before the higher.
3. Within a <DRM Union Of Geometry> or <DRM Union Of Features>, an ordering_reason field is present. If FIXED_LISTED is specified, this indicates that the order in which the components of the union are specified is to be treated as the rendering order. If LAYERED_HIGH_QUALITY_RENDERING, LAYERED_FASTEST_RENDERING, or VIEWER_RANGE are specified, they are to be interpreted according to their specifications to resolve any conflicts.

4.15.3 Colours and lighting

4.15.3.1 Overview

The apparent colour of an environmental object is determined by both the reflectance properties of the object and the light energy irradiating the object. The DRM constructs used to specify these properties are <DRM Colour> and <DRM Light Source>, respectively.

4.15.3.2 Colours

The DRM supports colours in the CMY, HSV, and RGB colour models. Colour values can be specified for the ambient, diffuse, specular, and emissive properties of an object’s colour characteristics. The colour values are stored in the fields of the concrete subclasses of the <DRM Colour Data> abstract class:

1. <DRM CMY Colour>,
2. <DRM HSV Colour>, and
3. <DRM RGB Colour>.

Objects in the DRM are coloured with instances of the concrete subclasses of <DRM Colour>. A <DRM Colour> is either a <DRM Inline Colour> or a <DRM Colour Index>. A <DRM Inline Colour> instance specifes colour data directly. A <DRM Colour Index> identifies the colour data to be used by indexing into an instance of <DRM Colour Table>.

A <DRM Inline Colour> is composed of one <DRM Primitive Colour>, which is used to aggregate the colour data. Similarly, a <DRM Colour Table> is composed of one or more ordered <DRM Primitive Colour> instances. A <DRM Colour Table> can contain a <DRM Ambient Colour>, a <DRM Diffuse Colour>, a <DRM Specular Colour>, and a <DRM Emissive Colour>. Each of these four classes, in turn, is composed of a <DRM Colour Data>, as described in the beginning of this section, that contains the actual colour values for the ambient, diffuse, specular, and emissive characteristics of the coloured object, respectively.

Both a <DRM Inline Colour> and a <DRM Colour Index> can be composed of a <DRM Presentation Domain> that specifies the set of sensor domains for which the colour should be used. In addition, both a <DRM Inline Colour> and a <DRM Colour Index> can be composed of a <DRM Translucency> that specifies the percentage of light that can pass through the colour. The colour_mapping field of a <DRM Colour> further specifies how the colour is applied to the coloured object, such as the side of the object to which the colour should be applied and how the colour should be combined with a <DRM_Image>, if present. The constraints specified in 6.2.5 Colour mapping constraints for a <DRM_Colour> ensure that this field is appropriately specified.

4.15.3.3 Light sources

A <DRM Light Source> represents a light source in the environment; the apparent size and position of the light source determine which subclass of <DRM Light Source> is used in the representation. The colour of the light emitted by a <DRM Light Source> is explicitly specified, but rather than specifying a <DRM Colour> component for the <DRM Light Source> and constraining it to contain the specific colour information required, a <DRM Light Source> directly specifies <DRM Ambient Colour>, <DRM Diffuse Colour>, and <DRM Specular Colour> components. Further information provided by a <DRM Light Source> is specified by its fields or is specific to the particular subclass being instanced.

The fields of a <DRM Light Source> instance specify the scope to which it applies (apply_to_children), whether it is to be combined with the effects of other <DRM Light Source> instances (override_positional_lights, override_infinite_lights), and whether it is on or off (active_light_value). (In the case of a <DRM Light Source> that is dynamically controlled by a <DRM Light Source Control Link> instance C, C determines whether the <DRM Light Source> is on or off and active_light_value’s original setting is a default state. See the 4.5.13 Constructs for controlling dynamic data for details.)

The remaining information specified by a <DRM Light Source> depends upon the subclass being instanced. <DRM Light Source> has two subclasses: <DRM Infinite Light>, which is concrete, and <DRM Base Positional Light>, which is abstract and has two concrete subclasses of its own, <DRM Positional Light> and <DRM Spot Light>.

A <DRM Infinite Light> is used to represent a light source that, for practical purposes, can be considered infinitely far away from the observer. For such a light source, all light rays emitted from that source can be considered to be parallel, so a <DRM Infinite Light> specifies a <DRM Reference Vector> of vector_type LIGHT_DIRECTION to provide this information. A <DRM Infinite Light> does not specify attenuation factors.

<DRM Base Positional Light> is used to represent light sources that are not at an infinite distance, and which therefore specify a position in space as a <DRM Location 3D>. The field values of a <DRM Base Positional Light> specify a radius of influence and attenuation factors. For its subclass <DRM Positional Light>, the radius of influence indicates a sphere of influence. For <DRM Spot Light>, a cone of influence is specified by a <DRM Lobe Data> component, bounded where it meets the sphere specified by the radius value.

4.15.3.4 Lighting effects

The <DRM Rendering Properties> class contains fields that specify various details of how lighting effects should be handled in order to reproduce results consistent with the local processing environment.

A <DRM Rendering Properties> instance specifies the shading method to be used when evaluating lighting effects on the rendered objects; that is, it specifies the algorithm that should be used to perform lighting calculations in order to achieve the effect intended by the data provider.

In addition to lighting effects information such as presentation domain and recommended lighting algorithm, A <DRM Rendering Properties> instance also specifies further details of visual representation. The style field specfies whether the affected <DRM Geometry> instances are to be rendered in “solid” style, “wireframe” style, or both (solid but showing the wireframe outlines). The side field specifies whether the “front”, “back”, or both sides of the affected <DRM Geometry>  should be rendered, where "front" and "back" are determined by evaluating the surface normal information of the affected geometry.

Instances of <DRM Rendering Properties> can be specified at almost any level of geometric representation in the DRM from the <DRM Environment Root> level to individual geometric primitives. A <DRM Rendering Properties> instance can be specified for a particular presentation domain, such as out-the-window viewing or night vision goggles.

4.15.3.5 Simulating lighting effects

The <DRM Light Rendering Properties> class supports the capability of specifying that a geometric representation appears to emit light, and the apparent characteristics of that light, without requiring the calculation of the environmental effects consequent upon treating the representation as an actual light source.

The active_light_value fields is the master control for a <DRM Light Rendering Properties> instance. It specifies whether or not the lighting effect is to be simulated at the present time (i.e, whether the effect specified by the instance is enabled). A dynamic control mechanism is also provided for the <DRM Light Rendering Properties> class so that the effect may be turned on and off during processing of the environmental data.

The candela_value field specifies the intensity of the simulated light of a <DRM Light Rendering Properties> instance in candelas. The light_extinguishing_range field specifies the distance in metres at which an observer will no longer see the corresponding light-emitting <DRM Geometry> instance. A value of 0,0 for the light_extinguishing_range field indicates that the light is always seen when the light is active regardless of distance.

More specific details of the appearance of such a simulated light are indicated by supplying <DRM Light Rendering Behaviour> instances for the given <DRM Light Rendering Properties> instance. The category of behaviour specified varies according to the subclass of <DRM Light Rendering Behaviour> utilized The types of behaviour include:

1. directional,
2. flashing,
3. moving,
4. rotating,
5. strobing,
6. twinkling, and
7. visible only within a specified volume.

4.15.4 Images and texturing

4.15.4.1 Overview

Images may be used as textures to enhance the visual detail of objects. The DRM supports the use of images with the <DRM Image> class. When used as textures, images are applied to instances of <DRM Geometry> and/or <DRM Feature> as described in 4.15.4.3 Applying images as textures. Images may also be used by themselves as spatial objects as described in 4.15.4.4 Positioning images as spatial objects to provide, for example, geo-specific imagery.

4.15.4.2 Image specification

A <DRM Image> specifies one or more MIP levels of texels, and may be either 2D or 3D. All such imagery resources in a given transmittal are provided as <DRM Image> components of a <DRM Image Library> instance. See 4.5.11 Constructs for sharing data and 4.5.12.3.3 Applying images as textures for how the contents of a <DRM Image Library> are referenced from other contexts in a transmittal.

For a <DRM Image> instance, the number of MIP levels is specified by the value of its level_count field, which is also the size of its mip_extents_array field. Each entry in mip_extents_array specifies the dimensions of the image in the horizontal, vertical, and z directions. (For a 2D image, the size of the z dimension is specified to be 1.)

The structure of the texel data of a <DRM Image> instance is specified by the field values of the <DRM Image> as follows:

1. The image_signature specifies the characteristics of a texel. Each texel characteristics is called a texel component. This determines which of the “bits_of”, “min_value_of”, and “max_value_of” fields of the <DRM Image> instance apply and where those not being used are set to zero. See 5.2.5.22 Image_Signature and <DRM Image> for details of specific image signatures.
2. If the image_signature utilizes colour, the colour_model field specifies the colour model in use.
3. The component_data_type field value specifies the data type of the texel components.
4. The data_is_little_endian determines how individual bytes in the texel data are to be interpreted.

5. The scan_direction and scan_direction_z field values specify how the order of the texel data relates to the ordering of the texels when the <DRM Image> is rendered.

The use of the optional <DRM Image Anchor> component of a <DRM Image> is explained in 4.5.12.3.4 Positioning images as spatial objects. The use of the optional <DRM Property Table Reference> components is described in 5.2.5.22 Image_Signature for the ONE_MATERIAL, TWO_MATERIALS, and THREE_MATERIALS selection values.

4.15.4.3 Applying images as textures

A <DRM Image> is applied to a representation of the environment either as a spatial object (see 4.5.12.3.4 Positioning images as spatial data), or through reference by a <DRM Image Mapping Function>.

A <DRM Image Mapping Function>, as discussed in 4.5.11 Constructs for sharing data, specifies the <DRM Image> being applied as a texture map by means of a one-way association to that <DRM Image>. A <DRM Image Mapping Function> instance specifies the remaining details of how the texture is to be applied to the object(s) being textured, in concert with any applicable <DRM Texture Coordinate> and/or <DRM Tack Point> instances.

The details of how <DRM Image Mapping Function> information is to be combined with colour information, and of how a <DRM Image Mapping Function> may apply modifiers to the texel data to adjust its intensity level, may be found along with other information in the specifications for the respective classes in 6.3 DRM class specifications. Here, the interaction of <DRM Image Mapping Function> with instances of other classes to specify the mapping itself are specified.

A <DRM Image Mapping Function> instance F may specify a projection that is planar, cylindrical, or spherical. In the case of cylindrical or spherical projections, F shall specify a <DRM Image Anchor> component representing the details of the projection, as specified and constrained in 6.2.20 Image mapping functions and texture coordinates. If F is a component of a <DRM Feature>, F shall specify a <DRM Image Anchor> regardless of the type of projection used. However, in the case where F specifies a planar projection and is part of a geometric representation, <DRM Texture Coordinate> instances or <DRM Tack Point> instances may be specified rather than placing a <DRM Image Anchor> on F itself.

Consider a <DRM Image Mapping Function> F specifying a planar projection, lacking a <DRM Image Anchor> component, and referencing a <DRM Image> that does not specify a <DRM Image Anchor> component itself, where F is a component of some <DRM Geometry> G. The <DRM Primitive Geometry> instances in the tree rooted at G shall supply instances of either <DRM Texture Coordinate> or <DRM Tack Point> for the mapping to be fully specified.

<DRM Texture Coordinate> instances appear in the context of <DRM Vertex>, <DRM Point>, and <DRM Tack Point> instances. For a <DRM Primitive Geometry> with <DRM Vertex> components, either the <DRM Primitive Geometry> shall specify <DRM Tack Point> instances, or the <DRM Vertex> instances shall specify <DRM Texture Coordinate> instances. <DRM Tack Point> instances supply a method of mapping a texture to an object that either has no <DRM Vertex> instances (such as a <DRM Ellipse> instance) or for which it is desired that the mapping be ‘pinned’ to the texture using locations other than the vertices.

4.15.4.4 Positioning images as spatial objects

A <DRM Image> may itself directly represent environmental data; for example, raw satellite imagery may be stored as <DRM Image> instances. In such a case, a <DRM Image> may itself have a mapping to a spatial reference frame, independent of any <DRM Image Mapping Function> instances. This information is specified by providing a <DRM Image Anchor> as a component of the <DRM Image>. A <DRM Image Anchor> instance, when specified as a component of a <DRM Image> instance M, indicates that M is specific to the given region in the environment. Such a <DRM Image>, when representing a region on the surface of Earth, may be called a geo-specific image.

When a <DRM Image Anchor> is interpreted as a component of a <DRM Image>, the ordered <DRM Location> components of the <DRM Image Anchor> are interpreted as follows.

1. The first <DRM Location> component specifies the position to which the lower left corner of the <DRM Image> is mapped.
2. The second <DRM Location> component specifies the position to which the upper left corner of the <DRM Image> is mapped.
3. The third <DRM Location> component specifies the position to which the upper right corner of the <DRM Image> is mapped.

The <DRM Location> components of a <DRM Image Anchor> instance are interpreted as the positions of the corners of the given <DRM Image>, not those of the centre of the texels in the corners of the <DRM Image>.

4.15.5 Views

An instance of <DRM Camera Point> specifies a view into the visual representation of a transmittal, by specifying a “camera” and its location, together with its viewing volume and projection.

An instance of <DRM Stamp Behaviour> specifies how a geometry representation shall rotate with respect to a viewer’s location. Such an instance is attached as a component of a <DRM Geometry Hierarchy> instance. The <DRM Geometry Hierarchy> instance rotates about the x, y and/or z axes of the applicable SRF within the specified angular limits. The center of rotation is specified by the <DRM Location 3D> instance that is a component of the <DRM Stamp Behaviour> instance. Both clockwise and counter-clockwise angular limits may be specifed for each axis independently. A sentinel value for infinity shall specify unlimited rotation.

4.15.6 Sound

4.15.6.1 Overview

Sound in the DRM is comprised of sound resources and sound instances. Sound resources provide the actual digitized acoustic phenomenon while sound instances provide the information necessary to control the presentation of the sound resource.

4.15.6.2 Sound sources

A sound resource is represented in the DRM by an instance of <DRM Sound>. All such sound resources in a given transmittal are provided as <DRM Sound> components of a <DRM Sound Library> instance. See 4.5.12.5.3 Sound presentation for a description of how the contents of a <DRM Sound Library> may be referenced from other contexts in a transmittal.

A <DRM Sound> instance does not itself contain the digitized sound data; instead, its sound_urn field value specifies a URN indicating where that data is located. <DRM Sound> does specify the following:

1. a meaningful short name for the sound;
2. the duration of the sound, the amount of time in seconds that it takes for the sound to be played once;
3. the sampling_rate of the sound, the number of samples per second that were recorded when the sound data was captured;
4. the bits_per_sample (also known as “sample size” or “quantization”); and
5. a string specifying the encoding and compression schemes used, if applicable.

The meaningful short name is not necessarily unique in the context of a given <DRM Sound Library>. If a fuller text description is desired, a <DRM Sound> may have a <DRM Description> component.

Apart from metadata components, a <DRM Sound> may have a <DRM Classification Data> component, specifying the environmental entity being represented by the sound resource in question.

4.15.6.3 Sound presentation

4.15.6.3.1 Overview

A <DRM Sound> is not referenced directly by a geometric or feature representation; that is, a <DRM Sound> is always a component of a <DRM Sound Library>, and never a component of a <DRM Geometry Hierarchy> or <DRM Feature Hierarchy>. Instead, a <DRM Geometry Hierarchy> or <DRM Feature Hierarchy> may have a collection of <DRM Sound Instance> components.

A <DRM Sound Instance> represents a single case of the existence of a sound; that is, a reference to a <DRM Sound> in a given context, including any specialization unique to that case. The specialization that is possible includes:

1. specifying whether the <DRM Sound Instance> is audible only within a specific area or region,
2. the time interval for which the sound is active, and
3. a dynamic control mechanism to supply finer control over whether the sound is active and under what conditions.

4.15.6.3.2 Spatial extent

A <DRM Sound Instance> may represent spatialized audio, region-based audio, or environmental audio, depending on the components specified for the <DRM Sound Instance>. Spatialized audio is that for which an explicit location of the sound source is specified. Region-based audio is that for which a boundary of the effect of the sound is specified without explicitly specifying the position of the sound source itself. Environmental audio specifies a sound that is heard throughout a given environment without being bound to a specific position or region. Each of these concepts is discussed in turn.

If a <DRM Sound Instance> SI has a <DRM Location 3D> component L, SI is said to represent spatialized audio. That is, SI indicates that the source of the sound is considered to be located at L. If SI also has a <DRM Fade Range> component F, F is interpreted as follows. A <DRM Fade Range> specifies the range in metres from L at which the sound begins to fade away, and that at which it is completely inaudible. If SI also specifies a <DRM Perimeter Data> or <DRM Sound Volume>, they shall be specified so that L is the centre of the region thus specified. If no boundaries are specified, the data consuming organization is free to interpret the <DRM Sound Instance> based upon its own organizational policy regarding spatialized audio.

If a <DRM Sound Instance> SI specifies a <DRM Sound Volume> and does not specify a <DRM Location 3D>, SI represents region-based audio, where the sound is detectable within the volume of space thus specified, but not outside that volume. (Note that region-based audio is not localized within the given region, since a specific position for the source of the sound is not specified.) If SI also has a <DRM Fade Range> component F, the distances specified by F are considered to be relative to the centre of the <DRM Sound Volume>. If SI specifies no <DRM Fade Range>, audibility is cut off without gradual attenuation at the boundary of the volume.

If a <DRM Sound Instance> SI specifies a <DRM Perimeter Data> and does not specify a <DRM Location 3D>, SI represents environmental audio, where the sound is detectable within the perimeter of the environment thus specified, but not outside that environment. Environmental audio is not localized within the given environment, since a specific position for the source of the sound is not specified. If SI also has a <DRM Fade Range> component F, the distances specified by F are considered to be relative to the centre of the <DRM Perimeter Data>. If SI specifies no <DRM Fade Range>, audibility is cut off without gradual attenuation at the perimeter.

4.15.6.3.3 Activation

A <DRM Sound Instance> specifies an active_sound_value flag as one of its fields, indicating the default state of the sound; i.e.,  whether it is “on” or “off”. A <DRM Sound Instance> may be “off” if a control mechanism is specified that activates the <DRM Sound Instance> under specific conditions. The most powerful method provided for such control is <DRM Sound Instance Control Link>, described in 4.16 Constructs for controlling dyanmic data.

Another method involves specifying <DRM Time Interval> components for a given <DRM Sound Instance>. If <DRM Time Interval> components are so specified without a <DRM Sound Instance Control Link>, the sound shall be active only during the time period(s) specified.

4.15.7 Labels

4.15.7.1 Overview

A <DRM Label> exists to tie an instance of <DRM Text> or <DRM Symbol> to a <DRM Feature>, possibly to a specific <DRM Location> within that <DRM Feature>, corresponding to the concept of annotating a map with text or symbols.

4.15.7.2 Text

An instance of <DRM Text> specifies some textual information, together with formatting information specifying how it is to be rendered (such as the font), to be used to label the given <DRM Feature> if it is visually rendered, as on a 2D map or display.

4.15.7.3 Symbols

An instance of <DRM Symbol> specifies a pictograph in a standard symbology system, to be used to label the given <DRM Feature> if it is visually rendered, as on a 2D map or display. The symbol_urn field specifies the URN at which the actual pictograph data is to be found.

4.16 Constructs for controlling dynamic data

4.16.1 Introduction

Using  <DRM Control Link>s can be applied to a wide range of problems related to representing control over the values of fields and states of DRM objects, as well as representing the behaviour of such control.

This DRM mechanism can be used in transmittals needing a mechanism to allow a consuming system to dynamically control objects within a transmittal. The need for this control extends beyond extracting individual <DRM Model>s for use as moving models, or objects that are moved through or within the parent transmittal; it includes the need to identify and control the state of objects that are part of the environment that have dynamic behaviour. Examples of these objects include:

• moving objects, e.g. wind socks, rotating beacons,
• objects that change appearance dynamically, e.g. with changing radiance,
• destructible objects, e.g. bridges, buildings,
• the thermal energy of an automobile as it starts up, and
• tank gun and turret.

This mechanism is also to be used to represent how the behaviour or state of one object affects other objects in a transmittal. Examples of such objects include:

• the relationship of the rotation of various gears in a gear system, and
• the relationship of the tail rotor rotation to the main rotor rotation on a helicopter.

Additionally, this mechanism provides support for representing instances of <DRM Model> in which some of the attributes of the <DRM Model> instances change from instance to instance. This type of <DRM Model> is sometimes referred to as a “smart instance” or “basis set”. This type of model includes:

• object clusters (e.g., trees) in which the elevation of each object shall reflect the elevation of the terrain surface below the object;
• generic objects  (e.g., houses) that may have different colours in different instances; and
• objects (e.g., buildings and bridges) in which the vertices representing polygons that “touch” the terrain are required to conform to the terrain without distorting the remaining vertices so that the object is “level”.

4.16.2 Control links and expressions

4.16.2.1 Overview

The concept behind control links is that the abstract class <DRM Control Link> provides a connection between <DRM Expression> trees and the fields of other SEDRIS objects, called target objects. For each class of target object, there shall be a matching, specialized subclass of <DRM Control Link>, the specification of which states how its ordered <DRM Expression> components are used to determine the values of the fields of the target object (called target fields). The target object shall aggregate the specialized <DRM Control Link>.

In general, a specialized <DRM Control Link> will contain at least one field, called a link field, for each field in the target object. The link field is a 1-based index into the ordered list of <DRM Expression> components, and is used to select the specific <DRM Expression> that controls the value of the target field. The specialization may also contain "constraint" fields that are used to constrain the values of the target field. These constraint fields are indexes into the ordered list of <DRM Expression> components.

<DRM Expression> is an abstract class used to represent places in a transmittal where the consuming system is required to perform an evaluation in order to get the exact value of a target field. A <DRM Expression> tree is composed of other <DRM Expression> trees, nesting to an arbitrary level. Together, the set of <DRM Expression> trees connected to a <DRM Control Link> specifies the desired relationship and behaviour of controlling inputs to values that will be applied to the fields of other SEDRIS objects (called 'target objects' and 'target fields'). The application of <DRM Expression> instances to target fields is specified by a specialization of the <DRM Control Link> class that associates the values of the <DRM Expression> instances to the fields of the target object(s).

For example, the <DRM State Related Geometry> class has an optional relationship with the <DRM State Control Link> subclass of <DRM Control Link>. This specialization specifies which of the <DRM State Control Link>'s ordered <DRM Expression> components are to be applied to the fields of the <DRM State Related Geometry>.

There are three subclasses of <DRM Expression>: <DRM Literal>, <DRM Variable>, and <DRM Function>.

4.16.2.2 The <DRM Literal> and <DRM Variable> classes

A <DRM Literal> is the simplest <DRM Expression> it is merely a constant value.

A <DRM Variable> is a surrogate for a value that will be supplied by way of an <DRM Interface Template>. <DRM Interface Template>, which is aggregated by <DRM Environment Root> and <DRM Model>, specifies the “hooks” that may be controlled within the parent <DRM Environment Root> or <DRM Model> by the consuming system. An <DRM Interface Template> is associated with one or more <DRM Variable> instances. <DRM Geometry Model Instance> and <DRM Feature Model Instance> aggregate <DRM Expression> components, indicating their relationship with the appropriate <DRM Interface Template> (that of the <DRM Model> being instanced).

For an instance of a concrete subclass of <DRM Variable>, the meaning is specified by an Element_Type value, and specifies the semantic meaning of the set of data values bound to that <DRM Variable>. Since any subclass of <DRM Variable> may represent a numeric quantity, the <DRM Variable> class has EDCS Unit and EDCS Scale fields with appropriate constraints (see 6.2.58 Variable meaning constraints). <DRM Variable> instances are not constrained to use Variable_Code enumerants as their meanings. Variable_Code instances most frequently occur within the context of <DRM Variable> instances, but the converse is not true. <DRM Variable> instances often represent environmental properties such as WIND_SPEED.

Essentially, a <DRM Variable> exists to connect an <DRM Interface Template> to points within <DRM Expression>s where outside control may be exerted.

For a <DRM Variable> contained within a <DRM Model>, evaluation is valid only for a specific model instance. The value is determined by an <DRM Expression>s aggregated by the specific <DRM Feature Model Instance> or <DRM Geometry Model Instance>.

For <DRM Variable> instances contained within an <DRM Environment Root>, evaluation can only be performed within the context of values that shall be supplied by the consuming system.

4.16.2.3 The <DRM Function> class

4.16.2.3.1 Overview

<DRM Function> instances are used as <DRM Expression>s for which the value is determined by evaluating arguments and passing them through some function. A <DRM Function> aggregates its arguments as a set of ordered <DRM Expression> components, where the exact interpretation of each argument is specified by the specific function. The arguments, together with the specification of the function, determine the value "returned" by the <DRM Function>. The abstract class <DRM Function> has two concrete subclasses: <DRM Predefined Function> and <DRM Pseudo Code Function>.

4.16.2.3.2 The <DRM Predefined Function> class

The <DRM Predefined Function> class specifies the function from the Predefined_Function selection data type. These functions fall into various categories as shown in Table 4.4:

The number and type of arguments required for a <DRM Predefined Function> therefore depends upon the function. The arguments of a <DRM Predefined Function> are specified by attaching instances of <DRM Expression> as components of the <DRM Predefined Function> itself. The components of a <DRM Predefined Function> are always its arguments, and are ordered so that the assignment of each to its specific corresponding argument is unambiguous. A corollary is that <DRM Predefined Function> instances that require no arguments have no components. A further corollary is that the number of <DRM Expression> components for a <DRM Predefined Function> instance shall not exceed the number of arguments.

4.16.2.3.3 The <DRM Pseudo Code Function> class

<DRM Pseudo Code Function> is used to represent functions that are too complex to use <DRM Expression> trees, or that require looping, branching, or other complex operations. These instances contain fields that describe the desired behaviour in human-readable form.

Instances of <DRM Pseudo Code Function> are used to represent functions that are too complex to use <DRM Expression> trees. These include:

1. functions that require looping,
2. functions that require branching, and
3. user-defined pseudo-code or code fragments.

These instances contain fields that describe the desired behaviour in human-readable form.

The reader is asked to keep in mind that while any valid <DRM Expression> can be converted into executable code or structures that can be directly used by a consuming system, most systems will not use them that way. Currently, most consuming systems require that an <DRM Expression> be re-coded into the consuming functions. For complex functions, pseudo-code may be easier to convert.

4.16.3 <DRM Control Link> subclasses that turn on and off

4.16.3.1 <DRM Light Source Control Link>

<DRM Light Source Control Link> provides control over the active_light_value field of a <DRM Light Source>. This allows the consuming system to turn the <DRM Light Source> on and off at will.

4.16.3.2 <DRM Light Rendering Properties Control Link>

<DRM Light Rendering Properties Control Link> provides control over the active_value and candela_value field values of the target <DRM Light Rendering Properties> instances. This allows the user to control whether the target is “on” or “off”, and if it is on, how bright it is. In addition, if the user allows the candela_value field to vary, <DRM Light Rendering Properties Control Link> can specify constraints on the upper and lower limits of the candela value so that there are limits on the maximum and/or minimum brightness. The user is not required to provide control over all four fields. If any of the link fields is zero, the corresponding target field is not controlled.

4.16.3.3 <DRM Sound Instance Control Link>

<DRM Sound Instance Control Link> provides control over the active_sound_value field of a <DRM Sound Instance>. This allows the consuming system to turn the <DRM Sound Instance> on and off at will.

4.16.4 <DRM State Control Link>

4.16.4.1 Overview

A state-related aggregation represents something that can assume multiple states. Each branch of the aggregation represents a particular state. The state-related aggregation object itself specifies the state being described with its state_tag field. The state is one of a special set of EDCS Attributes that are designated as “state applicable”. Each branch of the aggregation has a <DRM State Data> link object, specifying the value of the state associated with that branch.

4.16.4.2 Applying <DRM State Control Link> to a <DRM State Related Geometry>

Consider a specific building represented by a <DRM State Related Geometry> instance. The data provider in this example has chosen to model four damage states: 0% damaged, 25% damaged, 50% damaged, and 100% damaged (totally destroyed) as shown in Table 4.5.

This indicates that the 'default' state of the aggregation is 0% damage, that is, completely undamaged. The branches' <DRM State Data> link objects have the possible field values (meanings given in the bottom row) shown in Table 4.6.

Generally speaking, any state-related aggregation should be produced with an appropriate <DRM State Control Link> component. Consequently, the building example needs a <DRM State Control Link> to allow the use of states other than the default of 0% damage as shown in Table 4.7.

The <DRM State Control Link> component controls the active_state_value by providing a connection between it and the controlling <DRM Expression>, so that the active_state_value changes to specify which branch of the aggregation is currently active. Since active_state_value is the only controlled field in a state-related aggregation, the <DRM State Control Link> should have exactly one <DRM Expression> component, and therefore its expression_index field value would be one.

In the example shown in Table 4.8, the <DRM Expression> is a <DRM Variable>, so that whatever value is plugged into the <DRM Variable> when the <DRM State Related Geometry> is instanced is then fed into the active_state_value.

Consider a specific building represented by a <DRM State Related Geometry> instance. The data provider in the example shown in Table 4.9 has chosen to model four damage states: 0% damaged, 25% damaged, 50% damaged, and 100% damaged (totally destroyed).

This indicates that the “default” state of the aggregation is 0% damage, that is, completely undamaged. The branches' <DRM State Data> link objects have the field values (meanings given in the bottom row) shown in Table 4.10.

Generally speaking, any state-related aggregation should be produced with an appropriate <DRM State Control Link> component. Consequently, the building example needs a <State Control Link> to allow the use of states other than the default of 0% damage.

The <DRM State Control Link> component controls the active_state_value by providing a connection between it and the controlling <DRM Expression>, so that the active_state_value changes to specify which branch of the aggregation is currently active. Since active_state_value is the only controlled field in a state-related aggregation, the <DRM State Control Link> should have exactly one <DRM Expression> component, and therefore its expression_index field value would be one as shown in Table 4.11.

In the example in Table 4.12, the <DRM Expression> is a <DRM Variable>, so that whatever value is plugged into the <DRM Variable> when the <DRM State Related Geometry> is instanced is then fed into the active_state_value.

Suppose that a value of 25% is supplied to the <DRM Variable>. The aggregate then changes state to 25% damage. Then more damage is done, so that the damage is updated to 45%. This presents a problem, because the data provider has specified each branch with a single matching value, and 45% is not covered by any of the branches. At this point, the mismatch_behaviour of the <DRM State Control Link> comes into play. Since its value is LAST, the aggregation will remain in the 25% damage state.

There are two other possible choices for mismatch_behaviour, but they are not appropriate for this example. DEFAULT would have reset the aggregate to its default state (that provided by the original unmodified active_state_value), namely, 0% damage. The effect would be that 45% damage would magically appear to return the building to its intact state, as for that matter, would 99% damage, or any other value not covered by the branches of the aggregation. The other possible choice, NONE , acts as an “off” state. The building would seem to disappear completely if none of the branches matched, then reappear when a matching value occurred. If that had been specified, 5% damage would make the building disappear from sight, but 25% damage would make it reappear, making life rather bizarre for the end user.

4.16.5 Customizing or dynamically changing appearance

4.16.5.1 <DRM Control Link> subclasses for the subclasses of <DRMColour Data>

<DRM CMY Colour Control Link>, <DRM HSV Colour Control Link>, and <DRM RGB Colour Control Link> serve exactly the same purposes for their respective colour models. An understanding of the operation of any of the three is an understanding of the principles underlying the operation of all three. Consequently, only the operation of <DRM RGB Colour Control Link> will be described, with the understanding that the explanation applies to the other two classes in principle.

<DRM RGB Colour Control Link> provides control over the red, green, and blue fields of the target <DRM RGB Colour> instances. A data provider is not required to provide control over all three fields. The target field is not controlled if any of the link fields within a <DRM RGB Colour Control Link> instance is zero.

<DRM RGB Colour> instances within the context of a <DRM Colour Table> shall not have <DRM RGB Colour Control Link> components, because a <DRM Colour Table> does not provide an <DRM Interface Template> to allow values to be supplied for <DRM Variable> instances. Data consumers need only concern themselves with <DRM RGB Colour Control Link> instances in the context of <DRM Model> and <DRM Environment Root> instances, and even in that case primarily with the former rather than the latter.

A data provider may wish to provide control over the colour of a <DRM Model>, so that every <DRM Geometry Model Instance> of that <DRM Model> can be given a different colour, allowing the user of the <DRM Model> to vary the appearance of model instances without being forced to replicate many <DRM Model> instances that differ only in colour. As another example, a <DRM Model> representing a car may be designed for an environment in which thermal colours are a consideration. In this case, the user might need the ability to change the colour of the car dynamically, as the engine heats up from a cold start or as the engine cools down after being shut off.

4.16.5.2 <DRM Translucency Control Link>

<DRM Translucency Control Link> provides control over the translucency_value field of a <DRM Translucency> instance. This allows such visual effects as fading in puddles based on the precipitation rate.

4.16.5.3 <DRM Texture Coordinate Control Link>

<DRM Texture Coordinate Control Link> provides control over the s and t fields of a <DRM Texture Coordinate>. The producer is not required to provide control over both fields. The target field is not controlled if any of the link fields within a <DRM Texture Coordinate Control Link> instance (s_expression_index or t_expression_index ) is zero.

4.16.6 <DRM Control Link> subclasses for table indices

4.16.6.1 <DRM Property Set Index Control Link>

<DRM Property Set Index Control Link> provides control over the index field value of the target <DRM Property Set Index> instances.

EXAMPLE The appearance of a tree canopy varies according to the season of the year, so a data provider may choose to provide the ability to apply different texture maps and colours to a representation of a tree canopy to represent its appearance in different seasons. This can be achieved by providing an <DRM Property Set Table> instance containing a different <DRM Property Set> instance for each season of the year. Each <DRM Property Set> instance specifies appropriate <DRM Colour> and <DRM Image Mapping Function> instances. The aggregate representing the tree canopy has a <DRM Property Set Index> component that, in turn, has a <DRM Property Set Index Control Link> component. The <DRM Property Set Index> index field may then be used to select the appropriate <DRM Property Set> for a given time of year.

4.16.6.2 <DRM Colour Index Control Link>

<DRM Colour Index Control Link> provides control over the index and intensity_level fields of the target <DRM Colour Index> instances. A data provider is not required to provide control over both field values. The target field is not controlled if any of the link fields within a <DRM Colour Index Control Link> instance is zero.

4.16.6.3 <DRM Property Table Reference Control Link>

<DRM Property Table Reference Control Link> provides control over theindex_on_axis field of the target <DRM Property Table Reference> instances. This allows different n-1 dimensional “slices” of the n-dimensional <DRM Property Table> that is referred to by a given target <DRM Property Table Reference> instance to be selected.

EXAMPLE Consider a <DRM Polygon> instance that specifies the electromagnetic properties of its surface material by a <DRM Property Table Reference> component. If the <DRM Property Table Reference> instance has a <DRM Property Table Reference Control Link> instance, its index_on_axis field value can be changed at will.

4.16.7 <DRM LSR Location 3D Control Link>

<DRM LSR Location 3D Control Link> provides control over the x, y, and z fields of the coordinate fields of the target <DRM LSR Location 3D> instances. Data providers are not required to provide control over all three fields. The target field is not controlled if any of the link fields within a <DRM LSR Location 3D Control Link> (x_expression_index, y_expression_index, or z_expression_index) is zero.

EXAMPLE Consider a <DRM LSR Location 3D> in a <DRM Model> representing a building, where the location represents a point at the foundation of the building. In this case, the data provider wishes to be able to conform each instance of the <DRM Model> to the terrain on which it is instanced, so that the bottom of the building rests on the terrain, regardless of whether the terrain is flat or hilly. The <DRM LSR Location 3D> is provided with an <DRM LSR Location 3D Control Link> that specifies zero for the x and y values of the target, but a controlling <DRM Variable> for the z value.

4.16.8 <DRM Reference Vector Control Link>

<DRM Reference Vector Control Link> provides control over the unit_vector field values of the target <DRM Reference Vector> instances. Data providers are not required to provide control over all three entries of the unit vector. The target field is not controlled if any of the link fields within a <DRM Reference Vector Control Link> instance (v0_expression_index, v1_expression_index, and v2_expression_index) is zero.

One possible use of a <DRM Reference Vector Control Link> is to specify the normal vector of a <DRM Polygon> instance. Another possible use is to control a <DRM Reference Vector> of type LIGHT_DIRECTION, to allow the user to control the direction of the light.

4.17 Metadata

4.17.1 Overview

Metadata can exist at a variety of levels within a transmittal hierarchy, as deemed appropriate by the data producer. Certain metadata is a required part of specific DRM classes.

In the DRM, classes that represent metadata provide functionality in one of two categories:

1. metadata provided, in compliance with ISO 19115 (see 2.[I19115]), solely to allow a human user to make decisions about the information being described, or
2. provision of “summary” metadata, to allow a data provider to describe the structure, contents, and patterns of usage in a transmittal.

4.17.2 Classes derived from ISO 19115

4.17.2.1 Overview

The “human-oriented” metadata classes of the DRM were designed to comply with the ISO standard for geospatial metadata as specified in ISO 19115 (see 2.[I19115]). Instances of these classes are intended to provide human-readable descriptions of various characteristics of the data sets represented by the objects of which they are components. The meanings of these fields are as specified in ISO 19115.  This part of ISO/IEC 18023 does not redefine the meanings of the fields, but instead uses a subset of the fields specified in ISO 19115 within the metadata DRM classes within this part of ISO/IEC 18023.  As a result, there is a correspondence between the DRM classes in this part of ISO/IEC 18023 with their field elements and the data elements in ISO 19115.  This part of ISO/IEC 18023 does not maintain the organization between data elements and data class elements described in ISO 19115.

4.17.2.2 Contact information

The <DRM Responsible Party> class corresponds to the data element CI_ResponsibleParty of ISO 19115; the Mandatory Metadata constraint specifies the required information that shall be provided in its field values to ensure such correspondence.  The following is the listing of the field elements of the <DRM Responsible Party> and the corresponding ISO 19115 data elements:

1. person corresponds to the individualName data field of CI_ResponsibleParty;
2. position corresponds to the positionName data field of CI_ResponsibleParty;
3. organization corresponds to the organisationName data field of CI_ResponsibleParty;
4. address corresponds to the address data class of CI_ResponsibleParty, represented by an instance of the Address data type to encompass the data fields deliveryPoint, city, administrativeArea, postalCode, and country in data class element CI_Address;
5. voice_phone and fax_phone correspond to data class element CI_Telephone data elements voice and facsimile;
6. tdd_tty_phone has no correspondence in ISO 19115;
7. email_address corresponds to the electronicMailAddress data element in data class element CI_Address;
8. web_site corresponds to data element linkage of data class element CO_OnLineResource;
9. hours_of_service and other fields correspond respectively to hoursOfService and contactInstructions of the data class element CI_Contact; and
10. role_code consists of an instance of the ISO 19115 CI_RoleCode data type.

4.17.2.3 Citation

The <DRM Citation> class corresponds to data class element CI_Citation of ISO 19115. The title field shall be provided with information, in compliance with the 6.2.27 Mandatory Metadata constraint, as well as at least one entry in the originators field. The following is the listing of the field elements of the <DRM Citation> class and the corresponding ISO 19115 data elements:

1. title corresponds to the data element title of data class element CI_Citation;
2. edition corresponds to the data element edition of data class element CI_Citation;
3. responsible_party corresponds to the data element citedResponsibleParty of data class element CI_ResponsibleParty, but is represented by an instance of the Contact_Information data type to provide complete contact information;
4. series_name correspdonds to the data element name of data class element CI_Series;
5. issue_id corresponds to data element issueIdentification of data class element CI_Series; and
6. other corresponds to data element otherCitationDetails of data class element CI_Citation.

The <DRM Spatial Extent> class corresponds to ISO 19115 data element EX_GeographicBoundingBox, specifying the geographic areal domain of a data set. <DRM Spatial Extent> specifies a bounding rectangle (or parallelepiped, if three-dimensional <DRM Location> instances are used) within which all position information in the data set being thus described shall fall.

The DRM mechanisms for providing time-related information serve more than one purpose. As well as providing human-oriented metadata, these mechanisms are used as part of the time-related organizing mechanism. See 4.13.12 Time for details.

4.17.2.4 Description

The <DRM Description> class corresponds to the data class element MD_Identification of ISO 19115 (see 2.[I19115]) and is constrained by 6.2.27 Mandatory Metadata to, at a minimum, provide information in its abstract section. The following is the listing of the field elements of the <DRM Description> class and the corresponding ISO 19115 MD_Identification data elements (see 2.[I19115]):

1. abstract corresponds to data element abstract.
2. purpose corresponds to data element purpose.

4.17.2.5 Data quality information

The <DRM Data Quality> class corresponds to the data class element DQ_Element of ISO 19115 used to provide a general assessment of the quality of the data set being described. The following is the listing of the field elements of the <DRM Data Quality> class and the corresponding ISO 19115 data elements:

1. fictional is of data type Boolean and has no equivalent in DQ_Element.

2. property_accuracy is of data type Data_Quality_Element and corresponds to the date element DQ_QuantativeAttributeAccuracy.
3. logical_consistencyis of data type Data_Quality_Element and corresponds to the data element DQ_LogicalConsistency.
4. completeness is of data type Data_Quality_Element and corresponds to the data element DQ_Completeness.
5. absolute_horizontal_positional_accuracy is of data type Data_Quality_Element and corresponds to the data element DQ_AbsoluteExternalPositionalAccuracy.
6. relative_horizontal_positional_accuracy is of data type Data_Quality_Element and corresponds to the data element DQ_RelativeInternalPositionalAccuracy.
7. absolute_vertical_positional_accuracy is of data type Data_Quality_Element and corresponds to the data element DQ_AbsoluteExternalPositionalAccuracy.
8. relative_vertical_positional_accuracy is of data type Data_Quality_Element and corresponds to the data element DQ_RelativeInternalPositionalAccuracy.

The lineage information of ISO 19115 in data element LI_Lineage corresponds to the <DRM Lineage> class in the DRM and may contain instances of <DRM Source> and/or <DRM Process Step>. A <DRM Source>, representing information about a particular data source (whether an original or derived data source), has a <DRM Citation> component to refer to the source data set, and a <DRM Time Interval> component specifying the time period for which the source data was applicable. The description, scale, and contribution information about the data source is represented directly in the fields of the <DRM Source> class itself.

A <DRM Process Step> instance, describing a single processing step during the derivation of the data set being described, may be associated to any applicable <DRM Source> instances via appropriate <DRM In Out> link objects that indicate whether each <DRM Source> was an input or output of the <DRM Process Step>. The <DRM Process Step> class provides a human-readable description of the process directly in its own fields, as well as a mandatory <DRM Absolute Time Point> component specifying the date (and, optionally, time) at which the process was performed. A <DRM Process Step> may also specify a <DRM Responsible Party> for the process.

4.17.2.6 Keywords

The <DRM Keywords> class corresponds to the data element MD_Keyword of ISO 19115, specifying a keyword_count and keyword_array as fields, where 6.2.27 Mandatory Metadata constrains the data provider to provide at least one entry in the array. Each entry of keyword_array is specified as a Keyword_Structure that specifies a Keyword_Type_Code, encoding the type of information provided by the keyword_list field within the structure, as well as a thesaurus field. The thesaurus field may be set to NONE if no authoritative source is being cited for the keywords. The keyword_list of an individual Keyword_Structure contains at least one keyword; if multiple keywords are provided, they shall be in the form of a semicolon-separated list. The keyword_array corresponds to both the data element keyword in MD_Keywords and the MD_KeywordTypeCode list.