Modeling observation data in SOS (Sensor Observation Service)

Jun 23, 2015

This week NZ Herald published an article
about a device created by an Irish farmer enterpreneur that sends a message to a farmer when the cow is about to give birth.
The device monitors “heightened tail moviment”.

In this post I will try to apply what I am learning following the SOS Tutorial
(the Open Geospatial Consortium standard for Sensor Observation Service). Feel free to drop me a message via
@kinow if you find any mistakes or have any suggestions.

Modeling the tail moviment observation data in SOS

SOS is a standard designed to provide access to observation data. There are several server implementations, such as Kisters KiWIS,
istSOS and 52North SOS.

The standard mentions and utilises several other standards, such as SensorML, WFS, XML, WMS, etc. The SOS Tutorial on
how to model your observation data for SOS starts by defining procedure, observed property, feature of interest,
phenomenon and result times, and the result value.

Let’s try to model the data from the tail moviment sensors in the following table.

Name

Description

Our example

Procedure

The process that has generated the observation, such as a sensor, from the O&M specification. In our example that could be a sensor identification

moocall_001

Observed Property

A property which is observed (look at NASA SWEET ontology for existing values)

Heightned tail moviment

Feature of Interest

A feature that carries the property which is observed

Pregnant cow

Phenomenon and Result Times

The phenomenon time is when the data has been taken, and the result time when it has been created. If both are the same, the resultTime can point to the phenomenonTime

20150623142000

Result value

This is the result of the observation. Can be a OM_Measurement if numeric, OM_TruthObservation, etc (O&M)

3 (supposing we have a scale from 1 to 5)

In the next post I will try to show how to load this model and some dummy data into a fresh installation of
52North SOS server.