Adding Deployment from OMS

[hylkevds]

OMS has the concept of Deployment, that ties a Sensor to a Host. In our current proposal for the DataModel we've also added this class as an EntityType.

Ongoing Discussion:

• Deployment: can we drop the links to Sensor and Thing, reference via Deployment?
  • Deployment doesn’t exist with ex-situ measurements -> we must keep the links to Sensor and Thing
• Do we even need Deployment? Formally, under OMS, one can refactor DS to both ObservationCollection and Deployment
  • The Datastream already links the Sensor to the Thing
  • If the Sensor is moved to another Thing, a new Datastream is created
  • If the Sensor is moved to a different spot on the same Thing, a new Datastream is created
  • The Datastream already has a phenomenonTime that describes over which time span it contains Observations, and thus when it was deployed on the Thing.
  • We could add position information, ideally from GeoPOSE
  • BUT:
  • How to indicate if a DS is still open?
    • Add deploymentTime to DS?
    • Boolean: isActive, deploymentTime is taken from DS phenomenonTime
  • Merging deployment and Datastream doesn’t work nicely in the cases where:
    • A Sensor is re-deployed on the same Host and the same Datastreams are to be reused
    • A Sensor measures multiple ObservedProperties and thus has multiple Datastreams associated with it

[humaidkidwai]

The requirement for Deployment entity stemmed from the idea of including relative postioning information of the Sensor on the Thing as a Datastream is ideally just a collection of Observation.

Though it is possible that the position information (ideally using GeoPose) could be included in the Datastream, excluding Deployment also makes it inefficient to access Sensors deployed at a particular Thing that are not yet producing Datastreams.

A query such as Get all sensors currently deployed at a Thing requires the query to first link the Datastreams associated with the Thing and then fetch the Sensors linked to that Datastream

Another use case, as mentioned, is the redeployment of a Sensor. Writing to the same Datastream is useful when the Sensors are turned/taken off for a while (for any reason, such as maintenance). Having a deployment entity that records this information is useful for better query efficiency

Merging deployment and Datastream doesn’t work nicely in the cases where: A Sensor measures multiple ObservedProperties and thus has multiple Datastreams associated with it

Could you elaborate on this?

[hylkevds]

To keep the core data model as simple as possible, we could put Deployment, ObservingProcedure and FeatureType into a separate extension. Though if we design the conformance classes right this may not be required.

The important part would be that they are not required for passing the conformance tests.

[humaidkidwai]

reason::Deployment, atDepth::Deployment, depthUom::Deployment are context specific. They can be included within the properties::Deployment property as per the requirements of the user. It doesn't seem to be universal. Infact, GeoPose could describe the depth relevant information within the position::Deployment property itself.

[hylkevds]

The image was outdated, depth is now position, though it would probably need an encodingType for the user to know what the position field contains. One could argue reason and description are too similar though.

[hylkevds]

Should Deployment and ObservingProcedure be in core or in an extension? If extension, what do we call it and what else would there be in it? An extension for just those two classes seems odd.

[hylkevds]

At the SWG Telco it was decided to put Deployment and ObservingProcedure in an extension named OM Extension.

[humaidkidwai]

One could argue reason and description are too similar though.

Agreed, reason is redundant

[KathiSchleidt]

I'm looking through the examples for reason provided in the OMS Spec, can split all into a distinct descriptionand reason

EXAMPLE 1 A researcher involved in a biodiversity survey campaign assessing the distribution of selected alien species. The deploymentReason describes the fact that this individual was involved in this campaign for the reason of identifying alien species.

• Description: a biodiversity survey campaign assessing the distribution of selected alien species.
• Reason: identifying alien species

EXAMPLE 2 A sensor is mounted on a building to monitor seismic activities.

• Description: A sensor is mounted on a building
• Reason: to monitor seismic activities

EXAMPLE 3 A new sensor type is rolled out within a regional or thematic network due to new legal reporting requirements.

• Description: A new sensor type is rolled out within a regional or thematic network
• Reason: new legal reporting requirements

In addition, reasonstems from the OMS model, I haven't found a way of saying that OMS:Deployment->reason = STA:Deployment->description

[KathiSchleidt]

On the addition of the position attribute to Deployment, this worries me :(

There are several agreed ways of positioning features within the OGC, e.g.:

• GeoPOSE
• Linear Referencing (ISO 19148)

Not sure how one could utilize GeoPOSE the way you've nested in in the Deployment. I CAN say that the way it's currently set up, there's no relation to 19148 anymore.

Could we please first reflect what existing OGC mechanisms would support this requirement instead of immediately going freestyle?

[humaidkidwai]

Not sure how one could utilize GeoPOSE the way you've nested in in the Deployment.

A ValueCode list of the SDUs from GeoPOSE (Basic_YPR, Basic_Quaternion, Advanced) for the type of position property.

Example: For a position of type Basic_YPR:

{ "position": { "lat": 47.7, "lon": -122.3, "h": 11.5 }, "angles": { "yaw": 5.514456741060452, "pitch": -0.43610515937237904, "roll": 0.0 } }

Since position is already a key in the SDUs of GeoPose, we could rename it to orientation within our Deployment entity