Part 1:  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. Each entry in the table of contents contains a hyperlink to the corresponding subclause. Clicking on the “⇒” symbol that precedes some entries will toggle the display of lower level subclause entries.

4.1.2 Introduction

This clause describes the concepts of this International Standard and how they interact with each other to provide cohesive and consistent data representation. Provision is made for representing data to the level of detail necessary to support a variety of information technology applications that will use or depend on environmental data using the concepts specified in this part of ISO/IEC 18023.

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 specifies the notation used in this part of ISO/IEC 18023.

Table 4.2 — Document conventions and notation

DRM class names are used in the text either as nouns or as adjectives. When used as nouns, DRM class names refer only to the DRM class. When used as adjectives, DRM class names modify the noun to which they apply. Except when that noun is “class” or “subclass”, the noun refers to an instance of that class. If the DRM class being used as an adjective, the noun refers to an instance of a concrete subclass of that class.

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. This part of ISO/IEC 18023 permits representations of environmental data 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, representations of environmental data shall contain an appropriate integration of terrain, ocean, atmosphere, and space domain data about a region of interest. This part of ISO/IEC 18023 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).

This part of ISO/IEC 18023 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.

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

EXAMPLE 1  soil and subsurface characteristics

EXAMPLE 2  surface elevations

EXAMPLE 3  vegetation

EXAMPLE 4  roads

EXAMPLE 5  signs

EXAMPLE 6  vehicles

EXAMPLE 7  buildings with interiors and included objects

The terrain also includes inland waters, as well as the ocean bottom (e.g., bathymetry and sediment types).

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

EXAMPLE 8  wave heights

EXAMPLE 9  depth pressure

EXAMPLE 10  vessels

EXAMPLE 11  buoys and impediments to navigation

EXAMPLE 12  temperature

EXAMPLE 13  salinity gradients

EXAMPLE 14  acoustic phenomena

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

EXAMPLE 15  particulate and aerosol data on haze, dust, and smoke

EXAMPLE 16  clouds

EXAMPLE 17  atmospheric pressure

EXAMPLE 18  wind

EXAMPLE 19  precipitation

EXAMPLE 20  humidity

EXAMPLE 21  obscurants

EXAMPLE 22  contaminants

EXAMPLE 23  nuclear/biological/chemical effects

EXAMPLE 24  radiated energy

EXAMPLE 25  temperature

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

A representation of the space domain includes data on the location and characteristics of regions beyond the specified upper boundary of a planetary atmosphere.

EXAMPLE 27  stars and the interstellar medium

EXAMPLE 28  natural or artificial celestial objects

EXAMPLE 29  neutral and charged atomic and molecular particles and their optical properties

EXAMPLE 30  solar winds

EXAMPLE 31  space weather

EXAMPLE 32  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 representations of environmental data. This part of ISO/IEC 18023 provides the common framework for meeting this challenge.

4.2.2 Representational capability

4.2.2.1 Overview

This part of ISO/IEC 18023 enables environmental data to be modelled to meet the requirements of applications. The Data Representation Model (DRM) supports the creation of data models that allow an application to completely and accurately represent environmental data while ensuring that such data can be understood and used by another application.

The DRM supports a wide variety of concepts including:

1. geometry,
2. features,
3. topology,
4. metadata,
5. EDCS attributes (EAs) (see 6 EDCS attributes of ISO/IEC 18025),
6. EDCS classifications (ECs) (see 5 EDCS classifications of ISO/IEC 18025),
7. relationships among data, and
8. the organization of data.

4.2.2.2 Multiple representation requirements

The same environmental object may be represented in the DRM in different ways for different purposes.  These purposes include:

1. data interchange,
2. simulation, and
3. storage for later processing.

EXAMPLE 1  A building may be represented as:

1. a collection of facets describing its physical shape,

2. ECs and EAs specifying its purpose or function, and/or

3. its position, how it obscures line of sight, and/or other characteristics established by application requirements.

EXAMPLE 2  A bridge may be represented in multiple ways for different purposes:

1. If route planning and transportation of goods is the purpose, the location of the bridge and its traffic patterns may be represented.

2. If the use of the underlying waterway by vessels and boats is the purpose, its height above the surface of the water or whether the bridge deck can be raised may be represented.

By permitting multiple representations, the DRM allows sufficient expressive capability for different applications and purposes without requiring that all applications be able to understand all representations.

4.2.2.3 Representational polymorphism

The ability to support multiple forms of representations is called representational polymorphism. Polymorphism (from the Greek meaning “having multiple forms”) is the ability to allow multiple forms. Representational polymorphism allows a variable, function, or object to have more than one form. The DRM supports representational polymorphism by specifying DRM classes that allow multiple, independent representations of environmental data to be created and the relationships among these representations to be expressed.

EXAMPLE 1  A road may be represented using:

1. a DRM class specifying a linear feature, and

2. another DRM class specifying a series of polygons.

Neither representation changes the nature of the road. Each reflects a different application’s requirements for representing a road.

EXAMPLE 2  A cloud may be represented using:

1. a DRM class specifying a 3D grid of moisture content, using a DRM class specifying a volumetric feature, and

2. a DRM class specifying an areal feature of a cloudy region within a weather map.

Neither representation changes the nature of the cloud. Each reflects a different application’s requirements for representing a cloud.

Relationships among multiple representations may be explicitly expressed in the DRM by specifying associations between pairs of representations, generally indicating that one form is an alternate representation of the other (see 4.5.4.4 Associations). Relationships among data representations based on the same organizing principle may also specified. These organizational principles include:

1. time,

2. spatial partition,

3. resolution, and

4. classification or theme.

The data organization capabilities in the DRM (see 4.6.10 Organizing principles) permit multiple, alternative organizations to be represented without requiring that any single, specific organization be present.  This organizational capability allows the DRM to provide multiple representations for diverse application purposes.

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 environmental data 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 Data Representation Model (DRM) defined in this part of ISO/IEC 18023,
2. ISO/IEC 18025 — Environmental Data Coding Specification (EDCS),
3. ISO/IEC 18026 — Spatial Reference Model (SRM),
4. the SEDRIS abstract transmittal format (ATF) as defined in Part 2 of ISO/IEC 18023 standardized concrete transmittal formats such as the SEDRIS transmittal format binary encoding (STF) as defined in Part 3 of ISO/IEC 18023, and
5. the SEDRIS Application Program Interface (API) defined in this part of ISO/IEC 18023.

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 ISO/IEC 18025, 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 characteristics are (attribution).

Similarly, the DRM relies on ISO/IEC 18026 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 ATF, as specified in Part 2 of ISO/IEC 18023. 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, Part 3 of ISO/IEC 18023 specifies a binary encoding referred to as the STF. 4.3.3.2 Accessing transmittals using the API describes the mechanism that allows applications to be 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)

ITR is the mechanism that allows relationships between objects contained in different 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 object. Objects that satisfy this constraint are termed publishable.

4.3.3.2 Accessing transmittals using the API

The SEDRIS API allows access to, and manipulation of, 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 the DRM require specifying semantic information about the environmental data being represented. This information is provided in the form of classifications of the environmental objects and attributes specifying properties of such objects. ISO/IEC 18025  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. 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.

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.

4.5 DRM syntax

4.5.1 Overview

Through the use of the data representation model, users of this part of ISO/IEC 18023 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 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 this part of ISO/IEC 18023. 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 — Information Technology — Unified Modeling Language (UML) — Part 1:  Specification 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

The DRM class diagrams, provided in 6.3 DRM class specifications, omit the operations. 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.

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

If the multiplicity is exactly one as in Class A in Figure 4.3, 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 UML generalization relationship, as denoted in Figure 4.4, is used in this part of ISO/IEC 18023. Here, classes B and C are both a subclass of class A, and both inherit from class A.

Figure 4.4 — UML generalization

Link classes are a special case of UML association classes and are used only within the context of aggregation and association relationships.

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 separate the evolution of the DRM from the evolution of the API, each class in the DRM is not treated as an independent class with its own methods. 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.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.

EXAMPLE  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 DRM classes, and relationships between classes, does not itself guarantee complete semantic validity.

EXAMPLE  A quad-tree that divides a spatial region into four sub-regions may be syntactically specified by defining four quadrants. However, the specification will not be semantically correct unless the four quadrants are disjoint and their union is the original spatial region.

Many DRM classes require additional semantic information to ensure that the use of those DRM classes will be valid. This part of ISO/IEC 18023 specifies a set of constraints that define valid semantic use. These constraints are specified in 6.2 Constraints.

4.5.5 Representational paradigm

The concepts of this part of ISO/IEC 18023, 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

Several key concepts in the DRM transcend the specification of a particular DRM object. These concepts are treated here. In some cases, these key concepts have an interrelation that a study of individual DRM classes will not reveal. In other cases, the concepts described herein enable a better understanding of the role of individual classes or group of classes. Where appropriate, each key concept discussed here in general terms is treated in detail later through the description or example of specific classes that embody the concept.

4.6.2 Spatial concepts

A fundamental characteristic of any environmental object is its location. Whether an object is in the real world or in a fictitious environment, a precise, accurate, and consistent representation of its spatial location, especially in relation to other objects in the environment, is critical to its accurate portrayal. Any number of spatial reference frames (SRFs) can be used to specify the location of an object. In practice, many spatial reference frames exist, and each is designed to serve a particular domain of use or application. Environmental objects within some physical proximity can be represented in different SRFs, if desired or required. Full understanding of the parameters for the specification of each SRF and the interrelationship between SRFs is needed if meaningful representation and use of such environmental objects is expected.

The science and mathematics for defining spatial reference frames, their valid parameters, their interrelationship, 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 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

The <DRM Data Table> class represents an n-dimensional array of cells. <DRM Property Grid> is a special version of <DRM Data Table> where at least one of the axes of the table is based on a spatial location. Each cell holds one or more data values whose semantics are specified with EDCS attribute codes. These values are said to be the elements of the <DRM Data Table>. The <DRM Data Table> instance may have as many elements as needed. Each element for a <DRM Data Table> instance has an EDCS_Scale_Code, an EDCS_Unit_Code, and a data type along with the EDCS_Attribute_Code. This information for all elements is called the signature of the <DRM Data Table> instance. It is also possible for the <DRM Data Table> instance to contain sparse information by representing EDCS Value_Characteristic concepts in the element data.

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 functions 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 modelling 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 as described conceptually in 4.6.10 Organizing principles and in more detail in 4.13 Organizing principles. 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 Representation> objects. This allows a <DRM Feature Representation> or <DRM Geometry Hierarchy> object to be represented as an alternate representation of a given <DRM Geometry Hierarchy> instance. 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 modelling 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 conceptually in 4.6.10 Organizing principles and in more detail in 4.13 Organizing principles. Each <DRM Feature Representation> object can be associated with one or more other <DRM Geometry Hierarchy> objects, as well as with one or more <DRM Feature Representation> objects. This allows a <DRM Feature Representation> object to be represented as an alternate representation of a <DRM Geometry Hierarchy> object or another <DRM Feature Representation> 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 Representation> versus <DRM Geometry Representation> distinction as a mechanism to provide a fundamental separation for representing environmental objects. The distinction between the <DRM Feature Representation> representations and <DRM Geometry Representation> representations is that a <DRM Feature Representation> representations removes all spatial information not required to support spatial connectivity; that is, it only requires topology. The location data of a feature representation is stored within the topology DRM classes. A <DRM Geometry Representation> representations stores location data within the actual representation of the environmental objects. The <DRM Geometry Representation> representations can then be augmented with topological relationships. Conversely, a <DRM Feature Representation> object 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> 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> representation is better suited for immersive visualizations, while a <DRM Feature Representation> 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 Representation> and <DRM Geometry Hierarchy>, <DRM Feature Representation> and <DRM Property Grid>, as well as the self association of a <DRM Feature Representation> instance to itself and a <DRM Geometry Hierarchy> instance 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> object is a type of <DRM Feature Hierarchy> object (which itself is a type of <DRM Feature Representation> object), and since a <DRM Aggregate Geometry> object is a type of <DRM Geometry Hierarchy> object, all association relationships that apply to polymorphic representation of <DRM Feature Representation> and <DRM Geometry Hierarchy> objects 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> object. 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> object 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 modellers and data producers to reuse the same <DRM Model> object numerous times by providing a pointer (captured in <DRM Feature Model Instance> and <DRM Geometry Model Instance> classes) from the environment they are modelling to the specific <DRM Model> object in the <DRM Model Library> object.

A <DRM Model> object can be composed of two branches:  feature model and geometry model. This allows a <DRM Model> object to act analogous to the <DRM Environment Root> object, where a feature and geometry branch is provided. A <DRM Model> object can instance other <DRM Model> objects. This capability can be used to build very complex worlds and reuse them in a broader context.

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> objects in order to provide a richer and more complex planetary object.

Alternatively, a <DRM Model> object 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.

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 Capturing SRF information

4.7.2.1 SRFs

ISO/IEC 18026 defines the concepts required to specify spatial information using the DRM. 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. An SRF is a means of specifying a spatial coordinate system. An SRF Template is an abstraction of a set of specifications of SRFs that share the same abstract coordinate system, coordinate system parameter binding rules, and coordinate component names and/or symbols. An SRF Set is a finite parameterized set of two or more SRFs. Furthermore, ISO/IEC 18026 defines SRF Instances by specifying the SRF Template parameters for an instance. The DRM provides the ability to store SRF information through all three mechanisms, SRF Template Parameters, SRF Set Parameters, and SRF Instances.

SRF information is specified in a DRM class via an srf_info field. The following DRM classes specify a srf_info field:

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_info field, specified using the structured data type SRF_Info as specified in ISO/IEC 18026. Within this field, the SRF information can be provided as either SRF template parameters, SRF set information, or as an SRF instance code. The specification of each of these data elements in defined in  ISO/IEC 18026.

4.7.2.2 SRF location compatibility

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 a DRM class that specifies the SRF information.  The coordinate shall be specified so that it is specified within the SRF Template specified by the srf_info field. A coordinate is always specified in the context of an SRF to avoid ambiguity. The context SRF is specified by the nearest aggregating DRM class instance of a DRM class having an srf_info field.  The coordinate shall belong to a DRM class that is compatible to the SRF specified by the srf_info field value. A coordinate is compatible to an SRF if the DRM class corresponds to the SRF Template of the srf_info field. If the srf_info specifies the SRF through SRF Template parameters, the SRF Template of the srf_info field value is specified by the template_code field. If the srf_info field value specifies an SRF set, the SRF Template of the srf_info field value is the SRF template corresponding to the SRF set per ISO/IEC 18026. If the srf_info field value specifies an SRF instance, the SRF Template of the srf_info field value is the SRF template corresponding to the SRF instance per ISO/IEC 18026.

Table 4.4 specifies the DRM class and its compatible SRF Template:

4.7.2.3 Specifying multiple SRF locations

All coordinates aggregated under a DRM class instance of <DRM Environment Root> shall be compatible with the SRF defined within the srf_info field of the <DRM Environment Root> instance. Storing coordinates for a different SRF is accomplished by aggregation multiple <DRM Environment Root> instances under the <DRM Transmittal Root> instance. In this situation, each <DRM Environment Root> shall specify a unique SRF.

4.7.3 Location

The <DRM Location> class has three abstract subclasses:

1. <DRM Location 3D> (the subclasses of which correspond to 3D SRFs specified in ISO/IEC 18026),
2.  <DRM Location 2D> (the subclasses of which correspond to 2D SRFs specified in ISO/IEC 18026), and
3. <DRM Location Surface> (the subclasses of which correspond to surface SRFs specified in ISO/IEC 18026.

An instance of a concrete subclass of <DRM Location 3D> shall appear only within the context of a compatible SRF.

EXAMPLE 1  An instance of <DRM SMS 3D_Location> appears only within the context of an object that specifies a three-dimensional Geocentric Solar Magnetic (SMS) SRF.

A <DRM Location 3D> instance shall never appear in the scope of an object that specifies other than a three-dimensional SRF.

Similarly, an instance of a concrete subclass of <DRM Location 2D> or <DRM Location Surface> shall appear only within the context of a compatible SRF. If the respective SRFs are compatible, an instance of a concrete subclass of <DRM Location 2D> or <DRM Location Surface> may appear within the context of a 3D SRF.

EXAMPLE 2  An instance of <DRM EC Surface Location> may appear within the context of an EC Augmented 3D SRF.

A reference surface defines the surface from which vertical values are computed for instances of concrete subclasses of <DRM Location 2D> within a transmittal.

An instance of a concrete subclass of <DRM Location 2D>, or an instance of a concrete subclass of <DRM Location Surface>, specified in the scope of a 3D SRF, is termed a conforming point.

EXAMPLE 3  Given point P_2D with coordinate values (λ,φ), construct a line that intersects the ellipsoid at P_2D and is orthogonal to the ellipsoid. The intersection of the line with the reference surface R provides the value for the third dimension of the conforming point P_3D. (see Figure 4.7). The<DRM Reference Surface>is associated to the <DRM Geometry Hierarchy> object that aggregates the objects representing the surface R.

Figure 4.7 — Determining conformal points elevation

The value for the third dimension of a conforming point is determined by the surface data that matches one or more ofthe field values of a <DRM Reference Surface> instance. An instance of a <DRM Reference Surface> associates to a corresponding instance of a <DRM Geometry Hierarchy> or <DRM Feature Hierarchy> that aggregates the surface used for determining the third value of a conforming point. The third value is determined by a line orthogonal to the object reference model at the coordinate specified by the conforming point and intersecting the reference surface data specified by the <DRM Geometry Hierarchy> or <DRM Feature Hierarchy> instance. The elevation value at the intersection point of the reference surface determines the third value of the conforming point.

EXAMPLE 4  When representing a house containing exterior walls, conforming points can be used for the lowest vertices of each wall in order for the bottom of the walls to lie on the terrain surface wherever the house is instanced. The coordinates at the bottom of the wall provide only two values as shown with points P2 and P3 in Figure 4.8. The third value of the coordinates is provided by the reference surface yielding points P2’ and P3’.

Figure 4.8 — Using conforming points

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 here; the latter is covered in 4.7.5 Transforming from a model SRF to an environment SRF.

A <DRM Reference Vector> object specifies a 3D vector and its type, defining the semantic meaning of the 3D vector. For a given <DRM Reference Vector> instance, the semantic meaning of the 3D vector may be further qualified by a <DRM Property Value> instance supplied as a component of the <DRM Reference Vector> (see 4.8 Semantic Attribution in the DRM for further information).

A <DRM Reference Vector> instance always has a <DRM Location> subclass instance, which is either a component of the <DRM Reference Vector> instance, or is supplied by one of the aggregating DRM objects of the <DRM Reference Vector> object. The constraint specified in 6.2.50 Required Reference Vector Location defines when the <DRM Reference Vector> shall aggregate a <DRM Location> component. For all other cases, a <DRM Location> will be inherited.

The spatial reference frame determines 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, such 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.  Therefore, the 3D vector specified by a <DRM Reference Vector> instance shall always be a unit vector.

However, 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> object is not 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 Space Euclidean (LTSE) vector space appropriate for each <DRM Reference Vector> instance is embedded in the spatial reference frame. It is this LTSE vector space that is used to specify the unit_vector information needed for the unit_vector field of the <DRM Reference Vector> instance.

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 ellipsoid, 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 LTSE space is constructed such that it is tangent to the ORM at the surface location that is on the same ray from the centre of the ORM to the given point, where the reference parameters of the LTSE are x_offset = y_offset = azimuth = 0.0. Therefore, for such spatial reference frames (whose ORM is an ellipsoid), the unit_vector of a <DRM Reference Vector> instance is interpreted as a vector in the canonical LTSE space defined at the position specified by the <DRM Location> component of the <DRM Reference Vector> object.

EXAMPLE  Given two points in a celestiodetic spatial reference frame with location values (λ₁,φ₁) and (λ₂,φ₂), the orientation from the first point to the second point would be provided as illustrated in Figure 4.9.  An LTSE would be constructed at (λ₁,φ₁), and in that LTSE space a vector D would be specified for (λ₁,φ₁) to (λ₂,φ₂). The unit vector would then be calculated for vector D and specified within a <DRM Reference Vector> instance.

Figure 4.9 — Orientation specified with local tangent plane

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 Transforming from a model SRF to an environmental SRF

Within this part of ISO/IEC 18023, an SRF that is bound to some non-abstract ORM is termed a world SRF. In a world SRF, the origin is tied to some real-world location. An SRF that is not bound to an ORM or is bound to an abstract ORM is termed a local SRF. In a local SRF, the origin is not tied to a specific real-world location.

A <DRM Transformation> instance allows some representation to be defined in a local SRF and then instanced in another SRF, either a world SRF or another local SRF. Thus, a complex DRM object may be defined in a consistent manner with all the pieces of such a representation specified correctly relative to one another. Once such a representation has been thus specified, the issue of mapping that representation into a world SRF can be considered.

A <DRM World Transformation> instance is used only to instance a <DRM Feature Model Instance> or <DRM Geometry Model Instance> object into a world SRF or into another local SRF. A local transformation, such as a <DRM LSR Transformation> instance, are not restricted to be used soley with <DRM Feature Model Instance> or <DRM Geometry Model Instance> objects. A local transformation may also be used by <DRM Aggregate Geometry> or <DRM Property Grid Hook Point> instances.

A <DRM Model> instance can be defined in any SRF. If a <DRM Model> instance is defined in a world SRF, it can only be instanced in the object hierarchy of a <DRM Environment Root> instance with a matching SRF defined. A matching SRF is one in which there exists a transformation from the model SRF to the target SRF. ISO/IEC 18026 specifies available transformations.

A <DRM Model> instanced defined with a local SRF can be instanced in the object hierarchy of a <DRM Environment Root> with any SRF defined. In this case, an instance of <DRM World Transformation> is used to specify a transformation from the local SRF of the <DRM Model> instance to the target SRF of the <DRM Environment Root> instance.

4.7.6 Spatial extents

A <DRM Spatial Extent> instance specifies a bounding surface (if 2D) or a volume (if 3D) within which the DRM objects representing environmental data are contained. This includes surfaces with area zero and volumes 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. The first of these components is termed the minimum location of the spatial extent. The second of these components is termed the maximum location of the spatial extent. ISO/IEC 18026 defines the relationships between coordinate components. Conceptually, the minimum location can be considered to be the lower left corner and the maximum location can be considered to be the upper right corner of a bounding surface or volume 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.

In the case of an SRF such as geodetic, the coordinate component values of the maximum location may be either greater than or less than those of the minimum location, depending on the particular region for which spatial domain information is being specified as depicted in the following example:

EXAMPLE  Consider the geodetic situation in of four points with P1 with a value of (10°, 170°), P2 a value of (10°, -170°), P3 a value of (-10°, 170°) and P4 with a value of (-10°, -170°) as depicted in Figure 4.10. ISO/IEC 180126 specifies the positive direction for both the lines of longitude and lines of latitude. A spatial extent with the first point specified as P3 (-10°, 170°) and the second point specified as P2 (10°, -170°), will define the surface depicted by R1. Conversely, a spatial extent with the first point specified as P4 (-10°, -170°) and the second point specified as P1 (10°, 170°), will define the region depicted by R2 (NOTE R2 is continuous around the back of the ORM). Thus, the location (0°, 0°) is within R2 but not within R1.

Figure 4.10 — Example spatial extents

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.

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> component with the first <DRM Location> component so that the <DRM Perimeter Data> specifies a connected boundary. <DRM Perimeter Data> is constrained (see 6.2.35 Non-selfoverlapping perimeter data locations for details) so that the boundary thus specified does not overlap with itself.

EXAMPLE 1  In the case of <DRM Aggregate Feature> or <DRM Aggregate Geometry>, the aggregate represents some aspect or aspects of the region in question.

EXAMPLE 2  In the case of <DRM Sound Instance>, the meaning is more specialized (see 4.15.6 Sound for details).

EXAMPLE 3  <DRM Perimeter Data> instances also occur as link objects in a perimeter-related organization (see 4.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.

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 LOD 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> instance is centred at a <DRM Location 3D> instance specified as a component of the <DRM Volume> instance. 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>. <DRM Spherical Volume Extent> specifies the radius of the sphere.

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.

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 by 6.2.20 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 Element_Type value specifies the semantic meaning of the set of data values bound to that <DRM Property> instance in the form of an EDCS attribute. 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.43 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 that may include such items as:

1. maximum value,
2. minimum value,
3. measurement error, and
4. sentinel values (in the case of multiple value sets).

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.42 Property characteristic constraints for semantic constraints ensuring that <DRM Property Characteristic> information is meaningful within the context of a <DRM Property> instance.

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.9 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> instance, 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 by an instance of the class <DRM Property Description>. Such an instance of <DRM Property Description> 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, ensuring that the <DRM Property Value> meaning values match that of the <DRM Property Description>.

EXAMPLE 1 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 that apply to all <DRM Property Value> instances within that scope that have matching meaning field values.

 EXAMPLE 2  In a <DRM Aggregate Geometry> instance 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.

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> instance;
4. as the component_data_table_ecc of a <DRM Table Property Description> instance; and
5. as part of the texel data of a <DRM Image> instance, depending on the image_signature.

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

The details of the specific interpretation of an ECC depend on the context in which it appears. In the case of a <DRM Classification Data> instance, the tag field specifies the semantic meaning of the DRM object to which the <DRM Classification Data> instance is being applied. 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.8.3 Relationships between representations

The DRM provides the capability of expressing relationships between environmental objects by providing the ability to express relationships between their representations. A <DRM Base Association Data> instance specifies the semantic meaning of the association relationship with which it is bound. Consequently, relationships can be expressed between environmental objects represented as instances concrete subclasses of <DRM Feature Representation>, <DRM Geometry Representation>, or both.

Relationships between representations are of two categories:  spatial relationships and functional relationships. An instance of <DRM Base Association Data> will be either a concrete instance of  <DRM Base Spatial Association Data> or an instance of  <DRM Functional Association Data>. The semantic meaning of a spatial relationship thus represented is expressed by using a concrete subclass of <DRM Base Spatial Association Data> (i.e., either an instance of <DRM Spatial Association Data> or an instance of <DRM Proximity Data>). The meaning field of the instance specifies the spatial relationship being represented. Thus, for an association relationship between representations of two environmental objects, object_1 and object_2, the meaning specifies the spatial relationship between object_1 and object_2.

EXAMPLE  If none of the points in object_1 are also in object_2, an association between their representations specifying via a <DRM Spatial Association Data> instance that they are DISJOINT could be supplied.

A <DRM Proximity Data> instance, in addition to specifying that the two related environmental objects are in proximity of each other, specifies the distance in metres of that proximity. In addition to providing the capability of specifying spatial relationships, <DRM Base Association Data> provides the capability of specifying functional relationships through its subclass <DRM Functional Association Data>. Examples of relationships currently supported by this mechanism include CONTROLS, CONTROLLED_BY, and relationships that specify the existence of forces between the two objects, such as SUPPORTS and SUPPORTED_BY.

NOTE  Two representations may have more than one relationship with one another including having various spatial relationships in addition to functional relationships.

4.9 Data tables

4.9.1 Overview

The abstract <DRM Data Table> class specifies an n-dimensional array of data cells. This cell data is distinct from the DRM fields of the <DRM Data Table> class and is accessed through the specialized API functions, 7.3.23 GetDataTableData and 7.3.65 PutDataTableData.

The number of dimensions of the cell data array is determined by the number of ordered <DRM Axis> instances aggregated by a given <DRM Data Table> instance. The axis_value_count field of each <DRM Axis> component specifies the number of cells in its corresponding dimension.

EXAMPLE  A <DRM Data Table> instance with two axes with axis_value_count field values of s and t will have s×t cells.

Each cell in a data table may contain one or more properties. The ordered list of properties is termed a signature of the data table. This signature is constituted from the ordered list of <DRM Table Property Description> components associated with the <DRM Data Table> instance. A <DRM Table Property Description> in the signature describes a property contained in the cell data. It specifies the property’s meaning, unit of measure, and data type. The dimensions and signature do not fully describe the intended meaning of the overall <DRM Data Table> instance. For that, a <DRM Classification Data> instance is provided as a component of each <DRM Data Table> instance.

The cell data for a <DRM Data Table> instance is represented by an array of values of data type Data_Table_Data. Each element of type Data_Table_Data in the array represents the array of property values for the cells of the <DRM Data Table> instance. Since the cell data may be arbitrarily large and consequently pose practical problems for access and storage, the 7.3.23 GetDataTableData and 7.3.65 PutDataTableData functions are provided to extract and insert sub-portions of cell data. Cell data may be accessed by individual properties and/or by a spatial sub-extents as specified by the extents field which is of data type Data_Table_Extents.

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 can 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> specifies:

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> instance, 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.2 Axis Type Constraints constraint.

EXAMPLE If a <DRM Property Grid> specifies its srf_info 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>. In addition to the fields inherited from <DRM Property>, <DRM Table Property Description> has a value_type field. All entries in a <DRM Data Table> instance corresponding to a given <DRM Table Property Description> instance have the same value_type, unit, and scale.

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.

Two of the concrete subclasses, <DRM Regular Axis> and <DRM Irregular Axis>, specify mechanisms for handling interpolation. Interpolation is used to find the value of a data point between the tick marks of the data. The interpolation methods are specified in 5.2.7.32 Interpolation_Type and include values for no preference and to disallow interpolation. The interpolation methods have specific requirements with further specification provided through the supplemental_information field of the <DRM Description> component of the <DRM Data Table> aggregate of the <DRM Axis> instance.

EXAMPLE 1  The interpolation method DIAGONALIZATION requires two dimensional data and a data cell element of EA GRID_DIAGONALIZATION.

EXAMPLE 2  The interpolation method KRIGING specifies weighting values that are calculated by deriving the function of the data variogram and evaluating this function over the set of points in the data (see [OLIVER]). If other weighting values are to be used, they are specified in the supplemental_information field of a <DRM Description> instance.

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 EA HIGH_CLOUD_TOP_LEVEL (see ISO/IEC 18025). 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 a <DRM Regular Axis> instance, this applies to the first_value and spacing fields; in instances of the other subclasses, it applies to an explicit array of axis values. The <DRM Axis> classes that represent numeric data have value_unit and value_scale fields that determine an unambiguous for the numeric data. The values are constrained to be consistent with the axis_type (see 6.2.2 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 a numerical axis that has constant spacing between the axis values. The axis values are called tick marks. To specify the tick marks, a <DRM Regular Axis> instance specifies the starting value (first_value), 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)

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

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

When a <DRM Regular Axis> instance 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.7.32 Interpolation_Type. If there is no preferred interpolation method, interpolation_type shall have value NOT_SUPPLIED. Data not appropriate for 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.

EXAMPLE  Consider a <DRM Property Grid> instance with one <DRM Regular Axis> component that has first_value = 0, spacing = 100, spacing_type = ARITHMETIC, value_unit = METRE, and value_scale = UNI. The data values at 0 metres, 100 metres, 200 metres, ... are provided within the data of the <DRM Property Grid> instance, but the value at 50 metres or 150 metres is not. If these values are to be determined, they shall be interpolated from the existing data. If interpolation_type = DISALLOWED, the data cannot be determined. If interpolation_type = NOT_SUPPLIED, there is no preferred interpolation method and any method can be used. If interpolation_type = LINEAR, the slope of the best line fitting the data is determined and used to interpolate the data point. Thus, given M = slope of the line, V = the data value at point P, V = P × M.

When a <DRM Regular Axis> instance represents a spatial axis as a component of a <DRM Property Grid> instance, the values of the axis are relative to the <DRM Location> components of the <DRM Property Grid Hook Point> instance. 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> instance using the location_index field of the <DRM Property Grid> instance.

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> instance 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.2 Axis type constraints.

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

If a <DRM Irregular Axis> instance is used as a spatial <DRM Axis> instance within a <DRM Property Grid> instance, 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> instance is always LOWER.

4.9.5.4 Enumeration axis

A <DRM Enumeration Axis> instance is constrained to specify an axis_type corresponding to an 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 representation

4.10.1 Overview

<DRM Geometry Representation> is an abstract DRM class for which an instance of one of its concrete classes 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 Representation> includes, but is not limited to, the concepts of:

1. point geometry,
2. linear geometry,
3. planar geometry,
4. surface geometry, and
5. volume geometry.

<DRM Geometry Representation> 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

The <DRM Geometry Hierarchy> class represents a hierarchically organized collection of concrete instances of <DRM Geometry Representation> subclasses. <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> instance of a <DRM Model> instance. <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 the spatial reference frames of one or more <DRM Property Grid> instances 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>.

EXAMPLE  Consider a <DRM Property Grid> instance G as shown in Figure 4.11. 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:

1. points,
2. lines,
3. surfaces,
4. volumes, and
5. 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> instance are aggregated in a <DRM Union Of Primitive Geometry> instance. 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> instance with various geometric rendering characteristics or a <DRM Location> instance 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> instance 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> instance 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.

4.10.3.3.2 Lines

A <DRM Line> instance is an ordered list of two or more <DRM Vertex> instances specifying a sequence of connected straight 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 specifies a circular arc with the centre specified by the component <DRM Location> instance 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> instance (i.e., the positions of the first and last light points). L has a <DRM Light Rendering Properties> component specified with a <DRM Flashing Light Behaviour> instance, so L is rendered as thirty flashing light points, evenly spaced between L’s endpoints. The UML for this example is depicted in Figure 4.12.

Figure 4.12 — 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> instance represents 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> instance is not duplicated to also appear as the last <DRM Vertex> instance of the <DRM Polygon> instance. Thus, the 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

The <DRM Volume Geometry> class abstracts common properties of classes used to specify geometric volumes. The <DRM Volume Geometry> class has two concrete subclasses, <DRM Polyhedron> and <DRM Volume Object>.

4.10.3.5.2 Polyhedrons

The <DRM Polyhedron> class specifies an arbitrary, bounded region of three-dimensional space. The exact volume is specified by a set of <DRM Polygon> components with a minimum set of four <DRM Polygon> components. The set of <DRM Polygon> instances shall specify a completely enclosed volume.

4.10.3.5.3 Volume objects

The <DRM Volume Object> class specifies a bounded region of three-dimensional space with a regular geometric shape. The geometric shape is specified by one of the following <DRM Volume Extent> subclasses:

1. <DRM Cylindrical Volume Extent>,
2. <DRM Parallelepiped Volume Extent>, or
3. <DRM Spherical Volume Extent>.

The center of a <DRM Volume Object> instance is specified by the <DRM Location 3D> component. The shape and extent of a <DRM Volume Object> instance is specified by the <DRM Volume Extent>. component

4.10.3.6 Mesh surfaces

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 a table, a <DRM Finite Element Mesh> instance uses a <DRM Mesh Face Table> instance to efficiently represent a finite element mesh. Finite element meshes are often used as input data for computational environment models.

A mesh surface consists of a finite set of faces that approximates and partitions a smooth surface or volume. A face is a polygon that may have one or more interior rings. An interior ring is polygon contained by and co-planar to the exterior polygon of a face. Mesh vertices represent the endpoints of the faces where they meet adjacent mesh faces and also represent the endpoints of the faces’ interior rings.

Four DRM classes (or their concrete subclasses) are used to represent a mesh surface:

1. <DRM Vertex>,
2. <DRM Location>,
3. <DRM Finite Element Mesh>, and
4. <DRM Mesh Face Table>.

Each vertex in the mesh surface is represented with a <DRM Vertex> instance that is an ordered component of a <DRM Finite Element Mesh> instance. <DRM Vertex> aggregates concrete instances of <DRM Location> and also any relevant attribute information that may be associated with the vertex. A <DRM Mesh Face Table> component of the <DRM Finite Element Mesh> object specifies all face information for the mesh. While the fields specify the number of faces in the mesh and the maximum number of vertices needed to specify a face, the actual description of the faces is specified in a two dimensional mesh face table that is accessed through the API functions, 7.3.30 GetMeshFaceTableData and 7.3.68 PutMeshFaceTableData.

The dimensions of the mesh face table are specified by mesh_face_count (rows) by maximum_vertices_per_face (columns). The table values are unsigned integer values that are indices into the ordered <DRM Vertex> components of a <DRM Finite Element Mesh> instance. Thus, a face in the mesh surface is defined by a row in the mesh face table that specifies a list of vertices that specify a face and its interior rings. If a face has no interior rings, its row in the mesh face table is simply a list of vertex indices with zeros values in any unused columns. If a face has an interior ring, the vertex indices for the ring’s vertices are listed after the face’s vertices and one delimiting zero index. Other interior rings may follow the first with a zero index separating each.

EXAMPLE 1   Figure 4.13 illustrates a mesh surface with three faces, one with an interior ring:

This is represented by the following mesh face table depicted in Table 4.5:

Table 4.5 -- Mesh face table for Figure 4.9

A <DRM Mesh Face Table> instance may optionally contain face adjacency information in a separate table called the adjacent face table. The presence of the adjacent face table is specified with the Boolean field adjacent_face_table_present. This table has the same dimensions as the mesh face table. The values in the table are positive integer values that specify face indices that represent the row in the mesh face table. In general, the table value (i, j) represents the face that is adjacent to the i^th face through the edge from vertex j to vertex j+1. If the (j+1)^th vertex is a zero, the meaning is the first vertex in the row.  If there is no adjacent face or if the vertex represents a ring vertex or a zero, the table value shall be zero.

EXAMPLE 2  Table 4.6 contains the adjacent face table for the example depicted in Figure 4.9:

4.11 Feature representation

4.11.1 Overview

<DRM Feature Representation> is an abstract DRM class for which an instance of one of its concrete classes 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 Representation>  instance is either a <DRM Primitive Feature> instance or a <DRM Feature Hierarchy> instance. A <DRM Primitive Feature> instance directly represents some environmental entity, or some portion of an environmental entity, while a <DRM Feature Hierarchy> instance is an organized collection of such primitives.

4.11.2 Primitive features

4.11.2.1 Overview

<DRM Primitive Feature> has three concrete subclasses:

1. <DRM Point Feature>,
2. <DRM Linear Feature>, and
3. <DRM Areal Feature>.

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

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> instance (see 4.12 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.

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.

A <DRM Linear Feature> is not required to be continuous. 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.

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 universal field shall be set to TRUE and there shall be only one <DRM Areal Feature> with that value  for the universal field per transmittal.

4.11.3 Feature hierarchy

A <DRM Feature Hierarchy> instance is a hierarchically organized collection of concrete instance of <DRM Feature Representation> subclasses. <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> instance of a <DRM Model> instance.

A <DRM Aggregate Feature> instance 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 the <DRM Aggregate Feature> instance 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 Representation> 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 Representation> 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.

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

1. <DRM Geometry Node>,
2. <DRM Geometry Edge>, and
3. <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> instance 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> instance, or because it is used to specify an endpoint for one or more <DRM Feature Edge> instances, or both. A <DRM Feature Node> instance 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> instance:

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> instance 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> instance, 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  A <DRM Feature Edge> instance may be specified in any orientation in space.

For a <DRM Feature Edge> instance 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.74 <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> instance.

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> instance 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> instance 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> instance 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> instance is to be interpreted forwards (start to end) or backwards (end to start) 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> instance 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> instance. 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> instance 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> instance, 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> instance. Note that the representation may go on to use the edges for each such <DRM Feature Face Ring> instance 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.

5. At level FIVE, in addition to the conditions specified by level FOUR, the following conditions are met. At least one instance of <DRM Feature Volume> shall exist. Every <DRM Feature Node> instance associates to the <DRM Feature Volume> instance it is located in, if any. Every <DRM Feature Edge> instance associates to the <DRM Feature Volume> instance it is completely located in, if any. Every <DRM Feature Face> instance associates to the two <DRM Feature Volume> instances that bound it. <DRM Feature Volume> instances may not intersect or overlap one another unless they meet at a common <DRM Feature Face>. The set of <DRM Feature Volume> instances shall be exclusive and exhaustive. Exactly one <DRM Feature Volume> instance within the parent <DRM Union Of Feature Topology> instance shall have universal set to TRUE, all others shall have universal set to FALSE.

A detailed specification of the levels of feature topology is contained in 5.2.7.17 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> instance 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 Volume Object> where the node corresponds to the centre of the bottom face.

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

<DRM Geometry Face> is simpler than its counterpart in feature topology. A <DRM Geometry Face> instance 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. octant,
6. perimeter,
7. quadrant,
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. octant division of a volume,
2. quadrant 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. This part of ISO/IEC 18023 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 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 LOD Related Geometry> and <DRM LOD 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 LOD Data>,
2. <DRM Index LOD Data>,
3. <DRM Map Scale LOD Data>,
4. <DRM Spatial Resolution LOD Data>, and
5. <DRM Volume LOD Data>.

The <DRM Distance LOD 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 instance of <DRM Feature Hierarchy> or <DRM Geometry Hierarchy> is valid,
2. the minimum fade band in metres where the corresponding instances of <DRM Feature Hierarchy> or <DRM Geometry Hierarchy> can begin to be faded in,
3. the maximum range in metres where the corresponding instance of <DRM Feature Hierarchy> or <DRM Geometry Hierarchy> is valid, and
4. the maximum fade band in metres where the corresponding instance of <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 LOD Data> link object.

The <DRM Index LOD 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 LOD 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 LOD 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 LOD 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 Octant

The octant 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.37 Octant related organizing principle constraint to ensure that instances of these classes are semantically valid. In terms of their octant behaviour, <DRM Octant Related Features> and <DRM Octant Related Geometry> have exactly the same organization, so “octant 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 octant is analogous to that of a quadrant as discussed in 4.13.8 Quadrant.

An octant 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 octant in this part of ISO/IEC 18023 is not necessarily a classical region oct_tree, in that a SEDRIS data provider is not constrained to organize the entire hierarchy below an octant as smaller and smaller oct_trees. A data provider may choose to do so, but it is not a requirement.

To begin specifying an octant, 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 octant related organization is not required to specify a branch for each possible octant. Some data providers may have data that naturally lends itself to octant 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.37 Octant 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 octant 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 octant related organization is always TRUE indicating that the octant related organizing principle is strictly obeyed. In addition, since the octants partition the octant’s region and do not overlap, no two branches may have primitives in common, so the unique_descendants field value of an octant 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 octant 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.35 Non-selfoverlapping Perimeter_Data locations.

4.13.8 Quadrant

The quadrant 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 quadrant behaviour, <DRM Quadrant Related Features> and <DRM Quadrant Related Geometry> have exactly the same organization, so “quadrant 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 quadrant 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 quadrant in this part of ISO/IEC 18023 is not necessarily a classical region quad_tree, in that a SEDRIS data provider is not constrained to organize the entire hierarchy below a quadrant as smaller and smaller quadrants. A data provider may choose to do so, but it is not a requirement.

To begin specifying a quadrant, the region being subdivided into quadrants shall be specified. This is done by attaching a <DRM Spatial Extent> component to each quadrant related aggregation, specifying the rectangular region being divided into quadrants. Every quadrant 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.

A quadrant related organization is not required to specify a branch for each possible quadrant. Some data providers may have data that naturally lends itself to quadrant 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 quadrant 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 quadrant related organization is always TRUE, indicating that the quadrant related organizing principle is strictly obeyed. In addition, since the quadrants partition the quadrant’s region and do not overlap, no two branches may have primitives in common, so the unique_descendants field value of a quadrant 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 quadrant 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 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 EAs 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.13 Union

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

The DRM provides the following mechanisms for sharing data within a transmittal:

1. models,
2. libraries, and
3. property sets

Each of these is described below.

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 an 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> instance 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> instance, then instanced via references to the <DRM Library> instance 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.9 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 (that is, non-spatial information about an 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 Representation> or <DRM Feature Representation> inherits a component, that component may be treated as if it were attached directly to the <DRM Geometry Representation> or <DRM Feature Representation> 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 LOD 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.3 <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 Representation> specific and some that are <DRM Geometry Representation> specific. In this case, <DRM Feature Representation> instances only  use the properties that are legal for the <DRM Feature Representation> class, while <DRM Geometry Representation> instances only use the properties that are legal for the <DRM Geometry Representation> 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.4 <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.5 Locations for reference vectors

In general, a <DRM Location> instance 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> instance from the object that aggregates the <DRM Reference Vector> rather than specifying a separate <DRM Location> instance. 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> instance 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> instance is required for the <DRM Reference Vector>.

4.14.5.3.6 < 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 environmental 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.7 <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.8 <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.9 <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 LOD 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 LOD 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 DRM 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 a finer <DRM Primitive Geometry> instance is nested (e.g., a <DRM Polygon> with subfaces), a <DRM Primitive Geometry> instance 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> instance, 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 classes 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 specifies 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.3 Colour mapping constraints for a <DRM_Colour> ensure that this field is appropriately specified.

4.15.3.3 Light sources

A <DRM Light Source> instance 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> instance is explicitly specified, but rather than specifying a <DRM Colour> component for the <DRM Light Source> instance and constraining it to contain the specific colour information required, a <DRM Light Source> instance directly specifies <DRM Ambient Colour>, <DRM Diffuse Colour>, and <DRM Specular Colour> components. Further information provided by a <DRM Light Source> instance 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> instance that is dynamically controlled by a <DRM Light Source Control Link> instance C, C determines whether the <DRM Light Source> instance is on or off and active_light_value’s original setting is a default state. See 4.16 Constructs for controlling dynamic data for details.)

The remaining information specified by a <DRM Light Source> instance 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> instance. 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 specifies whether the affected <DRM Geometry Representation> instances are to be rendered in SOLID display style, WIREFRAME display 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 Representation>  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 Representation> 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 Representation> and/or <DRM Feature Representation> 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.

The texel data for a <DRM Image> instance is represented by an array of Octet values within the Image_Data data type (see 5.3.3.108 Image_Data). Since the texel data may be arbitrarily large and could pose practical problems for access and storage, the 7.3.27 GetImageData and 7.3.67 PutImageData functions are provided to extract and insert subextents of the texel data. Texel data may be accessed by individual MIP level subextents as specified by the start and stop texel parameters of 7.3.27 GetImageData and 7.3.67 PutImageData.

4.15.4.2 Image specification

All imagery resources in a given transmittal are provided as <DRM Image> components of a <DRM Image Library> instance. 4.14 Constructs for sharing data and 4.15.4.3 Applying images as textures for how the contents of a <DRM Image Library> are referenced from other contexts in a transmittal. A <DRM Image> specifies one or more MIP levels of texels, and may be either two-dimensional or three-dimensional.

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 two-dimensional image, the size of the z dimension is specified to be 1.)

The actual texel data of a <DRM Image> instance is distinct from its fields. This information is represented by data type Image_Data (see 5.3.3.108 Image_Data) and is accessed by the specialized API functions, 7.3.27 GetImageData and 7.3.67 PutImageData. Texel data may have several different parts, termed texel components. The meaning of the texel components and the format by which they are represented in the Image_Data type is specified by fields in <DRM Image>. These files are described as follows.

1. The image_signature specifies the number and meaning of the texel components. Each texel characteristics is called a texel component. For example, the LUMINANCE_AND_ALPHA image signature indicates that there are two texel components: a luminance component and an alpha component. Thus, each texel for images with this image signature will consist of a luminance value and an alpha value. The value of image_signature also determines which of the bits_of, minimum_value_of, and maximum_value_of fields of the <DRM Image> instance apply. Those fields that the image_signature not being used are set to zero. See 5.2.7.29 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.15.4.4 Positioning images as spatial objects. The use of the optional <DRM Property Table Reference> components is described in 5.2.7.29 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.15.4.4 Positioning images as spatial data), or through reference by a <DRM Image Mapping Function>.

A <DRM Image Mapping Function>, as discussed in 4.14 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.19 Image mapping functions and texture coordinates. If F is a component of a <DRM Feature Representation>, 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 Representation> 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> instance with <DRM Vertex> components, either the <DRM Primitive Geometry> instance 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 specified 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.15.6.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 methods 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> instance. Instead, a <DRM Geometry Hierarchy> or <DRM Feature Hierarchy> instance 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> S has a <DRM Location 3D> component L, S is said to represent spatialized audio. That is, S indicates that the source of the sound is considered to be located at L. If S 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 S 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> S specifies a <DRM Sound Volume> and does not specify a <DRM Location 3D> instance, S 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 S 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 S specifies no <DRM Fade Range>, audibility is cut off without gradual attenuation at the boundary of the volume.

If a <DRM Sound Instance> S specifies a <DRM Perimeter Data> and does not specify a <DRM Location 3D> instance, S 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 S 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 S 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; that is, 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 dynamic 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 Representation>, possibly to a specific <DRM Location> within that <DRM Feature Representation>, 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 Representation> 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 Representation> 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

<DRM Control Link> instances 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 and rotating beacons),
• objects that change appearance dynamically (e.g., with changing radiance),
• destructible objects (e.g., bridges and 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 DRM 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.56 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.7:

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>

A <DRM Light Source Control Link> instance provides control over the active_light_value field of a <DRM Light Source> instance. This allows the consuming system to turn the <DRM Light Source> instance 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.8.

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

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

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.11, 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.12 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.13.

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.

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

In the example in Table 4.15, 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 <DRM Colour 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 the index_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 Control Link> subclasses for spatial location

Control links may be used to modify coordinate components representing locations within a local SRF. Only local SRFs may be modified in this manner. Conceptually, any type of local SRF may have an associated SRF-specific control link. ISO/IEC 18026 specifies only the LSR SRF as being local.

<DRM LSR 3D Location Control Link> provides control over the u, v, and w fields of the coordinate fields of the target <DRM LSR 3D Location> 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 3D Location Control Link> (u_expression_index, v_expression_index, or w_expression_index) is zero.

EXAMPLE Consider a <DRM LSR 3D Location> 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 3D Location> is provided with an <DRM LSR 3D Location Control Link> that specifies zero for the u and v values of the target, but a controlling <DRM Variable> for the w 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, 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. 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.25 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 corresponds 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 and is constrained by 6.2.25 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:

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_consistency is 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> 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.25 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.

4.17.2.7 Metadata access constraints, use constraints, and security information

Rather than representing access constraints, use constraints, and security information in separate classes, the DRM has a single class, <DRM Access> that contains fields corresponding to each of the three concepts. The following is the listing of the field elements of the <DRM Access> class and the corresponding ISO 19115 data elements:

1. access_constraints correspond to the data element accessConstraints of MD_LegalConstraints;
2. use_constraints corresponds to the data element useConstraints of MD_LegalConstraints; and
3. security corresponds to the data class element MD_SecurityConstraints.

The Security_Information data type consisting of the three string fields system, classification, and handling correspond to the data fields classificationSystem, classification, and handlingDescription of MD_SecurityConstraints in ISO 19115.

The 6.2.25 Mandatory Metadata constraint requires only that a user specify the classification information, since an unclassified data set will not have any other information. No specialized data types, such as enumerations, are provided for the system or classification fields, since there is no worldwide standard for security information of this kind, and many countries may have multiple incompatible systems used for different purposes.

4.17.2.8 Browse media

The <DRM Browse Media> class corresponds to the ISO 19115 date element MD_BrowseGraphic, a graphic providing an illustration of the data set being described, but has been modified in SEDRIS to enable transmittals to be self-contained. Rather than separate file name and file type fields, a <DRM Browse Media> instance specifies a media_urn field. Within the media_urn field value, part of the URN specifies the type of graphic being used, such as JPEG, from a list of registered file types.

A <DRM Transmittal Root> instance may optionally aggregate any number of <DRM Browse Media> instances.

4.17.3 Classes describing the structure of a transmittal

4.17.3.1 Overview

The second category of ‘metadata’, summary information about the structure of a transmittal that can be used to automatically make processing decisions based on the content of a given transmittal, is represented by the various summary classes of the DRM. Summary information is accessible only at a high level. The <DRM Transmittal Root>, <DRM Environment Root>, and <DRM Model> instances of a transmittal are the items that can be supplied directly with summary information. Such information can be provided in as much detail as desired.

Summary information can be provided in the following areas, individually or in various combinations: 

1. transmittal summary,
2. EDCS usage summary,
3. DRM class usage summary,
4. hierarchy summary, and
5. primitive summary.

4.17.3.2 Transmittal summary

Every <DRM Transmittal Root> instance is required to provide a <DRM Transmittal Summary>. The information in a <DRM Transmittal Summary> could be derived by an end user by performing a thorough analysis on the transmittal’s contents, as indeed all summary information could be provided, but a <DRM Transmittal Summary> provides a mechanism for a data provider to highlight important information about a transmittal without forcing the end user to re-create information at the provider’s disposal.

Many of the fields of a <DRM Transmittal Summary> specify whether various kinds of data are present in <DRM Environment Root> instances, <DRM Model> instances, both, or neither within the transmittal being summarized. Features, geometry, and geometry topology are the first three. Note that there is no feature_topology_present field, because if features are present, feature topology is automatically present.

The data_tables_present field does not indicate whether a <DRM Data Table Library> is present, but whether <DRM Data Table> instances are present within the context of any <DRM Environment Root> or <DRM Model> instance. For example, if <DRM Property Grid> instances are present under a <DRM Environment Root>, but no <DRM Model> instances contain any <DRM Property Grid>, <DRM Mesh Face Table>, or <DRM Property Table> instances, this field value would be set to ENVIRONMENT_ROOT.

The priority_values_present flag indicates whether <DRM Rendering Priority Level> instances have been provided. If not, the end user shall be required to derive various rendering priority information since it is not provided explicitly.

The terrain_lods_present flag indicates whether terrain data organized by level of detail has been provided. This data may be in the form of <DRM Property Grid> instances, <DRM Polygon> instances, or other primitives. The organization is not specified by this flag, although it can be specified using other summary information.

The two_D_features_flag indicates whether <DRM Primitive Feature> instances specified in reference to <DRM Feature Topology> using <DRM Location 2D> instances are present.

The mobility_values_present and thermal_values_present fields indicate whether <DRM Property> instances referring to EACs corresponding to mobility and thermal information have been provided, and if so, in which context.

The models_present, images_present, sounds_present, and symbols_present fields are flags indicating whether instances of the corresponding <DRM Library> subclasses are present.

The colours_present flag indicates whether the colour_model flag is actually meaningful. For example, a transmittal containing no <DRM Colour> instances, such as a transmittal with geometry consisting only of <DRM Property Grid> instances and various organizational hierarchy, would contain no meaningful colour information.

The EDCS_usage_list_is_comprehensive flag is discussed in 4.17.3.3 EDCS usage summary, as is the optional EDCS usage summary information provided by a <DRM Transmittal Summary>. The optional DRM class summary is discussed as part of the <DRM DRM Class Summary Item> below.

4.17.3.3 EDCS usage summary

A <DRM EDCS Use Summary Item> specifies a pattern of EDCS codes that appears within the scope being summarized, specifically, an ECC (as a <DRM Classification Data>) and an optional set of EACs (as <DRM Property Description> instances) used with the ECC, or just an individual EAC. If the ECC is qualified, the <DRM Classification Data> representing it is qualified with <DRM Property Value> instances rather than representing the qualifiers as <DRM Property Description> components of the <DRM EDCS Usage Summary Item>.

A list of <DRM EDCS Use Summary Item> instances can be provided for:

1. a <DRM DRM Class Summary Item> (see DRM class usage summary, below);
2. a <DRM Primitive Summary Item> (see Primitive summary, below);
3. a <DRM Hierarchy Summary Item> (see Hierarchy summary, below); or
4. a <DRM Transmittal Summary>.

For a <DRM Transmittal Summary>, the EDCS usage summary, if provided, may be comprehensive, spelling out the uses of all EACs and ECCs that occur within the transmittal, or the summary may omit items. The EDCS_usage_list_is_comprehensive field in <DRM Transmittal Summary> indicates which is the case.

4.17.3.4 DRM class usage summary

A <DRM DRM Class Summary Item> indicates the presence of instances of the class corresponding to its drm_class field value within the context being summarized. A <DRM DRM Class Summary Item> may be provided with a list of <DRM EDCS Use Summary Item> instances to summarize EDCS usage among the instances of the specified class within the scope being summarized.

A <DRM Hierarchy Summary Item> or <DRM Transmittal Summary> can be provided with a list of <DRM DRM Class Summary Item> instances, representing classes used in the context being summarized. By the 6.2.34 Non-overlapping DRM Class Summary Items constraint, each <DRM DRM Class Summary Item> in such a list is required to have a unique field value for its drm_class field within that list, to prevent non-value-adding repetition of information.

Note that <DRM DRM Class Summary Item> has an optional <DRM SRF Summary> component. A <DRM DRM Class Summary Item> is constrained so that such a <DRM SRF Summary> component may be present only if the drm_class field of the <DRM DRM Class Summary Item> corresponds to a class that specifies SRF parameters. Each <DRM SRF Summary> then corresponds to a specific SRF specified by an instance of that class somewhere in the context being summarized.

4.17.3.5 Hierarchy summary

A hierarchy summary (that is, a tree of <DRM Hierarchy Summary Item> instances and their accompanying information) can only be provided for instances of those classes that can provide access to a <DRM Geometry Hierarchy> or <DRM Feature Hierarchy> instance; specifically, only for <DRM Environment Root> and <DRM Model> instances. The 6.2.16 Hierarchy summary constraints constraint specifies constraints so that such hierarchy summary information, if provided, will correspond to the hierarchy that it summarizes. An <DRM Environment Root> or <DRM Model> may summarize either its feature hierarchy, its geometry hierarchy, or both, if both are present, but may not provide a summary of a hierarchy that is not present. For example, an empty <DRM Model>, having no hierarchies, is not permitted to have a hierarchy summary.

A hierarchy summary shall be no deeper than the hierarchy that it summarizes; that is, at the point where the hierarchy consists only of primitives, no further <DRM Hierarchy Summary Item> instances shall exist.

Each level k of a hierarchy summary shall correspond to level k of the hierarchy being summarized, and any associations from <DRM Hierarchy Summary Item> instances at level k shall be to hierarchy instances at level k in the hierarchy being summarized. The drm_class field of <DRM Hierarchy Summary Item> indicates the class of instances being summarized, while the multiplicity_meaning and multiplicity field values indicate how many instances at that level are being summarized (possibly exactly, possibly only indicating an order of magnitude, as specified by multiplicity_meaning).

A <DRM Hierarchy Summary Item> may provide a DRM class summary in the form of a list of <DRM DRM Class Summary Item> instances, indicating the DRM classes instanced within the context of the particular hierarchy instance or group of instances being summarized. A <DRM Hierarchy Summary Item> may also provide an EDCS usage summary in the form of a list of <DRM EDCS Usage Summary Item> instances, indicating patterns of usage of EACs and ECCs within the context being summarized.

A hierarchy summary is not required to be as deep as the corresponding hierarchy. The data provider has discretion in determining how much detail will be useful.

4.17.3.6 Primitive summary

A <DRM Model> or <DRM Environment Root> may be provided with a list of <DRM Primitive Summary Item> instances, in addition to any hierarchy summary that may be present, since these concepts provide different functionality. A hierarchy summary describes the hierarchical structure of the hierarchy being represented. A <DRM Primitive Summary Item> represents a common pattern of primitive instances that appear within the scope being summarized, as well as indicating the number of occurrences of the pattern. For example, a <DRM Primitive Summary Item> can be used to indicate quadrilateral <DRM Polygon> instances wherein each <DRM Vertex> has a <DRM Texture Coordinate> and each such <DRM Polygon> has a <DRM Image Mapping Function> and a <DRM Property Value>.

A <DRM Primitive Summary Item> may also be provided with an EDCS usage summary in the form of a list of <DRM EDCS Usage Summary Item> components, indicating patterns of EDCS usage occurring within the pattern of primitive objects being summarized.

4.18 Transmittal structure

4.18.1 Overview

The smallest valid and compliant transmittal shall contain at least the <DRM Transmittal Root> along with a few required instances of metadata such as <DRM Citation>, <DRM Responsible Party>, <DRM Description>, <DRM Data Quality>, and <DRM Transmittal Summary>.

A transmittal in turn may contain zero or more <DRM Environment Root> instances, as well as an optional instance of each <DRM Library> subclass.

Primitive data, along with a variety of other supporting data items (including attributes, organizational objects, and others) may be found as aggregated data under appropriate <DRM Environment Root> or <DRM Library> instances.

4.18.2 Transmittal root

The <DRM Transmittal Root> is the hierarchical root of a given SEDRIS transmittal. It contains fields that describe the version of DRM and EDCS to which the transmittal conforms. It also has a number of required data items that shall be provided. The smallest valid and compliant SEDRIS transmittal shall have a <DRM Transmittal Root> object along with its required subordinate classes.

In addition, a <DRM Transmittal Root> can have a collection of optional data items. One of these is the <DRM Environment Root> object.

4.18.3 Environment root

4.18.3.1 Overview

A <DRM Environment Root> instance is the hierarchical root of all data instanced in a transmittal within the same spatial reference frame (except that found under a <DRM Library> instance). It specifies the characteristics of the spatial reference frame to which it is bound and the spatial extents of the region or volume that its content occupies. An <DRM Environment Root> also provides supporting instances of other data items, such as metadata, that clarify the intended interpretation of the data rooted at the <DRM Environment Root>.

4.18.3.2 SRFs

The srf_info field of a <DRM Environment Root> instance specify the SRF in which its <DRM Feature Hierarchy> and <DRM Geometry Hierarchy> components are specified. A <DRM Environment Root> is constrained to have a <DRM Feature Hierarchy> and/or a <DRM Geometry Hierarchy>. It may not be empty.

In the case where a given <DRM Transmittal Root> specifies multiple <DRM Environment Root> components, the srf_info of each such <DRM Environment Root> shall be distinct. This provides an unambiguous mechanism for representing a data set that, for example, may span multiple GCS cells or UTM zones.

4.18.3.3 Reference origins

A data provider may have applied coordinate conversion or transformation operations to the data represented in the scope of a <DRM Transmittal Root> before the data was represented using the DRM. An instance of <DRM Reference Origin> may be supplied to correlate data from producer to consumer by specifying the original SRF in which the data was represented and an instance of <DRM Location>  specifying the origin of the data in the original SRF.

4.19 Application program interface (API)

4.19.1 Key API concepts

4.19.1.1 Overview

This part of ISO/IEC 18023 specifies a standard API for manipulating transmittals.

The API supports many capabilities including:

1. opening and closing transmittals
2. extracting data from a transmittal,
3. writing new data to a transmittal,
4. modifying existing data in a transmittal, and
5. access to error information.

The API provides retrieval functions that work with both transmittals and DRM objects. The API provides private data types to work with these data elements. An instance of the Transmittal private data type (see 5.4.8 Transmittal) provides access to a transmittal. An instance of the Object private data type (see 5.4.3 Object) provides access to DRM objects within an open transmittal.

4.19.1.2 API operations on base DRM objects

All API functions access a DRM object by using an instance of the Object private data type. Such an instance is termed object handle. Object handles identify implementation dependent information about the object. Once an object handle is retrieved by the API, it can be used to retrieve additional information from the DRM object such as field data and handles to associates, aggregates, and components.

4.19.1.3 API operations on specific DRM objects

The following DRM classes are supported by class-specific API functions:

1. <DRM Image>,
2. <DRM Mesh Face Table>,
3. <DRM Data Table>,
4. <DRM Property Grid>, and
5. <DRM Property Table>.

<DRM Data Table> may not be accessed via an object handle since <DRM Data Table> is an abstract DRM class. Instances of the other four DRM classes all represent complex data that requires special handling. The API provides for the creation, retrieval, and storage of the data associated with these four DRM objects.

4.19.1.4 Opening and closing transmittals

API functions operate on transmittals and their contents. The API functions, 7.3.62 OpenTransmittalByLocation and 7.3.63 OpenTransmittalByName, open a transmittal and return an instance of the private data type Transmittal (see 5.4.8 Transmittal). Such an instance is termed a transmittal handle. The transmittal handle may then be passed to other API functions to identify the transmittal upon which the functions are to operate. A transmittal handle becomes invalid when it is passed to the 7.3.5 CloseTransmittal function that closes a transmittal. When CloseTransmittal is invoked, all resources associated with that transmittal are released.

4.19.1.5 Iterating through data

An iterator is a mechanism that simplifies traversal of DRM object relationships. The following API functions are provided for creating and initializing an iterator for traversing each type of relationship:

1. InitializeAggregateIterator
2. InitializeAssociateIterator
3. InitializeComponentIterator

The function returns an instance of the Iterator private data type (see 5.4.2 Iterator). Such an instance is termed an iterator handle. The iterator handle is subsequently used by 7.3.31 GetNextObject to return an object handle.

The resources associated with an iterator (including its iterator handle and any unretrieved object handles) are freed by invoking 7.3.10 FreeIterator.

4.19.1.6 Filtering data

DRM objects may be selectively retrieved from a transmittal by specifying search criteria in the form of filters. 7.3.7 CreateSearchFilter creates a search filter and returns an instance of the private data type Search_Filter (see 5.4.6 Search Filter). Such an instance is termed a search filter handle. The search filter handle is then passed as a parameter when an iterator is created. The search criteria will be applied during the traversal of that iterator.

4.19.1.7 Inter-transmittal referencing

ITR supports the specification of relationships between DRM objects contained in different transmittals.

EXAMPLE ITR allows a DRM object in one transmittal to associate to a DRM object in another transmittal.

To create an ITR relationship to a DRM object, the DRM object that is being referenced shall be published and the transmittal to which the DRM object belongs shall have a URN. Publishing a DRM object consists of associating the DRM object with a specified string termed a label by invoking 7.3.64 PublishObject. A URN for a transmittal is specified by invoking 7.3.82 SetTransmittalName. If the relationship between DRM objects is aggregation, the aggregating DRM object and the aggregated DRM object shall both be published, and the transmittals containing both DRM objects shall have URNs. Bidirectional associations may be specified in a similar manner.

Resolution is the process of attempting to retrieve the transmittal and the DRM object within that transmittal using the URN and label provided. A DRM object is termed unresolved if it cannot be retrieved. Conversely, a DRM object is termed resolved if it can be retrieved. All DRM objects in an open transmittal are, by definition, resolved. Control of the resolution process is specified by parameter of data type ITR_Behaviour (see 5.2.6.13 ITR_Behaviour).

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 object. This constraint specifies the DRM classes whose instances can be used in 7.3.64 PublishObject and thus published.

4.19.1.8 API implementations

The API supports storage and retrieval of environmental data in multiple encodings as defined in this International Standard. The API provides, for each applicable function, a parameter of data type Encoding that specifies which type of encoding is applicable for the operation of the function.

EXAMPLE  To open transmittal A, the encoding parameter specifies in which encoding transmittal A is stored.

4.19.1.9 Managing memory

Private data types are data types that have objects (methods and resources) that implement the functionality associated with the private data type. Each instance of a private data type has an associated handle that is used to access the corresponding object. Handles may be replicated to provide access through alternate means.

EXAMPLE The Iterator private data type corresponds to the resource that implements iterator functionality according to the parameters associated with each instance.

A Create function associated with the private data type creates an object and returns a handle. Handles may also be returned by functions that provide access to an existing object. Resources (normally memory resources) are associated with each handle and with each object. The resources used by the object and the resources used by its handle(s) are separate. Resources for an object are allocated when the Create function is called. This also allocates resources for a handle that is returned by the Create function. Resources associated with a handle are freed when the Free function that corresponds to the private data type is invoked. The resources associated with the object are freed when there are no handles that access the object.

4.19.2 Manipulation of DRM Objects

4.19.2.1 Accessing transmittals and root objects

Before a DRM object can be accessed, access to the transmittal shall be established using either of the two functions that open transmittals:

• 7.3.62 OpenTransmittalByLocation creates new transmittals or accesses existing transmittals using the URL associated with the transmittal.
• 7.3.63 OpenTransmittalByName accesses existing transmittals through the use of the URN associated with the transmittal.

Once a transmittal has been opened, the root object may be retrieved by using 7.3.45 GetRootObject. If the open function created a new transmittal, the root object can be set by invoking 7.3.78 SetRootObject.

Once the root object has been obtained, access to other DRM objects is possible.

When access to a transmittal is no longer needed, the transmittal may be closed by invoking 7.3.5 CloseTransmittal.

4.19.2.2 Inserting and removing DRM objects

New DRM objects may be created by:

1. instantiating DRM objects,
2. storing the data corresponding to the objects, and
3. creating the transmittal hierarchy by creating the allowed relationships between objects in a transmittal.

Accessing existing DRM objects is specified in 4.19.2.3 Accessing DRM objects.

The following functions are used to create, insert, and remove DRM objects:

• 7.3.6 CreateObject  instantiates an object a specified DRM class in a specified transmittal.
• 7.3.71 RemoveFromTransmittal  removes the specified object from the specified transmittal.

4.19.2.3 Accessing DRM objects

4.19.2.3.1 Retrieving DRM object data

The DRM class, fields, and handles to related DRM objects may be retrieved using the following functions:

• 7.3.24 GetDRMClass retrieves the DRM class of an object in a transmittal.
• 7.3.26 GetFields retrieves the field data of an object in a transmittal.
• 7.3.21 GetComponent retrieves a handle to a single component of an object in a transmittal.
• 7.3.18 GetAggregate retrieves a handle to a single aggregate of an object in a transmittal.
• 7.3.19 GetAssociate retrieves a handle to a single associate of an object in a transmittal.

Retrieval of two other types of DRM object data exist. Retrieval of data table data is described in 4.19.2.7 Access and modification of data table data. Retrieval of image data is described in 4.19.2.8 Access and modification of image data.

4.19.2.3.2 Iterators

For each type of DRM relationship (aggregate, component, and associate) there is a corresponding iterator type. The functions that provide iterator functionality are:

• 7.3.54 InitializeAggregateIterator allocates an iterator of aggregate objects for the specified object.
• 7.3.55 InitializeAssociateIterator allocates an iterator of associate objects for the specified object.
• 7.3.56 InitializeComponentIterator allocates an iterator of component objects for the specified object.
• 7.3.31 GetNextObject retrieves the next object in the iterator.
• 7.3.10 FreeIterator deallocates the iterator specified.

4.19.2.3.3 Searching transmittals

4.19.2.3.3.1 Overview

Iterators provide the following mechanisms for selectively returning DRM objects:

1. search filters,
2. spatial extent, and
3. hierarchy organization.

Each is specified below.

4.19.2.3.3.2 Searching by filtering

A search filter is an instance of the private data type, 5.4.6 Search_Filter. The search filter specifies a set of rules that determine which DRM objects may be returned from a search of a SEDRIS transmittal. The search filter is specified during the initialization of an iterator. The 7.3.7 CreateSearchFilter function creates and initializes a search filter with search rules as specified in 5.3.3.239 Search_Rule. The 7.3.11 FreeObject function is used to free a search filter. Search filters may be used for the following types of searches:

1. objects of specific DRM classes,
2. objects that have associate objects,
3. objects that have associated objects of specific DRM class,
4. objects with components of specific DRM classes,
5. objects with components with specific field values,
6. objects with specific field values,
7. objects with specific field ranges,
8. objects within a specified levels down the tree,
9. objects that meet a specified function, and
10. a combination of the above criteria.

Search filters can be used in the initialization of all three types of iterators.

4.19.2.3.3.3 Searching by spatial extent

A spatial extent is a parallelepiped specified by an instance of 5.3.3.238 Search_Bounds. This spatial extent is passed to 7.3.8 CreateSpatialSearchBoundary, which allocates resources necessary for performing the search, returning a search boundary handle (an instance of 5.4.5 Search_Boundary). The search boundary handle is then passed to 7.3.56 InitializeComponentIterator. The spatial search evaluation operates on the <DRM Location> instances that are components of other DRM objects to determine how an object intersects the search boundary.

Additional parameters that define the search criteria include:

1. specify whether the evaluation is 2D in which case only the x and y values of the locations are considered;
2. specify whether the evaluation is 3D and all location data is evaluated;
3. specify if the boundary of the spatial extent is included in, or excluded from, the search criteria;
4. specify if the DRM object should be fully enclosed or partially enclosed by the spatial extent; and
5. specify if DRM objects should be evaluated using the centroid of the object, the minimum box surrounding the object, or the exact location objects of the object.

DRM objects can also be evaluated separately from iterators using 7.3.9 DetermineSpatialInclusion.

4.19.2.3.3.4 Searching by hierarchy organization

Searching may be done by inclusion or exclusion of branches in a hierarchy. Three different kinds of branch selection are supported:

1. all branches of a specific aggregate type will be excluded;
2. all branches of a specific aggregate type will be included; or
3. branches will be selectively included.

When selective inclusion is enabled, the 5.3.3.102 Hierarchy_Select_Parameters instance provides the link object data that is to be included. This instance specifies which branch(es) of a <DRM Aggregate Feature> or <DRM Aggregate Geometry> instance shall be followed.

4.19.2.3.4 Object IDs

A unique and persistent object ID (a string) for each DRM object is created by the implementation and shall be available on request. The following two functions support object ID:

• 7.3.36 GetObjectIDString retrieves the object ID from the DRM object identified by the object handle.
• 7.3.35 GetObjectFromIDString retrieves an object handle for the DRM object identified by the specified object ID.

4.19.2.3.5 Multiple object retrieval

For greater efficiency, multiple DRM objects may be retrieved by a single function call. The following functions support this capability:

• 7.3.38 GetPackedHierarchy retrieves a hierarchy rooted at the specified object into a 5.3.3.176 Packed Hierarchy.
• 7.3.12 FreePackedHierarchy deallocates the objects and memory associated with the specified 5.3.3.176 Packed Hierarchy.
• 7.3.43 GetRemainingObjectsList iterates over the remaining objects in an iterator and returns all of the objects in one array.
• 7.3.13 FreeRemainingObjectsList deallocates the objects of the array retrieved from 7.3.43 GetRemainingObjectsList.
• 7.3.44 GetRemainingPackedHierarchies iterates over the remaining objects in an iterator and returns an array with a 5.3.3.176 Packed Hierarchy for each remaining object in the iterator.
• 7.3.14 FreeRemainingPackedHierarchiesList frees all resources associated to the data returned from 7.3.44 GetRemainingPackedHierarchies.

4.19.2.4 Inquiry functions

The following inquiry functions are provided for obtaining information about objects, transmittals, and API constructs:

• 7.3.25 GetEncoding returns the encoding associated with a transmittal.
• 7.3.28 GetIterationLengthRemaining returns the number of objects remaining for a given iterator.
• 7.3.34 GetNumberOfPathsToTransmittalRoot determines how many different paths can be traversed from the root object to the given object. It implements a mechanism to determine if a DRM object is shared among many aggregate objects.
• 7.3.37 GetObjectReferenceCount returns the number of object handles that refer to the DRM object that is being referenced by the specified object handle.
• 7.3.42 GetRelationCounts returns the number of aggregate, component, and associate DRM objects with which the DRM object has a relationship.
• 7.3.46 GetSRFInfo returns the SRF information currently in effect for the specified DRM object.
• 7.3.50 GetTransmittalVersionInformation returns the version of the DRM and EDCS used to create the given transmittal by retrieving the data from the Transmittal Root object stored as the root object in the storage format.
• 7.3.51 GetUniqueTransmittalID returns a string identifier for the associated transmittal that can then be compared with identifiers from other transmittals.
• 7.3.61 ObjectsAreSame returns an indication of whether two object handles refer to the same DRM object in a transmittal.
• 7.3.84 TransmittalsAreSame determines if two transmittal handles are referencing the same transmittal specified by a single storage mechanism.

4.19.2.5 Modification of fields

The field values of newly created DRM objects may be specified using 7.3.66 PutFields. The field data of an existing DRM object may be modified using this function if the transmittal has been opened in an access mode that allows modification.

4.19.2.6 Modification of object relationships

Relationships between DRM objects within a transmittal may be created or removed using the following functions:

• 7.3.2 AddAssociateRelationship creates an associate relationship between the specified objects.
• 7.3.3 AddComponentRelationship creates a component relationship between the specified objects.
• 7.3.52 GetUnresolvedObjectFromPublishedLabel creates a placeholder object to be used for creating relationships between objects when one object is not available.
• 7.3.69 RemoveAssociateRelationship removes the associate relationship between the specified objects.
• 7.3.70 RemoveComponentRelationship removes the component relationship between the specified objects.

4.19.2.7 Access and modification of data table and mesh face table data

The selected cells of instances of <DRM Data Table> subclasses may be specified or retrieved using the following functions:

• 7.3.23 GetDataTableData identifies a subset of the data extents and a subset of elements and returns the data in 5.3.3.62 Data_Table_Data.
• 7.3.65 PutDataTableData stores a subset of the data extents and a subset of elements as specified in 5.3.3.62 Data_Table_Data.
• 7.3.30 GetMeshFaceTableData returns the mesh face table data for a subset of the mesh face table.
• 7.3.68 PutMeshFaceTableData stores a subset of the mesh face table data.

4.19.2.8 Access and modification of image data

The data associated with an instance of <DRM Image> may be specified or retrieved using the following functions:

• 7.3.27 GetImageData retrieves the image data in 5.3.3.108 Image_Data.
• 7.3.67 PutImageData stores image data as specified in 5.3.3.108 Image_Data.

4.19.2.9 Cloning objects

Since an instance of the 5.4.3 Object data type is a handle to DRM objects, it is not the object, but just a reference or pointer to the real DRM object in the transmittal. The function 7.3.4 CloneObject provides a new handle to an existing DRM object.

4.19.3 Inter-Transmittal Referencing (ITR)

ITR is supported by the following functions:

• 7.3.82 SetTransmittalName specifies a transmittal URN name for the specified transmittal.
• 7.3.49 GetTransmittalName retrieves the transmittal URN name for the specified transmittal.
• 7.3.64 PublishObject publishes an object to allow it to be used for ITR, otherwise the object cannot be referenced from an object in a  different transmittal.
• 7.3.39 GetPublishedLabels retrieves the object labels of the specified object.
• 7.3.40 GetPublishedObjectList returns a list of all objects that are published in a transmittal.
• 7.3.41 GetReferencedTransmittalList returns a list of all URN transmittal names for the transmittals referenced by the specified transmittal.
• 7.3.59 ObjectIsPublished returns a boolean answer when an object is queried to determine if it has been published.
• 7.3.73 ResolveTransmittalName activates the ITR resolution mechanism and resolves to the storage file for the specified URN transmittal name.
• 7.3.60 ObjectIsResolved determines if the specified object handle contains a reference to the actual object in a transmittal.
• 7.3.72 ResolveObject calls the resolution mechanism on objects that are unresolved; i.e., the call returns FALSE for 7.3.59 ObjectIsResolved.

4.19.4 Data conversion

An application may request that location and/or colour data contained in a transmittal be converted during retrieval into the form needed by the application using the following functions:

• 7.3.81 SetSRFInfo specifies that all that all <DRM Location> objects, retrieved after this function is called, are converted to the desired SRF by changing the DRM class and field values of the DRM objects.
• 7.3.87 UseDefaultSRFInfo specifies that all <DRM Location> objects will be returned with the DRM class and field values stored in the transmittal.
• 7.3.74 SetColourModel specifies that all <DRM Colour> objects are converted to the desired colour model by changing the DRM class and the field values of the DRM objects.
• 7.3.86 UseDefaultColourModel specifies that all <DRM Colour> objects will be returned with the DRM class and field values stored in the transmittal.

4.19.5 Managing temporary application data

As a convenience for processing while traversing transmittals, the API allows data defined by the processing application to be associated with a DRM object. This data is called user data and is managed by the application. It is not considered part of the transmittal. Once the application associates some user data to a DRM object, API maintains the association until the DRM object is freed. The most common use case for user data involves objects with multiple handles in the API. User data associated with a DRM object through one DRM object may be retrieve via any handle to the DRM object. Also, since the application is responsible for memory management of the user data and there are often multiple handles to DRM objects with user data, it is necessary for the application to determine the number of outstanding handles before a DRM object is freed to determine whether or not to free its user data. The following function support user data.

1. 7.3.83 SetUserData stores a handle for user data associated with a DRM object within the scope of that DRM object.
2. 7.3.53 GetUserData retrieves the handle to the user data provided by 7.3.83 SetUserData.

4.19.6 Error handling

4.19.6.1 Overview

Errors are handled by two mechanisms. In the first mechanism, an application may register an error call back function that will be called when a function fails. In the second mechanism, error information may be retrieved upon request. Each mechanism is described below.

4.19.6.2 API call back capabilities

The Status_Logger data type specifies the function definition for user-defined callback functions. The callback function shall support the following parameters:

1. a parameter of type Transmittal_API_Function to contain the API function that failed,
2. a parameter of type Status_Code to contain the reason for the error, and
3. two parameters of type String to contain error message one and error message two.

A function meeting the Status_Logger signature can be registered through the API to be called when an API function fails. The following functions are used to provide this capability:

• 7.3.76 SetGeneralCallback registers the callback function to be used when any API function fails;
• 7.3.77 SetGeneralCallbackForOneFunction registers the callback function to be used when a specific API function fails with any Status_Code; and
• 7.3.80 SetSpecificCallback registers the callback function to be used when a specific API function fails with a specific Status_Code.

• 7.3.75 SetFirstErrorMessage, and
• 7.3.79 SetSecondErrorMessage.

4.19.6.3 API error information retrieval

The API specifies the function 7.3.29 GetLastFunctionStatus returns the status of the last API function that was called along with a human readable string describing the function. This part of ISO/IEC 18023 does not specify the format for the explanatory string nor the level of information contained within.

4.20 Profiles

To ensure a consistent subset of SEDRIS functionality for a widely used set of application-specific requirements, this part of ISO/IEC 18023 supports the concept of profiles. A profile is a formal specification of:

1. which SEDRIS features are required;
2. capacity requirements attuned to the requirements supported by the profile;
3. which optional capabilities are required; and
4. which registered items are required.

The Default Profile is specified that incorporates all of the functionality specified in this part of ISO/IEC 18023 but does not include any registered items. An implementation of SEDRIS is free to exceed the requirements of any profile to which it claims conformance.

Additional profiles may be specified by amending this part of ISO/IEC 18023.

4.21 Registration

4.21.1 Overview

The orderly evolution of SEDRIS functionality is supported through the registration of one of the following in the International Registry of Graphical Items:

1. selection item data type selectors, and
2. set data type members.

Each of these is described in more detail below.

Registration is accomplished by preparing a registration proposal as specified in ISO/IEC 9973 and submitting this proposal using the procedures described therein.

4.21.2 Registration of selection item values

Selection item data types provide for the specification of three types of values:

1. standard values,
2. registered values, and
3. implementation dependent values

Standard items are those values for a selection item data type that are specified in this standard. Support for standard items is as specified in this standard.

Registered items are those values for a selection item data type that have been submitted to the International Registry of Graphical Items using the procedures specified in ISO/IEC 9973. There is no requirement to support registered items unless they are explicitly required by a particular profile and that profile is being supported by an implementation. Implementations not supporting a particular registered value shall ignore such values and report the occurrence of such values as a non-fatal error.

Implementation dependent values are those supported by a particular implementation. They should solely be used for development or experimental purposes. Implementations separate from that which specifies the implementation dependent value shall ignore such values and report the occurrence of such values as a non-fatal error.

A registration proposal for selection data item selectors shall contain the name for the selector as well as the meaning associated with that name. Such meanings shall not duplicate existing selectors and shall not modify the intent of the selection data item data type.

4.21.3 Registration of set members

New members of set data types may be added by registration. The position of new set members in the list of set members shall be as specified by the Registry of Graphical Items. Typically, each new member is appended to the list following either the last standard set member or the last previously registered set member as appropriate.

Only standard set members and registered set members may be in the set. Implementation dependent set members are not allowed.

http://www.iso.ch/iso/en/ittf/PubliclyAvailableStandards/ISO_IEC_18023-1_Ed1.html