i. Abstract

The OGC Timeseries Profile of Observations and Measurements is a conceptual model for the representation of observations data as timeseries, with the intent of enabling the exchange of such data sets across information systems. This standard does not define an encoding for the conceptual model; however there is an accompanying OGC Standard which defines an XML encoding (OGC TimeseriesML 1.0 - XML Encoding of the Timeseries Profile of Observations and Measurements). Other encodings may be developed in future.

ii.    Keywords

The following are keywords to be used by search engines and document catalogues.

Timeseries, Observations, Exchange, Interoperability, OGC

iii.  Preface

This standard defines the semantics of observational data as timeseries for data exchange. It profiles the Observations and Measurements standard to define a result of type Timeseries. This allows observational information systems to communicate timeseries data between systems and to end users.  This standard has been developed from work initially undertaken within OGC WaterML 2.0: Part 1 – Timeseries. Work has been done to remove the hydrology specific aspects of this work to produce a domain-neutral model for the representation and exchange of timeseries data. 

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv.   Submitting Organizations

The following organizations submitted this document to the Open Geospatial Consortium Inc.

Australian Bureau of Meteorology

Met Office

Australian Commonwealth Scientific and Industrial Research Organisation (CSIRO)

Météo-France

KISTERS AG

Environment Canada

US National Weather Service

Landcare Research

v.     Submitters

All questions regarding this submission should be directed to the editors or the submitters:

vi.   Future Work

Future work will focus on increasing the flexibility of this standard in order to provide the widest practicable support for alternative types of timeseries. Some of the areas identified for exploration in future work include:

•     Enhanced multi-parameter support
•     Alternative encoding formats e.g. JSON, RDF etc.
•     Coverage timeseries harmonisation
•     Internet of Things harmonisation

1.    Scope

This document is an OGC® Implementation Standard for the representation of observations data structured as a timeseries. The Timeseries Profile of Observations and Measurements builds upon the OGC Observations & Measurements standard (OGC Abstract Topic 20).

The profile is designed to be extensible to allow encoding of timeseries data in a variety of exchange scenarios. Example areas of usage are: cross-border exchange of observational data; release of data for public dissemination; enhancing disaster management through data exchange; and exchange in support of national reporting. The core aspect of the model is in the correct, precise description of timeseries. Interpretation of timeseries relies on understanding the nature of the process that generated them. This standard provides the framework under which timeseries can be exchanged with appropriate metadata to allow correct machine interpretation and thus correct use for further analysis. Existing systems should be able to use this model as a conceptual ‘bridge’ between existing schema or systems, allowing consistency of the data to maintained.

This standard does not mandate an encoding, only a conceptual model. Encodings are provided in separate standards documents. At the time of writing an XML encoding is available (OGC TimeseriesML 1.0).

2.    Conformance

This standard defines a set of implementation requirements for Timeseries Observations.

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site^[1].

In order to conform to this OGC^® interface standard, a software implementation shall choose to implement:

a)      Any one of the conformance classes specified in Annex A (normative).

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

3.    References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

OGC 08-131r3 – The Specification Model – A Standard for Modular Specification

ISO 19103:2005 – Conceptual Schema Language

ISO 19108:2002 -Geographic information - Temporal schema

ISO 19109:2005 -Geographic information – Rules for application schema

ISO 8601- Data elements and interchange formats – Information interchange – Representation of dates and times

OGC Abstract Specification Topic 20  – Observations and Measurements (aka ISO 19156:2011)

OGC Abstract Specification Topic 2  – Spatial Referencing by Coordinates (aka ISO 19111:2007)

OGC Abstract Specification Topic 6  – Schema for Coverage geometry and functions (aka ISO 19123:2005)

OGC Abstract Specification Topic 11  – Geographic information — Metadata (aka ISO 19115:2003)

OGC 07-036 Geography Markup Language (aka ISO 19136:2007)

OGC WaterML2.0 part 1 – Timeseries. OGC 10-126r4. www.opengis.net/standards/waterml

OGC Observations and Measurements v2.0 OGC Document 10-004r1 http://www.opengis.net/doc/AS/Topic20 (also published as ISO 19156:2011, Geographic information— Observations and Measurements)

OGC SWE Common Data Model Encoding Standard v2.0 OGC Document 08-094r1 http://www.opengis.net/doc/IS/SWECommon/2.0

Unified Code for Units of Measure (UCUM) – Version 1.8, July 2009

Unified Modeling Language (UML). Version 2.3. May 2010.

Extensible Markup Language (XML) – Version 1.0 (Fourth Edition), August 2006

XML Schema – Version 1.0 (Second Edition), October 2004

4.    Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purpose of this document, the following additional terms and definitions apply:

4.1 Coverage

Feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain

[ISO 19123:2005, definition 4.17]

5.    Conventions

5.1    Abbreviated Terms

In this document the following abbreviations and acronyms are used or introduced: 

FTP                 File Transfer Protocol

GIS                  Geographic Information System

ISO                  International Organization for Standardization

O&M              Observations and Measurements

OGC               Open Geospatial Consortium

SensorML       Sensor Model Language

SWE                Sensor Web Enablement

TVP                Time-Value Pair

UML               Unified Modeling Language

UTC                Coordinated Universal Time

WMO             World Meteorological Organisation

XML               Extensible Markup Language

5.2    UML Notation

The diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram. 

Note: Within the context of this profile, the following colour scheme is used to identify the package in which the class exists. This is just for informative purposes.

Blue: Defined within this standard (Timeseries Profile of O&M)

Green: ISO 19156 – Observations & Measurements

Red: Other (ISO or GML)

5.3    Finding Requirements and Recommendations

This standard is identified as http://www.opengis.net/spec/timeseries/1.0. For clarity, each normative statement in this standard is in one and only one place and defined within a requirements class table and identified with a URI, whose root is the specification URI. In this standard, all requirements are associated to tests in the abstract test suite in Annex A using the URI of the requirement as the reference identifier.

Requirements classes are separated into their own clauses and named, and specified according to inheritance (direct dependencies). The Conformance test classes in the test suite are similarly named to establish an explicit and mnemonic link between requirements classes and conformance test classes.

6.    Observations and Measurements - Overview

ISO 19156 – Observations and Measurements (O&M) is a generic information model for describing observations. It defines an observation as “…an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a phenomenon. It involves application of a specified procedure, such as a sensor, instrument, algorithm or process chain. The procedure may be applied in-situ, remotely, or ex-situ with respect to the sampling location. The result of an observation is an estimate of the value of a property of some feature.” This is described using UML in Figure 1.

The Timeseries Profile of Observations & Measurements builds upon the O&M model.

6.1    Sampling Features

O&M defines the concept of sampling features as a “feature, such as a station, transect, section or specimen, which is involved in making observations concerning a domain feature.”

Sampling features are used in two circumstances:

1. The observation does not obtain values for the whole of a domain feature;
2. The observation procedure obtains values for properties that are not characteristic of the type of the ultimate feature (e.g. measuring electrical conductivity as a proxy for salinity)

These concepts are common within a number of timeseries domains, thus the sampling features concept is used in this profile.

7.    Timeseries Profile of Observations and Measurements - Overview

7.1    Introduction

The Timeseries Profile of Observations and Measurements (abbreviated to Timeseries Profile) is an open standard for conceptualising observations data as a timeseries. It is based on the information model of Observations and Measurements version 2.0 (O&M). O&M is a conceptual model for describing observations and the relationships to various important aspects of the observation process. O&M provides a conceptual model, with an associated implementation as a GML Application Schema in XML schema, for describing a wide range of observations from multiple domains; from observations made by satellites and sensors to manual procedures performed in laboratories. It is a flexible model. Likewise, this standard is accompanied by a second standard defining a GML schema encoding using GML 3.3 encoding rules (see OGC TimeseriesML 1.0).

The Timeseries Profile restricts and extends the O&M conceptual model to define a conceptual model that is directly applicable to observations and derived data structured as a timeseries.

It is possible that other implementations of the Timeseries Profile can be derived from the conceptual model, for example JSON, NetCDF, non-GML conformant XML etc.

The Timeseries Profile defines five main components for describing observations timeseries. Table 1 lists each component and its relationship with Observation and Measurements (ISO 19156).  Collections are not currently defined within O&M and are thus an extension.

The general characteristics of the Timeseries Profile are:

1. A detailed timeseries model that supports encoding of information crucial to correct interpretation of timeseries, such as properties describing the nature of individual data values and their relationships;
2. A model that is reusable across different systems and different transport technologies;
3. A model that can be extended through the use of external schema and soft-typing;
4. The ability to capture information relating to the provenance of a timeseries (i.e. how the timeseries was created).

7.2    Clarification of Terminology around Observations and Simulations

While Observations and Measurements (ISO 19156) describes a conceptual information model for describing ‘observations’ (OM_Observation), an observation in this context may be the description of outputs from simulations such as forecast models, where the ‘observations’ occur into the future, or within a simulated time period. Therefore the term ‘Observation’ or ‘observation’ in this standard should be considered to be equally applicable to actual observations and to simulations (which may be simulating the future or the past). Using the same base concepts for describing actual observations and simulations increases the ease of data integration.

7.3    Use of Vocabularies

Controlled vocabularies, also known as code-lists, are used in data exchange to identify particular concepts or terms, and sometimes relationships between them. For example, an organisation may define a controlled vocabulary for all observed phenomena that are to be exchanged between parties. Some of these definitions may be related in hierarchies or through other relationships such as equivalence (e.g. precipitation and rainfall refer to the same concept).

The Timeseries Profile does not define a full set of vocabularies for data exchange; it does, however define some vocabularies which also provide backward compatibility with vocabularies in WaterML2.0: Part 1 - Timeseries. Vocabularies are defined in the Timeseries Profile for the following concepts:

•   Quality assertions for data values of a broad, categorical type. See section 8.11.10
•   The interpolation type of the values of a timeseries. See section 8.11.11
•   The general types of processes used in observation. See section 8.11.12

These vocabularies are defined within the OGC definition namespace (http://www.opengis.net/def/), which is governed by the OGC Naming Authority (OGC-NA). The OGC-NA is responsible for processing requests to change or add new definitions to this namespace. The procedures for the OGC-NA are outlined in OGC document 09-046 (OGC-NA – Procedures) and the structure of URIs is outlined in OGC 09-048 (OGC-NA – Name type specification – definitions).

It is envisaged that the Timeseries Profile will be used alongside existing sets of vocabularies as agreed upon within communities (for example for describing the sampled medium). The parties involved in exchange will determine the vocabularies that are to be used in exchange. Optimally a recognised body, such as WMO, would govern the vocabularies. These vocabularies require a governance structure that allows changes to be made as definitions evolve.

7.4    Timeseries Observation as a specialised OM_Observation

O&M groups observations into two types based on the nature of the result: observations whose result is static (e.g. a single measurement) and observations where the result varies as some function. It is therefore possible to define an observations timeseries using this model in two ways:

1. A collection of OM_Observations. Each observation represents a single data point; the collection makes up a timeseries.
2. An OM_Observation whose result is a discrete coverage that varies in time (c.f. OM_DiscreteCoverageObservation). Here the OM_Observation feature type provides the spatio-temporal context for the whole timeseries.

TimeseriesObservation takes the second view of OM_Observation and defines TimeseriesObservation (base class), TimeseriesTVPObservation (where TVP means time-value pair) and a TimeseriesDomainRangeObservation as shown in Figure 2.

The TimeseriesObservation may be viewed as the contract that facilitates data exchange between parties through a common agreement (OM_Observation) of how observations may be conceptualised: i.e. the relationship between features, observed phenomena, procedure and the result generated (a timeseries).

The two subtypes of TimeseriesObservation offer two different structuring possibilities for the timeseries result: a time-value pair style structure where the time, value and associated metadata are encoded as coupled items (TimeseriesTVP), and a separated structure where the time and values are represented as separate collections with metadata described separately to the time and values (TimeseriesDomainRange). The second approach will most often result in a more compact encoding due to a more efficient structuring although the first encoding may be more intuitive for many users. See section 7.6.1 for a more detailed description of the relationship to coverages.

In the context of this profile, metadata at the Observation level is used as the carrier of first class elements required for data exchange and/or discovery (e.g. identifiers, spatiotemporal context, connections to features, procedures, phenomena and so on). Metadata at the Timeseries level is metadata that describes the structure and nature of the series, such as quality, interpolation types, whether the series is cumulative etc. Finally the Timeseries Profile also supports metadata at the individual data points in the timeseries for example to add quality metadata for individual values.

It should be noted that the Timeseries class and its derivatives are available for use without the TimeseriesObservation feature type; this would be useful, for example, where existing systems are communicating that have previously agreed upon identifiers and/or context that allows sufficient context for exchange to occur without providing the full TimeseriesObservation.

7.5    Feature of Interest and Spatial Sampling Features

In O&M, the feature of interest is the feature that is the target of the observation. O&M also makes a distinction between observations that make direct observations of feature properties and those that sample the feature and use the sample as a proxy for the value of a feature’s property (often this step involves process, e.g. using an aggregation or interpolation method). Within a number of domains sampling is a common approach (e.g. making a measurement at a particular point to make inferences about the whole feature).

This profile defines one specialised sampling feature, a MonitoringFeature,which can serve as the feature of interest for timeseries observations.

MonitoringFeature extends the O&M spatial sampling feature, SF_SpatialSamplingFeature.

It should be noted that a spatial sampling feature is normally a proxy feature for the ultimate feature of interest. For example the nominal temperature of a city may be determined by an observation at a single point (as opposed to measuring the temperature across the whole city). In this case the city is the ultimate feature of interest, but the feature of interest of the observation is the spatial sampling feature which is represented by a single point.

The bounding geometry of the MonitoringFeature (spatial sampling feature) is described by the ‘shape’ property from SF_SpatialSamplingFeature. For timeseries observations, the shape is frequently a point (e.g. corresponding to the location of a station or sensor) but it may be a polygon, line or other geometric object depending on the types of observations being made.

NB. Whilst this profile provides the MonitoringFeature as a candidate feature of interest for use with a timeseries observation it should be noted that any O&M Feature Type may be used.

7.6    Timeseries Concepts

Conceptually, the Timeseries Profile captures the notion of timeseries as a low-level data structure that contains an ordered set of related feature observations. The feature observations that make up a timeseries are often made by sensors, but may also be from manual observations, or a combination of both. For in-situ sensors, data loggers are often connected to sensors to store the individual observations, and will group them into timeseries for a particular phenomenon that is being measured. When data is processed from sensors and/or data loggers, particular metadata is associated with the collection of points that allow interpretation based on how the sensor is configured to measure (e.g. averaging periods, accumulation of values, value resets, etc.).

A timeseries may not be the result of direct measurements but also derived from combinations of other series, processing and/or calculations. From an O&M perspective, such timeseries are still observations but are results from a different process (e.g. a temporal aggregation process). This allows disambiguation of timeseries of directly sensed phenomena and those derived through other relationships e.g. direct measurements of discharge vs. level-to-discharge calculation using a rating curve or table.

The value type of the individual observations is another axis of categorisation for timeseries. Potential types for measurement include:

• Measures (3.2 m/s)
• Categorical (e.g. ‘cloudy’, ‘windy’, etc.)
• Vectors (e.g. wind speed and direction: 3.2 m/s North)
• Composite (combination of phenomena, e.g. Conductivity, Temperature, Dissolved oxygen)

The Timeseries Profile focuses on timeseries with value types of measures and categories. These types capture the majority of requirements for data exchange, while keeping a level of simplicity in the model and encodings, leading to simpler implementations.

Combined with the two subtypes of TimeseriesObservation identified in 7.4 these values create four possible observation subtypes with corresponding results as shown in Table 2.

Composite timeseries (multiple phenomena) and other measurement types such as vectors may be addressed in future versions.

7.6.1    Relationship to ISO 19123 – Coverages

ISO 19123 defines a coverage as a:

“(a) feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain”

Or,

“…a coverage is a feature that has multiple values for each attribute type, where each direct position within the geometric representation of the feature has a single value for each attribute type.”

It is common in many domains, particularly in some Geographic Information System (GIS) communities, to primarily consider a coverage as akin to a two dimensional spatial layer with values of a property over the layer. However it should be noted that the ISO 19123 definition is broader than this and allows for coverages that (for example) vary in time and are at a single point in a spatial coordinate reference system. Given the ISO 19123 definition, a timeseries in the context of observational data can be seen as a discrete coverage, where the domain is a spatiotemporal axis and the range is all the possible values of the observed property. An instance of such a coverage would be a set of ordered time instances where each is associated with a single value from the attribute space. This association is often represented using time-value pairs.

The ISO coverages model describes two approaches to representing coverages: a ‘domain-range’ representation where the domain and range are encoded separately, with a mapping function that allows looking up of the range value for a given domain value; and a ‘geometry-value’, or interleaved, approach whereby the geometry and value are coupled together – the coupling explicitly represents the mapping. GML 3.2.1 notes that the geometry-value approach is

“… typically used during data collection where a set or properties relating to a single location are managed together, or update of a datastore where only a small number of features are manipulated at one time.” 

And the domain-range approach is

‘…more suitable for analysis, where spatio-temporal patterns and anomalies within a specific property are of interest.”

For example, a grid showing the spatial distribution of rainfall is often generated from observations using interpolation techniques such as Kriging. The surface may be generated using point observations from in-situ sensors. The point observations are often represented using a geometry-value structure with the generated surface being represented using the domain-range approach, with a spatial grid (domain) mapped to its range values (representing total rainfall in the grid cell, for example). This provides a more efficient representation.

The Timeseries Profile defines a timeseries as a coverage whose domain consists of a collection of ordered temporal elements and the spatial component relates to the feature of interest of the observation. For in-situ timeseries the spatial element will be fixed and need not be directly represented in the timeseries domain. The core coverage elements and the relationship to timeseries are shown in Figure 4. The timeseries is a one-dimensional coverage where the varying dimension is time; time being a first class dimension equivalent to any of the spatial dimensions as supported by ISO 19123.

The TimeseriesTVP subtype of TimeseriesObservation within the Timeseries Profile is a representation of a special case of the CV_DiscreteCoverage class from OGC Abstract Specification Topic 6, in which each GeometryValuePair has a ‘geometry’ which is a timestamp, and a ‘value’ which is a measure or other simple datatype. The OGC Coverage Implementation Schema 1.1 (CIS 1.1) candidate standard[2] provides alternative representations of coverages, including an option for interleaving coverages, which can be useful for timeseries of more complex values.

7.7    Timeseries and Point metadata

Associating metadata with timeseries as a whole and at each individual data value (point) in the timeseries is a common requirement in observational data. Data is annotated with various types of qualifying information such as quality assertions, affecting environmental conditions, description of processing and so on. These annotations are important when processing and analysing timeseries to ensure correct interpretation.

The Timeseries Profile defines two core metadata classes; TimeseriesMetadata and PointMetadata. TimeseriesMetadata contains metadata that is applicable to the whole timeseries whereas PointMetadata is applicable to a particular data value in the timeseries. These classes are further specialised in the conceptual model for measurement and category based timeseries as shown in Figure 5.

Using the interleaved structuring, metadata is associated with a time-value pair explicitly, with the metadata directly associated with a pair.

Using the domain-range structuring, metadata is associated to the timeseries through an AnnotationCoverage. This is a coverage that describes the temporally ranging metadata for the series. The domain of the coverage is the time that the annotation is valid; the range captures the values of the annotation (e.g. a quality assertion). In ISO 19123 the values of range are described using a Record, which is a generic set of typed values. Each annotation that is required would need an associate record type. For example, quality may be a string record type that allows for simple categorical representations of quality.

(It is noted that the term ‘annotation coverage’ is commonly used in some domains to refer to a coverage containing labels or other cartographic text and that this usage is distinct from that purpose).

7.8    Quality

The Timeseries Profile provides the ability to specify a quality assertion using a default set of defined concepts of quality as described in the DataQualityCode code list defined in section 8.11.10. When a non-default quality code is required the qualifier property can be used.  The qualifier property is used for qualifying information that is broader in nature than the quality property. These often include indicators or flags that provide further context for the value. Qualifiers allow for deeper interpretation and capture of useful information on a per value basis. The qualifier uses the SWE Common ‘Quality’ union that allows a qualifier to be specified using a Quantity, Quantity Range, Category or Text type.

7.9    Timeseries Spacing and Interpolation Types

7.9.1    intendedObservationSpacing

This defines the expected duration between individual observations. It is common that observations will occur frequently (such as those performed by automated sensors or regular visits); this property allows specification of expected time between measurements. This is reflected in the individual points that make up the resulting timeseries, but there are cases where the observation interval does not match the intended observation interval. One example would be an increased observation interval intended to capture an event such as a peak in flood. Note the spacing property for Timeseries is a stricter definition, allowing regularly spaced (equidistant) timeseries to be encoded.

7.9.2    Equidistant timeseries (baseTime and spacing)

Ttimeseries that are regularly spaced, such as those that are generated from automatic sensors, can be represented without specifying the individual time instant for each point. The spacing property of the timeseries is used to specify the time between points. This is then used as the spacing for each point encountered, starting from the time set by baseTime. If the spacing between the timeseries values differs then the time instants should be directly represented; for such cases (non-equidistant times), the intendedObservationSpacing (section 8.10.7) may be used to indicate the expected spacing. This allows for discovery based on the intended spacing, even there are some values that are not exactly equidistant (e.g. the frequency was increased through an important event).

7.9.3    Anchor Point

The startAnchorPoint and endAnchorPoint properties are used to extend a timeseries to include non-explicitly represented periods of time for which the observation is valid. Individual points, when associated with their interpolation type (section 7.9.6), have a ‘direction’ in time: to correctly process such data it is required to understand where the boundaries of the values lie.

For example, in Figure 6, the first point of the series (position B) has a data type of average for the preceding interval. Here the value represents the average from the previous point up to this point. As there is no previous point (it is the first in the series), it is not possible to determine when the preceding interval began. The anchor point time specifies a ‘ghost’ point to allow the value to be interpreted correctly.

7.9.4    Joining Separate Observation Series (max gap period)

When two non-overlapping timeseries have been separately collected they require ‘connection’ in order to make a single timeseries. For example, if the latest two months of observational timeseries data is transferred from one system to a major archive, the series must be connected in order to make a full series over which reporting can be run (e.g. to calculate yearly summaries). Figure 7 shows an example of this scenario.

Observation set #2 is the latest 2 months of data coming into the archival set shown by observation set #1. The join period between the two series will be determined by the time period between the series where no existing points exist. When any analysis is run over this series it is important to know if it is possible to interpolate between point A and point B. The maxGapPeriod property defines this for an observation series – if the join period is greater than the maxGapPeriod then the series should not be interpolated between the adjoining points.

7.9.5    Cumulative timeseries

A series that is defined as cumulative (using the cumulative property of type boolean) is one where the values indicate a sequentially increasing series; i.e. each value is added to the last so the value represents the total of a value since accumulation began. An example is shown in Figure 8.

Note: cumulative series should only be used for timeseries of the total data types: instantaneous total, preceding total, succeeding total as these represent total quantities.

The accumulationAnchorTime is used to define the time at which accumulation begins. This is used for consistently accumulated values (such as rainfall) where the values are representing a continuous stream of totals across a certain period. The accumulationIntervalLengthdefines the duration of the period. For example, Figure 9 shows accumulated daily rainfall totals from 9am to 9am.

7.9.6    Interpolation Type

One of the core characteristics of measurement timeseries is the nature of the relationship between the time instant and the recorded value. This relationship is determined by the procedure that was used in making the estimate that the value represents. Representing this is crucial to correctly interpret the timeseries values. For example, the value may represent an average across the time period since the last point (average in preceding interval). The Timeseries Profile defines a number of types of timeseries, as shown in Table 3.

The interpolation type is defined per point within the timeseries as it is possible for this to change mid series.

Table Types of timeseries

	7.9.6.1 Continuous/Instantaneous A continuous timeseries indicates the observation result is the value of a property at the indicated instant in time. The points are essentially connected and interpolation may occur between points in order to estimate the value of the property between points. The appropriate time spacing between successive points to minimise interpolation errors is related to rate of change (wrt time) of the property. http://www.opengis.net/def/timeseries/InterpolationCode/Continuous
	7.9.6.2            Discontinuous The sampling of the property occurs such that it is not possible to regard the series as continuous. The time between samples is too large to classify the measurements as continuous. http://www.opengis.net/def/timeseries/InterpolationCode/Discontinuous
	7.9.6.3            Instantaneous Total Value represents a total attributed to a specific time instant. This is normally generated from an event based measuring device such as a tipping bucket rain gauge. http://www.opengis.net/def/timeseries/InterpolationCode/InstantTotal
	7.9.6.4            Average in preceding interval Value represents the average value over the preceding interval. http://www.opengis.net/def/timeseries/InterpolationCode/AveragePrec
	7.9.6.5            Maximum in preceding interval Value represents the maximum value that was measured during the preceding time interval. http://www.opengis.net/def/timeseries/InterpolationCode/MaxPrec
	7.9.6.6            Minimum in preceding interval Value represents the minimum value that was measured during the preceding time interval. http://www.opengis.net/def/timeseries/InterpolationCode/MinPrec
	7.9.6.7            Preceding total Value represents the total of measurements taken within the previous time interval. http://www.opengis.net/def/timeseries/InterpolationCode/TotalPrec
	7.9.6.8            Average in succeeding interval Value represents the average value over the following interval. http://www.opengis.net/def/timeseries/InterpolationCode/AverageSucc
	7.9.6.9            Succeeding total Value represents the total of measurements taken within the following time interval. http://www.opengis.net/def/timeseries/InterpolationCode/TotalSucc
	7.9.6.10         Minimum in succeeding interval Value represents the minimum value for the following interval. http://www.opengis.net/def/timeseries/InterpolationCode/MinSucc
	7.9.6.11         Maximum in succeeding interval Value represents the maximum value for the following interval. http://www.opengis.net/def/timeseries/InterpolationCode/MaxSucc
	7.9.6.12         Constant in preceding interval Value is constant in the preceding interval. http://www.opengis.net/def/timeseries/InterpolationCode/ConstPrec
	7.9.6.13         Constant in succeeding interval Value is constant in the succeeding interval. http://www.opengis.net/def/timeseries/InterpolationCode/ConstSucc
	7.9.6.14         Statistical Interpolation type is defined by a statistical method. http://www.opengis.net/def/timeseries/InterpolationCode/Statistical

7.10    Observation Process

Within O&M, the ProcessUsed association links the observation to the OM_Process used to generate the result. OM_Process is abstract and does not define any attributes or associations. This standard specialises O&M as shown in Figure 10.

A large number of direct in-situ observations are performed by a sensor or sensor system. Manual procedures may also be used to make measurements at a particular sampling feature. These may be ad-hoc visits to a particular feature, or continued visits to a well identified sampling feature.

Procedures that generate derived or synthetic results also exist, such as those produced by algorithms or simulations. Algorithms are commonly implemented in software to process data sets for reporting or other purposes. Examples include:

• Temporal interpolation or aggregation;
• Spatial interpolation;
• Quality assurance related tasks such as automatic spike removal or gap filling;
• Derivation of new “observed phenomena”.

These operations are performed on raw observational data to create separate data products more appropriate for particular types of reporting, ingestion into models, or for archival purposes. Maintaining information on the procedure used in the creation of a new ‘observation’ is important for correct interpretation of an observation’s result. Note here that the data being described is not strictly an observation but the O&M model is appropriate for such description, and encourages such use:

“An instance of OM_Process is often an instrument or sensor, but may be a human observer, a simulator, or a process or algorithm applied to more primitive results used as inputs.”

A TimeseriesObservation shall have a procedure property of type or subtype of either OM_Process or SWE AbstractProcess, or a reference to one of these types. This includes ObservationProcess defined in this standard as a subtype of OM_Process.

7.11    Sampling Feature Collections

Defining groups of sampling features is often required, allowing multiple sampling features to be associated with a particular identifier or name. A SamplingFeatureCollection is how a group such as a “field site with many sampling locations” would be expressed.

A sampling group may be defined by fully defining each of the sampling features contained in the group, or by referencing each of the sampling features in the group.

 It is possible to implement sampling groups in both directions:

• When defining the sampling feature, include a relation to the sampling features in the group using the relatedSamplingFeatureproperty.
• Define a SF_SamplingFeatureCollection that contains the sampling features.

Note: this can be done by referencing already defined sampling features through an identifier or by defining the containing features directly inline.

7.12    Collections

The Timeseries Profile defines a generic collection feature type, Collection, to allow the grouping of observations and/or sampling features with metadata to describe the nature of the collection. Its UML is shown in Figure 12. Such collections are required in a number of data exchange scenarios; whether the underlying transport technology is web services, FTP or other technologies.

The grouping may indicate a relationship between the contained entities; however the relationship will depend on the individual use of the collection class. For example, a collection of observations may be all the observations within the last 24 hours for a particular measuring location, but this would be determined by the system creating or handling the documents.

The collection class also allows for local definitions of codes, such as quality codes and qualifiers. The local dictionaries are a convenience to allow elements that normally reside in code lists to be specified locally in the document. There are two benefits to this: it allows metadata to be provided alongside each code item; and it allows more compact encoding for code list items that need to be referenced regularly.

Finally the collection class allows for references to conformance classes (by conformance class identifier) to indicate which conformance classes are adhered to within the collection.

The contents of a collection will be determined by the scenario in which it is used; some examples include:

• Web service responses;
• Transactional updates;
• Data from groups of sensors.

The collection class may be replaced by services that already define such collections – such as in the Sensor Observation Service – but the model may be used as a guide to the content of collections.

8.    The Timeseries Profile UML Conceptual Model - Requirements Classes

This section defines a set of Requirements Classes for a timeseries conceptualmodel. This is not an encoding but a set of concepts that could be implemented in numerous ways or technology. A normative XML Schema implementation is provided in OGC15-042 TimeseriesML 1.0 – XML Encoding.

8.1    Requirement Class Dependencies

8.2    Requirements Class: Sampling Feature Collections

8.2.1    Requirements class overview

It is often necessary or useful to define groups of monitoring features, for example when there are several monitoring points at a particular site or station.

The ISO 19156 SF_SamplingFeatureCollectionprovides this grouping mechanism. A group can be defined in one of two ways:

·      By including a relationship from the sampling feature (MonitoringFeature) to the group using the relatedSamplingFeature property of the sampling feature.

·      By defining a SF_SamplingFeatureCollection that contains the sampling points. This can be done by defining the points inline of the collection or by referencing pre-defined sampling points using an identifier.

8.3    Requirements Class: Collection

8.3.1    Requirements class overview

8.3.2    Collection properties

The Timeseries Profile defines a generic collection feature type, Collection, to allow the grouping of observations and/or sampling features with metadata to describe the nature of the collection. Such collections are required in a number of data exchange scenarios; whether the underlying transport technology is web services, FTP or other technologies.

8.3.3    SamplingFeatureMember properties

A sampling feature member may be either a single sampling feature (e.g. MonitoringFeature) or a group of features (SF_SamplingFeatureCollection).

8.4    Requirements Class: Timeseries Observation

8.4.1    Requirements class overview

This standard defines TimeseriesObservation as a type of OM_Observation with particular requirements on the feature of interest, the result (must be a Timeseries), the procedure, and other aspects of the observation.

Two subtypes of TimeseriesObservationoffer two different encoding structures for the timeseries result: a time-value pair style structure where the time, value and associated metadata are encoded as coupled items (TimeseriesTVPObservation), and a separated structure where the time and values are represented as separate collections with metadata described separately to the time and values (TimeseriesDomainRangeObservation). The second approach will most often result in a more compact encoding due to a more efficient structuring and is consistent with the ISO 19123 Coverages model.

In this conceptual model TimeseriesTVPObservation and Timeseries are further sub-classed into: CategoricalTimeseriesTVPObservation, MeasurementTimeseriesTVPObservation, CategoricalTimeseriesDomainRangeObservationandMeasurementTimeseriesDomainRangeObservation.

8.4.2    TimeseriesObservation properties

A TimeseriesObservation is defined as a specialisation of the O&M OM_DiscreteCoverageObservation.

8.5    Requirements Class: Timeseries (TVP) Observation

8.5.1    Requirements class overview

8.5.2    TimeseriesTVPObservation properties

TimeseriesTVPObservation is a TimeseriesObservation where the result is a time-value pair encoded timeseries.

8.6    Requirements Class: Measurement Timeseries (TVP) Observation

8.6.1    Requirements class overview

8.6.2    MeasurementTimeseriesTVPObservation properties

MeasurementTimeseriesTVPObservation is a TimeseriesObservation where the result is a time-value pair encoded timeseries.

8.7    Requirements Class: Categorical Timeseries (TVP) Observation

8.7.1    Requirements class overview

8.7.2    CategoricalTimeseriesTVPObservation properties

CategoricalTimeseriesTVPObservation is a TimeseriesObservation where the result is a time-value pair encoded timeseries containing category type values (typically according to a defined classification scheme).

8.8    Requirements Class: Timeseries (Domain Range) Observation

8.8.1    Requirements class overview

A TimeseriesDomainRangeObservation is a type of timeseries observation where the result is a domain range encoded timeseries.

In a domain range encoding, the coverage domain (points, in this case temporal points) are encoded separately from the coverage rangeset (i.e. the values e.g. measurements).

8.8.2    TimeseriesDomainRangeObservation properties

TimeseriesDomainRangeObservation is a TimeseriesObservation where the result is a domain-range encoded timeseries.

8.9    Requirements Class: Measurement Timeseries (Domain Range) Observation

8.9.1    Requirements class overview

8.9.2    MeasurementTimeseriesDomainRangeObservation properties

A MeasurementTimeseriesDomainRangeObservation is a TimeseriesObservation where the result is a domain range encoded timeseries with measurement values for the rangeset.

8.10    Requirements Class: Categorical Timeseries (Domain Range) Observation

8.10.1    Requirements class overview

8.10.2    CategoricalTimeseriesDomainRangeObservation properties

CategoricalTimeseriesDomainRangeObservation is a TimeseriesObservation where the result is a domain-range encoded timeseries containing category type values (typically according to a defined classification scheme).

8.11    Requirements Class: Timeseries (core)

8.11.1    Requirements class overview

The core Timeseriesclass contains an ordered set of data. This data may be annotated with metadata about each particular data point (PointMetadata). It may also be annotated with metadata about the Timeseries as a whole (TimeseriesMetadata). There are several specializations of Timeseriesin this standard to accommodate different encodings (interleaved and domain-range) and different result types (measurement and categorical). The Timeseries(or it’s specializations) is the result of a TimeseriesObservation.

Several codelists are used by the Timeseries Profile. Some of these are initially defined in this standard (but may be extended by the OGC without updating this standard), others are not explicitly defined in this standard at all and community codelists may be used.

At a conceptual level the Timeseries Profile defines a timeseries as a coverage whose domain consists of collection of ordered temporal elements and the spatial component relates to the feature of interest of the observation.

8.11.2    Timeseries properties

Class described in the Timeseries requirements class. Base type for abstract timeseries of records.

8.11.3    AnnotatedTimeValuePair properties

The AnnotatedTimeValuePair is a datatype containing a simple time-value pair along with optional metadata about that data point.

8.11.4    CommentBlock properties

Comment blocks may be used to make comment about the timeseries. Each comment applies to a specified period of the timeseries (it could apply to the whole timeseries).

8.11.5    SampledMediumCode Codelist

The contents of this codelist are not defined in this standard. It is a stub for any community or vendor-specific codelist that defines codes for sampled media relevant to timeseries observations.

8.11.6    StatusCode Codelist

The contents of this codelist is not defined in this standard. It is a stub for any community or vendor specific codelist that defines status codes relevant to timeseries observations (for example to indicate what verification checks have taken place).

8.11.7    TimeseriesMetadata properties

In the context of this profile, metadata at the Observation level is used as the carrier of first class elements required for data exchange and/or discovery (e.g. identifiers, spatiotemporal context, connections to features, procedures, phenomena and so on). Metadata at the Timeseries level is metadata that describes the structure and nature of the series, such as quality interpolation types, whether the series is cumulative etc. It should be noted that the Timeseriesclass is available for use without the TimeseriesObservationfeature type; this would be useful, for example, where existing systems are communicating that have previously agreed upon identifiers and/or context that allows sufficient context for exchange to occur.

8.11.8    PointMetadata properties

The point metadata applies to an individual point. Although default values may be set depending on the encoding. In the XML encoding in this standard the concept of default point metadata is implemented.

8.11.9    TSML_DomainObject properties

The TSML_DomainObject is abstract. It has no properties, but carries two constraints:

• Temporal elements shall be ordered in increasing time
• The domain of the result is defined by the feature of interest (the spatial location) and the temporal steps on the timeseries.

8.11.10    DataQualityCode Codelist

Terms in this codelist are used to indicate the quality of individual data points. This codelist shall be managed by the OGC and is extensible outside of this standard at the discretion of the OGC.

The identifier for this codelist shall be:

http://www.opengis.net/def/timeseries/DataQualityCode

All items in this codelist shall have identifiers that follow the pattern:

http://www.opengis.net/def/timeseries/DataQualityCode/[itemlabel]

8.11.11    InterpolationCode Codelist

Terms in this codelist are used to indicate how data should be interpolated between neigbouring points in a timeseries. This codelist shall be managed by the OGC and is extensible outside of this standard at the discretion of the OGC.

The identifier for this codelist shall be:

http://www.opengis.net/def/timeseries/InterpolationCode

All items in this codelist shall have identifiers that follow the pattern:

http://www.opengis.net/def/timeseries/InterpolationCode/[itemlabel]

8.11.12    ProcessingCode Codelist

The contents of this codelist is not defined in this standard. It is a stub for any community or vendor specific codelist that defines processing codes relevant to timeseries observations (for example to indicate what processing level or step has been reached).

8.12    Requirements Class: CategoricalMetadata

8.13    Requirements Class: MeasurementMetadata

8.13.1    Requirements class overview

8.13.2    MeasurementTimeseriesMetadata properties

Metadata specific to measurement timeseries.

8.13.3    MeasurementPointMetadata properties

Metadata about a time-value data point for a measurement timeseries.

8.14    Requirements Class: Interleaved (TVP) Timeseries

8.14.1    Requirements class overview

8.14.2    TimeseriesTVP properties

The TimeseriesTVP is a timeseries encoding following a time-value pair interleaved pattern. It is made up of a set of individual time-value pairs (elements).

8.14.3    TimeValuePair properties

A single point in time and associated value (e.g. measurement).

8.15    Requirements Class: Measurement (TVP) Timeseries

8.15.1    Requirements class overview

The MeasurementTimeseriesTVP is a timeseries encoding following time-value pair interleaved pattern where the values of the range are measures.

8.15.2    MeasurementTimeseriesTVP properties

The MeasurementTimeseriesTVP is a timeseries encoding following a time-value pair interleaved pattern where the value is a measurement. It is made up of a set of individual time-value pairs (elements).

8.15.3    MeasureTimeValuePair properties

A time-value pair encoding where the value is a measure.

8.16    Requirements Class: Categorical (TVP) Timeseries

8.16.1    Requirements class overview

8.16.2    CategoricalTimeseriesTVP properties

The CategoricalTimeseriesTVP is a timeseries encoding following a time-value pair interleaved pattern where the value is a category. It is made up of a set of individual time-value pairs (elements).

8.16.3    CategoryTimeValuePair properties

A time-value pair encoding where the value is a categorisation.

8.17    Requirements Class: Timeseries (Domain Range)

8.17.1    Requirements class overview

The TimeseriesDomainRange is a timeseries encoding following the coverage domain-range pattern.

8.18    Requirements Class: Measurement (Domain Range) Timeseries

8.18.1    Requirements class overview

The MeasurementTimeseriesDomainRange is a timeseries encoding following the coverage domain-range pattern where each range element is a Measure.

8.19    Requirements Class: Categorical (Domain Range) Timeseries

8.19.1    Requirements class overview

The CategoricalTimeseriesDomainRange is a timeseries encoding following the coverage domain-range pattern where each range element is a value from a category. 

8.20    Requirements Class: Monitoring Feature

8.20.1    Requirements class overview

The MonitoringFeature serves as the feature of interest for timeseries observations. It extends SF_SpatialSamplingFeature. The geometry of the MonitoringFeature is described by the ‘shape’ property. For timeseries observations the shape is frequently a point but may be an area polygon or other geometric object.

8.20.2    MonitoringFeature properties

A feature where observations are taken such as a sensor, gauge or monitoring site.

8.20.3    TimeZone properties

The TimeZone class captures information about a timezone.

8.21    Requirements Class: MonitoringFeature FeatureOfInterest

8.21.1    Requirements class overview

8.22    Requirements Class: Procedures

8.22.1    Requirements class overview

8.22.2    ObservationProcess properties

A large number of direct in-situ observations are performed by a sensor or sensor system. Common types of sensors include rain gauges, level gauges, quality sensors such as temperature, turbidity etc.

Manual procedures may be also used to make measurements at a particular sampling point. These may be ad-hoc visits to particular point that may be of interest, or continued visits to a well identified sampling point.

Procedures that generate derived or synthetic results also exist, such as those produced by algorithms or simulations. Algorithms are commonly implemented in hydrological software to process data sets for reporting or other purposes. Examples include:

• Temporal interpolation or aggregation;
• Spatial interpolation;
• Quality assurance related tasks such as automatic spike removal or gap filling;
• Derivation of new observed phenomena such as calculation of volume from stage, discharge (flow) from stage etc.

8.22.3    ProcessTypeCode Codelist

Terms from this codelist are used to indicate the type of process that was used in an observation. This codelist shall be managed by the OGC and is extensible outside of this standard at the discretion of the OGC.

The identifier for this codelist shall be:

http://www.opengis.net/def/timeseries/ProcessTypeCode

All items in this codelist shall have identifiers that follow the pattern:

http://www.opengis.net/def/timeseries/ProcessTypeCode/[itemlabel]