In the second part of this blog series, we will discuss the interoperability between OGC SOS and SensorThings API. In summary, OGC SensorThings API can interoperate with SOS at both the data level and service interface level. That means SensorThings is backward compatible with SOS. However, SOS cannot interoperate with SensorThings API at the service interface level. That is because SensorThings API provides more features and better flexibility that cannot be matched by SOS. Details are as follows.

O&M enables data interoperability

The Observation data provided by both SOS and SensorThings are both based on the OGC Observations and Measurements (O&M) [OGC/ISO 19156:2011] standard. O&M defines a conceptual model for observations, and for features involved in sampling when making observations. Both OGC SOS and SensorThings API standards provides a physical model (i.e., encoding) based on the O&M conceptual model. As a result, it is not a surprise that at the data level the two standards can easily interoperate with each other. That means data retrieved from SOS O&M XML or SWE data array can be easily transformed into SensorThings API’s JSON encoding back and forth without loss of information.

SensorThings API’s service interfaces can be backward compatible with SOS

At the service interface level, SensorThings API can interoperate with SOS. That means for every service interface provided by SOS, we can find an equivalent way in SensorThings to fulfill the same function provided by that interface. As a result, an SOS can be built based on an SensorThings API. We can build a facade for SensorThings API so it can also accept SOS requests. In fact, SensorUp’s SensorThings API already provides SOS v.2.0 interfaces. 🙂

Take example 9 from the SOS specification as an example:

<br /><br />
  ?service=SOS<br />
  &amp;version=2.0.0<br />
  &amp;request=GetObservation<br />
  &amp;offering=<br />
  &amp;observedProperty=<br />

An equivalent SensorThings API request is:

<br />$expand=Observations<br />

The above two requests fulfill the same function, that is to retrieve Observations of certain ObservedProperty (e.g., get all water temperature observations).

SOS service interfaces cannot interoperate with SensorThings API

However, SOS’ service interface is not compatible with SensorThings. SensorThings adopts OData’s URL Path and Query Options. OData’s URL Path and Query Options are very flexible and powerful, like “SQL for the Web”. As a result, there are many functions that can be achieved effortlessly with SensorThings but not possible in SOS. Take the following use case as an example: Find all Observations whose Feature-of-Interest’s description contains ‘water’.

A SensorThings request looks like:

</pre><br />
<span class="s1">$filter=substringof(‘water’,description)&$expand=Observations</span><br />

As you can see, it’s a pretty straightforward SensorThings query. However, the above request cannot be fulfilled by SOS. This is just one example, and there are many examples and use cases that can be done by SensorThings but not SOS.


If your organization is deciding which international standard to use to build an interoperable IoT data cloud, our recommendation will be using SensorThings. SensorThings API provides superior interoperability, as it is backward compatible with SOS. At the data interoperability level, the Observations from both services can interoperate with each other. That means we can transform Observations from one service to the other without information loss. A SensorThings can provide SOS interfaces easily, and SensorUp’s implementation demonstrates such capabilities. However, SOS cannot match SensorThings flexibility. As a result, SOS cannot interoperate with SensorThings at the service interface level. 


Leave a Reply

You must be logged in to post a comment.