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:

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.

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.