In our series of posts leading up to the INSPIRE Hack in Barcelona next week, we have today arrived at another extension point for Map Compositions, namely that of handling dynamic data.
We all love sensors. Magic little devices that are scattered all over, feeding big data goodness into the cloud for us to crunch, analyze and derive knowledge from.
In theory, at least until we try using it, we also love Sensor Observation Services. That is, we love that a standard exist – we do however wonder why sensor manufacturers do not implement it and why it takes 12 kb of ASCII encoded XML to register a 4 byte floating point observation in a sensor server.
Enter SensLog, a Volunteered Geographical Information and Sensor data hub that both offers the convenience of SOS compliant querying capabilities for upstream standards compliance — but also offers a simplified JSON based Web Service API for rapid application development.
Anyway, the above may be considered a slight derailing from the topic at hand.
The matter of the fact is that in addition to (semi-)static map tiles of the Open Street Map nature, decentralized data sources increasingly include dynamic data sources. Some of these are publishing their data as WFS services, and as such constitute no difference from any other WFS service – others are only available through sensor data networks. Here is the weak, although significant link towards the mention of SOS and SensLog.
We would like to see an extension to the Map Composition schema that enables inclusion of dynamic sensor data. Sensor Observation Services would be a natural candidate for inclusion – but given the presence of SensLog in the SDI4Apps family of software components, we would like to start here.
What is required is a simple RESTful Web Service API that returns a GeoJSON file with the sensor observations that can be stacked into a Map Composition document.
The API must expose methods to:
- Select one or more sensors (or sensor types) that data should be reported for
- Select an area of interest (typically a map extent to limit the number of returned resources)
- A time period (datetime to datetime or recurring time of day, recurring weekday etc.)
- A maximum number of observations to return per sensor (once again to limit the data transfer volume)
Furthermore, a user interface to setup the queries that shows in real-time the combined effect of the applied filters must be developed — perhaps on top of HSLayers NG – perhaps on top of any other map client such as Leaflet, Openlayers, QGIS…
Naturally, this is a challenge that sits close to the core developers of SensLog — are you up for the challenge Michal?
See you all physically or virtually at the INSPIRE Hack next week… Until then, toodel-pip.
