Open Geospatial Consortium

Submission Date: 2021-11-18

Approval Date:   2022-03-07

Publication Date:   2023-05-26

External identifier of this OGC® document:

Internal reference number of this OGC® document: 20-082r4

Version: 3.0.0

Category: OGC® Abstract Specification

Editors:  Katharina Schleidt, Ilkka Rinne

OGC Abstract Specification Topic 20:
Observations, measurements and samples

Copyright notice

Copyright © 2023 Open Geospatial Consortium
To obtain additional rights of use, visit


This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:

OGC® Abstract Specification

Document subtype:

Document stage:

Approved for public release

Document language:


License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.



This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

Note on the OGC and ISO TC 211 Standards alignment

This revised OGC Standard was created from ISO 19156:2023(E) document after the final edits by the ISO Central Secretariat for publication as an ISO International Standard. It has an identical content with ISO 19156:2023(E) except for the copyright, title pages and double branding.


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



Ilkka Rinne (ed.)

Spatineo Oy

Katharina Schleidt (ed.)


Linda van den Brink


Sylvain Grellet


Clemens Portele

Interactive Instruments GmbH

Hylke van der Schaaf

Fraunhofer IOSB


The submitters would like to acknowledge the following people as important contributors to this version of the specification:



Mickael Beaufils


Hélène Bressan


Simon Cox

CSIRO Australia

Abdelfettah Feliachi


Robin Huisman

Terraindex B.V.

Alistair Ritchie

Landcare Research New Zealand Limited

László Sőrés

Hungarian Mining and Geological Service

Jörg Klausen

World Meteorological Organization (WMO)

Supporting and contributing organizations

The submitters would like to acknowledge the following organizations as important supporters and contributors to this version of the specification:



CSIRO Australia


Finnish Meteorological Institute

Fraunhofer IOSB


Hungarian Mining and Geological Service

Interactive Instruments GmbH

Manaaki Whenua - Landcare Research New Zealand Limited

Spatineo Oy

Terraindex B.V.

Vaisala Oyj

Pole INSIDE - Environmental information systems research center

Table of Contents


This second edition cancels and replaces OGC Abstract Specification Topic 20 – Observations and Measurements (OGC 10-004r3), which has been technically revised.

The main changes are as follows:

— the UML model and the requirements/conformance class structure has been completely redesigned to address the contemporary modelling and observation data provision use cases;

— the fundamental Observation model has remained largely the same as in OGC 10-004r3, but certain carefully designed improvements and clarifications for the intended use have been included;

— the Sample model has been refined: given the integral nature of the Sample model, is has been decided to include that term in the name of the document;

— Annex C has been added listing the changes between OGC 10-004r3 and this document.

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.


This document arises from work originally undertaken through the Open Geospatial Consortium’s Sensor Web Enablement (SWE) activity. A set of interfaces and protocols was standardized through which applications and services are able to access sensors of all types, and observations generated by them, over the Web.

A new generation of geospatial standards is now emerging, based on general Web standards, architecture and current practice, as described in W3C Spatial Data on the Web Best Practices.[31] This includes several new standards for describing and publishing sensors and observations, such as the OGC SensorThings API[22] and the W3C/OGC Semantic Sensor Network Ontology.[28] This Abstract Specification Topic 20 (now named “Observations, Measurements, and Samples”, or abbreviated to "OMS") is informed by these recent developments. The focus of revising the Topic is aimed at enabling the publication of observation data as part of the Web of data, while also supporting other means of data exchange.

The content presented in this document is derived from the previous edition published by Open Geospatial Consortium as OGC 10-004r3, and also ISO 19156:2011. A technical note describing the changes in comparison to OGC 10-004r3 is provided in Annex C.

Geographic information — Observations, measurements and samples

1. Scope

This document defines a conceptual schema for observations, for features involved in the observation process, and for features involved in sampling when making observations. These provide models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities.

Observations commonly involve sampling of an ultimate feature-of-interest. This document defines a common set of sample types according to their spatial, material (for ex situ observations) or statistical nature. The schema includes relationships between sample features (sub-sampling, derived samples).

This document concerns only externally visible interfaces and places no restriction on the underlying implementations other than what is needed to satisfy the interface specifications in the actual situation.

2. Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO 19103, Geographic information — Conceptual schema language

ISO 19107, Geographic information — Spatial schema

ISO 19108, Geographic information — Temporal schema

3. Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at

— IEC Electropedia: available at

3.1 application schema

conceptual schema for data required by one or more applications

[SOURCE: ISO 19101-1:2014, 4.1.2]

3.2 coverage

feature that acts as a function to return values from its range for any direct position within its domain

[SOURCE: ISO 19123-1:—, Under preparation. Stage at the time of publication: ISO/FDIS 19123-1:2023. 3.1.8]

3.3 data type

specification of a value domain with operations allowed on values in this domain

EXAMPLE Integer, Real, Boolean, String and Date.

Note 1 to entry: Data types include primitive predefined types and user-definable types.
[SOURCE: ISO 19103:2015, 4.14]

3.4 domain

well-defined set

Note 1 to entry: All elements within a domain (set) are of a given type.
[SOURCE: ISO 19109:2015, 4.8, modified — Original Note 1 to entry has been replaced with a new Note 1 to entry.]

3.5 domain feature

feature of a type defined within a particular application domain

Note 1 to entry: This can be contrasted with observations and sampling features, which are features of types defined for cross-domain purposes.

3.6 ex situ


referring to the study, maintenance or conservation of a specimen or population away from its natural surroundings

Note 1 to entry: Opposite of in situ (on-site).
Note 2 to entry: An example of ex situ and direct is measuring a patient’s temperature with a mercury thermometer in a blood sample.
Note 3 to entry: An example of ex situ and remote is measuring a patient’s temperature with an infra-red thermometer pointed at the blood sample.

3.7 feature

abstraction of real-world phenomena

Note 1 to entry: A feature can occur as a type or an instance. In this document, feature instance is meant unless otherwise specified.
[SOURCE: ISO 19101-1:2014, 4.1.11, modified — Note 1 to entry has been modified.]

3.8 feature-of-interest

subject of the observation

3.9 feature type

class of features having common characteristics

3.10 in situ


referring to the study, maintenance or conservation of a specimen or population without removing it from its natural surroundings

Note 1 to entry: Opposite of ex situ (off-site).
Note 2 to entry: An example of in situ and direct is measuring a patient’s temperature with a mercury thermometer in the patient’s rectum.
Note 3 to entry: An example of in situ and remote is measuring a patient’s temperature with an infra-red thermometer at a distance.

3.11 measure

<GML> value described using a numeric amount with a scale or using a scalar reference system

Note 1 to entry: When used as a noun, measure is a synonym for physical quantity.
[SOURCE: ISO 19136-1:2020, 3.1.41]

3.12 measurement

set of operations having the object of determining the value of a quantity

[SOURCE: ISO 19101-2:2018, 3.21]

3.13 observation

act carried out by an observer to determine the value of an observable property of an object (feature-of-interest) by using a procedure, with the value provided as the result

3.14 observation result

estimate of the value of a property determined through a known observation procedure

3.15 observer

identifiable entity that can generate observations pertaining to an observable property by implementing a procedure

Note 1 to entry: An observer is an instance of a sensor, instrument, implementation of an algorithm or a being such as a person.

3.16 procedure

specified way to carry out an activity or a process

[SOURCE: ISO 9000:2015, 3.4.5, modified — Note 1 to entry has been deleted.]

3.17 process

set of interrelated or interacting activities that use inputs to deliver an intended result

[SOURCE: ISO 9000:2015, 3.4.1, modified — Notes 1-6 have been deleted.]

3.18 property

facet or attribute of an object referenced by a name

EXAMPLE Abby’s car has the colour red, where “colour red” is a property of the car.

Note 1 to entry: In some communities, the observed property is referred to as the measurand.
[SOURCE: ISO 19143:2010, 4.21, modified — Example and note have been added to the entry.]

3.19 property type

characteristic of a feature type

EXAMPLE Cars (a feature type) all have a characteristic colour, where “colour” is a property type.

Note 1 to entry: The value for an instance of an observable property type can be estimated through an act of observation.
Note 2 to entry: In chemistry-related applications, the term “determinand” or “analyte” is often used.

3.20 proximate feature-of-interest

entity that is directly of interest in the act of observing

Note 1 to entry: This is a specialized form of the feature-of-interest.

3.21 range

<coverage> set of feature attribute values associated by a function, the coverage, with the elements of the domain of a coverage

Note 1 to entry: This is consistent with the more generic definition of "range" in ISO 19107.
[SOURCE: ISO 19123-1:—, 3.1.47]

3.22 sample

object that is representative of a concept, real-world object or phenomenon

3.23 sampler

device or entity (including humans) that is used by, or implements, a sampling procedure to create or transform one or more sample(s)

3.24 sensor

element of a measuring system that is directly affected by a phenomenon, body, or substance carrying a quantity to be measured

[SOURCE: JCGM 200:2012, 3.8, modified — EXAMPLES and NOTE deleted.]

3.25 ultimate feature-of-interest

entity that is ultimately of interest in the act of observing

Note 1 to entry: This is a specialized form of the feature-of-interest.

3.26 unit of measure

reference quantity chosen from a unit equivalence group

Note 1 to entry: In positioning services, the usual units of measurement are either angular units or linear units. Implementations of positioning services shall clearly distinguish between SI units and non-SI units. When non-SI units are employed, it is required that their relation to SI units be specified.
[SOURCE: ISO 19116:2019, 3.29]

3.27 value

element of a type domain

Note 1 to entry: A value considers a possible state of an object within a class or type (domain).
Note 2 to entry: A data value is an instance of a datatype, a value without identity.
Note 3 to entry: A value can use one of a variety of scales including nominal, ordinal, ratio and interval, spatial and temporal. Primitive datatypes can be combined to form aggregate datatypes with aggregate values, including vectors, tensors and images.
[SOURCE: ISO/IEC 19501:2005, 0000_5, modified — Notes 1- 3 to entry have been added.]

4. Document conventions

4.1. Abbreviated terms and acronyms


Coverage Implementation Schema


Earth observation


General Feature Model


Geography Markup Language


Infrastructure for Spatial Information in Europe


Observations and measurements


Observations, measurements and samples (this document)


Open Geospatial Consortium


Research Data Alliance


OGC Sensor Model Language


OGC Sensor Observation Service


OGC SensorThings API


OGC Sensor Web Enablement


Unified Modeling Language


unit of measure


Uniform Resource Identifier


Extensible Markup Language





4.2. Schema language

The conceptual schema specified in this document is in accordance with the Unified Modelling Language (UML, ISO/IEC 19501), following the guidance of ISO 19103.

The UML in Abstract Core and Basic packages is conformant with the profile described in ISO 19136-1:2020, Annex E. Use of this restricted idiom supports direct transformation into a GML Application Schema. The stereotype «FeatureType» states that a class is an instance of the «metaclass» FeatureType (ISO 19109) and therefore represents a feature type.

The prose explanation of the model uses the term “property” to refer to both class attributes and association roles. This is consistent with the General Feature Model described in ISO 19109. In the context of properties, the term “value” refers to either a literal (for attributes whose type is simple), or to an instance of the class providing the type of the attribute or target of the association. Within the explanation, the property names (property types) are sometimes used as natural language words where this assists in constructing a readable text.

4.3. Model element names

This document specifies a model for observations using terminology that is based on current practice in a variety of scientific and technical disciplines. It is designed to be applied across disciplines, so the best or “most neutral” term has been used in naming the classes, attributes and associations provided. The terminology does not, however, correspond precisely with any single discipline. As an aid to implementers, a mapping from the element names specified in this document to common terminology in related application domains is provided in Annex B.

4.4. Requirements and recommendations

All requirements are normative and each is presented with the following template:

Requirement /req/{pkg}/{classM}/{reqN}

[Normative statement]

where /req/{pkg}/{classM}/{reqN} identifies the requirement. The use of this layout convention allows the normative provisions of this document to be easily located by implementers.

All defined classes, attributes and associations mentioned within requirements or recommendations are shown in bold. These correspond to references to the definition of the referenced element.

The following base (/req/{pkg}/) has been used per package:

a) /req/obs-cpt: Conceptual Observation schema;

b) /req/obs-core: Abstract Observation Core;

c) /req/obs-basic: Basic Observations;

d) /req/sam-cpt: Conceptual Sample schema;

e) /req/sam-core: Abstract Sample core;

f) /req/sam-basic: Basic Samples.

In the lines below, the base (/req/{pkg}/) has been left out for better readability.

For naming of individual requirements pertaining to classes, the following syntax is used.

{Class Name}-sem: The semantic definition of the concept, together with the naming of the Class.

For naming of individual requirements pertaining to attributes or associations, the following syntax is used.

{Attribute/Association Name}-sem: The semantic definition of the concept, together with the naming of the attribute or association role. Except for cases where concepts are mandatory within all packages, these statements are phrased to be cardinality-neutral, e.g. they apply to cardinality 0..*.

{Attribute/Association Name}-type: Type information pertaining to the attribute or association when the type is constrained within one model package.

{Attribute/Association Name}-card: Cardinality information pertaining to the attribute or association, when the cardinality is constrained within one model package.

{Attribute/Association Name}-con: Additional constraints. As these sometimes pertain to multiple attributes or associations, this part of the name can become more complex.

Individual requirements are case-sensitive, following UML naming conventions. Requirements pertaining to classes contain the class name in UpperCamelCase. Requirements pertaining to attributes or associations utilize the attribute name or association role name in lowerCamelCase.

All recommendations are informative and each is presented with the following template:

Recommendation /rec/{pkg}/{classM}/{recO}

[Informative statement]

where /rec/{pkg}/{classM}/{recO} identifies the recommendation. The use of this layout convention allows the informative provisions of this document to be easily located by implementers.

4.5. Requirements classes

Each statement (requirement or recommendation) in this document is a member of a requirements class.

All requirement classes are normative.

Each requirements class is described in a discrete clause and summarized using the following template:

Requirements class


Target type

[artefact or technology type]


Name of the requirements class










[repeat as necessary]

All requirements in a class shall be satisfied. Hence, the requirements class is the unit of re-use and dependency.

Dependency to another requirements class (and the requirements and recommendations defined in it) is done using the “Imports” keyword. All requirements in a dependency shall also be satisfied by a conforming implementation.

A requirements class may consist only of dependencies and introduce no new requirements.

4.6. Conformance classes

Conformance to this document is possible at a number of levels, specified by conformance classes in accordance with Annex A. Each conformance class is summarized using the following template:

Conformance class



[Identifier for the requirements class]

Test purpose

[Reason for test]

Test method

[Method to determine if test fulfilled]

Test type

[Type of test]

All tests in a class shall be passed. Each conformance class tests conformance to a set of requirements packaged in a requirements class.

4.7. Identifiers

Each requirements class, requirement and recommendation is identified by a unique identifier. This allows cross-referencing of class membership, dependencies and links from each conformance test to the requirements tested. Appended to a base Uniform Resource Identifier (URI) that identifies the specification as a whole, it enables the construction of a complete URI for identification in an external context.

The entire Requirements and Conformance Structure, consisting of the individual requirements and definitions together with the information on how these are linked together for the creation of Requirements and Conformance classes, will be exposed in a machine-actionable format (such as the one provided by the OGC Definitions Server).

The URI for each requirements class has the form:

The URI for each requirement has the form:

The URI for each recommendation has the form:

The URI for each conformance class has the form:

4.8. Associations in UML context diagrams

The UML model described in this document is rather complex. To keep the text size readable in the UML, context diagrams of this document only display certain associations of each class. Please refer to the context diagram of a particular class to see all associations of that class. All associations of the classes in each package are also shown in the detailed package overview diagrams in Annex E.

5. Conformance

5.1. Overview

Clauses 8 to 13 of this document use UML to present conceptual schemas for describing Observations. These schemas define conceptual classes that:

a) may be considered to comprise a cross-domain application schema; or

b) may be used in application schemas, profiles and implementation specifications.

This flexibility is controlled by a set of UML types that can be implemented in a variety of manners. Use of alternative names that are more familiar in a particular application is acceptable, provided that there is a one-to-one mapping to classes and properties in this document.

The UML model in this document defines conceptual classes. Various software systems define implementation classes or data structures. All of these reference the same information content. The same name may be used in implementations as in the model, so that types defined in the UML model may be used directly in application schemas.

Annex A defines a set of conformance tests that will support applications whose requirements range from the minimum necessary to define data structures to full object implementation.

5.2. Conformance classes

The conformance rules for Models in general are described in ISO 19109. Application Schemas also claiming conformance to this document shall also conform to the rules specified in Clauses 8 to 13 and pass all relevant test cases of the Abstract Test Suite in Annex A.

Depending on the characteristics of the implementing model application, schema or profile, one or more of the declared conformance classes can be chosen for fine-grained Observations, measurements and samples (OMS) conformance. Table 1, Table 2, Table 3, Table 4, Table 5 and Table 6 list all of these classes by package, including their relative identifiers and the corresponding subclauses of the Abstract Test Suite. The full URIs of the conformance classes are formed by prefixing the relative URI path as described in 4.7.

Table 1. Conceptual Observation schema conformance classes
Conformance class Identifier Subclause

Conceptual Observation schema package



Conceptual Observation – Deployment



Conceptual Observation – Host



Conceptual Observation – ObservableProperty



Conceptual Observation – Observation



Conceptual Observation – Observer



Conceptual Observation – ObservingProcedure



Conceptual Observation – Procedure



Table 2. Abstract Observation Core conformance classes
Conformance class Identifier Subclause

Abstract Observation Core package



Abstract Observation Core – AbstractDeployment



Abstract Observation Core – AbstractHost



Abstract Observation Core – AbstractObservableProperty



Abstract Observation Core – AbstractObservation



Abstract Observation Core – AbstractObservationCharacteristics



Abstract Observation Core – AbstractObserver



Abstract Observation Core – AbstractObservingProcedure



Abstract Observation Core – NamedValue



Abstract Observation Core – AbstractObservationCollection



Table 3. Basic Observations conformance classes
Conformance class Identifier Subclause

Basic Observations package



Basic Observations – Deployment



Basic Observations – GenericDomainFeature



Basic Observations – Host



Basic Observations – ObservableProperty



Basic Observations – Observation



Basic Observations – ObservationCharacteristics



Basic Observations – ObservationCollection



Basic Observations – Observer



Basic Observations – ObservingCapability



Basic Observations – ObservingProcedure



Table 4. Conceptual Sample schema conformance classes
Conformance class Identifier Subclause

Conceptual Sample schema package



Conceptual Sample – PreparationProcedure



Conceptual Sample – PreparationStep



Conceptual Sample – Sample



Conceptual Sample – Sampler



Conceptual Sample – Sampling



Conceptual Sample – SamplingProcedure



Table 5. Abstract Sample Core conformance classes
Conformance class Identifier Subclause

Abstract Sample Core package



Abstract Sample Core – AbstractPreparationProcedure



Abstract Sample Core – AbstractPreparationStep



Abstract Sample Core – AbstractSample



Abstract Sample Core – AbstractSampler



Abstract Sample Core – AbstractSampling



Abstract Sample Core – AbstractSamplingProcedure



Table 6. Basic Samples conformance classes
Conformance class Identifier Subclause

Basic Samples package



Basic Samples – MaterialSample



Basic Samples – NamedLocation



Basic Samples – PhysicalDimension



Basic Samples – Sample



Basic Samples – SampleCollection



Basic Samples – Sampler



Basic Samples – Sampling



Basic Samples – SpatialSample



Basic Samples – StatisticalClassification



Basic Samples – StatisticalSample



6. Packaging, requirements and dependencies

6.1. Requirements

As OMS implementations often seamlessly integrate with existing data ecosystems, a very flexible requirements and conformance structure is defined. This structure enables users to selectively mix and match elements as required for their purposes from the OMS data model without the necessity of achieving compliance with the entire data model.

Such flexibility is becoming increasingly relevant with the shift to Linked Data practices, where different organizations maintain and expose only certain aspects of a larger distributed dataset.

EXAMPLE Some providers only serve information on Observable Properties or Monitoring Facilities, while relying on other partners to provide information on measurement procedures. These can claim compliance to those parts falling under their responsibility, while letting other data providers link to these resources.

For this purpose, a fine-grained structure for requirements and recommendations, requirements classes and conformance classes has been defined. As far as possible, patterns from the OGC Modular Specification[25] have been taken into account. However, pertaining to the alignment between UML Packages and Conformance Classes, a relaxation of the requirement on one-to-one alignment between UML Package and Conformance class has been proposed as follows.

a) For each UML Package, both a Requirements Class as well as a conformance class have been defined.

b) Additional Requirements Classes have been created for each Class appearing in the data model. Conformance Classes are added accordingly to enable grouping of the former and support references to either a group or an individual Requirement Class depending on the need.

c) Thematic domains can create additional Requirements and Conformance classes reflecting their domain profiles by reference to existing Requirements and Requirements Classes.

As mentioned, as data provision paradigms increasingly shift towards distributed and linked approaches, stipulating that all aspects of an information system conform explicitly to the same underlying standards becomes increasingly difficult. Simultaneously, as distributed data provision becomes increasingly ubiquitous, ever more communities are emerging dedicated to individual aspects of the wider data provision landscape.

One example of such external definition and hosting pertains to the provision of observable properties. In previous versions of the Observations and Measurements (O&M) Model, the observable properties concept was only included as a metaclass, with the assumption that a reference to an existing code list will be provided. Within the current OMS Model, the observable property has been upgraded to a featureType. This is because emerging requirements show the need for a more detailed model for this concept. Simultaneously, other communities, such as the Research Data Alliance (RDA), are also working on observable property models (I-ADOPT). The same rationale can be applied to most concepts from the OMS Model.

In order to expose this flexibility beyond the package structure described above, a fine-grained hierarchical requirements class structure was created. A modular requirements class is provided for each concept at all three levels of the model. In addition, a further requirements class that imports all the modular classes provided for the individual concepts has been provided for each package.

6.2. UML

6.2.1. UML package structure

OMS provides the relevant concepts for the structured description of observations, including the sampling structure often essential for true understanding of the nature of the observations being provided. As data provision mechanisms are transitioning towards highly distributed linked approaches, the model structure and packaging has been significantly abstracted. This approach allows implementers to explicitly select the concepts to be supported based on their requirements, while clearly stating to which requirements and Conformance Classes their implementation complies. Both the Observation and Sample sections of this model have been structured using the following layering of packages.

a) Conceptual: Within the Conceptual Model Packages, only Interfaces are provided. These models provide a very abstract view of the individual concepts they contain without reference to specific implementations. This approach allows for the inclusion of semantically aligned objects from external sources, which, although they have not been created under the OMS model, do provide concepts sharing the same semantic meaning as the concepts from the Conceptual models.

b) Abstract Core: Within the Abstract Core Model Packages, only abstract featureTypes are provided following the semantic structure of the Conceptual model (i.e. realizing the interfaces provided by the Conceptual Model Packages). A consistent approach to metadata provision is introduced. All associations from the abstract featureTypes reference the conceptual interfaces for greater implementation flexibility. The Abstract Core Model Packages are foreseen for the creation of domain models providing an Abstract Core ready for Extension.

c) Basic: Within the Basic Packages, simple concrete featureTypes (specializing the abstract ones from the Abstract Core model) have been defined with some basic utility attributes added for rapid out-of-the-box deployment. A few additional concepts pertaining to collections and potential observations are introduced at this level.

6.2.2. UML package dependencies

Some model elements used in the schema are defined in other International Standards. Table 7 lists the dependencies between the UML packages defined in this document and other International Standards, and Figure 1 shows the dependencies of the entire OMS UML model package to the other International Standards in a graphical form.

Table 7. UML package level dependencies
OMS Package Package International Standard Classes

Conceptual Observation schema

Any type

ISO 19103:2015


Conceptual Observation schema

Temporal Objects

ISO 19108:2002


Conceptual Observation schema

Name types

ISO 19103:2015


Abstract Observation Core

Conceptual Observation schema

ISO 19156:2023 (this document)

TM_Instant, TM_Period via the Temporal Objects dependency

Abstract Observation Core

General Feature Model

ISO 19109:2015

Feature concepts

Abstract Observation Core


ISO 19103:2015


Basic Observations

Abstract Observation Core

ISO 19156:2023 (this document)


Basic Observations

Web environment

ISO 19103:2015


Basic Observations


ISO 19107:2019


Conceptual Sample schema

Any type

ISO 19103:2015


Conceptual Sample schema

Temporal Objects

ISO 19108:2002


Conceptual Sample schema

Name types

ISO 19103:2015


Conceptual Sample schema

Conceptual Observation schema

ISO 19156:2023 (this document)

Observation, Procedure

Abstract Sample Core

Conceptual Sample schema

ISO 19156:2023 (this document)


Abstract Sample Core

General Feature Model

ISO 19109:2015

Feature concepts

Abstract Sample Core


ISO 19107:2019


Abstract Sample Core


ISO 19103:2015


Abstract Sample Core

Abstract Observation Core

ISO 19156:2023 (this document)


Basic Samples

Abstract Sample core

ISO 19156:2023 (this document)


Basic Samples

Web environment

ISO 19103:2015


Basic Samples

Measure types

ISO 19103:2015


External UML package dependencies
Figure 1. External UML package dependencies

6.3. Note on the use of "Any"

The UML models defined in this document make extensive use of the Any interface defined in the ISO 19103:2015 Any type package. The realized Any values of the associations with role names proximateFeatureOfInterest, ultimateFeatureOfInterest, result, metadata, featureOfInterest and sampledFeature may be of any type or a reference to a digital representation of an appropriate concept. If they are of feature type, the values are not owned by the instances of referring classes, they may have an independent life span from the referring classes, and they may be associated with more than one instance of referring classes.

Any type can be owl:Thing, featureType, dataType

EXAMPLE 2 Reference to SensorThings deployment:

EXAMPLE 4 Reference to an instance of borehole:

EXAMPLE 5 Reference to a hydrostation:

EXAMPLE 6 Reference to a river segment:

EXAMPLE 7 An (embedded) Boolean value as Result.

EXAMPLE 8 An (embedded) SWE DataRecord.

EXAMPLE 10 OMS MaterialSample → Reference to a rock sample:

7. Fundamental characteristics of observations and samples (informative)

7.1. Observation schema

7.1.1. Property evaluation

Properties of a feature fall into two basic categories.

1) Value (e.g. name, price, legal boundary) assigned by some authority. These are exact.

2) Value (e.g. height, classification, colour) determined by application of an observation procedure. These are estimates, with a finite error associated with the value.

The observation error typically has a systematic component, which is similar for all estimates made using the same procedure, and a random component, associated with the particular application instance of the observation procedure. If potential errors in a property value are important in the context of a data analysis or processing application, then the details of the act of observation which provided the estimate of the value are required.

7.1.2. Observation

An observation is an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a characteristic. This act 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 a given feature; an observation is a property-value-provider for a feature-of-interest. Use of a common model allows observation data using different procedures to be combined unambiguously.

In conventional measurement theory (e.g. References [11], [14], [15], [16], [18], [23]) the term “measurement” is used. However, a distinction between measurement and category-observation has been adopted in more recent work[12],[17],[24] so the term “observation” is used here for the general concept. “Measurement” may be reserved for cases where the result is a numerical quantity.

The observation itself is also a feature, since it has properties and identity.

Observation details are important for data discovery and for data quality estimation.

The observation could be considered to carry “property-level” instance metadata, which complements the dataset-level and feature-level metadata commonly provided via catalogue services (e.g. the ISO 19115 series or another community agreed one).

7.1.3. Properties of an Observation

An observation results in a value being assigned to a characteristic. The characteristic is a property of a feature, the latter being the feature-of-interest of the observation. The observation uses a specified procedure performed by an observer, which is often an instrument or sensor[11],[12] but may be a process chain, human observer, an algorithm, a computation or a simulator. The key idea is that the observation result is an estimate of the value of some quality (property, characteristic) of the feature-of-interest, and the other properties of the observation provide context or metadata to support evaluation, interpretation and use of the result. Figure 2 (based on representation work done under INSPIRE[29]) provides a visual overview of this.

Properties of an Observation
Figure 2. Properties of an Observation

The relationship between the properties of an observation and those of its feature-of-interest is key to the semantics of the data model elaborated in this document. This is further elaborated in Clause D.3.

7.1.4. Observation location

The principal location of interest of an observation is usually associated with the ultimate feature-of-interest.

However, the location of the feature-of-interest can potentially not be readily available. For example, in remote sensing applications, a complex processing chain is required to geolocate the scene or swath. In feature-detection applications, the initial observation can be made on a scene, but the entity to be detected, which is the ultimate feature-of-interest, occupies some location within it. The distinction between the proximate and ultimate feature-of-interest is a key consideration in these cases. The proximate feature-of-interest is the object upon which the measurement is directly performed, whereas the ultimate feature-of-interest is the object for which this measurement is ultimately seen as representative of.

Other locations may be relevant in various scenarios. Sub-sampling at locations within the feature-of-interest may occur. The procedure may involve a sensor located remotely from the ultimate feature-of-interest such as in remote sensing, or where specimens are removed from their sampling location and observations made ex-situ (the sampling schema description below elaborates on this). Furthermore, the location of the feature-of-interest may be time-dependent.

The model is generic. The geospatial location of the feature-of-interest may be of little or no interest for some observations (e.g. live specimens, observations made on non-located things like chemical species).

For these reasons, a generic Observation class does not have an inherent location property. Relevant location information should be provided by the feature-of-interest, by the sampling procedure, or by the observation procedure, according to the specific scenario.

In contrast to spatial properties, some temporal properties are associated directly with an observation (8.2.3; 8.2.4). This is due to the fact that an observation is a kind of event so its temporal characteristics are fundamental, rather than incidental.

7.1.5. Result types

Observation results may have many datatypes, including primitive types like category or measure, but may also have more complex types such as time, location and geometry. Complex results are obtained when the observed property requires multiple components for its encoding. Furthermore, if the property varies on the feature-of-interest, then the result is a coverage, whose domain extent is the extent of the feature. In reality, the result will typically be sampled discretely on the domain and may be represented as a discrete coverage.

Building on this, specialized observation types can be defined by communities to describe the type of result provided, expressed using a terminology common to that community.

7.1.6. Use of the observation model

The observation model takes a data-user-centric viewpoint, emphasizing the semantics of the feature-of-interest and its properties. This contrasts with sensor-oriented models, which take a process- and thus a provider-centric viewpoint.

The digital representation of an observation is a property-value-provider for a feature-of-interest. Aside from the result, the details of the observation event are primarily of interest in applications where an evaluation of errors in the estimate of the value of a property is of concern. The observation could be considered to carry “property-level” instance metadata, complementing the dataset-level and feature-level metadata that have been conventionally considered (e.g. ISO 19115-1).

Additional discussion of the application of the observation and sample models, and nuances within these, is provided in Annex D.

7.2. Sample schema

7.2.1. Role of sample features

A sample may act as a proxy for the ultimate feature-of-interest of an observation, and be associated with this observation by the role feature-of-interest. In this case the sampled-feature association of the sample would point upwards in the chain of sampled features leading to the ultimate feature-of-interest of the observation. The sample may also be associated with observations, both those being made directly on the sample as well as observations on other samples.

7.2.2. Proximate vs. ultimate feature-of-interest Introduction

The observation model maps the result of the application of a procedure to a subject, which plays the role of feature-of-interest of the observation. However, the proximate feature-of-interest of an observation is not always the ultimate domain-specific feature whose properties are of interest in the investigation of which the observation is a part. There are three circumstances that can lead to this:

a) the observation does not obtain values for the whole of a domain feature;

b) the observation is performed on a proxy that is not part of the domain feature;

c) the observation procedure obtains values for properties that are not characteristic of the type of the ultimate feature.

Furthermore, in some practical situations, multiple differences apply. Proximate feature-of-interest embodies a sample design

In some cases, for various reasons, the domain feature is not fully accessible. In such circumstances, the procedure for estimating the value of a property of the domain feature involves sampling in representative locations. Then the procedure for transforming a property value observed on the sample to an estimate of the property on the ultimate feature-of-interest depends on the sample design.

EXAMPLE 1 The chemistry of water in an underground aquifer is sampled at one or more positions in a well or bore.

EXAMPLE 2 The magnetic field of the earth is sampled at positions along a flight-line. In contrast to the well in the EXAMPLE 1, the flight-line does not represent a real-world object.

EXAMPLE 3 The structure of a rock mass is observed on a cross-section exposed in a river bank.

EXAMPLE 4 The bubble of air around the intake of an air quality monitoring station is taken as representative for the wider air around the station. Again, a virtual feature serves as proximate feature-of-interest.

In other cases, where direct observation of the domain feature is not possible, the observation may be performed on a proxy.

EXAMPLE 5 In order to measure the intensity of the sun’s light, the reflectance on a white sheet of paper can be utilized as a proxy for the sun’s intensity.

In some cases, the observation procedure obtains values for properties that are not characteristic of the type of the ultimate feature.

EXAMPLE 6 The salinity of water in a well is measured, the feature-of-interest of this well is an aquifer. However, the final target of the observation is the fluid body contained within the aquifer (see Figure 8). Observed property is a proxy

The procedure for obtaining values of the property of interest may be indirect, relying on direct observation of a more convenient parameter which is a proxy for the property of interest. Application of an algorithm or processing chain obtains an estimate of the ultimate property of interest.

The observation model requires that the feature-of-interest of the initial observation be of a type that carries the observed property within its properties. Thus, if the proxy property is not a member of the ultimate feature-of-interest, a proxy feature with a suitable model shall be involved.

EXAMPLE 1 A remote sensing observation can potentially obtain the reflectance colour, when the investigation is actually interested in vegetation type and quality. The feature which contains reflectance colour is a scene or swath, while the feature carrying vegetation properties is a parcel or tract.

EXAMPLE 2 The direct value coming from a sensor can be quantified as a voltage, whereas the observed property represented by this voltage is the physiochemical value being observed by the sensor (e.g. pH). Combination

These variations may be combined if exhaustive observation of the domain feature is impractical, and direct measurement is of a proxy property.

EXAMPLE For certain styles of mineralization, the gold concentration of rocks in a region can be estimated through measurement of a related element (e.g. copper) in a specimen of gravel collected from a stream that drains part of the region. The gravel samples the rocks in the catchment of the stream, i.e. in the stream bed and upslope.

7.2.3. Role of samples

Samples are artefacts of an observational strategy and have no significant function outside of their role in the observation process. The physical characteristics of the samples themselves are of little interest, except perhaps to the manager of a sampling campaign.

EXAMPLE 1 In various countries/domains, terms like “site” and station” are encountered. These usually correspond to an identifiable locality where a monitoring facility (host, platform, etc.) has been established, or sensors or other measurement devices (observers) have been deployed to acquire observations on a given observable property applying a specific procedure. In the context of the observation model, the spatial sample (both proximate and ultimate) connotes the world in the vicinity of the observer/sampler, so the observed properties relate to the physical medium at the observer/sampler described by the sample, and not to any physical artefact such as a mooring, buoy, benchmark, monument, well, and so forth that are potentially described by the Host.

EXAMPLE 2 In some domains, elements are taken from their natural environment (ex situ), curated and preserved for the purpose of keeping a trace of their existence. Examples include biodiversity studies, crop seed preservation, etc. In those cases, the material samples considered are called specimen. It is for this reason that the class named "SF_Specimen" in the previous edition of this document has been renamed "MaterialSample" in this edition.

EXAMPLE 3 Statistical samples usually apply to populations or other sets, of which a certain subset can be of specific interest.

A transient spatial sample, such as a ship-track or flight-line, can be identified and described, but is unlikely to be revisited exactly.

A sample is intended to sample some object in an application domain. However, in some cases the identity, and even the exact type, of the sampled object is not known when observations are made using the sample.

7.2.4. Sampling process

Understanding the process by which samples are obtained is often essential to understanding the context of subsequent measurements on this object (feature-of-interest). Different sampling strategies can provide vastly different samples, in turn leading to different result values in observations pertaining to these samples.

A sample is created through the act of sampling, whereby a sampler follows a defined procedure in order to identify and/or extract representative samples from the ultimate feature-of-interest.

The nature of the sampler varies by sampling strategy; at one end of the spectrum the sampler can be a sensor or other automated measurement device; at the other end of the spectrum the sampler can be a human being providing observations or taking part in a biodiversity survey campaign.

As a dependence on the sampling strategy, a sampling procedure appropriate to the sampling act to be performed needs to be selected and defined. For the provision of fine-grained information pertaining to the sampling process, multiple sampling procedures can be applied to one sampling act. Multiple sampling procedures can also be required for the case where one sampling process classifies samples in accordance with multiple criteria.

EXAMPLE 1 When performing observations on populations, these can potentially first be sampled by gender and age. Sampling procedures describing the criteria utilized for gender and age classification can be provided individually.

A sampling event can involve very different samples, whereby some of these samples can serve purely to provide contextual information pertaining to the sampling event.

EXAMPLE 2 When sampling water from a river, information on the meteorology at the time of sampling can be relevant for the interpretation of measurements obtained on the water sample.

7.2.5. Classification of samples

A small number of common sampling patterns, similar across domains, provide a basis for processing and portrayal tools, and depend particularly on the geometry of the sample design. These provide a basis for processing and portrayal tools which are similar across domains, and depend particularly on the geometry of the sample design. Common names for sampling features include specimen, sample, site, profile, transect, path, swath and scene.

Spatial sampling is classified primarily by the topological dimension. Material samples can provide information on their original source location, but are more often characterized by their size and storage location.

In addition, various preparation steps may be performed on samples both before and after observations are performed on the sample.

Additional information on provenance, curation and methods of archiving a sample has been delegated to external standards that may be referenced via the ‘metadata’ association that can be provided for all types contained within the Sampling model.

7.3. Alignment between Observation, Sample and domain models

7.3.1. Model consistency

The type of the feature-of-interest is defined in an application schema (ISO 19109). This may be part of a domain model, or may be from a cross-domain model, such as Sample (Clause 11). The feature type defines its set of characteristics as properties. For consistency, the feature-of-interest shall carry the observed property as part of the definition of its type (e.g. Figure 3).

EXAMPLE A pallet with the characteristic mass is to be described via a feature model. In the simplest form, an interface “Pallet” can be defined as having the attribute “mass” of type “Measure” describing the mass characteristic of the pallet being described (Figure 3). However, when using this direct approach, no further measurement metadata is available; only the numeric mass is provided together with the unit of measurement.

(Example) Pallet interface
Figure 3. (Example) Pallet interface
Simple example for model consistency.

Alternatively, through utilization of the OMS model, an observation providing the value of this property for the feature being investigated may be utilized to fulfil the data requirements ensuing from the Pallet Interface. This approach makes it possible for the information system to ‘describe’ how the result (here mass value) was obtained together with the relevant value.

For this purpose, the observation shall have observedProperty “mass”, the result shall be of the type “Measure” and the scale (unit of measure) shall be suitable for mass measurements. Thus, the requirements ensuing from the Pallet Interface are fulfilled, while additional relevant measurement meta-information is also provided; model consistency has been ensured. This approach is illustrated in Figure 4.

(Example) An observation with consistent properties
Figure 4. (Example) An observation with consistent properties
The observed property (mass) is a characteristic associated with the type of the feature-of-interest (Pallet) and the procedure and result type are also suitable.

Figure 5 shows a complete representation of a mass observation. In addition to the basic information provided with the observation in Figure 4, information on the specific measurement device used is provided together with information on where this device was deployed as the observation was performed.

(Example) An observation with complete properties
Figure 5. (Example) An observation with complete properties
For additional context, the Observer, Host and Deployment have been added.

An attribute from within the conceptual model can be instantiated as an Observation in the concrete realization. The attributes that have been defined for the domain feature within the interface, in the example “mass” and “uom”, can be realized through the association of an Observation carrying this information. Formally, these two representations both realize the defined interface.

Based on the use case, when modelling, it is necessary to decide whether solely providing information of type "Measure" with UoM is sufficient for the domain considered. In some cases, the full OMS model is required to actually discover, exchange and reuse data properly. For example, a single attribute "lake surface" will be sufficient for most mapping agency needs, whereas a more thorough observation description of how that surface was measured and when (e.g. dam empty/full, rainfall observation, etc.) is important for water management needs.

7.3.2. Relationship between Sample and domain features

A Sample feature is established in order to make observations concerning some domain feature. The association “sampledFeature” links the Sample feature to the feature which this Sample feature was designed to sample. The target of this association is usually a real-world feature from an application domain (see Figure 6).

EXAMPLE A profile typically samples a water- or atmospheric-column; a well samples the water in an aquifer; a tissue specimen samples a part of an organism.