ISO/IEC 18023-1 — SEDRIS functional specification
4.1 Introduction and Table of contents
See Table 4.1 for the table of contents for this clause.
Table 4.1 — Table of contents
ISO/IEC 18023-1 — SEDRIS functional specification
4.1 Introduction and Table of contents
See Table 4.1 for the table of contents for this clause.
Table 4.1 — Table of contents
This clause describes the fundamental SEDRIS concepts and how they interact with each other to provide a cohesive data representation system. Provision is made for representing data to the level of detail necessary to support a variety of information technology (IT) applications that will use or depend on SEDRIS-based environmental data.
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 defines these conventions and notations.
Table 4.2 — Document conventions and notations
|
CONVENTION |
EXAMPLE |
DESCRIPTION |
|
<DRM Class> |
SEDRIS Data Representation Model (DRM) class names with the underscores replaced by spaces and the name enclosed in angle brackets (e.g., DRM_Colour_Data = <DRM Colour Data>) |
|
|
Courier font |
FALSE |
Programming constructs including data type names and definitions, enumerated and selection data type values, field names, function parameter names, equations, and pseudo-code. |
|
Italics |
http://www.sedris.org/ |
Internet addresses |
|
not always |
for emphasis |
|
|
“quotes” |
“generic” |
highlight or call attention to |
4.2 SEDRIS and environmental domains
Accurate and unambiguous representation of environmental data is an important component of many information technology applications. SEDRIS technology ensures that environmental representations can be described and transmitted accurately, unambiguously, and precisely.
Authoritative representations of the environment are expected to be internally consistent and conform to physics-based principles. Furthermore, environmental representations shall contain an appropriate integration of terrain, ocean, atmosphere, and space domain data about a region of interest. SEDRIS technology supports the representation of the physical as well as the abstract aspects of each environmental domain. In addition, the actual reference objects being modeled or described can be either real (e.g., some region of the Earth) or some artificial object. This latter capability is important in applications that evaluate the characteristics and performance of artificial objects with respect to environmental effects and impacts, prior to production (e.g., testing and evaluating land, water, air, and space vehicles). To meet these application requirements, SEDRIS technology also supports the representation of 3D models, including various articulations required to convey general system design characteristics, as well as data representation in the environmental domains of:
a. terrain,
b. ocean,
c. atmosphere, and
d. space.
Terrain representation includes data on the location and characteristics of a planetary surface, natural and permanent or semi-permanent artificial features, and related processes including seasonal and diurnal variation. Examples of these include, but are not limited to, the representation of soil and subsurface characteristics, surface elevations, vegetation, roads, signs, vehicles, and buildings with interiors and included objects. The terrain also includes inland waters, as well as the ocean bottom (e.g., bathymetry and sediment types).
Ocean representation includes data on the location and characteristics of natural and artificial features and description of the dynamic processes of the liquid planetary surface and subsurface. Examples of these include, but are not limited to, the representation of wave heights, depth pressure, vessels, buoys and impediments to navigation, temperature, salinity gradients, and acoustic phenomena.
Atmosphere representation includes data on the characteristics of the gaseous envelope surrounding a planetary object and location and characteristics of liquid or solid particles contained within an atmosphere. Examples of these include, but are not limited to, the representation of particulate and aerosol data on haze, dust, smoke, fog, clouds, atmospheric pressure, wind, precipitation, humidity, obscurants, contaminants, nuclear/biological/chemical effects, radiated energy, temperature, and illumination. For the Earth, the atmosphere domain is specified to include the zone extending from the planetary surface to the lower mesosphere as part of a general transition area to the space domain.
Space representation includes data on the location and characteristics of regions beyond the specified upper boundary of a planetary atmosphere. Examples of these include, but are not limited to, the representation of stars and the interstellar medium, natural or artificial celestial objects, neutral and charged atomic and molecular particles and their optical properties, solar winds, space weather, and electromagnetic effects. For the Earth, the space domain generally lies beyond the upper stratosphere as part of a general transition area from the atmosphere domain.
It should be noted that there are no clear boundaries between the various domains. An application may combine environmental domain components as appropriate to fulfill requirements. The challenge in such combinations is to ensure that consistency and correlation are achieved in the resulting environmental representation. SEDRIS technology provides the common framework for meeting this challenge.
4.2.2 Representational capability
This part of ISO/IEC 18023 also provides the requisite facilities necessary to model data according to the requirements of environmental applications. The SEDRIS Data Representation Model (DRM) supports the creation and instantiation of data model constructs specific to the requirements of each application while ensuring that such data can also be reused by other applications as appropriate.
The DRM supports a wide variety of concepts including:
· Geometry
· Features
· Topology
· Metadata
· Attributes
· Classifications
· Relationships
· Data organization
These concepts and others will be described later in this part of ISO/IEC 18023.
The DRM’s ability to support a variety of data models is also the direct result of its support for the polymorphic representation of environmental objects. This means the same environmental object can be represented through various means. For example, a road can be represented as a linear feature while at the same time captured as a series of polygonal facets. Similarly, a cloud can be represented as a 3D grid of moisture content, a volumetric feature object, or represented as a cloudy region within a weather map. Neither representation changes the nature of the object, but rather reflects a particular application’s view of that object. Since the DRM allows multiple representations of environmental objects, applications that hold differing views of environmental objects may be supported.
In addition, the DRM permits the relationships between the various representations to be explicitly expressed. It does this by recording the "association" of the various representations, generally indicating that one form is an alternate representation of the other. The DRM also ensures that the form and structural semantics of the data are fully expressed and can be correctly understood by users.
Environmental data can often be organized based on a variety of schemas including: time, spatial partition, resolution, classification or theme, among others. The data organization capabilities in the DRM allow for a potentially infinite combination of organizational schemas without restricting the user to a particular resolution or order.
The DRM is at the heart of SEDRIS technologies, and is based on object-oriented techniques, the characteristics of which are described using the Unified Modeling Language (UML). It consists of a large variety of object-oriented classes that allow the description of any environmental data, regardless of resolution, domain, or density.
The combination of these classes and their relationships provides a rich, powerful, and expressive schema that can be thought of as the grammar of a language for describing environmental data.
4.2.3 Interchange and interoperability
A producer may create data for a variety of purposes including tailoring a database for use by a particular customer or application. Such purposes are supported through the use of a common object model (the SEDRIS DRM as defined in this part of ISO/IEC 18023) and a common file format (the SEDRIS abstract transmittal format defined in ISO/IEC 18023-2) and the associated binary encoding as defined in ISO/IEC 18023-3. Both are accessed through a common application program interface (the SEDRIS API which is defined in this part of ISO/IEC 18023).
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 defines the mechanisms which make environmetal data interoperability possible.
4.2.3.2 Multiple representation requirements
Depending on context, the data about the same object can require different representations. An expressive language is able to support this multi-representation requirement. The variation of context in data representation is often considered as a “view” of the object being represented.
For example, depending on the application, a building can be "viewed" as a collection of facets describing its physical shape. Alternatively, the building can be "viewed" by its purpose or function, by its position, by how it obscures line of sight, or by other aspects established by the application requirements.
Similarly, a bridge can be “viewed” through different contexts. If route planning and transportation of goods is the context, the location of the bridge and its traffic patterns are of interest. If shipping or boating is the context, its height above the surface of the water or whether the bridge deck can be raised would be of interest. Many other examples exist.
In each of these examples, the data about the environmental object and its characteristics is valid and sufficient for a given application from a particular view and context. SEDRIS supports the representation of such potentially diverse views, without requiring that applications be burdened by conforming to unneeded representations.
4.2.3.3 Reuse of environmental data
A key motivator for interchange and sharing is to reduce production cost by reusing existing data sets. SEDRIS supports the creation and reuse of environmental data by providing a common representational mechanism. The combined power of the DRM, the EDCS, and the SRM makes it possible for various applications to represent their data in ways peculiar to their own requirements. At the same time, the same components, augmented with the SEDRIS API and the STF, enable the sharing and reuse of the 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, as described in 4.2.3.2 Multiple representation requirements. 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.4 Complementary modeling
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, one vendor might produce the spatial positioning data of a city. Another application might produce the visualizations of buildings in the city, while a third might produce street sounds from that city. In a training application, one producer might produce the terrain data upon which a training simulation might occur, another producer might produce the data of a vehicle which is the object of the training, another producer might provide standard dynamic models of features to be encountered by that vehicle, and another might produce 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.
This part of ISO/IEC 18023 is fundamentally about two key aspects:
a. the clear and unambiguous representation of environmental data, and
b. the practical and efficient interchange of environmental data.
To achieve these representation and interchange objectives, this part of ISO/IEC 18023 relies on its five core technology components. These are:
c. the SEDRIS Data Representation Model (DRM),
d. the Environmental Data Coding Specification (EDCS) (see [2.I18025]),
e. the Spatial Reference Model (SRM) (see [2.I18026]),
f. the SEDRIS application programmer interface specification (API), and
g. the SEDRIS abstract transmittal format (ATF) as defined in ISO/IEC 18023-2 and the SEDRIS transmittal format binary encoding (STF) as defined in ISO/IEC 18023-3.
Three of the core technology components of SEDRIS (DRM, EDCS, and SRM) are used to achieve the first aspect of SEDRIS. The combination of these three core 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 aspect of SEDRIS builds upon the first, and provides the ability to interchange and share environmental data. The SEDRIS API and the STF 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.
The DRM and the API are described below. The organization of the abstract transmittal format is defined in ISO/IEC 18023-2 and the binary encoding of STF is in Part 3.
4.3.2 Representation of environmental data
4.3.2.1 Role of DRM, EDCS, and SRM
Representation of an environmental object requires a data model that allows the expression of the object’s semantics, including its possible relationship to other objects of interest, the composition and characteristics of that object, and the spatial attributes of that object. The DRM provides the technology necessary to express the representation of an environmental object. This means the manner in which an environmental object can be organized within a desired and appropriate hierarchy, as well as how that object may relate to other environmental objects, can be specified through the DRM.
The DRM relies on the EDCS, however, for describing the semantics of what an object is and what characteristics it has. Similarly, the DRM relies on the SRM for specifying the spatial location of an object, its extent, or its components in a proper spatial reference frame. This allows both the EDCS and SRM to evolve independently of the DRM. New environmental concepts can be added to the EDCS dictionaries without changing the DRM. The EDCS dictionary entries are used by the DRM to describe what an environmental data object is (classification), or what its specific characterstics are (attribution).
Similarly, 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 leave 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 in turn 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:
a. an aggregate relationship,
b. a component relationship, or
c. an associate relationship.
When such a relationship exists, the DRM object will contain aggregates, components, or associates, respectively. These relationships are described in the DRM by UML diagrams for each data class. The nature of the allowed relationships is generally described in 4.5 Data representation model (DRM) and is specifically described for each class in 6 DRM class definitions.
4.3.3 Interchange of environmental data
A hierarchy of DRM class instances organized according to the principles described in this part of ISO/IEC 18023, and accessible through the SEDRIS API, 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 provide 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 providers generate transmittals as output of their applications or processes. There need not be a one-to-one relationship between data providers and consumers; i.e., a data provider may generate data for more than one consumer and a consumer may receive data from more than one data provider.
SEDRIS transmittals are accessed using the application program interface (API) defined in 7—Application program interface (API). Herein are described the functions which may be used to create transmittals, modify their content, and retrieve the information for use within an application.
SEDRIS transmittals themselves are not an interchange mechanism. Instead, they provide the media-based form for the exchange of environmental data. As a result, there is a requirement for storing the information contained within a transmittal in a form that allows its transport between SEDRIS implementations. This requirement is satisfied through the SEDRIS Abstract Transmittal Format (ATF), as defined in ISO/IEC 18023-2. Other parts of ISO/IEC 18023 define the encodings for the ATF that specify the actual form in which data is stored. While the forms provided by each encoding may differ, the information content is the same for the same SEDRIS transmittal. In particular, ISO/IEC 18023-3 defines a binary encoding referred to as the SEDRIS Transmittal Format (STF). The provision of a standard API (see 4.3.3.1.2 Access) means that applications are decoupled from specific transmittal encodings. Therefore, applications do not need to be concerned about the transmittal encoding used, and instead can interact with any encoding in exactly the same manner, via the API.
4.3.3.1.4 Inter-Transmittal Referencing (ITR)
Inter-Transmittal Referencing (ITR) is the mechanism that allows relationships between objects contained in different SEDRIS transmittals. For example, an aggregate in one transmittal can have an ITR reference to a component object in a different transmittal. Relationships that use ITR still follow the DRM relationship rules. Those DRM objects that can create relationships through ITR are limited by the DRM constraint, Publishable objects.
4.3.3.2 Application Program Interface (API)
The SEDRIS API allows access to, and manipulation of, SEDRIS transmittals. The API decouples the user’s application from the specific format of the transmittal. It also provides access functions that allow data extraction independent of the transmittal’s data organization or presentation. It does this by allowing the calling applications to set a specific extraction context through filters. Under these conditions only data that matches the filter criteria is returned to the calling application. The key API concepts and overall characteristics of the API are defined in 4.6 Application program interface (API), and the specific functions are described in 7 Application program interface (API).
4.4 Related standards and their use
This part of ISO/IEC 18023 depends on other International Standards for definitions which are also applicable outside of the SEDRIS milieu. The following describe the primary companion standards required by this part of ISO/IEC 18023.
The concepts embodied by SEDRIS often require indicating information about the data in a SEDRIS transmittal. This information is provided in the form of classifications of the environmental objects and attributes defining properties of such objects. ISO/IEC 18025—Environmental data coding specification (EDCS) defines 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 defines codes for indicating the units of measure in which an attribute value is 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.
The spatial concepts used within SEDRIS are defined in ISO/IEC 18026—Spatial reference model (SRM) (see 2.[I18026]). This includes not only the formal definitions of the various spatial reference frames but also 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 defined in ISO/IEC 18026 (see 2.[I18026]).
Metadata concepts used in this part of ISO/IEC 18023 are built on the concepts defined in ISO 19115.2—Geographic information – Metadata (see 2.[I19115.2]).
4.5 Data representation model (DRM)
Through the use of the data representation model, users of SEDRIS can describe and articulate their environmental data clearly, while simultaneously using the same representation model to understand data from other users unambiguously. The DRM is an object-oriented data representation model and provides a unified method for describing all data elements and their logical relationships needed to express environmental data in a seamless manner across all environmental domains.
4.5.2 Specification techniques
A data representation model can be thought of as a meta-“data model”. The DRM, however, is more than a simple abstraction of a given data model. Generally, a data model is the specific set of data structures, and their relationships, that define the unique instance of data about a concept or an object. Quite often, data models can be realized as a format or are closely aligned with realizable schemas.
As a result, multiple data models can be realized that describe the exact same object or concept. However, software written to only parse and process a specific data model will not be able to correctly process another data model, even if the other data model describes the same concept or object. For example, the data model for a tree may include a data structure that contains its height, species, age, stem diameter, and location. Another model of the data for the same tree may have a data structure that defines location, material properties of the trunk, stem diameter, and the height of the tree. Clearly the values that can be communicated in one of these data models will not be parsed by software that is designed to expect the other data model.
More importantly, a data model is usually directly tied to the object or concept it models. For example, the semantic of “treeness” is built into the field names and the data structures of the tree modeled in the previous example. Hence, it is not reasonable to express data about a building using the data model for the tree. Instead, a model for data that would represent a building is needed. Furthermore, when it is desired to include additional data about trees, it will be necessary to expand the tree data model, thereby forcing a change in the structure and logic of the software that was designed to process the original data model.
Separating the semantics of what something is from the “data primitives” that can represent the thing is a fundamental concept in SEDRIS. An equally important concept is the factoring out of the common syntax and structural semantics of data models that are used to describe “similar things”.
Combining these two methods (along with other important concepts that will be discussed later) provides the power to use a single schema for representing an endless variety of possible data models. This single schema is the SEDRIS data representation model. The previous tree example will be used to illustrate this point.
Although SEDRIS exists to describe environmental data, there are no data structures in SEDRIS that define a tree, a building, or, in general, any particular environmental object or concept. Instead, the DRM is designed to allow the user to apply the necessary classes to instantiate a desired data model that, in conjunction with using the EDCS, will exactly define a particular object or concept.
The previous example describes an object (a tree) that has both a physical location and a series of attributes, where the attributes differ depending on the data model used to describe the tree. 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 EDCS to specify the semantics and the attributes of a represented object, the data models that described the tree in the previous example can be easily represented.
Furthermore, this general approach allows the same collection of DRM classes used to represent the tree example to define a chair, a bridge, a bush, a rock, or any other object, by simply specifying the appropriate EDCS classification. In addition, since an object may contain zero or more data items to describe its characteristics, the desired EDCS attributes (and their values) can be included to describe the new object.
This simple but powerful methodology is used throughout the DRM to capture a potentially unlimited array of environmental data models, concepts, or objects through a finite set of well-designed DRM classes and their relationships. Since this technique allows the representation of many different data models in a clear and unambiguous manner, it is called the data representation model.
4.5.3 Modeling technique and notation
This part of ISO/IEC 18023 uses UML to model the object classes within the DRM component of the standard. UML notation is used to describe a static object class diagram as well as instance diagrams, which describe example instances of the data conforming to the object class diagram. This section will describe the extensions and deviations to conventional UML use, where UML is defined per ISO/IEC 19501.
UML describes object classes by providing the name, a set of attributes, and a set of operations or behavior 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:
|
Class Name |
|
attribute 1 attribute 2 … |
|
operation 1 operation 2 … |
Figure 4.1—UML object class
For simplicity and readability, the DRM is not presented in the above form. The DRM object diagrams, provided in the DRM class definitions of 6 DRM class definitions, omit the attributes and operations instead only providing the class name in order to highlight the class relationships. The UML attribute listings are also provided in the DRM class definitions, 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.
An extension to UML is made in order to distinguish between object classes that can be instantiated (i.e., concrete classes) and object classes that cannot be instantiated (i.e., abstract classes). The notation used to identify an abstract class is shading the rectangular box (see Figure 4.5).
Figure 4.2—UML associations
In this part of ISO/IEC 18023, UML aggregation, without the UML requirement for non-cyclic aggregations, is used to denote the whole to part relationship between object classes. Thus, for this part of ISO/IEC 18023 aggregation will define a graph of nodes versus the UML aggregation that defines a tree of nodes. Furthermore, within object pairs that have an aggregation relationship, aggregating objects will be referred to as aggregates or parents, whereas aggregated objects will be referred to as components or children.
The UML inheritance relationship, as denoted in 
Figure 4.3, is used in this part of ISO/IEC 18023. Here, classes B and C are both a type of class A, and both inherit from class A.
Figure 4.3—UML inheritance
Cardinality 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. If the multiplicity is exactly one as in Class A in Figure 4.4, the numbering can be removed. Class B is an optional relationship that follows the UML notation. Class C also follows UML notation by using the “*” character to denote “zero or more”. Class D states a minimum per the UML notation. Finally, Class E is an extension to the UML notation stating a specific ordering exists between object classes.
Figure 4.4—Cardinality and optional relationships
The multiplicity of a relationship between a class A and a class B indicates, for a given instance of A, the number of instances of B that may participate in such a relationship with A. For component relationships, if B is a formal component of A, the multiplicity for A in the relationship indicates how many instances of A can share B. Relationships between classes specify the legal possibilities, while relationships between objects shall comply with those possibilities.
The last distinction made between the conventional UML notation and its use in this part of ISO/IEC 18023 concerns UML association classes. These classes are referred to as Link Classes in this part of ISO/IEC 18023 and are used within the context of aggregation and association relationships, a deviation from standard UML modeling.
4.5.4 Introduction to DRM classes
There are hundreds of classes in the DRM. These classes can be grouped into a small number of categories based on whether they describe:
a. the physical shape or form of objects or concepts, used for geometric rendering (referred to as the geometry classes);
b. the more abstract representation of the physical objects, or the non-physical concepts (referred to as the feature classes);
c. topology, as it pertains to geometry topology or feature topology;
d. attributes of objects or concepts, including physical characteristics such as mass, temperature, and material composition;
e. data organization schemes;
f. explicit relationships between classes.
The geometry classes include such primitives as points, vertices, lines, arcs, polygons, and volumes. They also include point sample data represented in n-dimensional uniform and non-uniform grids, including finite element meshes.
The feature classes include such primitives as point features, linear features, and areal features.
Both feature and geometry primitives have their own independent topology data classes for describing mathematical and physical connectivity.
Attributes include such items as location, colour, sound, classification, metadata, and extents.
Data organization classes include methods for organizing data by such concepts as time, distance, type or classification, spatial relationships, and state. Libraries can also be thought of as data organization schemes. Libraries allow for storage savings by reuse of shareable items through referencing an instance of an item in a library.
Explicit relationships describe association between various classes.
To isolate the evolution of the DRM from the API (thereby reducing impact on application software development investments), each class in the DRM is not treated as an independent class with its own method. Instead, all classes in the DRM inherit from a single “superclass”, which is treated as a virtual class.
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:
Figure 4.5—Abstract vs Concrete Classes
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.
An aggregation relationship between two classes A and B is referred to on occasion as the ‘has-a’ relationship, because an instance of A is considered to ‘have’ instances of B as components or parts. 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 defines 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.
For example, consider a case where an abstract class “member”, is defined 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”.
The most common meaning, which applies unless otherwise stated, is that the two associated objects are alternate representations of an abstract object. Associations that do not directly indicate alternate representation are generally used to depict 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. Within the topological classes themselves, associations are used to indicate several types of relationships. These relationships are discussed in 4.5.9 Topology.
4.5.4.4 Multiplicity and sharing
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.
For 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.
Figure 4.6—Object
sharing
The syntactic specification of the structure of DRM classes, types, and relationships between classes does not in itself guarantee complete semantic validity in a given transmittal. A quad-tree organization, for example, may be syntactically correct in specifying four quadrants, but semantically invalid if, for example, they are all identified as corresponding to the same quadrant, or if the spatial extents of the quadrants do not partition some region into quadrants. A number of DRM classes require further specification of what is and is not semantically valid use in practice.
The SEDRIS Data Representation Model specifies a set of constraints that distinguish valid and invalid semantic usage in cases where syntactically valid cases may occur that are not semantically valid. These constraints are defined in 6.2 Constraints.
4.5.5 Representational paradigm
SEDRIS concepts, embodied in the DRM, are depicted using UML as defined in 4.5.3 Modeling technique and notation. UML diagrams are used in the data class definitions in 6 Data class definitions. All of the DRM, using several UML diagram pages, is defined in Annex A UML Diagrams.
Each DRM class contains the information shown in Table 4.3:
Table 4.3 — DRM class description elements
|
Property |
Description |
|
Superclass |
The name of the superclass for the class being defined. |
|
Class |
The name of the class being defined. |
|
Subclass |
The names of any subclasses derived from the class being defined. |
|
Definition |
A description of the class. |
|
Example(s) |
An example of the use of the class. |
|
Inherited field elements |
A definition for each of the fields in the class that are inherited from its superclass hierarchy. This definition is provided for convenience only. The actual definition is contained in the definition of the superclass. |
|
Field elements |
A definition for each of the non-inherited fields in the class, if any. |
|
Associated to (one-way) (inherited) |
A list of inherited DRM classes to which the DRM class defined in this table may contain one-way associations. The DRM classes in the list will not have an association to the DRM class defined in this table, but will be associated by the DRM class defined in this table. This is provided for convenience only. The actual list is defined in the superclass. |
|
Associated to (one-way) |
A list of DRM classes to which the DRM class defined in this table may contain one-way associations. The DRM classes in the list will not have an association to the DRM class defined in this table, but will be associated by the DRM class defined in this table. |
|
Associated by (one-way) (inherited) |
The DRM class defined in this table may have one-way associations by the inherited list of DRM classes. The DRM class defined in this table will not have an association to the DRM classes in this list. This is provided for convenience only. The actual list is defined in the superclass. |
|
Associated by (one-way) |
The DRM class defined in this table may have one-way associations by the list of DRM classes. The DRM class defined in this table will not have an association to the DRM classes in this list. |
|
Associated with (two-way) (inherited) |
A list of inherited DRM classes that may contain two-way associations to the DRM class defined in this table. The DRM class defined in this table will have an association to the DRM classes in this list. This is provided for convenience only. The actual list is defined in the superclass. |
|
Associated with (two-way) |
A list of DRM classes that may contain two-way associations to the DRM class defined in this table. The DRM class defined in this table will have an association to the DRM classes in this list. |
|
Composed of (inherited) |
A list of inherited DRM non-metadata classes of which the class being defined is composed in a two-way manner. This definition is provided for convenience only. The actual list is contained in the definition of the superclass. |
|
Composed of |
A list of DRM non-metadata classes of which the class being defined is composed in a two-way manner. |
|
Composed of (metadata) (inherited) |
A list of inherited DRM metadata classes of which the class being defined is composed in a two-way manner. This definition is provided for convenience only. The actual definition is contained in the definition of the superclass. |
|
Composed of (metadata) |
A list of DRM metadata classes of which the class being defined is composed in a two-way manner. |
|
Component of (inherited) |
A list of DRM classes that may aggregate the DRM class defined in this table. This definition is provided for convenience only. The actual definition is contained in the definition of the superclass. |
|
Component of |
A list of DRM classes that may aggregate the DRM class defined in this table. |
|
Constraints |
A list of constraints which apply to the class being defined. |
|
Notes |
More detailed notes about the various items in the class definition. |
|
Class diagram |
A UML diagram depicting the relationships of the class being defined including its superclass, its subclasses, its associated classes, and the classes of which it is composed. |
The full set of DRM class definitions may be found in 6 Data class definitions.
Several key concepts in the DRM transcend the definition 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.
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 definition 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 interrelaionship, and their operations is generally complex and detailed. As a result, the DRM does not define SRFs, but rather it relies on the concepts defined in the Spatial Reference Model (SRM) 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 defined in the SRM. The DRM also permits the coexistence of different SRFs in a transmittal, so 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 stand-alone 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.5.7 Spatial concepts.
4.5.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 defines specific DRM classes used to provide the EDCS codes for environmental object semantics as discussed in 4.5.5 Semantic attribution in the DRM.
4.5.6.4 Environmental concepts as data tables
A significant portion of environmental data is represented as point-sampled data. Such data represents ocean volume or columns, atmospheric volumes, layers, or columns, space data, surface elevation or surface characteristics data, image data, and point sampling of 3D solid objects. The DRM represents these through the use of <DRM Data Table> and <DRM Property Grid> objects.
A <DRM Data Table> is an n-dimensional array of cells, where each cell may contain one or more data elements. A <DRM Property Grid> is a special version of <DRM Data Table>, where at least one of the axes of the table is based on spatial locations.
The cells of a table may contain as many data elements as needed for the particular data representation needed. However, the “signature” of the table defines the type of data elements in a given cell, and how those elements should be stored. Cells of a data table may be sparse or full depending on the nature of data being represented. EDCS attributes are used to define the properties of the elements of each cell.
EDCS classification entries are used to define the meaning of the entire table. Each axis of a table can be defined independently for its spacing and units. Unlike most other DRM objects, specific API access and manipulation calls exist for handling data tables.
The DRM objects involved in the representation of tabular data are further detailed in 4.5.9 Data tables.
4.5.6.5 Environmental concepts as geometry
Certain environmental objects should be represented in a manner as close to their physical appearance as possible. These include the representation of 2D and 3D lines, 2D and 3D solid or point-sampled surfaces, and solid or point-sampled volumes. Often these representations are used in realistic visualization applications. In general, when modeling of an environmental object requires an abstraction that closely resembles its physical appearance and is intended to preserve its geometrical shape, the DRM objects under a branch called geometry are used.
Primitive geometry objects include point, line, surface (such as polygon and NURBS), and volume geometry. In addition, finite element mesh and property grid representations are also considered geometry objects.
The primitive geometry objects can be organized in a number of ways described in 4.5.6.10 Organizing principles under Key DRM concepts and in 4.5.13 Organizing principles for details. Collections of primitive objects when organized in this manner are called geometry hierarchy objects. Each <DRM Geometry Hierarchy> object can be associated with one or more other <DRM Geometry Hierarchy> objects, as well as with one or more <DRM Feature> objects. This allows a <DRM Feature> or a <DRM Geometry Hierarchy> object to be represented as an alternate representation of a given <DRM Geometry Hierarchy>. Therefore, a variety of representations and details can be used to represent an environmental object that is represented as a collection of geometry primitives. A complete treatment of geometry concepts is provided in 4.5.10 Geometry.
4.5.6.6 Environmental concepts as feature
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. Examples of such environmental concepts include, but are not limited to, borders (for example, between countries), point locations representing an object as a single point, road centerlines, and outlines of buildings, lakes, or regions. Often these representations are used in analysis or 2D map applications. In general, when modeling of an environmental object requires a higher degree of abstraction of that object, the DRM objects under the feature branch are used.
Primitive feature objects include point features, linear features, and areal features. And unlike geometry objects, the representation of location of feature objects is directly through their topology primitives.
The primitive feature objects can be organized in a number of ways described in 4.5.6.10 Organizing principles under Key DRM concepts and in 4.5.13 Organizing principles for details. Each <DRM Feature> object can be associated with one or more other <DRM Geometry Hierarchy> objects, as well as with one or more <DRM Feature> objects. This allows a <DRM Feature> to be represented as an alternate representation of a <DRM Geometry Hierarchy> object or another <DRM Feature> object. Therefore a variety of representations and details can be used to represent an environmental object that is represented as a feature primitive or a collection of feature primitives. A complete treatment of feature concepts is provided in 4.5.11 Features.
4.5.6.7 Distinction between features and geometry representations
The DRM provides the <DRM Feature> versus <DRM Geometry> distinction as a mechanism to provide a fundamental separation for environmental object representations. The distinction between the <DRM Feature> representations and <DRM Geometry> representations is that a <DRM Feature> representation removes all spatial information not required to support spatial connectivity; i.e., it only requires topology. The location data of a feature representation is stored within the topology DRM classes. A <DRM Geometry> representation stores location data within the actual representation of the environmental objects. The <DRM Geometry> representation can then be augmented with topological relationships. Conversely, a <DRM Feature> representation is inherently a topological description. Furthermore, by making this distinction in the DRM, a specific branching point between two types of representations is provided in the form of a feature representation branch and a geometry representation branch at the second level of a Transmittal structure (i.e., at the <DRM Environment Root>).
A second distinction for feature representation versus geometry representation is data application or data usage. A <DRM Feature> representation is more suited to artificial reasoning applications such as route planning and minimizing route costs as in geographic travel systems. While both types of representations can be used for the same applications, each representation provides better suited mechanisms. Thus, the <DRM Geometry> representation is better suited for immersive visualizations, while a <DRM Feature> representation is better suited for visualization of abstractions of an environment such as maps.
4.5.6.8 Representational polymorphism
The association links between <DRM Feature> and <DRM Geometry Hierarchy>, <DRM Feature> and <DRM Property Grid>, as well as the self association of <DRM Feature> to itself and <DRM Geometry Hierarchy> to itself provide a powerful mechanism for the alternate representation of the same environmental object. This polymorphic aspect of the DRM enables it to serve a variety of applications that tend to deal with the same environmental objects but differ in their context or view of that object. Examples of environmental data that can be used in this manner are many and varied, providing a strong binding between the diverse and possible representations of an object. This in turn enables data producers to articulate the same environmental object in more than one representation, if they choose to do so. It also affords the data consuming applications the ability to pick the most useful representation of an object, if multiple representations are available in a given transmittal.
The DRM allows the representation of an independent topology for both features and geometry. Topology is inherent, and therefore required, in the representation of environmental objects as features. Often, feature data is used in analysis or planning applications. This use demands a degree of connectivity between feature primitives in order to reduce the computational burden of finding adjacent and connected environmental objects. As a result, the spatial location of feature-based data within the DRM can only be obtained through the use of the topology relationships described below. Topology of the feature-based objects is often used by applications that require information about connectivity in order to answer questions such as navigation through an environment, or adjacency of environmental objects.
Unlike the required feature topology, geometry topology is optional. Geometry objects may contain full topology about the connectivity of the surfaces and facets they depict. However, such topology is not a required component of geometry objects.
The DRM supports five topology levels for both features and geometry as described in 4.5.12 Topology. In addition, the DRM provides mechanisms for capturing stacking information (over and under) without the need for 3D topology. Such information is needed by applications that need to know what is above or below an environmental object, but whose use of topology information is more limited. Examples of such cases include multi-level road network systems (such as multi-deck roadways), bridges, and multi-level buildings.
DRM objects involved in both geometry and feature topology representations are discussed in 4.5.12 Topology.
4.5.6.10 Organizing principles
The DRM allows primitive data to be organized in a number of ways. The DRM classes that provide organization hierarchies are found in both the geometry and feature branches. Each DRM aggregate object acts as an organizing container, and can contain one or more containers. This recursive capability in the DRM allows modeling of simple as well as complex data organization schemes.
The feature and geometry branches each have their own independent aggregate objects, with ten aggregate objects for the feature branch and fourteen for the geometry branch. Since a <DRM Aggregate Feature> is a type of <DRM Feature Hierarchy> (which itself is a type of <DRM Feature>), and since a <DRM Aggregate Geometry> is a type of <DRM Geometry Hierarchy>, all association relationships that apply to polymorphic representation of <DRM Feature> and <DRM Geometry Hierarchy> also apply to all types of aggregate objects. Therefore, not only aggregate objects can recursively organize data as needed, but they can also associate to other aggregate (and primitive) data at any and all levels of the instanced hierarchy. In everyday applications and data sets, there is no one prescribed way to organize data. As a result, the DRM aggregate objects are also not limited to a predefined way to organize data.
Data can be organized by time, by classification, by spatial extent or by spatial partitioning, as well as by a number of special use cases, such as level of detail, alternate hierarchy, and separating planes, among others.
A complete treatment of DRM objects used as organizing principals is provided in 4.5.13 Organizing principles.
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>. If the instantiation or use of an object is not singularly unique within the environment, yet the object will be used multiple times, libraries can save unnecessary storage space by serving as a repository for such objects.
Libraries of 3D models/icons, images, sounds, map symbols, data tables, colour tables, and attribute sets are supported by the DRM. A discussion of libraries, as a construct for sharing data, is provided in 4.5.14.3 Libraries.
4.5.6.12 Models and instancing
Models in a <DRM Model Library> can be instanced in the environment and can be given local attributes that make them appear as if they are unique. This capability in the DRM allows data modelers and data producers to reuse the same <DRM Model> numerous times by providing a pointer (captured in <DRM Feature Model Instance> and <DRM Geometry Model Instance> classes) from the environment they are modeling to the specific <DRM Model> in the <DRM Model Library>.
A <DRM Model> can be composed of two branches, one called feature model, the other geometry model. This allows a <DRM Model> to act analogous to the <DRM Environment Root>, where a feature and geometry branch is provided. A <DRM Model> can recursively instance other <DRM Model>s. This capability can be used to build very complex worlds and reuse them in a broader context. For example, a representation of a solar system may include a region of space within the <DRM Environment Root>, where each celestial object can be instanced by pointing to a <DRM Model> in the <DRM Model Library>. Each such model (celestial body) can in turn point to other <DRM Model>s in order to provide a richer and more complex planetary object.
Alternatively, a <DRM Model> can be a simple model of an 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 overriding attributes of the base model. Sharing, instancing, and applying transformation to a model is discussed in 4.5.14.2 Models.
Metadata can be assigned to most DRM objects. This includes organizational objects (such as aggregates), primitive data, data tables, and libraries among others.
The DRM allows for inclusion of metadata that is intended for use by humans as well 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 defined in ISO 19115.2 (see [2.I19115_2]).
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.5.17 Metadata.
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.5.18 Transmittal structure, and constructs for sharing data discussed in 4.5.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.5.15 Constructs for presenting data and Error! Reference source not found. Constructs for controlling dynamic data.
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.
A spatial reference frame, or SRF, is a concept defined in the Spatial Reference Model. Briefly, in the SRM, and thus in the DRM, a coordinate is an ordered pair or ordered triple of real numbers designating the position of a point, and is defined in some coordinate system. A coordinate system is a set of rules by which a coordinate can spatially relate a location to a unique origin and associated axes. A spatial reference frame ties a coordinate system’s origin to some Object Reference Model. A coordinate is always defined in the context of some spatial reference frame to avoid ambiguity. A spatial reference frame in the DRM is specified by an instance of a DRM class that has an srf_parameters field, where the field specifies SRF parameters information as defined by the SRM.
Coordinates are specified in the DRM as instances of <DRM Location> (see 4.5.4.3 Location) or as coordinates within gridded data in the scope of a <DRM Property Grid> instance. In the DRM, a coordinate appears only within an object subtree (that is, a tree of aggregate/component relationships) rooted at an instance of some DRM class that specifies a spatial reference frame via an srf_parameters field. Further, the coordinate shall be specified so that it is defined within that spatial reference frame.
Five classes specify srf_parameters: <DRM Environment Root>, <DRM Property Grid>, <DRM Model>, <DRM Image Anchor>, and <DRM Reference Origin>. Each such class specifies its spatial reference frame by means of an srf_parameters field, defined using the structured type SRF_Parameters as defined in the Spatial Reference Model. In the case of <DRM Property Grid>, 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 the other cases, the coordinate data is specified by <DRM Location> instances (that is, instances of concrete subclasses descended from <DRM Location>).
<DRM Location> has two subclasses, both of which are abstract: <DRM Location 2D> and <DRM Location 3D>. These correspond to the SRM concepts of a Coordinate_2D and a Coordinate_3D. The subclasses of <DRM Location 2D>, in turn, correspond to the 2D SRFs defined by the SRM, and the subclasses of <DRM Location 3D> correspond to the 3D SRFs so defined.
An instance of a concrete subclass of <DRM Location 3D> shall appear only within the context of a compatible set of SRF parameters. For example, a <DRM SM Location 3D> shall appear only within the scope of an object that specifies SRF_Parameters defined for a three-dimensional solar magnetic (SM) spatial reference frame. A <DRM Location 3D> shall never appear in the scope of an object that specifies 2D parameters.
A <DRM Location 2D> shall appear only within the context of a compatible set of SRF parameters. In the case of 2D, a <DRM Location 2D> can be completely specified within the context of an object that requires 3D parameters. As long as the respective SRFs are compatible, a <DRM Location 2D> may appear in a 3D context. For example, a <DRM EC Location 2D> may appear within the context of an AEC spatial reference frame. In the cases where this occurs, the <DRM Location 2D> is a conformal point; that is, it represents a location in 3D space where the location lies on the reference surface for that SRF. A 2D coordinate is considered to lie on the object reference surface used to specify the spatial reference frame in which it is defined. In the DRM, this may be further refined through the use of <DRM Reference Surface> (q.v.).
Orientation information, as distinct from location information, is represented in the DRM by two mechanisms: <DRM Reference Vector> and <DRM World Transformation>. The former is covered below; the latter, in 4.5.7.5 InterSRF Relationships.
A <DRM Reference Vector> specifies an SRM Vector_3D, together with a vector_type field supplying the semantic meaning of the SRM Vector_3D. For a given <DRM Reference Vector> instance, the semantic meaning specified by the vector_type field may be further qualified by a <DRM Property Value> instance supplied as a component of the <DRM Reference Vector> (see 4.5.5 Semantic Attribution in the DRM for further information). The Vector_3D specified by a <DRM Reference Vector> instance shall always be a unit_vector.
A <DRM Reference Vector> instance always has a <DRM Location> component, which is either a direct component of the <DRM Reference Vector> instance, or is supplied by the context of the <DRM Reference Vector>, subject to the 6.2.50 Required Reference Vector Location constraint. The <DRM Location> component is needed to permit the API to convert <DRM Reference Vector> instances between vector and non-vector space spatial reference frames.
The SRM, and consequently the DRM, supports several spatial reference frames that do not have a vector space structure. Without additional information, the unit_vector of a <DRM Reference Vector> would not be meaningful in such spatial reference frames since the standard dot product of two vectors is not the correct inner product for such non-vector spaces. Consequently, for each spatial reference frame supported by the SRM that lacks a vector space structure, a Local Tangent Plane vector space appropriate for each <DRM Reference Vector> instance is embedded in the spatial reference frame, and it is this Local Tangent Plane vector space that is used to define unit_vector information.
The spatial reference frames supported by the SRM that lack vector space structure fall into two categories: those for which the Object Reference Model (ORM) is an oblate spheroid or a sphere, and those for which this is not the case.
For a spatial reference frame having an ORM that is an oblate spheroid or a sphere, the canonical LTP space at a point is defined as follows. Given a point location in the spatial reference frame under consideration, the canonical LTP space at the point is the Local Tangent Plane space tangent to the ORM at the surface location that shares the same ray from the centre of the ORM as the given point, where the Local Tangent Plane's spatial reference parameters x_offset = y_offset = azimuth = 0.0. In such a spatial reference frame, the unit_vector of a <DRM Reference Vector> instance is interpreted as a vector in the canonical LTP space defined at the position specified by the <DRM Location> component of the <DRM Reference Vector>.
For a spatial reference frame having an ORM that is not an oblate spheroid or a sphere, vectors are interpreted in the corresponding celestiocentric spatial reference frame, such as the Geocentric spatial reference frame.
4.5.7.5 InterSRF relationships
Coordinate information shall always be specified in a compatible spatial reference frame. There are cases, however, when it is desirable to specify a generic representation of some entity in a Local Space Rectangular (LSR) SRF and then reference the generic representation in another SRF.
An instance of <DRM World Transformation> is used to specify a transformation from a source context to a target context, where the source context is a <DRM Model>, always defined within an LSR SRF (either 2D or 3D) and the target context may be defined within any SRF.
A reference surface is a surface defined to provide the vertical resolution of <DRM Location 2D> instances found in a transmittal. For example, consider a representation H of a house containing some representation W of an exterior wall. The data provider wishes the locations specifying the base of W to lie on the representation of the terrain surface wherever H is instanced, and chooses to use <DRM Location 2D> which will conform to terrain surface rather than specifying the exact vertical values for those locations. In order to conform the <DRM Location 2D> instances to a terrain surface, the <DRM Reference Surface> shall associate to a <DRM Geometry Hierarchy> which captures the terrain surface.
A <DRM Spatial Extent> instance specifies a bounding rectangle (if 2D) or a parallelepiped (if 3D) within which the DRM components representing environmental data are contained. This includes rectangles with area zero and parallelepipeds with volume zero.
A <DRM Spatial Extent> instance has two ordered <DRM Location> components, specified in the SRF in which the <DRM Spatial Extent> has been specified. The ordering of these components is semantically significant because the first <DRM Location> specifies the minimum coordinate values of the spatial domain, while the second specifies the maximum coordinate values. Conceptually, these <DRM Location> instances can be considered as the “lower left” and “upper right” corners of a bounding box within which all coordinates in the corresponding component tree are located.
Note that in the case of an SRF such as Geodetic, the coordinate values of the second <DRM Location> may be either greater than or less than those of the first <DRM Location>, depending on the particular region for which spatial domain information is being specified.
An instance of <DRM Perimeter Data> specifies the perimeter of the region corresponding to the object of which it is a component. In the case of <DRM Aggregate Feature> or <DRM Aggregate Geometry>, the aggregate represents some aspect or aspects of the region in question. In the case of <DRM Sound Instance>, the meaning is more specialized (see 4.5.15.5 Sound for details). <DRM Perimeter Data> instances also occur as link objects in a perimeter-related organization (see 4.5.13.7 Perimeter for details of its usage). The semantics of how a <DRM Perimeter Data> specifies the perimeter of the given region are the same in all these use cases.
The N ordered <DRM Location> components of a <DRM Perimeter Data> instance specify the perimeter of the given region by specifying an implicit line segment between each pair of <DRM Location> components i, i+1 for i in the range 1, …, n-1, where the components are numbered starting at 1. There is a last implicit line segment connecting the nth <DRM Location> with the first <DRM Location> component so that the <DRM Perimeter Data> specifies a connected boundary. <DRM Perimeter Data> is constrained (see 6.2.38 Non-selfoverlapping perimeter data locations for details) so that the boundary thus specified does not overlap with itself.
The <DRM Volume> class is used to specify instances of volumes in space. Its concrete subclasses exist to bind the volumes thus specified to specific semantic meanings and syntactically constrain their usage to valid contexts, so a discussion of the abstract <DRM Volume> class itself is sufficient to cover its subclasses as well in regard to their expression of boundary information. (Other classes that represent volumetric information are <DRM Volume Level Of Detail Data> and <DRM Volume Light Behaviour>, but in terms of specifying the location and shape of their volume information, these DRM classes have the same structure as <DRM Volume>.)
A <DRM Volume> is centred at a <DRM Location 3D>, which is specified as a component of the <DRM Volume>. The shape of the volume is specified by a separate component, an instance of one of the concrete subclasses of <DRM Volume Extent>. This design permits a common volume shape to be specified once and reused at many different locations to specify different volumes.
<DRM Volume Extent> has three concrete subclasses: <DRM Cylindrical Volume Extent>, <DRM Parallelepiped Volume Extent>, and <DRM Spherical Volume Extent>. <DRM Cylindrical Volume Extent> specifies its major and minor axes as <DRM Reference Vector> components, while the axis lengths and cylinder height are specified by the fields of the <DRM Cylindrical Volume Extent> itself. <DRM Parallelepiped Volume Extent> specifies three ordered <DRM Reference Vector> components as the axes of the parallelepiped, the lengths of which are specified as field values within <DRM Parallelepiped Volume Extent>. Finally, <DRM Spherical Volume Extent> specifies the radius of the sphere in question.
The use of <DRM Reference Vector> instances permits these volume constructs to be subjected to coordinate conversion and transformation without undue distortion of the volume shapes.
4.5.8 Semantic attribution in the DRM
4.5.8.1 Use of EDCS attributes
The DRM uses EDCS Attribute Codes (EACs) to specify the semantic meaning of some related set of data values (sometimes a singleton), where the data type of that set is constrained to conform to that specified by EDCS for the EAC in question.
An EAC may be specified in the following contexts in the DRM:
a. As the state_tag of a <DRM State Related Features> or <DRM State Related Geometry> instance;
b. As the axis_type of a <DRM Axis> instance;
c. As the meaning of a <DRM Variable> instance; and
d. As the meaning of a <DRM Property> instance.
4.5.8.1.2 <DRM State Related Features> or <DRM State Related Geometry>
In the case of state-related aggregations, state_tag 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; see 4.5.10.11 State for details. Since EDCS attributes that are used as state tags are restricted to those EDCS attributes having percentage or enumerated values, unit and scale information need not be specified.
In the remaining cases, 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 DATA_TABLE_COMPONENT is constrained by 6.2.21 Index codes within tables to appear only within the context of a <DRM Data Table> with appropriate characteristics. Except for the special cases covered by Index_Code and Variable_Code, the information represented by Element_Type constructs consists of EACs.
For an instance of a concrete subclass of <DRM Axis>, the axis_type is specified by an Element_Type value, and specifies the semantic meaning of the tick marks for that axis. In the case of <DRM Regular Axis>, this applies to the first_value and spacing fields; in the other subclasses, it applies to an explicit array of axis values. The <DRM Axis> classes that represent numeric data have EDCS Unit and EDCS Scale fields so that the values’ meaning is unambiguous, and they are constrained to be consistent with the axis_type (see 6.2.4 Axis type restrictions for details).
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>. A <DRM Variable> may represent a numeric quantity, so <DRM Variable> has EDCS Unit and EDCS Scale fields with appropriate constraints (see 6.2.58 Variable meaning restrictions). <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.
For an instance of a concrete subclass of <DRM Property>, the EDCS classification is specified by an Element_Type value, and specifies the semantic meaning of the set of data values bound to that <DRM Property>. Any subclass of <DRM Property> may represent numeric data, so <DRM Property> has EDCS Unit and EDCS Scale fields with appropriate constraints (see 6.2.45 Property meaning restrictions). 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>.
A <DRM Property Characteristic> instance specifies details about the representation of a property, such as maximum value, minimum value, measurement error, and (in the case of multiple value sets) sentinel values.
A <DRM Property Characteristic> instance appears only as a component of some <DRM Property> instance (or instances). It specifies a value and a semantic meaning for that value, where the semantic meaning is represented by an EDCS Metadata Code, such as TOLERANCE. See 6.2.44 Property_Characteristic restrictions for semantic constraints ensuring that <DRM Property Characteristic> information is meaningful within the context of a <DRM Property>.
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.
A <DRM Table Property Description> is always a component of a <DRM Data Table>, and specifies the semantic meaning of the corresponding set of elements within the cells of the <DRM Data Table>. The <DRM Table Property Description> also specifies the data type of the data, but the data itself is contained by the cells of the <DRM Data Table>. (See 4.5.6 Data tables for further details.)
Within the scope of a <DRM Aggregate Feature> or <DRM Aggregate Geometry>, many <DRM Property Value> instances may appear that specify values of the same property for different locations, but subject to a common set of constraints, such as a common measurement error, or (collectively) minimum or maximum value.
This information can be provided with the class <DRM Property Description> which serves to provide context for all <DRM Property Value> instances within the scope of a <DRM Aggregate Feature> or <DRM Aggregate Geometry> of which the <DRM Property Description> is a component, such that the <DRM Property Value> meaning values match that of the <DRM Property Description>.
For example, consider a <DRM Property Description> specifying a meaning of WIND_SPEED and a <DRM Property Characteristic> specifying a TOLERANCE value. The information being provided is that <DRM Property Value> instances falling within the scope of that <DRM Property Description> and having the same meaning of WIND_SPEED also have the given TOLERANCE value.
In addition, <DRM Property Description> may have qualifying <DRM Property Value> components, which then apply to all <DRM Property Value> instances within that scope that have matching meaning field values. For example, in a <DRM Aggregate Geometry> containing many <DRM Polygon> instances that specify different EMISSIVITY values, the aggregate can contain a single <DRM Property Description> component specifying the EM_BAND.
4.5.8.2 Use of EDCS classifications
The DRM uses EDCS Classification Codes to specify the semantic meaning of what some collection of DRM objects represents in the environment; that is, to classify those DRM objects.
An EDCS Classification Code (ECC) may be specified in the following contexts in the DRM:
a. As the tag of a <DRM Classification Data> instance;
b. As the environmental_domain of a <DRM Environmental Domain Summary> instance;
c. As the classification of a <DRM Reference Surface>;
d. As the component_data_table_ecc of a <DRM Table Property Description>;
e. As part of the texel data of a <DRM Image>, depending on the image_signature.
For <DRM Classification Data>, <DRM Environmental Domain Summary>, and <DRM Reference Surface>, the ECC specified is subject to qualification by <DRM Property Value> components, as discussed in 4.5.5.2.2 Qualification.
The details of the specific interpretation of an ECC depend on the context in which it appears. In the case of <DRM Classification Data>, the tag field specifies the semantic meaning of the object to which the <DRM Classification Data> is being applied, as defined in 6 DRM class definitions. 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.
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 on the <DRM Classification Data> instance, which, 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.
The abstract <DRM Data Table> class defines an n-dimensional array of data cells. The dimension n is determined by the number of ordered <DRM Axis> objects aggregated as components by a given <DRM Data Table>. Each <DRM Axis> component determines the number cell ranks in its coordinate dimension. Consequently, a <DRM Data Table> with two axes of size m and n will have m ´ n cells. A <DRM Data Table> also aggregates an ordered list of <DRM Table Property Description> components. This list constitutes the signature of the table. Each cell contains as many data items (properties) as there are <DRM Table Property Description> components in the signature. These <DRM Table Property Description> components describe each data item: its meaning, the units of measure, and the storage type. However, the dimensions and signature do not fully describe the intended meaning of the <DRM Data Table>. For that a <DRM Classification Data> instance is provided as a component of each <DRM Data Table> instance.
The <DRM Data Table> class defines 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>. In order to use this class the following shall be specified: the spatial reference frame that preserves the "griddedness" of the cells, the orientation and location of one cell in space, and which <DRM Axis> components are the spatial axes.
In an analog to a <DRM Geometry Model> instance, which is referenced at a spatial location using a <DRM Geometry Model Instance> that provides a <DRM Transformation>, the DRM provides the <DRM Property Grid Hook Point> class, a subclass of <DRM Geometry Hierarchy>, to tie a <DRM Property Grid> instance to a spatial location within the geometric context in which it is to be referenced. A <DRM Property Grid Hook Point> instance specifies the spatial location as a <DRM Location> component, while a <DRM Property Grid> instance specifies which of its cells corresponds to that location.
Note that a <DRM Property Grid> instance specifies its own SRF. This may or may not match the SRF in which the <DRM Property Grid> is instanced. The spatial_axes_count shall correspond to the <DRM Property Grid>'s own SRF, rather than that of whatever context instances the <DRM Property Grid>. The spatial_axes_count field specifies which of the ordered <DRM Axis> components of a given <DRM Property Grid> are spatial, in accordance with the 6.2.4 Axis Type Restrictions constraint.
For example, if a <DRM Property Grid> specifies its srf_parameters as Augmented Mercator (AM), there can be no more than one "x" axis, "y" axis, or elevation/"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.
The <DRM Property Table> class is used to store tabular data that requires no spatial axes. 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 component index. <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.5.9.4 Table property descriptions
Attributed data is used throughout the DRM. To fully specify a data value, its meaning and storage type are required. If the data value is a numeric value, a scaled unit of measure is also required. The data signature of a <DRM Data Table> cell needs this information for each data item.
<DRM Table Property Description> represents a signature item in a <DRM Data Table>. Since the values are stored in the cells of a <DRM Data Table> instance, <DRM Data Table> does not have a value field. On the other hand, all the cells corresponding to a given <DRM Table Property Description> have the same storage type, so a given signature item is specified once in the fields of the <DRM Table Property Description>. Consequently, <DRM Table Property Description> has a value_type field, in addition to the fields inherited from <DRM Property>.
A <DRM Data Table> cell may reference other <DRM Data Table> instances, if they are components of the referencing <DRM Data Table> instance or if they reside in a <DRM Data Table Library>. 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 kth 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. However, the DRM grants more flexibility. <DRM Table Property Description> contains the field component_data_table_ecc and an optional ordered list of <DRM Property Value> components. These <DRM Property Value> components qualify the component_data_table_ecc when they are specified. This allows the provider of a <DRM Data Table> to reference, not the kth component <DRM Data Table>, but the jth component <DRM Data Table> that matches the given qualified ECC.
The <DRM Axis> class abstracts the common characteristics of its concrete subclasses. Each <DRM Axis> instance specifies:
a. the semantic meaning of its tick marks (the axis_type);
b. a scaled unit of measure (the axis_unit and axis_scale); and
c. a count for the number of tick marks on the axis (the axis_value_count).
The <DRM Axis> class has four concrete subclasses:
Each of these is discussed in more detail below.
The <DRM Regular Axis> class is used to specify numerical axes that have a constant spacing between the axis values (which are called tick marks). To specify these regularly spaced values, a <DRM Regular Axis> specifies the starting value (its first_value field), the type of spacing being used (spacing_type), and the spacing itself (spacing).
The notion of equal spacing applies to both arithmetic and geometric spacing. If ARITHMETIC is specified, the kth tick mark value is:
tick(k) = first_value + (k ´ spacing)
while, if GEOMETRIC is specified, the kth tick mark value is
tick(k) = first_value ´ (spacingk)
When <DRM Regular Axis> is used as a spatial axis, the first_value is relative to the <DRM Location> associated with the parent <DRM Property Grid Hook Point>.
When a <DRM Regular Axis> is used to represent a continuous value, interpolation could be required as a result the preferred interpolation method is provided by the interpolation_type field entry of the <DRM Regular Axis> class. The interpolation methods are specified in 5.2.5.26 Interpolation_Type. If there is no preferred interpolation method, interpolation_type shall be NOT_SUPPLIED. Data not requiring interpolation shall set interpolation_type to DISALLOWED. Spatial axes are not permitted to disallow interpolation although a data provider may indicate that a preferred interpolation method is not supplied.
When a <DRM Regular Axis> instance represents a spatial axis as a component of a <DRM Property Grid>, the values of the axis are relative to the <DRM Location> components of the <DRM Property Grid Hook Point>. The <DRM Property Grid> aggregate of the <DRM Regular Axis> instance specifies which tick mark in the axis will correspond to the <DRM Location> component of the <DRM Property Grid Hook Point>. This is done with the location_index field of the <DRM Property Grid>.
The essential difference between <DRM Regular Axis> and <DRM Irregular Axis> is that the former uses regular spacing to specify its tick marks and the latter does not. The tick marks of a <DRM Irregular Axis> are specified explicitly in the axis_value_array field. The number of values in the axis_value_array field is specified by the axis_value_count field, which also indicates how many tick marks are represented along the axis. Further restrictions on the contents of the axis_value_array can be found in 6.2.4 Axis type restrictions.
Note that the <DRM Irregular Axis> class has an interpolation_type field just as <DRM Regular Axis> does.
If a <DRM Irregular Axis> instance is used as a spatial <DRM Axis> within a <DRM Property Grid>, the values within axis_value_array are all offsets from the location corresponding to the location_index of the grid. That is, if the axis is the ith spatial axis of a grid, and v is the corresponding coordinate value of the location cell, the kth tick coordinate value is
v + axis_value_array[k]
where k ranges from zero (0) 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 an <DRM Irregular Axis> is always LOWER.
A <DRM Enumeration Axis> instance is constrained to specify an axis_type corresponding to an EDCS Attribute Code (EAC) that is bound to a set of EECs, from which its tick marks are supplied as its axis_value_array.
<DRM Interval Axis> specifies an axis whereby the axis values corresponding to the tick marks are defined 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.
<DRM Geometry> is an abstract DRM class for which an ‘instance’ of the class (that is, an instance of one of the concrete classes descended from <DRM Geometry>) represents an entity in the environment, or an organized collection of such entities, in a manner intended to approximate the physical extent and characteristics of that entity so that it can be presented in terms of a given sensor domain in a realistic manner. Often, but not always, this is in terms of visual representation.
<DRM Geometry> includes, but is not limited to, the concepts of point geometry, linear geometry, planar geometry, surface geometry, and volume geometry. For example, <DRM Geometry> also includes the concept of <DRM Property Grid Hook Point> instances used to reference tables, wherein various properties of an entity have been systematically sampled.
A <DRM Geometry Hierarchy> is a hierarchically organized collection of <DRM Geometry> instances. <DRM Geometry Hierarchy> is abstract, and has three subclasses: <DRM Geometry Model Instance>, <DRM Aggregate Geometry>, and <DRM Property Grid Hook Point>.
<DRM Geometry Model Instance> is covered in 4.5.14.2.2 Instancing. <DRM Geometry Model Instance> provides a mechanism for referencing the <DRM Geometry Model> of a <DRM Model>.
A <DRM Aggregate Geometry> specifies a collection of either <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.
A <DRM Property Grid Hook Point> provides a mechanism for instancing a <DRM Property Grid> within the scope of an <DRM Environment Root> or of a <DRM Model>.
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.5.10.2.3 Property grid hook points
A <DRM Property Grid Hook Point> exists to specify the connection between one or more <DRM Property Grid> instances’ spatial reference frames and that of the <DRM Property Grid Hook Point> itself, where the <DRM Property Grid> instances are components of the <DRM Property Grid Hook Point>.
Consider a <DRM Property Grid> instance G as shown in Figure 4.7, which is constrained as are all instances of the class to specify 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.
Figure 4.7—Example of property grid hook point
The <DRM Primitive Geometry> class defines the smallest data elements that can be used to represent environmental enitities. 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> capture geometry data items that describe points, lines, surfaces, volumes, and finite element meshes.
While individual <DRM Primitive Geometry> instances may represent a single renderable object, multiple instances are typically needed (e.g., when property data is associated with a set of primitives rather than each primitive individually). In this case, the set of related <DRM Primitive Geometry> are aggregated in a <DRM Union Of Primitive Geometry>. This allows the property data to be associated with the <DRM Union Of Primitive Geometry> instance and apply to all <DRM Primitive Geometry> instances in the container.
A <DRM Point> instance specifies a <DRM Location> with various geometric rendering characteristics. A <DRM Point> instance may be associated with an optional <DRM Light Rendering Properties> instance, in which case it is said to represent a light point. A <DRM Point> may be used to represent the appearance of any environmental entity that is so small from the viewpoint of an observer that it may be considered as a point.
A <DRM Linear Geometry> instance defines 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 Base Vertex> or <DRM Location> instances specifying the geometry. Instead, count indicates how the <DRM Linear Geometry> is to be rendered. A count field value of zero (0) for a given <DRM Linear Geometry> instance L indicates that L is to be rendered as solid, and the suppress_last field does not apply. If, however, count is greater than zero, the interpretation of count depends on whether L has a <DRM Light Rendering Properties> component. If a <DRM Light Rendering Properties> component is present, count is the number of evenly spaced light points to be rendered along L. Otherwise, count is the number of evenly spaced line segments to be rendered along L. In either of these two cases, suppress_last indicates whether the last light point/segment in the sequence is to be suppressed or rendered.
If desired, a <DRM Linear Geometry> instance may be provided with an association to a <DRM Geometry Edge> instance to indicate its geometric topology, but this is not required.
A <DRM Line> is an ordered list of two or more <DRM Base Vertex> instances defining a sequence of connected line segments. As an example, consider a <DRM Line> instance representing the outline of a rectangular runway. The <DRM Line> instance aggregates five <DRM Vertex> instances with ordered pairs of <DRM Vertex> instances representing the end points of the four line segments representing the runway outline.
A <DRM Arc> instance is circular arc with the center at the component <DRM Location> and with end points specified by the <DRM Base Vertex> components. The arc segment is from the first <DRM Base Vertex> component until it intersects the radial line which passes through the second <DRM Base Vertex> component.
As an example, consider a <DRM Arc> instance L representing an arc of lights on one side of a helipad. In this particular example, L has two <DRM Vertex> components, a count value of 30, and suppress_last has value FALSE. The <DRM Vertex> instances specify the endpoints of the <DRM Arc> (i.e., the positions of the first and last light points). L has a <DRM Light Rendering Properties> component specified with <DRM Flashing Light Behaviour>, so L is rendered as 30 flashing light points, evenly spaced between L’s endpoints.
Surface geometry is a set of <DRM Primitive Geometry> classes that use geometrical representation constructs having area, but no thickness. Planar representations are supported by the classes <DRM Polygon> and <DRM Ellipse>.
A <DRM Polygon> class instance specifies a bounded portion of a plane, defined by a set of three or more ordered <DRM Base Vertex> components. The order of the <DRM Base Vertex> components is counter-clockwise. The first <DRM Base Vertex> is not duplicated to also appear as the last <DRM Base Vertex> of the <DRM Polygon>. Thus, the last segment connecting the last <DRM Base Vertex> instance to the first <DRM Base Vertex> instance is only implicitly defined. 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.
<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 appropriate vector_type values (MAJOR_AXIS and 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.
<DRM Volume Geometry> abstracts common properties of classes used to specify geometric volumes. Currently <DRM Volume Geometry> has one concrete subclass, <DRM Elliptic Cylinder>.
An instance of <DRM Elliptic Cylinder> specifies a closed cylindrical volume having an elliptical cross-section, in a manner such that the representation can be subjected to a coordinate conversion or transformation without undue distortion of the cylinder’s shape and position, and so that the cylinder can be specified at any desired position and any desired orientation.
<DRM Elliptic Cylinder> specifies the shape of the elliptic cross-section in the same manner used by <DRM Ellipse>, described previously in 4.5.10.3.4.3 Ellipses. The position in the case of a cylinder is a location in 3D space, so <DRM Elliptic Cylinder> has a <DRM Location 3D> rather than a <DRM Location>. Rather than the centre of the volume, the <DRM Location 3D> component of a <DRM Elliptic Cylinder> is the centre of the bottom face of the volume. In addition to the major_axis_length and minor_axis_length fields, <DRM Elliptic Cylinder> specifies the height of the cylinder as a field value so that the volume is fully specified.
4.5.10.3.6 Finite element meshes
A finite element mesh is a surface or solid (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 vetices (or faces or solid elements) will have the same set of property types. Because of the homogeneity of the data, a finite element mesh is efficiently represented in the DRM with a specialized set of <DRM Data Table> instances. Finite element meshes are often used as input data for computational environment models.
<DRM Feature> is an abstract DRM class for which an “instance” of the class (that is, an instance of one of the concrete classes descended from <DRM Feature>) is used to represent an entity in the environment, or an organized collection of such entities, that specifies the properties of the entity in terms of its spatial connectivity.
A <DRM Feature> is either a <DRM Primitive Feature> or a <DRM Feature Hierarchy>. A <DRM Primitive Feature> directly represents some environmental entity, or some portion of an environmental entity, while a <DRM Feature Hierarchy> is an organized collection of such primitives.
<DRM Primitive Feature> has three concrete subclasses: <DRM Point Feature>, <DRM Linear Feature>, and <DRM Areal Feature>. Consequently, all three of these classes inherit the formal component, aggregate, and association relationships specified for <DRM Feature> as well as those for <DRM Primitive Feature>. Of particular interest is that a <DRM Feature> may have a <DRM Classification Data> instance as a component, denoting what the particular <DRM Feature> represents, as well as zero or more attributes to capture the desired characteristics of that <DRM Feature>.
An instance of <DRM Point Feature> is used to represent a single environmental object, such as a tree, house, vehicle, or table, in such a way that the spatial information associated with that representation has been abstracted to a single point location. (The examples given earlier in this clause, although not directly mentioned, used a <DRM Point Feature> to represent the tree and building.) The spatial information itself is provided by an associated <DRM Feature Node> (see 4.5.9 Topology).
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.5.12 Topology).
Each such <DRM Feature Edge> instance is associated through a link object; specifically, an instance of <DRM Edge Direction> specifying the direction in which that <DRM Feature Edge> is to be interpreted to incorporate it into the sequence. For example, consider a <DRM Linear Feature> representation of a single road that is part of a larger system of roads, where the representation is divided into many segments. The topology of the <DRM Linear Feature> in this example is a sequence of many <DRM Feature Edge> instances, where the <DRM Edge Direction> instances specify the direction (from start to end or end to start) in which each <DRM Feature Edge> is to be interpreted so that the <DRM Linear Feature> expresses the entire sequence as a continuous entity.
Note that a <DRM Linear Feature> is not required to be continuous; that is, it is possible for two <DRM Feature Edge> instances to be specified in sequence for a <DRM Linear Feature> that do not share a common endpoint. This permits the representation of linear entities that are discontinuous, such as a road that is interrupted by some terrain obstacle, such as a lake or crater.
An instance of <DRM Areal Feature> is used to represent either an environmental object or the “universe” within which all other <DRM Primitive Feature> instances are considered to be located.
In the first case, if an instance of <DRM Areal Feature> is used to represent an environmental object, it represents a single environmental object, such as a lake, orchard, parking lot, or wall, in such a way that the spatial information associated with that representation has been abstracted to a bounded region. The spatial information itself is provided by one or more associated <DRM Regular Feature Face> instances (see 4.5.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 defined, the spatial information itself is provided one associated <DRM Universal Feature Face> instance (see 4.5.12 Topology).
A <DRM Feature Hierarchy> is a hierarchically organized collection of <DRM Feature> instances. <DRM Feature Hierarchy> is abstract, and has two subclasses: <DRM Feature Model Instance> and <DRM Aggregate Feature>.
<DRM Feature Model Instance> is described in 4.5.14.2.2 Instancing. It provides a mechanism for referencing the <DRM Feature Model> of a <DRM Model>.
A <DRM Aggregate Feature> specifies a collection of <DRM Primitive Feature> and/or <DRM Feature Hierarchy> instances, organized according to some organizing principle specific to the particular subclass of <DRM Aggregate Feature> being considered. Each of the concrete subclasses of <DRM Aggregate Feature> is covered under the corresponding organizing principle.
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 in different ways. Feature topology represents connectivity information for associated <DRM Feature> instances, and semantically represents connectivity information for the environmental data being represented. An example of this would be a feature representation of two roads, where any intersections between the roads would be identified in their representations. Geometry topology, on the other hand, represents connectivity information for associated <DRM Geometry> instances, and semantically represents connectivity information specific to the geometric representation itself. An example of this would be topological information indicating that two <DRM Polygon> instances have a common boundary.
Feature topology consists of instances of the subclasses of <DRM Feature Topology>:
b. <DRM Feature Edge>, and
These instances are always organized by a <DRM Feature Topology Hierarchy>, as specified in 6 DRM class definitions.
Geometry topology consists of instances of the subclasses of <DRM Geometry Topology>:
e. <DRM Geometry Edge>, and
These instances are always organized by a <DRM Geometry Topology Hierarchy>, as specified in 6 DRM class definitions.
A <DRM Feature Node> represents a position in space that is significant in terms of its connectivity. This position is significant either because it specifies the topology (that is, position and connectivity information) of a <DRM Point Feature> (in which case it can be considered an “entity node”, since in a way it represents an entity in its own right), or because it is used to specify an endpoint for one or more <DRM Feature Edge> instances, or both. A <DRM Feature Node> can be considered “zero-dimensional”, in the sense that it specifies position but does not specify the dimensions of the thing being represented (length, width, height).
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>:
a. all associated <DRM Point Feature> instances located at N;
b. through its <DRM Connected Feature Edge> component, all <DRM Feature Edge> instances that refer to N as an endpoint; and
c. 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.5.12.3 Geometry topology.
A <DRM Feature Edge> represents a sequence of line segments in space, possibly discontinuous, such that the sequence is significant in terms of its connectivity. This information is significant either because it specifies the topology of a <DRM Linear Feature>, or because it is used to specify part of a boundary of one or more <DRM Feature Face> instances, or both. A <DRM Feature Edge> can be considered “one-dimensional”, in the sense that it specifies “length” but does not specify “width” or “height” for the entity being represented. (Note that a <DRM Feature Edge> may be specified in any orientation in space.)
For a <DRM Feature Edge> E, the endpoints of E are specified by its ordered associated <DRM Feature Node> instances, where the first <DRM Feature Node> associate N1 is the starting node and the second, N2, is the ending node. (This directionality is utilized when specifying sequences of <DRM Feature Edge> instances to specify higher level constructs, as mentioned in the discussion of <DRM Feature Edge>.) If E is not a straight line between N1 and N2, E will have an ordered collection of <DRM Location> components, so that a non-self overlapping but connected sequence of line segments is specified between N1 and N2. The only self-overlapping case that may occur is when N1 and N2 are the same <DRM Feature Node>.
The set of <DRM Linear Feature> instances associated with E (if any) can always be determined by examining the associations of E. Depending on the level of topological information being supplied, E may also specify the collection of <DRM Feature Face> instances bordered by E, as associates of E that are ordered counterclockwise when “looking along” E.
A <DRM Feature Face> represents a region in space, not necessarily planar, such that the region is significant in terms of its connectivity. A <DRM Feature Face> can be considered “two-dimensional”, in the sense that it does not specify “thickness” but does specify a spatial extent.
<DRM Feature Face> has two concrete subclasses: <DRM Regular Feature Face> characterized by having a finite extent, and <DRM Universal Feature Face> characterized by having an infinite extent. No transmittal shall have more than one instance of <DRM Feature Face>.
Boundaries of a <DRM Feature Face> are specified using by a <DRM Feature Face Ring> described in 4.5.12.2.3.2 <DRM Feature Face Ring>.
<DRM Feature Face Ring> is an abstract DRM class with two concrete subclasses: <DRM External Feature Face Ring> and <DRM Internal Feature Face Ring>. All <DRM Feature Face Ring> instances have the same structure, but the two subclasses represent different semantic concepts and have different relationships with the <DRM Feature Face> subclasses that use them.
A <DRM Feature Face Ring> specifies a boundary as a sequence of one or more ordered <DRM Feature Edge> instances forming a closed (but not necessarily planar) shape. Each <DRM Feature Edge> instance is associated through a <DRM Edge Direction> instance, specifying whether the <DRM Feature Edge> is to be interpreted “forwards” (start to end) or not (end to start) in order for it to “link up” with its predecessor and successor in the sequence. The constraints specified in 6.2.15 Feature_Edge restrictions ensure that the <DRM Feature Edge> instances of a <DRM Feature Face Ring> do not touch except at their endpoints. The semantic information supplied by a <DRM Feature Face Ring> depends on the specific subclass being used, <DRM Internal Feature Face Ring> or <DRM External Feature Face Ring>.
A <DRM Internal Feature Face Ring> is a component of exactly one <DRM Feature Face> instance, and specifies an inner boundary for that <DRM Feature Face>. That is, it specifies a “hole”, a region that is not semantically part of the <DRM Feature Face> in question. A <DRM Internal Feature Face Ring> may be a part of an instance of either subclass of <DRM Feature Face>.
A <DRM External Feature Face Ring> is a component of exactly one <DRM Regular Feature Face> instance, and specifies an explicit outer boundary for that <DRM Regular Feature Face>.
A <DRM Regular Feature Face> is characterized by having an explicit outer boundary in the form of a <DRM External Feature Face Ring>, and thus has a finite extent. A <DRM Regular Feature Face> may also have <DRM Internal Feature Face Ring> instances.
For example, consider a <DRM Regular Feature Face> associated with a <DRM Areal Feature> that represents the exterior wall of some structure, as indicated by a <DRM Classification Data> for the <DRM Areal Feature>. If the exterior wall contains windows, one possible representation is to represent the boundary of each window by a <DRM Internal Feature Face Ring>. Note that the representation may go on to use the edges for each such <DRM Internal Feature Face Ring> to specify a separate <DRM External Feature Face Ring>, <DRM Regular Feature Face>, and <DRM Areal Feature> 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.
<DRM Regular Feature Face> instances may appear at any level of topology. The other subclass of <DRM Feature Face>, <DRM Universal Feature Face>, is only instanced at topology level 3 or higher, as discussed below.
Instances of <DRM Universal Feature Face> only occur for topology level 3 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 five levels of feature topology organization:
0. A level 0 organization contains <DRM Feature Topology> objects, but at least two <DRM Feature Node> instances are specified for the same location 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 1, no two <DRM Feature Node> instances shall be specified for the same coordinates in space, but otherwise there are no constraints in addition to level 0. At least two <DRM Feature Edge> instances intersect or overlap at some position not indicated by a common <<DRM Feature Node>.
2. At level 2, in addition to the conditions specified at level 1, no two <DRM Feature Edge> instances intersect or overlap except where they meet at a common <DRM Feature Node>.
3. At level 3, in addition to the conditions specified at level 2, 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 3, the set of <DRM Regular 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 4, in addition to the conditions specified by level 3, the following conditions are met. The <DRM Feature Topology> instances are specified by <DRM Location 3D> instances, and at least one <DRM Feature Edge> shall form part of the boundary of more than two <DRM Feature Face> instances.
A detailed specification of the levels of feature topology is contained in 5.2.5.14 Feature_Topology_Level.
<DRM Universal Feature Face> exists to support the requirements of level 3 topology. An instance of <DRM Universal Feature Face> shall be provided for every context in which level 3 topology is specified. Since every <DRM Feature Edge> is required to bound two <DRM Feature Edge> instances, the outer boundary of the entire topological surface formed by the <DRM Regular Feature Face> instances requires the presence of a <DRM Universal Feature Face>, representing the “universe” outside the topological surface.
Since a <DRM Universal Feature Face> consequently has infinite extent, it has inner boundaries as represented by <DRM Internal Feature Face Ring> components, but has no outer boundary.
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 direct components of the topology.
A <DRM Geometry Node> is always associated with an instance of one of the following, where the <DRM Location> specified by the associate is the location of the <DRM Geometry Node>:
a. <DRM Point>,
d. <DRM Property Grid Hook Point>,
e. <DRM Ellipse> where the node corresponds to the centre, and
f. <DRM Elliptic Cylinder> where the node corresponds to the centre of the bottom face.
A <DRM Geometry Edge> is either associated with some <DRM Linear Geometry> (in which case, its <DRM Geometry Node> endpoints are associated with <DRM Base Vertex> instances of the <DRM Linear Geometry>) or forms part of the <DRM Geometry Face Ring> of some <DRM Geometry Face>.
<DRM Geometry Face> is somewhat simpler than its counterpart in feature topology. A <DRM Geometry Face> instance F has only a single <DRM Geometry Face Ring>, representing its outer boundary. F is associated with some collection of <DRM Polygon> instances that form a connected surface, specifying the outer boundary of the surface in question (which may or may not be planar). The <DRM Geometry Edge> instances forming the outer boundary of F shall be specified by <DRM Base Vertex> instances forming the outer boundary of the polygonal representation being so abstracted.
The level of detail (LOD) organizing principles provide a DRM mechanism to represent the same set of environmental data using alternate representations at different levels of detail. The two classes <DRM Level Of Detail Related Geometry> and <DRM Level Of Detail Related Features> are used to aggregate <DRM Feature Hierarchy> and <DRM Geometry Hieararchy> that contain the actual alternate representations at the different levels of detail. The level of detail information is provided in a link object that shall be of one of the DRM subclasses of <DRM Base Level of Detail Data>.
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:
a. alternate hierarchy,
b. animation,
c. classification,
d. level of detail,
e. oct_tree,
f. perimeter,
g. quad_tree,
h. separating plane,
i. spatial index,
j. state,
k. time,
l. union of geometry hierarchy
m. union of primitive geometry, and
n. union of features.
Of these, the following concepts organize by spatial relationship:
o. oct_tree division of a volume,
p. quad_tree division of a region,
q. perimeter division by irregularly shaped boundaries,
r. separating planes, and
s. spatial index division by regularly shaped boundaries.
Each of these organizing principles has at least one formal constraint specifying the semantic restrictions 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:
t. 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;
u. animation, where the contained data, which is always geometric, is organized by prescribed animation sequences;
v. level of detail (LOD), where contained data is organized by various characteristics such as scale, viewing distance or range, and spatial resolution;
w. continuous LOD (CLOD), where contained data is organized by a an algorithm (generally used in computer graphics applications) that replaces specific facets with finer detailed facets, on a facet by facet basis;
x. union of geometry hierarchy, where the contained data is organized but the reason for organizing them into separate branches or components is not specified;
y. union of primitive geometry, where the contained data is a collection of primitive geometry data items;
z. union of features, where the contained data is a collection of primitive feature data items or of other organizers for feature data.
Other organizing principles include:
aa. time, where the contained data is valid for specific time periods;
bb. 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
cc. classification, such as organizing all objects in a classroom by their types.
Each of these organizing principles is described more fully below.
4.5.13.2 Alternate hierarchy organization
The alternate hierarchy organizing principles provides a DRM mechanism to represent the same set of environmental data using different representations. This is done with the class <DRM_Alternate_Hierachy_Related_Geometry> for geometry data and with the class <DRM_Alternate_Hierachy_Related_Features> for feature data. The link class <DRM Hierarchy Data> instance indicates the reason for each branch from this hierarchy within a string.
The animation organizing principle provides representing environmental data as a sequence of animation frames. This is accomplished through the <DRM_Animation_Related_Geometry> which aggregates an ordered set of <DRM Geometry Hierarchy>s which are frames of animation sequence(s). The behaviour of the animation sequence is controlled by the ordered <DRM_Animation_Behaviour> components of the <DRM_Animation_Related_Geometry>.
The ordered set of <DRM_Animation_Behaviour> components allow the animation to be provided in discrete sequences of frames. Each <DRM_Animation_Behaviour> specifies:
a. frame duration in seconds,
b. the number of times the animation sequence will repeat with a flag value of zero for continuous repetition,
c. the sequence mode to cycle trough the frames, whether standard (beginning to end) or swing (beginning to end, end to beginning),
d. the index of the component representing the beginning frame of the <DRM_Animation_Related_Geometry>,
e. the index of the component representing the ending frame of the <DRM_Animation_Related_Geometry>, and
f. a flag to specify random beginning frame which will ignore the beginning frame index and have the sequence cycle towards the ending frame.
The classification related organizing principle provides the mechanism to group environmental data based on an EDCS classification code (ECC). This is accomplished with the DRM class <DRM Classification Related Features> and <DRM Classification Related Geometry> for feature and geometry data respectively. 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>.
The LOD organizing principles provides a DRM mechanism to represent the same set of environmental data using alternate representations at different levels of detail. This is done with the classes <DRM Level Of Detail Related Geometry> and <DRM Level Of Detail Related Features>. These two DRM classes of aggregate objects, <DRM Aggregate Feature> and <DRM Aggregate Geometry>, contain the actual alternate representations at the different levels of detail. The level of detail information is provided in the link object which 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:
a. <DRM Distance Level Of Detail Data>,
b. <DRM Index Level Of Detail Data>,
c. <DRM Map Scale Level Of Detail Data>,
d. <DRM Spatial Resolution Level Of Detail Data>, and
e. <DRM Volume Level Of Detail Data>.
The <DRM Distance Level Of Detail Data> class defines a level of detail described in terms of distance from the eyepoint to the centre of the object. This class specifies the following:
f. the minimum range in metres where the component hierarchy is valid,
g. the minimum fade band in metres where the component hierarchy can begin to be faded in,
h. the maximum range in metres where the component hierarchy is valid, and
i. the maximum fade band in metres where the component hierarchy begins to fade out.
The centre of the object to be used for evaluation is provided as a <DRM Location> component of the <DRM Distance Level Of Detail Data> link object.
The <DRM Index Level Of Detail Data> class defines an index that indicates the relative level of detail of the associated data. Lower values indicate more detailed versions and higher values indicate less detailed versions.
The <DRM Map Scale Level Of Detail Data> class defines the level of detail based on the map scale of the associated data. The map scale is provided as a float value.
The <DRM Spatial Resolution Level Of Detail Data> class defines the level of detail based on spatial resolution providing both the spatial resolution and the unit of measurement for such resolution.
The <DRM Volume Level Of Detail Data> class defines 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 which, 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.
The oct_tree related organizing principle is represented in the DRM by the <DRM Oct Tree Related Geometry> class for the organization of geometry, and the <DRM Oct Tree Related Features> class for the organization of features. The two classes are constrained by the Oct Tree Related Organizing Principle constraint to ensure that instances of these classes are semantically valid. In terms of their oct_tree behaviour, <DRM Oct Tree Related Features> and <DRM Oct Tree Related Geometry> have exactly the same organization, so ‘oct_tree related aggregation’, will be used herein to mean ‘either an instance of <DRM Oct Tree Related Geometry> or an instance of <DRM Oct Tree Related Features>’. The notion of an oct_tree is analogous to that of a quad_tree as discussed in 4.5.10.8 Quad_tree.
An oct_tree corresponds to the spatial data structure notion of a region oct_tree [SAMET], that divides a volume into eight equal-sized octants. However, an oct_tree in SEDRIS is not necessarily a classical region oct_tree, in that a SEDRIS data provider is not constrained to organize the entire hierarchy below an oct_tree as smaller and smaller oct_trees. A data provider may choose to do so, but it is not a requirement.
To begin specifying an oct_tree, the region being subdivided into octants shall be specified. This is done by attaching a three-dimensional <DRM Spatial Extent> component to each oct_tree related aggregation, specifying the parallelepiped being divided into octants. Every oct_tree related aggregation then has between one and eight branches (<DRM Feature Hierarchy> instances in the case of <DRM Oct Tree Related Features>, <DRM Geometry Hierarchy> instances in the case of <DRM Oct Tree Related Geometry>) corresponding to the equal-sized octants into which the region is being partitioned. The <DRM Oct Tree Data> link object for a given branch indicates, via the value of its octant field, which of the eight octants is represented.
Note that an oct_tree related organization is not required to specify a branch for each possible octant. Some data providers may have data that naturally lends itself to oct_tree organization, but which for some reason leaves one or more octants empty, just as with quad_tree organizations.
For consumption of a transmittal in a spatial reference frame other than that in which it was defined, 6.2.39 Oct Tree Related Organizing Principle specifies further restrictions to ensure that each octant is clearly specified, even if coordinate conversion or transformation is applied to the data. This is necessary, because the notion of ‘size’ is not invariant under coordinate conversion and transformation. Consequently, each branch of an oct_tree related organization is required to specify an explicit three-dimensional <DRM Spatial Extent>, corresponding exactly to the bounding parallelepiped of the octant represented by that branch.
Since a <DRM Spatial Extent> component specifies a strict boundary, no position information in the scope of its aggregate may lie outside the bounding parallelepiped specified by the <DRM Spatial Extent>. Consequently, the strict_organizing_principle field value of an oct_tree related organization is always TRUE indicating that the oct_tree related organizing principle is strictly obeyed. In addition, since the octants by definition partition the oct_tree’s region and do not overlap, no two branches may have common primitive components, so the unique_descendants field value of an oct_tree related aggregation is always TRUE. A user who does not wish to ensure that the primitives within his or her data always conform strictly to an oct_tree related organization can still organize the data spatially, using a spatial index related organization.
The perimeter related organizing principle provides for spatial organization of environmental data by providing a set of non-overlapping perimeters. This organizing principle is expressed in the DRM by <DRM Perimeter Related Geometry> and <DRM Perimeter Related Features>. Each of these classes may contain instances of <DRM Geometry Hierarchy> and <DRM Feature Hierarchy>, respectively, with link objects of <DRM Perimeter Data>. The perimeter data is stored as <DRM Location> objects of the link object. This class shall meet the constraint 6.2.38 Non-selfoverlapping Perimeter_Data locations.
The quad_tree related organizing principle is represented in the DRM by the <DRM Quad Tree Related Geometry> class for the organization of geometry, and the <DRM Quad Tree Related Features> class for the organization of features. The two classes are constrained by the 6.2.47 Quad tree related organizing principle constraint to ensure that instances of these classes are semantically valid. In terms of their quad_tree behaviour, <DRM Quad Tree Related Features> and <DRM Quad Tree Related Geometry> have exactly the same organization, so ‘quad_tree related aggregation’, will be used herein to mean ‘either an instance of <DRM Quad Tree Related Geometry> or an instance of <DRM Quad Tree Related Features>’.
A quad_tree corresponds to the spatial data structure notion of a region quad_tree [SAMET], which divides a region into four equal-sized quadrants. However, a quad_tree in SEDRIS is not necessarily a classical region quad_tree, in that a SEDRIS data provider is not constrained to organize the entire hierarchy below a quad_tree as smaller and smaller quad_trees. A data provider may choose to do so, but it is not a requirement.
To begin specifying a quad_tree, the region being subdivided into quadrants shall be specified. This is done by attaching a <DRM Spatial Extent> component to each quad_tree related aggregation, specifying the rectangular region being divided into quadrants. Every quad_tree related aggregation then has between one and four branches (<DRM Feature Hierarchy> instances in the case of <DRM Quad Tree Related Features>, <DRM Geometry Hierarchy> instances in the case of <DRM Quad Tree Related Geometry>) corresponding to the equal-sized quadrants into which the region is being partitioned. The <DRM Quad Tree Data> link object for a given branch indicates, via the value of its quadrant field, which of the four quadrants is represented.
Note that a quad_tree related organization is not required to specify a branch for each possible quadrant. Some data providers may have data that naturally lends itself to quad_tree organization, but which for some reason leaves one or more quadrants empty. For example, a <DRM Quad Tree 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 Quad Tree 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 defined, Quad_Tree Related Organizing Principle specifies further restrictions to ensure that each quadrant is clearly specified, even if coordinate conversion or transformation is applied to the data. This is necessary, because the notion of ‘size’ is not invariant under coordinate conversion and transformation. Consequently, each branch of a quad_tree related organization is required to specify an explicit <DRM Spatial Extent>, corresponding exactly to the bounding box of the quadrant represented by that branch.
A <DRM Spatial Extent> component specifies a strict boundary, such that no position information in the scope of its aggregate may lie outside the bounding rectangle (if the <DRM Spatial Extent> is two-dimensional) or bounding parallelepiped (if the <DRM Spatial Extent> is three-dimensional) specified by the <DRM Spatial Extent>. Consequently, the strict_organizing_principle field value of a quad_tree related organization is always TRUE, indicating that the quad_tree related organizing principle is strictly obeyed. In addition, since the quadrants by definition partition the quad_tree’s region and do not overlap, no two branches may have common primitive components, so the unique_descendants field value of a quad_tree related aggregation is always TRUE. A user who does not wish to ensure that the primitives within his or her data always conform strictly to a quad_tree related organization can still organize the data spatially, using a spatial index related organization.
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. This principle is implemented with the DRM class <DRM_Separated_Plane_Relations> which aggregates components 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 component is on the positive or negative side of the <DRM Separating Plane> component. The separating plane is defined by the three ordered <DRM Location> components. The positive side of the plane is defined to be the side with plane normal pointing towards it and the negative side with the plane normal pointing away from it.
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.
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> which aggregate components 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> objects provide both the state tag and the active state value. The state tag is the EDCS Attribute Code (EAC) that is being used to differentiate the component objects. The active state value defines the default value for the state information. The <DRM State Data> object stores a value for the specific branch of the same fundamental type as the active state value provided.
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> which aggregate components 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
What type of time data is being used is stored in the <DRM Time Related Features> or <DRM Time Related Geometry> class.
4.5.13.13 Union
4.5.13.13.1 Union of geometry hierarchy organization
<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, however; that is, a given <DRM Geometry Hierarchy> instance cannot be attached twice as a component of the same <DRM Union Of Geometry Hierarchy> instance. However, this does not in itself guarantee that none of the <DRM Geometry Hierarchy> components have common primitives, so 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 kth <DRM Geometry Hierarchy> component of a given <DRM Union Of Geometry Hierarchy> will always result in the same object (given, of course, that the <DRM Union Of Geometry Hierarchy> instance and its components have not been edited in the interim). 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.5.13.13.2 Union of primitive geometry organization
A <DRM Union Of Primitive Geometry> instance exists to group 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, however; that is, 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; that is, retrieving the kth <DRM Primitive Geometry> component of a given <DRM Union Of Primitive Geometry> will always result in the same object (given, of course, that the <DRM Union Of Primitive Geometry> instance and its components have not been edited in the interim). The meaning of, or reason for, the ordering, if any, is specified via the ordering_reason field of the <DRM Union Of Primitive Geometry> instance. For 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.5.13.13.3 Union of features organization
A <DRM Union Of Features> instance is the ‘feature side’ analogue to both <DRM Union Of Geometry Hierarchy> and <DRM Union Of Primitive Geometry>; its components may be either <DRM Feature Hierarchy> instances or <DRM Primitive Feature> instances.
The components of a <DRM Union Of Features> are not required to be homogeneous; for example, a <DRM Union Of Features> instance may contain both <DRM Quad Tree Related Features> instances and <DRM Areal Feature> instances as components. The components are required to be unique, however; that is, a given <DRM Feature> instance cannot be attached twice as a component of the same <DRM Union Of Features> instance. However, this does not in itself guarantee that none of the components have common primitives when <DRM Aggregate Feature> components are present, so 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 kth <DRM Feature Hierarchy> component of a given <DRM Union Of Features> will always result in the same object (given, of course, that the <DRM Union Of Features> instance and its components have not been edited in the interim). 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.5.14 Constructs for sharing data
The DRM provides the following mechanisms for sharing data within a transmittal. Sharing data is a valuable strategy when creating environmental data and providing abstractions of the environmental domains. In many cases due to system limitations of varied types, it is necessary to simplify environmental data and one such mechanism is the sharing or re-use of data values for environmental phenomena. When implementing these concepts, it is necessary to provide the mechanism to clearly demonstrate when data sharing is taking place. For this reason, the DRM in this part of ISO/IEC 18023 provides specific classes to distinguish the data being shared and explicit rules for sharing data within the DRM class hierarchy.
A model is defined 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 for example a model of a house could be composed of a set 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 contained under the <DRM_Feature_Model> component class and the geometry representation under the <DRM_Geometry_Model> component class. Models can be constructed with a specific SRF and have field values to indicate:
a. if the model is a model that moves within the transmittal;
b. if the model is a root model or a component model, or both;
c. if the model has moving parts; and
d. if the model has units for the SRF or is unitless.
A <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> (via the <DRM Geometry Model Instance> and/or <DRM Feature Model Instance> classes), 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.
Models are stored in the transmittal under the <DRM_Model_Library> component of the <DRM_Transmittal_Root> object. These models are instanced into other models or into the hierarchy under the <DRM_Environment_Root> object in a transmittal. The DRM allows the instancing of the specific <DRM_Geometery_Model> or <DRM_Feature_Model> components of the <DRM_Model>. In order to instance the geometric representation of a model, a <DRM_Geometry_Model_Instance> is created which associates to the <DRM_Geometery_Model> to be instanced. Likewise, in order to instance the feature representation of a model, a <DRM_Feature_Model_Instance> is created which associates to the <DRM_Feature_Model> to be instanced.
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.5.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 transform into a new SRF and alter the model through the <DRM World Transformation> class. The DRM also provides for altering models instanced within other models through the <DRM_LSR_Transformation> subclass of <DRM_Transformation>.
The <DRM World Transformation> class specifies a <DRM_Location> and a 3´3 matrix, used to transform the model into the non-LSR SRF. The location specifies the SRF to be instanced into and the exact location the model origin should be instanced. The 3´3 matrix provides a nine element matrix containing scaling and rotation data where the direction of rotation is determined by the right-hand rule.
The <DRM_LSR_Transformation> class specifies the transformation to occur when instancing a model in a LSR SRF into another model in a LSR SRF. This is done by either providing a 4 x 4 matrix through the class <DRM_Local_4x4> or through an ordered set of <DRM_LSR_Transformation>.
A <DRM Library> serves as a repository for data that may occur many times within the scope of an <DRM Environment Root> or <DRM Model>. The data is stored once in the <DRM Library>, then instanced via references to the <DRM Library>> rather than replicating the actual data every time the data is used.
The abstract class <DRM Library> has seven concrete subclasses:
a. <DRM Attribute Set Table Library>, where reusable sets of attributes are stored;
b. <DRM Colour Table Library>, where reusable colour tables are stored;
c. <DRM Data Table Library>, where reusable data tables (n-dimensional array of data) are stored;
d. <DRM Image Library>, where reusable images and/or texture maps are stored;
e. <DRM Model Library>, where reusable models of physical environmental objects are stored;
f. <DRM Sound Library>, where reusable sound items are stored;
g. <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.5.14.3.2 <DRM Attribute Set Table Library>
The <DRM Attribute Set Table Library> class contains elements of class <DRM Attribute Set Table Groups>. This class, in turn, contains <DRM_Attribute_Set_Table> objects which, in turn, contain <DRM_Attribute_Set> objects. The class <DRM_Attribute_Set> provides for the collecting of a set of properties or attributes to be referenced as a group. The following classes are allowed as components of this class: <DRM_Classification Data>, <DRM_Colour>, <DRM Image Mapping Function>, <DRM Light Rendering Properties>, <DRM Point Of Contact>, <DRM Presentation Domain>, <DRM Property Table>, <DRM Property Table Reference>, <DRM Property Value>, <DRM Rendering Priority Level>, <DRM Rendering Properties>, and <DRM Spatial Extent>.
In order to share the attribute sets, the DRM provides the class <DRM_Attribute_Set_Index>. Object of this class have associations to the <DRM Attribute Set Table Group> objects in the <DRM Attribute Set Table Library> object in the transmittal. The index is provided for the <DRM_Attribute_Set> component of the primary <DRM_Attribute_Set_Table>. The <DRM_Attribute_Set> objects can also be shared by being directly aggregated by other DRM objects.
4.5.14.3.3 <DRM Colour Table Library>
The <DRM_Colour_Table Library> class contains elements of class <DRM Colour Table Group>. This class in turns contains <DRM_Colour_Table> objects which 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>. Object of this class have associations to the <DRM Colour Table Group> objects in the <DRM_Colour_Table Library> object in the transmittal. The index is provided for the <DRM_Primitive_Colour> component of the primary <DRM_Colour_Table>. The <DRM_Primitive_Colour> objects can also be shared by being directly aggregated by other DRM objects.
4.5.14.3.4 <DRM Data Table Library>
The <DRM_Data_Table_Library> class is used to contain <DRM_Data_Table> instances that can be referenced or 'instanced' by an object within the transmittal. This referencing can be done through aggregation by other DRM objects or through other data table mechanisms as described in 4.5.6 Data Tables.
4.5.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.5.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.5.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.5.14.3.8 <DRM Symbol Library>
The <DRM Symbol Library> class contains the complete list of the unique <DRM Symbol> objects that can be referenced within a transmittal. Symbols are referenced as components of <DRM Label> objects.
The DRM provides the class <DRM Hierarchical Table> in order to collect a set of data used within a subset of the DRM hierarchy. The purpose is to centrally locate a group of components that are shared among many objects within a hierarchy. A <DRM Hierarchical Table> object can be attached to any <DRM Aggregate Geometry> and can thus apply to different parts of the geometry hierarchy.
The <DRM Hierarchical Table> has five different subclasses which are: <DRM Colour Entry Table>, <DRM Location Table>, <DRM Property Table Reference Table>, <DRM Reference Vector Table>, and <DRM Texture Coordinate Table>. The class <DRM Colour Entry Table> contains <DRM Colour Entry> objects. The class <DRM Location Table> contains <DRM Location> objects. The class <DRM Property Table Reference Table> contains <DRM Property Table Reference> objects. The class <DRM Reference Vector Table> contains <DRM Reference Vector> objects. The class <DRM Texture Coordinate Table> contains <DRM Texture Coordinate> objects. The component objects of these tables can be directly aggregate by other DRM objects within the geometry hierarchy or they can be referenced through the class <DRM Vertex With Component Index>.
Only the following DRM classes are relevant to the discussion of attribute inheritance and context:
a. <DRM Primitive Feature> and its subclasses
b. <DRM Primitive Geometry> and its subclasses
c. <DRM Aggregate Feature> and its subclasses, each of which organizes one or more collections of <DRM Primitive Feature> instances
d. <DRM Aggregate Geometry> and its subclasses, each of which organizes one or more collections of <DRM Primitive Geometry> instances
e. "Attribute" objects, which describe attributes of geometry or features
Attribute objects can be attached to various levels of an <DRM Aggregate Feature> (or <DRM Aggregate Geometry>) and “inherited” by the various features (or geometry) that are organized by that aggregate. That is, <DRM Aggregate Geometry> instances (and <DRM Aggregate Feature> instances) inherit a list of attribute components from their 'ancestors'.
Remembering that a SEDRIS transmittal is acyclic when considered in terms of aggregate/component relationships, one object A is the ancestor of another object B when A aggregates (contains) B as a component. For 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>) 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. This allows for the explicit sharing of individual object instances among many aggregates efficiently, in a way that is useful to a data consumer.
Inheritance is transitive. That is, when a <DRM Geometry> or <DRM Feature> inherits a component, that component may be treated as if it were attached directly to the <DRM Geometry> or <DRM Feature> 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 an <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> will 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.5.14.5.2 General Inheritance Rules
Directly attached components always override - that is, logically replace - any conflicting inherited components. The definition of "conflicting" depends on the class of object. For example, directly attached components always override any conflicting attributes from a referenced <DRM Attribute Set> instance or <DRM Colour Table> instance.
4.5.14.5.3 Inheritable Components
The following classes are subject to simple replacement; that is, a directly attached component always overrides an inherited component, in the case of instances of these classes.
a. <DRM Access>
b. <DRM Base Level Of Detail Data>
c. <DRM_Colour>
f. <DRM Light Rendering Properties>
i. <DRM Rendering Priority Level>
k. <DRM Time Constraints Data>
The following classes are subject to more complex rules of inheritance:
m. <DRM Image Mapping Function>
<DRM Attribute Set Index> is not inherited itself. Instead, the applicable attribute objects from the referenced <DRM Attribute Set> are treated as if they replaced the <DRM Attribute Set Index> for the purposes of inheritance. For each of those attribute objects, the individual, standard inheritance rules for their classes apply.
Since an <DRM Attribute Set> may contain some objects that are <DRM Feature> specific and some that are <DRM Geometry> specific, for <DRM Feature> instances, only the attributes that are legal for the <DRM Feature> class are used, while for <DRM Geometry>, only the attributes that are legal for the <DRM Geometry> class are used.
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 Attribute Set> that appears at the same level, the directly attached component overrides the component overrides the component from the <DRM Attribute Set>.
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.
In general, <DRM Location> is not inherited; it is covered by a special rule specific to <DRM Base Reference Vector>.
A <DRM Base Reference Vector> is required to have a defined point of origin. In order for the unit_vector field of a <DRM Base Reference Vector> to be defined in a SRF, that SRF shall have a compatible vector space structure. Several of the SRFs supported by this International Standard (e.g., geodetic) do not have vector space structure. When a <DRM Base Reference Vector> is defined 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 defined inside that LTP space.
If a <DRM Base Reference Vector> has a directly attached <DRM Location> component, that is its point of origin. However, in many contexts where <DRM Base Reference Vector> appears in the DRM, the vector can unambiguously inherit a <DRM Location> from the object that aggregates the <DRM Base Reference Vector> rather than specifying a separate <DRM Location>, which would be required to be the specific instance it should inherit in order to be valid. 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> the default <DRM Location> in the context of the aggregation tree rooted at A.
In the cases of those classes specified by the Required Reference Vector Location constraint, in which multiple <DRM Location> components are present, and inheritance would be ambiguous, a directly attached <DRM Location> is required for the <DRM Base Reference Vector>.
In the case of a <DRM Vertex With Component Indices> that refers to a <DRM Location Table>, a <DRM Base Reference Vector> inherits the <DRM Location> indexed by the <DRM Vertex With Component Indices>.
A directly attached <DRM Property Description> component overrides an inherited instance if the “newer” <DRM Property Description> has the same meaning. 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 have the same meaning.
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>.
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.
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.
A directly attached <DRM Property Value> instance overrides an inherited instance if the “newer” <DRM Property Value> has the same qualified classification. 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 have the same qualified classification.
<DRM Citation> cannot be inherited due to their semantic meaning. The <DRM Citation> at the top of any hierarchy specifies the bibliographic citation information for the collection as a whole; to reference any part of the collection specifically, that part would require its own <DRM Citation>.
<DRM Keywords> cannot be inherited due to their bottom-up nature. The <DRM Keywords> at the top of any hierarchy are a collection of the individual keywords that apply through the hierarchy, so they are built bottom-up in the hierarchy rather than being inherited top-down.
A <DRM Label> is attached to exactly one <DRM Feature>, so it cannot be inherited to apply to other <DRM Feature> instances.
A <DRM Description> should be specific to the instance that aggregates it.
<DRM Spatial Extent> instances cannot be inherited due to the bottom-up nature of a <DRM Spatial Extent>. For instance, 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 Point Of Contact> instances are not inherited.
4.5.15 Constructs for presenting data
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.5.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.
a. 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.
b. In the case of <DRM Animation Related Geometry>, different branches represent different frames of the animation, and thus should not be rendered simultaneously.
c. In the case of SEDRIS objects that belong to different branches of a level of detail related organization, such as an instance of <DRM Level Of Detail Related Geometry>, the data consumer's mechanism for handling level of detail is responsible for resolving such issues, and similarly for coarser and finer levels of detail in a <DRM Continuous Level Of Detail Related Geometry>.
d. 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.
e. 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.
f. In the case of SEDRIS objects belonging to different branches of spatial organizing principles, such as <DRM Spatial Index Related Geometry>, ideally data would be constructed strictly according to the organizing principle, so that no overlap could occur. However, this strictness is not required. In addition, other organizing principles exist that do not inherently exclude two branches of an organization from being active simultaneously with potentially overlapping data. Furthermore, an organization may potentially have overlapping data within the same branch.
Consequently, the following mechanisms are supplied to allow data providers to resolve potential ambiguities in the rendering of potentially overlapping data.
g. In the case of a <DRM Primitive Geometry> instance for which finer <DRM Primitive Geometry> is nested (e.g., a <DRM Polygon> with subfaces), a <DRM Primitive Geometry> may contain a <DRM Union Of Primitive Geometry> instance as a component to organize such subfaces. This indicates unambiguously that a nesting relationship exists, so that either the coarse or fine representation may be used.
h. 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.
i. Within a <DRM Union Of Geometry> or <DRM Union Of Features>, an ordering_reason field is present. If FIXED_LISTED is specified, this indicates that the order in which the components of the union are specified is to be treated as the rendering order. If LAYERED_HIGH_QUALITY_RENDERING, LAYERED_FASTEST_RENDERING, or VIEWER_RANGE are specified, they are to be interpreted according to their definitions to resolve any conflicts.
The apparent colour of an environmental object is determined by both the reflectance properties of the object and the light energy irradiating the object. The DRM constructs used to specify these properties are <DRM Colour> and <DRM Light Source>, respectively.
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:
a. <DRM CMY Colour>,
b. <DRM HSV Colour>, and
c. <DRM RGB Colour>.
Objects in the DRM are coloured with component 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> is used when the colour is completely specified in the components of this class. A <DRM Colour Index> is used when the colour data is found as a component of a <DRM Colour Table>, for example when using colour palettes or when reusing colours.
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, which contain 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>, which 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>, which specifies the percentage of light that can pass through the colour. The colour_mapping field of a <DRM Colour> further specifies how the colour is applied to the coloured object, such as the side of the object to which the colour should be applied and how the colour should be combined with a <DRM_Image>, if present. The constraints specified in 6.2.5 Colour mapping restrictions for a <DRM_Colour> ensure that this field is appropriately specified.
A <DRM Light Source> represents a light source in the environment; the apparent size and position of the light source determine which subclass of <DRM Light Source> is used in the representation. The colour of the light emitted by a <DRM Light Source> is explicitly specified, but rather than specifying a <DRM Colour> component for the <DRM Light Source> and constraining it to contain the specific colour information required, a <DRM Light Source> directly specifies <DRM Ambient Colour>, <DRM Diffuse Colour>, and <DRM Specular Colour> components. Further information provided by a <DRM Light Source> is specified by its fields or is specific to the particular subclass being instanced.
The fields of a <DRM Light Source> instance specify the scope to which it applies (apply_to_children), whether it is to be combined with the effects of other <DRM Light Source> instances (override_positional_lights, override_infinite_lights), and whether it is on or off (active_light_value). (In the case of a <DRM Light Source> that is dynamically controlled by a <DRM Light Source Control Link> instance C, C determines whether the <DRM Light Source> is on or off and active_light_value’s original setting is a default state. See the 4.5.13 Constructs for controlling dynamic data for details.)
The remaining information specified by a <DRM Light Source> depends upon the subclass being instanced. <DRM Light Source> has two subclasses: <DRM Infinite Light>, which is concrete, and <DRM Base Positional Light> which is abstract and has two concrete subclasses of its own, <DRM Positional Light> and <DRM Spot Light>.
A <DRM Infinite Light> is used to represent a light source that, for practical purposes, can be considered infinitely far away from the observer. For such a light source, all light rays emitted from that source can be considered to be parallel, so a <DRM Infinite Light> specifies a <DRM Reference Vector> of vector_type LIGHT_DIRECTION to provide this information. A <DRM Infinite Light> does not specify attenuation factors.
<DRM Base Positional Light> is used to represent light sources that are not at an infinite distance, and which therefore specify a position in space as a <DRM Location 3D>. The field values of a <DRM Base Positional Light> specify a radius of influence and attenuation factors For its subclass <DRM Positional Light>, the radius of influence indicates a sphere of influence. For <DRM Spot Light>, a cone of influence is specified by a <DRM Lobe Data> component, bounded where it meets the sphere specified by the radius value.
4.5.15.3.5 Simulating lighting effects
Images may be used as textures to enhance the visual detail of objects. The DRM supports the use of images with the <DRM Image> class. When used as textures, images are applied to instances of <DRM Geometry> and/or <DRM Feature> as described in 4.5.15.3.3 Applying images as textures. Images may also be used by themselves as spatial objects as described in Error! Reference source not found. Error! Reference source not found. to provide, for example, geo-specific imagery.
4.5.15.4.2 Image specification
A <DRM Image> specifies one or more MIP levels of texels, and may be either 2D or 3D. All such imagery resources in a given transmittal are provided as <DRM Image> components of a <DRM Image Library> instance. See 4.5.11 Constructs for sharing data and 4.5.12.3.3 Applying images as textures for how the contents of a <DRM Image Library> are referenced from other contexts in a transmittal.
For a <DRM Image> instance, the number of MIP levels is specified by the value of its level_count field, which is also the size of its mip_extents_array field. Each entry in mip_extents_array specifies the dimensions of the image in the horizontal, vertical, and z directions. (For a 2D image, the size of the z dimension is defined to be 1.)
The structure of the texel data of a <DRM Image> instance is specified by the field values of the <DRM Image> as follows:
a. The most important field value is its image_signature, which specifies the number of component values in a texel and what they represent. This determines which of the “bits_of”, “min_value_of”, and “max_value_of” fields of the <DRM Image> instance are in play, where those not being used are set to zero. See 5.2.5.22 Image_Signature and <DRM Image> for details of specific image signatures.
b. If the image_signature utilizes colour, the colour_model field specifies the colour_model in use.
c. The component_data_type field value specifies the data type of the components of a texel.
d. The data_is_little_endian determines how individual bytes in the texel data are to be interpreted.
e. The scan_direction and scan_direction_z field values specify how the order of the texel data relates to the ordering of the texels when the <DRM Image> is rendered.
The use of the optional <DRM Image Anchor> component of a <DRM Image> is explained in 4.5.12.3.4 Positioning images as spatial objects. The use of the optional <DRM Property Table Reference> components is described in 5.2.5.22 Image_Signature for the ONE_MATERIAL, TWO_MATERIALS, and THREE_MATERIALS selection values.
4.5.15.4.3 Applying images as textures
A <DRM Image> is applied to a representation of the environment either as a spatial object (see 4.5.12.3.4 Positioning images as spatial data), or or through reference by a <DRM Image Mapping Function>.
A <DRM Image Mapping Function>, as discussed in 4.5.11 Constructs for sharing data, specifies the <DRM Image> being applied as a texture map by means of a one-way association to that <DRM Image>. A <DRM Image Mapping Function> instance specifies the remaining details of how the texture is to be applied to the object(s) being textured, in concert with any applicable <DRM Texture Coordinate> and/or <DRM Tack Point> instances.
The details of how <DRM Image Mapping Function> information is to be combined with colour information, and of how a <DRM Image Mapping Function> may apply modifiers to the texel data to adjust its intensity level, may be found along with other information in the specifications for the respective classes in 6 DRM class definitions. Here, the interaction of <DRM Image Mapping Function> with instances of other classes to specify the mapping itself are specified.
A <DRM Image Mapping Function> instance F may specify a projection that is planar, cylindrical, or spherical. In the case of cylindrical or spherical projections, F shall specify a <DRM Image Anchor> component representing the details of the projection, as specified and constrained in 6.2.20 Image mapping functions and texture coordinates. If F is a component of a <DRM Feature>, F shall specify a <DRM Image Anchor> regardless of the type of projection used. However, in the case where F specifies a planar projection and is part of a geometric representation, <DRM Texture Coordinate> instances or <DRM Tack Point> instances may be specified rather than placing a <DRM Image Anchor> on F itself.
Consider a <DRM Image Mapping Function> F specifying a planar projection, lacking a <DRM Image Anchor> component, and referencing a <DRM Image> that does not specify a <DRM Image Anchor> component itself, where F is a component of some <DRM Geometry> G. The <DRM Primitive Geometry> instances in the component 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 Base Vertex>, <DRM Point>, and <DRM Tack Point> instances. For a <DRM Primitive Geometry> with <DRM Base Vertex> components, either the <DRM Primitive Geometry> shall specify <DRM Tack Point> instances, or the <DRM Base 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 Base 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.5.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.
a. The first <DRM Location> component specifies the position to which the lower left corner of the <DRM Image> is mapped.
b. The second <DRM Location> component specifies the position to which the upper left corner of the <DRM Image> is mapped.
c. The third <DRM Location> component specifies the position to which the upper right corner of the <DRM Image> is mapped.
Note that 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>.
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 component <DRM Location 3D> instance of the <DRM Stamp Behaviour> instance. Both clockwise and counter-clockwise angular limits may be specifed for each axis independently. A sentinel value for infinity shall specify unlimited rotation.
Sound in the DRM is separated into two concepts: that of a sound resource – the actual digitized acoustic phenomenon – and that of a specific instance of such a resource. The latter is the mechanism used to control the presentation of sound, while the former is the sound data itself.
A sound resource (a digital representation of an acoustic phenomenon) is represented in the DRM by an instance of <DRM Sound>. All such sound resources in a given transmittal are provided as <DRM Sound> components of a <DRM Sound Library> instance. See 4.5.12.5.3 Sound presentation for a description of how the contents of a <DRM Sound Library> may be referenced from other contexts in a transmittal.
A <DRM Sound> instance does not itself contain the digitized sound data; instead, its sound_urn field value specifies a URN indicating where that data is located. <DRM Sound> does specify the following:
a. A meaningful short name for the sound;
b. the duration of the sound; i.e., the amount of time in seconds that it takes for the sound to be played once;
c. the sampling_rate of the sound; i.e., the number of samples per second that were recorded when the sound data was captured;
d. the bits_per_sample (also known as “sample size” or “quantization”)
e. a string specifying the encoding and compression schemes used, if applicable
The meaningful short name is not necessarily unique in the context of a given <DRM Sound Library>. If a fuller text description is desired, a <DRM Sound> may have a <DRM Description> component.
Apart from metadata components, a <DRM Sound> may have a <DRM Classification Data> component, specifying the environmental entity being represented by the sound resource in question.
A <DRM Sound> is not referenced directly by a geometric or feature representation; that is, a <DRM Sound> is always a component of a <DRM Sound Library>, and never a component of a <DRM Geometry Hierarchy> or <DRM Feature Hierarchy>. Instead, a <DRM Geometry Hierarchy> or <DRM Feature Hierarchy> may have a collection of <DRM Sound Instance> components.
A <DRM Sound Instance> represents a single case of the existence of a sound; that is, a reference to a <DRM Sound> in a given context, including any specialization unique to that case. The specialization that is possible includes:
a. specifying whether the <DRM Sound Instance> is audible only within a specific area or region,
b. the time interval for which the sound is active, and
c. a dynamic control mechanism to supply finer control over whether the sound is active and under what conditions.
A <DRM Sound Instance> may represent spatialized audio, region-based audio, or environmental audio, depending on the components specified for the <DRM Sound Instance>. Spatialized audio is that for which an explicit location of the sound source is specified. Region-based audio is that for which a boundary of the effect of the sound is specified without explicitly specifying the position of the sound source itself. Environmental audio specifies a sound that is heard throughout a given environment without being bound to a specific position or region. Each of these concepts is discussed in turn.
If a <DRM Sound Instance> SI has a <DRM Location 3D> component L, SI is said to represent spatialized audio. That is, SI indicates that the source of the sound is considered to be located at L. If SI also has a <DRM Fade Range> component F, F is interpreted as follows. A <DRM Fade Range> specifies the range in metres from L at which the sound begins to fade away, and that at which it is completely inaudible. If SI also specifies a <DRM Perimeter Data> or <DRM Sound Volume>, they shall be specified so that L is the centre of the region thus specified. If no boundaries are specified, the data consuming organization is free to interpret the <DRM Sound Instance> based upon its own organizational policy regarding spatialized audio.
If a <DRM Sound Instance> SI specifies a <DRM Sound Volume> and does not specify a <DRM Location 3D>, SI represents region-based audio, where the sound is detectable within the volume of space thus specified, but not outside that volume. (Note that region-based audio is not localized within the given region, since a specific position for the source of the sound is not specified.) If SI also has a <DRM Fade Range> component F, the distances specified by F are considered to be relative to the centre of the <DRM Sound Volume>. If SI specifies no <DRM Fade Range>, audibility is cut off without gradual attenuation at the boundary of the volume.
If a <DRM Sound Instance> SI specifies a <DRM Perimeter Data> and does not specify a <DRM Location 3D>, SI represents region-based audio, where the sound is detectable within the perimeter of the region thus specified, but not outside that region. (Note that region-based audio is not localized within the given region, since a specific position for the source of the sound is not specified.) If SI also has a <DRM Fade Range> component F, the distances specified by F are considered to be relative to the centre of the <DRM Perimeter Data>. If SI specifies no <DRM Fade Range>, audibility is cut off without gradual attenuation at the perimeter.
A <DRM Sound Instance> specifies an active_sound_value flag as one of its fields, indicating the default state of the sound; i.e., whether it is “on” or “off”. A <DRM Sound Instance> may be “off” if a control mechanism is specified that activates the <DRM Sound Instance> under specific conditions. The most powerful method provided for such control is <DRM Sound Instance Control Link>, described in Error! Reference source not found. Error! Reference source not found..
Another method, however, 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 is active only during the time period(s) specified.
A <DRM Label> exists to tie an instance of <DRM Text> or <DRM Symbol> to a <DRM Feature>, possibly to a specific <DRM Location> within that <DRM Feature>, corresponding to the concept of annotating a map with text or symbols.
An instance of <DRM Text> specifies some textual information, together with formatting information specifying how it is to be rendered (such as the font), to be used to label the given <DRM Feature> if it is visually rendered, as on a 2D map or display. The contents of the <DRM Text> may be an identifier but may be any other information desired.
An instance of <DRM Symbol> specifies a pictograph in a standard symbology system, to be used to label the given <DRM Feature> if it is visually rendered, as on a 2D map or display. The symbol_urn field specifies the URN at which the actual pictograph data is to be found.
4.5.16 Constructs for controlling dynamic data
Using <DRM Control Link>s can be applied to a wide range of problems related to representing control over the values of fields and states of DRM objects, as well as representing the behaviour of such control.
This DRM mechanism can be used in transmittals needing a mechanism to allow a consuming system to dynamically control objects within a transmittal. The need for this control extends beyond extracting individual <DRM Model>s for use as "moving models", or objects that are moved through or within the parent transmittal; it includes the need to identify and control the state of objects that are part of the environment that have dynamic behaviour. Examples of these objects include:
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>z in which some of the attributes of the <DRM Model> change from instance to instance. This type of <DRM Model> is sometimes referred to as a "smart instance" or "basis set". Examples include:
· 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, 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.5.16.2 Control links and expressions
The concept behind control links is that the abstract class <DRM Control Link> provides a connection between <DRM Expression> trees and the fields of other SEDRIS objects, called target objects. For each class of target object, there shall be a matching, specialized subclass of <DRM Control Link>, the definition of which specifies how its ordered <DRM Expression> components is 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> defines the desired relationship and behaviour of controlling inputs to values, which 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 defined by a specialization of the <DRM Control Link> class, which 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 defines which of the <DRM State Control Link>'s ordered <DRM Expression> components are to be applied to the fields of the <State Related Geometry>.
There are three subclasses of <DRM Expression>: <DRM Literal>, <DRM Variable>, and <DRM Function>.
4.5.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).
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.5.16.2.3 The <DRM Function> class
<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 defined by the specific function. The arguments, together with the definition 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>.
The <DRM Predefined Function> class specifies the function from the Predefined_Function selection data type. These functions fall into various categories.
Mathematical Constants.
Examples of this category include PI, FALSE, and TRUE.
Unary Mathematical Functions
These functions take a single argument. Examples of these include trigonometric functions such as sine and cosine.
Binary Mathematical Functions
These functions take two arguments. Examples of these include arithmetic functions such as addition and subtraction.
Other
A variety of other useful functions are provided, although not all are currently capable of static evaluation by the SEDRIS API. Some are applicable only at run-time; see 5.2.5.33 Predefined_Function for specifics.
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 them as component <DRM Expression> instances to 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 functions that require no arguments have no components, and a further corollary is that the number of <DRM Expression> components should not exceed the number of arguments for the given function.
<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.
<DRM Pseudo Code Function> is supported for three reasons. First, it is nearly impossible to capture every possible function that could be used to defined the behaviour of control-linked objects. Second, <DRM Expression> instances cannot define functions that require looping, branching, and so on. Finally, given the first two points, it is recognized that many functions, while relatively simple when viewed as pseudo-code or code fragments, would become overly complicated if converted to <DRM Expression> trees.
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.5.16.3 <DRM Control Link> subclasses that turn on and off
4.5.16.3.1 <DRM Light Source Control Link>
<DRM Light Source Control Link> provides control over the active_light_value field of a <DRM Light Source>. This allows the consuming system to turn the <DRM Light Source> on and off at will.
4.5.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's 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. However. if any of the link fields is zero, the corresponding target field is not controlled.
4.5.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.5.16.4 <DRM State Control Link>
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.5.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.4.
Table 4.4 — Example state specification
|
state_tag |
EAC_GENERAL_DAMAGE_FRACTION |
|
active_state_value |
0% |
This indicates that the 'default' state of the aggregation is 0% damage, that is, completely undamaged. The branches' <DRM State Data> link objects have the possible field values (meanings given in the bottom row) shown in Table 4.5.
Table 4.5 — Possible state values example
|
state_value |
0% |
25% |
50% |
100% |
|
meaning |
building's OK |
some damage |
heavy damage |
a little pile of rubble |
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.6.
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.
Table 4.6 — Example <DRM State Control Link>
|
expression_index |
1 |
|
mismatch_behaviour |
LAST |
In the example shown in Table 4.7, 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.
Table 4.7 — Example expression using a <DRM Variable> instance
|
meaning |
{ VARIABLE, ACTIVE_STATE_VALUE} |
|
value_unit |
EUC_UNITLESS |
|
value_scale |
ESC_UNI |
|
value_type |
FLOAT |
|
description |
{ DEFAULT, 12, "damage state"} |
|
runtime_label |
{ DEFAULT, 0, ""} |
Consider a specific building represented by a <DRM State Related Geometry> instance. The data provider in the example shown in Table 4.8 has chosen to model four damage states: 0% damaged, 25% damaged, 50% damaged, and 100% damaged (totally destroyed).
Table 4.8 — Example general damage fraction
|
state_tag |
EAC_GENERAL_DAMAGE_FRACTION |
|
active_state_value |
0% |
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.9.
Table 4.9 — Example possible damage fractions
|
state_value |
0% |
25% |
50% |
100% |
|
meaning |
undamaged |
some damage |
heavy damage |
a little pile of rubble |
Generally speaking, any state-related aggregation should be produced with an appropriate <DRM State Control Link> component. Consequently, the building example needs a <State Control Link> to allow the use of states other than the default of 0% damage.
The <DRM State Control Link> component controls the active_state_value by providing a connection between it and the controlling <DRM Expression>, so that the active_state_value changes to specify which branch of the aggregation is currently active. Since active_state_value is the only controlled field in a state-related aggregation, the <DRM State Control Link> should have exactly one <DRM Expression> component, and therefore its expression_index field value would be one as shown in Table 4.10.
Table 4.10 — Example state control link values
|
expression_index |
1 |
|
mismatch_behaviour |
LAST |
In the example in Error! Reference source not found., 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.
Table 4.11 — Example expression values using variables
|
meaning |
{VARIABLE, ACTIVE_STATE_VALUE} |
|
value_unit |
EUC_UNITLESS |
|
value_scale |
ESC_UNI |
|
value_type |
FLOAT |
|
description |
{DEFAULT, 12, "damage state"} |
|
runtime_label |
{DEFAULT, 0, ""} |
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.5.16.5 Customizing or dynamically changing appearance
4.5.16.5.1 <DRM Control Link> subclasses for the subclasses of <DRMColour Data>
<DRM CMY Colour Control Link>, <DRM HSV Colour Control Link>, and <DRM RGB Colour Control Link> serve exactly the same purposes for their respective colour models. An understanding of the operation of any of the three is an understanding of the principles underlying the operation of all three. Consequently, only the operation of <DRM RGB Colour Control Link> will be described, with the understanding that the explanation applies to the other two classes in principle.
<DRM RGB Colour Control Link> provides control over the red, green, and blue fields of the target <DRM RGB Colour> instances. A data provider is not required to provide control over all three fields. If any of the link fields within an <DRM RGB Colour Control Link> instance is zero, that indicates that the corresponding target field is not controlled.
<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.5.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.5.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. If either of the link fields within a <DRM Texture Coordinate Control Link> instance ( s_expr_index or t_expr_index) is zero, that indicates that the corresponding target field is not controlled.
4.5.16.6 <DRM Control Link> subclasses for table indices
4.5.16.6.1 <DRM Attribute Set Index Control Link>
<DRM Attribute Set Index Control Link> provides control over the index field value of the target <DRM Attribute Set Index> instances. For 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 Attribute Set Table> containing a different <DRM Attribute Set> for each season of the year, which in turn specifies appropriate <DRM Colour> and <DRM Image Mapping Function> instances. The aggregate representing the tree canopy is provided with an <DRM Attribute Set Index> with a component <DRM Attribute Set Index Control Link>, to allow the user to change the <DRM Attribute Set Index> index field to select the appropriate <DRM Attribute Set> for a given time of year.
4.5.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. If either of the link fields within a <DRM Colour Index Control Link> instance is zero, that indicates that the corresponding target field is not controlled.
4.5.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 the user to specify 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.
For 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> has a <DRM Property Table Reference Control Link>, its index_on_axis field value can be changed at will, allowing the user to change the electromagnetic properties of the <DRM Polygon> as a result.
4.5.16.7 <DRM LSR Location 3D Control Link>
<DRM LSR Location 3D Control Link> provides control over the x, y, and z fields of the coordinate fields of the target <DRM LSR Location 3D> instances. Data providers are not required to provide control over all three fields. If any of the link fields within an <DRM LSR Location 3D Control Link> (x_expression_index, y_expression_index, or z_expression_index) is zero, that indicates that the corresponding target field value is not controlled.
For example, consider an <DRM LSR Location 3D> in a <DRM Model> representing a building, where the location represents a point at the foundation of the building. In this case, the data provider wishes to be able to conform each instance of the <DRM Model> to the terrain on which it is instanced, so that the bottom of the building rests on the terrain, regardless of whether the terrain is flat or hilly. The <DRM LSR Location 3D> is provided with an <DRM LSR Location 3D Control Link> that specifies zero for the x and y values of the target, but a controlling <DRM Variable> for the z value.
4.5.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. If any of the link fields within <DRM Reference Vector Control Link> (v0_expression_index, v1_expression_index, and v2_expression_index) is zero, that indicates that the corresponding target is not controlled.
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.
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:
a. metadata provided in compliance with ISO 19115.2 (see [I19115.2]), which is provided solely to allow a human user to make decisions about the information being described,
b. provision of ‘summary’ metadata, to allow a data provider to describe the structure, contents, and patterns of usage in a transmittal.
4.5.17.2 Classes derived from ISO 19115.2
The ‘human-oriented’ metadata classes of the DRM were designed to comply with the International Standard for geospatial metadata as defined in ISO 19115.2 (see [I19115.2]). 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 “human-oriented” metadata classes of the DRM were designed to comply with the ISO standard for geospatial metadata as defined in ISO 19115.2 (see [I19115.2]). 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 meaning of these fields is as defined in ISO 19115.2. This part of ISO/IEC 18023 does not redefine the meaning of the fields, but instead uses a subset of the fields defined in ISO 19115.2 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.2. This part of ISO/IEC 18023 does not maintain the organization between data elements and data class elements described in ISO 19115.2.
4.5.17.2.2 Contact information
The <DRM Point Of Contact> class corresponds to the data element CI_ResponsibleParty of ISO 19115.2; 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 Point Of Contact> and the corresponding ISO 19115.2 data elements:
a. Person_or_position corresponds to the individualName data field of CI_ResponsibleParty.
b. Organization corresponds to the organisationName data field of CI_ResponsibleParty.
c. 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.
d. Voice_phone and fax_phone correspond to data class element CI_Telephone data elements voice and facsimile.
e. Email_address corresponds to the electronicMailAddress data element in data class element CI_Address.
f. Web_site corresponds to data element linkage of data class element CO_OnLineResource.
g. Hours_of_service and other fields correspond respectively to hoursOfService and contactInstructions of the data class element CI_Contact.
h. Role_Code consists of an instance of the ISO 19115 CI_RoleCode data type.
The <DRM Citation> class corresponds to data class element CI_Citation of ISO 19115.2. The title field shall be provided with information, in compliance with the 6.2.27 Mandatory Metadata constraint, as well as at least one entry in the originators field. The following is the listing of the field elements of the <DRM Citation> class and the corresponding ISO 19115.2 data elements:
a. title corresponds to the data element title of data class element CI_Citation;
b. edition corresponds to the data element edition of data class element CI_Citation;
c. originators corresponds to the data element citedResponsibleParty of data class element CI_ResponsibleParty, but is represented by an instance of a string data type to encompass the data fields individualName, organisationName, and positionName;
d. series_name correspdonds to the data element name of data class element CI_Series;
e. issue_id corresponds to data element issueIdentification of data class element CI_Series; and
f. 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.5.13.12 Time for details.
The <DRM Description> class corresponds to the data class element MD_Identification of ISO 19115 (see 2.[I19115]) and is constrained by 6.2.27 Mandatory Metadata to, at a minimum, provide information in its abstract section. The following is the listing of the field elements of the <DRM Description> class and the corresponding ISO 19115 MD_Identification data elements (see 2.[I19115]):
a. Abstract corresponds to data element abstract.
b. Purpose corresponds to data element purpose.
4.5.17.2.5 Data quality information
The <DRM Data Quality> class corresponds to the data class element DQ_Element of ISO 19115.2 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.2 data elements
a. property_accuracy corresponds to the date element DQ_QuantativeAttributeAccuracy, except that it is provided as a string values, rather than being split into the data element nameOfMeasure, measureIdentification, measureDescription, evaluationMethodType, evaluationMethodDescription, evaluationProcedure, dateTime, & result
b. logical_consistency corresponds to the data element DQ_LogicalConsistency, except that it is provided as a string values, rather than being split into the data element nameOfMeasure, measureIdentification, measureDescription, evaluationMethodType, evaluationMethodDescription, evaluationProcedure, dateTime, & result
c. completeness corresponds to the data element DQ_Completeness, except that it is provided as a string values, rather than being split into the data element nameOfMeasure, measureIdentification, measureDescription, evaluationMethodType, evaluationMethodDescription, evaluationProcedure, dateTime, & result
d. abs_pos_accuracy corresponds to the data element DQ_AbsoluteExternalPositionalAccuracy, except that it is provided as a string values, rather than being split into the data element nameOfMeasure, measureIdentification, measureDescription, evaluationMethodType, evaluationMethodDescription, evaluationProcedure, dateTime, & result
e. rel_pos_accuracy corresponds to the data element DQ_RelativeInternalPositionalAccuracy, except that it is provided as a string values, rather than being split into the data element nameOfMeasure, measureIdentification, measureDescription, evaluationMethodType, evaluationMethodDescription, evaluationProcedure, dateTime, & result
The lineage information of ISO 19115.2 in data element LI_Lineage corresponds to the <DRM Source> and <DRM Process> classes in the DRM. 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> 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>. The <DRM Process> class provides a human-readable description of the process directly in its own fields, as well as a mandatory <DRM Absolute Time Point> component specifying the date (and, optionally, time) at which the process was performed. A <DRM Process> may also specify a <DRM Point Of Contact> for the process.
The <DRM Keywords> class corresponds to the data element MD_Keyword of ISO 19115.2, specifying a keyword_count and keyword_array as fields, where 6.2.27 Mandatory Metadata constrains the data provider to provide at least one entry in the array. Each entry of keyword_array is specified as a Keyword_Structure, which 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 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.5.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>, which 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.2 data elements:
a. access_constraints correspond to the data element accessConstraints of MD_LegalConstraints,
b. use_constraints corresponds to the data element useConstraints of MD_LegalConstraints, and
c. security corresponds to the data class element MD_SecurityConstraints.
The security_Info data type consisting of the three string fields system, classification, & handling correspond to the data fields classificationSystem, classification, & handlingDescription of MD_SecurityConstraints in ISO 19115.2.
The 6.2.27 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.
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> is not required to provide a <DRM Browse Media>, although it may provide any number of <DRM Browse Media> components, if desired.
4.5.17.3 Classes describing the structure of a transmittal
The second category of ‘metadata’, summary information about the structure of a transmittal which 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. However, 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:
a. transmittal summary,
b. EDCS usage summary,
c. DRM class usage summary,
d. hierarchy summary, and
e. primitive summary.
4.5.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 defined 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.5.14.1.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.
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:
a. a <DRM DRM Class Summary Item> (see DRM class usage summary, below);
b. a <DRM Primitive Summary Item> (see Primitive summary, below);
c. a <DRM Hierarchy Summary Item> (see Hierarchy summary, below); or
d. 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.5.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.37 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 component may be present only if the drm_class field of the <DRM DRM Class Summary Item> corresponds to a class that specifies spatial reference frame parameters. Each <DRM SRF Summary> then corresponds to a specific spatial reference frame specified by an instance of that class somewhere in the context being summarized.
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>; specifically, only for <DRM Environment Root> and <DRM Model> instances. The 6.2.17 Hierarchy summary constraints constraint specifies restrictions 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.
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 that 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.
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 Point Of Contact>, <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.
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.
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>.
The srf_parameters 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 either a <DRM Feature Hierarchy> or a <DRM Geometry Hierarchy>, or both; it may not be “empty”.)
In the case where a given <DRM Transmittal Root> specifies multiple <DRM Environment Root> components, the srf_parameters 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.
A data provider may have applied coordinate conversion or transformation operations to the data represented in the scope of a <DRM Environment Root> before the data was represented using the DRM. In order to support correlation of data between consumers and producers, an instance of the <DRM Reference Origin> class may be supplied to specify the original spatial reference frame in which the data set was represented, together with a <DRM Location> component specifying the origin of the data in that SRF.
4.6 Application program interface (API)
This part of ISO/IEC 18023 defines a standard API for manipulating SEDRIS transmittals. The API allows users of this part of ISO/IEC 18023 to ignore media and implementation details by abstracting SEDRIS data through the API. The API provides transmittal manipulation capabilities through object retrieval, creation, and modification functionality.
4.6.1.2 Separation of the API from the DRM
The API treats most DRM objects as equal and provides very little specialization based on DRM class. This allows the design of the API to be unencumbered by the specifics of the DRM. This is important in allowing the DRM to be modified through the registration process while maintaining a fully functioning API to work with existing and registered DRM classes. For example instead of creating one function to instantiate each DRM object in a transmittal, the API defines one function capable of instantiating any DRM classes in a transmittal. The API is a complementary piece to the DRM, in that the API cannot be implemented without an understanding of the DRM. The DRM defines the classes, the class attributes, and the class relationships with other classes, but the behaviour of the classes is defined and implemented by the API.
4.6.1.3 Separation of the storage format from the API
The API is separated from the storage format for transmittals and the encodings of such formats. This division allows for one API to provide the access to any number of formats. The API functionality is to be implemented independent of storage format artifacts. Thus, the API focuses on access to the data elements defined in this part of ISO/IEC 18023 and does not provide a mechanism for the storage format or encoding. This allows developers using the API in this part of ISO/IEC 18023 to focus on properly working with the data elements defined herein.
4.6.1.4 Inter-Transmittal Referencing (ITR)
ITR as described in 4.3.3.1.4 Inter-Transmittal Referencing is implemented using the API as opposed to using the DRM. The DRM defines the relationships between the DRM class object instances, but it is the API that provides the functions for accessing these relationships. This holds true for ITR functionality. The API provides the functions that use ITR constructs and as a result the data elements associated with ITR functionality. The DRM does not include a definition of ITR, which is provided by the API.
As a result of separating the API from the storage mechanism, the API provides functionality for working with many different API implementations. For the most part, it is expected that each implementation will only work with one storage format, but that is not required. With multiple API implementations, the same API can be used to store transmittals to different formats, without creating relationships between the different formats. This mechanism can be found throughout the API with the “implementation identifier” parameters throughout API functions. These data elements provide implementers the mechanism to differentiate between API implementations.
4.6.1.6 Read, write, modify interface
Implementing the API and the associated functionality of the functions will require supports extracting data from a transmittal, writing new data to a transmittal, and modifying existing data in a transmittal. Thus, DRM objects can be read, written, and modified. 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. A transmittal is manipulated with the private data type specified in 5.4.9 Transmittal, while DRM objects are manipulated with the private data type specified in 5.4.3 Object. Data manipulation occurs at the object level and as such most API functions deal with the object private type.
4.6.1.7 API operations on base DRM object
The API operations on DRM objects are based on providing the private data type “Object” to an API function. The private data type can also be referred to as an “object handle”. API implementations provide all of the functionality through object handles. DRM objects returned from transmittals are returned as object handles through the “get” functions such as 7.3.50 GetRootObject. Object handles are used to retrieve:
a. related DRM objects, also as object handles,
b. field data of the DRM object,
c. DRM class specific data, and
d. handles to other API constructs such as 5.4.4 Object ID and 5.4.9 Transmittal.
When implementing the DRM object creation capabilities, object handles will be returned, as well as using object handles to modify and data associated with DRM objects.
4.6.1.8 API operations on specific DRM objects
There are only a handful of DRM classes that have specific API operations. These DRM classes are <DRM Image> and the <DRM Data Table> as well as subclasses <DRM Mesh Face Table>, <DRM Property Grid>, and <DRM Property Table>. Since the <DRM Data Table> class is abstract, an API implementation will not create such an instance and hence only the other four classes will ever be instantiated as object handles. These classes have corresponding data that is not defined within the DRM, but is defined within the API. The API provides for instantiation, retrieval, and storage of the data associated with these DRM objects. As such, this capability exists within the API implementation. There is a defined behaviour for all DRM objects for the API operations on specific DRM objects, but the auxiliary data can only be provided for the specific DRM classes.
4.6.1.9 Opening and closing transmittals
In order to access the individual DRM objects through their object handles, it is necessary to operate on the transmittal. In fact the transmittal is the common interchange block as far as the API is concerned. When implemented, the API will first provide the capability to access the transmittal by making available an appropriate object handle followed by the transmittal data inside of the transmittal through the object handle. Thus, the important capabilities are opening and closing a transmittal. By opening, the API will implement the capability to retrieve the transmittal in whatever storage format the API implementation supports and return a handle to the transmittal. This handle can then be used to apply API operations to DRM objects. Upon closing the transmittal the API implementation shall release all resources of the storage format required by that transmittal.
4.6.1.10 Iterating through data
The API provides the iterator mechanism in order to simplify the traversal of DRM object relationships. The private data type Iterator described in 5.4.2 Iterator is a handle to the API construct for an iterator. The API defines iterators as list of object handles which are iterated through with the function described in 7.3.44 GetNextObject. Iterators are initialized with a specific object handle and released when done as described in 7.3.21 FreeIterator. An implementation shall release all resources and object handles related to the iterator when the FreeIterator call is made, regardless of what the iteration state of such an iterator is. Furthermore, iterators provide the advanced filtering capabilities of the API, and are the only mechanism to implement such capabilities.
The API provides for implementing functionality to filter data by specifying the criteria that DRM objects shall satisfy in order to be retrieved through the use of iterators. The API provides for filtering of data by creating a search filter as described in 5.4.7 Search_Filter and providing the search filter handle into the iterator initializing function. The implementation will then use such a search filter to retrieve only the DRM objects that meet the filter criteria.
The API provides for managing the memory associated with the data constructs by providing functions to retrieve or create the data constructs and then providing the corresponding options to release all resources corresponding to that data constructs. These functions take the form of FreeXXX and work with the private data types of the data constructs. Thus, for example, an object handle instantiated through 7.3.44 GetNextObject will need to be released as specified in 7.3.22 FreeObject. Implementations shall implement this functionality so that handles to the various API constructs are valid until the handles are passed into their corresponding FreeXXX function.
4.6.2 Manipulation of DRM Objects
SEDRIS transmittals can be accessed through open transmittal function calls that provide different access permissions. A transmittal is newly created as specified in 7.4.77 OpenTransmittalByLocation. For editing or only reading transmittal data, either 7.4.77 OpenTransmittalByLocation or 7.4.78 OpenTransmittalByName can be used.
In order to start consuming transmittal data, a transmittal is opened and the root object retrieved. The root object is the root of the hierarchy tree of the transmittal as specified by the DRM and is retrieved using 7.3.50 GetRootObject. Navigation of the transmittal can then be performed starting at the root object and using the API. When creating a transmittal, the root object will be set using the function 7.3.102 SetRootObject.
A user may specify how ITR will be handled during consumption using the 5.2.4.28 ITR_Traversal data type. This type allows the API to determine how to retrieve objects that are related through ITR. This type allows a user to return no objects with ITR, report that there is an object pointed to, but not retrieve it, and to retrieve all objects including objects pointed to by ITR.
4.6.2.2 Inserting and removing DRM objects
The API allows users to create previously non-existent transmittals as well as modify transmittals that have already been created. The process of creating new transmittal data requires:
a. instantiating DRM objects,
b. storing the data corresponding to the objects, and
c. creating the transmittal hierarchy by creating the allowed relationships between objects in a transmittal.
Objects of any concrete DRM class can be created using 7.3.13 CreateObject. This call will create an object in the specified transmittal of the specified DRM class. The only requirement is that the transmittal has been opened through one of the OpenTransmittal functions, with access mode set to create or update.
Likewise, objects are removed from a transmittal with the function defined in 7.3.95 RemoveFromTransmittal. This function will remove the object associated with the passed in object handle from the transmittal corresponding to the associated transmittal handle. This function only implements the removal of the DRM object and its associated field data from the transmittal and hence from the media format mechanism. It does not specify any action in regards to the relationships that the object might have with other DRM objects. In order to remove these relationships, the functions 7.3.93 RemoveAssociateRelationship and 7.3.94 RemoveComponentRelationship are provided. These two functions are used to remove the specific relationships between DRM objects.
The API provides the capabilities to retrieve a single component, aggregate, or associate of an object in a transmittal. This is accomplished through the use of the functions 7.3.34 GetComponent, 7.3.31 GetAggregate, and 7.3.32 GetAssociate. These functions can be used once the root object has been retrieved to traverse the complete object hierarchy.
After DRM objects have been retrieved from a transmittal, the API provides functions to retrieve the data associated with each object. The most important object data is the DRM class of the object. This data is provided through 7.3.37 GetDRMClass. The field data of an object is retrieved using the 7.3.39 GetFields function. These functions apply to all DRM objects and are implemented by using the object handles to retrieve the data.
The API provides the private data type defined in 5.4.2 Iterator in order to cycle through a set of DRM objects that are related to an object. There are three types of iterators aggregate, component, and associate, one for each allowed DRM relationship type. The API iterators create an internal list of DRM objects, which are then sequentially retrieved using the function 7.3.44 GetNextObject.
The iterators use the search capability described in 5.3.3.194 Search_Rule. In order to use the searching capability, a valid Search_Rule is passed into the 7.3.18 CreateSearchFilter function and the resulting search filter is then passed into one of the iterator creation functions to create an iterator.
Objects in the iterator list are retrieved using the 7.3.44 GetNextObject function. When the iterator list has been exhausted, the iterator can be deallocated using 7.3.21 FreeIterator.
An aggregate iterator is created with the 7.3.73 InitializeAggregateIterator function which allows the user to provide a search filter. If no search filter is provided, the iterator will initialize to all aggregates. The user cycles through the list with 7.3.44 GetNextObject and when there are no more objects in the list, the iterator is passed into 7.3.21 FreeIterator.
An associate iterator is created with the 7.3.74 InitializeAssociateIterator function which allows the user to provide a search filter as well. If no search filter is provided, the iterator will initialize to all associates. The user cycles through the list with 7.3.44 GetNextObject and when there are no more objects in the list, the iterator is passed into 7.3.21 FreeIterator.
The third type of iterator is the component iterator. This iterator contains more advanced features than the other two types of iterators. Component iterators are created using 7.3.75 InitializeComponentIterator. The objects are retrieved through 7.3.44 GetNextObject, and deallocated with 7.3.21 FreeIterator. Component iterators can retrieve component hierarchies if the maximum search depth is specified greater than one in the Search_Rule. If the maximum search depth is specified is zero, the complete hierarchy rooted at the start object will be retrieve. When retrieving objects, component iterators provide more advance criteria for limiting objects retrieved and specifying the order in which objects are ordered.
4.6.2.3.3 Searching transmittals
The API provides for different searching mechanisms through aggregate, associate, and component iterators. The mechanisms provided for filtering includes search filtering, search bounds, and selecting specific hierarchy paths of a transmittal.
The first mechanism for searching transmittal data is the search filter as described in 5.4.7 Search_Filter. Search filters provide constructs to store a defined set of rules that can be used to filter objects from a SEDRIS transmittal so that only the objects that pass the rules will be returned to the user. The search filter is then passed into an iterator upon initialization. Search filters are created and initialized with search rules, described in 5.3.3.241 Search_Rule, using the function 7.3.18 CreateSearchFilter. When the search filter is not to be used for initializing any other iterators, the implementation shall free all resources associated with the search filter when its handle is passed into 7.3.28 FreeSearchFilter. The following types of searches can be done through the search filtering mechanism:
· Objects with specific field values
Search filters can be used in the initialization of all three types of iterators - aggregate, associate, and component.
Transmittals can be searched by specifying a spatial extent to the component iterator. The spatial extents are then used to evaluate the inclusion of DRM objects. The construct described in 5.3.3.240 Search_Bounds is used to specify the bottom leftmost corner and the highest, rightmost corner of a parallelepiped specifying the spatial extent. This is then passed into the function 7.3.19 CreateSpatialSearchBoundary to allocate the resources necessary for the search boundary and returning a handle to a search boundary as defined in 5.4.7 Search_Filter. The search boundary handle is then passed into the 7.3.76 InitializeComponentIterator function to perform the search evaluation. The search evaluation is implemented by retrieving all DRM objects of DRM class <DRM Location> and determining if the location(s) are within the spatial extent. In order to perform the search evaluation, additional parameters are passed into the 7.3.19 CreateSpatialSearchBoundary function in order to:
a. specify whether the evaluation is 2D in which case only the x and y values of the locations are considered;
b. specify whether the evaluation is 3D and all location data is evaluated;
c. specify if the spatial extent is inclusive or exclusive;
d. specify if the DRM object should be fully enclosed or partially enclosed by the spatial extent; and
e. 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 one at a time outside of component iterators and using the same algorithm with the function 7.3.20 DetermineSpatialInclusion.
The API provides the data constructs to specify which paths down a hierarchy tree through which a component iterator is to iterate. The data construct is specified in 5.3.3.118 Hierarchy_Select_Parameters. This data element specifies which branch(es) will be followed of <DRM Aggregate Geometry> or <DRM Aggregate Feature>, based on the field values of the link object attached to that branch. Furthermore, the data element will provide three different types of branch control: all branches of a specific aggregate type will be excluded, all will be included, or there will be selective inclusion. When selective inclusion is enabled, the 5.3.3.118 Hierarchy_Select_Parameters provides the link object data that is to be included.
The API provides the mechanism for unique and persistent object identifiers to be implemented on a per transmittal basis. These object identifiers can be retrieved through the API as a private data type defined in 5.4.4 Object ID. The object identifier is a handle to the true identifier which is left up to the storage format or API implementation to implement. This part of ISO/IEC 18023 does not define what the object identifier structure shall be, but it shall be able to support the full functionality provided in this part of ISO/IEC 18023. Specifically, it shall support all the functions defined as follows:
a. 7.3.11 CompareObjectIDs requires that two object identifiers can be evaluated to determine if they are equal or one is greater than the other.
b. 7.3.40 GetIDForObject requires that every object will have a unique and persistent identifier and that the API implementation can consistently return that identifier for a DRM object
c. 7.3.48 GetObjectForID requires that API implementations will return the DRM object that corresponds to the object identifier contained within the Object ID handle.
d. 7.3.62 GetTransmittalFromID requires the API implementation will return a handle to the transmittal in which the object associated to the Object ID resides.
e. 7.3.78 ObjectIDToString requires that object identifier associated to the Object ID can be converted and returned as a human readable string.
Persistent requires persistence across the opening and closing of transmittals, while uniqueness is limited to the transmittal scope.
4.6.2.3.5 Multiple object retrieval
The API provides function to retrieve more than one DRM object per function call in order to be implemented in a more efficient method. The first such function is 7.3.51 GetPackedHierarchy. This function retrieves a hierarchy rooted at a given object into a set of data structures that can be directly traversed. The data structure is the structure described in 5.3.3.169 Packed Hierarchy and its accompanying structures defined in 5.3.3.170 Packed Hierarchy Object and 5.3.3.171 Packed Hieararchy Reference. These constructs are specified in this part of ISO/IEC 18023 and implementers need only correctly return them once the 7.3.51 GetPackedHierarchy function is called with an object handle. Furthermore, the resources associated with the DRM objects in the Packed Hierarchy data construct is released upon the data structure being passed into the 7.3.24 FreePackedHierarchy function.
7.3.51 GetPackedHierarchy is defined outside of the context of iterators, but the API provides two additional multiple object retrieval functions that can be used with iterators. The first function is described in 7.3.57 GetRemainingObjectsList. This function iterates over the remaining objects in an iterator and returns all of all of the objects as object handles inside of an array all at one time. The user can then access the array elements in order to get the objects instead of calling the 7.3.44 GetNextObject function for each object. The DRM object corresponding to the object handles are released when the array is passed into the 7.3.26 FreeRemainingObjectsList function.
The function 7.3.58 GetRemainingPackedHierarchies is the second multiple object retrieval function that is used within the context of iterators. This function iterates over the remaining objects available through an iterator and returns packed hierarchies for all of them at one time. The depth to which the sub-hierarchy of each remaining object is extracted below that object can be specified. A depth value of one will only return the components of each remaining object in the iterator. A value of zero indicates that the entire sub-hierarchy of each remaining object is to be returned. A call to the 7.3.27 FreeRemainingPackedHierarchiesList function will require the implementation to free all resources associated to the objects contained within the Packed Hiearchy(ies) and the data structure as well.
The API provides for implementing many functions which can be used to query for information about objects, transmittals, API constructs, and even the API implementation itself. The following is a list of such functionality:
· 7.3.42 GetImplementationIdentifier provides the implementation identifier associated with the API implementation accessing the storage format.
· 7.3.43 GetIterationLengthRemaining will return the number of objects remaining for a given iterator.
· 7.3.47 GetNumberOfPathsToTransmittalRoot determines how many different paths can be traversed from the root object to the given object. Implements a mechanism to determine if a DRM object is shared among many aggregate objects.
· 7.3.49 GetObjectReferenceCount will return how many object handles are referring to DRM object that is being referenced by the passed in object handle.
· 7.3.56 GetRelationCounts will query the DRM object for the number component, aggregate, and associate objects.
· 7.3.61 GetSRFParameters provides the SRF parameters currently in effect for the specified DRM object.
· 7.3.66 GetTransmittalVersionInformation provides the version of the DRM and EDCS used to define the given transmittal by retrieving the data from the Transmittal Root object stored as the root object in the storage format.
· 7.3.67 GetUniqueTransmittalID provides a mechanism for the API implementation to provide a string identifier for the associated transmittal, which can then be compared with identifiers from other transmittals.
· 7.3.70 HasAggregates queries the DRM object to determine if it has aggregate objects as specified by this function.
· 7.3.71 HasAssociations queries the DRM object to determine if it has associate objects as specified by this function.
· 7.3.72 HasComponents queries the DRM object to determine if it has component objects as specified by this function.
· 7.3.81 ObjectsAreSame provides the functionality to determine whether two object handles refer to the same DRM object in a transmittal.
4.6.2.5 Modification of fields
The API provides the functionality to create objects and to set the field values of newly created objects with the 7.3.89 PutFields function. This function takes the fields data structure and instructs the API implementation to store the field values to the associated object referenced by the object handle. The same mechanism is used to modify existing field values. An object handle is retrieved through any of the functions providing access functionality and the fields are retrieved using the GetFields function. The fields are then modified and the call is made to 7.3.89 PutFields which stores the new field values as long as the transmittal was opened with the correct mode. The API implementation is responsible for verifying that the object can, in fact, be modified.
4.6.2.6 Modification of object relationships
The functions 7.4.2 AddAssociateRelationship and 7.4.3 AddComponentRelationship create the relationships between DRM objects in a transmittal. In each case, the two objects to create relationships are passed in and the relationships made. The 7.4.2 AddAssociateRelationship function also creates the aggregate relationship required. In the case where associate objects have a bi-directional relationship (i.e. both objects associate to each other), the user can determine when to create the second half of the associate relationship by a parameter into 7.4.2 AddAssociateRelationship.
In the case of ITR, there are two methods to creating ITR relationships. If both objects are accessible and hence both transmittals have been opened correctly, the 7.4.2 AddAssociateRelationship and 7.4.3 AddComponentRelationship functions are used. If one of the transmittals and hence one of the objects is not available, the user can create a placeholder object using the function described in 7.3.59 GetUnresolvedObjectFromPublishedLabel.
4.6.2.7 Access and modification of data table data
The <DRM Data Table> subclasses contain auxiliary data as defined by its components (see 4.5.6 Data Tables for a complete description of the <DRM Data Table> subclasses). The API provides the functionality required to retrieve and store the data associated with Data Table. There are three functions used to retrieve the data associated with data tables:
· 7.3.38 GetElementOfDataTable
7.3.36 GetDataTable provides the capability to specify a subset of the data extents and a subset of elements and returns the data as an array of pointers to the data construct defined in 5.3.3.201 Property_Data_Value. 7.3.38 GetElementOfDataTable provides the capability to specify a subset of the data extent for one element. 7.3.50 GetPackedDataTable provides the capability to provide a subset of the data extent and a subset of the elements, but returns the data as an array unsigned bytes. This part of ISO/IEC 18023 does not define the storage format for the data nor do the above functions require that the implementation store the data as they are retrieved. In fact, the largest discriminant between the three access function for data associated with Data Table objects is the organization of the returned data. The 7.3.36 GetDataTable function will return data that is heterogeneous, that is to say the data could be composed of bytes and floats and integers depending on what is retrieved as a result the data will be returned as an array of data structures that can contain any of the fundamental data types of this part of ISO/IEC 18023. The 7.3.38 GetElementOfDataTable function provides only one element and hence only one type of fundamental type. As a result, the data returned from 7.3.38 GetElementOfDataTable can only contain one fundamental data type. The 7.3.50 GetPackedDataTable will convert the cell data into bytes requiring more effort on user to consume the data, but being more memory efficient.
The API defines functions capable of writing the data associate with Data Table objects which parallel the Get functions. Thus, the functions defined are 7.3.85 PutDataTable, 7.3.87 PutElementOfDataTable, and 7.3.91 PutPackedDataTable. The implementation shall verify that all of the necessary DRM objects have been added as components to the Data Table objects in order to properly store the data.
4.6.2.8 Access and modification of image data
The <DRM Image> DRM class is the only other class that has auxiliary data defined and stored through the API. As a result, the API defines both the 7.3.41 GetImageData retrieval function and the 7.3.90 PutImageData storage function. The data is manipulated both when retrieving and when storing the data as an array of bytes. This part of ISO/IEC 18023 does not define what the storage mechanism not the storage format will be for the image data.
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.7 CloneObject provides a new handle to an existing DRM object.
4.6.3 Inter-Transmittal Referencing (ITR)
The API defines a set of data constructs and functions that operate on those constructs as well as transmittals and objects in order to provide the functionality of ITR. The API defines the requirements necessary to for ITR references to be created and for retrieving the data associated with such references.
In order for ITR references to be created, two conditions shall be met. First, the transmittal shall have a transmittal URN. Second, the object to be used in ITR references shall be “published” through the API publishing mechanism. Providing a transmittal URN name is accomplished through the function described in 7.3.106 SetTransmittalName. This part of ISO/IEC 18023 does not define what the data structure for such a URN will be nor how it will be stored. All that is required is that an implementation store the URN name with the transmittal storage mechanism and that the name can be retrieved with the function 7.3.65 GetTransmittalName. The second requirement for ITR references is accomplished through the function 7.3.84 PublishObject. This function will assign a label of type string to the DRM object corresponding to the object handle. This part of ISO/IEC 18023 does not define the structure of the storage mechanism used to store this information, but requires that the information can be retrieved with the function 7.3.52 GetPublishedLabels.
The API defines two additional functions which provide information about the ITR references at the scope of a transmittal. The function 7.3.53 GetPublishedObjectList returns a list of all objects that are published in a transmittal. The function 7.3.54 GetReferencedTransmittalList returns a list of all URN transmittal names for the transmittals referenced by the transmittal passed into the function. The implementation shall store this data along with the transmittal storage mechanism since this part of ISO/IEC 18023 defines no data construct for such storage. This data shall be correctly stored by the implementation when ITR references are created through the use of 7.4.3 AddComponentRelationship and 7.4.2 AddAssociateRelationship.
One additional function is defined to retrieve ITR information at the object level. The function 7.3.79 ObjectIsPublished provides a Boolean answer when an object is queried to determine if it has been published.
Another large area dealing with ITR is the concept of ITR resolution. The API mechanism defines the constructs needed for this capability. When traversing a transmittal through the access functions of the API, how ITR will be handled is specified. When ignoring or stopping at ITR references, no resolution occurs, but when resolving ITR references, the implementation is required to retrieve transmittal and DRM objects automatically. This part of ISO/IEC 18023 does not define the algorithm used to retrieve a storage mechanism from the URN transmittal name. Such a mechanism is in the purview of the implementation. The API defines the functions which manipulate the mechanism, but not the mechanism itself. Therefore, the API function 7.3.64 GetTransmittalLocation will activate the resolution mechanism by providing a URN name and requiring the implementation to resolve to a specified file location. Likewise, the function 7.3.83 OpenTransmittalByName will use the resolution mechanism of the implementation to determine the location of the storage mechanism and open the transmittal. The function 7.3.97 ResolveTransmittalName will take a URN transmittal name and exercise the resolution mechanism to resolve to a storage file.
The final set of ITR functionality defined by the API corresponds to object and object resolution. Through the ITR options of accessing objects in a transmittal object handles can be returned that do not contain the actual handle to the DRM object. Instead they will be placeholders for the DRM object and contain the ITR information necessary to retrieve the objects. This information would be the URN transmittal name and the published label of the object being referenced. The function 7.3.80 ObjectIsResolved queries the API implementation to determine if the object handle contains a reference to the actual object in a transmittal or if it contains the ITR information necessary to retrieve the object. When the case is the former, the handle is termed an “unresolved object” and when it is the latter, it is termed a “resolved object .” The function 7.3.80 ObjectIsResolved queries the object handle to determine which is the case. If the case is former, the actual object is not being referenced,. The function 7.3.96 ResolveObject is then used to attempt to reference the actual DRM object.
ITR references are created by the API implementation when objects in different transmittals are related through the functions 7.4.2 AddAssociateRelationship and 7.4.3 AddComponentRelationship. To make these relationships with objects in different transmittals, the objects shall be resolved unless the function 7.3.68 GetUnresolvedObjectFromPublishedLabel is used. This function will create and unresolved object; i.e., an object handle containing the ITR information, which can be used in 7.4.2 AddAssociateRelationship and 7.4.3 AddComponentRelationship to create the ITR references.
The API provides functionality to convert the transmittal data stored in the storage mechanism and converting it as specified by a user. An implementation shall support the conversion of such data without modifying the storage mechanism.
Two functions are defined in this part of ISO/IEC 18023 for converting the Location data in a transmittal, 7.3.105 SetSRFParameters and 7.3.112 UseDefaultSRFParameters.
The 7.3.105 SetSRFParameters function sets the SRF that will be used to represent all <DRM Location> objects returned after this function is called. This function has no effect on <DRM Location> objects that have already been returned to the user before this function was called. See [2.I18026] for details on the various SRFs supported by this part of ISO/IEC 18023. The implementation will convert <DRM Location> objects by modifying both the DRM class returned by <DRM Location> objects and the field data associated with the <DRM Location> objects.
The function 7.3.112 UseDefaultSRFParameters places the API into the “default” SRF state, in which <DRM Location> objects are returned based entirely on the SRF in which they were originally encoded in the transmittal. In this case, the <DRM Location> objects will have the DRM class and field values that are stored on the storage mechanism.
The API defines the functions 7.3.98 SetColourModel and 7.3.111 UseDefaultColorModel to manipulate colour conversion at the API level. The function 7.3.98 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. The function 7.3.111 UseDefaultColorModel returns <DRM Colour> objects with the DRM class and field values stored on the storage mechanism.
The API defines a set of functions that can be considered utility functions. These functions provide utility in processing transmittal objects, but not from any inherent data in the transmittal, but more with information about the API constructs. The utility functions are provided herein:
· 7.3.109 TransmittalAreSame determines if two transmittal handles are referencing the same transmittal defined by a single storage mechanism.
· 7.3.60 GetSortKey provides a value that can be used as a sort key for the object.
· 7.3.107 SetUserData stores a handle to user defined memory to a DRM object within the scope of the object going in and out of memory.
· 7.3.60 GetUserData provides the handle to the user defined memory provided by 7.3.107 SetUserData.
The API defines one function for an implementation to handle error conditions. GetErrorDescription provides a human readable string explaining the error condition encountered within the API implementation when an error condition is returned fron an API function. This part of ISO/IEC 18023 does not specify the format for the explanatory string nor the level of information contained within.
To insure 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:
a. which SEDRIS features are required;
b. capacity requirements attuned to the requirements supported by the profile;
c. which optional capabilities are required; and
d. which registered items are required.
The Default Profile is defined which incorporates all of SEDRIS as 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 defined by amending this part of ISO/IEC 18023.
The orderly evolution of SEDRIS functionality is supported through the registration of one of the following in the International Registry of Graphical Items:
a. selection item data type selectors
b. set data type members
Each of these is described in more detail below.
Registration is accomplished by preparing a registration proposal as specified in [2.I9973] and submitting this proposal using the procedures described therein.
4.8.2 Registration of selection item values
Selection item data types provide for the specification of three types of values:
a. standard values
b. registered values
c. implementation dependent values
Standard items are those values for a selection item data type which 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 which have been submitted to the International Registry of Graphical Items using the procedures specified in [2.I9973]. 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 defines 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.8.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 defined 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.