4.1. example term

5.1.  Identifiers

The normative provisions in this standard are denoted by the URI

http://www.opengis.net/spec/sensorthings/2.0

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

6.1.  Who should use the OGC SensorThings API

Organizations that need web-based platforms to manage, store, share, and analyze IoT-based sensor observation data should use the OGC SensorThings API. The OGC SensorThings API simplifies and accelerates the development of IoT applications. Application developers can use this open Standard to connect to various IoT devices and create innovative applications without worrying the daunting heterogeneous protocols of the different IoT devices, gateways and services. IoT device manufacturers can also use OGC SensorThings API as the API can be embedded within various IoT hardware and software platforms, so that the various IoT devices can effortlessly connect with the OGC Standard-compliant servers around the world. In summary, the OGC SensorThings API is transforming the numerous disjointed IoT systems into a fully connected platform where complex tasks can be synchronized and performed.

6.2.  Benefits of the OGC SensorThings API

In today’s world, most IoT devices (e.g., sensors and actuators) have proprietary software interfaces defined by their manufacturers and used selectively. New APIs are often required and developed on an as-needed basis, often in an environment with resource limitations and associated risks. This situation requires significant investment on the part of developers for each new sensor or project involving multiple systems and on the part of the providers of sensors, gateways, and portals or services where observations and measurements are required.

As a standardized data model and interface for sensors in the WoT and IoT, the OGC SensorThings API offers the following benefits: (1) it permits the proliferation of new high value services with lower overhead of development and wider reach, (2) it lowers the risks, time and cost across a full IoT product cycle, and (3) it simplifies the connections between devices-to-devices and devices-to-applications.

6.3.  SensorThings API Overview

The OGC SensorThings API data model consists of three main parts: (1) the Sensing part, (2) the Sampling part and (3) the Tasking part. Additionally, SensorThings API supports the following two extensions to the data model: (1) the Sensing Extension (Observations & Measurements) and (2) the Relations extension

The Sensing part allows IoT devices and applications to CREATE, READ, UPDATE, and DELETE (i.e., HTTP POST, GET, PATCH, and DELETE) IoT data and metadata in a SensorThings service. The Sensing part is designed based on the OGC/ISO Observation, Measurements and Samples (OMS) model [OGC 20-004r3 and ISO 19156:2023]. An Observation is modeled as an act that produces a result whose value is an estimate of a property of a given Feature. An Observation instance is characterized by its event time (e.g., resultTime and phenonmenonTime), Feature, ObservedProperty, and the procedure used (often a Sensor). Moreover, Things are also modeled in the SensorThings API. A Thing draws from the same concept as a Host in OMS where a Host is defined as a collection of Observers (defined as Sensor in SensorThings API). Formally, its definition follows the ITU-T definition: “an object of the physical world (physical things) or the information world (virtual things) that is capable of being identified and integrated into communication networks” [ITU-T Y.2060]. The geographical Locations of Things are useful in almost every application and as a result are included as well. For the Things whose location changed, the HistoricalLocations entities offer the history of the Thing’s locations. A Thing also can have multiple Datastreams. A Datastream is a collection of Observations grouped by the same ObservedProperty, Sensor and optionally by Feature and ObservingProcedure. An Observation is an event performed by a Sensor that produces a result whose value is an estimate of an ObservedProperty of any given Feature which may be a proximate or ultimate FeatureofInterest. Details of each above described entity are provided in Clause 7.

The Sampling part is a new addition to the SensorThings API. As is often the case, an Observation may not be a true representation of the intended Feature’s Property that an Observer may be trying to Observe. Sampling is a common strategy to understand the characteristics of an otherwise difficult-to-measure Property of any feature-of-interest. Samples are created by a Sampler, that may be a physical device or a human being. The method used to execute a Sampling may be described by a SamplingProcedure. This SamplingProcedure can be used by multiple Samplers and conversely, a Sampler may implement multiple SamplingProcedures. However, any Sampling that is executed by a Sampler is always associated with a unique SamplingProcedure. In addition, various preparation steps may be performed on samples both before and after observations are performed on the sample. The entities are explained in detail in [sampling-extension].

The Tasking part provides a standard way for parameterizing — also called tasking — of taskable IoT devices, such as individual sensors and actuators, composite consumer / commercial / industrial / smart cities in-situ platforms, mobile and wearable devices, or even unmanned systems platforms such as drones, satellites, connected and autonomous vehicles, etc. A Task defines a control action executed by an Actuator. Actuator is modeled to describe a device that is equipped with Tasking Capabilities. A TaskingCapability characterizes an Actuator’s (or in some cases, a Thing’s) ability to trigger a change in ActuableProperties of any FeatureOfInterest by executing the given Task. The Tasking Data Model thus mirrors the Sensing Data Model. Each of these entities are elaborated further in [actuation-extension].

The [sensing-OM-extension] and [relations-extension] are optional extensions to the data model that may be used for extended data modelling requirements.

6.4.  SensorThings API and Relation to ISO/OGC Observations, Measurements and Samples

Managing and retrieving observations and metadata from IoT sensor systems is one of the most common use cases. As a result, SensorThings API’s sensing part is designed based on the OMS model. OMS defines models for the exchange of information describing observation acts, their results as well as the feature involved in sampling when making observations.

SensorThings API defines nine entities for the IoT sensing applications and several additional entities in various extensions. base lists each component and its relationship with OMS. SensorThings API uses the term of Sensor to describe the Observer that is used in generating an Observation, instead of using OMS’ term of Observer.

Table 1 — SensorThings API Sensing entities and equivalent concepts in OMS 3.0

6.5.  SensorThings API 2.0 changes from 1.1

From the SensorThings API version 1.1 to 2.0 changes have been made to both the data model and the API. The changes to the data model have been summarised in Table 2 and Figure 1.

Table 2 — Changes in the SensorThings API 2.0 data model compared to v1.1

Figure 1 — Sensing Core Changes

6.6.  Relation to OASIS-OData

OData is an API standard for exchanging relational data. It allows for the definition of a consistent REST API on any relational data model. OData specifies how clients can inspect the data model and how they can perform Create, Read, Update and Delete actions. OData comes with a very powerful query language that allows users to compose the response to queries such that only a minimal number of queries is required to fetch needed data, regardless of the use case of the client. The OData specification also defines filtering mechanisms that allows filtering across relations. OData uses JSON-encoding by default, and specifies generic rules for encoding relational data models in JSON.

The OGC SensorThings API v2 interface is not an OData interface and does not claim to be an OData service. It specifies a subset of the OData 4.01 interface, and extends it at the same time. A SensorThings API Server implementation can implement the full OData specification. An OData client can access a SensorThings API service.

7.1.  Recurring attributes

Several attributes are used in several classes. They always have the same semantic meaning, regarless of the class they are used in.

7.2.  Thing

The SensorThings API follows the ITU-T definition, i.e., with regard to the Internet of Things, a thing is an object of the physical world (physical things) or the information world (virtual things) that is capable of being identified and integrated into communication networks [ITU-T Y.2060]. A Thing is related to the Platform entity as described in Section 4.9.2.1 of [OGC 16-079] in a way that any entity that can be modelled as a Thing MAY be subsequently translated to a Platform and vice versa.

Table 3 — Attributes of a Thing entity

Table 4 — Direct relation between a Thing entity and other entity types

{
  "@context": "https://example.org/v2.0/$metadata#Things/$entity",
  "@id": "Things(1)",
  "id": 1,
  "name": "Oven",
  "description": "This thing is an oven.",
  "properties": {
    "owner": "Ulrike Schmidt",
    "color": "Black"
  },
  "Locations@navigationLink": "Things(1)/Locations",
  "Datastreams@navigationLink": "Things(1)/Datastreams",
  "HistoricalLocations@navigationLink": "Things(1)/HistoricalLocations"
}

Listing 1 — Example of a Thing entity returned by a HTTP end point.

7.3.  Location

The Location entity geo-locates the Thing or the Things it associated with. A Thing’s Location entity is defined as the last known location of the Thing.

The Feature can be either a proximate feature of interest or the ultimate feature of interest depending upon the context of the Observation. For in-situ sensing applications, the Location MAY describe the coordinates of where the Thing is located. The Feature is the entity for which the value of a property was determined by the Sensor. The ObservedProperty in this case MAY characterize only the area around the sensing device or it MAY characterize the larger observedArea that the sensing application intends to capture. Thus, depending upon the feature-of-interest, the Feature can then be either a ProximateFeatureOfInterest or UltimateFeatureOfInterest. For ex-situ sensing applications, the Location MAY describe the coordinates of where the Thing is located, whereas the feature MAY be the point location of the observed Feature.

Section 7.1.4 of [OGC 20-082r4 and ISO 19156:2023] provides a detailed explanation of observation location.

Table 5 — Attributes of a Location entity

Table 6 — Direct relation between a Location entity and other entity types

Table 7 — Non-exhaustive list of code values used for identifying types for the encodingType of the Location and Feature entities

{
  "@context": "https://example.org/v2.0/$metadata#Locations/$entity",
  "@id": "Locations(1)",
  "id": 1,
  "name": "CCIT",
  "description": "Calgary Center for Innvative Technologies",
  "encodingType": "application/geo+json",
  "location": {
    "type": "Feature",
    "geometry":{
      "type": "Point",
      "coordinates": [-114.06,51.05]
    }
  },
  "Things@navigationLink": "Locations(1)/Things",
  "HistoricalLocations@navigationLink": "Locations(1)/HistoricalLocations",
}

Listing 2 — Example of a Location entity using a GeoJSON Feature.

{
  "@context": "https://example.org/v2.0/$metadata#Locations/$entity",
  "@id": "Locations(2)",
  "id": 2,
  "name": "IOSB",
  "description": "Fraunhofer-Institut für Optronik, Systemtechnik und Bildauswertung IOSB",
  "encodingType": "application/geo+json",
  "location": {
    "type": "Point",
    "coordinates": [8.426, 49.015]
  },
  "Things@navigationLink": "Locations(2)/Things",
  "HistoricalLocations@navigationLink": "Locations(2)/HistoricalLocations",
}

Listing 3 — Example of a Location entity using a GeoJSON Geometry.

7.4.  HistoricalLocation

A Thing’s HistoricalLocation entity set provides the times of the current (i.e., last known) and previous locations of the Thing. It can be used to model the path observed by a moving Thing.

The HistoricalLocation can also be created, updated and deleted. One use case is to migrate historical observation data from an existing observation data management system to a SensorThings API system. Another use case is to track the Location of a Thing, when a permanent network connection is not available. If the Location of a Thing is changed at a later time, when a network connection is available again, then the auto-generated Time of the HistoricalLocation entity would not reflect the time when the Thing was actually at the set Location, but only the time at which the change was sent to the server. To resolve this, the Location of a Thing can also be changed by adding a HistoricalLocation. If the time of a manually created HistoricalLocation is later than the time of all existing HistoricalLocations, then the Location of the Thing is updated to the Location of this manually created HistoricalLocation.

Table 8 — Attributes of a HistoricalLocation entity

Table 9 — Direct relation between a HistoricalLocation entity and other entity types

{
  "@context": "https://example.org/v2.0/$metadata#HistoricalLocations/$entity",
  "@id": "HistoricalLocations(1)",
  "id": 1,
  "time": "2020-03-20T16:35:23.383586Z",
  "Thing@navigationLink": "HistoricalLocations(1)/Thing",
  "Locations@navigationLink": "HistoricalLocations(1)/Locations"
}

Listing 4 — Example of a HistoricalLocation entity returned by a HTTP end point.

7.5.  Datastream

A Datastream groups a collection of Observations into a time series measuring the same ObservedProperty by the same Sensor for the same Feature for the same Thing.

Table 10 — Attributes of a Datastream entity

TM_Period is by default encoded as a complex type with a start (mandatory) and end (mandatory) attributes of type TM_Instant.

Table 11 — Direct relation between a Datastream entity and other entity types

The resultType defines the result types for specialized single and multi observations based on the JSON encoding of the SWE Common Data Model [OGC 08-094r1 and OGC 17-011r2]. The result of an Observation may be a single simple number or String, or it may contain a complex JSON structure holding multiple values for multiple ObservedProperties. The exact definition for this result structure, and which unit of measurement and which ObservedProperty pertains to each value in the result structure is exactly described by this resultType Object.

{
  "name": "Oven temperature",
  "description": "This is a datastream measuring the air temperature in an oven.",
  "resultType": {
    "type": "Quantity",
    "definition": "http://mmisw.org/ont/cf/parameter/air_temperature",
    "uom": { "code": "Cel", "label": "degree Celsius", "symbol": "°C" }
  }
}

Listing 5 — A Datastream example measuring a scalar Observation

{
  "result": 25.1,
  "phenomenonTime":  {
    "start": "2021-13-14T15:16:00Z"
  }
}

Listing 6 — An Observation for the Datastream defined in the example above

{
  "name": "Sample Datings",
  "description": "This is a datastream containing the geological datings of rock samples.",
  "resultType": {
    "type": "Category",
    "definition": "http://sweet.jpl.nasa.gov/2.0/timeGeologic.owl#GeologicTime",
    "codeSpace": "http://sweet.jpl.nasa.gov/2.0/timeGeologic.owl#Era"
  }
}

Listing 7 — A Datastream example for Observations with category values from a predefined code space

{
  "result": "Jurassic",
  "phenomenonTime":  {
    "start": "2021-13-14T15:16:00Z"
  }
}

Listing 8 — An Observation for a Datastream defined in the example above

{
  "name": "Temperature and Pressure",
  "description": "This is a datastream containing temperature and pressure measurement sets.",
  "resultType": {
    "type": "DataRecord",
    "name": "Measurement set",
    "fields": [
      {
        "name": "temp",
        "type": "Quantity",
        "definition": "http://mmisw.org/ont/cf/parameter/air_temperature",
        "label": "Air Temperature",
        "uom": { "code": "Cel", "label": "degree Celsius", "symbol": "°C"  }
      },
      {
        "name": "press",
        "type": "Quantity",
        "definition": "http://mmisw.org/ont/cf/parameter/air_pressure_at_mean_sea_level",
        "label": "Air Pressure",
        "uom": { "code": "mbar", "label": "Millibar", "symbol": "mBar"  }
      }
    ]
  }
}

Listing 9 — A Datastream example measuring multiple observedProperties

{
  "result": {
    "temp": 15,
    "press": 1024
  },
  "phenomenonTime": {
    "start": "2021-13-14T15:16:00Z"
  }
}

Listing 10 — An Observation for a Datastream defined in the example above

7.6.  Sensor

A Sensor is an instrument that observes a property or phenomenon with the goal of producing an estimate of the value of the property

Table 12 — Attributes of a Sensor entity

Table 13 — Direct relation between a Sensor entity and other entity types

Table 14 — Non-exhaustive list of code values used for identifying types for the encodingType of the Sensor entity

The Sensor encodingType allows clients to know how to interpret the metadata value. Currently SensorThings API defines two common Sensor metadata encodingTypes. Most sensor manufacturers provide their sensor datasheets in a PDF format. As a result, PDF is a Sensor encodingType supported by SensorThings API. The second Sensor encodingType is SensorML. Lastly, some sensor datasheets are HTML documents rather than PDFs. Other encodingTypes are permitted (e.g., text/plain). Note that the metadata property may contain either a URL to metadata content (e.g., an https://, ftp://, etc. link to a PDF, SensorML, or HTML document) or the metadata content itself (in the case of text/plain or other encodingTypes that can be represented as valid JSON). It is up to clients to perform string parsing necessary to properly handle metadata content.

{
  "@context": "https://example.org/v2.0/$metadata#Sensors/$entity",
  "@id": "Sensors(1)",
  "id": 1,
  "name": "TMP36",
  "description": "TMP36 - Analog Temperature sensor",
  "encodingType": "application/pdf",
  "metadata": "http://example.org/TMP35_36_37.pdf",
  "Datastreams@navigationLink": "Sensors(1)/Datastreams"
}

Listing 11 — Example of a Sensor entity returned by a HTTP end point.

7.7.  ObservedProperty

An ObservedProperty is a property of a Feature that is being observed by a Sensor, such as temperature, humidity, population count or colour. It should be uniquely identified by its definition, which should point to an external vocabulary by means of a URL, URI or DID.

Table 15 — Attributes of an ObservedProperty entity

Table 16 — Direct relation between an ObservedProperty entity and other entity types

{
  "@context": "https://example.org/v2.0/$metadata#ObservedProperties/$entity",
  "@id": "ObservedProperties(1)",
  "id": 1,
  "name": "DewPoint Temperature",
  "description": "The dewpoint temperature is the temperature to which the
                  air must be cooled, at constant pressure, for dew to form.
                  As the grass and other objects near the ground cool to
                  the dewpoint, some of the water vapor in the atmosphere
                  condenses into liquid water on the objects.",
  "definition": "http://dbpedia.org/page/Dew_point",
  "Datastreams@navigationLink": "ObservedProperties(1)/Datastreams"
}

Listing 12 — Example of an ObservedProperty entity returned by a HTTP end point.

7.8.  Observation

An Observation provides a value for an ObservedProperty of a Feature, as observed by a Sensor. This value can be of any type, as described by the resultType of the Datastream that Observation is associated with.

Table 17 — Attributes of an Observation entity

TM_Object is by default encoded as a complex type with a start (mandatory) and end (optional) attributes of type TM_Instant. This means it can either describe a time instant, when only the start is present, or a time interval with both stand and end are present.

TM_Period is by default encoded as a complex type with a start (mandatory) and end (mandatory) attributes of type TM_Instant. This means it always describes a time interval with fixed starting and ending instants.

Table 18 — Direct relation between an Observation entity and other entity types

An Observation can be directly linked to a Feature, through the relation ProximateFeatureOfInterest. Features linked to an Observation in this way are generally samples, either real, physical ones, like water samples taken from a river, or transient ones, to fix the place that a moving Thing happended to be in, when it made a measurement.

In case the Feature is a domain object, like a river, a building, or a plot of land, the Feature is indirectly linked to the Observation through the UltimateFeatureOfInterest relation on the Datastream. It is also possible for both relations to exist, in which case the ProximateFeatureOfInterest is a sample of the UltimateFeatureOfInterest.

A third case is possible, when the target of the observation is (a sub-part of) the Thing itself. For instance, when the Observation is on the battery-level of a drone. In this case neither the ProximateFeatureOfInterest, nor the UltimateFeatureOfInterest need to be set.

{
  "@context": "https://example.org/v2.0/$metadata#Observations/$entity",
  "@id": "Observations(1)",
  "id": 1,
  "phenomenonTime": {
    "start": "2017-11-12T13:00:00Z",
    "end": "2017-11-12T14:00:00Z"
  },
  "resultTime": "2017-11-12T14:00:00Z",
  "result": 12.5,
  "Datastream@navigationLink": "Observations(1)/Datastream",
  "proximateFeatureOfInterest@navigationLink": "Observations(1)/proximateFeatureOfInterest"
}

Listing 13 — Example of an Observation entity returned by a HTTP end point.

7.9.  Feature

An Observation assigns a value to a property of a subject by applying an ObservingProcedure. The subject is the Feature that can take the role of ProximateFeatureOfInterest or ultimateFeatureOfInterest of the Observation [OGC 20-082r4 and ISO 19156:2023]. In cases where estimating the value of a property of interest is not possible directly, a proxy feature MAY be used. Such an application typically requires Sampling the UltimateFeatureOfInterest such that the observed Feature represents an approximation of the domain feature. In many sensing applications, the Observations’ Feature can be ambiguous with the Location of the Thing. Thus the concept of roles is introduced to better describe the relationship between an Observation and it’s Feature.

Table 19 — Attributes of a Feature entity

Table 20 — Direct relation between a Feature entity and other entity types

{
  "@context": "https://example.org/v2.0/$metadata#Features/$entity",
  "@id": "Features(1)",
  "id": 1,
  "name": "0113700020130227",
  "description": "Water Sample from LA NOYE À DOMMARTIN (80) taken on 2013-02-27 at 10:20:00",
  "encodingType": "application/geo+json",
  "feature": {
    "type": "Point",
    "coordinates": [
      2.38961955,
      49.800951554
    ]
  },
  "FeatureType@navigationLink": "FeaturesOfInterest(1)/FeatureType",
  "Datastreams@navigationLink": "FeaturesOfInterest(1)/Datastreams",
  "Observations@navigationLink": "FeaturesOfInterest(1)/Observations"
}

Listing 14 — Example of a Feature entity using a GeoJSON Geometry.

7.10.  FeatureType

The type or types of each Feature can be specified using the FeatureType class. The definition attribute of the FeatureType should point to an external registry or code list, that defines the Type.

Table 21 — Attributes of a FeatureType entity

Table 22 — Direct relation between a FeatureType entity and other entity types

{
  "@context": "https://example.org/v2.0/$metadata#FeatureType/$entity",
  "@id": "FeatureType(1)",
  "id": 1,
  "name": "Water Sample",
  "description": "A Sample taken from a river, lake or sea",
  "definition": "https://example.org/water_sample",
  "Features@navigationLink": "FeatureType(1)/Features"
}

Listing 15 — Example of a FeatureType entity.

8.1.  OData Entity Model

Every OData service utilizes an entity model which MAY be distributed over several schemas. The service describes this model through a metadata document accessible by a simple HTTP GET request to the <serviceRoot>/$metadata path. This chapter describes an overview of the types of entities in the metadata document that will be used to describe the SensorThings API data model and its data model extensions. The entities listed below are also used to describe the REST and MQTT bindings of the SensorThings API service.

This section is base on:

The entity model consists of the following elements:

Each Entity has a primary key that is composed of one or more of the declared properties of the entity type. Which properties of the Entity Type make up the primary key of the Entity Type is specified in the service metadata document. For the data models specified in this document the primary key is always the field id, though the data type of the field may vary between services. In most cases the primary key field will be server generated at the time an Entity is created, but a service may allow for client-specified primary key fields.

URLs in documents may be absolute or relative. Relative URLs are relative to the context URL in the document, or if there is no context url, relative to the request URL. See https://docs.oasis-open.org/odata/odata-json-format/v4.01/odata-json-format-v4.01.html#sec_RelativeURLs.

Table 23 — Common control annotations

8.2.  OData Common Schema Definition Language

The data model is specified in the metadata document that can be retrieved from the context url. It is described in a machine-readable way using the OData Common Schema Definition Language. See https://docs.oasis-open.org/odata/odata-csdl-json/v4.01/odata-csdl-json-v4.01.html

An example CSDL document describing a service hosting a SensorThings API v2.0 core data model can be found in Annex C. A shortened example with comments can be found in Annex B.

8.3.  URI Patterns

URI Patterns in the SensorThings API consist of three parts: the URI-Root, the resource path and query options. The URI-Root always ends with the version number of the standard, encoded as: "v"majorversionnumber + "." + minorversionnumber. The resource path consists of zero to many parts separated with by the slash (/) character. Resource paths are case sensitive. The query options start with a question mark (?) character. At the top level, query options are separated with the ampersant (&) character.

http://example.org/v2.0/Datastreams(5)/Observations?$orderby=ID&$top=10
_______________________/__________________________/___________________/
          |                          |                      |
  service root URI             resource path           query options

Example 1: Complete URI example using HTTP bindings

base/topic/v2.0/Datastreams(5)/Observations?$orderby=ID&$top=10
_______________/__________________________/___________________/
      |                      |                      |
   root URI            resource path           query options

Example 2: Complete URI example using MQTT bindings

v2.0/Datastreams

v2.0/Datastreams(4)

v2.0/Datastreams('xz42df')

v2.0/Datastreams(4)/name

v2.0/Datastreams(4)/Thing/name

v2.0/Datastreams(4)/name/$value

v2.0/Datastreams(4)/Thing/name/$value

v2.0/Datastreams(4)/Thing

v2.0/Observations(42)/Datastream/Thing

v2.0/Datastreams(4)/Observations

v2.0/Datastreams(4)/Thing/Locations

v2.0/Datastreams(4)/Thing/$ref

v2.0/Datastreams(4)/Observations/$ref

v2.0/Datastreams(4)/Observations(1)/$ref

v2.0/Datastreams(4)/Observations(5321)

8.4.  Encoding rules for constants

Encoding rules for constants in resource paths and query options are listed in Table 24

Table 24 — Encoding rules for constants in requests

8.5.  Requesting Data

This section describes how to read data from a SensorThings API compatible service. Details on how to send requests and how to receive responses are described in the protocol bindings sections. For example, when using the HTTP bindings, GET is used for read requests.

{
  "value": [
    {
      "name": "Things",
      "url": "https://example.org/v2.0/Things"
    },
    {
      "name": "Locations",
      "url": "https://example.org/v2.0/Locations"
    },
    {
      "name": "Datastreams",
      "url": "https://example.org/v2.0/Datastreams"
    },
    {
      "name": "Sensors",
      "url": "https://example.org/v2.0/Sensors"
    },
    {
      "name": "Observations",
      "url": "https://example.org/v2.0/Observations"
    },
    {
      "name": "ObservedProperties",
      "url": "https://example.org/v2.0/ObservedProperties"
    },
    {
      "name": "Features",
      "url": "https://example.org/v2.0/Features"
    },
    {
      "name": "FeatureTypes",
      "url": "https://example.org/v2.0/FeatureTypes"
    }
  ],
  "serverSettings": {
    "conformance": [
        "http://www.opengis.net/spec/sensorthings/2.0/req/datamodel",
        "http://www.opengis.net/spec/sensorthings/2.0/req/resource-path/resource-path-to-entities",
        "http://www.opengis.net/spec/sensorthings/2.0/req/request-data",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-update-delete/create-entity",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-update-delete/link-to-existing-entities",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-update-delete/deep-insert",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-update-delete/deep-insert-status-code",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-update-delete/update-entity",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-update-delete/delete-entity",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-update-delete/historical-location-auto-creation",
        "http://www.opengis.net/spec/sensorthings/2.0/req/create-observations-via-mqtt/observations-creation",
        "http://www.opengis.net/spec/sensorthings/2.0/req/receive-updates-via-mqtt/receive-updates"
    ],
    "http://www.opengis.net/spec/sensorthings/2.0/req/receive-updates-via-mqtt/receive-updates": {
      "endpoints": [
        "mqtt://server.example.com:1833",
        "ws://server.example.com/sensorThings",
      ]
    },
    "http://www.opengis.net/spec/sensorthings/2.0/req/create-observations-via-mqtt/observations-creation": {
      "endpoints": [
        "mqtts://server.example.com:8883",
        "wss://server.example.com:443/sensorThings"
      ]
    }
  }
}

8.6.  Request Query Options

v2.0/Things?$select=id,name

v2.0/Things?$select=distinct:properties/type

{
    "value": [
        { "properties": { "type": "waterBody" } },
        { "properties": { "type": "station" } },
        { "properties": { "type": "aquifer" } }
    ]
}

v2.0/Things?$expand=Datastreams($expand=ObservedProperty)

v2.0/Datastreams?$expand=Observations($select=result,phenomenonTime;$orderby=phenomenonTime desc;$top=1),ObservedProperty

v2.0/Things?$top=5

v2.0/Observations?$top=5&$orderby=phenomenonTime%20desc

v2.0/Things?$skip=5

v2.0/Observations?$skip=2&$top=2&$orderby=resultTime

v2.0/Observations?$orderby=result

v2.0/Observations?$orderby=Datastreams/id desc, phenomenonTime

v2.0/Datastreams(42)/Observations?$filter=result gt 5

v2.0/Locations?$filter=st_within(location, geography'POLYGON ((30 10, 10 20, 20 40, 40 40, 30 10))')

v2.0/Observations?$filter=validTime/start lt 2012-12-03T07:16:23Z

v2.0/Observations?$filter=Datastream/name eq 'Temperature'

v2.0/Observations?$filter=Datastream/Thing/name eq 'House 1'

8.7.  Modifying Data

This section describes how to create, update and delete Entities. Deltails on how to send POST, PATCH, PUT and DELETE requests and how responses are received are described in the protocol bindings sections.

8.8.  JSON-Patch

9.1.  GET

intro text for the requirement class.

Use the following table for Requirements Classes.

9.2.  POST

9.3.  PUT

9.4.  PATCH

9.5.  DELETE

9.6.  HEAD

9.7.  OPTIONS

10.1.  Request / Response

intro text for the requirement class.

Use the following table for Requirements Classes.

10.2.  Publish / Subscribe

11.1.  Request / Response

intro text for the requirement class.

Use the following table for Requirements Classes.

11.2.  Publish / Subscribe

12.1.  Request / Response

intro text for the requirement class.

Use the following table for Requirements Classes.

12.2.  Publish / Subscribe