Unlocking Sensor Data – I’ll send an SOS to the world

Revealing: the title refers, for the younger readers, to a great 1979-hit by The Police as expanded below. To be played at the loudest possible volume. If you don’t see anything here below try the YouTube link directly: https://www.youtube.com/watch?v=MbXWrmQW-OE.

One of the main aspects that glues the OSGeo-world together are OGC-standards: WMS, WFS, WMTS, WCS and WPS are, at least for most insiders, not hollow acronyms. But who knows about and uses SOS? SOS stands for “Sensor Observation Service”, an OGC standard within the elaborate framework of the OGC SensorWeb Enablement.  SOS provides a standard to publish (SOS-T) and request time-based (meta-) data, mostly from “Sensors”. Its convention is similar to WMS/WFS (GetCapabilities, DescribeSensor, GetObservation etc). Think of weather or air quality measurements over time.

The Internet of Things (IoT)  is now gaining a strong momentum: “The Internet of Things (IoT) is the network of physical objects or “things” embedded with electronics, software, sensors, and network connectivity, which enables these  objects to collect and exchange data. The Internet of Things allows objects to be sensed and controlled remotely across existing network infrastructure, creating opportunities for more direct integration between the physical world and computer-based systems, and resulting in improved efficiency, accuracy and economic benefit Each thing is uniquely identifiable through its embedded computing system but is able to interoperate within the existing Internet infrastructure. Experts estimate that the IoT will consist of almost 50 billion  objects by 2020.” (from Wikipedia).

So how will SOS and the generic OGC SensorWeb Enablement will fit into this force? I really don’t know. For many of the OGC-standards like WMS, there are multiple implementations. For SOS  I know about just two: the 52 North SOS, and the IstSOS.  Both of these are powerful with their own strengths and limitations.

I have worked successfully with the 52 North SOS within a Dutch project on Air Quality. All details are in this online document. In essence we are (still) publishing and emitting Dutch National Air Quality data via a SOS server. At the same time, via GeoServer, using WMS-Time via this web-client. On the way I found that the OGC-SOS Standard is complex and quite cumbersome in its usage. 52 North has provided a custom REST interface that appeals to be more usable. But SOS with its inner talk of “Procedures” and “Offerings” remains a Hot Potato.

heron-viewer-o3-ts

So the broader question is more about the OGC SOS standard and the related OGC SensorWeb Enablement  : how we as an OSGeo-community think it should evolve within the expanding world of the IoT? My opinion is that we need to strive for more ease-of-use. SOS-as-standard is an academic challenge. A window to the future may be the OGC-effort initiated by Steve Liang: the SensorThings API not only provides a simplification from the original  OGC SensorWeb Enablement but also a modern way of community-based cooperation of standards making via GtiHub: http://ogc-iot.github.io/ogc-iot-api. Time will tell, a message in a bottle will also eventually arrive.

 

 

 

 

 

 

4 Comments:

  1. Pingback: Unlocking Sensor Data – I’ll send an SOS to the world | GeoNe.ws

  2. Great to know your positive comments on OGC SensorThings API. OGC SensorThings API is at its final stage to become v1.0 (voting starts in Dec). If you have any potential project in mind, please let us know. We will be very happy to work with you!

    BTW, the other major difference between SOS and SensorThings is the support of real-time applications. SensorThings API support pub-sub via OASIS MQTT, an popular IoT transport layer standard. And because SensorThings is RESTful, it is compatible with MQTT’s topic structure nicely. Unfortunately SOS is XML-RPC, it is not compatible with MQTT.

    In addition, as SensorThings entities are resource-oriented and “inter-linked”, it is very search engine or catalog friendly. Plus the MQTT support, whenever a new entities (e.g., a new Observation or a new Sensor becomes online), it can be “pushed” to the subscribers in near-real-time. This is also something missing in SOS.

    I am writing a series of blogs for SensorThings. Feel free to check it out here: https://sensorup.atlassian.net/wiki/pages/viewrecentblogposts.action?key=SPS

    Steve L.

    • Just van den Broecke

      Good to hear from you Steve! Also to see more lightweight stuff coming out of OGC using GitHub (e.g. GeoPackage). At Geonovum we have several cases where we may apply SensorThings. We are exploring several platforms, also for example FIWARE https://www.fiware.org (which also support MQTT) and LoRa (http://thethingsnetwork.org). Is there an Open Source (reference) implementation for SensorThings?

  3. “Unfortunately SOS is XML-RPC, it is not compatible with MQTT.”

    How does this tie in to the MQTT service offered as part of the istSOS?

Leave a Reply

Your email address will not be published.