7.1.1.  Project Outputs

1. An ingestion service designed to publish streams of observations to the D142 Sensor Hub.

2. An information model mapping the observation systems to the OGC SSN ontology identifying compliance and gaps when considering the effect of moving features on these observation systems.

7.2.1.  Harmonization of Sensor Integration Frameworks

OGC maintains several different standards and specifications related to real-world observation systems. The primary work associated with this project centers on two standards:
* the OGC Sensor Web Enablement (SWE) Standards with focus on the joint OGC Semantic Sensor Network (SSN) and W3C SOSA standard as well as the W3C Semantic Sensor Web Ontology (SOSA) Recommendation; and
* the OGC Observations, Measurements, and Samples (OMS v3) draft standard.

SSN and OMS are complementary viewpoints (more information is provided on OMS below). SSN is ‘provider-centric’ and encodes details of the sensing system along with raw observation data. SSN is self-contained and focuses on the set of requirements for data producers. SSN provides extensive support for serialization of numeric data arrays and is particularly optimized for data that includes multiple parallel streams that must be processed together. For example, the data collected by cameras on airborne vehicles must be geo-referenced based on the instantaneous position of the platform and orientation of the camera.

7.2.1.1.  OGC Semantic Sensor Network

The D142 SensorHub platform closely models the ontology of the OGC Semantic Sensor Network. The SSN ontology is built around a central Ontology Design Pattern (ODP) describing the relationships between sensors, stimulus, and observations.

Figure 6 — OGC Semantic Sensor Network Ontology

The ontology can be considered from four main perspectives:

• The Sensor — A perspective with a focus on what a sensor senses and how;

• The Observation — A perspective with a focus on observations and measurements and related metadata;

• The System — A perspective with a focus on systems of sensors and deployments; and,

• The Feature — A perspective focusing on the platform hosting the sensing system or the real-world entity being observed. In this context, it is important to differentiate the former as a Sampling Feature and the latter as a Feature of Interest or Sampled Feature. This is required to bridge the concepts defined by the SSN ontology to the OGC OMS model.

OMS is designed to be more ‘user-centric’ with the target of the observation and the observed property as first-class objects. OMS works at a higher semantic level than SSN and abstracts the concepts of a sensing system, expecting the details to be provided by specific applications and domains. OMS also provides a model for sampling since almost all scientific observations are made on a subset of, or proxy for, the ultimate feature of interest.

For context, the assertion used within this project activity positions the SSN Standard as the foundation for modeling the physical characteristics of an observation system inclusive of the raw observation data while OMS models the use of the observation system to measure the observable properties of real-world features.

A main focus of this project is to identify the opportunity to leverage the Moving Features specification when applied to observation systems managed through the OGC SWE and OMS standards. Of particular interest is whether the Moving Features MF_JSON encoding scheme may be used to represent observation systems in which the sampling features (Observers) move and/or the features of interest are in motion.

7.4.1.  Ocean Vessel Traffic

An AIS monitoring network is responsible for the identification and positioning of ocean vessels and aids to navigation such as shore stations and moored buoys. The AIS Base Station is the primary component in an AIS shore station and is responsible for the transceiving of AIS data from all AIS sources within its area of concern.

Applied to this project, one System record was defined to represent the aggregated AIS data sourced for an area of interest. This System is an abstraction of the complex sensor system used to implement an AIS monitoring network. Each vessel is modelled as a Feature of Interest with its corresponding AIS positioning records modelled as a Datastream of Observations where the Datastream is specific to the cumulative daily geopositioning reports.

This scenario models the use of a stationary feature (the AIS base station) to observe a set of moving features within its coverage area.

7.4.2.  Saildrone USV Monitoring

A Saildrone is an Autonomous Surface Vessel (ASV) equipped with various sensor systems designed to monitor phenomenon related to the marine environment.

NOAA commissioned Saildrone ASVs to monitor the sea surface conditions of the North Atlantic basin. In 2021 and 2022, NOAA created missions to monitor the ocean environment during Hurricane Sam (2021) and Hurricane Fiona (2022). Each of these missions included a number of Saildrone ASVs hosting specific sensing equipment measuring wind speeds, barometric pressure, water temperature, and salinity. The information collected by each mission is made available through the NOAA/PMEL open data portal.

The mission data for 2021 and 2022 is produced as NetCDF files. For each of these files, the format is transformed from NetCDF to the OSH SSN physical model and published to the D142 SensorHub.

Each Saildrone attached to the NOAA mission is modelled as a System with associated properties to identify the ASV’s role, mission, valid time period, and spatial coverage. For each Saildrone, the set of sensing platforms provides environmental observations related to the water column immediately below the ocean surface and the air column immediately above the ocean surface.

Figure 7 — Saildrone Discrete Point Coverage

Each sensing platform records measurements against its respective phenomenon with a nominal sampling schedule. Geopositioning measurements are collected across a continuous curve while environmental sampling uses a discrete sampling schedule. Of note is that each sensing platform has its own sampling schedule independent of the other sensing platforms.

From the perspective of Mission Control, the Feature of Interest is the Saildrone feature itself. The environmental sensing platforms represent Sampling Features against the Phenomenon of the Sampled Feature — the North Atlantic Basin — which also represents the Ultimate Feature of Interest for this project.

This scenario models the use of moving features as observers of a stationary feature of interest with a wide extent and time period. The observations associated with each Saildrone mission represent a Discrete Point Coverage from the ocean’s surface domain. This point coverage of measurements is inclusive of sea surface temperature, salinity, current speed, wave height, and direction as well as wind speed and direction for the air column immediately above the ocean’s surface.

7.4.3.  North Atlantic Ocean Basin

The ultimate feature of interest for this Testbed-18 project is the North Atlantic Ocean. Specifically, the participants were interested in the ingestion of ocean observations related to the ocean surface with the goal of correlating these observations to weather events (Hurricanes) and human activities (Vessel Traffic).

7.5.1.  AIS Vessel Traffic

Vessel traffic is ingested through open source repositories as observations of ocean vessel locations and travel activities. The source of the observations is provided through the AIS messaging system in which an ocean vessel reports its location, speed, course, and heading. These observations are processed to provide insight into the general behavior of ocean vessels within an area of interest.

Figure 8 — Denmark Maritime Authority Vessel Traffic

Vessel traffic is modelled as an observation system. One System_ entity is created representing the Responsible Party, in this case the Denmark Maritime Authority, providing the set of observations within the area of concern for this project. The system has many datastreams of observations with each representing a specific time period (daily) of observations. Each observation provides the geolocation, speed, course, and heading of the vessel at the reported time. Each observation is directly related to one ocean vessel modelled as a feature of interest.

7.5.2.  Saildrone Ocean Observations

A Saildrone is modelled as a Platform hosting a System of Sensors. Each Saildrone has a Deployment specific to a mission sponsored through NOAA for ocean observations. For example, Saildrone 1021 was deployed to the Atlantic Ocean between May 25, 2019 and October 22, 2019 with a mission to collect ocean observation data over a crossing from Bermuda to Lymington, UK with return to Newport, RI.

Mission data for the 2021 Hurricane season is sourced from the NOAA/PMEL open data portal. Saildrone observation data is provided in raw NetCDF format and processed into the D142 SensorHub using the SSN ontology.

7.6.1.  Moving Sampling Features

A sampling feature such as the Saildrone platform creates observations along its trajectory. This series of observations is represented as a Sampling Curve and relate to the coverage area representing the immediate vicinity around the ocean surface over which the Saildrone passes. When considering the North Atlantic Ocean Basin as the ‘ultimate’ feature of interest, the set of observations are relevant only in the context of when and where the observations were made.

The OGC SSN model infers a dependency between the Sampling Feature (Saildrone) and the Feature of Interest (Ocean Basin) through the Datastream entity. The Datastream maintains the Schema for the Observations and defines the observed properties for each Feature of Interest. The issue revolves around the dependency that the Feature of Interest being observed must have all observable properties defined by the Datastream schema. In the case of the Saildrone, in order to properly model the sampling curve, the [latitude, longitude] of each observation must be referenced as part of the observable schema for each Datastream of Observations produced. And yet, the Ocean Basin feature does not have [lat,lon] of the Saildrone trajectory as one of its observable properties.

The second issue related to ‘moving’ sampling features is the cadence of the set of observations. The Saildrone platform has more than one sensing platform. Each sensing platform has a cadence of observations defined by its sampling rate. For example, sea surface temperature may be observed over a 30s interval with 90s elapsed between observations. Air temperature, however, is sensed through a separate device hosted on the Saildrone and is monitored at a difference cadence — 60s on, 240s off, centered at :00. As a result, the SSN datastream model separates each sensing platform based on the nominal sampling schedule of the platform.

Related to the issue of nominal sampling schedules is that the SSN model does not provide a means to identify the specific sampling curve used to sense a phenomenon. In the case of sea surface temperature with a cadence of 12s on, 588s off, centered at :00 — the result observation set is effectively modeled as a time series of observations — one observation every 10 minutes with a time instant result time. Modelling the observation with a time instant value rather than a time period infers that a client application may use the time instant value to locate the position of the observation. This would be an incorrect inference. The observation is actually made through a 12s sensing period which means that the result observation is made over a 12s sampling curve overlapping the Saildrone trajectory. To properly identify the sampling curve, client applications should use the time-start and sampling period to determine the start and stop times of the sampling observation. This time interval can then be used to map against the sampling features trajectory to produce that section of curve representing the sampling area for each observation.

7.6.2.  Moving Features of Interest

Moving features are modelled within the SSN ontology as features of interest. In the case of AIS vessel traffic, each ocean vessel is treated as a feature of interest with the reported [lat,lon] and temporal properties for the course, heading, speed, and rate of turn. With regards to the OGC SSN model, the challenge is that the feature of interest — the ocean vessel — is unknown until its first reported message. This requires the vessel to be registered as a feature of interest on its first report prior to recording the AIS message as an observation. If each ocean vessel was to be registered as a SSN:System, then the full SSN schema would need to be created on first report. The approach taken to mitigate the cost of instantiating a new system for each ocean vessel is to treat the AIS Base Station as the observing system. Effectively, the base station becomes a stationary observation system (Sampling Point) for its coverage area. As a new ocean vessel is observed within the station’s area of interest, the vessel is registered as a feature of interest and each AIS message stored as an observation.

Similarly, Saildrones are managed as a feature of interest with a temporal geometry representing the location of the platform. However, Saildrones do not monitor any temporal properties related to the Saildrone itself. This is managed within SSN as simply a Datastream of positional observations with a simplified schema for its [lat,lon]. As identified in the previous section, the observed properties provided by the Saildrone are related to the North Atlantic Ocean basin. This results in a collection of datastreams where the Saildrone trajectory is stored in the geopositioning datastream for the Saildrone while observed properties are managed as temporal properties stored in separate datastreams. In this context, client applications must have prior knowledge of the use of the SSN System object (Saildrone instance) to tie together the set of disparate environmental observation datastreams.

8.1.1.  Data Ingesters

Several data ingesters were developed during the project to collect data from various data sources.

• Hurricane Tracks obtained from NOAA Office for Coastal Management. This data includes the hurricane center location, as well as wind speed, air pressure, and storm category.

• High Density Observations Bulletin (HDOB) collected by aircrafts and obtained from NOAA Hurricane Center. This data includes aircraft location, as well as geopotential height, air and surface pressure, air temperature, dew point temperature, average and peak wind speeds, and wind direction.

• Automatic Identification System (AIS) data received from ship transponders and used for maritime traffic monitoring. This data was obtained from the NOAA Office for Coastal Management via MarineCadastre.gov and Danish coastal authorities. This data includes vessel location, speed over ground, course over ground, heading, and status code.

• Autonomous Surface Vehicle (ASV or USV) data obtained from Saildrone. This data includes vessel location, speed over ground, course over ground, heading, pitch, roll, and ~20 atmospheric and oceanic variables.

Each data ingester is responsible for pushing feature of interest and observation data to the Sensor Hub in GeoJSON and O&M JSON formats, respectively, following the protocol defined in the draft Connected Systems API (see the next section for details).

8.1.2.  Sensor Hub (Aggregation Layer)

The Sensor Hub receives features of interest and related observations from all data ingesters, saves them in persistent storage, and makes all ingested data available with different protocols and formats.

{
  "type": "Feature",
  "properties": {
    "uid": "urn:x-wmo:storm:2020228N37286",
    "name": "Tropical Storm Kyle",
    "validTime": [
      "2020-08-14T12:00:00Z",
      "2020-08-16T00:00:00Z"
    ]
  }
}

{
  "type": "Feature",
  "properties": {
    "uid": "urn:mrn:x-vessel:338531000",
    "name": "GENESIS VIGILANT",
    "featureType": "http://www.opengis.net/def/featureType/x-T18/Vessel",
    "validTime": [
      "1981-05-22T09:00:00Z",
      "now"
    ],
    "mmsi": "338531000",
    "imo": "IMO8973928",
    "callSign": "WDG9352",
    "vesselType": "Towing",
    "length": 30,
    "width": 10,
    "draft": 5
  }
}

{
  "foi@id": "0hh79ki1f29l8",
  "phenomenonTime": "2020-08-14T12:00:00Z",
  "resultTime": "2020-08-14T12:00:00Z",
  "result": {
    "location": {
      "lat": 36.6,
      "lon": -74.2
    },
    "windSpeed": 35,
    "minPressure": 1008.0,
    "category": "TS"
  }
}

{
  "datastream@id": "tm3kijpkaoei6",
  "obsFormat": "application/om+json",
  "resultSchema": {
    "type": "DataRecord",
    "label": "Storm Observations",
    "fields": [
      {
        "name": "location",
        "type": "Vector",
        "definition": "http://sensorml.com/ont/swe/property/Location",
        "referenceFrame": "http://www.opengis.net/def/crs/EPSG/0/4326",
        "coordinates": [
          {
            "name": "lat",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/GeodeticLatitude",
            "axisID": "Lat",
            "label": "Geodetic Latitude",
            "uom": {
              "code": "deg"
            }
          },
          {
            "name": "lon",
            "type": "Quantity",
            "definition": "http://sensorml.com/ont/swe/property/Longitude",
            "axisID": "Lon",
            "label": "Longitude",
            "uom": {
              "code": "deg"
            }
          }
        ]
      },
      {
        "name": "windSpeed",
        "type": "Quantity",
        "definition": "http://mmisw.org/ont/cf/parameter/wind_speed",
        "label": "Maximum Wind Speed",
        "description": "Maximum sustained winds",
        "uom": {
          "code": "[kn_i]"
        }
      },
      {
        "name": "minPressure",
        "type": "Quantity",
        "definition": "http://mmisw.org/ont/cf/parameter/air_pressure",
        "label": "Minimum Pressure",
        "uom": {
          "code": "mbar"
        }
      },
      {
        "name": "category",
        "type": "Category",
        "definition": "http://sensorml.com/ont/T18/concepts/StormCategory",
        "label": "Storm Category",
        "codeSpace": {
          "href": "http://sensorml.com/ont/T18/concepts/SaffirSimpsonScale"
        },
        "constraint": {
          "type": "AllowedTokens",
          "values": ["TD","TS","H1","H2","H3","H4","H5"]
        }
      }
    ]
  }
}

{
  "items": [
    {
      "type": "Feature",
      "id": "p96kqua33r1n2",
      "properties": {
        "uid": "urn:osh:foi:vessel:367533290",
        "featureType": "http://www.opengis.net/def/featureType/x-T18/Vessel",
        "name": "MARIE CHERAMIE",
        "description": "Proxy feature for vessel 367533290",
        "mmsi": "367533290",
        "imo": "IMO8964862",
        "callSign": "WDG4131",
        "vesselType": "Other",
        "length": 49.0,
        "width": 13.0,
        "draft": 3.1
      }
    },
    ...
  ]
}

{
  "type": "Feature",
  "id": "p96kqua33r1n2",
  "properties": {
    ... same as above ...
  },
  "links": [
    {
      "rel": "temporalGeometries",
      "title": "Temporal Geometries",
      "href": "$root/collections/vessels/items/p96kqua33r1n2/tgeometries"
    },
    {
      "rel": "temporalProperties",
      "title": "Temporal Properties",
      "href": "$root/collections/vessels/items/p96kqua33r1n2/tproperties"
    }
  ]
}

{
  "temporalGeometries": [
    {
      "id": "tg-kuhmds0ib5gd8",
      "type": "MovingPoint",
      "datetimes": [
        "2020-01-01T00:00:07Z",
        "2020-01-01T00:01:08Z",
        "2020-01-01T00:02:18Z",
        ...
      ],
      "coordinates": [
        [ 33.73451, -118.27071 ],
        [ 33.7345, -118.27071 ],
        [ 33.73449, -118.27069 ]
      ],
      "interpolation": "Linear"
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "$root/collections/vessels/items/p96kqua33r1n2/tgeometries?limit=3&offset=3"
    }
  ]
}

{
  "temporalProperties": [
    {
      "datetimes": [
        "2020-01-01T00:00:07Z",
        "2020-01-01T00:01:08Z",
        "2020-01-01T00:02:18Z"
      ],
      "sog": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/SpeedOverGround",
        "description": "Vessel speed relative to ground",
        "interpolation": "Linear",
        "values": [ 0.0, 0.0, 0.0 ]
      },
      "cog": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/CourseOverGround",
        "description": "Vessel travel direction relative to ground",
        "interpolation": "Linear",
        "values": [ 280.4, 274.5, 260.33 ]
      },
      "heading": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/TrueHeading",
        "description": "Vessel heading direction relative to true north, measured clockwise",
        "interpolation": "Linear",
        "values": [ 511.0, 511.0, 511.03 ]
      },
      "status": {
        "type": "TText",
        "form": "http://sensorml.com/ont/x-ais/property/NavigationStatus",
        "description": "Vessel Status",
        "interpolation": "Linear",
        "values": [ "0", "0", "0" ]
      }
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "$root/collections/vessels/items/p96kqua33r1n2/tproperties?limit=3&offset=3"
    }
  ]
}

8.1.3.  Client Applications

Two of the D143 Client deliverable applications consume data from the Sensor Hub using the Moving Features API. The Clients issue GET requests to retrieve feature collections in GeoJSON format.

Features and Moving Features can also have more static properties.

8.1.4.  Sequence Diagram

The following UML sequence diagram provides more details about the interaction between the different components described in the previous sections.

Figure 12 — Sensor Hub Sequence Diagram

8.2.1.  Definitions

For clarity, this section summaries the definitions of some of the fundamental concepts of the SOSA / SSN model and provides a mapping table to other existing and upcoming OGC information models.

8.2.2.  Application to Testbed-18 Use Cases

The next paragraphs summarize how the different Testbed-18 use cases were implemented.

8.2.3.  Connected Systems API

Testbed-18 has been the opportunity to refine the initial design of the Connected Systems API for which a new OGC Standard Working Group has been formed.

The goals of this new API are the following:

• modernize the existing SWE services using a REST approach;

• fully align with the new OGC API guidelines;

• design as an extension of OGC API — Features;

• better integrate static feature data and bi-directional dynamic (highly time variable) data flows;

• make use of existing data models (SensorML, SWE Common, O&M/OMS);

• support HTTP, Websocket and MQTT protocols; and

• provide efficient binary encodings for high bandwidth sensor data (video, radar, lidar, etc.).

Currently, the API exposes the following resource hierarchy:

Table 10

Some of these resources will provide linking capabilities to other OGC APIs, as explained in the table below.

Table 11

More up-to-date information about OGC API — Connected Systems can be found on the official GitHub repository.

8.2.4.  Using Sampling Features

The Saildrone (and HDOB) use cases highlighted how important the modeling of the Features of Interest is in order to make sense of the data that is being collected without a-priori knowledge of the sensor systems being used.

The Saildrone is an automated marine vehicle that measures its own mechanical state (location, orientation, and velocity) as well as both atmospheric and oceanic parameters. In order to differentiate the intent of the different sensors on-board, multiple features of interest must be defined as follows.

• The Saildrone System is the Feature of Interest for the vessel state observations.

• The Atmosphere is the ultimate Feature of Interest for observations of atmospheric parameters.

• The Ocean is the ultimate feature of interest for observations of water parameters.

However, Saildrones are mobile platforms, which means the on-board sensors are also moving within the atmosphere and the ocean. So, attaching the last two features to the corresponding atmospheric and oceanic observations only provides part of the required information because it does not capture where exactly in the atmosphere or the ocean the observation is made.

Although simply assuming that the user knows the data and can thus imply that the exact location of the observations is provided by the location of the drone platform, providing metadata that clearly describes this fact is preferable. This information would become even more necessary for more complex use cases where profilers or other types of remote sensors are used (e.g., Saildrones can also carry sonar profilers and cameras).

This pattern has been applied with success to static in-situ sensors using the concept of Spatial Sampling Features introduced along with O&M v2. A Spatial Sampling Feature is a type of “proxy feature” that describes a spatial extent within a larger feature that the observation applies to. It thus references a larger feature (i.e., often called a domain feature) and also provides a geometry for a sample taken within this larger feature. In the O&M v2 model, the geometry can be 0D (SamplingPoint), 1D (SamplingCurve, e.g., LineString), 2D (SamplingSurface, e.g., Polygon), or 3D (Sampling Volume, c.f. Testbed-17 for Sphere examples). Note that OMS calls this a Spatial Sample and the standard also defines other types of samples (Statistical Sample, Material Sample, etc.).

The Connected Systems API specification intends to clarify how this existing Spatial Sample model can be used to define Sampling Features whose geometry is defined relative to another feature. This will be helpful for mobile systems since the sampling geometry of such systems typically moves along with the system itself. The key is simply that the sampling feature location is not provided in a geographic coordinate reference system but rather in a local reference system that is attached to the platform and thus moves with it.

The following figure contains annotations overlaid on an original Saildrone diagram to illustrate how sampling features could be used to precisely model the Saildrone use case.

Figure 13 — Saildrone diagram with Sampling Features

The diagram shows different sampling features that are positioned relative to a local reference system whose origin is located at the center of flotation of the vessel. Defining a separate sampling feature for each sensor or group of sensors allows one to specify the exact sampling coordinates but also set different ultimate features of interest (in this case ‘ocean’ or ‘atmosphere’).

The sampling features are further described in the following table:

Table 12

Note: This is a quite realistic model but this level of detail is not always needed. Since the exact location of each sensor may not be significant, a possible simplification could be to use a single sampling feature for all atmospheric parameters.

8.2.5.  Using Deployments

As discussed previously, the Deployment concept is defined in the SOSA/SSN ontology as well as in the upcoming OMS standard. Although it was not part of the Connected Systems API implementation that was used during the Testbed, it is currently being implemented in OpenSensorHub and will be part of the proposed API standard. It was clear during the Testbed that there are many use cases that benefit from using a Deployment instance that is separate from the System, Platform, and Feature of Interest resources.

A Deployment resource is used to provide metadata describing the purpose for deploying a particular observing system at a particular place and time. Creating Deployment resources is especially useful when the same system is deployed multiple times for different purposes. For example, it could describe a particular mission involving one or more mobile sensor systems, a survey/field campaign involving humans, or simply describe that a sensor that is usually not mobile has been moved to a different location.

The plan is to implement the Deployment concept as another kind of Feature in the Connected Systems API, with the following properties containing more information about the deployment.

Table 13

In addition, a Deployment resource has the following sub-resources.

Table 14

* Systems can be deployed on a given Platform (this pattern is often used when the platform is fixed), but Platforms can also be deployed themselves (pattern used for mobile platforms, e.g., drones).

8.2.6.  Detailed System Description

The draft Connected Systems API is designed to let data providers decide the proper level of detail to use when describing observing systems. The data model that was initially used to describe Saildrones during Testbed-18 was purposefully kept simple, as shown on the following UML diagram.

Figure 14 — Saildrone UML Diagram (Simple Metadata)

In this model, each Saildrone vessel is a simple System that references itself as the feature of interest. This model is very simple to implement but fails to capture important metadata about each sensor as well as the ultimate feature of interest for metaocean observables.

Fortunately, an alternative model allowing the provision of much greater detail is also possible and was added to the SensorHub server at the end of the Testbed. The following simplified UML diagram illustrates this model, showing how the Saildrone System can be broken down into different sensor components.

Figure 15 — Saildrone UML Diagram (Advanced Metadata)

In this model, each sensor component produces a different datastream, and observations in each datastream are associated with a different sampling feature located at a specific point on the watercraft. This model provides a much more accurate representation of the actual system.

In addition to the sampling features, more detailed SensorML datasheets have also been created for the platform and its subsystems. The following table provides URLs to the corresponding example resources on the SensorHub:

Table 15

8.3.1.  Data Ingestion

Features of interest, System descriptions, and Observations are ingested into the SensorHub using the Connected Systems API. Various protocols and formats are supported by the API.

Supported resource formats include the following.

• GML or GeoJSON for features of interest

• GeoJSON, SensorML/XML or SensorML/JSON for system descriptions

• O&M/XML, O&M/JSON or SWE Common (CSV, JSON or binary) encoded streams for observations

• SWE Common for commands

Regarding protocols, resources can be inserted using the following.

• HTTP POST (or PUT for updates)

• Incoming WebSocket stream (for observations and commands, add only)

• MQTT Publish (any resource type, add only)

When a given resource is received and parsed without error, it is added to a persistent store using OSH Datastore API. This API is used to abstract various storage backends, ranging from embedded databases to large scale distributed databases.

During the transactional process, an event is also dispatched using the Event Bus so that consumers can be notified that data has been added, modified, or deleted. For observations and commands, real-time consumers can receive data without having to wait for the database to be updated, thus reducing overall latency of the data delivery pipeline. This is particularly useful for data streams with high sampling rate such as video or orientation telemetry.

8.3.2.  Data Retrieval

Once ingested into the system, data is made available via several channels, including the following.

• OGC Sensor Observation Service 2.0 (SOS)

• OGC SensorThings API 1.1 (STA)

• OGC Connected Systems API (draft)

• OGC Moving Features API (draft)

The following protocols are supported for retrieval.

• HTTP and Websocket for SOS

• HTTP and MQTT for SensorThings

• HTTP, Websocket, and MQTT for Connected Systems API

• HTTP for Moving Features API

During Testbed-18, only the Connected Systems API and Moving Features API were used for data retrieval by clients. The same data was exposed via both interfaces.

For the Connected Systems API, the retrieval functionality was supported natively since the same interface was used for ingestion. However, exposing the same data using the Moving Features API was more complex and involved the following process.

1. Every Feature of Interest registered on the SensorHub is exposed as a “Moving Feature” resource through the Moving Feature API. The resulting Moving Features can then be grouped into collections based on any criteria.

2. When temporal properties of a given Moving Feature are requested, all observations (other than location) for the corresponding feature of interest are collected, time matched, and packaged in MF-JSON format in chronological order.

3. When temporal geometries of a given Moving Feature are requested, observations of the feature location are collected and packaged in MF-JSON format. Only point location is supported by the current prototype implementation.

The following filtering capabilities have been implemented in the Moving Feature API prototype.

• Filter moving features by id, UID, keywords, property values, valid time, and spatial extent

• Filter temporal properties by observable and time

8.4.1.  Hurricane Tracks

The first screenshot shows the tracks of two hurricanes that have been selected in the application: Hurricane SAM (2021) and Tropical storm KARL (2016).