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

The 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
* 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 behaviour 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 postitional 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’s transponders and used for maritime traffic monitoring. This data was obtained from 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 definition 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

• Designed 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

• 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 API, 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, 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:

• 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 a sonar profiler 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 relatively 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 details 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 metocean 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 URL 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 are:

• 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:

• 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 new 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:

• 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

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

Figure 18 — Hurricane SAM and Tropical storm KARL

The table on the left allows selection of features of interest for which observations should be added to the map. When a storm is selected, its entire track is displayed on the map using both a polyline and individual markers. The visual style of each marker can be changed according to data values. In this case, a different icon is used depending on the storm category.

When selecting a particular marker, more information about the state of the hurricane at that particular location is shown in the popup at the top right of the screen.

8.4.2.  Maritime Vessel Tracks

The following two screenshots show tracks for marine vessels for which we ingested AIS data during the testbed. The first screenshot shows the track of a towing vessel named “SEASPAN PUSHER”.

Figure 19 — Marine Vessel Tracking

Here again, the left panel allows selection of the features of interest (each vessel is a different feature of interest). The track is shown as a polyline and individual sampling locations (i.e. where measurements were made and transmitted using AIS channel) are represented using a ship icon. Each icon is also oriented according to the heading measurement provided in the data. When clicking on one of these icons, more information about the vessel and the corresponding observation are displayed in the popup at the top left.

The next screenshot shows the same data but for a different ship named “CSL WELLAND”.

Figure 20 — CSL Welland

8.4.3.  Saildrone Tracks

The next examples show the tracks of two different saildrone missions. For the transatlantic mission #1021, only navigation data was ingested in the SensorHub. This data is similar to the AIS vessel data and is displayed on the following screenshot:

Figure 21 — Saildrone Mission 1045

In this case, heading or course data is not provided so it is not possible to orient the ship icon in the correct direction.

9.3.1.  Hurricane collections

The input data as storm collection ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/storms/items?f=application%2Fjson query has the following format:

{
  "items": [
    {
      "type": "Feature",
      "id": "resvipdo9f52u",
      "properties": {
        "uid": "urn:osh:foi:storm:1916181N13281",
        "featureType": "Feature",
        "name": "Tropical Storm UNNAMED_1916181N13281",
        "validTime": [
          "1916-06-28T12:00:00Z",
          "1916-07-10T18:00:00Z"
        ]
      }
    },
    {
      "type": "Feature",
      "id": "31d9u5gf6qveu",
      "properties": {
        "uid": "urn:osh:foi:storm:1859297N20267",
        "featureType": "Feature",
        "name": "Tropical Storm UNNAMED_1859297N20267",
        "validTime": [
          "1859-10-24T00:00:00Z",
          "1859-10-29T18:00:00Z"
        ]
      }
    },
…..
],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/storms/items?offset=100&f=application%2Fjson",
      "type": "application/json"
    }
  ]
}

Each response contains a maximum of 100 items, and if a next node appears between the “links” then the search for the next storm items continues with the url specified in the “href” node

The input data as temporal geometries for storm ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/storms/items/resvipdo9f52u/tgeometries query has the following format:

{
  "temporalGeometries": [
    {
      "id": "tg-tm3kijpkaoei6",
      "type": "MovingPoint",
      "datetimes": [
        "1916-06-28T12:00:00Z",
        "1916-06-28T18:00:00Z",
        "1916-06-29T00:00:00Z",
        "1916-06-29T06:00:00Z",
…..
      ],
      "coordinates": [
        [ 12.5, -79.5 ],
        [ 12.5, -79.8 ],
        [ 12.5, -80.1 ],
        [ 12.5, -80.5 ],
…..
      ],
      "interpolation": "Linear"
    }
  ]
}

The input data as temporal properties for storm ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/storms/items/resvipdo9f52u/tproperties query has the following format:

{
  "temporalProperties": [
    {
      "datetimes": [
        "1916-06-28T12:00:00Z",
        "1916-06-28T18:00:00Z",
        "1916-06-29T00:00:00Z",
        "1916-06-29T06:00:00Z",
…..
      ],
      "windSpeed": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/wind_speed",
        "description": "Maximum sustained winds",
        "interpolation": "Linear",
        "values": [ 25.0, 25.0, 25.0, 25.0, ….]
      },
      "minPressure": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/air_pressure",
        "interpolation": "Linear",
        "values": [ -1.0, -1.0, -1.0, -1.0, ….]
      },
      "category": {
        "type": "TText",
        "form": "http://sensorml.com/ont/T18/concepts/StormCategory",
        "interpolation": "Linear",
        "values": [ "TD", "TD", "TD", "TD", ….]
      }
    }
  ]
}

The input data as vessel collection ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items?f=application%2Fjson query has the following format:

{
  "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": "umlomq0l6bsuq",
      "properties": {
        "uid": "urn:osh:foi:vessel:368011000",
        "featureType": "http://www.opengis.net/def/featureType/x-T18/Vessel",
        "name": "USS KIDD",
        "description": "Proxy feature for vessel 368011000",
        "mmsi": "368011000",
        "imo": "",
        "callSign": "NKID",
        "vesselType": "Other"
      }
    },
…..
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items?offset=100&f=application%2Fjson",
      "type": "application/json"
    }
  ]
}

Each response contains a maximum of 100 items, and if a next node appears between the “links” then the search for the next vessel items continues with the url specified in the “href” node.

The input data as temporal geometries for vessel ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tgeometries query has the following format:

{
  "temporalGeometries": [
    {
      "id": "tg-kuhmds0ib5gd8",
      "type": "MovingPoint",
      "datetimes": [
        "2020-01-01T00:00:07Z",
        "2020-01-01T00:01:17Z",
        "2020-01-01T00:02:27Z",
        "2020-01-01T00:03:37Z",
….
      ],
      "coordinates": [
        [ 47.98258, -122.22902 ],
        [ 47.98255, -122.22893 ],
        [ 47.98257, -122.22893 ],
        [ 47.98255, -122.22897 ],
…..
      ],
      "interpolation": "Linear"
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tgeometries?offset=100",
      "type": "auto"
    }
  ]
}

Each response contains a maximum of 100 observations, and if a next node appears between the “links” then the search for the next vessel item observations continues with the url specified in the “href” node

The input data as temporal properties for vessel ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tproperties query has the following format:

{
  "temporalProperties": [
    {
      "datetimes": [
        "2020-01-01T00:00:07Z",
        "2020-01-01T00:01:17Z",
        "2020-01-01T00:02:27Z",
        "2020-01-01T00:03:37Z",
…..
      ],
      "sog": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/SpeedOverGround",
        "description": "Vessel speed relative to ground",
        "interpolation": "Linear",
        "values": [ 0.5, 0.9, 0.6, 0.3, ….]
      },
      "cog": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/CourseOverGround",
        "description": "Vessel travel direction relative to ground",
        "interpolation": "Linear",
        "values": [ 316.9, 121.7, 121.0, 137.3, ….]
      },
      "heading": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/TrueHeading",
        "description": "Vessel heading direction relative to true north, measured clockwise",
        "interpolation": "Linear",
        "values": [ 216.0, 216.0, 216.0, 216.0, …..]
      },
      "status": {
        "type": "TText",
        "form": "http://sensorml.com/ont/x-ais/property/NavigationStatus",
        "description": "Vessel Status",
        "interpolation": "Linear",
        "values": [ "0", "0", "0", "0", ….]
      }
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tproperties?offset=100",
      "type": "auto"
    }
  ]
}

9.3.2.  Vessel AIS collections

The input data as vessel collection ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items?f=application%2Fjson query has the following format:

{
  "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": "umlomq0l6bsuq",
      "properties": {
        "uid": "urn:osh:foi:vessel:368011000",
        "featureType": "http://www.opengis.net/def/featureType/x-T18/Vessel",
        "name": "USS KIDD",
        "description": "Proxy feature for vessel 368011000",
        "mmsi": "368011000",
        "imo": "",
        "callSign": "NKID",
        "vesselType": "Other"
      }
    },
…..
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items?offset=100&f=application%2Fjson",
      "type": "application/json"
    }
  ]
}

Each response contains a maximum of 100 observations, and if a next node appears between the “links” then the search for the next vessel item observations continues with the url specified in the “href” node

The input data as temporal properties for vessel ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tproperties query has the following format:

{
  "temporalGeometries": [
    {
      "id": "tg-kuhmds0ib5gd8",
      "type": "MovingPoint",
      "datetimes": [
        "2020-01-01T00:00:07Z",
        "2020-01-01T00:01:17Z",
        "2020-01-01T00:02:27Z",
        "2020-01-01T00:03:37Z",
….
      ],
      "coordinates": [
        [ 47.98258, -122.22902 ],
        [ 47.98255, -122.22893 ],
        [ 47.98257, -122.22893 ],
        [ 47.98255, -122.22897 ],
…..
      ],
      "interpolation": "Linear"
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tgeometries?offset=100",
      "type": "auto"
    }
  ]
}

Each response contains a maximum of 100 observations, and if a next node appears between the “links” then the search for the next vessel item observations continues with the url specified in the “href” node

The input data as temporal properties for vessel ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tproperties query has the following format:

{
  "temporalProperties": [
    {
      "datetimes": [
        "2020-01-01T00:00:07Z",
        "2020-01-01T00:01:17Z",
        "2020-01-01T00:02:27Z",
        "2020-01-01T00:03:37Z",
…..
      ],
      "sog": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/SpeedOverGround",
        "description": "Vessel speed relative to ground",
        "interpolation": "Linear",
        "values": [ 0.5, 0.9, 0.6, 0.3, ….]
      },
      "cog": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/CourseOverGround",
        "description": "Vessel travel direction relative to ground",
        "interpolation": "Linear",
        "values": [ 316.9, 121.7, 121.0, 137.3, ….]
      },
      "heading": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/TrueHeading",
        "description": "Vessel heading direction relative to true north, measured clockwise",
        "interpolation": "Linear",
        "values": [ 216.0, 216.0, 216.0, 216.0, …..]
      },
      "status": {
        "type": "TText",
        "form": "http://sensorml.com/ont/x-ais/property/NavigationStatus",
        "description": "Vessel Status",
        "interpolation": "Linear",
        "values": [ "0", "0", "0", "0", ….]
      }
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/vessels/items/umlomq0l6bsuq/tproperties?offset=100",
      "type": "auto"
    }
  ]
}

Each response contains a maximum of 100 observations, and if a next node appears between the “links” then the search for the next vessel item observations continues with the url specified in the “href” node

9.3.3.  Saildrone Collections

The input data as saildrone collection ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/saildrones/items?f=application%2Fjson query has the following format:

{
  "items": [
    {
      "type": "Feature",
      "id": "p7e4barvjhaj2",
      "properties": {
        "uid": "urn:mrn:wmo:1801556",
        "featureType": "http://www.opengis.net/def/featureType/T18/Saildrone",
        "name": "Saildrone 1031",
        "description": "Saildrone Unmanned Surface Vehicle (USV) 1031",
        "validTime": [
          "2022-07-16T20:00:00Z",
          "2022-10-14T09:59:00Z"
        ],
        "mission": "Saildrone Atlantic 2022 Hurricane Monitoring, drone 1031",
        "platformID": "1031"
      }
    },
    {
      "type": "Feature",
      "id": "dpgba35clbhau",
      "properties": {
        "uid": "urn:mrn:noaa:pmel:2021:1045",
        "featureType": "http://www.opengis.net/def/featureType/T18/Saildrone",
        "name": "Saildrone Hurricane Monitoring 2021 NRT data, drone 1045",
        "description": "Saildrone Hurricane Monitoring 2021 NRT data, drone 1045",
        "validTime": [
          "2021-10-21T00:00:00Z",
          "2021-10-28T13:59:00Z"
        ]
      }
    },
….
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/saildrones/items?offset=100&f=application%2Fjson",
      "type": "application/json"
    }
  ]
}

Each response contains a maximum of 100 items, and if a next node appears between the “links” then the search for the next saildrone items continues with the url specified in the “href” node

The input data as temporal geometries for Saildrone ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/saildrones/items/dpgba35clbhau/tgeometries query has the following format:

{
  "temporalGeometries": [
    {
      "id": "tg-4knoao0uki8bq",
      "type": "MovingPoint",
      "datetimes": [
        "2021-10-21T00:00:00Z",
        "2021-10-21T00:30:00Z",
        "2021-10-21T01:00:00Z",
        "2021-10-21T02:00:00Z",
….
      ],
      "coordinates": [
        [24.3430336, -61.6090112],
        [24.3401616, -61.61264],
        [24.3387488, -61.6178816],
        [24.3431344, -61.6280896],
….
      ],
      "interpolation": "Linear"
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/saildrones/items/ dpgba35clbhau/tgeometries?offset=100",
      "type": "auto"
    }
  ]
}

Each response contains a maximum of 100 observations, and if a next node appears between the “links” then the search for the next Saildrone item observations continues with the url specified in the “href” node

The input data as temporal properties for Saildrone ID returned by the https://api.georobotix.io/ogc/t18/mfapi/collections/saildrones/items/dpgba35clbhau/tproperties query has the following format:

{
  "temporalProperties": [
    {
      "datetimes": [
        "2021-10-21T00:00:00Z",
        "2021-10-21T00:30:00Z",
        "2021-10-21T01:00:00Z",
        "2021-10-21T02:00:00Z",
…..
      ],
      "TEMP_AIR_MEAN": {
        "type": "TDouble",
        "form": "",
        "description": "Mean Air Temperature",
        "interpolation": "Linear",
        "values": [27.58, 27.47, 27.41, 27.15,…]
      },
      "RH_MEAN": {
        "type": "TDouble",
        "form": "",
        "description": "Relative humidity",
        "interpolation": "Linear",
        "values": [79.38, 81.23, 80.71, 82.44,….]
      },
      "BARO_PRES_MEAN": {
        "type": "TDouble",
        "form": "",
        "description": "Air pressure",
        "interpolation": "Linear",
        "values": [1019.44, 1019.65, 1019.73, 1019.7,….]
      },
      "TEMP_SBE37_MEAN": {
        "type": "TDouble",
        "form": "",
        "description": "Seawater temperature",
        "interpolation": "Linear",
        "values": [28.3778, 28.4097, 28.4121, 28.3226,….]
      },
      "WIND_FROM_MEAN": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/wind_from_direction",
        "description": "Wind Direction",
        "interpolation": "Linear",
        "values": [79.9, 76.7, 95.9, 115.8,….]
      },
      "WIND_SPEED_MEAN": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/wind_speed",
        "description": "Wind speed nominal_sampling_schedule: 60s on, 240s off, centered at :00",
        "interpolation": "Linear",
        "values": [4.67, 5.09, 5.45, 3.74,….]
      },
      "SAL_SBE37_MEAN": {
        "type": "TDouble",
        "form": "",
        "description": "Seawater salinity",
        "interpolation": "Linear",
        "values": [36.5952, 36.5911, 36.5926, 36.6004,….]
      },
      "WATER_CURRENT_SPEED_MEAN": {
        "type": "TDouble",
        "form": "",
        "description": "Speed of water current",
        "interpolation": "Linear",
        "values": [0.4, 0.388, 0.282, 0.269,…]
      },
      "WATER_CURRENT_DIRECTION_MEAN": {
        "type": "TDouble",
        "form": "",
        "description": "Direction of water current",
        "interpolation": "Linear",
        "values": [158.7, 159.3, 160.7, 190.6,….]
      },
      "WAVE_DOMINANT_PERIOD": {
        "type": "TDouble",
        "form": "",
        "description": "Dominant wave period",
        "interpolation": "Linear",
        "values": [9.85, 9.85, 9.14, 9.14,….]
      },
      "WAVE_SIGNIFICANT_HEIGHT": {
        "type": "TDouble",
        "form": "",
        "description": "Significant wave height",
        "interpolation": "Linear",
        "values": [1.457, 1.456, 1.574, 1.442,….]
      }
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/saildrones/items/dpgba35clbhau/tproperties?offset=100",
      "type": "auto"
    }
  ]
}

Each response contains a maximum of 100 observations, and if a next node appears between the “links” then the search for the next saildrone item observations continues with the url specified in the “href” node

The server also provides another type of saildrone item, i.e. with different properties, and precisely the following type:

"SOG": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/SpeedOverGround",
        "description": "Vessel speed relative to ground",
        "interpolation": "Linear",
        "values": [0.023, 0.006, 0.907, 0.651,…]
      },
      "COG": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/CourseOverGround",
        "description": "Vessel travel direction relative to ground",
        "interpolation": "Linear",
        "values": [143.6, 329.9, 93.9, 4.9,…]
      },
      "HDG": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/TrueHeading",
        "description": "Vessel heading direction relative to true north, measured clockwise",
        "interpolation": "Linear",
        "values": [-1.0, -1.0, -1.0, -1.0,…]
      },
      "HDG_WING": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/WingHeading",
        "description": "Direction of wing relative to true north, measured clockwise",
        "interpolation": "Linear",
        "values": [256.7, 18.4, 333.6, 260.8,…]
      },
      "WING_ANGLE": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/WingAngle",
        "description": "Angle of the wing",
        "interpolation": "Linear",
        "values": [-84.7, 23.3, -131.2, -122.7,…]
      },
      "PITCH": {
        "type": "TDouble",
        "form": " http://sensorml.com/ont/swe/property/PitchAngle",
        "description": "Vessel pitch angle w.r.t to the local horizontal plane",
        "interpolation": "Linear",
        "values": [-1.0, -1.0, -1.0, -1.0,…]
      },
      "ROLL": {
        "type": "TDouble",
        "form": "http://sensorml.com/ont/swe/property/RollAngle",
        "description": "Vessel roll angle w.r.t to the local horizontal plane",
        "interpolation": "Linear",
        "values": [-1.0, -1.0, -1.0, -1.0,…]
      },
      "STATUS": {
        "type": "TText",
        "form": "http://sensorml.com/ont/ais/property/NavigationStatus",
        "description": "Vessel Status",
        "interpolation": "Linear",
        "values": ["-1", "-1", "-1", "-1",…]
      }

The client allows recognition of both types of saildrone items. Therefore, it allows the correct management and visualization of data, geometries, and properties of different types.

10.1.1.  Background

Our approach to address the needs for the shared use of our ocean resources is to make Marine Spatial Planning a core foundation on which to build out vertical applications. Our platform is based on a federated information model represented as a unified social graph. This provides a decentralized approach towards designing various data streams each represented by their well-known and/or standardized model. To date, service layers based on the OGC standards for Feature, Observations & Measurements, and Sensors APIs have been developed and extended for adoption within the marine domain. Previous work provides for data discovery and processing of features based on the IHO S-100 standard (Marine Protected Areas, Marine Traffic Management, …); as well as connected observation systems as provided by NOAA’s Integrated Ocean Observing System (IOOS) and its Canadian variant, CIOOS.

This project extends the core federated model to leverage the Moving Features specification to implement service endpoints for the NOAA open data pipelines for major weather events (Hurricane Tracking, Ocean Drifters, Saildrones …) and AIS vessel traffic monitoring as provided through the Denmark Maritime Authority.

10.2.1.  Feature model

10.3.1.  Baltic/North Sea Vessel Traffic

AIS Vessel traffic is of global concern. According to the World Bank, the volume of ship traffic on any day exceeds well over 100,000 active voyages and is a direct performance indicator of global economic trade. However, from the perspective of managing vessel traffic as it affects an area of interest, the responsiblity falls to the regional maritime authority. In this scenario, we model the Danish Maritime Authority as the Responsible Party for vessel traffic within the Baltic/North Sea.

{'uid': 'urn:mrn:itu:mmsi:642122020',
 'featureType': 'http://www.opengis.net/def/featureType/T18/Vessel',
 'name': 'ALHANI',
 'description': '',
 'validTime': ['2022-05-14T00:00:00Z', '2022-05-14T23:59:59Z'],
 'mmsi': '642122020',
 'imo': '9331153',
 'callSign': '5AXF',
 'shipType': 'Tanker',
 'cargoType': 'No additional information',
 'length': 249.0,
 'width': 44.0,
 'draft': 7.7}

link: temporalGeometry

[{'id': 'tg-44l1f3rcki3l6',
  'type': 'MovingPoint',
  'datetimes': ['2022-05-14T00:02:54Z',
   '2022-05-14T00:03:02Z',
   '2022-05-14T00:03:11Z',
   '2022-05-14T00:03:22Z',
   '2022-05-14T00:03:33Z',
   '2022-05-14T00:03:42Z',

   ...

   '2022-05-14T00:09:12Z',
   '2022-05-14T00:09:21Z',
   '2022-05-14T00:09:32Z',
   '2022-05-14T00:09:43Z'],
  'coordinates': [[56.120763, 12.514048],
   [56.120427, 12.514782],
   [56.120122, 12.515447],
   [56.11976, 12.516273],
   [56.11943, 12.517032],
   [56.119123, 12.517703],

   ...

   [56.106298, 12.544985],
   [56.10592, 12.545745],
   [56.105498, 12.546588],
   [56.105022, 12.5475]],
  'interpolation': 'Linear'}]

link: temporalPropertiesCollection

[{'datetimes': [
   '2022-05-14T00:02:54Z',
   '2022-05-14T00:03:02Z',
   '2022-05-14T00:03:11Z',
   '2022-05-14T00:03:22Z',
   '2022-05-14T00:03:33Z',
   ...
   '2022-05-14T00:09:12Z',
   '2022-05-14T00:09:21Z',
   '2022-05-14T00:09:32Z',
   '2022-05-14T00:09:43Z'],
  'sog': {'type': 'TDouble',
   'form': 'http://sensorml.com/ont/swe/property/SpeedOverGround',
   'description': 'Vessel speed relative to ground',
   'interpolation': 'Linear',
   'values': [
    11.4,
    11.5,
    11.5,
    11.6,
    11.7,
    ...
    13.7,
    13.7,
    13.7,
    13.7]},
  'cog': {'type': 'TDouble',
   'form': 'http://sensorml.com/ont/swe/property/CourseOverGround',
   'description': 'Vessel travel direction relative to ground',
   'interpolation': 'Linear',
   'values': [
    129.3,
    129.3,
    129.2,
    129.4,
    129.5,
    ...
    132.2,
    131.7,
    132.1,
    132.9]},
  'heading': {'type': 'TDouble',
   'form': 'http://sensorml.com/ont/swe/property/TrueHeading',
   'description': 'Vessel heading direction relative to true north, measured clockwise',
   'interpolation': 'Linear',
   'values': [
    129.0,
    129.0,
    129.0,
    129.0,
    129.0,
    ...
    132.0,
    132.0,
    133.0,
    132.0]},
  'rot': {'type': 'TDouble',
   'form': 'http://sensorml.com/ont/swe/property/RateOfTurn',
   'description': 'The rate of turn (ROT) or angular velocity of the ship',
   'interpolation': 'Linear',
   'values': [
    0.4,
    0.0,
    0.0,
    0.4,
    0.0,
    ...
    -3.6,
    2.9,
    -0.7,
    -3.6]},
  'status': {'type': 'TText',
   'form': 'http://sensorml.com/ont/ais/property/NavigationStatus',
   'description': 'Vessel Status',
   'interpolation': 'Linear',
   'values': [
    'Under way using engine',
    'Under way using engine',
    'Under way using engine',
    'Under way using engine',
    'Under way using engine',
    ...
    'Under way using engine',
    'Under way using engine',
    'Under way using engine',
    'Under way using engine']}}]

10.3.2.  NOAA Ocean Observation System — 2021 Hurricane Season

This scenario focuses on the NOAA observation system in place for the 2021 Hurricane Season. Saildrones were deployed to the North Atlantic to monitor ocean conditions relevant to major weather events. NOAA is the responsible party for managing the observation stream provisioned through each Saildrone platform.

link: temporalGeometry

{'temporalGeometries':
  [{'id': 'tg-7ghcsqq1f1jfi',
   'type': 'MovingPoint',
   'datetimes': [
    '2021-10-29T00:00:00Z',
    '2021-10-29T00:30:00Z',
    '2021-10-29T01:00:00Z',
    '2021-10-29T01:24:00Z',
    '2021-10-29T01:54:00Z',
    ...
    '2021-10-30T22:00:00Z',
    '2021-10-30T22:30:00Z',
    '2021-10-30T23:00:00Z',
    '2021-10-30T23:24:00Z'],
   'coordinates': [
    [34.7411872, -76.0770688],
    [34.7448704, -76.0758656],
    [34.7483968, -76.0736768],
    [34.7510592, -76.0718848],
    [34.753872, -76.0688832],
    ...
    [34.7464, -76.1448448],
    [34.7394144, -76.14592],
    [34.7397824, -76.1432064],
    [34.751056, -76.1286272]],
   'interpolation': 'Linear'}]}

link: temporalPropertiesCollection

[{'datetimes': [
   '2021-10-29T00:00:00Z',
   '2021-10-29T00:30:00Z',
   '2021-10-29T01:00:00Z',
   '2021-10-29T01:24:00Z',
   '2021-10-29T01:54:00Z',
   ...
   '2021-10-30T22:00:00Z',
   '2021-10-30T22:30:00Z',
   '2021-10-30T23:00:00Z',
   '2021-10-30T23:24:00Z'],
  'TEMP_AIR_MEAN': {'type': 'TDouble',
   'form': '',
   'description': 'Mean Air Temperature',
   'interpolation': 'Linear',
   'values': [
    21.08,
    21.73,
    22.09,
    22.12,
    22.31,
    ...
    19.45,
    19.31,
    19.15,
    19.23]},
  'RH_MEAN': {'type': 'TDouble',
   'form': '',
   'description': 'Relative humidity',
   'interpolation': 'Linear',
   'values': [77.09,
    79.21,
    74.05,
    76.38,
    74.52,
    ...
    65.22,
    62.19,
    61.83,
    62.73]},
  'BARO_PRES_MEAN': {'type': 'TDouble',
   'form': '',
   'description': 'Air pressure',
   'interpolation': 'Linear',
   'values': [
    1009.33,
    1008.9,
    1008.46,
    1008.1,
    1007.9,
    ...
    1002.62,
    1002.76,
    1003.21,
    1003.33]},
  'TEMP_SBE37_MEAN': {'type': 'TDouble',
   'form': '',
   'description': 'Seawater temperature',
   'interpolation': 'Linear',
   'values': [
    23.5597,
    23.6702,
    23.8158,
    23.8885,
    23.9358,
    ...
    23.1876,
    23.0885,
    23.0781,
    23.2082]},
  'SAL_SBE37_MEAN': {'type': 'TDouble',
   'form': '',
   'description': 'Seawater salinity',
   'interpolation': 'Linear',
   'values': [
    34.8257,
    34.882,
    34.9626,
    34.992,
    35.0063,
    ...
    35.2432,
    35.2798,
    35.2796,
    35.2143]},
  'WIND_FROM_MEAN': {'type': 'TDouble',
   'form': 'http://mmisw.org/ont/cf/parameter/wind_from_direction',
   'description': 'Wind Direction',
   'interpolation': 'Linear',
   'values': [
    108.5,
    106.9,
    119.0,
    114.4,
    116.5,
    ...
    266.4,
    259.8,
    264.8,
    261.0]},
  'WIND_SPEED_MEAN': {'type': 'TDouble',
   'form': 'http://mmisw.org/ont/cf/parameter/wind_speed',
   'description': 'Wind speed nominal_sampling_schedule: 60s on, 240s off, centered at :00',
   'interpolation': 'Linear',
   'values': [
    8.14,
    9.84,
    9.66,
    8.41,
    9.66,
    ...
    8.72,
    8.75,
    7.22,
    8.37]},
  'WATER_CURRENT_SPEED_MEAN': {'type': 'TDouble',
   'form': '',
   'description': 'Speed of water current',
   'interpolation': 'Linear',
   'values': [
    0.313,
    0.32,
    0.298,
    0.336,
    0.289,
    ...
    0.115,
    0.132,
    0.145,
    0.138]},
  'WATER_CURRENT_DIRECTION_MEAN': {'type': 'TDouble',
   'form': '',
   'description': 'Direction of water current',
   'interpolation': 'Linear',
   'values': [
    252.8,
    249.5,
    250.1,
    251.2,
    248.8,
    ...
    61.3,
    77.0,
    61.0,
    69.8]},
  'WAVE_DOMINANT_PERIOD': {'type': 'TDouble',
   'form': '',
   'description': 'Dominant wave period',
   'interpolation': 'Linear',
   'values': [
    12.8,
    12.8,
    3.76,
    3.76,
    4.0,
    ...
    12.8,
    12.8,
    12.8,
    12.8]},
  'WAVE_SIGNIFICANT_HEIGHT': {'type': 'TDouble',
   'form': '',
   'description': 'Significant wave height',
   'interpolation': 'Linear',
   'values': [0.896,
    0.878,
    0.85,
    0.85,
    0.863,
    0.953,
    ...
    1.64,
    1.514,
    1.547,
    1.547]}}]

11.3.1.  Web Implementation

An initial demonstration was created to display a 3D compass in a web page that mimics a gimballed compass designed for use on ships and aircraft by compensating for their pitch and roll. This demo combines data streamed from multiple sensors on a mobile device to calculate orientation using W3C Geo-alignment features and displays the correct heading in a web browser regardless of the device’s attitude.

This implementation works well when the device is either held flat in the horizontal plane or viewed vertically in portrait mode. However, the heading is incorrect when the device is viewed in landscape mode as the direction indicator remains aligned with the short edge of the screen which is pointing to the left (or right) of the observer in this case. Although technically still correct, this is misleading and unhelpful to the user.

Figure 48 — 3D Compass Web Page With Fixed Heading Indicator

To address this issue, the direction indicator was redesigned to float upwards and remain aligned with the top of the screen regardless of the device’s orientation. The resultant heading is correct in both portrait and landscape modes, and transitions smoothly between these two states.

Figure 49 — 3D Compass Web Page With Floating Heading Indicator

The demo also highlighted that care is needed to correctly calculate heading when the device is inverted — such that the display is facing downwards with the user observing from below — since bearings are measured counterclockwise rather than in the customary clockwise direction.

Figure 50 — 3D Compass Web Page Inverted Display

11.3.2.  Mobile App Implementation

The 3D compass demo was ported to a native mobile app for Android devices in order to allow more autonomous operation by eliminating the requirement for web connectivity. Support is provided for both fixed and floating heading indicators which are better suited to horizontal and vertical device operation respectively.

Figure 51 — 3D Compass Mobile App For Android

Development of the native app identified an anomoly whereby code written for the web API produced different results under the Android operating system on the same host device. This decrepancy was traced to a difference in the ranges for yaw, pitch and roll angles under the two systems, which highlighted a wider issue.

The full range of orientations can be described using a only subset of the full range of angles. For instance:

• yaw can equate to compass heading in the range [0, 360);

• pitch can be limited to the subset between straight up and straight down in the range [-90, 90];

• roll can determine rotation from vertical, where zero represents upright, clockwise rotations extend to upside-down at 180 degrees and anticlockwise rotations end similarly at -180 degrees, resulting in a full range of (-180, 180].

Choosing the above ranges produces a simple mapping in which heading equates to yaw angle and inversion is determined purely from roll angle when pitch angles are limited to half of their full 360 degree range. However, symmetry ensures that there are two alternative schemes where either roll or yaw angles are limited to half their full range and still allow the full range of orientations to be defined.

Table 16 — Limited Angle Ranges Permitting Full Orientation Range

Pitch angles in the ranges (-180, -90) and (90, 180] are valid, though these duplicate other orientations and are incompatible with the simple mapping described above. Hence the full ranges of yaw, pitch and roll angles should be taken into account when calculating heading and inversion since failure to consider such cases can lead to incorrect results.

A snapshot feature was added to the app that assembles location and orientation data from the device’s sensors into an instantaneous GeoPose JSON. This can be copied to the device’s clipboard in several formats including Basic-Euler, Basic-Quaternion and Advanced in order to share the captured GeoPose data with other applications.

Figure 52 — 3D Compass Mobile App GeoPose Snapshot

GeoPose syntax compliance was verified using a prototype Swagger validator tool.

13.1.1.  Ingestion Service

The moving feature collection system for Hurricane tracking use case integrates moving features with static features including time, wind speed, air pressure, and category so that each static feature is attached with the “moving attribute”. It supports the interoperability between multiple sensors so that we can identify different static features at different locations. It also lays solid foundation for visualizing enriched information associated with the moving feature. The integrated features which are pushed into the Sensor Hub can be retrieved through a publish-subscribe message service via HTTP. It also enhances the reproduction of multi-sensor integration and information retrieval. Furthermore, applying the integration to the hurricane tracking use case helps timely disaster response and provides comprehensive information for disaster mitigation.

13.1.2.  Sensorhub

A better alignment of the SensorWeb API with “OGC API — Features” made sense since observation systems and features of interest are also regular features and can have a (summary) GeoJSON and/or JSON-FG representations. Hence the idea of the new “OGC API — Connected Systems”, that will be much better integrated with the rest of the OGC API ecosystem.

It is possible to implement conversion from SWE/O&M data model to Moving Feature data model on the fly, while maintaining semantic information about the temporal variables.

It is also possible to generate a snapshot of time varying features of interest at a point in time using dynamic information from observations.

Limitations of MF-API / MF-JSON syntax when several feature properties are observed at different times (such as by different sensors, at different sampling rates, etc.) and so forth.

13.1.3.  Client

The client and other deliverables work well together. However, there is an improvement that can be made in Sensorhub. The only observations are in terms of data management relating to the same type of feature of interest such as the Saildrones.
The saildrone 1021 has different temporal properties than other saildrones. This is justified by them having different types of sensors. The D143 Superelectric Client has been implemented in order to manage these different types of observational data. Another useful observation is on the right data fusion for the storms, where the HDOB type data has been inserted as an additional element of the “temporalGeometries” array, differentiating them with the “id”.

Per the temporal geometries:

{
  "temporalGeometries": [
    {
      "id": "tg-7k7p48g374pbu",
      "type": "MovingPoint",
      "datetimes": [
        "2022-09-15T13:20:00Z",
        "2022-09-15T13:20:30Z",
        "2022-09-15T13:21:00Z",
        "2022-09-15T13:21:30Z",
	….
      ],
      "coordinates": [
        [12.2, -69.0],
        [12.2, -69.0],
        [12.2, -69.0],
        [12.2, -69.0],
	….
      ],
      "interpolation": "Linear"
    },
    {
      "id": "tg-tm3kijpkaoei6",
      "type": "MovingPoint",
      "datetimes": [
        "2022-09-14T12:00:00Z",
        "2022-09-14T18:00:00Z",
        "2022-09-15T00:00:00Z",
        "2022-09-15T06:00:00Z",
        "2022-09-15T12:00:00Z"
      ],
      "coordinates": [
        [16.4, -49.1],
        [16.6, -50.1],
        [16.6, -51.3],
        [16.5, -52.4],
        [16.4, -53.6]
      ],
      "interpolation": "Linear"
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/storms/items/sfmhi32ege8fm/tgeometries?offset=100",
      "type": "auto"
    }
  ]
}

Figure 53

Which unfortunately did not happen with the “temporalProperties”, where the “id” is not reported:

{
  "temporalProperties": [
    {
      "datetimes": [
        "2022-09-15T13:20:00Z",
        "2022-09-15T13:20:30Z",
        "2022-09-15T13:21:00Z",
        "2022-09-15T13:21:30Z",
	….
      ],
      "aircraft_number": {
        "type": "TText",
        "form": "https://dbpedia.org/page/Aircraft_registration",
        "interpolation": "Linear",
        "values": ["AF303", "AF303", "AF303", "AF303", ….]
      },
      "geopotential_height": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/geopotential_height",
        "interpolation": "Linear",
        "values": [NaN, NaN, NaN, NaN,….]
      },
….
….
      "rain_rate": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/rainfall_rate",
        "interpolation": "Linear",
        "values": [NaN, NaN, NaN, NaN,]
      }
    },
    {
      "datetimes": [
        "2022-09-14T12:00:00Z",
        "2022-09-14T18:00:00Z",
        "2022-09-15T00:00:00Z",
        "2022-09-15T06:00:00Z",
        "2022-09-15T12:00:00Z"
      ],
      "windSpeed": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/wind_speed",
        "description": "Maximum sustained winds",
        "interpolation": "Linear",
        "values": [30.0, 35.0, 45.0, 45.0, 45.0]
      },
      "minPressure": {
        "type": "TDouble",
        "form": "http://mmisw.org/ont/cf/parameter/air_pressure",
        "interpolation": "Linear",
        "values": [1009.0, 1006.0, 1002.0, 1002.0, 1002.0]
      },
      "category": {
        "type": "TText",
        "form": "http://sensorml.com/ont/T18/concepts/StormCategory",
        "interpolation": "Linear",
        "values": ["TD", "TS", "TS", "TS", "TS"]
      }
    }
  ],
  "links": [
    {
      "rel": "next",
      "href": "https://api.georobotix.io/ogc/t18/mfapi/collections/storms/items/sfmhi32ege8fm/tproperties?offset=100",
      "type": "auto"
    }
  ]
}

Figure 54

This issue has created a problem in the client by proceeding with a work around to make up for this lack. From the point of view of the client, it would be appropriate to homogenize the data as was done for the hurricane HDOBs data, with the difference of adding the “id” also for the temporal properties. It would be appropriate that the same thing could be implemented for the Saildrones as well.

13.2.1.  Ingestion service

In the future, we will endeavor to work on real-time moving feature integration. There are two future work that we will put effort on:

1. We will endeavor to integrate moving features with static features for more sensors. Enriched information will be organized in a unified, lightweight, and compact data file. The integration of real-time heterogeneous data along with the moving features also needs to receive more attention. Sometimes, real-time information is more valuable than historical information for prompt decision making, especially in disaster events. For example, when a disaster happens, real-time information integration enables decision-making departments to comprehensively understand the situation that occurred in the current location so that timely response and actions will be taken to mitigate the damage.

13.2.2.  Sensorhub

Work on the Connected Systems API at OGC. A SWG has been formed to work on a draft version of this API. Better document and provide implementation guidelines for features of interest (sampling features) attached to moving platforms

13.2.3.  GeoPose: Multi-Camera Video Analysis

Collaborative plans have been made to record geotagged video data using a StreetDrone Twizy autonomous vehicle operated by Ordnance Survey at their headquarters in Southampton, UK. Similar data were used to track a cyclist from a moving vehicle by calculating GeoPose in Testbed-17 Moving Features.

Figure 55 — StreetDrone Vehicle Operated By Ordnance Survey

The aim is to capture video from front- and rear-facing cameras aboard the vehicle concurrently with footage from multiple static locations. Code from Testbed-18 3D compass demos can be integrated with Away Team’s TrkdCam app to record geotagged video with camera orientation using smartphones as roadside cameras. The resultant data set should be suitable for demonstrating the essential elements of the road network use cases previously described, and could be extended to include streaming data for real-time use cases.

13.2.4.  Client

Possible future developments could concern the final use by identifying as stack holders those users and/or security departments for monitoring of critical events such as the occurrence of hurricanes, with the possibility of adding trajectory prediction and perhaps being able to warn immediately all subjects in danger, such as ships and aircraft. Naturally this implies the management of real-time dynamic data flows coming from different sources “ingesters”.