Modeling observation data in SOS (Sensor Observation Service)
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.
|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.