7.2.1.  Boolean

A Boolean representation of a property can take only two values that should be “true/false” or “yes/no”. In a sense, this type of representation is a particular case of the categorical representation with only two predefined options.

Example

The “Boolean” class described in Clause 8.2.4 is used to define a data component with a Boolean representation.

7.2.2.  Categorical

A categorical representation is a type of discrete representation of a property that only allows picking a value from a well defined list of possibilities (i.e., categories). This list is called a code space in this standard, following ISO 19103 terminology.

The different possible values constituting a code space are usually listed explicitly in an out-of-band dictionary or ontology. This is necessary because each value should be defined formally and unambiguously, so that it can be interpreted correctly.

Example

The “Category” class described in Clause 8.2.6 is used to define a data component with a categorical representation.

7.2.3.  Numerical (continuous)

Perhaps the most used representation of a property value, especially in the science and technical communities, is the numerical one, as the majority of properties measured by sensors can be represented by numbers.

Numerical representation is often used for continuous values and, in this case, the representation consists of a decimal (often floating point) number associated to a scale or unit of measure. The unit specification is mandatory even for quantities such as ratios that have no physical unit (in this case a scale factor is provided such as 1, 1/100 for percents, 1/1000 for per thousands, etc.).

Example

The “Quantity” class described in Clause 8.2.8 is used to define a data component with a decimal representation and a unit of measure.

7.2.4.  Countable (discrete)

Discrete countable properties are also of interest and are most accurately captured with a numerical integer representation. They do not require a unit since the unit is always the unit of count (i.e., the person if we are counting persons, the pixel if we are counting pixels, etc). Note that continuous properties can also be represented as integers with certain combinations of scale and precision. This case should not be confused with the countable properties described here.

Example

A discrete countable representation should not be confused with a continuous numerical representation whose scale and precision allow encoding the property value as an integer.

The “Count” class described in Clause 8.2.7 is used to define a data component with an integer representation and no unit of measure.

7.2.5.  Textual

A textual representation is useful for providing human readable data, expressed in natural language, as well as various alpha numeric tokens that cannot be assigned to well-defined categories.

Example

The “Text” class described in Clause 8.2.5 is used to define a data component with a textual representation.

7.2.6.  Constraints

Constraints can be added to some representation types to further restrict the set of possible values allowed for a given property.

These constraints apply only to the value of the data component to which they are associated. They shall not be used to express constraints on other data components or on any other information than the value.

Example

7.3.1.  Human readable information

The first means by which nature of data can be communicated is through human readable text. The data component’s description, which is present in all data types defined in this specification, can hold any length of text for this purpose. The data component’s label is used to carry short human readable information (i.e., a short name); this is useful to allow data consumers to quickly identify the represented property.

It is not recommended to use the concepts of “description” and “label” in a way that they contain robust semantic information (i.e., that machines can rely upon). The content of such fields is intended to be interpretable solely by humans.

7.3.2.  Robust semantics

All SWE Common data types allow for associating each data component in a dataset with the definition of the Property that it represents.

It is recommended that a model uses references to out-of-band dictionaries rather than inline information because semantics are supposed to be shared by multiple datasets. Using references also helps by providing a framework that is independent from the actual semantic technology used.

The SWE Common UML models and JSON schemas described in this standard can be used in combination with any semantic web technology. It is thus possible to connect a SWE dataset description to an existing taxonomy provided the external register exposes a unique identifier for each entry.

These semantic references point to out-of-band semantic information that can be encoded in various languages, such as the Ontology Web Language (OWL) or GML dictionary.

7.3.3.  Time, space and projected quantities

Temporal, spatial and other projected quantities need to be further defined by specifying the reference frame and axis with respect to which the quantity is expressed. In SWE Common, any simple component type can be associated to a particular axis of a given reference frame.

Example

The “Time” class described in Clause 8.2.9 is designed for carrying a temporal reference frame or a time of reference in the case of relative time data.

The “Vector” class detailed in Clause 8.3.2 is a special type of record used to assign a reference frame to all its child-components.

The “Matrix” class defined in Clause 8.5.2 allows the definition of higher order tensor quantities.

This standard does not impose requirements on the type of reference frames that a standardization target shall support. Standards that are dependent on this specification can (and often should) however define a minimum set of reference frames that shall be supported by all implementations.

7.4.1.  Simple quality information

Simple quality information can be associated with any scalar data component, in the form of another scalar or range value. The quality information defined here applies solely to the value of the associated data component (i.e., the measurement value) and, depending on its data type, quality can be represented by a numerical, categorical or textual value, or by a range of values.

This quality information can be static, i.e., constant over the whole dataset, or dynamic and provided with the data itself. In this case, the quality value is in fact carried by another component of the dataset (and described in SWE Common as such).

The exact type of quality information provided should be specified via semantic tagging just like with any other property in SWE Common.

Example

7.4.2.  Nil Values

The concept of NIL value is used to indicate that the actual value of a property cannot be given in the data stream, and that a special code (i.e., reserved value) is used instead. It is thus a kind of quality information. The reason for which the value is not included is essential for a good interpretation of the data, so each reserved value is associated to a well-defined reason. In that sense, a NIL value definition is essentially a mapping between a reserved value and a reason.

Each component of a dataset can define one or several NIL values corresponding to one or more reasons.

Example

7.4.3.  Full lineage and traceability

Full lineage and traceability is not in the scope of this specification. It is fully addressed by the OGC® Sensor Model Language Standard, which allows robust definition of measurement chains, with detailed information about the processing that takes place at each stage of the chain. This means that complex lineage guarantying full traceability can be recorded in a SensorML process chain, separately from the data itself.

Datasets can be associated to lineage information described using the Sensor Model Language by using a metadata wrapper such as the “Observation” object defined in the OGC® Observations, Measurements and Samples Specification (OMS). In this standard, the “procedure” and “observer” properties of the “Observation” class allows attaching detailed information about the measurement process (that is to say a description of how the data was obtained, i.e., lineage), to the data itself.

8.2.1.  Basic Data Types

This requirement class also includes requirements for the “Basic Types” UML package. This package defines low level data types that are used as property types by classes defined in the other packages.

Data types defined in this package relate to defining pairs of data types defined in ISO 19103 for use within classes describing value extents:

Figure 6 — Basic types for pairs of scalar types

8.2.2.  Attributes shared by all data components

All SWE Common data component classes carry standard attributes inherited (transitively) from the “AbstractDataComponent” and “AbstractSWEIdentifiable” classes (The “AbstractSWEIdentifiable” class is actually defined in the “Basic Types” package but is shown here for clarity). The class hierarchy is shown on the following UML diagram:

Figure 7 — AbstractDataComponent Class

Label and Description

The optional “label” and “description” attributes can be used to provide human readable information describing what property the component represents. The “label” is meant to hold a short descriptive name whereas “description” can carry any length of plain text. These two fields should not be used to specify robust semantic information (see Clause 7.3.2). Instead, the “definition” attribute described below should be used for that purpose.

Identifier

The optional “id” attribute allows assigning a unique identifier to the component, so that it can be referenced later on. It can be used, for example, when defining the unique identifier of a universal constant.

Definition

The “definition” attribute identifies the property (often an observed property in our context) that the data component represents by using a scoped name. It should map to a controlled term defined in a (web accessible) dictionary, registry or ontology. Such terms provide the formal textual definition agreed upon by one or more communities, eventually illustrated by pictures and diagrams as well as additional semantic information such as relationships to units and other concepts, ontological mappings, etc.

Example

Flags

The “optional” attribute is an optional flag indicating if the component value can be omitted in the data stream. It is only meaningful if the component is used as a schema descriptor (i.e., not for a component containing an inline value). It is ‘false’ by default.

The “updatable” attribute is an optional flag indicating if the component value is fixed or can be updated. It is only applicable if the data component is used to define the input of a process (i.e., when used to define the input or parameter of a service, process or sensor, but not when used to define the content of a dataset).

Example

8.2.3.  Attributes shared by all simple data components

As shown on Figures 4 and 5, classes modeling simple data components inherit attributes from the “AbstractSimpleComponent” class from which they are directly derived. This abstract class is shown again below:

Figure 8 — AbstractSimpleComponent Class

The definition attribute inherited from the “AbstractDataComponent” class is mandatory on this class and thus on all its descendants.

Reference Frames and Axes

It provides two attributes allowing the association of a data component to a reference frame and an axis and thus implements core concepts introduced in Clause 7.3.3. These attributes are used for a component which value is the projection of a property along a temporal or spatial axis.

The “referenceFrame” attribute identifies the reference frame (as defined by the “SC_CRS” object) relative to which the coordinate value is given. The “axisID” attribute takes a string that uniquely identifies one of the reference frame’s axes along which the coordinate value is given.

The union of these two attributes thus uniquely identifies one axis of one given reference frame along which the value of the component is expressed. Note that even though the ISO 19111 model assigns units to CRS axes in addition to a direction, only the direction is used in this standard and the unit is defined by the data component itself. This allows expressing other quantities than the one predefined along the CRS’s axes such as velocity, acceleration or rotation.

A component representing a projected quantity can be defined in isolation or can be contained within a “Vector” or ”Matrix” aggregate when it contributes to the specification of a multi-dimensional quantity (see Clauses 8.3.2 and 8.5.2). In this last case the reference frame definition is usually inherited from the parent “Vector” or ”Matrix” instance and is thus omitted from the scalar component itself. However, the “axisID” attribute still needs to be specified on “Vector” components.

Quality

The optional “quality” attribute is used to provide simple quality information as discussed in Clause 7.4.1. It is of type “Quality” which is a union of several classes as defined in Clause 8.2.15. Its multiplicity is more than one which means that several quality measures can be given on for a single data component.

Example

Nil Values

The optional “nilValues” attribute is used to provide a list (i.e., one or more) of NIL values as defined in Clause 7.4.2. The model of the “NilValues” class is detailed in Clause 8.2.16.

Concrete sub-classes of “AbstractSimpleComponent” can also define a “constraint” attribute that allows further restriction of the possible values allowed by the corresponding representation. This implements concepts defined in Clause 7.2.6. These constraints always apply to the value of the property as represented by the corresponding data component whether this value is given inline (data container case) or out-of-band (data descriptor case).

Constraints

All concrete sub-classes of “AbstractSimpleComponent” also define a “value” attribute. This attribute is not defined in this abstract class because it has a different primitive type in each concrete data component class (See following clauses).

The “value” attribute is always optional on any simple data component in order to allow for both data descriptor and data container cases.

Whether the data component is used as a descriptor or a container depends on the context and should be explicitly stated by any standard that makes use of the SWE Common Data Model.

All UML classes in this package that derive from “AbstractSimpleComponent” define a “value” attribute with the adequate primitive type and whose meaning is the one explained above.

8.2.4.  Boolean Class

The “Boolean” class is used to specify a scalar data component with a Boolean representation as defined in Clause 7.2.1. It derives from “AbstractSimpleComponent” and is shown below:

Figure 9 — Boolean Class

The “value” attribute of this class is of the boolean primitive type.

8.2.5.  Text Class

The “Text” class is used to specify a component with a textual representation as defined in Clause 7.2.5. It derives from “AbstractSimpleComponent” and is shown below:

Figure 10 — Text Class

Constraints

The “constraint” attribute allows further restricting the range of possible values by using the “AllowedTokens” class defined in Clause 8.2.17. This class allows the definition of the constraint by either enumerating the allowed tokens and/or by specifying a pattern that the value must match.

Value

The “value” attribute (or the corresponding value in out-of-band data) is a string that must match the constraint.

8.2.6.  Category Class

The “Category” class is used to specify a scalar data component with a categorical representation as defined in Clause 7.2.2. It derives from “AbstractSimpleComponent” and is shown below:

Figure 11 — Category Class

Code Space

The “codeSpace” attribute is of type “Dictionary” and allows listing and defining the meaning of all possible values for this component. It is expected that instances of the “Dictionary” class will usually be referenced (rather than included inline) by implementations of this class since the code space definition is usually obtained from a controlled vocabulary maintained at a remote location. This type of implementation is the one chosen in the JSON encodings defined by this standard.

Constraints

The “constraint” attribute allows further restricting the list of possible values by using the “AllowedTokens” class defined in Clause 8.2.17. This is usually done by specifying a limited list of possible values, which have to be extracted from the code space.

It is also possible to use this class without a code space, even though it is not recommended as values allowed in the component would then not be formally defined. However, as the intent of this class is to always represent a value extracted from a set of possible options, a constraint shall be defined if no code space is specified.

Value

The “value” attribute (or the corresponding value in out-of-band data) is a string that must be one of the items of the code space and also match the constraint.

8.2.7.  Count Class

The “Count” class is used to specify a scalar data component with a discrete countable representation as defined in Clause 7.2.4. It derives from “AbstractSimpleComponent” and is shown below:

Figure 12 — Count Class

Constraints

The “constraint” attribute can be used to restrict the range of possible values to a list of inclusive intervals and/or single values using the “AllowedValues” class defined in Clause 8.2.18. Numbers used to define these constraints should be integers and expressed in the same scale as the count value itself. The “significantFigures” constraint allowed by the “AllowedValues” class is not applicable to the “Count” class.

Value

The “value” attribute (or the corresponding value in out-of-band data) is an integer that must be within one of the constraint intervals or exactly one of the enumerated values.

8.2.8.  Quantity Class

The “Quantity” class is used to specify a component with a continuous numerical representation as defined in Clause 7.2.3. It derives from “AbstractSimpleComponent” and is shown below:

Figure 13 — Quantity Class

Unit of Measure (UoM)

In addition to attributes inherited from the “AbstractSimpleComponent” class, this class provides a unit of measure declaration through the “uom” attribute. This unit is essential for the correct interpretation of data represented as decimal numbers and is thus mandatory. Quantities with no physical unit still have a scale (such as unity, percent, per thousands, etc.) that must be specified with this property.

Constraints

The “constraint” attribute is used to restrict the range of possible values to a list of inclusive intervals and/or single values using the “AllowedValues” class defined in Clause 8.2.18. Numbers used to define these constraints must be expressed in the same unit as the quantity value itself. Additionally, it is possible to constrain the number of significant digits that can be added after the decimal point.

Value

The “value” attribute (or the corresponding value in out-of-band data) is a real value that is within one of the constraint intervals or exactly one of the enumerated values, and most importantly is expressed in the unit specified.

8.2.9.  Time Class

The “Time” class is used to specify a component with a date-time representation and whose value is projected along the axis of a temporal reference frame. This class is also necessary to specify that a time value is expressed in a calendar system. This class derives from “AbstractSimpleComponent” and is shown below:

Figure 14 — Time Class

Time is treated as a special type of continuous numerical quantity that can be either expressed as a scalar number with a temporal unit or a calendar date with or without a time of day. Consequently, this class has all properties of the “Quantity” class, plus some others that are specific to the treatment of time.

Reference Frame

As time is always expressed relative to a particular reference frame, the “referenceFrame” attribute inherited from the parent class “AbstractSimpleComponent” shall always be set on instances on this class unless the default ‘UTC’ is meant.

Note that specifying the frame of reference is required even when using ISO notation because there can be ambiguities between several universal time references such as UTC, TAI, GPS, UT1, etc… Differences between these different time reference systems are indeed in the order of a few seconds (and increasing), that is to say not negligible in various situations.

Example

The “axisID” attribute inherited from the parent class does not need to be set since a time reference system always has a single dimension. However it can be set to ‘T’ for consistency with spatial axes.

Reference Time

The “referenceTime” attribute is used to specify a different time origin than the one sometimes implied by the “referenceFrame”. This is used to express a time relative to an arbitrary epoch (i.e., different from the origin of a well known reference frame). The new time origin specified by “referenceTime” shall be expressed with respect to the reference frame specified and is of type “DateTime”. This forces the definition of this origin as a calendar date/time combination.

Example

Local Frame

The optional “localFrame” attribute allows for the definition of a local temporal frame of reference through the value of the component (i.e., we are specifying a time origin), as opposed to the referenceFrame which specifies that the value of the component is in reference to this frame.

This feature allows chaining several relative time positions. This is similar to what is done with spatial position in a geopositioning algorithm (and which is also supported by this standard using the “Vector” class).

Example

Unit of Measure (UoM)

The “uom” attribute is mandatory since time is a continuous property that shall always be expressed in a well defined scale. The only units allowed are obviously time units.

Constraints

Similarly to the “Quantity” class, the “constraint” attribute allows further restricting the range of possible time values by using the “AllowedTimes” class defined in Clause 8.2.19.

Value

The “value” attribute (or the corresponding value in out-of-band data) is of type “TimePosition” (see Clause 8.2.1) and must match the constraint.

8.2.10.  Requirements applicable to all range classes

This UML package defines four classes “CategoryRange,” “CountRange,” “QuantityRange,” and “TimeRange” that are used for representing extents of property values. These classes have common requirements that are expressed in this clause.

The “value” attribute of all these classes takes a pair of values (with a datatype corresponding to the representation) that represent the inclusive minimum and maximum bounds of the extent. These values must both satisfy the constraints specified by an instance of the class, and be expressed in the unit specified when applicable.

8.2.11.  CategoryRange Class

The “CategoryRange” class is used to express a value extent using the categorical representation of a property. It defines the same attributes as the “Category” class and those should be used in the same way (see Clause 8.2.6):

Figure 15 — CategoryRange Class

Code Space

The “CategoryRange” class also requires that the underlying code space is well-ordered (i.e., the ordering of the different categories in the code space is clearly defined) so that the range is meaningful.

Example

Value

The “value” attribute of the “CategoryRange” class takes a pair of tokens representing the inclusive minimum and maximum bounds of the extent.

8.2.12.  CountRange Class

The “CountRange” class is used to express a value extent using the discrete countable representation of a property. It defines the same attributes as the “Count” class and those should be used in the same way (see Clause 8.2.7):

Figure 16 — CountRange Class

Value

The “value” attribute of the “CountRange” class takes a pair of integer numbers representing the inclusive minimum and maximum bounds of the extent.

8.2.13.  QuantityRange Class

The “QuantityRange” class is used to express a value extent using the discrete countable representation of a property. It defines the same attributes as the “Quantity” class and those should be used in the same way (see Clause 8.2.8):

Figure 17 — QuantityRange Class

Value

The “value” attribute of the “QuantityRange” class takes a pair of real numbers representing the inclusive minimum and maximum bounds of the extent.

8.2.14.  TimeRange Class

The “TimeRange” class is used to express a value extent of a time property. It defines the same attributes as the “Time” class and those should be used in the same way (see Clause 8.2.9):

Figure 18 — TimeRange Class

The “value” attribute of the “TimeRange” class takes a pair of values of type “TimePosition” representing the inclusive minimum and maximum bounds of the extent.

8.2.15.  Quality Union

The “Quality” class is a union allowing the use of different representations of quality.

Quality can indeed be specified as a decimal value, an interval, a categorical value or a textual statement. In our model, quality objects are in fact data components used in a recursive way, as shown on the following diagram:

Figure 19 — Quality Union

These different representations of quality are useful to cover most use cases where simple quality information is provided with the data.

Example

The “definition” attribute of the chosen quality component helps to further define the type of quality information given just like any other data component, and the “uom” should be specified in the case of a decimal quality value or interval.

8.2.16.  NilValues Class

The “NilValues” class is used by all classes deriving from “AbstractSimpleComponent”. It allows the specification of one or more reserved values that may be included in a data stream when the normal measurement value is not available (see Clause 7.4.2). The UML model of this class is given below:

Figure 20 — NilValues Class

An instance of the “NilValues” class is composed of one to many “NilValue” objects, each of which specifies a mapping between a reserved value and a reason.

The mandatory “reason” attribute indicates the reason why a measurement value is not available. It is a resolvable reference to a controlled term that provides the formal textual definition of this reason (usually agreed upon by one or more communities).

The mandatory “value” attribute specifies the data value that would be found in the stream to indicate that a measurement value is missing for the corresponding reason. The range of values allowed here is the range of values allowed by the datatype of the parent data component.

This means that when specifying NIL values for a “Quantity” component, only real values are allowed (in most implementations, this includes NaN, -INF and INF) and for a “Count” component only integer values are allowed.

Consequently, it is also impossible to specify NIL values for a “Boolean” data component since it allows only two possible values. In this case a “Category” component should be used.

There are no restrictions on the choice of NIL values for “Category” and “Text” components since their datatype is String.

8.2.17.  AllowedTokens Class

The “AllowedTokens” class is used to express constraints on the value of a data component represented by a “Text” or a “Category” class. The UML class is shown below:

Figure 21 — AllowedTokens Class

This class allows defining the constraint either by enumerating a list of allowed values by using one or more “value” attributes and/or by specifying a pattern that the value must match. The value must then either be one of the enumerated tokens or match the pattern.

8.2.18.  AllowedValues Class

The “AllowedValues” class is used to express constraints on the value of a data component represented by a “Count” or a “Quantity” class. The UML class is shown below:

Figure 22 — AllowedValues Class

This class allows constraints to be defined either by enumerating a list of allowed values and/or a list of inclusive intervals. To be valid, the value must either be one of the enumerated values or included in one of the intervals. The numbers used in the “value” and “interval” properties shall be expressed in the same unit as the parent data component.

If the parent data component instance is used to define a projected quantity (i.e., when the “axisID” is set), then the constraints given by this class are expressed along the same spatial reference frame axis.

The number of significant digits can also be specified with the “significantFigures” property though it is only applicable when used with a decimal representation (i.e., within the “Quantity” class). This limits the total number of digits that can be included in the number represented whether a scientific notation is used or not.

Example

8.2.19.  AllowedTimes Class

The “AllowedTimes” class is used to express constraints on the value of a data component represented by a “Time” class. The UML class is shown below:

Figure 23 — AllowedTimes Class

This class is almost identical to the “AllowedValues” class and in fact all properties are used in the same way. The only difference with this class is that the “value” and “interval” properties allow the use of time data types as defined in Clause 8.2.1.

The constraints given by this class are expressed along the same time reference frame axis as the value attached to the parent data component.

8.2.20.  Unions of simple component classes

Several useful groups of classes are also defined in this package. These unions can be used as attribute types and they are shown on the following diagram:

Figure 24 — Simple Component Unions

The “AnyScalar” union groups all classes representing scalar components, numerical or not. The “AnyNumerical” union includes all classes corresponding to numerical scalar representations. The “AnyRange” union regroups all range components.

8.3.1.  DataRecord Class

The “DataRecord” class is modeled on the definition of ‘Record’ from ISO 11404. In this definition, a record is a composite data type composed of one to many fields, each of which having its own name and type definition. Thus it defines some logical collection of components of any type that are grouped for a given purpose.

As shown on the following figure, the “DataRecord” class in SWE Common is based on a full composite design pattern, such that each one of its “field” can be of a different type, including simple component types as well as any aggregate component type.

Figure 26 — DataRecord Class

The “DataRecord” class derives from the “AbstractDataComponent” class, which is necessary to enable the full composite pattern in which a “DataRecord” can be used to group scalar components, but also other records, arrays and choices recursively.

Fields

Each “field” attribute can take an instance of any concrete sub-class of “AbstractDataComponent”, which is the superset of all data component types defined in this standard. The name of each field must be unique within a given “DataRecord” instance so that it can be used as a key to uniquely identify and/or index each one of the record components.

Example

8.3.2.  Vector Class

The “Vector” class is used to express multi-dimensional quantities with respect to a well defined referenced frame (usually a spatial or spatio-temporal reference frame). This is done by projecting the quantity on one or several axes that define the reference frame and assigning a value to each of the axis projections.

The “Vector” class is a special case of a record that takes a collection of coordinates that are restricted to a numerical representation. Coordinates of a “Vector” can thus only be of type “Quantity,” “Count,” or “Time.” Its UML diagram is shown below:

Figure 27 — Vector Class

Coordinates

Just like record fields, vector coordinates must have a unique name:

Reference Frame

This class contains a mandatory “referenceFrame” attribute that identifies the frame of reference with respect to which the vector quantity is expressed. The coordinates of the vector correspond to values projected on the axes of this frame.

The “referenceFrame” attribute is inherited by all components of the “Vector,” so that it shall not be redefined for each coordinate. However the “axisID” attribute shall be specified for each coordinate, in order to unambiguously indicate what axis of the reference frame it corresponds to.

Local Frame

The optional “localFrame” attribute allows identifying the frame of interest, that is to say the frame we are positioning with the coordinate values associated to this component (by opposition to the “referenceFrame” that specifies the frame with respect to which the values of the coordinates are expressed).

Correctly identifying the local and reference frame is an important feature that allows chaining several relative positions, something that is essential to correctly compute accurate position of sensor data (especially remote sensing data).

Example

Example 1

A position vector (or location vector) is used to locate the origin of a frame of interest (the local frame) relative to the origin of a frame of reference (the reference frame) through a linear translation. It is composed of three coordinates of type “Quantity”, each with a definition indicating that the coordinate represents a length expressed in the desired unit. The definition of the “Vector” itself should also indicate that it is a “location vector.”

 

Example 2

An orientation vector is used to indicate the rotation of the axes of a frame of interest (the local frame) relative to a frame of reference (the reference frame). It is composed of three coordinates of type “Quantity” with a definition indicating an angular property. The “Vector” definition should indicate the type of orientation vector such as “Euler Angles” or “Quaternion”. Depending on the exact definition, the order in which the coordinates are listed in the vector may matter.

8.4.1.  DataChoice Class

The “DataChoice” class (also called Disjoint Union) is modeled on the definition of ‘Choice’ from ISO 11404. It is a composite component that allows for a choice of child components. By opposition to records that carry all their fields simultaneously, only one item at a time can be present in the data when wrapped in a “DataChoice”. The following diagram shows the “DataChoice” class as implemented in the SWE Common Data Model:

Figure 28 — DataChoice Class

This class implements a full composite pattern, so that each “item” can be any data component, including simple and aggregate types.

The “choiceValue” attribute is used to represent the token value that would be present in the data stream and that indicates the actual choice selection before the corresponding data can be given (i.e., knowing what choice item was selected ahead of time is necessary for proper decoding of encoded data streams).

Items

Each “item” attribute can take an instance of any concrete sub-class of “AbstractDataComponent,” which is the superset of all data component types defined in this standard. The name of each item shall be unique within a given “DataChoice” instance so that it can be used as a key to uniquely identify and/or index each one of the choice components.

The “DataChoice” component is used to describe a data structure (or a part of the structure) that can alternatively contain different types of objects. It can also be used to define the input of a service or process that allows a choice of structures as its input.

Example

8.5.1.  DataArray Class

The “DataArray” class is modeled on the corresponding definition of ISO 11404. This definition states that an array is a collection of elements of the same type (as opposed to a record where each field can have a different type), with a defined size. This class is shown on the following UML diagram:

Figure 30 — DataArray Class

This class implements a full composite pattern, so that the “elementType” can be any data component, including simple and aggregate types. It can be used to group identical scalar components as well as records, choices and arrays in a recursive manner.

Element Count

The “elementCount” attribute is used to indicate the size of the array, that is to say the number of elements of the given type in the array. Note that each element is not necessarily scalar but can be a record, another array, etc.

Element Type

The content of the “elementType” attribute defines the exact structure of each element in the array. The data component used and all of its children shall not include any inline values, as these will be block encoded in the “values” attribute of the parent “DataArray.”

However, the “DataArray” class itself, like any other data component can be used either as a data descriptor or as a data container. To use it as a data descriptor the “encoding” and “values” attributes are not set. To use it as a data container, these attributes are both set as described below.

Encoding and Values

The “encoding” and “values” fields are there to provide array data as an efficient block which can be encoded in several ways. The different encoding methods are described in Clauses 8.7 and 8.8. The “encoding” field shall have a value if the “values” field is present, and the data shall be encoded using the specified encoding.

The choice of simple encodings (defined in the “Simple Encodings” package) allows encoding data as JSON or as text using a delimiter separated values (DSV, a variant of CSV) format. The “Advanced Encodings” package defines binary encodings that can be used to efficiently package large datasets.

Nested Components

By combining instances of “DataArray”, “DataRecord” and scalar components, one can obtain the complex data structures that are necessary to fully describe any kind of sensor data. In particular, the possibility of nesting a “DataRecord” or “Vector” inside a “DataArray” allows defining structures such as trajectories, profiles, multi-band images, etc.

Example

Example 1

The “DataArray” class can be used to describe a simple 1D array of measurements such as radiance values obtained using a 12000 cells (1 row) CCD strip for instance. This can be done by using the “Quantity” class as the element type. In such a case, describing the dataset as a “DataRecord” would be a very repetitive task given the number of elements (12000 in this case!).

 

Example 2

The “DataArray” class can be used as a descriptor for a trajectory dataset by using a vector of [latitude, longitude] coordinates as its element type. Note that this can also be considered as a 1D coverage in a 2D CRS.

 

Multi-dimensional Arrays

Since the “DataArray” class alone can only represent 1-dimensional arrays, the construction of multi-dimensional arrays is done by nesting “DataArray” objects inside each other.

Example

Example

The structure of panchromatic imagery data can be described with two nested arrays, which sizes indicate the two dimensions of the image. A “Quantity” is used as the element type of the nested array in order to indicate that the repeated element of the 2D array is of type infrared radiance with a given unit.

 

In this example, the image is described as an array of rows, each row being an array of samples. It is also possible to describe an image as an array of columns by reversing the two dimensions. Note that this would change the order in which the data values would appear in a stream (by rows vs. by columns).

Array Size

One powerful feature of the “DataArray” model is that it allows for the element count to be either fixed or variable, thus allowing the description of data streams with variable number of repetitive elements as is often the case with many kinds of sensor.

In a fixed size array, the number of elements can be provided in the descriptor as an instance of the “Count” class with an inline value. This value is only present in the data description and not in the encoded block of array values. The definition of the “Count” instance is not required.

In a variable size array, the “elementCount” attribute either contains an instance of the “Count” class with no value or references an instance of a “Count” class in a parent or sibling data component. The value giving the actual array size is then included in the stream, before the array values themselves, so that the block can be properly decoded. One obvious implementation constraint is that the value representing the array size must be received before the array values. This is detailed further in the JSON implementation section.

Example

Array Semantics

As with any other data component, the “name” and “description” can be used to better describe the array and more importantly the “definition” attribute can be used to formally indicate the semantics behind the array.

Example

The value of the “definition” attribute of the “Count” instance used as the “elementCount” is also especially important, since it is used to define the meaning of the array dimension. Thanks to this, it is possible to tag the dimension of an array as spatial, temporal, spectral, or any other kind. However it is not mandatory as it is on other simple components.

Example

This extra information can be used by software to make decisions (or at least ask the user by providing him this information) about how to represent or even interpolate the data.

8.5.2.  Matrix Class

The “Matrix” extends the “DataArray” class by providing a reference frame within which the matrix elements are expressed and a local frame of interest. The UML diagram of this class is shown below:

Figure 31 — Matrix Class

The “Matrix” class is usually used to represent a position matrix or a tensor quantity of second or higher order. Each matrix element is expressed along the axis of a well defined reference frame.

Element Type

The “elementType” attribute inherited from the “DataArray” class can only take a nested “Matrix” instance or a scalar numerical component. Nested matrix objects allow the full description of N-dimensional matrices.

Reference Frame

The “referenceFrame” attribute is used in the same way as with the “Vector” class to specify the frame of reference with respect to which the matrix element values are expressed. It is inherited by all child components.

Local Frame

The “localFrame” attribute is used to identify the frame of interest, that is to say the frame whose orientation or position is given with the matrix in the case where it is a position matrix. If the matrix does not specify position, “localFrame” should not be used. Whether an instance of the “Matrix” class represents a position matrix or not should be disambiguated by setting the value of its “definition” attribute.

Example

8.5.3.  DataStream Class

The “DataStream” class has a structure similar than the “DataArray” class but is not a data component (i.e., it does not derive from “AbstractDataComponent”) and thus cannot be used as a child of other aggregate components. Below is its UML diagram:

Figure 32 — DataStream Class

This class should be used as the wrapper object to define a complete data stream. It defines a data stream as containing a list of elements with an arbitrary complex structure. An important feature is that the data stream can be open ended (i.e., the number of elements is not known in advance) and is thus designed to support real time streaming of data.

Element Count

The “elementCount” attribute is optional and can be used to indicate the number of elements in the stream if it is known. This is done by instantiating an instance of the “Count” class whose “value” attribute would be set to the number of elements.

Element Type

The “elementType” attribute is used to define the structure of each element in the stream. The data component used as the element type and all of its children shall be used solely as data descriptors, meaning that they shall not include any inline values. These values will instead be block encoded in the “values” attribute of the parent “DataStream”.

Encoding and Values

The “encoding” and “values” fields are there to provide the stream values as an efficient block which can be encoded in several ways. The same encoding methods as for the “DataArray” class are available and are described in Clauses 8.7 and 8.8. The “values” attribute is optional as the DataStream class can be used as a simple descriptor.

8.6.1.  Geometry Class

The “Geometry” class extends the “AbstractDataComponent” class with a value of type geometry and a constraint that can be used to limit the types of allowed geometries. This class is shown on the following UML diagram:

Figure 33 — Geometry Class

Coordinate Reference System

The “crs” attribute provides the URI of the coordinate reference system with respect to which the geometry coordinates are expressed. The unit of the coordinates is also provided by the coordinate reference system.

Constraints

The “constraint” attribute is used to restrict the possible geometries that can be provided using this component when it is used as a descriptor. The constraint is provided using the “AllowedGeometries” class that includes a list of allowed geometry types.

Value

The value of this component must be a geometry instance, whether it’s provided inline using the “value” attribute, or as part of a datastream.

8.7.1.  JSONEncoding Class

The “JSONEncoding” class defines a method allowing encoding arbitrarily complex data as JSON. The class used to specify this encoding method is shown in Figure 34.

The “recordsAsArrays” attribute specifies whether “DataRecord” values are encoded as JSON objects or JSON arrays. The “vectorsAsArrays” attribute specifies whether “Vector” values are encoded as JSON objects or JSON arrays. Both attributes are optional and default to false, meaning “DataRecord” and “Vector” values are per default encoded as JSON objects. The detailed rules are given in the implementation in Clause 10.2.

8.7.2.  TextEncoding Class

The “TextEncoding” class defines a method allowing encoding arbitrarily complex data using a text based delimiter separated values (DSV) format. The class used to specify this encoding method is shown below:

Figure 35 — TextEncoding Class

The “tokenSeparator” attribute specifies the characters to use for separating each scalar value from one another. Scalar values appear sequentially in the stream alternatively with the token separator characters, in an order unambiguously defined by the data component structure. The detailed rules are given in the implementation in Clause 10.3.

The “blockSeparator” attribute specifies characters used to mark the end of a “block”, corresponding to the complete structure defined by the data component tree (in a “DataArray”, “Matrix” or “DataStream” one block corresponds to one element, that is to say the structure defined by the “elementType” property). Stream or array data can then be composed of several blocks of the same type separated by block separator characters.

The “decimalSeparator” attribute specifies the character used as the decimal point in decimal number. This attribute is optional and the default is a period (‘.’).

Example

The “collapseWhiteSpaces” attribute is a boolean flag used to specify if extra white spaces (including line feeds, tabs, spaces and carriage returns) surrounding the token and block separators should be ignored (skipped) when processing the stream.

This type of encoding is used when compactness is important but balanced by a desire of human readability. This type of encoding is easily readable (for debugging or manual usage) as well as easily imported in various spreadsheet, charting or scientific software.

The main drawback of such an encoding is the impossibility of locating an error in the stream with certitude. Secondly, if only one expected value is missing, the whole block is usually lost since the parser cannot resynchronize correctly before the next block separator. This last issue can however be solved by transmitting this type of encoded stream using error resilient protocols when needed.

8.8.1.  BinaryEncoding Class

The “BinaryEncoding” class defines a method that allows encoding complex structured data using primitive data types encoded directly at the byte level, in the same way that they are usually represented in memory.

The binary encoding method can lead to very compact streams that can be optimized for efficient parsing and fast random access. However this comes with the lack of human readability of the data and sometimes lack of compatibility with other software (i.e., software that is not SWE Common enabled).

More information is needed to fully define a binary encoding, so the model is more complex than the other encodings. It is shown below:

Figure 36 — BinaryEncoding Class

The main class “BinaryEncoding” specifies overall characteristics of the encoded byte stream such as the byte order (big endian or little endian) and the byte encoding (raw or base64). The two corresponding attributes, respectively “byteOrder” and “byteEncoding” are mandatory. Base64 encoding is usually chosen to insert binary content within a JSON or XML document.

The “byteLength” attribute is optional and can be used to specify the overall length of the encoded data as a total number of bytes. This should be indicated whenever possible if the data size is known in advance as it can be useful for efficient memory allocation.

The “BinaryEncoding” class also has several “member” attributes that contain detailed information about parts of the data stream. This attribute can take a choice of instance of two classes: “Component” or “Block.”

The “Component” class is used to specify binary encoding details of a given scalar component in the stream. The following information can be provided for each scalar field:

The “Block” class is used to specify binary encoding details of a given aggregate component representing a block of values in the data stream. This is used either to specify padding before and/or after a block of data or to enable compression or encryption of all or part of a dataset.

This standard does not define any concrete encryption and compression methods, so that software implementations of this requirement class are not required to support any value in the “encryption” and “compression” attributes of the “Component” and “Block” classes. Extensions of this standard that define binary encryption and compression methods shall describe how the encrypted or compressed data is inserted in the SWE Common data stream.

9.1.1.  General JSON Principles

The following rules were used when generating the JSON schemas:

9.1.2.  Special Numerical Values

JSON does not define special decimal values for ‘Not a Number’, positive infinity and negative infinity. It is thus necessary to encode them as strings.

9.1.3.  Abstract Base Classes

The three abstract base classes defined in the UML models are implemented by the following JSON schemas:

9.1.4.  Unit Reference Object

The “UnitReference” object is the partial JSON schema implementation of the “UnitOfMeasure” UML class used in Clause 8.2.8 and Clause 8.2.13, and the “UomTime” UML class used in Clause 8.2.9 and Clause 8.2.14, as defining the model for “UnitOfMeasure” and “UomTime” are out of scope for SWE Common. SWE Common only references implementations of “UnitOfMeasure”, like for instance the ones provided by UCUM.

The schema for this class is provided in basicTypes.json (see #definitions/UnitReference). Further details on the usage of “UnitReference” object can be found in Clause 9.1.9 and Clause 9.1.10.

Examples of references to a unit of measure are provided below:

{ 
    "code": "W.m-2.Sr-1.um-1" 
}

Listing

{ 
    "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
}

Listing

{
    "symbol": "°C",
    "code": "Cel",
    "href": "https://qudt.org/vocab/unit/DEG_C"
}

Listing

9.1.5.  Boolean Object

The “Boolean” object is the JSON schema implementation of the “Boolean” UML class defined in Clause 8.2.4. The schema for this class is provided in Boolean.json.

The following snippet shows an example boolean component with an inline value:

{
  "type": "Boolean",
  "definition": "http://sweet.jpl.nasa.gov/2.0/physDynamics.owl#Motion",
  "label": "Motion Detected",
  "description": "True when motion was detected in the room",
  "value": true
}

Listing

The next snippet is an example of boolean component used as data descriptor, hence with no value:

{
  "type": "Boolean",
  "definition": "http://mmisw.org/ont/q2o/test/timeContinuityTest",
  "label": "Time Continuity Test",
  "description": "Set to true to enable time continuity test"
}

Listing

9.1.6.  Text Object

The “Text” object is the JSON schema implementation of the “Text” UML class defined in Clause 8.2.5. The schema for this class is provided in Text.json.

Constraints on a “Text” representation are expressed using the AllowedTokens Object.

The following snippets show how the “Text” component can be used to define human readable text fields, as well as any other alpha-numerical properties:

{
  "type": "Text",
  "definition": "http://sensorml.com/ont/swe/property/Manufacturer",
  "label": "Manufacturer",
  "value": "Ocean Devices, Inc."
}

Listing

{
  "type": "Text",
  "definition": "http://sensorml.com/ont/x-swe/property/VehicleRegistrationNumber",
  "label": "License Plate",
  "value": "45ER-EJK-235"
}

Listing

Constraints can also be used — typically when the component is used as a descriptor — to limit the possible text values, either by enumeration or a regular expression pattern:

{
  "type": "Text",
  "definition": "http://sensorml.com/ont/x-swe/property/VehicleRegistrationNumber",
  "label": "License Plate",
  "constraint": {
    "pattern": "^[0-9][A-Z]{4}-[A-Z]{3}-[0-9]{3}$"
  }
}

Listing

9.1.7.  Category Object

The “Category” object is the JSON schema implementation of the “Category” UML class defined in Clause 8.2.6. The schema for this class is provided in Category.json.

Constraints on a “Category” representation are expressed using the AllowedTokens Object.

The following examples illustrate how the “Category” component is used to define various fields with categorical representations. The categorical scale is defined either via a code space, an enumeration constraint, or both (in which case the enumeration constraint defines a subset of possible values from a code space):

{
  "type": "Category",
  "definition": "http://sweet.jpl.nasa.gov/2.0/timeGeologic.owl#GeologicTime",
  "label": "Geological Period",
  "description": "Name of the geological period according to the nomenclature of the International Commission on Stratigraphy",
  "codeSpace": "http://sweet.jpl.nasa.gov/2.0/timeGeologic.owl#Period",
  "value": "Jurassic"
}

Listing

{
  "type": "Category",
  "definition": "http://sweet.jpl.nasa.gov/2.0/biol.owl#Species",
  "label": "Bird Species",
  "description": "Bird species according to the classification of the World Bird Database",
  "codeSpace": "http://www.birdlife.org/datazone/species/index.html"
}

Listing

9.1.8.  Count Object

The “Count” object is the JSON schema implementation of the “Count” UML class defined in Clause 8.2.7. The schema for this class is provided in Count.json.

Constraints on a “Count” representation are expressed using the AllowedValues Object.

The following snippet shows a “Count” component used to define the size of a row in a raster dataset:

{
  "type": "Count",
  "definition": "http://www.opengis.net/def/property/OGC/0/NumberOfPixels",
  "label": "Row Size",
  "description": "Number of pixels in each row of the image",
  "value": 1024
}

Listing

9.1.9.  Quantity Object

The “Quantity” object is the JSON schema implementation of the “Quantity” UML class defined in Clause 8.2.8. The schema for this class is provided in Quantity.json.

Constraints on a “Quantity” representation are expressed using the AllowedValues Object.

The unit of measure is defined using either a URI or a code expressed using the Unified Code for Units of Measure (UCUM) standard.

The following snippets show how “Quantity” components are used to define various (observable or controllable) properties with continuous decimal representations:

{
  "type": "Quantity",
  "definition": "http://qudt.org/vocab/quantitykind/Temperature",
  "label": "Outside Temperature",
  "description": "Outside temperature taken at the top of the antenna",
  "uom": { "code": "Cel" },
  "value": 21.5
}

Listing

{
  "type": "Quantity",
  "definition": "http://sensorml.com/ont/swe/property/SpectralRadiance",
  "label": "Radiance",
  "description": "Radiance measured on band1",
  "uom": { "code": "W.m-2.Sr-1.um-1" },
  "value": 2.83e-2
}

Listing

{
  "type": "Quantity",
  "definition": "http://sensorml.com/ont/swe/property/HeightAboveMSL",
  "referenceFrame": "http://www.opengis.net/def/crs/EPSG/0/5714",
  "axisID": "H",
  "label": "MSL Height",
  "description": "Height above mean sea level",
  "uom": { "code": "m" }
}

Listing

{
  "type": "Quantity",
  "definition": "https://qudt.org/vocab/quantitykind/CostPerUnitEnergy",
  "label": "Electricity Cost",
  "description": "Average cost of electricity in Europe",
  "uom": {
    "href": "https://qudt.org/vocab/unit/EUR-PER-KiloW-HR"
  }
}

Listing

9.1.10.  Time Object

The “Time” object is the JSON schema implementation of the “Time” UML class defined in Clause 8.2.9. The schema for this class is provided in Time.json.

Constraints on a “Time” representation are expressed using the AllowedTimes Object.

The unit of measure is defined using either a URI or a code expressed using the Unified Code for Units of Measure (UCUM) standard. When the temporal property is provided in the ISO 8601:2019 format, this is indicated by using a specific URI.

The following snippets show how “Time” components are used to define various temporal properties, with different time scales:

ISO8601 formatted time stamp based on the UTC time standard:

{
  "type": "Time",
  "definition": "http://www.opengis.net/def/property/OGC-EO/0/MissionStartTime",
  "referenceFrame": "http://www.opengis.net/def/trs/BIPM/0/UTC",
  "localFrame": "urn:org:systems:001#MISSION-START-TIME",
  "label": "Flight Time",
  "description": "Time at take-off in UTC",
  "uom": {
    "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
  },
  "value": "2009-01-26T10:21:45+01:00"
}

Listing

ISO8601 formatted time stamp based on the GPS time standard:

{
  "type": "Time",
  "definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
  "referenceFrame": "http://www.opengis.net/def/trs/USNO/0/GPS",
  "label": "Sampling Time",
  "description": "Time at which the measurement was made",
  "uom": {
    "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
  },
  "value": "2009-11-05T16:29:26Z"
}

Listing

Time stamp in seconds past the Unix epoch:

{
  "type": "Time",
  "definition": "http://www.opengis.net/def/property/OGC/0/RunTime",
  "referenceTime": "1970-01-01T00:00:00Z",
  "label": "Model Run Time",
  "description": "Run time of the model expressed as a Unix time",
  "uom": {"code": "s" },
  "value": 1257415633
}

Listing

Time stamp in seconds past a custom time reference called MISSION_START_TIME:

{
  "type": "Time",
  "definition": "http://www.opengis.net/def/property/OGC-EO/0/ScanStartTime",
  "referenceFrame": "urn:org:systems:001#MISSION-START-TIME",
  "localFrame": "urn:org:systems:001#SCAN-START-TIME",
  "label": "Scanline Time",
  "description": "Acquisition time of the scan line",
  "uom": { "code": "s" }
}

Listing

9.1.11.  CategoryRange Object

The “CategoryRange” object is the JSON schema implementation of the “CategoryRange” UML class defined in Clause 8.2.11. The schema for this class is provided in CategoryRange.json.

“CategoryRange” objects share most properties with “Category” object, as shown on the following snippet:

{
  "type": "CategoryRange",
  "definition": "http://sweet.jpl.nasa.gov/2.0/timeGeologic.owl#GeologicTime",
  "label": "Approximate Dating",
  "description": "Approximate geological dating expressed as a range of geological eras",
  "codeSpace": "http://sweet.jpl.nasa.gov/2.0/timeGeologic.owl#Era",
  "value": ["Paleozoic", "Mesozoic"]
}

Listing

9.1.12.  CountRange Object

The “CountRange” object is the JSON schema implementation of the “CountRange” UML class defined in Clause 8.2.12. The schema for this class is provided in CountRange.json.

“CountRange” objects share most properties with “Count” object, as shown on the following snippet:

{
  "type": "CountRange",
  "definition": "http://www.opengis.net/def/property/OGC/0/ArrayIndex",
  "label": "Index Range",
  "value": [0, 3000]
}

Listing

9.1.13.  QuantityRange Object

The “QuantityRange” object is the JSON schema implementation of the “QuantityRange” UML class defined in Clause 8.2.13. The schema for this class is provided in QuantityRange.json.

“QuantityRange” objects share most properties with the “Quantity” object, as shown on the following snippet:

{
  "type": "QuantityRange",
  "definition": "http://mmisw.org/ont/mmi/device/OperationalRange",
  "label": "Operational Range",
  "description": "Operational temperature range of the cryogenic thermometer",
  "uom": { "code": "K" },
  "value": [10, 300]
}

Listing

9.1.14.  TimeRange Object

The “TimeRange” object is the JSON schema implementation of the “TimeRange” UML class defined in Clause 8.2.14. The schema for this class is provided in TimeRange.json.

“TimeRange” objects share most properties with the “Time” object, as shown on the following snippet:

{
  "type": "TimeRange",
  "definition": "http://www.opengis.net/def/property/EO/0/SurveyPeriod",
  "referenceFrame": "http://www.opengis.net/def/trs/BIPM/0/UTC",
  "label": "Survey Period",
  "uom": {
    "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
  },
  "value": ["2008-01-05T11:02:54Z", "2009-11-05T16:29:26Z"]
}

Listing

9.1.15.  NilValues Object

The “NilValues” object is the JSON schema implementation of the “NilValues” UML class defined in Clause 8.2.16. Schema patterns for this class are provided in basicTypes.json. Several sub-patterns are defined for the decimal, integer and text cases.

Examples of NIL values definitions are provided below, in the case of numerical, countable and textual representations:

{
  "type": "Quantity",
  "definition": "http://sweet.jpl.nasa.gov/2.0/physRadiation.owl#IonizingRadiation",
  "label": "Radiation Dose",
  "description": "Radiation dose measured by Gamma detector",
  "uom": { "code": "uR" },
  "nilValues": [
    { "reason": "http://www.opengis.net/def/nil/OGC/0/BelowDetectionRange", "value": "-Infinity" },
    { "reason": "http://www.opengis.net/def/nil/OGC/0/AboveDetectionRange", "value": "Infinity" }
  ]
}

Listing

{
  "type": "Count",
  "definition": "http://sweet.jpl.nasa.gov/2.0/physRadiation.owl#Radiance",
  "label": "Band 1",
  "nilValues": [
    { "reason": "http://www.opengis.net/def/nil/OGC/0/BelowDetectionRange", "value": 0 },
    { "reason": "http://www.opengis.net/def/nil/OGC/0/AboveDetectionRange", "value": 255 }
  ]
}

Listing

{
  "type": "Text",
  "definition": "http://sensorml.com/ont/x-swe/property/VehicleRegistrationNumber",
  "label": "License Plate",
  "nilValues": [
    { "reason": "http://www.opengis.net/def/nil/OGC/0/Missing", "value": "Missing" },
    { "reason": "http://www.opengis.net/def/nil/OGC/0/Unknown", "value": "Unknown" }
  ]
}

Listing

9.1.16.  AllowedTokens Object

The “AllowedTokens” object is the JSON schema implementation of the “AllowedTokens” UML class defined in Clause 8.2.17. The schema for this class is provided in basicTypes.json (see #definitions/AllowedTokens).

Examples of constraints for textual or categorical properties are provided below:

{
  "type": "Text",
  "definition": "http://sensorml.com/ont/swe/property/ModelNumber",
  "label": "Model Number",
  "constraint": {
    "pattern": "^[0-9][A-Z]{3}[0-9]{2}S1$"
  }
}

Listing

{
  "type": "Category",
  "definition": "http://www.opengis.net/def/property/OGC/0/SensorStatus",
  "label": "Sensor Status",
  "description": "Current connection status of the sensor",
  "constraint": {
    "values": [ "Off", "Stand-by", "Ready", "Busy" ]
  }
}

Listing

9.1.17.  AllowedValues Object

The “AllowedValues” object is the JSON schema implementation of the “AllowedValues” UML class defined in Clause 8.2.18. The schema for this class is provided in basicTypes.json (see #definitions/AllowedValues).

Examples of constraints for various numerical properties are provided below:

{
  "type": "Quantity",
  "definition": "http://qudt.org/vocab/quantitykind/Angle",
  "label": "Planar Angle",
  "uom": { "code": "deg" },
  "constraint": {
    "intervals": [[-180, 180]]
  }
}

Listing

{
  "type": "Count",
  "definition": "http://www.opengis.net/def/property/OGC/0/NumberOfPixels",
  "label": "Image Width",
  "constraint": {
    "values": [256, 512, 1024]
  }
}

Listing

{
  "type": "Quantity",
  "definition": "http://sensorml.com/ont/swe/property/GeodeticLatitude",
  "label": "Latitude",
  "uom": { "code": "deg" },
  "constraint": {
    "intervals": [[-90, 90]],
    "significantFigures": 6
  }
}

Listing

Numerical constraints can also be unbounded:

{
  "type": "Quantity",
  "definition": "http://qudt.org/vocab/quantitykind/RadialDistance",
  "label": "Radial Distance",
  "description": "Radial distance is always positive",
  "uom": { "code": "m" },
  "constraint": {
    "intervals": [[0, "+Infinity"]]
  }
}

Listing

9.1.18.  AllowedTimes Object

The “AllowedTimes” object is the JSON schema implementation of the “AllowedTimes” UML class defined in Clause 8.2.19. The schema for this class is provided in basicTypes.json (see #definitions/AllowedTimes).

Examples of constraints for various temporal properties, expressed as ISO-8601 or decimal values, are provided below:

{
  "type": "Time",
  "definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
  "referenceFrame": "http://www.opengis.net/def/trs/USNO/0/GPS",
  "label": "Acquisition Time",
  "uom": {
    "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
  },
  "constraint": {
    "intervals": [["2009-01-01T00:00:00Z", "+Infinity"]]
  }
}

Listing

{
  "type": "Time",
  "definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
  "referenceFrame": "urn:org:systems:001#SCAN-START-TIME",
  "label": "Lidar Pulse Time",
  "description": "Time stamp of LiDAR pulse relative to start of scan",
  "uom": { "code": "ms" },
  "constraint": {
    "intervals": [[0, 1e6]]
  }
}

Listing

9.2.1.  DataRecord Object

The “DataRecord” object is the JSON schema implementation of the “DataRecord” UML class defined in Clause 8.3.1. The schema for this class is provided in DataRecord.json.

The example below describes a record composed of weather data fields. In this case the “DataRecord” element is used as a descriptor for records of data that are provided as part of a datastream:

{
  "type": "DataRecord",
  "label": "Weather Data Record",
  "fields": [
    {
      "name": "time",
      "type": "Time",
      "definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
      "referenceFrame": "http://www.opengis.net/def/trs/BIPM/0/UTC",
      "label": "Sampling Time",
      "uom": {
        "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
      }
    },
    {
      "name": "temperature",
      "type": "Quantity",
      "definition": "http://mmisw.org/ont/cf/parameter/air_temperature",
      "label": "Air Temperature",
      "uom": { "code": "Cel" }
    },
    {
      "name": "pressure",
      "type": "Quantity",
      "definition": "http://mmisw.org/ont/cf/parameter/air_pressure_at_mean_sea_level",
      "label": "Air Pressure",
      "uom": { "code": "mbar" }
    },
    {
      "name": "windSpeed",
      "type": "Quantity",
      "definition": "http://mmisw.org/ont/cf/parameter/wind_speed",
      "label": "Wind Speed",
      "uom": { "code": "km/h" }
    },
    {
      "name": "windDirection",
      "type": "Quantity",
      "definition": "http://mmisw.org/ont/cf/parameter/wind_to_direction",
      "label": "Wind Direction",
      "uom": { "code": "deg" }
    }
  ]
}

Listing

{
  "type": "DataRecord",
  "definition": "urn:x-ogc:def:property:CSM::RadialDistortionCoefficients",
  "label": "Radial Distortion Coefficients",
  "fields": [
    {
      "name": "k1",
      "type": "Quantity",
      "definition": "urn:x-ogc:def:property:CSM::DISTOR_RAD1",
      "label": "Coef k1",
      "uom": { "code": "mm-2" },
      "value": 1.92709e-5
    },
    {
      "name": "k2",
      "type": "Quantity",
      "definition": "urn:x-ogc:def:property:CSM::DISTOR_RAD2",
      "label": "Coef k2",
      "uom": { "code": "mm-2" },
      "value": -5.14206e-10
    },
    {
      "name": "k3",
      "type": "Quantity",
      "definition": "urn:x-ogc:def:property:CSM::DISTOR_RAD3",
      "label": "Coef k3",
      "uom": { "code": "mm-2" },
      "value": -3.33356e-12
    }
  ]
}

Listing

9.2.2.  Vector Object

The “Vector” object is the JSON schema implementation of the “Vector” UML class defined in Clause 8.3.2. The schema for this class is provided in Vector.json.

{
  "type": "Vector",
  "definition": "http://www.opengis.net/def/property/OGC/0/PlatformLocation",
  "referenceFrame": "http://www.opengis.net/def/crs/EPSG/0/4326",
  "label": "Platform Location",
  "coordinates": [
    {
      "name": "lat",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/GeodeticLatitude",
      "label": "Latitude",
      "axisID": "Lat",
      "uom": { "code": "deg" },
      "value": 45.36
    },
    {
      "name": "lon",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/Longitude",
      "label": "Longitude",
      "axisID": "Lon",
      "uom": { "code": "deg" },
      "value": 5.2
    }
  ]
}

Listing

{
  "type": "Vector",
  "definition": "http://qudt.org/vocab/quantitykind/LinearVelocity",
  "referenceFrame": "http://www.opengis.net/def/crs/OGC/0/ECI_J2000",
  "label": "Platform Velocity",
  "coordinates": [
    {
      "name": "vx",
      "type": "Quantity",
      "definition": "http://qudt.org/vocab/quantitykind/Speed",
      "label": "Velocity X",
      "uom": { "code": "m/s" }
    },
    {
      "name": "vy",
      "type": "Quantity",
      "definition": "http://qudt.org/vocab/quantitykind/Speed",
      "label": "Velocity Y",
      "uom": { "code": "m/s" }
    },
    {
      "name": "vz",
      "type": "Quantity",
      "definition": "http://qudt.org/vocab/quantitykind/Speed",
      "label": "Velocity Z",
      "uom": { "code": "m/s" }
    }
  ]
}

Listing

{
  "type": "Vector",
  "definition": "http://sensorml.com/ont/swe/property/RotationQuaternion",
  "referenceFrame": "http://www.opengis.net/def/crs/OGC/0/ECI_J2000",
  "localFrame": "urn:org:systems:001#PLATFORM_FRAME",
  "label": "Platform Orientation",
  "coordinates": [
    {
      "name": "qx",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/Coordinate",
      "label": "QX",
      "uom": { "code": "1" }
    },
    {
      "name": "qy",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/Coordinate",
      "label": "QY",
      "uom": { "code": "1" }
    },
    {
      "name": "qz",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/Coordinate",
      "label": "QZ",
      "uom": { "code": "1" }
    },
    {
      "name": "qw",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/Coordinate",
      "label": "QW",
      "uom": { "code": "1" }
    }
  ]
}

Listing

9.3.1.  DataChoice Object

The “DataChoice” object is the JSON schema implementation of the “DataChoice” UML class defined in Clause 8.4.1. The schema for this class is provided in DataChoice.json.

{
  "type": "DataChoice",
  "label": "Weather Data Message",
  "items": [
    {
      "name": "TEMP",
      "type": "DataRecord",
      "label": "Temperature Measurement",
      "fields": [
        {
          "name": "time",
          "type": "Time",
          "definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
          "referenceFrame": "http://www.opengis.net/def/trs/BIPM/0/UTC",
          "label": "Sampling Time",
          "uom": {
            "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
          }
        },
        {
          "name": "temp",
          "type": "Quantity",
          "definition": "http://mmisw.org/ont/cf/parameter/air_temperature",
          "label": "Air Temperature",
          "uom": { "code": "Cel" }
        }
      ]
    },
    {
      "name": "PRESS",
      "type": "DataRecord",
      "label": "Pressure Measurement",
      "fields": [
        {
          "name": "time",
          "type": "Time",
          "definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
          "referenceFrame": "http://www.opengis.net/def/trs/BIPM/0/UTC",
          "label": "Sampling Time",
          "uom": {
            "href": "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"
          }
        },
        {
          "name": "press",
          "type": "Quantity",
          "definition": "http://mmisw.org/ont/cf/parameter/air_pressure_at_mean_sea_level",
          "label": "Air Pressure",
          "uom": { "code": "HPa" }
        }
      ]
    }
  ]
}

Listing

9.4.1.  DataArray Object

The “DataArray” element is the JSON schema implementation of the “DataArray” UML class defined in Clause 8.5.1. The schema for this class is provided in DataArray.json.

{
  "type": "DataArray",
  "label": "Calibration Table",
  "elementType": {
    "name": "point",
    "type": "DataRecord",
    "label": "Data Point",
    "fields": [
      {
        "name": "t",
        "type": "Quantity",
        "definition": "https://qudt.org/vocab/quantitykind/Temperature",
        "label": "Temperature",
        "uom": { "code": "Cel" }
      },
      {
        "name": "r",
        "type": "Quantity",
        "definition": "https://qudt.org/vocab/quantitykind/Resistance",
        "label": "Resistance",
        "uom": { "code": "KOhm" }
      }
    ]
  },
  "values": [
    {"t": 12, "r": 3.03},
    {"t": 30.1, "r": 1.68},
    {"t": 40.0, "r": 1.16},
    {"t": 50.1, "r": 0.85},
    {"t": 59.8, "r": 0.62}
  ]
}

Listing

When provided inline, “DataArray” values are encoded using the method defined in Clause 9.4.4.

The following example shows how to define a 1D variable size array whose data is provided separately.

{
  "type": "DataArray",
  "definition": "http://sensorml.com/ont/swe/property/Trajectory",
  "label": "Mobile Trajectory",
  "elementCount": {
    "definition": "http://www.opengis.net/def/property/OGC/0/NumberOfPoints",
    "label": "Implicit Size"
  },
  "elementType": {
    "name": "point",
    "type": "Vector",
    "definition": "http://www.opengis.net/def/property/OGC/0/PlatformLocation",
    "referenceFrame": "http://www.opengis.net/def/crs/EPSG/0/4326",
    "label": "Location Point",
    "coordinates": [
      {
        "name": "lat",
        "type": "Quantity",
        "definition": "http://sensorml.com/ont/swe/property/GeodeticLatitude",
        "label": "Latitude",
        "axisID": "Lat",
        "uom": { "code": "deg" }
      },
      {
        "name": "lon",
        "type": "Quantity",
        "definition": "http://sensorml.com/ont/swe/property/Longitude",
        "label": "Longitude",
        "axisID": "Lon",
        "uom": { "code": "deg" }
      }
    ]
  }
}

Listing

“DataArray” components can also be nested to form multi-dimensional arrays, as shown in the following example of a 2D array:

{
  "type": "DataArray",
  "definition": "http://sensorml.com/ont/swe/property/RasterImage",
  "label": "Satellite Image",
  "elementCount": {
    "definition": "http://www.opengis.net/def/property/OGC/0/NumberOfRows",
    "value": 3000
  },
  "elementType": {
    "name": "row",
    "type": "DataArray",
    "definition": "http://sensorml.com/ont/swe/property/RasterImage",
    "elementCount": {
      "definition": "http://www.opengis.net/def/property/OGC/0/NumberOfSamples",
      "value": 3000
    },
    "elementType": {
      "name": "pixel",
      "type": "DataRecord",
      "definition": "http://sensorml.com/ont/swe/property/GridCell",
      "fields": [
        {
          "name": "band1",
          "type": "Quantity",
          "definition": "http://qudt.org/vocab/quantitykind/Radiance",
          "label": "Radiance",
          "description": "Radiance measured on band1",
          "uom": { "code": "W.m-2.Sr-1" }
        },
        {
          "name": "band2",
          "type": "Quantity",
          "definition": "http://qudt.org/vocab/quantitykind/Radiance",
          "label": "Radiance",
          "description": "Radiance measured on band2",
          "uom": { "code": "W.m-2.Sr-1" }
        },
        {
          "name": "band3",
          "type": "Quantity",
          "definition": "http://qudt.org/vocab/quantitykind/Radiance",
          "label": "Radiance",
          "description": "Radiance measured on band3",
          "uom": { "code": "W.m-2.Sr-1" }
        }
      ]
    }
  }
}

Listing

9.4.2.  Matrix Object

The “Matrix” object is the JSON schema implementation of the “Matrix” UML class defined in Clause 8.5.2. The schema for this class is provided in Matrix.json.

{
  "type": "Matrix",
  "definition": "http://sensorml.com/ont/swe/property/RotationMatrix",
  "referenceFrame": "http://www.opengis.net/def/crs/OGC/0/ECI_J2000",
  "label": "3D Orientation Matrix",
  "elementType": {
    "name": "row",
    "type": "Matrix",
    "elementType": {
      "name": "coef",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/Coordinate",
      "label": "Matrix Coef",
      "uom": { "code": "1" }
    }
  },
  "values": [
    [0.36,0.48,-0.8],
    [-0.8,0.6,0],
    [0.48,0.64,0.6]
  ]
}

Listing

When provided inline, “Matrix” values are encoded using the method defined in Clause 9.4.4.

9.4.3.  DataStream Object

The “DataStream” object is the JSON schema implementation of the “DataStream” UML class defined in Clause 8.5.3. The schema for this class is provided in DataStream.json.

{
  "type": "DataStream",
  "label": "Aircraft Navigation",
  "elementType": {
    "name": "navData",
    "type": "DataRecord",
    "fields": [
      {
        "type": "Time",
        "definition": "http://www.opengis.net/def/property/OGC/0/SamplingTime",
        "referenceFrame": "http://www.opengis.net/def/trs/USNO/0/GPS",
        "referenceTime": "1970-01-01T00:00:00Z",
        "label": "Sampling Time",
        "uom": { "code": "s" }
      },
      {
        "name": "location",
        "type": "Vector",
        "definition": "http://www.opengis.net/def/property/OGC/0/PlatformLocation",
        "referenceFrame": "http://www.opengis.net/def/crs/EPSG/0/4979",
        "label": "Platform Location",
        "coordinates": [
          {
            "name": "lat",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/GeodeticLatitude",
            "label": "Latitude",
            "axisID": "Lat",
            "uom": { "code": "deg" }
          },
          {
            "name": "lon",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/Longitude",
            "label": "Longitude",
            "axisID": "Lon",
            "uom": { "code": "deg" }
          },
          {
            "name": "alt",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/HeightAboveEllipsoid",
            "label": "Altitude",
            "axisID": "h",
            "uom": { "code": "m" }
          }
        ]
      },
      {
        "name": "attitude",
        "type": "Vector",
        "definition": "http://www.opengis.net/def/property/OGC/0/PlatformOrientation",
        "referenceFrame": "http://www.opengis.net/def/cs/OGC/0/ENU",
        "label": "Platform Attitude",
        "coordinates": [
          {
            "name": "heading",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/TrueHeading",
            "label": "Heading",
            "axisID": "Z",
            "uom": { "code": "deg" }
          },
          {
            "name": "pitch",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/PitchAngle",
            "label": "Pitch",
            "axisID": "X",
            "uom": { "code": "deg" }
          },
          {
            "name": "roll",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/RollAngle",
            "label": "Roll",
            "axisID": "Y",
            "uom": { "code": "deg" }
          }
        ]
      }
    ]
  },
  "encoding": {
    "type": "TextEncoding",
    "tokenSeparator": ",",
    "blockSeparator": "\n",
    "decimalSeparator": "."
  }
}