How to model your observation data in SOS 2.0?

The SOS is designed to provide access to observations. For the SOS 2.0, these observations are by default encoded conformant to the Observations and Measurements 2.0 (O&M 2.0) standard. Check out the conceptual model of O&M 2.0 here and its XML encoding here.

The figure below depicts the central terms of the O&M 2.0 model.

As shown in the figure above, an observation aggregates the following elements:

• Feature of interest: a feature (so a representation of a real-world object) that carries the property which is observed.
  This can be either a domain feature (aka sampled feature), e.g. “Mississippi”, or a sampling feature, e.g. “water gage X" at Mississippi river. 
• Phenomenon time: time when the observation's result applies.
• Result time: time when the observation's result has been created.
  
• Procedure: instance of a process which
  has performed the observation. This is usually a physical sensor (or
  sensor system) (e.g., thermometer "t_234") but can also be for example a
  computation, post-processing step or simulation.
• Observed property: description (e.g. a
  concept in an ontology) of the property which is observed (e.g. “water
  temperature”, “salinity”, or here “Wind_Speed”).
• Result: the result value of the observation (e.g. 23 m/s). Can be a scalar value or a complex multi-dimensional array.

As the example shown in the figure above is a numerical measurement, the result element contains the following additional element:

• Unit of Measure (uom): allows the interpretation of the result value. Usually UCUM codes are used.

There are also additional optional properties (e.g. the validTime property which represents the time span for which an observation is valid). For more information take a look on the Observations and Measurements 2.0 (O&M 2.0) standard.

What steps are needed to model my data in O&M?

Usually, the procedure to map your data to O&M consists of the following steps:

1. Identify the sensors which are executing the observations. These are the procedures in the O&M model. If no global identifiers are available, create them by using the URL TBD. Create SensorML descriptions of the sensors like described
2. Identify the features of interest which are observed by the sensors. These are usually real-world objects like buildings, points of interest, tracked objects, etc. Try to reuse already existing feature respresentations. If there are not any, define your own feature type and create global identifers using the URL scheme TBD. Very often, the observations are samples of continuous phenomena in space. In that case, re-use the pre-defined feature types for sampling features as defined in O&M, subclause XX.
3. Identify the properties observed by the sensors. Try to re-use already existing definitions in dictionaries/vocabularies like provided in the NASA SWEET ontology. If there aren't any available, provide descriptions and create global identifiers using the URL scheme.
4. Indentify the times when the observation has been taken (phenomenonTime) and when the observation's result has been created (resultTime). If they're the same you can point from the resultTime to the phenomenonTime.
5. Identify the type of the observation's result. There are several subtypes of the generic observation defined in O&M providing well-defined result types. For example, if your observation results are scalar numerical values, you should use the OM_Measurement. If your observation results are just boolean values, you might use the OM_TruthObservation.

That's it.

Example