4 Concepts

4.1 Introduction and Topics

4.1.1 Topics

Table 4.1 lists the topics of this clause. Each entry in the list 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 part of ISO/IEC 18023 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 is 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 natural (e.g., some region of the Earth) or some constructed object. This latter capability is important in applications that evaluate the characteristics and performance of constructed 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 constructed 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 constructed 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 constructed 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 representation,
2. feature representation,
3. spatial positions and directions,
4. topology,
5. metadata,
6. EDCS attributes (EAs) (see 6 EDCS attributes 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 using 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. Representational polymorphism allows a variable, function, or object to have more than one representation. The DRM supports representational polymorphism by specifying 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. an instance of a DRM class specifying a linear feature, and/or
2. an instance of a 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. an instance of a DRM class specifying a 3D grid of moisture content, using a DRM class specifying a volumetric feature, and/or
2. an instance of 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).

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.

4.2.3 Interchange and interoperability

4.2.3.1 Overview

This part of ISO/IEC 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 DRM as specified in this part of ISO/IEC 18023), a common file format (the SEDRIS abstract transmittal format specified in part 2 of ISO/IEC 18023), and specific encodings such as that specified in part 3 of ISO/IEC 18023. Access to environmental data is through the API specified in 8 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, this International Standard specifies the mechanisms that make environmental data interoperability possible.

4.2.3.2 Reuse of environmental data

This part of ISO/IEC 18023 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). This part of ISO/IEC 18023 makes it possible for such processing to be feasible by allowing data to be viewed from different perspectives and by providing data access facilities so that the 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.

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

EXAMPLE 2  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 defined by the application using the DRM.

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 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 standardizes concrete transmittal formats such as the transmittal format binary encoding (STF) as defined in part 3 of ISO/IEC 18023, and
5. the 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 second objective builds upon the first, and provides the ability to interchange and share environmental data. The 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

The DRM provides the technology necessary to express the representation of an environmental object. Representation of an environmental object requires a data model that allows:

1. the composition and characteristics of that environmental object,
2. the spatial attributes of that environmental object,  and
3. that environmental object’s possible relationships to other environmental objects of interest.

The DRM relies on ISO/IEC 18025, however, for describing the semantics of what an object is (classification) and what characteristics it has (attribution). These descriptions use the entries in the EDCS. New environmental concepts can be added to the EDCS dictionaries without changing the DRM.

Similarly, the DRM relies on ISO/IEC 18026 for specifying the spatial location of an environmental object, its spatial extent, and/or its components in a proper spatial reference frame (SRF). SRFs, 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 SRF 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 DRM classes are provided for creating DRM objects that hold values for location, classification, and attribution. The DRM classes used for the expression of location data use the SRF concepts from the SRM. The DRM classes that deal with the classification and attribution of environmental objects use the EDCS dictionary entries to express object-level semantics.

The DRM objects used 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 is instanced to represent that object or concept.

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 classification, spatial extent, time, and spatial relationships. Such organizations support the creation of unique sets of environmental data tailored to specific applications.

The DRM, in conjunction with the EDCS and the SRM, can also be used to specify environmental data requirements by data modellers 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 DRM syntax and is specifically described for each DRM class in 6.2 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 transmittal. A 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 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

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

EXAMPLE  An aggregate in one transmittal can have an ITR reference to a component object in a different transmittal.

Relationships that use ITR follow the DRM relationship rules. Those DRM objects that can create relationships through ITR are limited by the DRM constraint, 7.2.59 Publishable object. DRM objects that satisfy this constraint are termed publishable.

4.3.3.2 Accessing transmittals using the API

The 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 8 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 relating to coordinate systems within part of ISO/IEC 18023 are specified in ISO/IEC 18026. The SRM specifies the mechanisms and the structure of SRFs as well as the formal definitions for specific SRFs (8 Spatial reference frames), the coordinate systems used within them (5 Abstract coordinate systems), and the reference objects to which they are attached (7 Reference datums, embeddings, and object reference models). 10 SRF operations of ISO/IEC 18026 specifies standard functionality for converting spatial positions and/or directions from one SRF to another. Representation of spatial data as well as the means of converting between representations is provided by the SRM API specified in 11 Application program interface of 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 DRM, 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 and/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 phenomenon 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 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 usage.

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

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 abstract class in italics.

The DRM class diagrams, provided in 6.2 DRM class specifications, omit the operations. The UML attribute listings are also provided in 6.2 DRM class specifications, 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. DRM classes contain all field elements defined within their class definition as well as all inherited from their abstract classes. As a result, all instances of the same class have the same set of field elements and the field elements of a class are specified to reside within the concrete classes regardless of whether the field element was inherited or not.

UML defines an association as a semantic relationship between two or more classes. In UML each end of the association has an IsNavigable Boolean attribute that determines if a class has access to the another class as specified in 2.5.2.3 of ISO/IEC 19501. UML navigability is specified within this part of ISO/IEC 18023 by defining either one-way or two-way directionality. One-way association means that only one class is aware of the association relationship (as indicated by one end of the association having the UML attribute IsNavigable set to FALSE). 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 (as specified by both ends of the association having the UML IsNavigable attribute set to TRUE. 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 the relationships of a two-way association 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; instead, simply a plain, solid 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

A link is a relationship between two class instances and shall be unique between the class instances. Multiple links are allowed between two class instances provided they are differentiated through one of the optional UML mechanisms of role names, relationship names, or association classes. In this part of ISO/IEC 18023, no DRM class instance will have multiple links to another class instance without using an association class. An association class is a class that specifies the semantics of a relationship between classes. Such  a class is termed a link class. Instances of link classes are termed link objects. Link objects specify information that applies to the specific relationship between the two class instances. In the DRM, some association and component relationships have a link class associated with the relationship. The notation for link class is shown in the Figure 4.5 where the box containing “Class C” represents the link class:

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, classification, spatial relationships, and state. Libraries can also be considered 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. In this part of ISO/IEC 18023, concrete classes never have subclasses. Therefore, in this part of ISO/IEC 18023, superclasses are always abstract.

An example of abstract versus concrete classes is shown in Figure 4.6:

In Figure 4.6, 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. In association relationships between two different environmental objects, the meaning of the association is specified using an instance of <DRM Base Association Data>.
2. In association relationships between non-topology DRM class instances and topology DRM class instances, the association indicates that an instance’s topology is represented by the associated object.
3. In association relationships between two topology DRM class instances, the meaning of the association is specified in 4.12 Topology.
4. In all other cases, the meaning of the association is that the associated DRM objects are each distinct representations of the same environmental object.

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 depicted in Figure 4.7. 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.7, the objects Vertex V2 and Vertex V3 are shared by objects Polygon P1 and Polygon P2.

Figure 4.7 — Object sharing

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 7.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.2 DRM class specifications. 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:

Any DRM object not being used solely as a link object that has an entry in either the “Component of (two-way) (inherited)” or “Component of (two-way)” rows will have at least one aggregate from the entries in these rows.

The full set of DRM class specifications is in 6.2 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 groups 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. A concept that encompasses the complete DRM is the <DRM SEDRIS Abstract Base> class. The <DRM SEDRIS Abstract Base> class is the ancestor of all DRM classes. Concrete DRM class instances will eventually derive from it.

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 SRFs can be used to specify the location of an object. In practice, many SRFs 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 DRM relies on the SRM concepts specified in ISO/IEC 18026 to represent location data. Similarly, the API in this part of ISO/IEC 18023 relies on the API defined in 11 Application program interface of ISO/IEC 18026 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, surface, 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 unto itself, and a point-sampled grid of surfaces or volumes (<DRM Property Grid>), among others. The DRM supports the expression of coordinates in 2D, surface, and 3D SRFs through a specific set of DRM classes each associated with a particular type of SRF.

SRFs may be specified using three mechanisms:

1. parameterizing an SRF template,
2. selecting an SRF set along with one of its members, or
3. selected from a list of instances of predefined SRFs.

A particular SRF and its context can be specified by populating an instance of SRF_Context_Info. SRF_Context_Info specifies the parameter values for the desired SRF, a designated spatial surface, and the units of measure for use within the transmittal. More details about the SRF_Context_Info data type may be found in 4.7.2.1 SRFs. See 8 Spatial reference frames of ISO/IEC 18026 for details about specifying SRFs.

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 classes 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 (ECCs) to identify the environmental object. Similarly, EDCS attribute codes (EACs) 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 EACs. 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_Unit_Code, an EDCS_Unit_Scale_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 classes under a branch called geometry representation 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> instance can be associated with one or more other <DRM Geometry Hierarchy> instances, as well as with one or more <DRM Feature Representation> instances. This allows a <DRM Feature Representation> or <DRM Geometry Hierarchy> instance to be represented as an alternate representation of a given <DRM Geometry Hierarchy> instance. A complete treatment of geometry representation concepts is provided in 4.10 Geometry representation.

4.6.6 Environmental concepts as features

In cases where an environmental object is best represented as a higher abstraction of its physical form or when the environmental object has no realizable physical form, the environmental object is represented conceptually. Such environmental concepts include, but are not limited to, borders between countries, point locations representing an object as a single point, road centre-lines, and outlines of buildings, lakes, or regions. These environmental objects are modelled using feature representations. 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 classes under the feature representation branch are used.

Primitive feature objects include point features, linear features, and areal features. 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> instance can be associated with one or more other <DRM Geometry Hierarchy> instances, as well as with one or more <DRM Feature Representation> instances. This allows a <DRM Feature Representation> instance to be represented as an alternate representation of a <DRM Geometry Hierarchy> instance or another <DRM Feature Representation> instance. A complete treatment of feature representation concepts is provided in 4.11 Feature representation.

4.6.7 Distinction between feature representation and geometry representation

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> representation and <DRM Geometry Representation> representation is that a <DRM Feature Representation> representation 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> instance stores location data within the actual representation of the environmental objects. The <DRM Geometry Representation> instnace can then be augmented with topological relationships. Conversely, a <DRM Feature Representation> instance is inherently a topological description.  Furthermore, by making this distinction in the DRM, a specific branching point between the two types of representation 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> class is better suited for immersive visualizations, while the <DRM Feature Representation> class 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 classes 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 representation and feature representation branches. Each DRM aggregate object acts as a container and can itself contain other aggregate objects.

The geometry representation and feature representation branches each have their own independent aggregate objects, with ten aggregate objects for the feature representation branch and fourteen for the geometry representation branch. Since <DRM Aggregate Feature> is a subclass of <DRM Feature Hierarchy> (which itself is a subclass of <DRM Feature Representation>), and since <DRM Aggregate Geometry> is a subclass of <DRM Geometry Hierarchy>, all association relationships that apply to polymorphic representation of <DRM Feature Representation> and <DRM Geometry Hierarchy> instances also apply to all types of aggregate DRM objects. Aggregate DRM 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 classes used to represent 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 item to be referenced or reused one or more times from within the <DRM Environment Root> instance. The following kinds of libraries are supported by the DRM:

1. models of environmental objects that can be instantiated,
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> instance 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> instance numerous times by providing a reference (captured in <DRM Feature Model Instance> and <DRM Geometry Model Instance> classes) from the environment they are modelling to the specific <DRM Model> instance in the <DRM Model Library> instance.

A <DRM Model> instance can be composed of two branches:  feature model and geometry model. This allows a <DRM Model> instance to behave analogously to the <DRM Environment Root> instance, where a feature representation and geometry representation branch is provided. A <DRM Model> instance can instance other <DRM Model> instances. 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 reference other <DRM Model> instances in order to provide a richer and more complex planetary object.

Alternatively, a single <DRM Model> instance without references to other models can represent a single environmental object (for example, a park bench, a door knob, or 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 are discussed in 4.14.2 Models.

4.6.13 Metadata

The DRM supports 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 is also supported in the DRM to allow automated machine-parsing of transmittals, if such metadata is present. Such metadata includes the following: a transmittal summary, included structures, use of EDCS, DRM classes used, and a summary of primitives and hierarchies used.

A detailed description of all DRM metadata classes 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 classes 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, a spatial coordinate system is is a set of rules by which an n-tuple of real numbers, termed a coordinate, uniquely designates the position of a point in space. An SRF (see 8 Spatial reference frames of ISO/IEC 18026) is a means of combining an abstract coordinate system (see 5 Abstract coordinate systems of ISO/IEC 18026) with an ORM (see 7 Reference datums, embeddings, and object reference models of ISO/IEC 18026) to specify 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, 8 Spatial reference frames of 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_context_info field. The following DRM classes specify an srf_context_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 SRF by means of an srf_context_info field, specified using the structured data type SRF_Context_Info. Within this field, the SRF information can be provided as either SRF template parameters, SRF set information, or as an SRF instance code. For 3D SRFs, the srf_context_info field may also specify a DSS that represents a designated spatial surface (see 9 Designated spatial surfaces and vertical offsets of ISO/IEC 18026) to be used in conjunction with some SRFs to provide a reference for the vertical coordinate-component. The specification of each of these data elements is defined in  11 Application program interface of ISO/IEC 18026. In addition, the srf_context_info specifies the units of measure and scales for the coordinate-components.

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 DRM 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 within the SRF specified by the currently applicable srf_context_info field. The context SRF is specified by the nearest aggregating DRM class instance of a DRM class having an srf_context_info field.  The coordinate shall belong to a DRM class that is compatible with the SRF specified by the srf_context_info field value. A coordinate is compatible with an SRF if the DRM class corresponds to the SRF template of the srf_context_info field. If the srf_context_info specifies the SRF through SRF template parameters, the SRF template of the srf_context_info field value is specified by the template_code field. If the srf_context_info field value specifies an SRF set, the SRF template of the srf_context_info field value is the SRF template corresponding to the SRF set per 8 Spatial reference frames of ISO/IEC 18026. If the srf_context_info field value specifies an SRF instance, the SRF template of the srf_context_info field value is the SRF template corresponding to the SRF instance per 8 Spatial reference frames of ISO/IEC 18026.

Table 4.4 specifies the DRM class and its corresponding SRF template:

Table 4.4 — DRM class / SRF template correspondence