SWECommon Encoding Discussion

SWE Common Encodings

 

Summary

 

A Sensor Observation Service supports one operation (request) named getObservation. The result is an Observation & Measurements (O&M) document. O&M provides the conceptual model and encoding to represent observations. An observations consists of: procedure, a feature, properties of the feature being estimated and a result. The O&M specification leaves open the type of result being returned. However, at several OGC projects, SweCommon

is the encoding of preference.  This page summarizes how to encode common marine observations in SweCommon.

 

Marine Devices

Marine devices could be of many types: in-situ, moving, constrained by a tethered etc. Most importantly is to be able to generalize the shape that the observation takes and the information required to process the data, such as plotting it appropriately.

Observation Shapes

Some frameworks describe the shape of the observation as features (CSML, O&M part 2, Arc Marine).  Some links:

• NetCDF - Common Data Model  NcML
• Draft-  Point Observation Conventions
• Common Marine Data Types from Arc Marine
• CSML - Climate Science Modeling Language - users manual v2 ( see table 1)
• Arc Hydro

 

For our purposes the shape of the observation could be one the following:

• Point
• Vertical Profile
• Horizontal Profile
• Trajectory
• Grid
• Swath

 

SWECommon Model

SWWCommon model is based on ISO 11404. In essence is composed of arrays and records. Arrays contains fields of a similar type, while records contain fields of different types. A field could be a string, integer, boolean etc.

Goals for Encoding

 

• Encoding provides all the information required for accurate plotting of the data (e.g. distinguishing that a set of tuples (x,y,z,t,v) are a grid type vs a trajectory)
• Encoding is simple and it is easy to create software to publish SOS / SWECommon
  
• Encoding is simple and it is easy to create software to read SOS / SWECommon
• Encoding allows easy to export of data to Spreadsheets
• Encoding truly represents a conceptual model
• Encoding is optimize for minimum size, reduce accessing time
• Encoding allows for fast plotting of the data
  

 

Encoding

Factoring vs Non Factoring

Lets assume the following:

• x = longitude
• y = latitude
• z = depth
• t = time
• v = values ( temperature, pressure, etc..)
• { } = array. An array always contains records and set of values .
• [ ] = record. A Record contains fields. Fields could be arrays or simple fields (that could have a value)

 And if we have data from a fixed sensor (e.g. temperature) in a mooring, the encoding will look as follows:

• Factoring: [y,x,z,{[t,v]}] - XML Example: swec-point.xml
• Non Factoring: {[y,x,z,t,v]} - XML Example: swec-point2.xml

 

Solution

Do all Non Factoring.

 

How do we differentiate one shape from another (e.g.  trajectory vs collection of stations )?

By a semantic tag in the swe:DataRecord definition

:

 

...   
<swe:elementType name="pointDataRecord">
  <swe:DataRecord definition="http://mmisw.org/ont/mmi/obs.owl/pointDataRecord">
...

 

The semantic tags to be used are:

 

• Point:  http://mmisw.org/ont/mmi/obs.owl/pointDataRecord
• Vertical Profile:  http://mmisw.org/ont/mmi/obs.owl/verticalProfileDataRecord

• Horizontal Profile: http://mmisw.org/ont/mmi/obs.owl/horizontalProfileDataRecord
• Trajectory: http://mmisw.org/ont/mmi/obs.owl/trajectoryDataRecord
• Grid: http://mmisw.org/ont/mmi/obs.owl/gridDataRecord
• Swath: http://mmisw.org/ont/mmi/obs.owl/swathDataRecord